REKAYASA PERANGKAT LUNAK Chapter 13 DEP

REKAYASA PERANGKAT LUNAK
Chapter 13 - DEPENDABILITY ENGINEERING

Anggota Kelompok :
1.
2.
3.
4.
5.
6.

Hairil Fiqri Sulaiman
M. Uwais Al- Qarni
Lucky Sholihin
Zolandia Ramanda
Edi Sucipto
Austin Arta Tunggal Pratama

1211500689
1211500846
1211500333

1211502750
1211504327
1211503691

Jurusan Ilmu Komputer Dan Elektronika
Fakultas Matematika Dan Ilmu Pengetahuan Alam
Universitas Gadjah Mada
Yogyakarta
i

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 runtime 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

techniques semakin berkurang. Biaya menemukan dan menghapus kesalahan
yang ada dalam sistem perangkat lunak meningkat secara eksponensial meningkat
(Gambar 13.1).

1

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 perusahaanperusahaan 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.
redundancy dan diversity digunakan untuk meningkatkan kehandalan
dalam kehidupan sehari-hari. Sebagai contoh redundansi, untuk mengamankan
rumah, kita menggunakan lebih dari satu kunci (redundancy) dan biasanya kunci
2

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.

Proses kehandalan ini banyak digunakan untuk meyakinkan regulasi yang
paling efektif dalam rekayasa perangkat lunak, yang diterapkan dalam
mengembangkan suatu perangkat lunak. Para pengembang sistem biasanya akan
3

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

didokumentasikan secara eksplisit.
4

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 benarbenar 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.
Contoh system yang perlu arsitektur dalam toleransi kesalahan adalah
system penerbangan yang harus selalu beroperasi, system telekomunikasi.

5

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
Pada gambar diatas menggambarkan hubungan Sistem proteksi dengan
control system. System proteksi memonitor proses control. Jika terjadi masalah
maka actuator akan menutup proses atau memanggil system proteksi. Datas
ditunjukkan terdapat 2 sensor. Sesnsor pertama sebagai sensor proteksi dan
6

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.
Arsitektur ini dapat digunakan untuk system yang membutuhkan komputasi
yang sangat tepat, namun apabila ketersediaan tidak penting. Jika output dari tiap
channel berbeda maka system dimatikan. Seperti pada system medis kehandalan
lebih penting dari ketersediannya, sebab jika mendapat respon system yang tidak
tepat maka pasien akan mendapatkan oerawatan yang salah. Namun jika dalam

7

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
disuplai oleh produsen yang berbeda.

8

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).
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.

Figure 13.6 Triple modular
redundancy

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.
9

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.

Figure 13.7 N-version
programming

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.
10

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
system persyaratan, yang memberikan rincian lengkap untuk tim tentang
bagaimana sistem harus bertindak. Tidak mungkin ada ruang lingkup untuk
penafsiran oleh para pengembang perangkat lunak. Jika ada kesalahan
dalam dokumen ini, maka ini akan disampaikan kepada semua anggota tim
dan dilaksanakan di semua versi sistem.

11

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.
2.
3.
4.
5.
6.
7.
8.

Batasi visibilitas informasi dalam sebuah program
Periksa semua masukan untuk validitas
Sediakan penanganan untuk semua pengecualian
Minimalkan penggunaan konstruksi kecenderungan-kesalahan
Memberikan kemampuan me-restart
Periksa batasan array
Sertakan waktu-habis saat memanggil komponen eksternal
Berikan nama semua konstanta yang mewakili nilai-nilai asli

Ketika memprogram, anda harus mengadopsi prinsip analog untuk
mengontrol akses ke variabel dan struktur data yang anda gunakan. Komponen
program seharusnya hanya memungkinkan akses ke data yang mereka butuhkan
untuk pelaksanaannya. Data program lain harus dapat diakses, dan tersembunyi
dari mereka. Jika anda menyembunyikan informasi, itu tidak bisa rusak oleh
12

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
kisaran tertentu. Sebagai contoh, masukan yang mewakili probabilitas
13

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.
Pengecualian dapat disebabkan oleh kondisi perangkat keras atau
perangkat lunak. Hal ini dapat dilakukan dalam program itu sendiri atau mungkin
melibatkan transfer kontrol ke mekanisme sistem penanganan pengecualian.
Biasanya, mekanisme manajemen pengecualian sistem melaporkan kesalahan dan
14

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
pengecualian. Hal ini standar ketika terjadi kesalahan dalam program
(misalnya, ketika nilai numerik melampaui batas). Tindakan yang biasa dari
sistem run-time adalah untuk menghentikan proses. Anda hanya harus
15

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
constructs yang disebut dengan pointer, menyimpan alamat yang merujuk
langsung ke daerah-daerah memori mesin (mereka menunjuk ke lokasi
memori).). Kesalahan dalam penggunaan pointer dapat membahayakan
16

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
Masalah Inheritance pada object-oriented programming adalah bahwa kode
yang terkait dengan objek tidak semua ada dalam satu tempat. Hal ini
membuat lebih sulit untuk memahami perilaku objek. Oleh karena itu, lebih
mungkin bahwa programming error akan terlewatkan.
17

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
Banyak sistem informasi organisasi didasarkan sekitar transaksi pendek di mana
pengolahan input pengguna membutuhkan waktu yang relatif singkat. Sistem ini
dirancang sedemikian rupa sehingga perubahan ke database sistem hanya
diselesaikan setelah semua proses lain telah berhasil diselesaikan. Jika ada yang
salah selama proses maka tidak ada pembaruan (update) pada database, sehingga
tidak menjadi inconsistent.

18

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
Semua bahasa pemrograman memungkinkan spesifikasi struktur data
array-sequential untuk mengakses menggunakan numeric index. Array ini
biasanya diletakkan di daerah yang berbatasan dalam memori kerja dari sebuah
program. Array ditentukan untuk menjadi ukuran tertentu, yang mencerminkan
bagaimana mereka digunakan. Misalnya, jika Anda ingin merepresentasikan usia
hingga 10.000 orang, maka Anda mungkin mendeklarasikan array dengan 10.000
lokasi untuk menyimpan data usia.

19

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 nilainilai 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
Dalam distributed systems, komponen dari sistem dijalankan pada
komputer yang berbeda dan panggilan dibuat di seluruh jaringan dari komponen
ke komponen. Untuk menerima beberapa layanan, komponen A dapat memanggil
komponen B. A menunggu B untuk merespon sebelum melanjutkan eksekusi.
Namun, jika komponen B gagal merespon (untuk beberapa alasan), maka
komponen A tidak bisa melanjutkannya. Seseorang yang menunggu respons dari
sistem melihat sebuah silent system failure, dengan tidak mendapatkan respon
dari sistem. Mereka tidak memiliki pilihan lain selain mengakhiri proses tunggu dan
me-restart sistem. Untuk menghindari hal ini, Anda harus selalu menyertakan
timeout saat memanggil komponen-komponen eksternal. Batas waktu A adalah
automatic-assumption dimana komponen telah gagal dan tidak akan menghasilkan
respon. Jika Anda belum menerima tanggapan dalam waktu yang telah Anda
tentukan, Anda menganggap ini sebagai kegagalan dan mengambil kembali
kendali dari apa yang disebut komponen. Anda kemudian dapat mencoba untuk
memulihkan kegagalan atau memberitahu pengguna sistem apa yang telah terjadi
dan memungkinkan mereka untuk memutuskan apa yang harus dilakukan.

20