i
REKAYASA PERANGKAT LUNAK
Chapter 13 - DEPENDABILITY ENGINEERING
Anggota Kelompok :
1.
Hairil Fiqri Sulaiman
1211500689
2.
M. Uwais Al- Qarni
1211500846
3.
Lucky Sholihin
1211500333
4.
Zolandia Ramanda
1211502750
5.
Edi Sucipto
1211504327
6.
Austin Arta Tunggal Pratama
1211503691
Jurusan Ilmu Komputer Dan Elektronika
Fakultas Matematika Dan Ilmu Pengetahuan Alam
Universitas Gadjah Mada
1
Penggunaan software engineering techniques merupakan bahasa
pemrograman yang baik digunakan. Yang telah membawa perbaikan yang signifikan dalam ketergantungan bagi sebagian besar perangkat lunak. Namun demikian, kegagalan sistem bisa saja terjadi. Ini dipengaruhi ketersediaan sistem atau penyebab hasil yang salah diproduksi
Dependability engineering berkaitan dengan teknik-teknik yang digunakan untuk meningkatkan keandalan kedua sistem kritis dan non-kritis. Teknik ini mendukungan tiga pendekatan yang saling melengkapi yang digunakan dalam mengembangkan perangkat lunak, diantaranya :
1. Fault avoidance, Desain software dan pelaksanaan proses harus menggunakan pendekatan yang mengembangkan perangkat lunak untuk membantu menghindari desain dan pemrograman kesalahan sehingga meminimalkan jumlah kesalahan yang mungkin muncul ketika sistem mengeksekusi. Sedikit kesalahan berarti lebih sedikit kesempatan untuk kegagalan run-time.
2. Fault detection and correction, Verifikasi dan proses validasi adalah desain yang dirancang untuk menemukan dan menghapus kesalahan dalam program, sebelum digunakan untuk penggunaan operasional. Sistem kritis memerlukan verifikasi sangat luas dan validasi untuk menemukan banyak kesalahan. Mungkin sebelum penyebaran sistem stakeholder meyakinkan bahwa sistem ini bisa diandalkan.
3. Fault tolerance, Sistem ini dirancang sedemikian rupa sehingga kesalahan atau sistem tak terduga selama eksekusi akan terdeteksi pada saat run-time dan dikelola sedemikian rupa sehingga kegagalan sistem tidak terjadi.
Menggunakan pendekatan sederhana untuk toleransi kesalahan
berdasarkan built-in serta memeriksa run-time dapat dimasukkan dalam semua sistem. Namun, teknik toleransi kesalahan yang lebih khusus (seperti penggunaan fault-tolerant arsitektur sistem) umumnya hanya digunakan ketika tingkat yang sangat tinggi dari sistem ketersediaan dan kehandalan diperlukan.
Sayangnya, penerapan fault-avoidance, fault-detection, dan fault-tolerance
2 Gambar 13.1
Akibatnya, perusahaan pengembangan perangkat lunak menerima bahwa perangkat lunak mereka akan selalu mengandung beberapa kesalahan residual. Tingkat kesalahan tergantung pada jenis sistem. Apabila dibungkus plastik produk memiliki tingkat yang relatif tinggi dari kesalahan, sedangkan sistem kritis biasanya memiliki kepadatan kesalahan jauh lebih rendah. Dasar pemikiran untuk menerima kesalahan adalah bahwa, jika dan ketika sistem gagal, lebih murah untuk membayar konsekuensi dari kegagalan dari itu akan menemukan dan menghapus kesalahan sebelum pengiriman sistem.
Banyak sistem kritis, seperti sistem pesawat, sistem medis, dan akuntansi sistem, digunakan dalam domain diatur seperti transportasi udara, obat-obatan, dan keuangan. Pemerintah pusat menetapkan peraturan yang berlaku di domain tersebut dan menunjuk badan pengawas untuk memastikan bahwa perusahaan-perusahaan mengikuti peraturan tersebut. Dalam prakteknya, ini berarti bahwa regulator sering harus yakin bahwa sistem perangkat lunak kritis dapat terpercaya dan ini memerlukan bukti jelas yang menunjukkan bahwa sistem ini dapat diandalkan.
Oleh karena itu, proses pembangunan untuk sistem kritis tidak hanya berkaitan dengan memproduksi sistem yang diandalkan, juga harus menghasilkan bukti yang dapat meyakinkan regulator bahwa sistem dapat diandalkan.
13.1 Redudancy and diversity
Redundancy dan diversity merupakan strategi fundemental untuk meningkatkan kehandalan dari jenis sistem. Redundancy berarti kapasitas cadangan dalam sistem yang dapat digunakan jika bagian dari sistem ada yang gagal. Diversity berarti redudant komponen sistem dari jenis yang berbeda, sehingga meningkatkan kemungkinan tidak akan gagal dengan cara yang persis sama.
3
yang digunakan adalah dari jenis yang berbeda (diversity) agar lebih aman. Ini berarti bahwa jika seorang penyusup menemukan cara untuk membobol salah satu kunci, mereka harus menemukan cara yang berbeda untuk membobol kunci lainnya sebelum mereka dapat masuk. Contoh lain, kita harus membackup data komputer kita untuk menjaga salinan kita apabila terjadi kegagalan disk, backupan disimpan pada beragam perangkat terpisah atau perangkat eksternal.
Sistem perangkat lunak yang dirancang untuk kehandalan dapat mencakup komponen yang menyediakan fungsi yang sama dengan komponen sistem lainnya. Jika komponen-komponen berlebihan yang beragam tidak sama dengan komponen lainnya, kesalahan umum dalam direplikasi komponen tidak akan mengakibatkan kegagalan sistem. Redundansi juga dapat disediakan seperti kode pengecekan tambahan yang benar-benar diperlukan untuk sistem fungsi. Kode ini dapat mendeteksi beberapa jenis kesalahan sebelum mereka menyebabkan kegagalan. Hal ini dapat memanggil mekanisme pemulihan untuk memastikan bahwa sistem terus beroperasi. Dalam sistem, ketersediaan merupakan persyaratan penting. Ini secara otomatis akan mulai beroperasi jika server yang ditunjuk gagal.
Diversity and redundancy dapat juga digunakan untuk mencapai proses yang diandalkan dengan memastikan bahwa kegiatan proses seperti validasi perangkat lunak tidak bergantung pada satu proses atau metode. Hal ini memlindungi perangkat lunak karena mengurangi kemungkinan kegagalan proses, di mana kesalahan manusia yang dilakukan selama proses pengembangan perangkat lunak menyebabkan kesalahan perangkat lunak. Sebagai contoh, kegiatan validasi dapat mencakup program pengujian, panduan program inspeksi, dan analisis statis sebagai mencari-cari kesalahan teknik. Ini adalah teknik pelengkap dalam salah satu teknik menemukan kesalahan yang terlewatkan oleh metode lain. Selain itu, anggota tim yang berbeda mungkin bertanggung jawab untuk kegiatan proses yang sama (misalnya, pemeriksaan program). Setiap orang menangani tugas dengan cara yang berbeda tergantung pada kepribadian mereka, pengalaman, dan pendidikan, jadi ini semacam redundansi yang memberikan perspektif yang beragam pada sistem.
13.2 Dependable Processes
Kehandalan proses perangkat lunak diciptakan untuk menghasilkan suatu perangkat lunak yang memiliki kehandalan. Perusahaan menggunakan kehandalan proses untuk meyakinkan suatu proses telah berjalan dengan tepat, terdokumentasi, dan teknik pengembangannya nantinya dapat digunakan untuk mengembangkan sistem yang bersifat kritis. Alasan paling rasional bagi perusahaan melakukan proses kehandalan adalah bahwa suatu perangkat lunak akan dikatakan baik apabila dalam distribusinya nanti hanya mengandung sedikit masalah sehingga akan jauh dari kegagalan sistem.
4
menampilkan model untuk proses yang berdasarkan regulasi, disertai dengan bukti bahwa proses tersebut telah diikuti.
Regulasi juga meyakinkan bahwa semua proses harus di berlakukan untuk semua pengembang meskipun dalam suatu pengembangan akan berada dalam proyek yang berbeda. Ini berarti bahwa semua proses harus didefinisikan secara ekplisit dan berulang:
1. Proses didefinisikan secara eksplisit adalah salah satu yang mendefinisikan
model proses yang ditetapkan digunakan untuk mendorong proses pembuatan perangkat lunak. Harus ada data yang dikumpulkan selama proses yang menunjukkan bahwa semua langkah yang diperlukan dalam model proses telah diberlakukan.
2. Proses berulang adalah salah tidak menggantungkan pada interpretasi dan
penghakiman individu. Sebaliknya, proses dapat diulang di seluruh proyek dengan berbagai anggota tim, terlepas dari siapa yang terlibat dalam pengembangan. Hal ini penting untuk sistem yang kritis, yang sering memiliki siklus pengembangan yang panjang di mana sering ada
perubahan signifikan dalam tim pengembangnya.
Kehandalan proses menghasilkan penggunaan redundansi dan keragaman mencapai kehandalan. Hal tersebut sering diikut sertakan dalam berbagai kegiatan yang memiliki tujuan yang sama. Misalnya, inspeksi program dan pengujian yang bertujuan untuk menemukan kesalahan dalam program. Pendekatan dapat melengkapinya sehingga secara bersamaan akan mendapatkan kesalahan dengan proporsi yang lebih tinggi dibandingkan teknik pencarian secara personal.
Kegiatan yang dilakukan dalam kehandalan proses jelas tergantung dari jenis perangkat lunak yang sedang dikembangkan. Secara umum, bagaimanapun, kegiatan ini harus diarahkan untuk menghindari pengenalan kesalahan dalam sistem, mendeteksi dan menghapus kesalahan, serta memelihara informasi tentang proses itu sendiri.
Contoh kegiatan yang mungkin diikut sertakan dalam kehandalan proses meliputi:
1. Mengulas kebutuhan untuk memeriksa bahwa kebutuhan sebisa mungkin
lengkap dan konsisten.
2. Melakukan manajemen kebutuhan untuk memastikan bahwa perubahan
dari kebutuhan diterkontrol dan dampak dari usulan perubahan kebutuhan yang dipengaruhi oleh perubahan dipahami oleh semua pengembang.
3. Spesifikasi formal, dimana pemodelan matematika dari perangkat lunak itu
dibuat dan dianalisis.. Manfaat yang paling penting adalah bahwa hal itu memaksa analisis yang sangat rinci dari suatu rekayasa kebutuhan. Analisis itu sendiri dimungkinkan untuk menemukan masalah kebutuhan yang bias saja terlewatkan dalam ulasan kebutuhan.
4. Pemodelan sistem, dimana desain sebuah perangkat lunak
didokumentasikan secara eksplisit dalam suatu gambaran model dan
hubungan antara kebutuhan dengan model tersebut juga
5
5. Inspeksi Desain dan Program, deskripsi dari sistem yang berbeda diperiksa
oleh orang yang berbeda pula. Pemeriksaan sering dilakukan dengan checklist desain dan kesalahan pemrograman yang bersifat umum.
6. Analisis statis, di mana pemeriksaan otomatis dilakukan pada kode sumber
program. Tahap ini mencari anomali yang mengindikasikan kesalahan atau kelalaian pemrograman.
7. Uji perencanaan dan manajemen, dimana seperangkat untuk melakukan
tes sistem telah didesain. Proses pengujian harus dimanajemen dengan hati-hati untuk mendemonstrasikan semua cakupan dalam tes dari rekayasa kebutuhan sudah diterapkan dalam proses pengujian.
Proses manajemen mutu menetapkan seperangkat proses dan standarisasi produk. Mereka juga mencakup kegiatan yang proses pengambilan informasi untuk mendemonstrasikan bahwa standar tersebut telah diikuti. Misalnya, mungkin ada standar yang ditetapkan untuk melakukan inspeksi program. Pemimpin tim inspeksi bertanggung jawab untuk mendokumentasikan semua proses untuk menunjukkan bahwa standar pemeriksaan memiliki diikuti.
Satu masalah umum dengan perangkat lunak adalah terdapat komponen yang salah masuk dalam pengembangan sistem. Hal ini dapat membawa situasi dimana sistem akan mengeksekusi semua, termasuk komponen yang belum diperiksa selama proses pengembangan.
Banyak pandangan luas terhadap pendekatan Agile, tidak semua benar-benar cocok untuk kehandalan proses (Boehm, 2002). Pendekatan Agile fokus pada pengembangan perangkat lunak bukan pada mendokumentasikan apa yang telah dilakukan. Mereka sering memiliki pendekatan yang cukup informal untuk berubah dan manajemen mutu. Basis Rencana pendekatan untuk pengembangan kehandalan sistem, yang membuat dokumentasi yang regulasi dan pemangku kepentingan sistem eksternal lainnya dapat dipahami, umumnya lebih disukai. Namun demikian, manfaat dari pendekatan Agile sama-sama berlaku untuk sistem yang kritis. Terdapat pula laporan dari keberhasilan dalam menerapkan metode Agile di wilayah (Lindvall, et al., 2004) dan kemungkinan bahwa varian metode Agile yang cocok untuk rekayasa sistem yang kritis akan dikembangkan.
13.3 Arsitektur Sistem yang Diandalkan
Seperti yang telah dibahas, pengembangan system yang handal harus
memiliki kehandalan proses. Namun, itu tidak menjadikan system anda benar –
benar handal. Arsitektur dibutuhkan untuk melakukan toleransi ketika terjadi kesalahan system. Berarti arsitektur harus dirancang untuk memahami komponen dan mekanisme yang memungkinkan control dapat berdalih dari satu komponen ke komponen yang lainnya ketika terjadi kesalahan.
6
Realisasi sederhana yakni pada replica server, yang mana terdapat 2 server yang melakukan tugas yang sama sehingga memiliki salinan transaksi. Server melalui komponennya akan melakukan menejemen terhadap suatu permintaan sehingga akan di salurkan ke server tertentu. Namun pada kegagalan server yang terjadi biasanya adalah kurangnya respon, solusianya akan ada pergantian server terhadap server yang mengalami kegagalan kemudian permintaan akan dikirim ulang ke server lain.
Pendekatan ini sering digunakan pada proses transaksi, karena mudah untuk mendapatkan salinan transaksi yang akan diproses tersebut. Proses pengolhan transaksi dirancang agar data hanya diupdate sekali, sehingga keterlambatan system tidak mempengaharui integritas system.
Replica server memiliki kerangkapan data yang tidak seragam. Perangkat tersebut identik dalam prosesnya sehingga kegagalan dapat dideteksi dengan terlokalisasi di satu mesin. Sayangnya kegagalan perangkat lunak pada versi yang lain dapat terjadi pada saat ya, sehingga membutuhkan gaya arsitektur lain yang mampu memasukkan semua versi dari software dan hardwere.
13.3.1 Protection systems
Sistem proteksi adalah system khusus yang berkaitan dengan system lainnya. Seperti pada system kereta api, yang memiliki proteksi terhadap segala kemungkinan pahit. Misalnya ketika kereta telah melewati sinyal merah namun kereta tidak melambat. Maka system proteksi akan melakukan perannya dengan menerapkan rem kereta otomatis. Sistem tersebet independen sehingga jika terdapat system yang tidak bisa dikendalikan maka system proteksi akan mematikan proses dan segala peralatannya.
Gambar 13.3 Arsitektur system Proteksi
7
kedua sebagai sensor utama. Ini sangat berguna karena jika terjadi kegagalan pada sensor utama akan ada sensor proteksi yang membackup sehingga system tetap beroperasi dengan memindahkan keadaan yang berpotensi tidak aman menjadi lebih aman. Itu merupak salah satu contoh umum dari arsitektur toleransi kesalahan.
Keuntungan pada arsitektur ini adalah semua proses dapat dipantau untuk memastikan bahwa system dalam keadaan aman dan software akan terlihat lebih simple. Sudah harus dipastikan dalam rancangannya kegagalan pada system proteksi memiliki probabilitas yang rendah misalnya 1/1000 sebab dengan itu kegagalan pada system proteksi akan sangat langka.
13.3.2 Self-monitoring architectures
System ini dirancang agar system dapat memantau operasinya sendiri, dan mengambil tindakan jika terdeteksi masalah. Hal ini dicapai dengan melakukan komputasi pada bagian yang terpisah lalu membandingkan output dari komputasi tersebut. Jika output yang didapat identik pada saat yang sama, maka dapat dipastikan tidak terjadi masalah. Namun bila sebaliknya maka kemungkinan terjadi kesalahan. Ketika terjadi kesalahan maka system akan memberikan exception error pada output line. Yang kemudaian secara otomatis control akan dipindah ke system lain. Seperti yang digambarkan dibawah ini
Gambar 13.4 Arsitektur Self-Monitoring
Arsitektur self-Monitoring dirancang sedemikian rupa seperti dibawah ini :
1. Hardware yang digunakan pada tiap bagian (channel) berbeda. Hal ini
memungkinkan untuk menjauhkan dari kesalahan prosessor dan menambah pertimbangan jika terjadi kesalahn dalm komputasi.
2. Software yang digunakan ditiap channel beragam. Jika tidak maka kita akan
menemukan kesalahan yang sama di waktu yang sama pula pada tiap channelnya.
8
mengatasi kesalahan hanya dengan mematikan proses sistemnya maka itu merupakan ketidaknyamanan.
Namun pada situasi yang membutuhkan ketersediaan system yang tinggi, maka kita harus melakukan self-checking system secara parallel. Kemudian dibutuhkan switch case unit atau pilihan ketika terdeteksi kesalahan lalu memilih sebuah jawaban dari system, dimana kedua channel harus memiliki respon yang konsisten. Seperti pada system control penerbangan Air Bus 340, di mana digunakan 5 komputer yang berperan sebagai self-checking. Seperti yang terdapat pada gambar 13.5
Gambar 13.5 Arsitektur system control Air Bus
Pada system control penerbangan Air Bus, computer melakukan komputasi secara parallel, dengan menggunakan input yang sama. Kemudaian output akan terhubung ke filter yang dapat mendeteksi jika status menunjukan adanya indikasi kesalahan, jika demikian maka output tersebut akan dimatikan. Output kemudaian akan diambil dari alternatif system lainnya sehingga mungkin terjadi empat computer yang gagal namun penerbangan tetap berlanjut karena memiliki satu computer yang benar. Arsitektur tersebut telah berjalan lebih dari 15 tahun dan tak ada situasi di mana control kehilangan pesawat dalam penerbangan karena kegagalan system. Para desianer Sistem Air Bus telah mencoba banyak cara
1. Computer primer pada system control menggunakan prosessor yang
berbeda dengan computer sekunder pada system control.
2. Chipset yang digunakan tiap channel di primer dan system sekunder
9
3. Software yang digunakan pada system control sekunder hanya memiliki
fungsionalitas kritis untuk mengurangi kompleksitas software pada system primer
4. Software ditiap channel pada primer dan sekunder system dikembangkan
dengan bahasa pemrograman yang berbeda dan dengan tim yang berbeda.
5. Perbedaan bahasa pemrograman digunakan pada system primer dan
sekunder.
Seperti yang akan dibahas di bagian berikutnya, ini tidak menjamin keberagaman tetapi mengurangi kemungkinan kegagalan system pada saluran yang berbeda.
13.3.3 N-Version Programming
Arsitektur Self-monitoring adalah contoh dari sistem di mana pemrograman multiversion yang digunakan untuk menyediakan kelebihan perangkat lunak dan keragaman. Gagasan tentang pemrograman multiversion berasal dari sistem perangkat keras dimana konsep tentang Triple modular redundansi (TMR) telah digunakan selama bertahun-tahun untuk membangun system yang toleran terhadap kegagalan perangkat keras (Gambar 13.6).
Pendekatan terhadap toleransi kesalahan bergantung pada sebagian besar kegagalan perangkat keras yang hasilnya dari komponen yang gagal bukan kesalahan desain. Ini mengasumsikan bahwa, ketika beroperasi penuh, semua unit perangkat keras melakukan sesuai spesifikasi. Oleh karena itu ada kemungkinan kegagalan yang rendah terhadap komponen secara simultan di seluruh unit hardware.
Dalam sistem TMR, unit
perangkat keras merupakan
replikasi yang berjumlah tiga
(atau kadang-kadang lebih).
Hasil dari setiap unit akan diteruskan ke output selector yang biasanya diimplementasikan sebagai sistem pemilihan. Sistem ini membandingkan semua input dan, jika dua atau lebih itu sama, maka nilai tersebut output. Jika salah satu unit gagal dan tidak menghasilkan output yang sama dengan unit lain, outputnya diabaikan.
10
Hal ini diasumsikan bahwa kemungkinan dari tim yang berbeda membuat desain yang sama atau membuat kesalahan kecil. Pendekatan serupa dapat digunakan untuk perangkat lunak fault-tolerant dimana versi N beragam dari sistem perangkat lunak mengeksekusi secara paralel (Avizienis, 1985; Avizienis, 1995). Pendekatan ini untuk toleransi kesalahan perangkat lunak, diilustrasikan pada Gambar 13.7, telah digunakan dalam railway signaling system, aircraft system, dan reactor protection system.
Dengan menggunakan spesifikasi yang umum, sistem perangkat lunak yang sama diimplementasikan oleh sejumlah tim. Versi ini dilaksanakan pada komputer yang terpisah. output mereka tersebut dibandingkan dengan menggunakan sistem pemilihan, dan hasilnya konsisten atau output yang tidak dihasilkan pada waktunya akan ditolak. Minimal tiga versi sistem secara tepat tersedia sehingga dua versi harus konsisten dalam hal kegagalan tunggal.
Hal ini menyebabkan biaya pengembangan perangkat lunak yang sangat tinggi. Akibatnya, pendekatan ini hanya digunakan dalam sistem dimana tidaklah praktis untuk menyediakan sistem layanan perlindungan yang dapat menjaga terhadap kegagalan keamanan-kritis.
13.3.4 Software Diversity
Semua arsitektur fault-tolerant di atas bergantung pada keragaman perangkat lunak untuk mencapai kesalahan toleransi. Perangkat lunak yang akan yang ditambahkan oleh tim yang berbeda yang tidak seharusnya berkomunikasi
selama proses pembangunan, sehingga mengurangi kemungkinan
kesalahpahaman atau salah tafsir dari spesifikasi. Perusahaan yang menggunakan sistem tersebut dapat mencakup kebijakan keragaman eksplisit bahwa bertujuan untuk memaksimalkan perbedaan antara versi sistem. Sebagai contoh:
1. Dengan memasukkan persyaratan bahwa harus megggunakan metode
desain yang berbeda. Sebagai Misalnya, satu tim menghasilkan desain berorientasi objek dan tim lain dapat menghasilkan fungsi dari orientasi desain tersebut.
11
2. Dengan yang menyatakan bahwa implementasi harus ditulis dalam bahasa
pemrograman yang berbeda. Misalnya, dalam tiga-versi sistem , Ada, C ++, dan Java yang dapat digunakan untuk menuliskan versi perangkat lunak.
3. Dengan membutuhkan penggunaan alat yang berbeda dan pengembangan
lingkungan untuk sistem.
4. Berdasarkan secara eksplisit membutuhkan algoritma yang berbeda yang
akan digunakan dalam beberapa bagian dari implementasi.
Setiap tim pengembangan harus bekerja dengan spesifikasi sistem rinci (kadang-kadang disebut V-spec) yang telah berasal dari ketentuan spesifikasi sistem(Avizienis, 1995). Serta menentukan fungsionalitas dari sistem, spesifikasi rinci harus mendefinisikan dimana output sistem sebagai perbandingan harus dihasilkan. Idealnya, versi yang beragam sistem seharusnya tidak memiliki ketergantungan dan seharusnya gagal dengan cara yang sama sekali berbeda. Jika hal ini terjadi, maka keseluruhan keandalan suatu sistem yang beragam diperoleh dengan melipatgandakan Kehandalan dari masing-masing saluran. Jadi, jika setiap saluran memiliki kemungkinan kegagalan pada permintaan dari 0,001, maka keseluruhan POFOD dari tiga sistem-channel (dengan semua saluran independen) adalah satu juta kali lebih besar dari keandalan sistem single-channel. Namun dalam prakteknya, mencapai saluran independensi total adalah mustahil. Ini telah terbukti secara eksperimental bahwa tim desain independen sering membuat kesalahan yang sama atau salah paham pada bagian yang sama dari spesifikasi (Brilliant, et., 1990 Knight dan Leveson, 1986; Leveson, 1995). Ada beberapa alasan untuk ini:
1. Anggota tim yang berbeda dari latar belakang budaya dan mungkin telah
dididik melalui pendekatan dan buku teks. Berarti bahwa mereka mungkin menemukan hal yang sama sulit untuk berkomunikasi dengan para ahli domain. Hal ini sangat mungkin bahwa mereka akan, secara independen,membuat kesalahan yang sama dan desain algoritma yang sama untuk memecahkan masalah.
2. Jika ketentuan tidak benar atau mereka didasarkan pada kesalahpahaman
tentang lingkungan sistem, maka kesalahan-kesalahan ini akan tergambar dalam setiap penerapan sistem.
3. Dalam suatu sistem kritis, V-spec adalah sebuah dokumen rinci berdasarkan
12
Salah satu cara untuk mengurangi kemungkinan terjadinya spesifikasi kesalahan umum adalah dengan mengembangkan persyaratan secara lengkap untuk sistem yang mandiri, dan untuk menentukan spesifikasi dalam berbagai bahasa Dalam sebuah analisis dari percobaan, Hatton (1997), menyimpulkan bahwa tiga sistem-channel adalah suatu tempat antara 5-9 kali yang lebih dapat diandalkan daripada sistem single-channel. Dia menyimpulkan bahwa peningkatan kehandalan yang dapat diperoleh dengan mencurahkan lebih banyak sumber daya ke versi tunggal tidak bisa cocok dengan pendekatan N-versi ini dan kemungkinan besar akan menyebabkan sistem yang lebih handal daripada pendekatan versi tunggal. Hanya dalam sistem kritis keamanan dan misi, dimana biaya kegagalan sangat tinggi, bahwa perangkat lunak multiversion mungkin dibutuhkan. Bahkan dalam situasi seperti (misalnya, sistem pesawat ruang angkasa), mungkin cukup untuk memberikan backup yang sederhana dengan keterbatasan fungsi sampai sistem utama dapat diperbaiki dan restart.
13.4 Dependable programming
Daftar pedoman praktek yang baik ditunjukkan pada gambar 13.8. Mereka dapat diterapkan dalam pemrograman apapun bahasa yang digunakan untuk pengembangan sistem, meskipun cara mereka digunakan tergantung pada bahasa tertentu dan notasi yang digunakan untuk pembangunan sistem.
Pedoman 1: kontrol visibilitas informasi dalam sebuah program
Suatu prinsip keamanan yang diadopsi oleh organisasi militer yaitu prinsip 'perlu diketahui' .hanya orang-orang yang perlu mengetahui bagian tertentu dari informasi untuk menjalankan tugasnya, yang diberikan informasi tersebut. Informasi yang tidak relevan dengan pekerjaan mereka akan ditahan. Pedoman pemrograman yang handal
1. Batasi visibilitas informasi dalam sebuah program
2. Periksa semua masukan untuk validitas
3. Sediakan penanganan untuk semua pengecualian
4. Minimalkan penggunaan konstruksi kecenderungan-kesalahan
5. Memberikan kemampuan me-restart
6. Periksa batasan array
7. Sertakan waktu-habis saat memanggil komponen eksternal
8. Berikan nama semua konstanta yang mewakili nilai-nilai asli
13
komponen program yang tidak seharusnya menggunakannya. Jika antarmuka tetap sama, representasi data dapat diubah tanpa mempengaruhi komponen yang lain dalam sistem.
Sebuah tipe data abstrak adalah tipe data dimana struktur internal dan representasi dari variabel jenis yang tersembunyi. Struktur dan atribut jenis tidak terlihat secara eksternal dan semua akses ke data tersebut melalui pengoperasian. Misalnya, anda mungkin memiliki tipe data abstrak yang mewakili antrian untuk permintaan layanan.
Anda juga dapat menggunakan tipe data abstrak untuk melakukan pemeriksaan bahwa nilai yang diberikan ada di dalam jangkauan. Misalnya, anda ingin mewakili suhu pada proses kimia, di mana suhu diperbolehkan berada dalam rentang 20-200 derajat celcius. Dengan menyertakan pengecekan pada nilai yang ditetapkan dalam tipe data operasi abstrak, anda dapat memastikan bahwa nilai suhu tidak pernah di luar jangkauan yang diperlukan. Dalam beberapa bahasa berorientasi objek, anda dapat menerapkan tipe data abstrak menggunakan definisi antarmuka, di mana anda menyatakan antarmuka untuk suatu objek tanpa referensi untuk implementasinya. Misalnya, anda dapat menentukan antrian antarmuka, yang mendukung metode untuk menempatkan objek ke antrian, menghapusnya dari antrian, dan query ukuran antrian. Dalam kelas objek yang mengimplementasikan antarmuka ini, atribut dan metode harus swasta untuk kelas tersebut.
Pedoman 2: periksa semua masukan untuk validitas
Semua program mengambil masukan dari lingkungan dan diproses. Spesifikasi membuat asumsi tentang inputan yang mencerminkan penggunaan pada dunia nyata. Contoh, dapat diasumsikan bahwa nomor rekening bank selalu 8 digit bilangan bulat positif. Secara tak disengaja, pengguna akan membuat kesalahan dan kadang-kadang akan memasukkan data yang salah. Serangan berbahaya pada sistem dengan mengandalkan sengaja memasukkan input yang salah. Bahkan ketika input berasal dari sensor atau sistem lain, sistem ini dapat salah dan memberikan nilai-nilai yang tidak tepat. Karena itu anda harus selalu memeriksa validitas input secepat hal ini dibaca dari lingkungan pengoperasian program. Pemeriksaan yang terlibat jelas tergantung
Pada inputnya sendiri tapi kemungkinan pengecekan yang dapat digunakan adalah sebagai berikut:
1. Pengecekan jarak. Anda dapat mengharapkan masukan berada dalam
14
harus berada dalam kisaran 0,0-1,0; masukan yang mewakili suhu air cair harus antara 0 derajat celcius dan 100 derajat celcius, dan sebagainya.
2. Pengecekan ukuran. Anda dapat memperkirakan masukan menjadi
sejumlah karakter tertentu (misalnya, delapan karakter untuk mewakili rekening bank). Dalam kasus lain, ukuran mungkin tidak tetap tetapi mungkin ada batas atas yang realistis. Sebagai contoh, tidak mungkin bahwa nama orang akan memiliki lebih dari 40 karakter.
3. Pengecekan representasi. Anda mungkin mengharapkan masukan untuk
jenis tertentu, yang diwakili dengan cara yang standar. Misalnya, nama orang tidak termasuk karakter numerik, alamat e-mail terdiri dari dua bagian, dipisahkan oleh tanda @, dan lain-lain.
4. Pengecekan kewajaran. Dimana sebuah input adalah salah satu dari
rangkaian dan anda mengetahui hubungannya antara isi dari rangkaian, maka anda dapat memeriksa bahwa nilai input wajar. Misalnya, jika nilai input merupakan pembacaan meteran listrik rumah tangga, maka anda akan mengharapkan jumlah listrik yang digunakan untuk menjadi kurang lebih sama seperti di yang periode tahun sebelumnya. Tentu saja, akan ada variasi, tapi besarnya perbedaan menunjukkan bahwa masalah telah timbul.
Tindakan yang anda ambil jika pemeriksaan validasi input gagal tergantung pada jenis sistem sedang dijalankan. Dalam beberapa kasus, anda melaporkan masalah kepada pengguna dan meminta agar nilai diinput kembali. Dimana nilai berasal dari sebuah sensor, anda mungkin menggunakan nilai valid terbaru. Dalam embedded system real-time, anda mungkin harus memperkirakan nilai berdasarkan riwayat, sehingga sistem dapat terus beroperasi.
Pedoman 3: menyediakan penanganan untuk semua pengecualian
Selama pelaksanaan program, kesalahan atau kejadian tak terduga pasti terjadi. Hal ini mungkin muncul karena kesalahan program atau mungkin akibat dari keadaan eksternal tak terduga. Sebuah kesalahan atau kejadian tak terduga yang terjadi selama pelaksanaan program disebut 'pengecualian'. Contoh pengecualian mungkin kegagalan system catu daya, mengakses data yang tidak ada, atau terlalu banyak nilai numerik atau terlalu sedikit.
15
menghentikan eksekusi. Oleh karena itu, untuk memastikan bahwa program pengecualian tidak menyebabkan kegagalan sistem, anda harus mendefinisikan penanganan pengecualian untuk semua pengecualian yang mungkin muncul, dan pastikan bahwa semua pengecualian terdeteksi dan ditangani secara tegas.
Dalam bahasa pemrograman seperti c, pernyataan ‘if’ harus digunakan untuk mendeteksi pengecualian dan untuk mentransfer ke kontrol kode penanganan pengecualian. Ini berarti bahwa anda harus secara jelas memeriksa pengecualian di mana pun dalam program mereka dapat terjadi. Namun, pendekatan ini menambah kompleksitas signifikan terhadap tugas penanganan pengecualian, meningkatkan kemungkinan bahwa anda akan membuat kesalahan dan mungkin menyalahgunakan pengecualian.
Beberapa bahasa pemrograman, seperti java, c ++, dan ada, termasuk konstruksi yang mendukung penanganan pengecualian sehingga anda tidak memerlukan pernyataan tambahan kondisi untuk memeriksa pengecualian. Bahasa pemrograman ini termasuk built-in tipe khusus (sering disebut pengecualian) dan pengecualian yang berbeda dapat dinyatakan sebagai jenis ini. Ketika situasi yang luar biasa terjadi, pengecualian ditandai dan bahasa runtime mengirimkan sistem kontrol ke penanganan pengecualian. Ini adalah bagian kode yang menyatakan nama pengecualian dan tindakan yang tepat untuk menangani setiap pengecualian (gambar 13.9). Perhatikan bahwa penangan pengecualian berada di luar aliran kontrol normal dan bahwa aliran kontrol normal ini tidak melanjutkan setelah pengecualian ditangani. Penanganan pengecualian biasanya melakukan satu atau lebih dari tiga hal:
1. Sinyal untuk komponen tingkat tinggi adalah pengecualian telah terjadi, dan
memberikan informasi kepada komponen tentang jenis pengecualian. Anda menggunakan pendekatan ini ketika salah satu komponen memanggil komponen lain dan komponen yang dipanggil perlu tahu apakah komponen yang dipanggil telah dilaksanakan dengan sukses. Jika tidak, itu terserah kepada komponen yang memanggil agar mengambil tindakan untuk memulihkan masalah.
2. Melaksanakan beberapa pengolahan alternatif yang yang awalnya ditujukan.
Oleh karena itu, penanganan pengecualian mengambil beberapa tindakan untuk memulihkan masalah. Pemrosesan kemudian dapat berjalan seperti biasa atau penanganan pengecualian mungkin menunjukkan bahwa pengecualian telah terjadi sehingga komponen pemanggil menyadari masalah.
3. Pengendalian bebas ke sistem pendukung run-time yang menangani
16
menggunakan pendekatan ini ketika memungkin untuk memindahkan sistem ke bagian yang aman dan tidak bergerak, sebelum menyerahkan kontrol kepada sistem run-time.
Penanganan pengecualian dalam program memungkinkan untuk mendeteksi dan memulihkan dari beberapa kesalahan input dan kejadian eksternal yang tak terduga. Dengan demikian, ia menyediakan tingkat dari toleransi kesalahan. Program mendeteksi kesalahan dan dapat mengambil tindakan untuk pulih dari keadaan tersebut. Karena kebanyakan kesalahan input dan kejadian eksternal tak terduga biasanya sementara, sangat mungkin untuk melanjutkan pengoperasian normal setelah pengecualian diproses.
Pedoman 4: Meminimalkan kecenderungan kesalahan pembangunan.
Kesalahan dalam program dan kebanyakan kesalahan pada sebuah program biasanya disebabkan oleh kesalahan manusia atau biasa disebut dengan human error. Beberapa konstruksi bahasa pemrograman dan teknik pemrograman secara inheren rawan kesalahan sehingga harus dihindari atau, paling tidak, digunakan sesedikit mungkin.
Yang termasuk berpotensi rawan kesalahan dalam pembangunan meliputi :
1. Unconditional branch (go-to) statements.
Bahaya go-to statements yang diakui sejak tahun 1968 (Dijkstra, 1968) dan, sebagai konsekuensinya, ini telah dikeluarkan dari bahasa pemrograman modern. Namun, mereka masih diperbolehkan dalam bahasa seperti C. Penggunaan go-to statements mengarah ke 'spaghetti code' yang kusut dan sulit untuk dipahami.
2. Floating-point number.
Representasi floating-point dalam fixed- length memory adalah tidaklah
tepat akurat. Misalnya, 3.00000000 kadang-kadang dapat
direpresentasikan sebagai 2.99999999 dan kadang-kadang sebagai 3,00000001. Sebuah perbandingan akan menunjukkan bahwa ini tidaklah setara.
3. Pointers programming languages seperti C dan C ++, mendukung low-level
17
jika mereka diset secara tidak benar dan karena menunjuk ke daerah yang salah dari sebuah memori. Mereka juga melakukan pengecekan batas array dan struktur lainnya yang lebih sulit untuk diterapkan.
4. Dynamic memory allocation
Memori program dapat dialokasikan pada saat run-time tetapi bukan pada saat kompilasi. Bahayanya adalah bahwa memori mungkin tidak teralokasi dengan benar, sehingga akhirnya sistem kehabisan memori yang tersedia. Ini bisa menjadi kesalahan yang sangat sulit dideteksi karena sistem dapat berjalan dengan lancar untuk waktu yang lama sebelum masalah terjadi.
5. Parallelism
Ketika terjadi proses eksekusi secara bersamaan, ada kemungkinan bisa terjadi timing dependencies diantara satu proses dengan proses yang lainnya. Timing problem biasanya tidak dapat dideteksi dengan inspeksi
program. Paralelisme mungkin akan dapat dihindari, namun
penggunaannya harus dikontrol secara hati-hati untuk meminimalkan interprocess dependensi.
6. Recursion
Ketika prosedur atau metode memanggil dirinya sendiri atau memanggil prosedur lain, yang kemudian memanggil prosedur panggilan aslinya, maka ini adalah 'rekursion'.Penggunaan rekursi dapat menghasilkan program yang lebih ringkas, namun bisa menyulitkan untuk mengikuti logika program rekursif, karena itu kesalahan programming bias lebih sulit untuk dideteksi. Kesalahan Recursion dapat mengakibatkan alokasi semua sistem memori sebagai temporary stack variable.
7. Interupts
Ini adalah cara forcing control untuk mentransfer ke bagian kode tanpa memperhatikan kode yang sedang dijalankan. Bahaya ini adalah jelas, interrupt dapat menyebabkan terjadinya sebuah operasi penting harus berhenti begitu saja.
8. Inheritance
18
Selain itu, inheritance, bila dikombinasikan dengan dynamic binding, dapat menyebabkan timing problem pada saat run-time.
9. Aliasing
Hal ini terjadi ketika lebih dari satu nama yang digunakan untuk merujuk pada entitas yang sama dalam sebuah program. Misalnya, jika dua pointer dengan nama yang berbeda menunjuk ke lokasi memori yang sama. Sangat mudah bagi pembaca program untuk miss statements yang mengubah entitas ketika mereka memiliki beberapa nama untuk dipertimbangkan.
10.Unbounded Arrays
dalam bahasa seperti C, array hanya cara untuk mengakses memori dan Anda dapat membuat penugasan sampai pada akhir array. Sistem runtime tidak memeriksa bahwa tugas sebenarnya merujuk kepada elemen dalam array. Buffer overflow, di mana seorang penyerang sengaja membangun sebuah program untuk menulis memori luar akhir buffer yang diimplementasikan sebagai array, merupakan kerentanan keamanan yang diketahui.
11.Default input processing
beberapa sistem menyediakan standar untuk pengolahan input, terlepas dari masukan yang disampaikan kepada sistem. Ini adalah celah keamanan dimana penyerang dapat mengeksploitasi dengan menghadirkan program dengan input tak terduga yang tidak bisa ditolak oleh sistem.
beberapa standar untuk pengembangan sistem safety-critical benar-benar melarang penggunaan konstruksi tersebut. Semua konstruksi dan teknik sebenarnya berguna, namun mereka harus digunakan dengan tetap berhati-hati. Jika memungkinkan, efek berpotensi berbahaya dapat dikontrol dengan menggunakan mereka dalam tipe data abstrak atau benda. Ini bertindak sebagai natural 'firewall' membatasi kerusakan yang disebabkan jika terjadi kesalahan.
Pedoman 5 : Memberikan kemampuan me-restart
19
Interaksi pengguna dengan sistem e-commerce biasanya berlangsung beberapa menit dan melibatkan minimal processing. Database untuk transaksinya adalah pendek, dan biasanya diselesaikan dalam waktu kurang dari satu detik. Namun, jenis lain dari sistem seperti sistem CAD dan system word processing melibatkan long transactions. Dalam sistem long transactions, waktu antara starting word sistem dan finishing work mungkin membutuhkan beberapa menit lebih atau jam. Jika sistem gagal selama long transaction, maka semua pekerjaan bisa hilang. Demikian pula, dalam sistem komputasi intensif seperti beberapa sistem e-science, menit atau jam dari processing mungkin diperlukan untuk menyelesaikan perhitungan. Semua hal ini bisa hilang pada saat terjadi kegagalan sistem.
Dalam semua jenis sistem, Anda harus menyediakan kemampuan me-restart yang didasarkan pada menjaga salinan data yang dikumpulkan atau dihasilkan selama pemrosesan. Fasilitas restart harus memungkinkan sistem untuk me-restart menggunakan salinan ini, daripada harus memulai semua dari awal. Salinan ini kadang-kadang disebut check-points. Sebagai contohnya :
1. dalam sistem e-commerce, Anda dapat menyimpan salinan formulir yang
telah diisi oleh user dan memungkinkan mereka untuk mengakses dan mengirimkan formulir tersebut tanpa harus mengisi mereka lagi.
2. Dalam sebuah long transaction atau komputasi intensive system, Anda
dapat secara otomatis menyimpan data setiap beberapa menit dan, ketika terjadi kegagalan sistem, maka kita bisa merestart dengan data yang terakhir disimpan. Anda juga harus memungkinkan terjadinya user error dan menyediakan cara bagi pengguna untuk kembali ke checkpoint terbaru dan memulai lagi dari sana.
Jika sebuah exception terjadi dan tidak memungkinkan untuk melanjutkan operasi yang normal, Anda dapat menangani exception dengan menggunakan backward error recovery. Ini berarti bahwa Anda me-reset keadaan sistem ke keadaan yang disimpan pada checkpoint dan merestart operasi dari titik itu.
Pedoman 6: Periksa batas array
20
Beberapa bahasa pemrograman, seperti Java, selalu melakukan pemeriksaan ketika ada nilai yang masuk ke dalam array, indeks berada dalam array. Jadi, jika sebuah array A diindeks dari 0 sampai 10.000, upaya untuk memasukkan nilai-nilai ke dalam elemen-elemen A [-5] atau A [12345] akan menyebabkan exception yang semakin besar. Namun, bahasa pemrograman seperti C dan C ++ tidak secara otomatis mencakup array-bound check dan hanya menghitung offset dari awal array. Oleh karena itu, A [12345] akan mengakses kata yang 12345 lokasi dari awal array, terlepas dari apakah iya atau tidak ini adalah termasuk bagian dari array.
Alasan mengapa bahasa ini tidak mencakup array-bound check adalah bahwa ini menimbulkan overhead setiap kali array diakses. Mayoritas akses array adalah benar sehingga sebagian besar bound-check tidak perlu meningkatkan waktu eksekusi program. Namun, kurangnya sebuah bound-check menyebabkan kerentanan terhadap security, seperti buffer overflow, yang saya bahas dalam Bab 14 lebih detail, memperkenalkan kerentanan ke dalam sistem yang dapat mengakibatkan sistem failure. Jika Anda menggunakan bahasa yang tidak termasuk array-bound check, Anda harus selalu menyertakan kode tambahan yang menjamin indeks array dalam batasannya.
Pedoman 7: Sertakan timeout saat memanggil komponen eksternal
