Software Engineering 9th Edition by Ian Sommerville (301 600)

Machine Translated by Google
284 Bab 10 Sistem Sosioteknik
Kegagalan Aktif
(Kesalahan manusia)
Gambar 10.9
Model keju Swiss alasan
kegagalan sistem Hambatan

Kegagalan sistem
Dalam model ini, pertahanan yang dibangun ke dalam sistem dibandingkan dengan
irisan keju Swiss. Beberapa jenis keju Swiss, seperti Emmental, memiliki lubang sehingga
anal oginya adalah bahwa kondisi latennya sebanding dengan lubang pada irisan keju.
Posisi lubang-lubang ini tidak statis tetapi berubah-ubah tergantung pada keadaan sistem
sosioteknik keseluruhan. Jika setiap irisan mewakili penghalang, kegagalan dapat terjadi
ketika lubang berbaris pada saat yang sama sebagai kesalahan operasional manusia.
Kegagalan aktif dari operasi sistem melewati lubang dan menyebabkan kegagalan sistem secara keseluruhan.
Biasanya, tentu saja, lubangnya tidak boleh disejajarkan sehingga kegagalan
operasional terperangkap oleh sistem. Untuk mengurangi kemungkinan kegagalan sistem
akibat kesalahan manusia, perancang harus:
1. Rancang sebuah sistem sehingga berbagai jenis penghalang disertakan. Ini berarti
bahwa 'lubang' mungkin akan berada di tempat yang berbeda sehingga kecil
kemungkinan lubang berbaris dan gagal menjebak kesalahan.
2. Meminimalkan jumlah kondisi laten dalam suatu sistem. Secara efektif, ini berarti
mengurangi jumlah dan ukuran 'lubang' sistem.
Tentu saja, desain sistem secara keseluruhan juga harus berusaha menghindari
kegagalan aktif yang dapat memicu kegagalan sistem. Ini mungkin melibatkan
perancangan proses operasional dan sistem untuk memastikan bahwa operator tidak
terlalu banyak bekerja, terganggu, atau disajikan dengan jumlah informasi yang berlebihan.
10.5.2 Evolusi sistem

Sistem yang besar dan kompleks memiliki masa pakai yang sangat lama. Selama hidup
mereka, mereka diubah untuk memperbaiki kesalahan dalam persyaratan sistem asli dan
untuk menerapkan persyaratan baru yang telah muncul. Komputer sistem kemungkinan
besar akan diganti dengan mesin baru yang lebih cepat. Organisasi yang menggunakan
sistem dapat mengatur ulang dirinya sendiri dan karenanya menggunakan sistem dengan
cara yang berbeda. Lingkungan eksternal sistem dapat berubah, memaksa perubahan
pada sistem. Oleh karena itu evolusi, di mana sistem berubah untuk mengakomodasi
perubahan lingkungan, adalah proses yang berjalan bersama proses operasional sistem
normal. Evolusi sistem melibatkan memasuki kembali proses pengembangan untuk
membuat perubahan dan perluasan ke perangkat keras sistem, perangkat lunak, dan proses operasional.
10.5 Operasi sistem 285
Sistem warisan
Sistem warisan adalah sistem berbasis komputer sosioteknik yang telah dikembangkan di masa lalu, sering menggunakan
teknologi yang lebih tua atau usang. Sistem ini tidak hanya mencakup perangkat keras dan perangkat lunak tetapi juga proses warisan
dan prosedur—cara lama dalam melakukan hal-hal yang sulit diubah karena bergantung pada perangkat lunak lama.
Perubahan pada satu bagian dari sistem pasti melibatkan perubahan pada komponen lainnya. Sistem lama sering
sistem bisnis-kritis. Mereka dipertahankan karena terlalu berisiko untuk menggantinya.
http://www.SoftwareEngineering-9.com/LegacySys/
Evolusi sistem, seperti evolusi perangkat lunak (dibahas dalam Bab 9), secara inheren
mahal karena beberapa alasan:
1. Perubahan yang diusulkan harus dianalisis dengan sangat hati-hati dari perspektif bisnis dan teknis.
Perubahan harus berkontribusi pada tujuan sistem dan
seharusnya tidak hanya termotivasi secara teknis.
2. Karena subsistem tidak pernah sepenuhnya independen, perubahan pada satu subsistem dapat
berdampak buruk pada kinerja atau perilaku subsistem lainnya.
Oleh karena itu, perubahan konsekuen pada subsistem ini mungkin diperlukan.
3. Alasan keputusan desain asli sering kali tidak dicatat. Mereka yang bertanggung jawab atas evolusi
sistem harus mencari tahu mengapa keputusan desain tertentu
telah dibuat.
4. Seiring bertambahnya usia sistem, strukturnya biasanya menjadi rusak oleh perubahan sehingga
biaya untuk membuat perubahan lebih lanjut meningkat.
Sistem yang telah berevolusi dari waktu ke waktu seringkali bergantung pada perangkat keras dan
teknologi perangkat lunak yang sudah usang. Jika mereka memiliki peran penting dalam suatu organisasi, mereka dikenal sebagai
'sistem warisan'. Ini biasanya merupakan sistem yang diinginkan oleh organisasi
ganti tetapi jangan lakukan karena risiko atau biaya penggantian tidak dapat dibenarkan.
Dari perspektif ketergantungan dan keamanan, perubahan pada sistem sering kali
sumber masalah dan kerentanan. Jika orang yang mengimplementasikan perubahan berbeda dari
mereka yang mengembangkan sistem, mereka mungkin tidak menyadari bahwa keputusan desain
dibuat untuk alasan keandalan dan keamanan. Oleh karena itu, mereka dapat mengubah
sistem dan kehilangan beberapa perlindungan yang sengaja diterapkan ketika sistem
dibangun. Selain itu, karena pengujian sangat mahal, pengujian ulang lengkap mungkin tidak mungkin
dilakukan setelah setiap perubahan sistem. Efek samping yang merugikan dari perubahan yang memperkenalkan atau
mengekspos kesalahan dalam komponen sistem lain mungkin tidak ditemukan.
POIN KUNCI
Sistem sosioteknik mencakup perangkat keras komputer, perangkat lunak, dan manusia, dan terletak di dalam suatu organisasi.
Mereka dirancang untuk mendukung tujuan dan sasaran organisasi atau bisnis.
Faktor manusia dan organisasi seperti struktur organisasi dan politik memiliki
efek signifikan pada pengoperasian sistem sosioteknik.
Sifat -sifat yang muncul dari suatu sistem adalah karakteristik dari sistem secara keseluruhan daripada bagian-bagian
komponennya. Mereka termasuk properti seperti kinerja, keandalan, kegunaan, keselamatan, dan keamanan. Keberhasilan
atau kegagalan suatu sistem seringkali bergantung pada sifat-sifat yang muncul ini.
Proses rekayasa sistem yang mendasar adalah pengadaan sistem, pengembangan sistem, dan operasi sistem.
Pengadaan sistem mencakup semua aktivitas yang terlibat dalam memutuskan sistem apa yang akan dibeli dan siapa yang
harus memasok sistem itu. Persyaratan tingkat tinggi dikembangkan sebagai bagian dari proses pengadaan.
Pengembangan sistem meliputi spesifikasi kebutuhan, desain, konstruksi, integrasi, dan pengujian. Integrasi sistem, di mana
subsistem dari lebih dari satu pemasok harus dibuat untuk bekerja sama, sangat penting.
Ketika sebuah sistem mulai digunakan, proses operasional dan sistem itu sendiri harus berubah untuk mencerminkan
perubahan kebutuhan bisnis.
Kesalahan manusia tidak dapat dihindari dan sistem harus menyertakan penghalang untuk mendeteksi kesalahan ini sebelum
menyebabkan kegagalan sistem. Model keju Swiss Reason menjelaskan bagaimana kesalahan manusia ditambah cacat
laten pada penghalang dapat menyebabkan kegagalan sistem.
BACAAN LEBIH LANJUT
'Bandara 95: Sistem bagasi otomatis'. Sebuah studi kasus yang sangat baik dan dapat dibaca tentang apa yang
bisa salah dengan proyek rekayasa sistem dan bagaimana perangkat lunak cenderung disalahkan atas kegagalan
sistem yang lebih luas. (Catatan Rekayasa Perangkat Lunak ACM, 21 Maret 1996.) http://doi.acm.org/
10.1145/227531.227544.
'Rekayasa sistem perangkat lunak: Sebuah tutorial'. Tinjauan umum yang baik tentang rekayasa sistem,
meskipun Thayer berfokus secara eksklusif pada sistem berbasis komputer dan tidak membahas masalah
sosioteknik. (RH Thayer. IEEE Computer, April 2002.) http://dx.doi.org/10.1109/MC.2002.993773.
Kepercayaan pada Teknologi: Perspektif Sosio-teknis. Buku ini adalah satu set makalah yang semuanya
berkaitan, dalam beberapa hal, dengan ketergantungan sistem sosioteknik. (K. Clarke, G. Hardstone, M.
Rouncefield dan I. Sommerville (eds.), Springer, 2006.)
'Dasar-Dasar Rekayasa Sistem'. Ini adalah bab pengantar dalam buku pegangan rekayasa sistem NASA. Ini
menyajikan ikhtisar proses rekayasa sistem untuk ruang angkasa
Bab 10 Latihan 287
sistem. Meskipun ini sebagian besar merupakan sistem teknis, ada masalah sosioteknis yang harus
dipertimbangkan. Keandalan jelas sangat penting. (Dalam Buku Pegangan Teknik Sistem NASA, NASA-
SP2007-6105, 2007.) http://education.ksc.nasa.gov/esmdspacegrant/ Documents/
NASA%20SP-2007-6105%20Rev%201%20Final%2031Dec2007.pdf.
LATIHAN
10.1. Berikan dua contoh fungsi pemerintah yang didukung oleh sistem sosioteknik yang kompleks dan jelaskan
mengapa, di masa mendatang, fungsi-fungsi ini tidak dapat sepenuhnya diotomatisasi.
10.2. Jelaskan mengapa lingkungan di mana sistem berbasis komputer diinstal mungkin memiliki:
efek tak terduga pada sistem yang menyebabkan kegagalan sistem. Ilustrasikan jawaban Anda dengan
contoh yang berbeda dari yang digunakan dalam bab ini.
10.3. Mengapa tidak mungkin untuk menyimpulkan sifat-sifat yang muncul dari sistem yang kompleks dari
sifat-sifat komponen sistem?
10.4. Mengapa terkadang sulit untuk memutuskan apakah telah terjadi kegagalan atau tidak dalam suatu
sistem sosioteknik? Ilustrasikan jawaban Anda dengan menggunakan contoh-contoh dari MHC-PMS yang
telah dibahas pada bab-bab sebelumnya.
10.5. Apa itu 'masalah jahat'? Jelaskan mengapa berkembangnya rekam medis nasional?
sistem harus dianggap sebagai 'masalah jahat'.
10.6. Sistem museum virtual multimedia yang menawarkan pengalaman virtual Yunani kuno akan dikembangkan
untuk konsorsium museum Eropa. Sistem harus memberikan fasilitas kepada pengguna untuk melihat model
3-D Yunani kuno melalui browser web standar dan juga harus mendukung pengalaman realitas virtual yang
mendalam. Kesulitan politik dan organisasi apa yang mungkin muncul ketika sistem dipasang di museum
yang membentuk konsorsium?
10.7. Mengapa integrasi sistem merupakan bagian yang sangat penting dari proses pengembangan sistem?
Sarankan tiga masalah sosioteknik yang dapat menyebabkan kesulitan dalam integrasi sistem
proses.
10.8. Jelaskan mengapa sistem warisan mungkin penting untuk operasi bisnis.
10.9. Apa argumen yang mendukung dan menentang mempertimbangkan rekayasa sistem sebagai profesi
tersendiri, seperti teknik elektro atau rekayasa perangkat lunak?
10.10. Anda adalah seorang insinyur yang terlibat dalam pengembangan sistem keuangan. Selama instalasi, Anda
menemukan bahwa sistem ini akan membuat sejumlah besar orang menjadi mubazir. Orang-orang di
lingkungan menolak Anda mengakses informasi penting untuk menyelesaikan instalasi sistem. Sejauh mana
Anda, sebagai seorang insinyur sistem, harus terlibat dalam situasi ini? Apakah tanggung jawab profesional
Anda untuk menyelesaikan instalasi seperti yang dikontrakkan?
Haruskah Anda mengabaikan pekerjaan itu sampai organisasi pengadaan menyelesaikan masalahnya?
REFERENSI
Ackroyd, S., Harper, R., Hughes, JA dan Shapiro, D. (1992). Teknologi Informasi dan Praktik Kerja Polisi. Milton
Keynes: Pers Universitas Terbuka.
Anderson, RJ, Hughes, JA dan Sharrock, WW (1989). Bekerja untuk Keuntungan: Organisasi Sosial
yang Dapat Dihitung dalam Perusahaan Wirausaha. Aldershot: Avebury.
Checkland, P. (1981). Berpikir Sistem, Praktek Sistem. Chichester: John Wiley & Sons.
Checkland, P. dan Scholes, J. (1990). Metodologi Sistem Lunak dalam Tindakan. Chichester: John Wiley & Sons.
Mumford, E. (1989). 'Partisipasi Pengguna dalam Lingkungan yang Berubah—Mengapa kita membutuhkannya'.
Dalam Partisipasi dalam Pengembangan Sistem. Ksatria, K. (ed.). London: Halaman Kogan.
Alasan, J. (2000). 'Kesalahan manusia: Model dan manajemen'. British Medical J., 320 768–70.
Rittel, H. dan Webber, M. (1973). 'Dilema dalam Teori Umum Perencanaan'. Ilmu Kebijakan, 4, 155–69.
Stevens, R., Brook, P., Jackson, K. dan Arnold, S. (1998). Rekayasa Sistem: Mengatasi Kompleksitas.
London: Prentice Hall.
Suchman, L. (1987). Rencana dan tindakan terletak: masalah komunikasi manusia-mesin.

New York: Cambridge University Press.
Swartz, AJ (1996). 'Bandara 95: Sistem Bagasi Otomatis?' Catatan Rekayasa Perangkat Lunak ACM, 21 (2), 79–83.
Thayer, RH (2002). 'Rekayasa Sistem Perangkat Lunak: Tutorial.' Komputer IEEE, 35 (4), 68–73.
Thomé, B. (1993). 'Rekayasa Sistem: Prinsip dan Praktik Rekayasa Sistem Berbasis Komputer'. Chichester: John
Wiley & Sons.
Putih, S., Alford, M., Holtzman, J., Kuehl, S., McCay, B., Oliver, D., Owens, D., Tully, C. dan Willey, A.
(1993). 'Sistem Rekayasa Sistem Berbasis Komputer'. Komputer IEEE, 26 (11), 54–65.
11
Keandalan dan keamanan
Tujuan
Tujuan dari bab ini adalah untuk memperkenalkan keandalan dan keamanan perangkat
lunak. Setelah Anda membaca bab ini, Anda akan:
mengerti mengapa ketergantungan dan keamanan biasanya lebih

penting daripada karakteristik fungsional sistem perangkat lunak;
memahami empat dimensi utama ketergantungan, yaitu ketersediaan, keandalan,

keselamatan, dan keamanan;
waspadai terminologi khusus yang digunakan saat membahas keamanan dan

ketergantungan;
memahami bahwa untuk mencapai perangkat lunak yang aman dan dapat diandalkan,
Anda perlu menghindari kesalahan selama pengembangan sistem, mendeteksi dan
menghapus kesalahan saat sistem digunakan, dan membatasi kerusakan yang
disebabkan oleh kegagalan operasional.
Isi
11.1 Sifat ketergantungan 11.2
Ketersediaan dan keandalan 11.3
Keselamatan 11.4 Keamanan
290 Bab 11 Keandalan dan keamanan
Karena sistem komputer telah tertanam dalam dalam bisnis dan kehidupan pribadi kita, masalah
yang diakibatkan oleh kegagalan sistem dan perangkat lunak semakin meningkat.
Kegagalan perangkat lunak server di perusahaan e-commerce dapat menyebabkan hilangnya
pendapatan yang besar, dan mungkin juga pelanggan untuk perusahaan itu. Kesalahan perangkat
lunak dalam sistem kontrol tertanam di dalam mobil dapat menyebabkan penarikan mahal model
tersebut untuk diperbaiki dan, dalam kasus terburuk, dapat menjadi faktor penyebab kecelakaan.
Infeksi PC perusahaan dengan malware memerlukan operasi pembersihan yang mahal untuk
menyelesaikan masalah dan dapat mengakibatkan hilangnya atau rusaknya informasi sensitif.
Karena sistem intensif perangkat lunak sangat penting bagi pemerintah, perusahaan, dan
individu, perangkat lunak yang banyak digunakan harus dapat dipercaya. Perangkat lunak harus
tersedia bila diperlukan dan harus beroperasi dengan benar dan tanpa efek samping yang tidak
diinginkan, seperti pengungkapan informasi yang tidak sah. Istilah 'kemampuan bergantung'
diusulkan oleh Laprie (1995) untuk mencakup atribut sistem terkait ketersediaan, keandalan,
keselamatan, dan keamanan. Seperti yang saya bahas di Bagian 11.1, properti ini terkait erat, jadi
memiliki satu istilah untuk mencakup semuanya masuk akal.
Keandalan sistem sekarang biasanya lebih penting daripada detailnya
fungsionalitas karena alasan berikut:
1. Kegagalan sistem mempengaruhi banyak orang. Banyak sistem menyertakan fungsionalitas

yang jarang digunakan. Jika fungsi ini ditinggalkan dari sistem, hanya sejumlah kecil
pengguna yang akan terpengaruh. Kegagalan sistem, yang mempengaruhi ketersediaan
sistem, berpotensi mempengaruhi semua pengguna sistem. Kegagalan dapat berarti bahwa
bisnis normal tidak mungkin.
2. Pengguna sering menolak sistem yang tidak dapat diandalkan, tidak aman, atau tidak aman. Jika pengguna
menemukan bahwa suatu sistem tidak dapat diandalkan atau tidak aman, mereka akan menolak untuk
menggunakannya. Selain itu, mereka juga dapat menolak untuk membeli atau menggunakan produk
lain dari perusahaan yang sama yang memproduksi sistem yang tidak dapat diandalkan, karena mereka
percaya bahwa produk ini juga cenderung tidak dapat diandalkan atau tidak aman.
3. Biaya kegagalan sistem mungkin sangat besar. Untuk beberapa aplikasi, seperti sistem kendali
reaktor atau sistem navigasi pesawat, biaya kegagalan sistem lebih besar daripada biaya
sistem kendali.
4. Sistem yang tidak dapat diandalkan dapat menyebabkan hilangnya informasi. Data sangat mahal
untuk dikumpulkan dan dipelihara; biasanya nilainya jauh lebih tinggi daripada sistem
komputer yang memprosesnya. Biaya untuk memulihkan data yang hilang atau rusak biasanya sangat tinggi.
Seperti yang saya bahas di Bab 10, perangkat lunak selalu menjadi bagian dari sistem yang
lebih luas. Ini dijalankan dalam lingkungan operasional yang mencakup perangkat keras tempat
perangkat lunak dijalankan, pengguna manusia perangkat lunak itu, dan proses organisasi atau
bisnis tempat perangkat lunak digunakan. Saat merancang sistem yang dapat diandalkan, Anda
harus mempertimbangkan:
1. Kegagalan perangkat keras Perangkat keras sistem mungkin gagal karena kesalahan dalam
desainnya, karena komponen gagal akibat kesalahan manufaktur, atau karena komponen
telah mencapai akhir masa pakainya.
11.1 Sifat ketergantungan 291
Sistem kritis
Beberapa kelas sistem adalah 'sistem kritis' di mana kegagalan sistem dapat mengakibatkan cedera pada orang,
kerusakan lingkungan, atau kerugian ekonomi yang luas. Contoh sistem kritis termasuk sistem tertanam dalam
perangkat medis, seperti pompa insulin (kritis keselamatan), sistem navigasi pesawat ruang angkasa (kritis misi), dan
sistem transfer uang online (kritis bisnis).
Sistem kritis sangat mahal untuk dikembangkan. Tidak hanya harus dikembangkan sehingga kegagalan sangat
jarang terjadi tetapi juga harus mencakup mekanisme pemulihan yang digunakan jika dan ketika kegagalan terjadi.
http://www.SoftwareEngineering-9.com/Web/Dependability/CritSys.html
2. Kegagalan perangkat lunak Perangkat lunak sistem mungkin gagal karena kesalahannya
spesifikasi, desain, atau implementasi.
3. Kegagalan operasional Pengguna manusia mungkin gagal menggunakan atau mengoperasikan sistem dengan benar.
Karena perangkat keras dan perangkat lunak menjadi lebih andal, kegagalan dalam operasi
sekarang, mungkin, merupakan penyebab tunggal terbesar dari kegagalan sistem.
Kegagalan ini seringkali saling terkait. Komponen perangkat keras yang gagal dapat berarti
operator sistem harus mengatasi situasi yang tidak terduga dan beban kerja tambahan.
Ini menempatkan mereka di bawah tekanan dan orang-orang di bawah tekanan sering membuat
kesalahan. Ini dapat menyebabkan perangkat lunak gagal, yang berarti lebih banyak pekerjaan bagi
operator, lebih banyak stres, dan sebagainya.
Akibatnya, sangat penting bahwa perancang sistem intensif perangkat lunak yang dapat diandalkan
mengambil perspektif sistem holistik, daripada fokus pada satu aspek sistem seperti perangkat lunak
atau perangkat kerasnya. Jika perangkat keras, perangkat lunak, dan proses operasional dirancang
secara terpisah, tanpa memperhitungkan potensi kelemahan bagian lain dari sistem, maka kemungkinan
besar kesalahan akan terjadi pada antarmuka antara bagian-bagian yang berbeda dari sistem.
11.1 Sifat ketergantungan
Kita semua akrab dengan masalah kegagalan sistem komputer. Tanpa alasan yang jelas, komputer kita
terkadang crash atau salah dalam beberapa hal. Program yang berjalan di komputer ini mungkin tidak
beroperasi seperti yang diharapkan dan terkadang dapat merusak data yang dikelola oleh sistem. Kami
telah belajar untuk hidup dengan kegagalan ini tetapi hanya sedikit dari kami yang sepenuhnya
mempercayai komputer pribadi yang biasanya kami gunakan.
Keandalan sistem komputer adalah properti dari sistem yang mencerminkan kepercayaannya.
Kepercayaan di sini pada dasarnya berarti tingkat kepercayaan yang dimiliki pengguna bahwa sistem
akan beroperasi seperti yang mereka harapkan, dan bahwa sistem tidak akan 'gagal' dalam penggunaan
normal. Tidaklah berarti untuk mengekspresikan ketergantungan secara numerik.
Keteguhan
Ketersediaan Keandalan Keamanan Keamanan
Kemampuan sistem untuk Kemampuan sistem untuk Kemampuan sistem untuk Kemampuan sistem untuk
memberikan layanan saat memberikan layanan seperti beroperasi tanpa kegagalan melindungi dirinya dari
yang ditentukan bencana gangguan yang tidak disengaja
diminta
atau disengaja
Sebaliknya, kami menggunakan istilah relatif seperti 'tidak dapat diandalkan', 'sangat dapat diandalkan', dan
Gambar 11.1
Sifat
'sangat dapat diandalkan' untuk mencerminkan tingkat kepercayaan yang mungkin kami miliki dalam suatu sistem.
ketergantungan Keterpercayaan dan kegunaan tentu saja bukan hal yang sama. Saya tidak berpikir bahwa pengolah kata
utama yang saya gunakan untuk menulis buku ini adalah sistem yang sangat dapat diandalkan.
Terkadang macet dan harus dimulai ulang. Namun demikian, karena sangat berguna, saya siap untuk
mentolerir kegagalan sesekali. Namun, untuk mencerminkan kurangnya kepercayaan saya pada sistem, saya
sering menyimpan pekerjaan saya dan menyimpan banyak salinan cadangannya. Saya mengkompensasi
kurangnya ketergantungan sistem dengan tindakan yang membatasi kerusakan yang dapat diakibatkan oleh
kegagalan sistem.
Ada empat dimensi utama untuk ketergantungan, seperti yang ditunjukkan pada Gambar 11.1.
1. Availability Secara informal, ketersediaan suatu sistem adalah kemungkinan sistem itu akan aktif dan
berjalan dan mampu memberikan layanan yang bermanfaat bagi pengguna pada waktu tertentu.
2. Keandalan Secara informal, keandalan suatu sistem adalah probabilitas, selama periode waktu tertentu,
bahwa sistem akan memberikan layanan dengan benar seperti yang diharapkan oleh pengguna.
3. Keamanan Secara informal, keamanan suatu sistem adalah penilaian tentang seberapa besar kemungkinan bahwa
sistem akan menyebabkan kerusakan pada orang atau lingkungannya.
4. Keamanan Secara informal, keamanan suatu sistem adalah penilaian seberapa besar kemungkinannya
sistem dapat menahan intrusi yang tidak disengaja atau disengaja.
Sifat ketergantungan yang ditunjukkan pada Gambar 11.1 adalah sifat kompleks yang dapat dipecah
menjadi sejumlah sifat lain yang lebih sederhana. Misalnya, keamanan mencakup 'integritas' (memastikan
bahwa program sistem dan data tidak rusak) dan 'kerahasiaan' (memastikan bahwa informasi hanya dapat
diakses oleh orang yang berwenang). Keandalan termasuk 'kebenaran' (memastikan layanan sistem seperti
yang ditentukan), 'presisi' (memastikan informasi disampaikan pada tingkat detail yang sesuai), dan 'ketepatan
waktu' (memastikan bahwa informasi disampaikan saat dibutuhkan).
11.1 Sifat ketergantungan 293
Tentu saja, sifat ketergantungan ini tidak semuanya berlaku untuk semua sistem. Untuk
sistem pompa insulin, yang diperkenalkan pada Bab 1, sifat yang paling penting adalah
ketersediaan (harus bekerja bila diperlukan), keandalan (harus memberikan dosis insulin yang
benar), dan keamanan (tidak boleh memberikan dosis insulin yang berbahaya) . Keamanan
tidak menjadi masalah karena pompa tidak akan menyimpan informasi rahasia. Itu tidak bekerja
bersih dan karenanya tidak dapat diserang dengan jahat. Untuk sistem cuaca hutan belantara,
ketersediaan dan keandalan adalah sifat yang paling penting karena biaya perbaikan mungkin
sangat tinggi. Untuk sistem informasi pasien, keamanan sangat penting karena data pribadi
sensitif yang dijaga.
Selain keempat properti ketergantungan utama ini, Anda mungkin juga menganggap properti
sistem lainnya sebagai properti ketergantungan:
1. Repairability Kegagalan sistem tidak dapat dihindari, tetapi gangguan yang disebabkan oleh
kegagalan dapat diminimalisir jika sistem dapat diperbaiki dengan cepat. Agar itu terjadi,
harus dimungkinkan untuk mendiagnosis masalah, mengakses komponen yang gagal,
dan membuat perubahan untuk memperbaiki komponen itu. Perbaikan dalam perangkat
lunak ditingkatkan ketika organisasi yang menggunakan sistem memiliki akses ke kode
sumber dan memiliki keterampilan untuk membuat perubahan padanya. Perangkat lunak
open source membuat ini lebih mudah tetapi penggunaan kembali komponen dapat membuatnya lebih sulit.
2. Pemeliharaan Saat sistem digunakan, persyaratan baru muncul dan penting untuk
mempertahankan kegunaan sistem dengan mengubahnya untuk mengakomodasi
persyaratan baru ini. Perangkat lunak yang dapat dipelihara adalah perangkat lunak yang
dapat diadaptasi secara ekonomis untuk mengatasi persyaratan baru, dan di mana ada
kemungkinan kecil bahwa membuat perubahan akan menimbulkan kesalahan baru ke dalam sistem.
3. Bertahan Hidup Atribut yang sangat penting untuk sistem berbasis Internet adalah
kemampuan bertahan (Ellison et al., 1999b). Survivabilitas adalah kemampuan sistem
untuk terus memberikan layanan saat diserang dan, berpotensi, saat bagian dari sistem
dinonaktifkan. Bekerja pada kemampuan bertahan berfokus pada identifikasi komponen
sistem utama dan memastikan bahwa mereka dapat memberikan layanan minimal. Tiga
strategi digunakan untuk meningkatkan kemampuan bertahan—ketahanan terhadap
serangan, pengenalan serangan, dan pemulihan dari kerusakan yang disebabkan oleh serangan (Ellison et al., 1999
Saya membahas ini secara lebih rinci di Bab 14.
4. Toleransi kesalahan Properti ini dapat dianggap sebagai bagian dari kegunaan dan
mencerminkan sejauh mana sistem telah dirancang sehingga kesalahan input pengguna
dapat dihindari dan ditoleransi. Ketika kesalahan pengguna terjadi, sistem harus, sejauh
mungkin, mendeteksi kesalahan ini dan memperbaikinya secara otomatis atau meminta
pengguna untuk memasukkan kembali datanya.
Gagasan ketergantungan sistem sebagai properti mencakup diperkenalkan karena sifat

ketergantungan ketersediaan, keamanan, keandalan, dan keselamatan terkait erat. Operasi
sistem yang aman biasanya tergantung pada sistem yang tersedia dan beroperasi dengan
andal. Sebuah sistem mungkin menjadi tidak dapat diandalkan karena penyusup telah merusak
datanya. Serangan penolakan layanan pada sistem dimaksudkan untuk mengkompromikan
ketersediaan sistem. Jika sistem terinfeksi virus, Anda tidak dapat yakin dengan keandalan atau
keamanannya karena virus dapat mengubah perilakunya.
Untuk mengembangkan perangkat lunak yang dapat diandalkan, Anda perlu memastikan bahwa:
1. Anda menghindari pengenalan kesalahan yang tidak disengaja ke dalam sistem selama spesifikasi
dan pengembangan perangkat lunak.
2. Anda merancang proses verifikasi dan validasi yang efektif dalam menemukan kesalahan residual
yang memengaruhi keandalan sistem.
3. Anda merancang mekanisme perlindungan yang menjaga dari serangan eksternal yang dapat
membahayakan ketersediaan atau keamanan sistem.
4. Anda mengonfigurasi sistem yang diterapkan dan perangkat lunak pendukungnya dengan benar
untuk lingkungan pengoperasiannya.
Selain itu, Anda biasanya harus berasumsi bahwa perangkat lunak Anda tidak sempurna dan
kegagalan perangkat lunak dapat terjadi. Oleh karena itu, sistem Anda harus menyertakan mekanisme
pemulihan yang memungkinkan pemulihan layanan sistem normal secepat mungkin.
Kebutuhan toleransi kesalahan berarti bahwa sistem yang dapat diandalkan harus menyertakan
kode yang berlebihan untuk membantu mereka memantau diri mereka sendiri, mendeteksi keadaan
yang salah, dan memulihkan dari kesalahan sebelum kegagalan terjadi. Ini mempengaruhi kinerja
sistem, karena pemeriksaan tambahan diperlukan setiap kali sistem dijalankan. Oleh karena itu,
desainer biasanya harus menukar kinerja dan ketergantungan. Anda mungkin perlu meninggalkan
cek dari sistem karena ini memperlambat sistem. Namun, risiko konsekuensial di sini adalah bahwa
beberapa kegagalan terjadi karena kesalahan belum terdeteksi.
Karena desain ekstra, implementasi, dan biaya validasi, meningkatkan ketergantungan sistem
secara signifikan meningkatkan biaya pengembangan. Secara khusus, biaya validasi tinggi untuk
sistem yang harus sangat dapat diandalkan seperti sistem kontrol kritis keselamatan. Selain
memvalidasi bahwa sistem memenuhi persyaratannya, proses validasi mungkin harus membuktikan
kepada regulator eksternal bahwa sistem tersebut aman. Misalnya, sistem pesawat harus menunjukkan
kepada regulator, seperti Otoritas Penerbangan Federal, bahwa kemungkinan kegagalan sistem
bencana yang mempengaruhi keselamatan pesawat sangat rendah.
Gambar 11.2 menunjukkan bahwa hubungan antara biaya dan peningkatan inkremental dalam
ketergantungan. Jika perangkat lunak Anda tidak terlalu dapat diandalkan, Anda bisa mendapatkan
peningkatan yang signifikan dengan biaya yang relatif rendah dengan menggunakan rekayasa perangkat lunak yang lebih baik.
Namun, jika Anda sudah menggunakan praktik yang baik, biaya peningkatan jauh lebih besar dan
manfaat dari peningkatan itu lebih sedikit. Ada juga masalah pengujian perangkat lunak Anda untuk
menunjukkan bahwa itu dapat diandalkan. Ini bergantung pada menjalankan banyak tes dan melihat
jumlah kegagalan yang terjadi. Ketika perangkat lunak Anda menjadi lebih dapat diandalkan, Anda
melihat semakin sedikit kegagalan. Akibatnya, semakin banyak tes diperlukan untuk mencoba dan
menilai berapa banyak masalah yang tersisa dalam perangkat lunak. Karena pengujian sangat mahal,
ini secara dramatis meningkatkan biaya sistem dengan ketergantungan tinggi.
11.2 Ketersediaan dan keandalan 295
Rendah Sedang Tinggi Sangat Ultra

Gambar 11.2
Biaya/keandalan Tinggi Tinggi
melengkung Keteguhan
11.2 Ketersediaan dan keandalan
Ketersediaan dan keandalan sistem adalah sifat yang terkait erat yang keduanya dapat
dinyatakan sebagai probabilitas numerik. Ketersediaan suatu sistem adalah probabilitas
bahwa sistem akan aktif dan berjalan untuk memberikan layanan ini kepada pengguna berdasarkan permintaan.
Keandalan sistem adalah probabilitas bahwa layanan sistem akan diberikan seperti yang didefinisikan
dalam spesifikasi sistem. Jika, rata-rata, 2 input dalam setiap 1.000
menyebabkan kegagalan, maka keandalan, dinyatakan sebagai tingkat terjadinya kegagalan, adalah
0,002. Jika ketersediaannya 0,999, ini berarti bahwa, selama beberapa periode waktu, sistem
tersedia untuk 99,9% dari waktu itu.
Keandalan dan ketersediaan terkait erat tetapi terkadang yang satu lebih penting daripada yang lain.
Jika pengguna mengharapkan layanan berkelanjutan dari suatu sistem maka sistem
memiliki kebutuhan ketersediaan yang tinggi. Itu harus tersedia setiap kali permintaan dibuat.
Namun, jika kerugian yang diakibatkan oleh kegagalan sistem rendah dan sistem dapat
pulih dengan cepat maka kegagalan tidak secara serius mempengaruhi pengguna sistem. Dalam sistem seperti itu,
persyaratan keandalan mungkin relatif rendah.
Sakelar pertukaran telepon yang merutekan panggilan telepon adalah contoh sistem di mana:
ketersediaan lebih penting daripada keandalan. Pengguna mengharapkan nada panggil saat mereka
mengangkat telepon, sehingga sistem memiliki persyaratan ketersediaan tinggi. Jika terjadi kesalahan sistem
saat koneksi sedang disiapkan, ini sering kali dapat dipulihkan dengan cepat. Pertukaran sakelar
biasanya dapat mengatur ulang sistem dan mencoba lagi upaya koneksi. Ini bisa dilakukan dengan sangat
dengan cepat dan pengguna telepon mungkin tidak menyadari bahwa telah terjadi kegagalan. Lebih-lebih lagi,
bahkan jika panggilan terputus, konsekuensinya biasanya tidak serius. Oleh karena itu, ketersediaan
kemampuan daripada keandalan adalah persyaratan ketergantungan utama untuk jenis sistem ini.
Keandalan dan ketersediaan sistem dapat didefinisikan lebih tepat sebagai berikut:
1. Keandalan Probabilitas operasi bebas kegagalan selama waktu tertentu, dalam

lingkungan tertentu, untuk tujuan tertentu.
2. Availability Probabilitas bahwa suatu sistem, pada suatu titik waktu, akan beroperasi
dan mampu memberikan layanan yang diminta.
Salah satu masalah praktis dalam mengembangkan sistem yang andal adalah bahwa
gagasan intuitif tentang keandalan dan ketersediaan terkadang lebih luas daripada definisi
terbatas ini. Definisi keandalan menyatakan bahwa lingkungan di mana sistem digunakan dan
tujuan penggunaannya harus diperhitungkan. Jika Anda mengukur keandalan sistem dalam
satu lingkungan, Anda tidak dapat berasumsi bahwa keandalannya akan sama jika sistem
digunakan dengan cara yang berbeda.
Sebagai contoh, katakanlah Anda mengukur keandalan pengolah kata di lingkungan kantor
di mana sebagian besar pengguna tidak tertarik dengan pengoperasian perangkat lunak. Mereka
mengikuti petunjuk penggunaannya dan tidak mencoba bereksperimen dengan sistem. Jika
Anda kemudian mengukur keandalan sistem yang sama di lingkungan universitas, maka
keandalannya mungkin sangat berbeda. Di sini, siswa dapat menjelajahi batas-batas sistem dan
menggunakan sistem dengan cara yang tidak terduga. Hal ini dapat mengakibatkan kegagalan
sistem yang tidak terjadi di lingkungan kantor yang lebih terbatas.
Definisi standar ketersediaan dan keandalan ini tidak memperhitungkan tingkat keparahan
kegagalan atau konsekuensi dari tidak tersedianya. Orang sering menerima kegagalan sistem
kecil tetapi sangat prihatin dengan kegagalan serius yang memiliki konsekuensi biaya tinggi.
Misalnya, kegagalan komputer yang merusak data yang disimpan kurang dapat diterima daripada
kegagalan yang membekukan mesin dan dapat diatasi dengan menghidupkan ulang komputer.
Definisi keandalan yang ketat menghubungkan implementasi sistem dengan spesifikasinya.

Artinya, sistem berperilaku andal jika perilakunya konsisten dengan yang ditentukan dalam
spesifikasi. Namun, penyebab umum dari ketidakandalan yang dirasakan adalah bahwa
spesifikasi sistem tidak sesuai dengan harapan pengguna sistem.
Sayangnya, banyak spesifikasi yang tidak lengkap atau salah dan diserahkan kepada insinyur
perangkat lunak untuk menafsirkan bagaimana sistem harus berperilaku. Karena mereka bukan
pakar domain, oleh karena itu mereka mungkin tidak menerapkan perilaku yang diharapkan
pengguna. Juga benar, tentu saja, bahwa pengguna tidak membaca spesifikasi sistem. Oleh
karena itu, mereka mungkin memiliki harapan yang tidak realistis terhadap sistem.
Ketersediaan dan keandalan jelas terkait karena kegagalan sistem dapat merusak sistem.
Namun, ketersediaan tidak hanya tergantung pada jumlah sistem yang crash, tetapi juga pada
waktu yang dibutuhkan untuk memperbaiki kesalahan yang menyebabkan kegagalan.
Oleh karena itu, jika sistem A gagal setahun sekali dan sistem B gagal sebulan sekali maka A
jelas lebih dapat diandalkan daripada B. Namun, asumsikan bahwa sistem A membutuhkan
waktu tiga hari untuk memulai kembali setelah kegagalan, sedangkan sistem B membutuhkan
10 menit untuk memulai kembali. Ketersediaan sistem B sepanjang tahun (waktu henti 120
menit) jauh lebih baik daripada sistem A (4.320 menit waktu henti).
Gangguan yang disebabkan oleh sistem yang tidak tersedia tidak tercermin dalam metrik
kemampuan ketersediaan sederhana yang menentukan persentase waktu sistem tersedia.
Waktu ketika sistem gagal juga signifikan. Jika sistem tidak tersedia selama satu jam setiap hari
antara pukul 3 pagi dan 4 pagi, ini mungkin tidak memengaruhi banyak pengguna. Namun, jika
sistem yang sama tidak tersedia selama 10 menit selama hari kerja, ketidaktersediaan sistem
mungkin akan memiliki efek yang jauh lebih besar.
11.2 Ketersediaan dan keandalan 297
Ketentuan Keterangan
Kesalahan atau kesalahan manusia Perilaku manusia yang menghasilkan pengenalan kesalahan ke dalam sistem. Misalnya, dalam sistem
cuaca hutan belantara, seorang programmer mungkin memutuskan bahwa cara menghitung waktu untuk transmisi
berikutnya adalah dengan menambahkan 1 jam ke waktu saat ini. Ini berfungsi kecuali ketika waktu transmisi antara
23.00 dan tengah malam (tengah malam adalah 00.00 dalam jam 24 jam).
Kesalahan sistem Karakteristik sistem perangkat lunak yang dapat menyebabkan kesalahan sistem. Kesalahannya adalah
pencantuman kode untuk menambahkan 1 jam ke waktu transmisi terakhir, tanpa memeriksa apakah waktunya
lebih besar atau sama dengan 23.00.
Sistem bermasalah Status sistem yang salah yang dapat menyebabkan perilaku sistem yang tidak terduga oleh pengguna sistem.
Nilai waktu transmisi tidak diatur dengan benar (ke 24.XX daripada 00.XX) ketika kode yang salah dijalankan.
Kegagalan sistem Suatu peristiwa yang terjadi pada suatu saat ketika sistem tidak memberikan layanan seperti yang diharapkan
oleh penggunanya. Tidak ada data cuaca yang dikirimkan karena waktunya tidak valid.
Masalah keandalan dan ketersediaan sistem sebagian besar disebabkan oleh kegagalan sistem.
Gambar 11.3
Terminologi reliabilitas Beberapa dari kegagalan ini merupakan konsekuensi dari kesalahan spesifikasi atau kegagalan
dalam sistem terkait lainnya seperti sistem komunikasi. Namun, banyak kegagalan merupakan
konsekuensi dari perilaku sistem yang salah yang berasal dari kesalahan dalam sistem.
Saat membahas reliabilitas, akan sangat membantu jika menggunakan terminologi yang tepat
dan membedakan antara istilah 'kesalahan', 'kesalahan', dan 'kegagalan'. Saya telah
mendefinisikan istilah-istilah ini dalam Gambar 11.3 dan telah mengilustrasikan setiap definisi
dengan sebuah contoh dari sistem cuaca hutan belantara.
Ketika input atau urutan input menyebabkan kode yang salah dalam sistem dieksekusi,
keadaan yang salah dibuat yang dapat menyebabkan kegagalan perangkat lunak. Gambar 11.4,
berasal dari Littlewood (1990), menunjukkan sistem perangkat lunak sebagai pemetaan dari satu
set input ke satu set output. Diberikan urutan input atau input, program merespons dengan
menghasilkan output yang sesuai. Misalnya, diberi masukan berupa URL, browser web
menghasilkan keluaran berupa tampilan halaman web yang diminta.
Kebanyakan input tidak menyebabkan kegagalan sistem. Namun, beberapa input atau
kombinasi input, yang ditunjukkan pada elips berbayang yaitu pada Gambar 11.4, menyebabkan
kegagalan sistem atau output yang salah dihasilkan. Keandalan program tergantung pada jumlah
input sistem yang merupakan anggota dari kumpulan input yang mengarah ke output yang salah.
Jika input dalam set Ie dieksekusi oleh bagian sistem yang sering digunakan, maka kegagalan
akan sering terjadi. Namun, jika input dalam Ie dieksekusi oleh kode yang jarang digunakan,
maka pengguna hampir tidak akan pernah melihat kegagalan.
Karena setiap pengguna sistem menggunakannya dengan cara yang berbeda, mereka
memiliki persepsi yang berbeda tentang keandalannya. Kesalahan yang mempengaruhi keandalan
sistem untuk satu pengguna mungkin tidak pernah terungkap di bawah mode kerja orang lain
(Gambar 11.5). Pada Gambar 11.5, kumpulan input yang salah sesuai dengan elips berlabel Ie
pada Gambar 11.4. Himpunan input yang dihasilkan oleh Pengguna 2 berpotongan dengan set input yang salah ini. Pengg
Set Masukan Yaitu Masukan Menyebabkan

Keluaran yang Salah
Program
Gambar 11.4
Sistem sebagai Set Keluaran Oe Keliru
pemetaan input/ Keluaran

output
oleh karena itu mengalami beberapa kegagalan sistem. Pengguna 1 dan Pengguna 3, bagaimanapun, tidak
pernah menggunakan input dari set yang salah. Bagi mereka, perangkat lunak akan selalu dapat diandalkan.
Keandalan praktis dari suatu program tergantung pada jumlah input yang menyebabkan output yang
salah (kegagalan) selama penggunaan normal sistem oleh sebagian besar pengguna. Kesalahan perangkat
lunak yang hanya terjadi dalam situasi luar biasa memiliki sedikit efek praktis pada kemampuan keandalan
sistem. Akibatnya, menghapus kesalahan perangkat lunak mungkin tidak secara signifikan meningkatkan
keandalan sistem secara keseluruhan. Mills dkk. (1987) menemukan bahwa menghapus 60% dari kesalahan
yang diketahui dalam perangkat lunak mereka menyebabkan peningkatan keandalan 3%. Adams (1984),
dalam sebuah studi produk perangkat lunak IBM, mencatat bahwa banyak cacat pada produk hanya
mungkin menyebabkan kegagalan setelah ratusan atau ribuan bulan penggunaan produk.
Kesalahan sistem tidak selalu menghasilkan kesalahan sistem dan kesalahan sistem tidak selalu
pada dasarnya mengakibatkan kegagalan sistem. Alasan untuk ini adalah sebagai berikut:
1. Tidak semua kode dalam suatu program dieksekusi. Kode yang menyertakan kesalahan (misalnya,
kegagalan untuk menginisialisasi variabel) mungkin tidak akan pernah dieksekusi karena cara
perangkat lunak tersebut digunakan.
Mungkin
Masukan
Pengguna
Keliru
1
Masukan
Pengguna
Pengguna
3
2
Gambar 11.5 Pola penggunaan

perangkat lunak
11.3 Keamanan 299 _
2. Kesalahan bersifat sementara. Variabel status mungkin memiliki nilai yang salah yang
disebabkan oleh eksekusi kode yang salah. Namun, sebelum ini diakses dan menyebabkan
kegagalan sistem, beberapa input sistem lain mungkin diproses yang mengatur ulang status ke nilai yang valid.
3. Sistem dapat mencakup deteksi kesalahan dan mekanisme perlindungan. Ini memastikan
bahwa perilaku yang salah ditemukan dan diperbaiki sebelum layanan sistem terpengaruh.
Alasan lain mengapa kesalahan dalam suatu sistem mungkin tidak menyebabkan kegagalan
sistem adalah bahwa, dalam praktiknya, pengguna menyesuaikan perilaku mereka untuk
menghindari penggunaan input yang mereka ketahui menyebabkan kegagalan program. Pengguna
berpengalaman 'mengatasi' fitur perangkat lunak yang menurut mereka tidak dapat diandalkan.
Misalnya, saya menghindari fitur tertentu, seperti penomoran otomatis dalam sistem pengolah
kata yang saya gunakan untuk menulis buku ini. Ketika saya menggunakan penomoran otomatis,
itu sering salah. Memperbaiki kesalahan dalam fitur yang tidak digunakan tidak membuat
perbedaan praktis pada keandalan sistem. Saat pengguna berbagi informasi tentang masalah dan solusi, efek dari masalah
Perbedaan antara kesalahan, kesalahan, dan kegagalan, dijelaskan pada Gambar 11.3,
membantu mengidentifikasi tiga pendekatan pelengkap yang digunakan untuk meningkatkan
keandalan sistem:
1. Penghindaran kesalahan Teknik pengembangan digunakan untuk meminimalkan kemungkinan

kesalahan manusia dan/atau menjebak kesalahan sebelum menyebabkan kesalahan sistem.
Contoh teknik tersebut termasuk menghindari konstruksi bahasa pemrograman rawan
kesalahan seperti pointer dan penggunaan analisis statis untuk mendeteksi anomali program.
2. Deteksi dan penghapusan kesalahan Penggunaan teknik verifikasi dan validasi yang
meningkatkan kemungkinan kesalahan akan terdeteksi dan dihapus sebelum
sistem digunakan. Pengujian sistematis dan debugging adalah contoh dari teknik deteksi
kesalahan.
3. Toleransi kesalahan Ini adalah teknik yang memastikan bahwa kesalahan dalam sistem tidak
mengakibatkan kesalahan sistem atau kesalahan sistem tidak mengakibatkan kegagalan
sistem. Penggabungan fasilitas self-checking dalam sistem dan penggunaan modul sistem
yang berlebihan adalah contoh teknik toleransi kesalahan.
Aplikasi praktis dari teknik ini dibahas dalam Bab 13, yang
mencakup teknik untuk rekayasa perangkat lunak yang dapat diandalkan.
11.3 Keamanan
Sistem yang kritis terhadap keselamatan adalah sistem di mana operasi sistem harus selalu
aman; yaitu, sistem tidak boleh merusak orang atau lingkungan sistem bahkan jika sistem gagal.
Contoh sistem keselamatan-kritis termasuk kontrol
dan sistem pemantauan di pesawat terbang, sistem kontrol proses di pabrik kimia dan farmasi, dan
sistem kontrol mobil.
Kontrol perangkat keras dari sistem yang kritis terhadap keselamatan lebih sederhana untuk diterapkan
dan dianalisis daripada kontrol perangkat lunak. Namun, kami sekarang membangun sistem dengan
kompleksitas sedemikian rupa sehingga tidak dapat dikendalikan oleh perangkat keras saja. Kontrol
perangkat lunak sangat penting karena kebutuhan untuk mengelola sejumlah besar sensor dan aktuator
dengan undang-undang kontrol yang kompleks. Misalnya, pesawat militer yang canggih dan tidak stabil
secara aerodinamis memerlukan penyesuaian permukaan penerbangan yang dikontrol perangkat lunak secara terus-menerus untuk memas
Perangkat lunak yang kritis terhadap keamanan terbagi dalam dua kelas:
1. Perangkat lunak kritis keamanan utama Ini adalah perangkat lunak yang tertanam sebagai
pengontrol dalam suatu sistem. Malfungsi perangkat lunak tersebut dapat menyebabkan
kerusakan perangkat keras, yang mengakibatkan cedera manusia atau kerusakan lingkungan.
Perangkat lunak pompa insulin, yang diperkenalkan pada Bab 1, adalah contoh sistem kritis-
keamanan utama. Kegagalan sistem dapat menyebabkan cedera pengguna.
2. Perangkat lunak kritis keamanan sekunder Ini adalah perangkat lunak yang secara tidak langsung
dapat mengakibatkan cedera. Contoh perangkat lunak tersebut adalah sistem desain rekayasa
berbantuan komputer yang malfungsinya dapat mengakibatkan kesalahan desain pada objek
yang dirancang. Kesalahan ini dapat menyebabkan cedera pada orang jika sistem yang
dirancang tidak berfungsi. Contoh lain dari sistem kritis keselamatan sekunder adalah sistem
manajemen perawatan kesehatan mental, MHC-PMS. Kegagalan sistem ini, dimana pasien yang
tidak stabil mungkin tidak dirawat dengan baik, dapat menyebabkan pasien tersebut melukai
diri sendiri atau orang lain.
Keandalan sistem dan keamanan sistem saling terkait tetapi sistem yang andal bisa jadi tidak
aman dan sebaliknya. Perangkat lunak mungkin masih berperilaku sedemikian rupa sehingga perilaku
sistem yang dihasilkan menyebabkan kecelakaan. Ada empat alasan mengapa sistem perangkat lunak
yang andal belum tentu aman:
1. Kita tidak akan pernah bisa 100% yakin bahwa sistem perangkat lunak bebas dari kesalahan dan toleran
terhadap kesalahan. Kesalahan yang tidak terdeteksi dapat menjadi tidak aktif untuk waktu yang lama
dan kegagalan perangkat lunak dapat terjadi setelah bertahun-tahun beroperasi dengan andal.
2. Spesifikasi mungkin tidak lengkap karena tidak menggambarkan perilaku sistem yang diperlukan
dalam beberapa situasi kritis. Persentase yang tinggi dari malfungsi sistem (Boehm et al., 1975;
Endres, 1975; Lutz, 1993; Nakajo dan Kume, 1991) adalah hasil dari spesifikasi daripada
kesalahan desain. Dalam studi kesalahan dalam sistem tertanam, Lutz menyimpulkan:
. . . kesulitan dengan persyaratan adalah akar penyebab utama dari kesalahan
perangkat lunak yang terkait dengan keselamatan, yang terus berlanjut hingga
integrasi dan pengujian sistem.
3. Malfungsi perangkat keras dapat menyebabkan sistem berperilaku dengan cara yang tidak terduga,
dan menghadirkan perangkat lunak dengan lingkungan yang tidak terduga. Ketika komponen
mendekati kegagalan fisik, mereka mungkin berperilaku tidak menentu dan menghasilkan sinyal
yang berada di luar rentang yang dapat ditangani oleh perangkat lunak.
11.3 Keamanan 301 _
Ketentuan Definisi
Kecelakaan (atau kecelakaan) Suatu peristiwa atau rangkaian peristiwa yang tidak direncanakan yang mengakibatkan
kematian atau cedera manusia, kerusakan harta benda, atau lingkungan. Overdosis insulin
adalah contoh kecelakaan.
Bahaya Suatu kondisi yang berpotensi menyebabkan atau berkontribusi terhadap

kecelakaan. Kegagalan sensor yang mengukur glukosa darah adalah contoh bahaya.
Kerusakan Ukuran kerugian akibat kecelakaan. Kerusakan dapat berkisar dari banyak orang yang terbunuh
akibat kecelakaan hingga cedera ringan atau kerusakan properti. Kerusakan akibat overdosis
insulin bisa berupa cedera serius atau kematian pengguna pompa insulin.
Tingkat keparahan bahaya Penilaian kemungkinan kerusakan terburuk yang dapat diakibatkan oleh bahaya tertentu.
Tingkat keparahan bahaya dapat berkisar dari bencana, di mana banyak orang terbunuh,
hingga kecil, di mana hanya terjadi kerusakan kecil.
Ketika kematian individu adalah suatu kemungkinan, penilaian yang wajar dari tingkat
keparahan bahaya adalah 'sangat tinggi.'
Probabilitas bahaya Probabilitas terjadinya peristiwa yang menimbulkan bahaya.
Nilai probabilitas cenderung berubah-ubah tetapi berkisar dari 'probable' (misalnya 1/100
peluang terjadinya bahaya) hingga 'tidak masuk akal' (tidak ada situasi yang memungkinkan
terjadinya bahaya). Kemungkinan kegagalan sensor pada pompa insulin yang mengakibatkan
overdosis mungkin rendah.
Mempertaruhkan
Ini adalah ukuran probabilitas bahwa sistem akan menyebabkan kecelakaan. Risiko
dinilai dengan mempertimbangkan probabilitas bahaya, tingkat keparahan bahaya, dan
probabilitas bahwa bahaya akan menyebabkan kecelakaan. Risiko overdosis insulin mungkin
sedang hingga rendah.
4. Operator sistem dapat menghasilkan input yang tidak salah secara individual tetapi, dalam
Gambar 11.6
beberapa situasi, dapat menyebabkan kegagalan fungsi sistem. Sebuah contoh anekdot
Terminologi keselamatan
dari hal ini terjadi ketika sebuah undercarriage pesawat runtuh saat pesawat berada di
tanah. Rupanya, seorang teknisi menekan tombol yang menginstruksikan perangkat lunak
manajemen utilitas untuk menaikkan undercarriage. Perangkat lunak melakukan instruksi
mekanik dengan sempurna. Namun, sistem seharusnya tidak mengizinkan perintah
tersebut kecuali jika pesawat berada di udara.
Kosakata khusus telah berkembang untuk membahas sistem kritis keselamatan dan penting
untuk memahami istilah khusus yang digunakan. Gambar 11.6 merangkum beberapa definisi
istilah penting, dengan contoh yang diambil dari sistem pompa insulin.
Kunci untuk memastikan keselamatan adalah memastikan bahwa kecelakaan tidak terjadi
atau bahwa konsekuensi dari suatu kecelakaan adalah minimal. Hal ini dapat dicapai dengan
tiga cara yang saling melengkapi:
1. Penghindaran bahaya Sistem dirancang sedemikian rupa sehingga bahaya dapat dihindari.
Misalnya, sistem pemotongan yang mengharuskan operator menggunakan dua tangan untuk menekan
tombol terpisah secara bersamaan menghindari bahaya tangan operator berada di jalur
blade.
2. Deteksi dan penghilangan bahaya Sistem ini dirancang agar bahaya dideteksi dan dihilangkan
sebelum menimbulkan kecelakaan. Misalnya, sistem pabrik kimia dapat mendeteksi
tekanan berlebih dan membuka katup pelepas untuk mengurangi tekanan ini sebelum
ledakan terjadi.
3. Batasan kerusakan Sistem dapat menyertakan fitur perlindungan yang meminimalkan

kerusakan yang mungkin terjadi akibat kecelakaan. Misalnya, mesin pesawat biasanya
dilengkapi dengan alat pemadam api otomatis. Jika terjadi kebakaran, seringkali dapat
dikendalikan sebelum menimbulkan ancaman bagi pesawat.
Kecelakaan paling sering terjadi ketika beberapa hal tidak beres pada saat yang bersamaan.
Analisis kecelakaan serius (Perrow, 1984) menunjukkan bahwa hampir semuanya disebabkan
oleh kombinasi kegagalan di berbagai bagian sistem. Kombinasi tak terduga dari kegagalan
subsistem menyebabkan interaksi yang mengakibatkan kegagalan sistem secara keseluruhan.
Misalnya, kegagalan sistem pendingin udara dapat menyebabkan panas berlebih, yang kemudian
menyebabkan perangkat keras sistem menghasilkan sinyal yang salah. Perrow juga menyarankan
bahwa tidak mungkin untuk mengantisipasi semua kemungkinan kombinasi kegagalan.
Kecelakaan yang ada kedepan bagian tak terelakkan dari menggunakan sistem yang kompleks.
Beberapa orang telah menggunakan ini sebagai argumen terhadap kontrol perangkat lunak.
Karena kompleksitas perangkat lunak, ada lebih banyak interaksi antara bagian-bagian yang
berbeda dari suatu sistem. Ini berarti bahwa mungkin akan ada lebih banyak kombinasi
kesalahan yang dapat menyebabkan kegagalan sistem.
Namun, sistem yang dikendalikan perangkat lunak dapat memantau kondisi yang lebih luas
daripada sistem elektro-mekanis. Mereka dapat diadaptasi dengan relatif mudah. Mereka
menggunakan perangkat keras komputer, yang memiliki keandalan bawaan yang sangat tinggi
dan yang secara fisik kecil dan ringan. Sistem yang dikendalikan perangkat lunak dapat
menyediakan interlock keamanan yang canggih. Mereka dapat mendukung strategi pengendalian
yang mengurangi jumlah waktu yang harus dihabiskan orang di lingkungan berbahaya.
Meskipun kontrol perangkat lunak dapat memperkenalkan lebih banyak cara di mana sistem
bisa salah, itu juga memungkinkan pemantauan dan perlindungan yang lebih baik dan karenanya dapat berkontribusi pada p
Dalam semua kasus, penting untuk menjaga rasa proporsional tentang keamanan sistem.
Tidak mungkin membuat sistem 100% aman dan masyarakat harus memutuskan apakah
konsekuensi dari kecelakaan sesekali sepadan dengan manfaat yang datang dari penggunaan
teknologi canggih. Ini juga merupakan keputusan sosial dan politik tentang bagaimana
menggunakan sumber daya nasional yang terbatas untuk mengurangi risiko terhadap populasi secara keseluruhan.
11.4 Keamanan
Keamanan adalah atribut sistem yang mencerminkan kemampuan sistem untuk melindungi diri
dari serangan eksternal, yang mungkin disengaja atau tidak disengaja. Serangan eksternal ini
dimungkinkan karena sebagian besar komputer tujuan umum sekarang terhubung ke jaringan dan
11.4 Keamanan 303 _
Ketentuan Definisi
Aset Sesuatu yang berharga yang harus dilindungi. Asetnya mungkin sistem perangkat lunak itu sendiri
atau data yang digunakan oleh sistem tersebut.
Paparan Kemungkinan kehilangan atau kerusakan pada sistem komputasi. Hal ini dapat berupa kehilangan atau kerusakan data, atau dapat
menjadi kehilangan waktu dan usaha jika pemulihan diperlukan setelah pelanggaran keamanan.
Kerentanan Suatu kelemahan dalam sistem berbasis komputer yang dapat dimanfaatkan untuk menimbulkan kerugian atau kerugian.
Menyerang Eksploitasi kerentanan sistem. Umumnya, ini dari luar sistem dan
upaya yang disengaja untuk menyebabkan beberapa kerusakan.
Ancaman Keadaan yang berpotensi menimbulkan kerugian atau kerugian. Anda dapat menganggap ini sebagai
kerentanan sistem yang terkena serangan.
Kontrol Ukuran perlindungan yang mengurangi kerentanan sistem. Enkripsi adalah contoh kontrol yang
mengurangi kerentanan sistem kontrol akses yang lemah.
sehingga dapat diakses oleh orang luar. Contoh serangan mungkin pemasangan
Gambar 11.7
Terminologi keamanan
virus dan trojan horse, penggunaan layanan sistem yang tidak sah atau tidak sah
modifikasi sistem atau datanya. Jika Anda benar-benar menginginkan sistem yang aman, sebaiknya jangan
untuk menghubungkannya ke Internet. Kemudian, masalah keamanan Anda terbatas untuk memastikan bahwa
pengguna yang berwenang tidak menyalahgunakan sistem. Namun, dalam praktiknya, ada manfaat
besar yang cocok dari akses jaringan untuk sebagian besar sistem besar sehingga memutuskan sambungan dari Internet
tidak hemat biaya.
Untuk beberapa sistem, keamanan adalah dimensi terpenting dari kemampuan ketergantungan
sistem. Sistem militer, sistem perdagangan elektronik, dan sistem yang melibatkan
pemrosesan dan pertukaran informasi rahasia harus dirancang sedemikian rupa sehingga
mereka mencapai tingkat keamanan yang tinggi. Jika sistem reservasi maskapai tidak tersedia,
misalnya, hal ini menyebabkan ketidaknyamanan dan beberapa penundaan dalam penerbitan tiket. Namun,
jika sistem tidak aman maka penyerang dapat menghapus semua pemesanan dan itu akan menjadi
praktis tidak mungkin untuk melanjutkan operasi maskapai normal.
Seperti aspek ketergantungan lainnya, ada terminologi khusus yang diasosiasikan dengan keamanan.
Beberapa istilah penting, seperti yang dibahas oleh Pfleeger (Pfleeger dan
Pfleeger, 2007), didefinisikan pada Gambar 11.7. Gambar 11.8 mengambil konsep keamanan
dijelaskan pada Gambar 11.7 dan menunjukkan bagaimana mereka berhubungan dengan skenario berikut diambil:
dari MHC-PMS:
Staf klinik masuk ke MHC-PMS dengan nama pengguna dan kata sandi. Sistem membutuhkan
kata sandi yang panjangnya paling sedikit delapan huruf tetapi memungkinkan kata sandi apa
pun untuk disetel tanpa pemeriksaan lebih lanjut. Seorang penjahat mengetahui bahwa seorang yang dibayar dengan baik
bintang olahraga menerima perawatan untuk masalah kesehatan mental. Dia akan suka
untuk mendapatkan akses ilegal ke informasi dalam sistem ini sehingga dia dapat memeras
bintang.
Ketentuan Contoh
Aset Catatan setiap pasien yang menerima atau telah menerima pengobatan.
Paparan Potensi kerugian finansial dari pasien masa depan yang tidak mencari pengobatan karena tidak
mempercayai klinik untuk menyimpan data mereka. Kerugian finansial dari tindakan hukum oleh bintang olahraga. Kehilangan
reputasi.
Kerentanan Sistem kata sandi yang lemah yang memudahkan pengguna untuk mengatur kata sandi yang dapat ditebak. ID pengguna
yang sama dengan nama.
Menyerang Peniruan identitas pengguna yang sah.
Ancaman Pengguna yang tidak sah akan mendapatkan akses ke sistem dengan menebak kredensial (nama login
dan kata sandi) dari pengguna yang berwenang.
Kontrol Sistem pemeriksaan kata sandi yang melarang kata sandi pengguna yang merupakan nama atau kata-kata yang tepat
yang biasanya dimasukkan dalam kamus.
Dengan menyamar sebagai kerabat yang peduli dan berbicara dengan perawat di ruang mental
Gambar 11.8
Contoh keamanan klinik kesehatan, ia menemukan cara mengakses sistem dan informasi pribadi
terminologi tentang perawat. Dengan memeriksa lencana nama, ia menemukan nama-nama dari beberapa
orang-orang mengizinkan akses. Dia kemudian mencoba untuk masuk ke sistem dengan menggunakan
nama-nama ini dan secara sistematis menebak kemungkinan kata sandi (seperti nama
anak).
Dalam sistem jaringan apa pun, ada tiga jenis ancaman keamanan utama:
1. Ancaman terhadap kerahasiaan sistem dan datanya Dapat mengungkapkan informasi kepada
orang atau program yang tidak berwenang untuk mengaksesnya
informasi.
2. Ancaman terhadap integritas sistem dan datanya Ancaman tersebut dapat merusak atau
merusak perangkat lunak atau datanya.
3. Ancaman terhadap ketersediaan sistem dan datanya Ancaman ini dapat membatasi
akses ke perangkat lunak atau datanya untuk pengguna yang berwenang.
Ancaman-ancaman ini, tentu saja, saling bergantung. Jika serangan membuat sistem
tidak tersedia, maka Anda tidak akan dapat memperbarui informasi yang berubah dengan
waktu. Ini berarti bahwa integritas sistem dapat dikompromikan. Jika
serangan berhasil dan integritas sistem terganggu, maka mungkin ada
diturunkan untuk memperbaiki masalah. Oleh karena itu, ketersediaan sistem
berkurang.
Dalam praktiknya, sebagian besar kerentanan dalam sistem sosioteknik diakibatkan oleh
kegagalan manusia daripada masalah teknis. Orang-orang memilih kata sandi yang mudah ditebak atau ditulis
11.4 Keamanan 305 _
menurunkan kata sandi mereka di tempat-tempat di mana mereka dapat ditemukan.

Administrator sistem membuat kesalahan dalam mengatur kontrol akses atau file konfigurasi
dan pengguna tidak menginstal atau menggunakan perangkat lunak perlindungan. Namun,
seperti yang saya bahas di Bagian 10.5, kita harus sangat berhati-hati saat mengklasifikasikan
masalah sebagai kesalahan pengguna. Masalah manusia sering kali mencerminkan keputusan
desain sistem yang buruk yang memerlukan, misalnya, perubahan sandi yang sering (sehingga
pengguna menuliskan sandinya) atau mekanisme konfigurasi yang rumit.
Kontrol yang mungkin Anda terapkan untuk meningkatkan keamanan sistem dibandingkan
ble untuk mereka untuk keandalan dan keamanan:
1. Penghindaran kerentanan Kontrol yang dimaksudkan untuk memastikan bahwa serangan

tidak berhasil. Strategi di sini adalah merancang sistem sehingga masalah keamanan
dapat dihindari. Misalnya, sistem militer yang sensitif tidak terhubung ke jaringan publik
sehingga akses eksternal tidak mungkin. Anda juga harus menganggap enkripsi sebagai
kontrol berdasarkan penghindaran. Setiap akses tidak sah ke data terenkripsi berarti tidak
dapat dibaca oleh penyerang. Dalam praktiknya, sangat mahal dan memakan waktu untuk
memecahkan enkripsi yang kuat.
2. Deteksi serangan dan netralisasi Kontrol yang dimaksudkan untuk mendeteksi dan menolak
serangan. Kontrol ini melibatkan termasuk fungsionalitas dalam sistem yang memantau
operasinya dan memeriksa pola aktivitas yang tidak biasa. Jika ini terdeteksi, maka
tindakan dapat diambil, seperti mematikan bagian dari sistem, membatasi akses ke
pengguna tertentu, dll.
3. Pembatasan eksposur dan pemulihan Kontrol yang mendukung pemulihan dari masalah.
Ini dapat berkisar dari strategi pencadangan otomatis dan 'pencerminan' informasi hingga
polis asuransi yang menutupi biaya yang terkait dengan serangan yang berhasil pada
sistem.
Tanpa tingkat keamanan yang wajar, kami tidak dapat yakin dengan ketersediaan, keandalan,
dan keamanan sistem. Metode untuk sertifikasi ketersediaan, keandalan, dan keamanan
mengasumsikan bahwa perangkat lunak operasional sama dengan perangkat lunak yang
awalnya diinstal. Jika sistem telah diserang dan perangkat lunak telah disusupi dalam beberapa
cara (misalnya, jika perangkat lunak telah dimodifikasi untuk memasukkan worm), maka
argumen keandalan dan keamanan tidak lagi berlaku.
Kesalahan dalam pengembangan sistem dapat menyebabkan celah keamanan. Jika sistem
tidak merespons input yang tidak diharapkan atau jika batas array tidak dicentang, penyerang
dapat memanfaatkan kelemahan ini untuk mendapatkan akses ke sistem. Insiden keamanan
utama seperti worm Internet asli (Spafford, 1989) dan worm Code Red lebih dari 10 tahun
kemudian (Berghel, 2001) mengambil keuntungan dari kerentanan yang sama. Program dalam
C# tidak menyertakan pemeriksaan terikat array, sehingga dimungkinkan untuk menimpa
bagian memori dengan kode yang memungkinkan akses tidak sah ke sistem.
POIN KUNCI
Kegagalan sistem komputer kritis dapat menyebabkan kerugian ekonomi yang besar, kehilangan informasi yang serius,
kerusakan fisik, atau ancaman terhadap kehidupan manusia.
Keandalan sistem komputer adalah properti sistem yang mencerminkan tingkat kepercayaan pengguna pada sistem. Dimensi
ketergantungan yang paling penting adalah ketersediaan, keandalan, keselamatan, dan keamanan.
Ketersediaan sistem adalah probabilitas bahwa sistem akan dapat memberikan layanan kepada penggunanya ketika diminta
untuk melakukannya. Keandalan adalah probabilitas bahwa layanan sistem akan disampaikan seperti yang ditentukan.
Keandalan yang dirasakan terkait dengan kemungkinan kesalahan yang terjadi dalam penggunaan operasional.
Sebuah program mungkin mengandung kesalahan yang diketahui tetapi mungkin masih dapat diandalkan oleh penggunanya.
Mereka mungkin tidak pernah menggunakan fitur sistem yang terpengaruh oleh kesalahan.
Keamanan suatu sistem adalah atribut sistem yang mencerminkan kemampuan sistem untuk beroperasi, secara
normal atau tidak normal, tanpa melukai orang atau merusak lingkungan.
Keamanan mencerminkan kemampuan sistem untuk melindungi dirinya dari serangan eksternal. Kegagalan keamanan
dapat menyebabkan hilangnya ketersediaan, kerusakan pada sistem atau datanya, atau kebocoran informasi
kepada orang yang tidak berwenang.
Tanpa tingkat keamanan yang wajar, ketersediaan, keandalan, dan keamanan sistem dapat terganggu jika serangan
eksternal merusak sistem. Jika suatu sistem tidak dapat diandalkan, sulit untuk memastikan keselamatan atau keamanan
sistem, karena dapat dikompromikan oleh kegagalan sistem.
BACAAN LEBIH LANJUT
'Evolusi jaminan informasi'. Artikel luar biasa yang membahas perlunya melindungi informasi penting dalam organisasi dari
kecelakaan dan serangan. (R. Cummings, IEEE Computer, 35 (12), Desember 2002.) http://dx.doi.org/10.1109/MC.2002.1106181.
'Merancang Sistem Komputer Kritis Keselamatan'. Ini adalah pengantar yang baik untuk bidang sistem kritis keselamatan,
yang membahas konsep dasar bahaya dan risiko. Lebih mudah diakses daripada buku Dunn tentang sistem kritis keselamatan.
(WR Dunn, IEEE Computer, 36 (11), November 2003.) http://dx.doi.org/10.1109/MC.2003.1244533.
Rahasia dan Kebohongan: Keamanan Digital di Dunia Jaringan. Buku yang sangat bagus dan sangat mudah dibaca
tentang keamanan komputer yang mendekati subjek dari perspektif sosioteknik. Kolom Schneier tentang masalah keamanan
secara umum (URL di bawah) juga sangat bagus. (B. Schneier, John Wiley & Sons, 2004.) http://www.schneier.com/essays.html.
Bab 11 Latihan 307
LATIHAN
11.1. Sarankan enam alasan mengapa ketergantungan perangkat lunak penting di sebagian besar sosioteknik
sistem.
11.2. Apa dimensi terpenting dari ketergantungan sistem?
11.3. Mengapa biaya untuk memastikan ketergantungan meningkat secara eksponensial ketika persyaratan
keandalan meningkat?
11.4. Berikan alasan untuk jawaban Anda, sarankan atribut ketergantungan mana yang paling mungkin
penting untuk sistem berikut:
Server Internet yang disediakan oleh ISP dengan ribuan pelanggan
Pisau bedah yang dikendalikan komputer yang digunakan dalam operasi lubang kunci
Sistem kontrol arah yang digunakan dalam kendaraan peluncuran satelit
Sistem manajemen keuangan pribadi berbasis Internet
11.5. Identifikasi enam produk konsumen yang kemungkinan besar dikendalikan oleh perangkat lunak yang kritis terhadap keselamatan
sistem.
11.6. Keandalan dan keamanan terkait tetapi atribut ketergantungan yang berbeda. Jelaskan perbedaan terpenting
antara atribut-atribut ini dan jelaskan mengapa sistem yang andal bisa menjadi tidak aman dan sebaliknya.
11.7. Dalam sistem medis yang dirancang untuk menghantarkan radiasi untuk mengobati tumor, sarankan satu bahaya
yang mungkin timbul dan usulkan satu fitur perangkat lunak yang dapat digunakan untuk memastikan bahwa bahaya
yang teridentifikasi tidak mengakibatkan kecelakaan.
11.8. Dalam istilah keamanan komputer, jelaskan perbedaan antara serangan dan ancaman.
11.9. Dengan menggunakan MHC-PMS sebagai contoh, identifikasi tiga ancaman terhadap sistem ini (selain ancaman
yang ditunjukkan pada Gambar 11.8). Sarankan kontrol yang mungkin diterapkan untuk mengurangi kemungkinan
serangan yang berhasil berdasarkan ancaman ini.
11.10. Sebagai ahli dalam keamanan komputer, Anda telah didekati oleh organisasi yang
kampanye untuk hak-hak korban penyiksaan dan telah diminta untuk membantu organisasi mendapatkan
akses tidak sah ke sistem komputer perusahaan Amerika. Ini akan membantu mereka mengkonfirmasi atau
menyangkal bahwa perusahaan ini menjual peralatan yang digunakan secara langsung dalam penyiksaan
tahanan politik. Diskusikan dilema etis yang ditimbulkan oleh permintaan ini dan bagaimana Anda akan bereaksi
terhadap permintaan ini.
REFERENSI
Adams, EN (1984). 'Mengoptimalkan layanan pencegahan produk perangkat lunak'. IBM J. Res & Dev., 28 (1), 2–14.
Berghel, H. (2001). 'Kode Cacing Merah'. Kom. ACM, 44 (12), 15–19.
Boehm, BW, McClean, RL dan Urfig, DB (1975). 'Beberapa pengalaman dengan bantuan otomatis untuk desain perangkat
lunak skala besar yang andal'. IEEE Trans. tentang Rekayasa Perangkat Lunak., SE-1 (1), 125–33.
Ellison, R., Linger, R., Lipson, H., Mead, N. dan Moore, A. (2002). 'Yayasan Rekayasa Sistem yang Dapat Bertahan'. Crosstalk:
Jurnal Rekayasa Perangkat Lunak Pertahanan, 12, 10-15.
Ellison, RJ, Fisher, DA, Berlama-lama, RC, Lipson, HF, Longstaff, TA dan Mead, NR (1999a).
'Kelangsungan Hidup: Melindungi Sistem Kritis Anda'. Komputasi Internet IEEE, 3 (6), 55–63.
Ellison, RJ, Linger, RC, Longstaff, T. dan Mead, NR (1999b). 'Analisis Sistem Jaringan yang Bertahan Hidup: Studi
Kasus'. Perangkat Lunak IEEE, 16 (4), 70–7.
Endres, A. (1975). 'Analisis kesalahan dan penyebabnya dalam program sistem'. IEEE Trans. pada Rekayasa
Perangkat Lunak., SE-1 (2), 140–9.
Laprie, J.-C. (1995). 'Komputasi yang Dapat Diandalkan: Konsep, Batas, Tantangan'. FTCS- 25: Simposium IEEE ke-25
tentang Komputasi Toleran Kesalahan, Pasadena, California: IEEE Press.
Littlewood, B. (1990). 'Model Pertumbuhan Keandalan Perangkat Lunak'. Dalam Buku Pegangan Keandalan Perangkat
Lunak. Benteng, P. (ed.). Amsterdam: Elsevier. 401–412.
Lutz, RR (1993). 'Menganalisis Kesalahan Persyaratan Perangkat Lunak dalam Sistem Tertanam Kritis Keamanan'.
RE'93, San Diego, California: IEEE.
Mills, HD, Dyer, M. dan Linger, R. (1987). 'Rekayasa Perangkat Lunak Cleanroom'. Perangkat Lunak IEEE, 4 (5), 19–25.
Nakajo, T. dan Kume, H. (1991). 'Analisis Sejarah Kasus Hubungan Penyebab Kesalahan Perangkat Lunak'.
IEEE Trans. pada Software Eng., 18 (8), 830–8.
Perrow, C. (1984). Kecelakaan Normal: Hidup dengan Teknologi Berisiko Tinggi. New York: Buku Dasar.
Pfleeger, CP dan Pfleeger, SL (2007). Keamanan dalam Komputasi, edisi ke-4. Boston: Addison Wesley.
Spafford, E. (1989). 'Cacing Internet: Krisis dan Akibat'. Kom. ACM, 32 (6), 678–87.
12
Keandalan dan
spesifikasi keamanan
Tujuan
Tujuan dari bab ini adalah untuk menjelaskan bagaimana menentukan ketergantungan
fungsional dan non-fungsional dan persyaratan keamanan. Setelah Anda membaca bab ini,
Anda akan:
memahami bagaimana pendekatan berbasis risiko dapat digunakan untuk mengidentifikasi

dan menganalisis persyaratan keselamatan, keandalan, dan keamanan;
memahami bagaimana pohon kesalahan dapat digunakan untuk membantu menganalisis risiko
dan memperoleh persyaratan keselamatan;
telah diperkenalkan ke metrik untuk spesifikasi keandalan dan bagaimana ini digunakan
untuk menentukan persyaratan keandalan yang terukur ;
mengetahui berbagai jenis persyaratan keamanan yang mungkin diperlukan dalam sistem
yang kompleks;
menyadari keuntungan dan kerugian menggunakan spesifikasi matematis formal

dari suatu sistem.
Isi
12.1 Spesifikasi persyaratan berbasis risiko 12.2
Spesifikasi keselamatan 12.3 Spesifikasi keandalan
12.4 Spesifikasi keamanan 12.5 Spesifikasi formal
310 Bab 12 Keandalan dan spesifikasi keamanan
Pada bulan September 1993, sebuah pesawat mendarat di bandara Warsawa di Polandia
selama badai petir. Selama sembilan detik setelah mendarat, rem pada pengereman yang dikendalikan komputer
sistem tidak bekerja. Sistem pengereman tidak mengenali bahwa pesawat telah
mendarat dan berasumsi bahwa pesawat masih mengudara. Fitur keselamatan pada pesawat
udara telah menghentikan penyebaran sistem dorong terbalik, yang memperlambat
pesawat, karena ini bisa berbahaya jika pesawat berada di udara. Pesawat lari dari
ujung landasan pacu, menabrak tepian tanah, dan terbakar.
Penyelidikan kecelakaan menunjukkan bahwa perangkat lunak sistem pengereman telah
beroperasi sesuai dengan spesifikasinya. Tidak ada kesalahan dalam program. Namun,
spesifikasi perangkat lunak tidak lengkap dan tidak memperhitungkan situasi langka, yang
muncul dalam kasus ini. Perangkat lunak berfungsi tetapi sistem gagal.
Hal ini menggambarkan bahwa ketergantungan sistem tidak hanya bergantung pada
rekayasa yang baik. Ini juga membutuhkan perhatian terhadap detail ketika persyaratan sistem diturunkan dan
penyertaan persyaratan perangkat lunak khusus yang diarahkan untuk memastikan:
keandalan dan keamanan suatu sistem. Persyaratan ketergantungan dan keamanan tersebut
terdiri dari dua jenis:
1. Persyaratan fungsional, yang menentukan fasilitas pemeriksaan dan pemulihan yang

harus disertakan dalam sistem dan fitur yang memberikan perlindungan terhadap
kegagalan sistem dan serangan eksternal.
2. Persyaratan non-fungsional, yang menentukan keandalan yang diperlukan dan kemampuan

ketersediaan sistem.
Titik awal untuk menghasilkan ketergantungan fungsional dan persyaratan keamanan

sering kali adalah aturan, kebijakan, atau regulasi bisnis atau domain tingkat tinggi. Ini adalah
persyaratan tingkat tinggi yang mungkin paling tepat digambarkan sebagai persyaratan 'tidak boleh'.
Sebaliknya, dengan persyaratan fungsional normal yang menentukan apa yang harus dilakukan sistem
lakukan, persyaratan 'tidak boleh' menentukan perilaku sistem yang tidak dapat diterima. Contoh
persyaratan 'tidak boleh' adalah:
“Sistem tidak akan mengizinkan pengguna untuk mengubah izin akses pada file apa pun yang
tidak mereka ciptakan.” (keamanan)
“Sistem tidak akan mengizinkan mode dorong mundur untuk dipilih ketika pesawat berada
dalam penerbangan." (keamanan)
“Sistem tidak akan mengizinkan aktivasi simultan lebih dari tiga alarm
sinyal.” (keamanan)
Persyaratan 'tidak boleh' ini tidak dapat diterapkan secara langsung tetapi harus
didekomposisi menjadi kebutuhan fungsional perangkat lunak yang lebih spesifik. Atau, mereka
dapat diimplementasikan melalui keputusan desain sistem seperti keputusan untuk menggunakan
jenis peralatan tertentu dalam sistem.
12.1 Spesifikasi persyaratan berbasis risiko 311
Mempertaruhkan Mempertaruhkan
Analisis resiko Pengurangan Risiko

Identifikasi Penguraian
Mempertaruhkan Mempertaruhkan Penyebab utama Keteguhan

Gambar 12.1 Spesifikasi Keterangan Penilaian Analisis Persyaratan
berbasis risiko
12.1 Spesifikasi persyaratan berbasis risiko
Keandalan dan persyaratan keamanan dapat dianggap sebagai persyaratan perlindungan. Ini
menentukan bagaimana sistem harus melindungi dirinya dari kesalahan internal, stop
kegagalan sistem yang menyebabkan kerusakan pada lingkungannya, menghentikan kecelakaan atau serangan dari
lingkungan sistem merusak sistem, dan memfasilitasi pemulihan di
peristiwa kegagalan. Untuk menemukan persyaratan perlindungan ini, Anda perlu memahami
risiko terhadap sistem dan lingkungannya. Pendekatan berbasis risiko untuk
spesifikasi persyaratan memperhitungkan kejadian berbahaya yang mungkin
terjadi, probabilitas bahwa ini benar-benar akan terjadi, probabilitas kerusakan
akan dihasilkan dari peristiwa tersebut, dan tingkat kerusakan yang ditimbulkan. Keamanan dan
persyaratan ketergantungan kemudian dapat ditetapkan, berdasarkan analisis kemungkinan
penyebab kejadian berbahaya.
Spesifikasi berbasis risiko adalah pendekatan yang telah banyak digunakan oleh keselamatan dan
pengembang sistem yang kritis terhadap keamanan. Ini berfokus pada peristiwa-peristiwa yang dapat menyebabkan
sebagian besar kerusakan atau yang mungkin sering terjadi. Peristiwa yang hanya memiliki
konsekuensi kecil atau sangat jarang dapat diabaikan. Dalam sistem yang kritis terhadap keselamatan,
risiko terkait dengan bahaya yang dapat mengakibatkan kecelakaan; dalam sistem yang kritis
terhadap keamanan, risiko berasal dari serangan orang dalam dan orang luar pada sistem yang dimaksudkan
untuk mengeksploitasi kemungkinan kerentanan.
Proses spesifikasi berbasis risiko umum (Gambar 12.1) melibatkan pemahaman

risiko yang dihadapi oleh sistem, menemukan akar penyebabnya, dan menghasilkan
persyaratan untuk mengelola risiko ini. Tahapan dalam proses ini adalah:
1. Identifikasi risiko Potensi risiko terhadap sistem diidentifikasi. Ini adalah

tergantung pada lingkungan di mana sistem akan digunakan. Risiko mungkin
timbul dari interaksi antara sistem dan kondisi langka dalam pengoperasiannya
lingkungan. Kecelakaan Warsawa yang saya bahas sebelumnya terjadi ketika
crosswinds yang dihasilkan selama badai petir menyebabkan pesawat miring sehingga
(tidak biasa) itu mendarat di satu roda daripada dua roda.
2. Analisis dan klasifikasi risiko Setiap risiko dipertimbangkan secara terpisah. Mereka itu
berpotensi serius dan tidak masuk akal dipilih untuk analisis lebih lanjut.
Pada tahap ini, risiko dapat dihilangkan karena tidak mungkin muncul atau karena tidak
dapat dideteksi oleh perangkat lunak (misalnya, reaksi alergi terhadap sensor dalam sistem
pompa insulin).
3. Dekomposisi Risiko Setiap risiko dianalisis untuk menemukan akar penyebab potensial dari
risiko tersebut. Akar penyebab adalah alasan mengapa suatu sistem mungkin gagal.
Mereka mungkin kesalahan perangkat lunak atau perangkat keras atau kerentanan bawaan
yang dihasilkan dari keputusan desain sistem.
4. Pengurangan risiko Proposal untuk cara-cara di mana risiko yang teridentifikasi dapat
dikurangi atau dihilangkan dibuat. Ini berkontribusi pada persyaratan ketergantungan
sistem yang menentukan pertahanan terhadap risiko dan bagaimana risiko akan dikelola.
Untuk sistem yang besar, analisis risiko dapat disusun menjadi beberapa fase (Leveson, 1995),
di mana setiap fase mempertimbangkan berbagai jenis risiko:
1. Analisis risiko awal, di mana risiko utama dari lingkungan sistem diidentifikasi. Ini tidak
tergantung pada teknologi yang digunakan untuk pengembangan sistem. Tujuan dari
analisis risiko awal adalah untuk mengembangkan satu set awal persyaratan keamanan
dan ketergantungan untuk sistem.
2. Analisis risiko siklus hidup, yang terjadi selama pengembangan sistem dan yang sebagian
besar berkaitan dengan risiko yang muncul dari keputusan desain sistem.
Teknologi dan arsitektur sistem yang berbeda memiliki risiko terkaitnya sendiri. Pada
tahap ini, Anda harus memperluas persyaratan untuk melindungi dari risiko ini.
3. Analisis risiko operasional, yang berkaitan dengan antarmuka pengguna sistem dan risiko
dari kesalahan operator. Sekali lagi, setelah keputusan dibuat pada desain antarmuka
pengguna, persyaratan perlindungan lebih lanjut mungkin harus ditambahkan.
Fase-fase ini diperlukan karena tidak mungkin membuat semua keputusan ketergantungan
dan keamanan tanpa informasi lengkap tentang implementasi sistem.
Persyaratan keamanan dan ketergantungan sangat dipengaruhi oleh pilihan teknologi dan
keputusan desain. Pemeriksaan sistem mungkin harus disertakan untuk memastikan bahwa
komponen pihak ketiga telah beroperasi dengan benar. Persyaratan keamanan mungkin harus
dimodifikasi karena bertentangan dengan fitur keamanan yang disediakan oleh sistem siap
pakai.
Misalnya, persyaratan keamanan mungkin bahwa pengguna harus mengidentifikasi diri
mereka ke sistem menggunakan frasa sandi daripada kata sandi. Frasa pass dianggap lebih
aman daripada kata sandi. Mereka lebih sulit bagi penyerang untuk menebak atau menemukan
perlindungan menggunakan sistem peretasan kata sandi otomatis. Namun, jika keputusan
dibuat untuk menggunakan sistem yang ada yang hanya mendukung otentikasi berbasis kata
sandi, maka persyaratan keamanan ini tidak dapat didukung. Kemudian mungkin perlu untuk
memasukkan fungsionalitas tambahan dalam sistem untuk mengimbangi peningkatan risiko
penggunaan kata sandi daripada frasa sandi.
12.2 Spesifikasi keselamatan 313
Standar IEC untuk manajemen keselamatan
IEC (International Electrotechnical Commission) telah menetapkan standar untuk manajemen keselamatan
untuk sistem proteksi (yaitu, sistem yang dimaksudkan untuk memicu pengamanan ketika beberapa situasi berbahaya muncul).
Contoh sistem proteksi adalah sistem yang secara otomatis menghentikan kereta api jika melewati sinyal merah.
Standar ini mencakup panduan ekstensif tentang proses spesifikasi keselamatan.
http://www.SoftwareEngineering-9.com/Web/SafetyLifeCycle/
12.2 Spesifikasi keselamatan
Sistem kritis keselamatan adalah sistem di mana kegagalan dapat mempengaruhi lingkungan
sistem dan menyebabkan cedera atau kematian pada orang-orang di lingkungan itu. Perhatian
utama dari spesifikasi keselamatan adalah untuk mengidentifikasi persyaratan yang akan
meminimalkan kemungkinan kegagalan sistem tersebut akan terjadi. Persyaratan keselamatan
terutama persyaratan perlindungan dan tidak berkaitan dengan operasi sistem normal. Mereka
mungkin menentukan bahwa sistem harus dimatikan agar keamanan tetap terjaga. Dalam
menurunkan persyaratan keselamatan, karena itu Anda perlu menemukan keseimbangan yang
dapat diterima antara keselamatan dan fungsionalitas dan menghindari perlindungan yang
berlebihan. Tidak ada gunanya membangun sistem yang sangat aman jika tidak beroperasi dengan cara yang hemat bi
Ingat dari diskusi di Bab 10 bahwa sistem kritis keselamatan menggunakan terminologi
khusus di mana bahaya adalah sesuatu yang dapat (tetapi tidak perlu) mengakibatkan
kematian atau cedera pada seseorang, dan risiko adalah kemungkinan bahwa sistem akan
memasuki keadaan berbahaya. Oleh karena itu spesifikasi keselamatan biasanya difokuskan
pada bahaya yang mungkin timbul dalam situasi tertentu, dan kejadian yang dapat menyebabkan bahaya tersebut.
Kegiatan dalam proses spesifikasi berbasis risiko umum, ditunjukkan pada Gambar 12.1,
memetakan ke proses spesifikasi keselamatan sebagai berikut:
1. Identifikasi risiko Dalam spesifikasi keselamatan, ini adalah proses identifikasi bahaya yang
mengidentifikasi bahaya yang dapat mengancam sistem.
2. Analisis risiko Ini adalah proses penilaian bahaya untuk memutuskan bahaya mana yang
paling berbahaya dan/atau paling mungkin terjadi. Ini harus diprioritaskan ketika
menurunkan persyaratan keselamatan.
3. Dekomposisi Risiko Proses ini berkaitan dengan penemuan kejadian yang dapat
menyebabkan terjadinya bahaya. Dalam spesifikasi keselamatan, proses ini dikenal
sebagai analisis bahaya.
4. Pengurangan risiko Proses ini didasarkan pada hasil analisis bahaya dan mengarah pada
identifikasi persyaratan keselamatan. Ini mungkin berkaitan dengan memastikan bahwa
bahaya tidak muncul atau menyebabkan kecelakaan atau bahwa jika kecelakaan memang
terjadi, kerusakan terkait diminimalkan.
12.2.1 Identifikasi bahaya
Dalam sistem kritis keselamatan, risiko utama berasal dari bahaya yang dapat menyebabkan
kecelakaan. Anda dapat mengatasi masalah identifikasi bahaya dengan mempertimbangkan
berbagai jenis bahaya, seperti bahaya fisik, bahaya listrik, bahaya biologis, bahaya radiasi,
bahaya kegagalan servis, dan sebagainya. Masing-masing kelas ini kemudian dapat dianalisis
untuk menemukan bahaya spesifik yang dapat terjadi. Kemungkinan kombinasi bahaya yang
berpotensi berbahaya juga harus diidentifikasi.
Sistem pompa insulin yang saya gunakan sebagai contoh pada bab-bab sebelumnya
adalah sistem yang kritis terhadap keselamatan, karena kegagalan dapat menyebabkan
cedera atau bahkan kematian pada pengguna sistem. Kecelakaan yang mungkin terjadi saat
menggunakan mesin ini termasuk pengguna yang menderita akibat jangka panjang dari
kontrol gula darah yang buruk (masalah mata, jantung, dan ginjal); disfungsi kognitif sebagai
akibat dari kadar gula darah rendah; atau terjadinya beberapa kondisi medis lainnya, seperti reaksi alergi.
Beberapa bahaya dalam sistem pompa insulin adalah:
• perhitungan overdosis insulin (kegagalan layanan);
• perhitungan dosis insulin (kegagalan layanan);
• kegagalan sistem pemantauan perangkat keras (kegagalan layanan);

•
kegagalan daya karena baterai habis (listrik);
• gangguan listrik dengan peralatan medis lainnya seperti alat pacu jantung
(listrik);
•
kontak sensor dan aktuator yang buruk disebabkan oleh pemasangan yang salah (fisik);
• bagian-bagian mesin yang putus di tubuh pasien (fisik);
• infeksi yang disebabkan oleh masuknya mesin (biologis);
• reaksi alergi terhadap bahan atau insulin yang digunakan dalam mesin (biologis).
Insinyur berpengalaman, bekerja dengan pakar domain dan penasihat keselamatan

profesional, mengidentifikasi bahaya dari pengalaman sebelumnya dan dari analisis domain
aplikasi. Teknik kerja kelompok seperti brainstorming dapat digunakan, di mana sekelompok
orang bertukar ide. Untuk sistem pompa insulin, orang-orang yang mungkin terlibat termasuk
dokter, fisikawan medis, dan insinyur serta perancang perangkat lunak.
Bahaya terkait perangkat lunak biasanya berkaitan dengan kegagalan untuk memberikan
layanan sistem, atau dengan kegagalan sistem pemantauan dan perlindungan. Sistem
pemantauan dan perlindungan disertakan dalam perangkat untuk mendeteksi kondisi, seperti
tingkat daya baterai rendah, yang dapat menyebabkan kegagalan perangkat.
12.2.2 Penilaian bahaya
Proses penilaian bahaya berfokus pada pemahaman kemungkinan bahwa suatu bahaya akan
terjadi dan konsekuensinya jika kecelakaan atau insiden yang terkait dengan bahaya itu harus
terjadi. Anda perlu membuat analisis ini untuk memahami apakah suatu bahaya
Wilayah yang Tidak Dapat Diterima

Risiko Tidak Dapat Ditoleransi
ALARP Risiko Ditoleransi Hanya jika

Pengurangan Risiko Tidak Praktis
Wilayah
atau Terlalu Mahal
Dapat diterima
Wilayah
Gambar 12.2
Segitiga risiko Risiko yang Dapat Diabaikan
merupakan ancaman serius bagi sistem atau lingkungan. Analisis juga memberikan dasar
untuk memutuskan bagaimana mengelola risiko yang terkait dengan bahaya.
Untuk setiap bahaya, hasil dari proses analisis dan klasifikasi adalah pernyataan
akseptabilitas. Hal ini dinyatakan dalam istilah risiko, dimana risiko memperhitungkan
kemungkinan terjadinya suatu kecelakaan dan akibat-akibatnya. Ada tiga ego kucing risiko
yang dapat Anda gunakan dalam penilaian bahaya:
1. Risiko yang tidak dapat ditoleransi dalam sistem kritis keselamatan adalah risiko yang mengancam kehidupan manusia.
Sistem harus dirancang sedemikian rupa sehingga bahaya tersebut tidak dapat
muncul atau, jika terjadi, fitur dalam sistem akan memastikan bahwa bahaya tersebut
terdeteksi sebelum menyebabkan kecelakaan. Dalam kasus pompa insulin, risiko yang
tidak dapat ditoleransi adalah pemberian insulin yang berlebihan.
2. Risiko serendah-rendahnya (ALARP) adalah risiko yang memiliki konsekuensi yang

kurang serius atau yang serius tetapi memiliki kemungkinan kejadian yang sangat
rendah. Sistem harus dirancang sedemikian rupa sehingga kemungkinan kecelakaan
yang timbul karena bahaya diminimalkan, dengan memperhatikan pertimbangan lain seperti biaya dan pengiri
Risiko ALARP untuk pompa insulin mungkin adalah kegagalan sistem pemantauan
perangkat keras. Konsekuensi dari ini adalah, paling buruk, kekurangan dosis insulin jangka pendek.
Ini adalah situasi yang tidak akan menyebabkan kecelakaan serius.
3. Risiko yang dapat diterima adalah risiko di mana kecelakaan terkait biasanya
mengakibatkan kerusakan kecil. Perancang sistem harus mengambil semua langkah
yang mungkin untuk mengurangi risiko yang 'dapat diterima', selama ini tidak
meningkatkan biaya, waktu pengiriman, atau atribut sistem non-fungsional lainnya.
Risiko yang dapat diterima dalam kasus pompa insulin mungkin adalah risiko reaksi
alergi yang timbul pada pengguna. Ini biasanya hanya menyebabkan iritasi kulit
ringan. Tidak ada gunanya menggunakan bahan khusus yang lebih mahal di perangkat untuk mengurangi risi
Gambar 12.2 (Brazendale dan Bell, 1994), dikembangkan untuk sistem kritis keselamatan,
menunjukkan ketiga wilayah ini. Bentuk diagram mencerminkan biaya untuk memastikan
risiko tidak mengakibatkan insiden atau kecelakaan. Biaya desain sistem untuk mengatasinya
Bahaya yang teridentifikasi Probabilitas bahaya Tingkat keparahan kecelakaan Perkiraan risiko Keberterimaan
1. Overdosis insulin Sedang Tinggi Tinggi Tak tertahankan
komputasi
2. Dosis insulin yang kurang Sedang Rendah Rendah Dapat diterima

komputasi
3. Kegagalan perangkat keras Sedang Sedang Rendah ALARP
sistem pemantauan
4. Kegagalan daya Tinggi Rendah Rendah Dapat diterima
5. Mesin salah dipasang Tinggi Tinggi Tinggi Tak tertahankan
6. Mesin rusak Rendah Tinggi Sedang ALARP
pasien
7. Mesin menyebabkan infeksi Medium Sedang Sedang ALARP
8. Gangguan listrik Rendah Tinggi Sedang ALARP
9. Reaksi alergi Rendah Rendah Rendah Dapat diterima
risiko ditunjukkan oleh lebar segitiga. Biaya tertinggi dikeluarkan oleh

Gambar 12.3 Risiko
klasifikasi untuk risiko di bagian atas diagram, biaya terendah dengan risiko di puncak segitiga.
pompa insulin Batas antar wilayah pada Gambar 12.2 tidak bersifat teknis melainkan
bergantung pada faktor sosial dan politik. Seiring waktu, masyarakat menjadi lebih menghindari risiko
sehingga batas-batas telah bergerak ke bawah. Meskipun biaya keuangan dari
menerima risiko dan membayar setiap kecelakaan yang diakibatkannya mungkin lebih kecil daripada biayanya
pencegahan kecelakaan, opini publik mungkin menuntut agar uang dibelanjakan untuk mengurangi
kemungkinan kecelakaan sistem, sehingga menimbulkan biaya tambahan.
Misalnya, mungkin lebih murah bagi perusahaan untuk membersihkan polusi di tempat yang langka
kesempatan itu terjadi, daripada memasang sistem untuk pencegahan polusi. Namun,
karena publik dan pers tidak akan mentolerir kecelakaan seperti itu, membersihkan
kerusakan daripada mencegah kecelakaan tidak lagi dapat diterima. Acara semacam itu
juga dapat menyebabkan reklasifikasi risiko. Misalnya, risiko yang dianggap
tidak mungkin (dan karenanya di wilayah ALARP) dapat direklasifikasi sebagai tidak dapat ditoleransi
karena peristiwa, seperti serangan teroris, atau kecelakaan yang pernah terjadi.
Penilaian bahaya melibatkan perkiraan probabilitas bahaya dan tingkat keparahan risiko. Ini adalah
biasanya sulit karena bahaya dan kecelakaan jarang terjadi sehingga para insinyur yang terlibat mungkin
tidak memiliki pengalaman langsung tentang insiden atau kecelakaan sebelumnya. Probabilitas dan tingkat keparahan
ditugaskan menggunakan istilah relatif seperti 'mungkin', 'tidak mungkin', dan 'langka' dan 'tinggi',
'sedang', dan 'rendah'. Hal ini hanya mungkin untuk mengukur istilah-istilah ini jika cukup kecelakaan dan
data insiden tersedia untuk analisis statistik.
Gambar 12.3 menunjukkan klasifikasi risiko untuk bahaya yang diidentifikasi sebelumnya
bagian untuk sistem pengiriman insulin. Saya telah memisahkan bahaya yang berhubungan dengan
perhitungan insulin yang salah menjadi overdosis insulin dan kekurangan insulin.
Overdosis insulin berpotensi lebih serius daripada kekurangan insulin dalam jangka pendek.
Overdosis insulin dapat mengakibatkan disfungsi kognitif, koma, dan akhirnya kematian.
Kekurangan insulin menyebabkan kadar gula darah tinggi. Dalam jangka pendek, ini
menyebabkan kelelahan tetapi tidak terlalu serius; dalam jangka panjang, bagaimanapun,
mereka dapat menyebabkan masalah jantung, ginjal, dan mata yang serius.
Bahaya 4-9 pada Gambar 12.3 tidak terkait dengan perangkat lunak, namun perangkat lunak
tetap memiliki peran dalam deteksi bahaya. Perangkat lunak pemantauan perangkat keras harus
memantau status sistem dan memperingatkan potensi masalah. Peringatan akan sering
memungkinkan bahaya dideteksi sebelum menyebabkan kecelakaan. Contoh bahaya yang
mungkin terdeteksi adalah mati listrik, yang dideteksi dengan memantau baterai, dan
penempatan mesin yang salah, yang dapat dideteksi dengan memantau sinyal dari sensor gula
darah.
Perangkat lunak pemantauan dalam sistem, tentu saja, terkait dengan keselamatan.
Kegagalan dalam mendeteksi bahaya dapat mengakibatkan kecelakaan. Jika sistem pemantauan
gagal tetapi perangkat kerasnya berfungsi dengan benar, maka ini bukan kegagalan yang
serius. Namun, jika sistem pemantauan gagal dan kegagalan perangkat keras tidak dapat
dideteksi, maka ini dapat memiliki konsekuensi yang lebih serius.
12.2.3 Analisis bahaya

Analisis bahaya adalah proses menemukan akar penyebab bahaya dalam sistem kritis
keselamatan. Tujuan Anda adalah untuk mengetahui peristiwa atau kombinasi peristiwa apa
yang dapat menyebabkan kegagalan sistem yang mengakibatkan bahaya. Untuk melakukan ini,
Anda dapat menggunakan pendekatan top-down atau bottom-up. Teknik deduktif, top-down,
yang cenderung lebih mudah digunakan, dimulai dengan bahaya dan naik dari itu ke kemungkinan kegagalan sistem.
Teknik induktif, bottom-up dimulai dengan kegagalan sistem yang diusulkan dan mengidentifikasi
bahaya apa yang mungkin timbul dari kegagalan itu.
Berbagai teknik telah diusulkan sebagai pendekatan yang mungkin untuk posisi atau
analisis dekomposisi bahaya. Ini diringkas oleh Storey (1996). Mereka termasuk ulasan dan
daftar periksa, teknik formal seperti analisis jaringan Petri (Peterson, 1981), logika formal
(Jahanian dan Mok, 1986), dan analisis pohon kesalahan (Leveson dan Stolzy, 1987; Storey,
1996). Karena saya tidak memiliki ruang untuk membahas semua teknik ini di sini, saya fokus
pada pendekatan yang banyak digunakan untuk analisis bahaya berdasarkan pohon kesalahan.
Teknik ini cukup mudah dipahami tanpa pengetahuan domain khusus.
Untuk melakukan analisis pohon kesalahan, Anda mulai dengan bahaya yang telah diidentifikasi.
Untuk setiap bahaya, Anda kemudian bekerja mundur untuk menemukan kemungkinan
penyebab bahaya itu. Anda menempatkan bahaya di akar pohon dan mengidentifikasi status
sistem yang dapat menyebabkan bahaya itu. Untuk masing-masing status ini, Anda kemudian
mengidentifikasi status sistem lebih lanjut yang dapat mengarah ke sana. Anda melanjutkan
dekomposisi ini sampai Anda mencapai akar penyebab risiko. Bahaya yang hanya dapat muncul
dari kombinasi akar penyebab biasanya lebih kecil kemungkinannya untuk menyebabkan kecelakaan daripada bahaya de
Gambar 12.4 adalah pohon kesalahan untuk bahaya terkait perangkat lunak dalam sistem
pengiriman insulin yang dapat menyebabkan pemberian dosis insulin yang salah. Dalam hal ini, saya punya
Salah
Dosis insulin
Dikelola
atau
Salah Dosis yang benar Pengiriman

Tingkat Gula Dikirim pada Sistem
diukur Waktu yang tidak tepat Kegagalan
atau atau
Sensor Gula pengatur waktu Insulin Pompa

Kegagalan Kegagalan Sinyal
Komputasi Komputasi
Kesalahan Salah Salah
atau atau
algoritma Hitung algoritma Hitung

Gambar 12.4 Kesalahan Kesalahan Kesalahan Kesalahan
Contoh pohon kesalahan
menggabungkan dosis insulin dan overdosis insulin menjadi satu bahaya, yaitu 'dosis insulin
yang diberikan salah.' Ini mengurangi jumlah pohon kesalahan yang diperlukan. Tentu saja,
ketika Anda menentukan bagaimana perangkat lunak harus bereaksi terhadap bahaya ini, Anda
harus membedakan antara kekurangan insulin dan overdosis insulin. Seperti yang telah saya
katakan, mereka tidak sama seriusnya—dalam jangka pendek, overdosis adalah bahaya yang lebih serius.
Dari Gambar 12.4, Anda dapat melihat bahwa:
1. Ada tiga kondisi yang dapat menyebabkan administrasi salah:

dosis insulin. Tingkat gula darah mungkin salah diukur sehingga kebutuhan insulin telah
dihitung dengan input yang salah. Sistem pengiriman mungkin tidak merespons dengan
benar perintah yang menentukan jumlah insulin yang akan disuntikkan. Sebagai alternatif,
dosis dapat dihitung dengan benar tetapi diberikan terlalu dini atau terlambat.
2. Cabang kiri dari pohon patahan, berkaitan dengan pengukuran kadar gula darah yang salah,
melihat bagaimana hal ini bisa terjadi. Ini bisa terjadi juga
karena sensor yang memberikan input untuk menghitung kadar gula telah gagal atau karena
penghitungan kadar gula darah yang dilakukan salah. Kadar gula dihitung dari beberapa
parameter yang diukur, seperti konduktivitas kulit. Perhitungan yang salah dapat dihasilkan
dari algoritma yang salah atau kesalahan aritmatika yang dihasilkan dari penggunaan angka
floating point.
3. Cabang pusat dari pohon berkaitan dengan masalah waktu dan menyimpulkan bahwa ini hanya
dapat dihasilkan dari kegagalan pengatur waktu sistem.
4. Cabang kanan dari pohon, berkaitan dengan kegagalan sistem pengiriman, memeriksa
kemungkinan penyebab kegagalan ini. Ini bisa diakibatkan oleh perhitungan yang salah dari
kebutuhan insulin, atau dari kegagalan untuk mengirim sinyal yang benar ke pompa yang
memberikan insulin. Sekali lagi, perhitungan yang salah dapat dihasilkan dari kegagalan
algoritma atau kesalahan aritmatika.
Pohon kesalahan juga digunakan untuk mengidentifikasi potensi masalah perangkat keras.
Pohon kesalahan perangkat keras dapat memberikan wawasan tentang persyaratan perangkat
lunak untuk mendeteksi dan, mungkin, memperbaiki masalah ini. Misalnya, dosis insulin tidak
diberikan pada frekuensi yang sangat tinggi, tidak lebih dari dua atau tiga kali per jam dan terkadang
lebih jarang dari ini. Oleh karena itu, kapasitas prosesor tersedia untuk menjalankan program
diagnostik dan pemeriksaan mandiri. Kesalahan perangkat keras seperti kesalahan sensor, pompa,
atau pengatur waktu dapat ditemukan dan peringatan dikeluarkan sebelum menimbulkan efek serius pada pasien.
12.2.4 Pengurangan risiko

Setelah risiko potensial dan akar penyebabnya telah diidentifikasi, Anda kemudian dapat
memperoleh persyaratan keselamatan yang mengelola risiko dan memastikan bahwa insiden atau
kecelakaan tidak terjadi. Ada tiga kemungkinan strategi yang dapat Anda gunakan:
1. Penghindaran bahaya Sistem dirancang sedemikian rupa sehingga bahaya tidak dapat terjadi.
2. Deteksi dan penghapusan bahaya Sistem ini dirancang agar bahaya dideteksi dan dinetralisir
sebelum menimbulkan kecelakaan.
3. Batasan kerusakan Sistem dirancang sedemikian rupa sehingga akibat dari suatu
penyok diminimalkan.
Biasanya, perancang sistem kritis menggunakan kombinasi dari pendekatan ini. Dalam sistem
yang kritis terhadap keselamatan, bahaya yang tidak dapat ditoleransi dapat ditangani dengan
meminimalkan kemungkinannya dan menambahkan sistem perlindungan yang menyediakan
cadangan keamanan. Misalnya, dalam sistem kontrol pabrik kimia, sistem akan berusaha mendeteksi
dan menghindari tekanan berlebih di dalam reaktor. Namun, mungkin juga ada sistem perlindungan
independen yang memantau tekanan dan membuka katup pelepas jika tekanan tinggi terdeteksi.
Dalam sistem pengiriman insulin, 'keadaan aman' adalah keadaan mati di mana tidak ada insulin
yang disuntikkan. Dalam waktu singkat ini bukan merupakan ancaman bagi kesehatan penderita diabetes. Untuk
SR1: Sistem tidak boleh memberikan dosis tunggal insulin yang lebih besar dari dosis maksimum yang ditentukan
untuk pengguna sistem.
SR2: Sistem tidak boleh memberikan dosis kumulatif insulin harian yang lebih besar dari dosis harian maksimum
yang ditentukan untuk pengguna sistem.
SR3: Sistem harus mencakup fasilitas diagnostik perangkat keras yang harus dijalankan setidaknya empat kali
per jam.
SR4: Sistem harus menyertakan penangan pengecualian untuk semua pengecualian yang diidentifikasi dalam
Tabel 3.
SR5: Alarm yang dapat didengar harus dibunyikan ketika ada anomali perangkat keras atau perangkat lunak yang
ditemukan dan pesan diagnostik, sebagaimana didefinisikan dalam Tabel 4, harus ditampilkan.
SR6: Jika terjadi alarm, pengiriman insulin akan ditangguhkan hingga pengguna mengatur ulang sistem dan
menghapus alarm.
kegagalan perangkat lunak yang dapat menyebabkan dosis insulin yang salah
Gambar 12.5
Contoh persyaratan dipertimbangkan, 'solusi' berikut mungkin dikembangkan:
keselamatan
1. Kesalahan aritmatika Hal ini dapat terjadi ketika perhitungan aritmatika menyebabkan
kegagalan representasi. Spesifikasi harus mengidentifikasi semua kemungkinan
kesalahan aritmatika yang mungkin terjadi dan menyatakan bahwa penangan
pengecualian harus disertakan untuk setiap kesalahan yang mungkin terjadi. Spesifikasi
harus menetapkan tindakan yang harus diambil untuk setiap kesalahan ini. Tindakan
aman default adalah mematikan sistem pengiriman dan mengaktifkan alarm peringatan.
2. Kesalahan algoritma Ini adalah situasi yang lebih sulit karena tidak ada pengecualian
program yang jelas yang harus ditangani. Jenis kesalahan ini dapat dideteksi dengan
membandingkan dosis insulin yang dibutuhkan yang dihitung dengan dosis yang
diberikan sebelumnya. Jika jauh lebih tinggi, ini mungkin berarti bahwa jumlahnya telah
dihitung secara tidak benar. Sistem juga dapat melacak urutan dosis. Setelah sejumlah
dosis di atas rata-rata telah diberikan, peringatan dapat dikeluarkan dan dosis lebih lanjut dibatasi.
Beberapa persyaratan keamanan yang dihasilkan untuk perangkat lunak pompa insulin
ditunjukkan pada Gambar 12.5. Ini adalah persyaratan pengguna dan, tentu saja, mereka
akan dinyatakan secara lebih rinci dalam spesifikasi persyaratan sistem. Pada Gambar 12.5,
referensi ke Tabel 3 dan 4 berhubungan dengan tabel yang disertakan dalam dokumen
persyaratan—tidak ditampilkan di sini.
12.3 Spesifikasi keandalan

Seperti yang saya bahas di Bab 10, keandalan keseluruhan sistem bergantung pada
keandalan perangkat keras, keandalan perangkat lunak, dan keandalan operator sistem.
Perangkat lunak sistem harus mempertimbangkan hal ini. Serta termasuk persyaratan
12.3 Spesifikasi keandalan 321
yang mengkompensasi kegagalan perangkat lunak, mungkin juga ada persyaratan keandalan terkait
untuk membantu mendeteksi dan memulihkan dari kegagalan perangkat keras dan kesalahan operator.
Keandalan berbeda dari keselamatan dan keamanan karena merupakan atribut sistem yang dapat
diukur. Artinya, dimungkinkan untuk menentukan tingkat keandalan yang diperlukan, memantau operasi
sistem dari waktu ke waktu, dan memeriksa apakah keandalan yang diperlukan telah tercapai. Misalnya,
persyaratan keandalan mungkin bahwa kegagalan sistem yang memerlukan reboot tidak boleh terjadi
lebih dari sekali per minggu. Setiap kali kegagalan seperti itu terjadi, itu dapat dicatat dan Anda dapat
memeriksa apakah tingkat keandalan yang diperlukan telah tercapai. Jika tidak, Anda dapat mengubah
persyaratan keandalan Anda atau mengirimkan permintaan perubahan untuk mengatasi masalah sistem
yang mendasarinya. Anda mungkin memutuskan untuk menerima tingkat keandalan yang lebih rendah
karena biaya mengubah sistem untuk meningkatkan keandalan atau karena memperbaiki masalah
mungkin memiliki efek samping yang merugikan, seperti kinerja atau keluaran yang lebih rendah.
Sebaliknya, keselamatan dan keamanan adalah tentang menghindari situasi yang tidak diinginkan,
daripada menentukan 'tingkat' keselamatan atau keamanan yang diinginkan. Bahkan satu situasi seperti
itu dalam masa pakai sistem mungkin tidak dapat diterima dan, jika itu terjadi, perubahan sistem harus
dilakukan. Tidak masuk akal untuk membuat pernyataan seperti 'kesalahan sistem harus mengakibatkan
kurang dari 10 cedera per tahun.' Segera setelah satu cedera terjadi, masalah sistem harus diperbaiki.
Oleh karena itu, persyaratan keandalan terdiri dari dua jenis:
1. Persyaratan non-fungsional, yang menentukan jumlah kegagalan yang dapat diterima selama
penggunaan normal sistem, atau waktu di mana sistem tidak tersedia untuk digunakan. Ini adalah
persyaratan keandalan kuantitatif.
2. Persyaratan fungsional, yang menentukan fungsi sistem dan perangkat lunak yang menghindari,
mendeteksi, atau menoleransi kesalahan dalam perangkat lunak dan dengan demikian memastikan
bahwa kesalahan ini tidak menyebabkan kegagalan sistem.
Persyaratan keandalan kuantitatif mengarah pada persyaratan sistem fungsional terkait. Untuk
mencapai beberapa tingkat keandalan yang diperlukan, persyaratan fungsional dan desain sistem harus
menentukan kesalahan yang akan dideteksi dan tindakan yang harus diambil untuk memastikan bahwa
kesalahan ini tidak menyebabkan kegagalan sistem.
Proses spesifikasi keandalan dapat didasarkan pada proses spesifikasi berbasis risiko umum yang
ditunjukkan pada Gambar 12.1:
1. Identifikasi risiko Pada tahap ini, Anda mengidentifikasi jenis kegagalan sistem yang dapat
menyebabkan kerugian ekonomi. Misalnya, sistem e-commerce mungkin tidak tersedia sehingga
pelanggan tidak dapat memesan, atau kegagalan yang merusak data mungkin memerlukan waktu
untuk memulihkan database sistem dari cadangan dan menjalankan kembali transaksi yang telah
diproses. Daftar kemungkinan jenis kegagalan, yang ditunjukkan pada Gambar 12.6, dapat
digunakan sebagai titik awal untuk identifikasi risiko.
2. Analisis risiko Ini melibatkan perkiraan biaya dan konsekuensi dari berbagai jenis kegagalan perangkat
lunak dan memilih kegagalan konsekuensi tinggi untuk analisis lebih lanjut.
Jenis kegagalan Keterangan
Kehilangan layanan Sistem tidak tersedia dan tidak dapat memberikan layanannya kepada pengguna. Anda
dapat memisahkan ini menjadi hilangnya layanan kritis dan hilangnya non-kritis
layanan, di mana konsekuensi dari kegagalan dalam layanan non-kritis
kurang dari konsekuensi kegagalan layanan kritis.
Pengiriman layanan yang salah Sistem tidak memberikan layanan dengan benar kepada pengguna. Sekali lagi, ini
dapat ditentukan dalam hal kesalahan kecil dan besar atau kesalahan dalam
penyampaian layanan kritis dan non-kritis.
Kerusakan sistem/data Kegagalan sistem menyebabkan kerusakan pada sistem itu sendiri atau sistemnya
data. Ini biasanya tetapi tidak harus bersamaan dengan yang lain
jenis kegagalan.
3. Dekomposisi risiko Pada tahap ini, Anda melakukan analisis akar penyebab masalah serius dan
Gambar 12.6 Jenis
kegagalan sistem
kemungkinan kegagalan sistem. Namun, ini mungkin tidak mungkin pada persyaratan
tahap sebagai akar penyebab mungkin tergantung pada keputusan desain sistem. Anda mungkin memiliki
untuk kembali ke aktivitas ini selama desain dan pengembangan.
4. Pengurangan risiko Pada tahap ini, Anda harus menghasilkan spesifikasi keandalan kuantitatif yang
menetapkan probabilitas yang dapat diterima dari berbagai jenis kegagalan.
Ini harus, tentu saja, memperhitungkan biaya kegagalan. Anda dapat menggunakan probabilitas
yang berbeda untuk layanan sistem yang berbeda. Anda juga dapat menghasilkan persyaratan
keandalan fungsional. Sekali lagi, ini mungkin harus menunggu hingga desain sistem
keputusan telah dibuat. Namun, seperti yang saya bahas di Bagian 12.3.2, terkadang sulit untuk
membuat spesifikasi kuantitatif. Anda mungkin hanya bisa
mengidentifikasi persyaratan keandalan fungsional.
12.3.1 Metrik keandalan

Secara umum, keandalan dapat ditentukan sebagai probabilitas bahwa kegagalan sistem akan
terjadi ketika sistem sedang digunakan dalam lingkungan operasi tertentu. Jika Anda
bersedia menerima, misalnya, bahwa 1 dari 1.000 transaksi mungkin gagal, maka Anda dapat
tentukan probabilitas kegagalan sebagai 0,001. Ini tidak berarti, tentu saja, Anda akan melihat 1
kegagalan dalam setiap 1.000 transaksi. Artinya, jika Anda mengamati N ribu transaksi,
jumlah kegagalan yang Anda amati harus sekitar N. Anda dapat memperbaiki ini untuk jenis kegagalan
yang berbeda atau untuk bagian sistem yang berbeda. Anda dapat memutuskan bahwa kritis
komponen harus memiliki probabilitas kegagalan yang lebih rendah daripada komponen nonkritis.
Ada dua metrik penting yang digunakan untuk menentukan keandalan ditambah metrik tambahan
yang digunakan untuk menentukan atribut sistem terkait ketersediaan. Itu
pilihan metrik tergantung pada jenis sistem yang sedang ditentukan dan
persyaratan domain aplikasi. Metriknya adalah:
1. Probabilitas kegagalan sesuai permintaan (POFOD) Jika Anda menggunakan metrik ini, Anda mendefinisikan
probabilitas bahwa permintaan untuk layanan dari suatu sistem akan menghasilkan suatu sistem
Ketersediaan Penjelasan
0.9 Sistem ini tersedia untuk 90% dari waktu. Artinya, dalam periode 24 jam (1.440
menit), sistem tidak akan tersedia selama 144 menit.
0,99 Dalam periode 24 jam, sistem tidak tersedia selama 14,4 menit.
0,999 Sistem tidak tersedia selama 84 detik dalam periode 24 jam.
0.9999 Sistem tidak tersedia selama 8,4 detik dalam periode 24 jam. Kira-kira, satu menit per minggu.
kegagalan. Jadi, POFOD 0,001 berarti ada kemungkinan 1/1.000 kegagalan akan terjadi
Gambar
12.7 ketika permintaan dibuat.
Spesifikasi ketersediaan
2. Tingkat terjadinya kegagalan (ROCOF) Metrik ini menetapkan kemungkinan jumlah
kegagalan sistem yang mungkin diamati relatif terhadap periode waktu tertentu
(misalnya, satu jam), atau jumlah eksekusi sistem. Pada contoh di atas, ROCOF adalah
1/1.000. Kebalikan dari ROCOF adalah mean time to failure (MTTF), yang terkadang
digunakan sebagai metrik keandalan. MTTF adalah jumlah rata-rata unit waktu antara
kegagalan sistem yang diamati. Oleh karena itu, ROCOF dari dua kegagalan per jam
menyiratkan bahwa waktu rata-rata untuk kegagalan adalah 30 menit.
3. Availability (AVAIL) Ketersediaan sistem mencerminkan kemampuannya untuk

memberikan layanan saat diminta. AVAIL adalah probabilitas bahwa suatu sistem akan
beroperasi ketika permintaan dibuat untuk layanan. Oleh karena itu, ketersediaan
0,9999, berarti bahwa rata-rata, sistem akan tersedia untuk 99,99% dari waktu operasi.
Gambar 12.7 menunjukkan apa arti tingkat ketersediaan yang berbeda dalam praktik.
POFOD harus digunakan sebagai metrik keandalan dalam situasi di mana kegagalan
sesuai permintaan dapat menyebabkan kegagalan sistem yang serius. Hal ini berlaku
terlepas dari frekuensi tuntutan. Misalnya, sistem proteksi yang memantau reaktor kimia
dan mematikan reaksi jika terjadi panas berlebih harus memiliki keandalan yang ditentukan
menggunakan POFOD. Umumnya, tuntutan pada sistem perlindungan jarang terjadi karena
sistem adalah garis pertahanan terakhir, setelah semua strategi pemulihan lainnya gagal.
Oleh karena itu POFOD 0,001 (1 kegagalan dalam 1.000 tuntutan) mungkin tampak berisiko,
tetapi jika hanya ada dua atau tiga tuntutan pada sistem dalam masa pakainya, maka Anda
mungkin tidak akan pernah melihat kegagalan sistem.
ROCOF adalah metrik yang paling tepat untuk digunakan dalam situasi di mana tuntutan
pada sistem dibuat secara teratur daripada sebentar-sebentar. Misalnya, dalam sistem
yang menangani sejumlah besar transaksi, Anda dapat menentukan ROCOF 10 kegagalan
per hari. Ini berarti Anda bersedia menerima bahwa rata-rata 10 transaksi per hari tidak akan
berhasil diselesaikan dan harus dibatalkan. Atau, Anda dapat menentukan ROCOF sebagai
jumlah kegagalan per 1.000 transaksi.
Jika waktu mutlak antara kegagalan penting, Anda dapat menentukan keandalan sebagai
waktu rata-rata antara kegagalan. Misalnya, jika Anda menentukan yang diperlukan
keandalan untuk sistem dengan transaksi panjang (seperti sistem desain berbantuan
komputer), Anda harus menentukan keandalan dengan waktu rata-rata yang lama untuk
kegagalan. MTTF harus lebih lama daripada waktu rata-rata pengguna bekerja pada modelnya
tanpa menyimpan hasilnya. Ini berarti bahwa pengguna tidak akan kehilangan pekerjaan
karena kegagalan sistem dalam satu sesi.
Untuk menilai keandalan suatu sistem, Anda harus menangkap data tentang operasinya.
Data yang diperlukan mungkin termasuk:
1. Jumlah kegagalan sistem yang diberikan sejumlah permintaan layanan sistem.

Ini digunakan untuk mengukur POFOD.
2. Waktu atau jumlah transaksi antara kegagalan sistem ditambah total waktu yang telah
berlalu atau jumlah total transaksi. Ini digunakan untuk mengukur ROCOF dan MTTF.
3. Waktu perbaikan atau restart setelah kegagalan sistem yang menyebabkan hilangnya
layanan. Ini digunakan dalam pengukuran ketersediaan. Ketersediaan tidak hanya
bergantung pada waktu antara kegagalan tetapi juga pada waktu yang dibutuhkan untuk
mengembalikan sistem ke operasi.
Satuan waktu yang dapat digunakan adalah waktu kalender atau waktu prosesor atau
satuan diskrit seperti jumlah transaksi. Dalam sistem yang menghabiskan banyak waktu
menunggu untuk menanggapi permintaan layanan, seperti sistem switching telepon, unit
waktu yang harus digunakan adalah waktu prosesor. Jika Anda menggunakan waktu kalender,
maka ini akan mencakup waktu ketika sistem tidak melakukan apa-apa.
Anda harus menggunakan waktu kalender untuk sistem yang terus beroperasi.
Sistem pemantauan, seperti sistem alarm, dan jenis sistem kontrol proses lainnya termasuk
dalam kategori ini. Sistem yang memproses transaksi seperti ATM bank atau sistem reservasi
maskapai penerbangan memiliki beban variabel yang ditempatkan pada mereka tergantung
pada waktu hari. Dalam kasus ini, satuan 'waktu' yang digunakan dapat berupa jumlah
transaksi (yaitu, ROCOF adalah jumlah transaksi yang gagal per N ribu transaksi).
12.3.2 Persyaratan keandalan non-fungsional

Persyaratan keandalan non-fungsional adalah spesifikasi kuantitatif dari keandalan dan
ketersediaan sistem yang diperlukan, dihitung menggunakan salah satu metrik yang
dijelaskan di bagian sebelumnya. Keandalan kuantitatif dan spesifikasi ketersediaan telah
digunakan selama bertahun-tahun dalam sistem kritis keselamatan tetapi jarang digunakan
dalam sistem kritis bisnis. Namun, karena semakin banyak perusahaan menuntut layanan
24/7 dari sistem mereka, kemungkinan teknik seperti itu akan semakin banyak digunakan.
Ada beberapa keuntungan dalam menurunkan spesifikasi reliabilitas kuantitatif:
1. Proses memutuskan tingkat keandalan yang diperlukan membantu memperjelas apa yang
benar-benar dibutuhkan pemangku kepentingan. Ini membantu pemangku kepentingan
memahami bahwa ada berbagai jenis kegagalan sistem, dan menjelaskan kepada mereka
bahwa tingkat keandalan yang tinggi sangat mahal untuk dicapai.
2. Ini memberikan dasar untuk menilai kapan harus berhenti menguji sistem. Anda berhenti ketika
sistem telah mencapai tingkat keandalan yang diperlukan.
3. Ini adalah sarana untuk menilai strategi desain yang berbeda yang dimaksudkan untuk meningkatkan
keandalan sistem. Anda dapat membuat penilaian tentang bagaimana setiap strategi mungkin
mengarah pada tingkat keandalan yang diperlukan.
4. Jika regulator harus menyetujui suatu sistem sebelum digunakan (misalnya, semua sistem
yang penting untuk keselamatan penerbangan di pesawat diatur), maka bukti bahwa
target keandalan yang disyaratkan telah terpenuhi penting untuk sertifikasi sistem.
Untuk menetapkan tingkat keandalan sistem yang diperlukan, Anda harus mempertimbangkan
kerugian terkait yang dapat diakibatkan oleh kegagalan sistem. Ini bukan hanya finansial
kerugian, tetapi juga hilangnya reputasi untuk bisnis. Kehilangan reputasi berarti pelanggan akan pergi
ke tempat lain. Meskipun kerugian jangka pendek dari kegagalan sistem mungkin
relatif kecil, kerugian jangka panjang mungkin jauh lebih signifikan. Misalnya, jika Anda mencoba
mengakses situs e-niaga dan ternyata tidak tersedia, Anda dapat:
coba temukan apa yang Anda inginkan di tempat lain daripada menunggu sistem tersedia. Jika ini terjadi
lebih dari sekali, Anda mungkin tidak akan berbelanja di situs itu lagi.
Masalah dengan menentukan keandalan menggunakan metrik seperti POFOD, ROCOF,
dan AVAIL memungkinkan untuk menentukan keandalan secara berlebihan sehingga menimbulkan biaya
pengembangan dan validasi yang tinggi. Alasan untuk ini adalah bahwa pemangku kepentingan sistem menemukannya
sulit untuk menerjemahkan pengalaman praktis mereka ke dalam spesifikasi kuantitatif. Mereka
mungkin berpikir bahwa POFOD 0,001 (1 kegagalan dalam 1.000 permintaan) mewakili
sistem yang tidak dapat diandalkan. Namun, seperti yang telah saya jelaskan, jika tuntutan layanan adalah
jarang, itu benar-benar mewakili tingkat keandalan yang sangat tinggi.
Jika Anda menentukan keandalan sebagai metrik, jelas penting untuk menilai bahwa:
tingkat keandalan yang disyaratkan telah tercapai. Anda melakukan penilaian ini sebagai bagian dari
pengujian sistem. Untuk menilai keandalan sistem secara statistik, Anda harus mengamati:
jumlah kegagalan. Jika Anda memiliki, misalnya, POFOD 0,0001 (1 kegagalan dalam
10.000 permintaan), maka Anda mungkin harus merancang tes yang menghasilkan 50 atau 60 ribu
tuntutan pada sistem dan di mana beberapa kegagalan diamati. Mungkin praktis
tidak mungkin untuk merancang dan mengimplementasikan jumlah tes ini. Oleh karena itu, spesifikasi
keandalan yang berlebihan menyebabkan biaya pengujian yang sangat tinggi.
Saat Anda menentukan ketersediaan sistem, Anda mungkin mengalami masalah serupa.
Meskipun tingkat ketersediaan yang sangat tinggi mungkin tampak diinginkan, sebagian besar sistem
memiliki pola permintaan yang sangat terputus-putus (misalnya, sistem bisnis sebagian besar akan digunakan
selama jam kerja normal) dan satu angka ketersediaan tidak benar-benar mencerminkan
kebutuhan pengguna. Anda membutuhkan ketersediaan tinggi ketika sistem sedang digunakan tetapi tidak di tempat lain
waktu. Tergantung, tentu saja, pada jenis sistemnya, mungkin tidak ada praktik nyata
perbedaan antara ketersediaan 0,999 dan ketersediaan 0,9999.
Masalah mendasar dengan spesifikasi berlebih adalah mungkin secara praktis
tidak mungkin untuk menunjukkan bahwa tingkat keandalan atau ketersediaan yang sangat tinggi telah
tercapai. Misalnya, katakanlah suatu sistem dimaksudkan untuk digunakan dalam aplikasi yang kritis
terhadap keselamatan dan oleh karena itu diperlukan untuk tidak pernah gagal selama masa pakai totalnya. Asumsikan bahwa
1.000 salinan sistem akan diinstal dan sistem dijalankan 1.000
kali per detik. Masa pakai sistem yang diproyeksikan adalah 10 tahun. Oleh karena itu, jumlah total
eksekusi sistem kira-kira 3*10 14. Tidak ada gunanya menetapkan bahwa tingkat terjadinya
kegagalan harus 1/1015 eksekusi (ini memungkinkan untuk beberapa faktor keamanan) karena
Anda tidak dapat menguji sistem dalam waktu lama cukup untuk memvalidasi tingkat keandalan
ini.
Oleh karena itu, organisasi harus realistis tentang apakah perlu menetapkan dan memvalidasi
tingkat keandalan yang sangat tinggi. Tingkat keandalan yang tinggi jelas dibenarkan dalam
sistem di mana operasi yang andal sangat penting, seperti sistem switching telepon, atau di mana
kegagalan sistem dapat mengakibatkan kerugian ekonomi yang besar. Mereka mungkin tidak
dibenarkan untuk banyak jenis bisnis atau sistem ilmiah. Sistem tersebut memiliki persyaratan
keandalan yang sederhana, karena biaya kegagalan hanya memproses penundaan dan mudah
serta relatif murah untuk memulihkannya.
Ada sejumlah langkah yang dapat Anda ambil untuk menghindari spesifikasi keandalan sistem
yang berlebihan:
1. Tentukan persyaratan ketersediaan dan keandalan untuk berbagai jenis kegagalan. Harus ada
kemungkinan lebih rendah dari kegagalan serius yang terjadi daripada kegagalan kecil.
2. Tentukan persyaratan ketersediaan dan keandalan untuk layanan yang berbeda secara terpisah.
Kegagalan yang mempengaruhi layanan yang paling kritis harus ditentukan sebagai
kemungkinan yang lebih kecil daripada yang hanya memiliki efek lokal. Anda dapat
memutuskan untuk membatasi spesifikasi keandalan kuantitatif ke layanan sistem yang paling kritis.
3. Putuskan apakah Anda benar-benar membutuhkan keandalan tinggi dalam sistem perangkat
lunak atau apakah tujuan ketergantungan sistem secara keseluruhan dapat dicapai dengan
cara lain. Misalnya, Anda dapat menggunakan mekanisme deteksi kesalahan untuk memeriksa
keluaran sistem dan memiliki proses untuk memperbaiki kesalahan. Maka mungkin tidak
diperlukan tingkat keandalan yang tinggi dalam sistem yang menghasilkan keluaran.
Untuk mengilustrasikan poin terakhir ini, pertimbangkan persyaratan keandalan untuk sistem
ATM bank yang mengeluarkan uang tunai dan menyediakan layanan lain kepada pelanggan. Jika
ada masalah ATM perangkat keras atau perangkat lunak, maka ini menyebabkan entri yang salah
dalam database akun pelanggan. Ini dapat dihindari dengan menetapkan tingkat keandalan
perangkat keras dan perangkat lunak yang sangat tinggi di ATM.
Namun, bank memiliki pengalaman bertahun-tahun tentang cara mengidentifikasi dan
memperbaiki transaksi akun yang salah. Mereka menggunakan metode akuntansi untuk mendeteksi
ketika ada yang salah. Sebagian besar transaksi yang gagal dapat dibatalkan begitu saja, sehingga
tidak menimbulkan kerugian bagi bank dan ketidaknyamanan pelanggan yang kecil. Bank yang menjalankan jaringan ATM
Oleh karena itu, terimalah bahwa kegagalan ATM dapat berarti bahwa sejumlah kecil transaksi
tidak benar, tetapi mereka pikir akan lebih hemat biaya untuk memperbaikinya nanti daripada
mengeluarkan biaya yang sangat tinggi untuk menghindari transaksi yang salah.
Bagi bank (dan nasabah bank), ketersediaan jaringan ATM lebih penting daripada gagal atau
tidaknya transaksi ATM individu. Kurangnya kemampuan avail berarti lebih banyak permintaan
pada layanan counter, ketidakpuasan pelanggan, biaya rekayasa untuk memperbaiki jaringan, dll.
Oleh karena itu, untuk sistem berbasis transaksi, seperti
perbankan dan sistem e-commerce, fokus spesifikasi keandalan biasanya pada menentukan
ketersediaan sistem.
Untuk menentukan ketersediaan jaringan ATM, Anda harus mengidentifikasi sistem
layanan dan menentukan ketersediaan yang diperlukan untuk masing-masing. Ini adalah:
• layanan database akun pelanggan;
• layanan individu yang disediakan oleh ATM seperti 'menarik uang tunai', 'memberikan
informasi rekening', dll.
Di sini, layanan database paling kritis karena kegagalan layanan ini berarti semua ATM di
jaringan tidak berfungsi. Oleh karena itu, Anda harus menentukan ini untuk memiliki tingkat
ketersediaan yang tinggi. Dalam hal ini, angka yang dapat diterima untuk kemampuan
ketersediaan basis data (mengabaikan masalah seperti pemeliharaan terjadwal dan peningkatan)
mungkin sekitar 0,9999, antara jam 7 pagi dan 11 malam. Ini berarti waktu henti kurang dari
satu menit per minggu. Dalam praktiknya, ini berarti bahwa sangat sedikit pelanggan yang akan
terpengaruh dan hanya akan menyebabkan ketidaknyamanan pelanggan yang kecil.
Untuk ATM individu, ketersediaan keseluruhan tergantung pada keandalan mekanis dan
fakta bahwa ATM dapat kehabisan uang tunai. Masalah perangkat lunak cenderung memiliki
efek yang lebih kecil daripada faktor-faktor seperti ini. Oleh karena itu, tingkat ketersediaan
perangkat lunak ATM yang lebih rendah dapat diterima. Oleh karena itu, ketersediaan
keseluruhan perangkat lunak ATM dapat ditentukan sebagai 0,999, yang berarti bahwa mesin
mungkin tidak tersedia antara satu dan dua menit setiap hari.
Untuk mengilustrasikan spesifikasi keandalan berbasis kegagalan, pertimbangkan
persyaratan keandalan untuk perangkat lunak kontrol di pompa insulin. Sistem ini memberikan
insulin beberapa kali per hari dan memonitor glukosa darah pengguna beberapa kali per jam.
Karena penggunaan sistem bersifat intermiten dan konsekuensi kegagalan serius, metrik
keandalan yang paling tepat adalah POFOD (probabilitas kegagalan sesuai permintaan).
Ada dua kemungkinan jenis kegagalan dalam pompa insulin:
1. Kegagalan perangkat lunak sementara yang dapat diperbaiki dengan tindakan pengguna
seperti menyetel ulang atau mengkalibrasi ulang mesin. Untuk jenis kegagalan ini, nilai
POFOD yang relatif rendah (katakanlah 0,002) mungkin dapat diterima. Ini berarti bahwa
satu kegagalan dapat terjadi pada setiap 500 permintaan yang dibuat pada mesin. Ini kira-
kira sekali setiap 3,5 hari, karena gula darah diperiksa sekitar lima kali per jam.
2. Kegagalan perangkat lunak permanen yang mengharuskan perangkat lunak diinstal ulang
oleh pabrikan. Probabilitas jenis kegagalan ini harus jauh lebih rendah.
Kira-kira setahun sekali adalah angka minimum, jadi POFOD tidak boleh lebih dari 0,00002.
Namun, kegagalan untuk memberikan insulin tidak memiliki implikasi keamanan langsung,
sehingga faktor komersial daripada faktor keamanan mengatur tingkat keandalan yang diperlukan.
Biaya layanan tinggi karena pengguna membutuhkan perbaikan dan penggantian yang cepat.
Adalah kepentingan pabrikan untuk membatasi jumlah kegagalan permanen yang memerlukan perbaikan.
RR1: Rentang yang telah ditentukan sebelumnya untuk semua input operator harus ditentukan dan sistem harus
memeriksa bahwa semua input operator berada dalam rentang yang telah ditentukan sebelumnya. (Memeriksa)
RR2: Salinan database pasien harus disimpan di dua server terpisah yang tidak ditempatkan di gedung
yang sama. (Pemulihan, redundansi)
RR3: Pemrograman versi-N harus digunakan untuk menerapkan sistem kontrol pengereman.
Gambar 12.8 (Redundansi)
Contoh
persyaratan
RR4: Sistem harus diimplementasikan dalam subset Ada yang aman dan diperiksa menggunakan analisis statis.
keandalan
(Proses)
fungsional
12.3.3 Spesifikasi keandalan fungsional

Spesifikasi keandalan fungsional melibatkan identifikasi persyaratan yang mendefinisikan
kendala dan fitur yang berkontribusi pada keandalan sistem. Untuk sistem di mana keandalan
telah ditentukan secara kuantitatif, persyaratan fungsional ini mungkin diperlukan untuk
memastikan bahwa tingkat keandalan yang diperlukan tercapai.
Ada tiga jenis persyaratan keandalan fungsional untuk suatu sistem:
1. Memeriksa persyaratan Persyaratan ini mengidentifikasi pemeriksaan pada input ke

sistem untuk memastikan bahwa input yang salah atau di luar jangkauan terdeteksi
sebelum diproses oleh sistem.
2. Persyaratan pemulihan Persyaratan ini ditujukan untuk membantu pemulihan sistem

setelah terjadi kegagalan. Biasanya, persyaratan ini berkaitan dengan pemeliharaan
salinan sistem dan datanya serta menentukan cara memulihkan layanan sistem setelah
terjadi kegagalan.
3. Persyaratan redundansi Ini menentukan fitur redundan dari sistem yang memastikan
bahwa kegagalan komponen tunggal tidak menyebabkan hilangnya layanan sepenuhnya.
Saya membahas ini secara lebih rinci di bab berikutnya.
Selain itu, persyaratan keandalan dapat mencakup persyaratan proses untuk keandalan.
Ini adalah persyaratan untuk memastikan bahwa praktik yang baik, yang diketahui dapat
mengurangi jumlah kesalahan dalam suatu sistem, digunakan dalam proses pengembangan.
Beberapa contoh keandalan fungsional dan persyaratan proses ditunjukkan pada Gambar
12.8.
Tidak ada aturan sederhana untuk menurunkan persyaratan keandalan fungsional. Dalam
organisasi yang mengembangkan sistem kritis, biasanya ada pengetahuan organisasi
tentang persyaratan keandalan yang mungkin dan bagaimana hal ini berdampak pada
keandalan sistem yang sebenarnya. Organisasi-organisasi ini mungkin berspesialisasi dalam
jenis sistem tertentu seperti sistem kontrol kereta api, sehingga persyaratan keandalan dapat
digunakan kembali di berbagai sistem.
12.4 Spesifikasi keamanan 329
12.4 Spesifikasi keamanan
Spesifikasi persyaratan keamanan untuk sistem memiliki kesamaan dengan persyaratan keselamatan.
Tidak praktis untuk menentukannya secara kuantitatif, dan persyaratan keamanan sering kali
merupakan persyaratan 'tidak boleh' yang mendefinisikan perilaku sistem yang tidak dapat diterima
daripada fungsionalitas sistem yang diperlukan. Namun, keamanan adalah masalah yang lebih
menantang daripada keselamatan, karena beberapa alasan:
1. Saat mempertimbangkan keamanan, Anda dapat berasumsi bahwa lingkungan tempat sistem
dipasang tidak berbahaya. Tidak ada yang mencoba menyebabkan insiden terkait keselamatan.
Saat mempertimbangkan keamanan, Anda harus berasumsi bahwa serangan pada sistem
disengaja dan penyerang mungkin memiliki pengetahuan tentang kelemahan sistem.
2. Ketika terjadi kegagalan sistem yang menimbulkan risiko terhadap keselamatan, Anda mencari
kesalahan atau kelalaian yang menyebabkan kegagalan tersebut. Ketika serangan yang disengaja
menyebabkan kegagalan sistem, menemukan akar penyebab mungkin lebih sulit karena
penyerang mungkin mencoba menyembunyikan penyebab kegagalan.
3. Biasanya dapat diterima untuk mematikan sistem atau menurunkan layanan sistem untuk
menghindari kegagalan terkait keselamatan. Namun, serangan pada sistem dapat disebut
serangan penolakan layanan, yang dimaksudkan untuk mematikan sistem. Mematikan sistem
berarti serangan telah berhasil.
4. Peristiwa terkait keselamatan tidak dihasilkan oleh musuh yang cerdas. Seorang penyerang dapat
menyelidiki pertahanan sistem dalam serangkaian serangan, memodifikasi serangan saat dia
belajar lebih banyak tentang sistem dan tanggapannya.
Perbedaan ini berarti bahwa persyaratan keamanan biasanya harus lebih luas daripada
persyaratan keselamatan. Persyaratan keselamatan mengarah pada pembentukan persyaratan
sistem fungsional yang memberikan perlindungan terhadap kejadian dan kesalahan yang dapat
menyebabkan kegagalan terkait keselamatan. Mereka sebagian besar prihatin dengan memeriksa
masalah dan mengambil tindakan jika masalah ini terjadi. Sebaliknya, ada banyak jenis persyaratan
keamanan yang mencakup berbagai ancaman yang dihadapi oleh suatu sistem.
Firesmith (2003) telah mengidentifikasi 10 jenis persyaratan keamanan yang mungkin disertakan
dalam spesifikasi sistem:
1. Persyaratan identifikasi menentukan apakah suatu sistem harus mengidentifikasi penggunanya

sebelum berinteraksi dengan mereka.
2. Persyaratan otentikasi menentukan bagaimana pengguna diidentifikasi.
3. Persyaratan otorisasi menentukan hak istimewa dan izin akses dari pengguna yang diidentifikasi.
4. Persyaratan kekebalan menentukan bagaimana sistem harus melindungi dirinya dari virus, worm,
dan ancaman serupa.
5. Persyaratan integritas menentukan bagaimana korupsi data dapat dihindari.

Manajemen risiko keamanan
Keselamatan adalah masalah hukum dan bisnis tidak dapat memutuskan untuk tidak memproduksi sistem yang aman.
Namun, beberapa aspek keamanan adalah masalah bisnis—bisnis dapat memutuskan untuk tidak menerapkan beberapa
tindakan keamanan dan untuk menutupi kerugian yang mungkin timbul dari keputusan ini. Manajemen risiko adalah proses
memutuskan aset apa yang harus dilindungi dan berapa banyak yang dapat dihabiskan untuk melindunginya.
http://www.SoftwareEngineering-9.com/Web/Security/RiskMan.html
6. Persyaratan deteksi intrusi menentukan mekanisme apa yang harus digunakan untuk
mendeteksi serangan pada sistem.
7. Persyaratan non-penyangkalan menentukan bahwa suatu pihak dalam suatu transaksi tidak dapat
menyangkal keterlibatannya dalam transaksi tersebut.
8. Persyaratan privasi menentukan bagaimana privasi data harus dijaga.
9. Persyaratan audit keamanan menentukan bagaimana penggunaan sistem dapat diaudit dan
diperiksa.
10. Persyaratan keamanan pemeliharaan sistem menentukan bagaimana aplikasi dapat mencegah
perubahan resmi agar tidak merusak mekanisme keamanannya secara tidak sengaja.
Tentu saja, Anda tidak akan melihat semua jenis persyaratan keamanan ini di setiap sistem.
Persyaratan khusus tergantung pada jenis sistem, situasi penggunaan, dan pengguna yang diharapkan.
Analisis risiko dan proses penilaian yang dibahas dalam Bagian 12.1 dapat digunakan untuk
mengidentifikasi persyaratan keamanan sistem. Seperti yang saya bahas, ada tiga tahap untuk proses
ini:
1. Analisis risiko awal Pada tahap ini, keputusan tentang kebutuhan sistem yang terperinci, desain
sistem, atau teknologi implementasi belum dibuat. Tujuan dari proses penilaian ini adalah untuk
mendapatkan persyaratan keamanan untuk sistem secara keseluruhan.
2. Analisis risiko siklus hidup Penilaian risiko ini berlangsung selama siklus hidup pengembangan
sistem setelah pilihan desain dibuat. Persyaratan keamanan tambahan memperhitungkan
teknologi yang digunakan dalam membangun sistem dan desain sistem dan keputusan
implementasi.
3. Analisis risiko operasional Penilaian risiko ini mempertimbangkan risiko yang ditimbulkan oleh
serangan berbahaya pada sistem operasional oleh pengguna, dengan atau tanpa sepengetahuan
orang dalam sistem.
Proses penilaian dan analisis risiko yang digunakan dalam spesifikasi persyaratan keamanan
adalah varian dari proses spesifikasi berbasis risiko umum yang dibahas dalam
12.4 Spesifikasi keamanan 331
Aset
Identifikasi
Nilai aset Paparan

Penilaian Penilaian
Ancaman Menyerang
Identifikasi Penilaian
Gambar 12.9
Proses penilaian
risiko awal untuk Kontrol Kelayakan Persyaratan Keamanan
persyaratan Identifikasi Penilaian Definisi
keamanan
Bagian 12.1. Proses persyaratan keamanan berbasis risiko ditunjukkan pada Gambar 12.9.
Ini mungkin tampak berbeda dari proses yang digerakkan oleh risiko pada Gambar 12.1, tetapi
saya menunjukkan bagaimana setiap tahap sesuai dengan tahapan dalam proses generik dengan
memasukkan aktivitas proses generik dalam tanda kurung. Tahapan prosesnya adalah:
1. Identifikasi aset, di mana aset sistem yang mungkin memerlukan perlindungan diidentifikasi.
Sistem itu sendiri atau fungsi sistem tertentu dapat diidentifikasi sebagai aset serta data
yang terkait dengan sistem (identifikasi risiko).
2. Penilaian nilai aset, di mana Anda memperkirakan nilai aset yang diidentifikasi
(analisis resiko).
3. Eksposur penilaian, di mana Anda menilai potensi kerugian yang terkait dengan setiap aset. Ini
harus memperhitungkan kerugian langsung seperti pencurian informasi
mation, biaya pemulihan, dan kemungkinan hilangnya reputasi (analisis risiko).
4. Identifikasi ancaman, di mana Anda mengidentifikasi ancaman terhadap aset sistem (risiko
analisis).
5. Penilaian serangan, di mana Anda menguraikan setiap ancaman menjadi serangan yang mungkin
dilakukan pada sistem dan kemungkinan cara serangan tersebut dapat terjadi.
Anda dapat menggunakan pohon serangan (Schneier, 1999) untuk menganalisis kemungkinan
serangan. Ini mirip dengan pohon kesalahan saat Anda memulai dengan ancaman di akar
pohon dan mengidentifikasi kemungkinan serangan kausal dan bagaimana ini bisa dilakukan (penguraian risiko).
6. Identifikasi kontrol, di mana Anda mengusulkan kontrol yang mungkin diterapkan untuk
melindungi aset. Kontrol adalah mekanisme teknis, seperti enkripsi, yang dapat Anda
gunakan untuk melindungi aset (pengurangan risiko).
7. Penilaian kelayakan, di mana Anda menilai kelayakan teknis dan biaya pengendalian yang
diusulkan. Tidak ada gunanya memiliki kontrol mahal untuk melindungi aset yang tidak
memiliki nilai tinggi (pengurangan risiko).
8. Definisi persyaratan keamanan, di mana pengetahuan tentang paparan, ancaman, dan penilaian
kontrol digunakan untuk memperoleh persyaratan keamanan sistem. Ini mungkin
Aset Nilai Paparan
Sistem informasi Tinggi. Wajib mendukung semua Tinggi. Kerugian finansial seperti yang mungkin terjadi pada klinik
konsultasi klinis. Berpotensi harus dibatalkan. Biaya dari

keselamatan-kritis. memulihkan sistem. Kemungkinan pasien
merugikan jika pengobatan tidak bisa
ditentukan.
database pasien Tinggi. Wajib mendukung semua Tinggi. Kerugian finansial seperti yang mungkin terjadi pada klinik
konsultasi klinis. Berpotensi harus dibatalkan. Biaya dari

keselamatan-kritis. memulihkan sistem. Kemungkinan pasien
merugikan jika pengobatan tidak bisa
ditentukan.
Catatan pasien individu Biasanya rendah meskipun mungkin Kerugian langsung rendah tetapi kemungkinan kerugian
tinggi untuk profil tinggi tertentu reputasi.

pasien.
menjadi persyaratan untuk infrastruktur sistem atau sistem aplikasi (risk

Gambar 12.10 Aset
pengurangan).
analisis dalam
risiko awal
laporan penilaian
Masukan penting untuk penilaian risiko dan proses manajemen adalah kebijakan keamanan
untuk MHC-PMS
organisasi. Kebijakan keamanan organisasi berlaku untuk semua sistem dan
harus mengatur apa yang harus dan apa yang tidak boleh. Misalnya, satu aspek
kebijakan keamanan militer dapat menyatakan 'Pembaca hanya dapat memeriksa dokumen yang
klasifikasi sama dengan atau di bawah tingkat pemeriksaan pembaca.' Artinya jika
pembaca telah diperiksa ke tingkat 'rahasia', mereka dapat mengakses dokumen yang diklasifikasikan
sebagai 'rahasia', 'rahasia', atau 'terbuka' tetapi bukan dokumen yang diklasifikasikan sebagai 'sangat rahasia'.
Kebijakan keamanan menetapkan kondisi yang harus selalu dijaga oleh a
sistem keamanan dan membantu mengidentifikasi ancaman yang mungkin timbul. Ancaman adalah
segala sesuatu yang dapat mengancam keamanan bisnis. Dalam praktiknya, kebijakan keamanan
biasanya merupakan dokumen informal yang mendefinisikan apa yang boleh dan apa yang tidak diperbolehkan. Namun,
Bishop (2005) membahas kemungkinan mengungkapkan kebijakan keamanan secara formal
bahasa dan menghasilkan pemeriksaan otomatis untuk memastikan bahwa kebijakan sedang
diikuti.
Untuk mengilustrasikan proses analisis risiko keamanan ini, pertimbangkan sistem
informasi rumah sakit untuk perawatan kesehatan mental, MHC-PMS. Saya tidak memiliki
ruang untuk membahas penilaian risiko yang lengkap di sini, melainkan menggunakan sistem ini sebagai sumber contoh.
Saya telah menunjukkan ini sebagai bagian dari laporan (Gambar 12.10 dan 12.11) yang mungkin
dihasilkan dari proses penilaian risiko awal. Analisis risiko awal ini
laporan digunakan dalam mendefinisikan persyaratan keamanan.
Dari analisis risiko untuk sistem informasi rumah sakit, Anda dapat memperoleh keamanan
persyaratan ritus. Beberapa contoh persyaratan tersebut adalah:
1. Informasi pasien harus diunduh, pada awal sesi klinik, dari:

database ke area aman pada klien sistem.
12.5 Spesifikasi formal 333
Ancaman Kemungkinan Kontrol Kelayakan
Pengguna yang tidak sah Rendah Hanya izinkan manajemen Biaya
mendapatkan akses sebagai manajer sistem dari lokasi tertentu implementasi yang rendah tetapi
sistem dan membuat sistem tidak yang secara fisik aman. harus berhati-hati dengan
tersedia distribusi kunci dan untuk
memastikan bahwa kunci tersedia

jika terjadi
keadaan darurat.
Pengguna yang tidak sah Tinggi Mengharuskan semua Solusi yang layak secara teknis
mendapatkan akses sebagai pengguna untuk mengautentikasi tetapi berbiaya tinggi.
pengguna sistem dan mengakses diri mereka sendiri menggunakan Kemungkinan resistensi pengguna.
informasi rahasia mekanisme biometrik.
Sederhana dan transparan untuk
Catat semua perubahan pada diterapkan dan juga mendukung
informasi pasien untuk dilacak pemulihan.
penggunaan sistem.
2. Semua informasi pasien pada klien sistem harus dienkripsi.

Gambar 12.11
Analisis ancaman dan
3. Informasi pasien harus diunggah ke database saat sesi klinik sedang
pengendalian dalam
laporan penilaian risiko
atas dan dihapus dari komputer klien.
awal
4. Sebuah log dari semua perubahan yang dibuat ke database sistem dan inisiator
dari perubahan ini harus disimpan pada komputer yang terpisah dari server database.
Dua persyaratan pertama saling terkait—informasi pasien diunduh ke mesin

lokal sehingga konsultasi dapat dilanjutkan jika server database pasien diserang
atau menjadi tidak tersedia. Namun, informasi ini harus dihapus agar pengguna
komputer klien selanjutnya tidak dapat mengakses informasi tersebut. Persyaratan
keempat adalah persyaratan pemulihan dan audit. Ini berarti bahwa perubahan
dapat dipulihkan dengan memutar ulang log perubahan dan dimungkinkan untuk
menemukan siapa yang telah membuat perubahan. Akuntabilitas ini mencegah penyalahgunaan sistem
12.5 Spesifikasi formal
Selama lebih dari 30 tahun, banyak peneliti telah menganjurkan penggunaan metode formal
pengembangan perangkat lunak. Metode formal adalah pendekatan berbasis matematis untuk
pengembangan perangkat lunak di mana Anda mendefinisikan model formal perangkat lunak.
Anda kemudian dapat menganalisis model ini secara formal dan menggunakannya sebagai dasar
untuk spesifikasi sistem formal. Pada prinsipnya, dimungkinkan untuk memulai dengan model
formal untuk perangkat lunak dan membuktikan bahwa program yang dikembangkan konsisten
dengan model tersebut, sehingga menghilangkan kegagalan perangkat lunak yang diakibatkan oleh kesalahan pemrograma
Teknik spesifikasi formal
Spesifikasi sistem formal dapat dinyatakan dengan menggunakan dua pendekatan mendasar, baik
sebagai model antarmuka sistem (spesifikasi aljabar) atau sebagai model keadaan sistem. Anda dapat
mengunduh bab web tambahan tentang topik ini, di mana saya menunjukkan contoh dari kedua
pendekatan ini. Bab ini mencakup spesifikasi formal bagian dari sistem pompa insulin.
http://www.SoftwareEngineering-9.com/Web/ExtraChaps/FormalSpec.pdf
Titik awal untuk semua proses pengembangan formal adalah model sistem formal, yang
berfungsi sebagai spesifikasi sistem. Untuk membuat model ini, Anda menerjemahkan
persyaratan pengguna sistem, yang diekspresikan dalam bahasa alami, diagram, dan tabel,
ke dalam bahasa matematika yang telah didefinisikan secara formal semantik. Spesifikasi
for mal adalah deskripsi yang jelas tentang apa yang harus dilakukan sistem.
Menggunakan metode manual atau yang didukung alat, Anda dapat memeriksa apakah
perilaku program konsisten dengan spesifikasi.
Spesifikasi formal tidak hanya penting untuk verifikasi desain dan implementasi perangkat
lunak. Mereka adalah cara yang paling tepat untuk menentukan sistem, sehingga mengurangi
ruang lingkup untuk kesalahpahaman. Selanjutnya, membangun spesifikasi formal memaksa
analisis rinci dari persyaratan dan ini adalah cara yang efektif untuk menemukan masalah
persyaratan. Dalam spesifikasi bahasa alami, kesalahan dapat disembunyikan oleh
ketidaktepatan bahasa. Ini tidak terjadi jika sistem secara formal ditentukan.
Spesifikasi formal biasanya dikembangkan sebagai bagian dari proses perangkat lunak
berbasis rencana, di mana sistem sepenuhnya ditentukan sebelum pengembangan.
Persyaratan dan desain sistem didefinisikan secara rinci dan dianalisis dan diperiksa dengan
cermat sebelum implementasi dimulai. Jika spesifikasi formal dari perangkat lunak
dikembangkan, ini biasanya muncul setelah persyaratan sistem telah ditentukan tetapi
sebelum desain sistem yang terperinci. Ada loop umpan balik yang ketat antara spesifikasi
kebutuhan yang terperinci dan spesifikasi formal.
Gambar 12.12 menunjukkan tahapan spesifikasi perangkat lunak dan antarmuka dengan
desain perangkat lunak dalam proses perangkat lunak berbasis rencana. Karena mahal
untuk mengembangkan spesifikasi formal, Anda mungkin memutuskan untuk membatasi
penggunaan pendekatan ini untuk komponen-komponen yang penting untuk operasi sistem.
Anda mengidentifikasi ini dalam desain arsitektur sistem.
Selama beberapa tahun terakhir, dukungan otomatis untuk menganalisis spesifikasi
formal telah dikembangkan. Model checker (Clarke et al., 2000) adalah perangkat lunak yang
mengambil spesifikasi formal berbasis status (model sistem) sebagai input, bersama dengan
spesifikasi beberapa properti yang diinginkan secara formal, seperti 'tidak ada status yang
tidak dapat dijangkau. .' Program pemeriksaan model menganalisis spesifikasi secara
mendalam dan melaporkan bahwa properti sistem dipenuhi oleh model atau menyajikan
contoh yang menunjukkan bahwa itu tidak terpenuhi. Pengecekan model terkait erat dengan
gagasan analisis statis dan saya membahas pendekatan umum ini untuk verifikasi sistem di Bab 15.
12.5 Spesifikasi formal 335
Meningkatkan Keterlibatan Kontraktor
Mengurangi Keterlibatan Klien

Pengguna
Sistem Resmi
Arsitektur Level tinggi
Persyaratan Persyaratan
Definisi Rancangan Spesifikasi Rancangan
Spesifikasi
Spesifikasi
Rancangan
Keuntungan mengembangkan spesifikasi formal dan menggunakannya dalam formal

Gambar 12.12 Spesifikasi
proses pembangunan adalah:
formal dalam proses
perangkat lunak berbasis
rencana 1. Saat Anda mengembangkan spesifikasi formal secara rinci, Anda mengembangkan pemahaman
yang mendalam dan rinci tentang persyaratan sistem. Bahkan jika Anda tidak menggunakan
spesifikasi dalam proses pengembangan formal, deteksi kesalahan persyaratan adalah
argumen yang kuat untuk mengembangkan spesifikasi formal (Hall, 1990). Masalah
kebutuhan yang ditemukan lebih awal biasanya jauh lebih murah untuk diperbaiki daripada
jika ditemukan pada tahap selanjutnya dalam proses pengembangan.
2. Karena spesifikasi diekspresikan dalam bahasa dengan semantik yang didefinisikan secara
formal, Anda dapat menganalisisnya secara otomatis untuk menemukan inkonsistensi dan ketidaklengkapan.
3. Jika Anda menggunakan metode seperti metode B, Anda dapat mengubah spesifikasi formal
menjadi program melalui urutan transformasi yang mempertahankan kebenaran. Oleh
karena itu, program yang dihasilkan dijamin memenuhi spesifikasinya.
4. Biaya pengujian program dapat dikurangi karena Anda telah memverifikasi program terhadap
spesifikasinya.
Terlepas dari keuntungan ini, metode formal memiliki dampak terbatas pada pengembangan
perangkat lunak praktis, bahkan untuk sistem kritis. Akibatnya, ada sedikit pengalaman dalam
masyarakat untuk mengembangkan dan menggunakan spesifikasi sistem formal. Argumen yang
diajukan terhadap pengembangan spesifikasi sistem formal adalah:
1. Pemilik masalah dan pakar domain tidak dapat memahami spesifikasi formal sehingga mereka
tidak dapat memeriksa apakah spesifikasi tersebut secara akurat mewakili kebutuhan
mereka. Insinyur perangkat lunak, yang memahami spesifikasi formal, mungkin tidak
memahami domain aplikasi sehingga mereka juga tidak dapat memastikan bahwa spesifikasi
formal merupakan cerminan akurat dari persyaratan sistem.
2. Menghitung biaya pembuatan spesifikasi formal cukup mudah, tetapi lebih sulit untuk
memperkirakan kemungkinan penghematan biaya yang akan dihasilkan dari penggunaannya.
Akibatnya, manajer tidak mau mengambil risiko mengadopsi pendekatan ini.
Biaya spesifikasi formal
Mengembangkan spesifikasi formal adalah proses yang mahal karena cukup banyak waktu yang dibutuhkan untuk
menerjemahkan persyaratan ke dalam bahasa formal dan memeriksa spesifikasi. Pengalaman telah menunjukkan bahwa
penghematan dapat dilakukan dalam pengujian dan verifikasi sistem dan tampaknya menetapkan sistem secara formal
tidak secara signifikan meningkatkan biaya pengembangan secara keseluruhan. Namun, keseimbangan biaya berubah,
dengan lebih banyak biaya yang dikeluarkan di awal proses pengembangan.
http://www.SoftwareEngineering-9.com/Web/FormalSpecCosts/
3. Sebagian besar perekayasa perangkat lunak belum dilatih untuk menggunakan bahasa spesifikasi
formal. Oleh karena itu, mereka enggan untuk mengusulkan penggunaannya dalam proses pembangunan.
4. Sulit untuk menskalakan pendekatan saat ini untuk spesifikasi formal hingga sistem yang sangat
besar. Ketika spesifikasi formal digunakan, sebagian besar untuk menentukan perangkat lunak
kernel kritis daripada sistem yang lengkap.
5. Spesifikasi formal tidak sesuai dengan metode pengembangan tangkas.
Namun demikian, pada saat penulisan, metode formal telah digunakan dalam pengembangan
sejumlah aplikasi yang kritis terhadap keselamatan dan keamanan. Mereka juga dapat digunakan
secara efektif dalam biaya pengembangan dan validasi bagian-bagian penting dari sistem perangkat
lunak yang lebih besar dan lebih kompleks (Badeau dan Amelot, 2005; Hall, 1996; Hall dan Chapman,
2002; Miller et al., 2005; Wordworth, 1996; Hall dan Chapman, 2002; Miller et al., 2005; Wordworth,
1996). ). Mereka adalah dasar alat yang digunakan dalam verifikasi statis seperti sistem verifikasi
driver yang digunakan oleh Microsoft (Ball et al., 2004; Ball et al., 2006) dan bahasa SPARK/Ada
(Barnes, 2003) untuk rekayasa sistem kritis.
POIN KUNCI
Analisis risiko merupakan aktivitas penting dalam spesifikasi keamanan dan ketergantungan
persyaratan. Ini melibatkan identifikasi risiko yang dapat mengakibatkan kecelakaan atau insiden.
Persyaratan sistem kemudian dibuat untuk memastikan bahwa risiko ini tidak terjadi dan, jika terjadi,
tidak menyebabkan insiden atau kecelakaan.
Pendekatan yang digerakkan oleh bahaya dapat digunakan untuk memahami persyaratan keselamatan suatu sistem. Anda
mengidentifikasi potensi bahaya dan menguraikannya (menggunakan metode seperti analisis pohon kesalahan) untuk
menemukan akar penyebabnya. Anda kemudian menentukan persyaratan untuk menghindari atau memulihkan dari masalah ini.
Persyaratan keandalan dapat didefinisikan secara kuantitatif dalam spesifikasi persyaratan sistem.
Metrik keandalan termasuk probabilitas kegagalan sesuai permintaan (POFOD), tingkat kejadian
kegagalan (ROCOF), dan ketersediaan (AVAIL).
Bab 12 Latihan 337
Penting untuk tidak terlalu menentukan keandalan sistem yang diperlukan karena hal ini menyebabkan hal yang tidak perlu
biaya tambahan dalam proses pengembangan dan validasi.
Persyaratan keamanan lebih sulit diidentifikasi daripada persyaratan keamanan karena penyerang sistem dapat menggunakan
pengetahuan tentang kerentanan sistem untuk merencanakan serangan sistem, dan dapat mempelajari kerentanan dari
serangan yang gagal.
Untuk menentukan persyaratan keamanan, Anda harus mengidentifikasi aset yang akan dilindungi dan menentukan
bagaimana teknik dan teknologi keamanan harus digunakan untuk melindungi aset tersebut.
Metode formal pengembangan perangkat lunak bergantung pada spesifikasi sistem yang dinyatakan sebagai model
matematis. Mengembangkan spesifikasi formal memiliki manfaat utama merangsang pemeriksaan rinci dan analisis
persyaratan sistem.
BACAAN LEBIH LANJUT
Safeware: Keamanan Sistem dan Komputer. Ini adalah diskusi menyeluruh tentang semua aspek sistem kritis
keselamatan. Hal ini sangat kuat dalam deskripsi analisis bahaya dan derivasi persyaratan dari ini. (N. Leveson, Addison-
Wesley, 1995.)
'Kasus Penggunaan Keamanan.' Artikel bagus, tersedia di Web, yang berfokus pada bagaimana kasus penggunaan
dapat digunakan dalam spesifikasi keamanan. Penulis juga memiliki sejumlah artikel bagus tentang spesifikasi keamanan
yang dirujuk dalam artikel ini. (DG Firesmith, Journal of Object Technology, 2 (3), Mei–Juni 2003.) http://www.jot.fm/issues/
issue_2003_05/column6/.
'Sepuluh Perintah Metode Formal. . .Sepuluh tahun kemudian.' Ini adalah seperangkat pedoman untuk penggunaan metode
formal yang pertama kali diusulkan pada tahun 1996 dan ditinjau kembali dalam makalah ini. Ini adalah ringkasan yang baik
dari isu-isu praktis seputar penggunaan metode formal. (JP Bowen dan MG Hinchey, IEEE Computer, 39 (1), Januari 2006.)
http://dx.doi.org/10.1109/MC.2006.35.
'Persyaratan Keamanan untuk Kita Semua: Survei.' Titik awal yang baik untuk membaca tentang spesifikasi persyaratan
keamanan. Para penulis fokus pada pendekatan ringan daripada formal. (IA
Tøndel, MG Jaatun, dan PH Meland, IEEE Software, 25 (1), Januari/Februari 2008.) http://dx.doi.org/
10.1109/MS.2008.19.
LATIHAN
12.1. Jelaskan mengapa batas-batas dalam segitiga risiko yang ditunjukkan pada Gambar 12.12 dapat berubah seiring waktu
dan mengubah sikap sosial.
12.2. Jelaskan mengapa pendekatan berbasis risiko ditafsirkan dengan cara yang berbeda ketika menentukan keselamatan
dan keamanan.
12.3. Dalam sistem pompa insulin, pengguna harus mengganti jarum dan suplai insulin secara berkala dan juga dapat
mengubah dosis tunggal maksimum dan dosis harian maksimum yang dapat diberikan. Sarankan tiga kesalahan
pengguna yang mungkin terjadi dan usulkan persyaratan keselamatan yang akan menghindari kesalahan ini yang
mengakibatkan kecelakaan.
12.4. Sistem perangkat lunak yang kritis terhadap keamanan untuk merawat pasien kanker memiliki dua komponen utama:
Mesin terapi radiasi yang memberikan dosis radiasi terkontrol ke lokasi tumor . Mesin ini dikendalikan oleh sistem
perangkat lunak tertanam.
Basis data perawatan yang mencakup rincian perawatan yang diberikan kepada setiap pasien.
Persyaratan perawatan dimasukkan dalam database ini dan secara otomatis diunduh ke mesin terapi radiasi.
Identifikasi tiga bahaya yang mungkin timbul dalam sistem ini. Untuk setiap bahaya, sarankan persyaratan
defensif yang akan mengurangi kemungkinan bahwa bahaya ini akan mengakibatkan kecelakaan.
Jelaskan mengapa pertahanan yang Anda sarankan cenderung mengurangi risiko yang terkait dengan bahaya.
12.5. Sarankan metrik keandalan yang sesuai untuk kelas sistem perangkat lunak di bawah ini. Memberi
alasan untuk pilihan metrik Anda. Memprediksi penggunaan sistem ini dan menyarankan nilai yang sesuai untuk
metrik keandalan.
sistem yang memantau pasien di unit perawatan intensif rumah sakit
pengolah kata
sistem kontrol mesin penjual otomatis
sistem untuk mengontrol pengereman di dalam mobil
sistem untuk mengontrol unit pendingin
pembuat laporan manajemen
12.6. Sistem perlindungan kereta api secara otomatis menerapkan rem kereta api jika batas kecepatan untuk
segmen rel terlampaui, atau jika kereta memasuki segmen rel yang saat ini ditandai dengan lampu merah (yaitu,
segmen tersebut tidak boleh dimasuki). Berikan alasan untuk jawaban Anda, pilih metrik keandalan yang mungkin
digunakan untuk menentukan keandalan yang diperlukan untuk sistem semacam itu.
12.7. Ada dua persyaratan keselamatan penting untuk sistem proteksi kereta api:
Kereta api tidak boleh memasuki segmen lintasan yang ditandai dengan lampu merah.
Kereta tidak boleh melebihi batas kecepatan yang ditentukan untuk suatu bagian rel.
Dengan asumsi bahwa status sinyal dan batas kecepatan untuk segmen lintasan ditransmisikan ke perangkat lunak
onboard di kereta sebelum memasuki segmen lintasan, usulkan lima kemungkinan persyaratan sistem fungsional
untuk perangkat lunak onboard yang mungkin dihasilkan dari persyaratan keselamatan sistem.
Bab 12 Referensi 339
12.8. Jelaskan mengapa ada kebutuhan untuk penilaian risiko keamanan awal dan siklus hidup
penilaian risiko keamanan selama pengembangan sistem.
12.9. Perluas tabel pada Gambar 12.11 untuk mengidentifikasi dua ancaman lebih lanjut terhadap MHC-PMS, bersama
dengan kontrol terkait. Gunakan ini sebagai dasar untuk menghasilkan persyaratan keamanan perangkat lunak lebih
lanjut yang menerapkan kontrol yang diusulkan.
12.10. Haruskah insinyur perangkat lunak yang bekerja pada spesifikasi dan pengembangan sistem yang terkait dengan
keselamatan disertifikasi secara profesional dalam beberapa cara? Jelaskan alasan Anda.
REFERENSI
Badeau, F. dan Amelot, A. (2005). 'Menggunakan B sebagai Bahasa Pemrograman Tingkat Tinggi dalam Proyek Industri:
Roissy VAL'. Prok. ZB 2005: Spesifikasi dan Pengembangan Formal di Z dan B, Guildford, Inggris: Springer.
Ball, T., Bounimova, E., Cook, B., Levin, V., Lichtenberg, J., McGarvey, C., Ondrusek, B., Rajamani, SK dan Ustuner, A. (2006).
'Analisis Statis Menyeluruh dari Driver Perangkat'. Prok. EuroSys 2006, Leuven, Belgia.
Bola, T., Masak, B., Levin, V. dan Rajamani, SK (2004). 'SLAM dan Pemverifikasi Driver Statis: Transfer Teknologi Metode
Formal Di Dalam Microsoft'. Prok. Metode Formal Terpadu 2004, Canterbury, Inggris: Springer.
Barnes, JP (2003). Perangkat Lunak dengan Integritas Tinggi: Pendekatan SPARK untuk Keselamatan dan Keamanan.
Harlow, Inggris: Addison-Wesley.
Uskup, M. (2005). Pengantar Keamanan Komputer. Boston: Addison-Wesley.
Brazendale, J. dan Bell, R. (1994). 'Sistem kontrol dan perlindungan terkait keselamatan: pembaruan standar'. IEE
Computing and Control Engineering J., 5 (1), 6-12.
Clarke, EM, Grumberg, O. dan Peled, DA (2000). Pengecekan Model. Cambridge, Mass.: MIT Press.
Pemadam Kebakaran, Ditjen (2003). 'Persyaratan Keamanan Rekayasa'. Jurnal Teknologi Objek, 2 (1), 53-68.
Hall, A. (1990). 'Tujuh Mitos Metode Formal'. Perangkat Lunak IEEE, 7 (5), 11–20.
Hall, A. (1996). 'Menggunakan metode Formal untuk Mengembangkan Sistem Informasi ATC'. Perangkat Lunak IEEE,
13 (2), 66–76.
Hall, A. dan Chapman, R. (2002). 'Kebenaran dengan Konstruksi: Mengembangkan Sistem yang Aman Secara Komersial'.
Perangkat Lunak IEEE, 19 (1), 18–25.
Jahanian, F. dan Mok, AK (1986). 'Analisis keamanan properti waktu dalam sistem waktu nyata'. IEEE Trans.on Rekayasa
Perangkat Lunak., SE-12 (9), 890–904.
Leveson, N. dan Stolzy, J. (1987). 'Analisis Keamanan Menggunakan Jaring Petri'. Transaksi IEEE pada Rekayasa
Perangkat Lunak, 13 (3), 386–397.
Leveson, NG (1995). Safeware: Keamanan Sistem dan Komputer. Membaca, Mass.: Addison-Wesley.
Miller, SP, Anderson, EA, Wagner, LG, Whalen, MW dan Heimdahl, MPE (2005). 'Verifikasi Formal Perangkat
Lunak Kontrol Penerbangan'. Prok. AIAA Bimbingan, Navigasi dan Konferensi Kontrol, San Francisco.
Peterson, JL (1981). Teori Petri Net dan Pemodelan Sistem. New York: McGraw-Hill.
Schneier, B. (1999). 'Serang Pohon'. Jurnal Dr Dobbs, 24 (12), 1–9.
Storey, N. (1996). Sistem Komputer Keselamatan-Kritis. Harlow, Inggris: Addison-Wesley.
Wordsworth, J. (1996). Rekayasa Perangkat Lunak dengan B. Wokingham: Addison-Wesley.

13
Rekayasa
ketergantungan
Tujuan
Tujuan dari bab ini adalah untuk membahas proses dan teknik untuk mengembangkan sistem yang
sangat dapat diandalkan. Setelah Anda membaca bab ini, Anda akan:
memahami bagaimana ketergantungan sistem dapat dicapai dengan menggunakan

komponen yang berlebihan dan beragam;
mengetahui bagaimana proses perangkat lunak yang dapat diandalkan berkontribusi pada
pengembangan perangkat lunak yang dapat diandalkan;
memahami bagaimana gaya arsitektur yang berbeda dapat digunakan untuk

mengimplementasikan redundansi dan keragaman perangkat lunak;
menyadari praktik pemrograman yang baik yang harus digunakan dalam

rekayasa sistem yang dapat diandalkan.
Isi
13.1 Redundansi dan keragaman 13.2 Proses
yang dapat diandalkan 13.3 Arsitektur sistem
yang dapat diandalkan 13.4 Pemrograman yang dapat
diandalkan
342 Bab 13 Rekayasa Keandalan
Penggunaan teknik rekayasa perangkat lunak, bahasa pemrograman yang lebih baik, dan manajemen
kualitas yang lebih baik telah menghasilkan peningkatan yang signifikan dalam ketergantungan
untuk sebagian besar perangkat lunak. Namun demikian, kegagalan sistem mungkin masih terjadi
yang memengaruhi kemampuan ketersediaan sistem atau menyebabkan hasil yang dihasilkan salah.
Dalam beberapa kasus, kegagalan ini hanya menyebabkan ketidaknyamanan kecil. Vendor sistem
mungkin hanya memutuskan untuk hidup dengan kegagalan ini, tanpa memperbaiki kesalahan dalam
sistem mereka. Namun, dalam beberapa sistem, kegagalan dapat menyebabkan hilangnya nyawa
atau kerugian ekonomi atau reputasi yang signifikan. Ini dikenal sebagai 'sistem kritis', di mana tingkat ketergantungan yang tinggi
Contoh sistem kritis termasuk sistem kontrol proses, sistem perlindungan yang mematikan
sistem lain jika terjadi kegagalan, sistem medis, sakelar telekomunikasi, dan sistem kontrol
penerbangan. Alat dan teknik pengembangan khusus dapat digunakan untuk meningkatkan
ketergantungan perangkat lunak dalam sistem kritis. Alat dan teknik ini biasanya meningkatkan
biaya pengembangan sistem tetapi mengurangi risiko kegagalan sistem dan kerugian yang mungkin
timbul dari kegagalan tersebut.
Rekayasa ketergantungan berkaitan dengan teknik yang digunakan untuk meningkatkan
ketergantungan sistem kritis dan non-kritis. Teknik-teknik ini mendukung tiga pendekatan pelengkap
yang digunakan dalam mengembangkan perangkat lunak yang dapat diandalkan:
1. Penghindaran kesalahan Desain perangkat lunak dan proses implementasi harus menggunakan
pendekatan pengembangan perangkat lunak yang membantu menghindari kesalahan desain
dan pemrograman sehingga meminimalkan jumlah kesalahan yang mungkin muncul saat
sistem dijalankan. Lebih sedikit kesalahan berarti lebih sedikit kemungkinan kegagalan run-time.
2. Deteksi dan koreksi kesalahan Proses verifikasi dan validasi dirancang untuk menemukan dan
menghapus kesalahan dalam suatu program, sebelum digunakan untuk penggunaan
operasional. Sistem kritis memerlukan verifikasi dan validasi yang sangat ekstensif untuk
menemukan sebanyak mungkin kesalahan sebelum penerapan dan untuk meyakinkan
pemangku kepentingan sistem bahwa sistem dapat diandalkan. Saya membahas topik ini di
Bab 15.
3. Toleransi kesalahan Sistem dirancang sedemikian rupa sehingga kesalahan atau perilaku sistem
yang tidak terduga selama eksekusi terdeteksi pada saat run-time dan dikelola sedemikian rupa
sehingga kegagalan sistem tidak terjadi. Pendekatan sederhana untuk toleransi kesalahan
berdasarkan pemeriksaan run-time bawaan dapat disertakan di semua sistem. Namun, teknik
toleransi kesalahan yang lebih khusus (seperti penggunaan arsitektur sistem toleransi
kesalahan) umumnya hanya digunakan ketika tingkat ketersediaan dan keandalan sistem yang
sangat tinggi diperlukan.
Sayangnya, menerapkan teknik penghindaran kesalahan, deteksi kesalahan, dan toleransi

kesalahan mengarah pada situasi pengembalian yang semakin berkurang. Biaya untuk menemukan
dan menghapus kesalahan yang tersisa dalam sistem perangkat lunak meningkat secara eksponensial
ketika kesalahan program ditemukan dan dihapus (Gambar 13.1). Ketika perangkat lunak menjadi
lebih andal, Anda perlu menghabiskan lebih banyak waktu dan upaya untuk menemukan kesalahan
yang semakin sedikit. Pada tahap tertentu, bahkan untuk sistem kritis, biaya dari upaya tambahan ini menjadi tidak dapat dibenarka
13.1 Redundansi dan keragaman 343
Gambar 13.1
Banyak Sedikit Sangat sedikit
Meningkatnya biaya
penghapusan kesalahan residual Jumlah Kesalahan Sisa
Akibatnya, perusahaan pengembangan perangkat lunak menerima bahwa perangkat lunak

mereka akan selalu mengandung beberapa kesalahan residual. Tingkat kesalahan tergantung
pada jenis sistem. Produk yang dibungkus susut memiliki tingkat kesalahan yang relatif tinggi,
sedangkan sistem kritis biasanya memiliki kerapatan kesalahan yang jauh lebih rendah.
Alasan untuk menerima kesalahan adalah bahwa, jika dan ketika sistem gagal, lebih murah
untuk membayar konsekuensi kegagalan daripada menemukan dan menghapus kesalahan
sebelum pengiriman sistem. Namun, seperti yang dibahas dalam Bab 11, keputusan untuk merilis
perangkat lunak yang rusak bukan hanya keputusan ekonomi. Penerimaan sosial dan politik dari
kegagalan sistem juga harus diperhitungkan.
Banyak sistem kritis, seperti sistem pesawat, sistem medis, dan sistem akuntansi, digunakan
dalam domain yang diatur seperti transportasi udara, kedokteran, dan keuangan.
Pemerintah nasional menetapkan peraturan yang berlaku di domain ini dan menunjuk badan
pengatur untuk memastikan bahwa perusahaan mengikuti peraturan ini. Dalam praktiknya, ini
berarti bahwa regulator sering kali harus diyakinkan bahwa sistem perangkat lunak penting dapat
dipercaya dan ini memerlukan bukti jelas yang menunjukkan bahwa sistem ini dapat diandalkan.
Oleh karena itu, proses pengembangan untuk sistem kritis tidak hanya berkaitan dengan
menghasilkan sistem yang dapat diandalkan; itu juga harus menghasilkan bukti yang dapat
meyakinkan regulator bahwa sistem tersebut dapat diandalkan. Memproduksi bukti semacam itu
menghabiskan sebagian besar biaya pengembangan untuk sistem kritis dan juga merupakan
faktor kontribusi penting terhadap tingginya biaya sistem kritis. Saya membahas masalah
menghasilkan kasus keamanan dan ketergantungan di Bab 15.
13.1 Redundansi dan keragaman
Redundansi dan keragaman adalah strategi mendasar untuk meningkatkan ketergantungan dari
semua jenis sistem. Redundansi berarti bahwa kapasitas cadangan termasuk dalam sistem yang
dapat digunakan jika bagian dari sistem itu gagal. Keanekaragaman berarti berlebihan
Ledakan Ariane 5
Pada tahun 1996, roket Ariane 5 Badan Antariksa Eropa meledak 37 detik setelah lepas landas pada penerbangan
perdananya. Kesalahan itu disebabkan oleh kegagalan sistem perangkat lunak. Ada sistem cadangan tetapi ini tidak
beragam sehingga perangkat lunak di komputer cadangan gagal dengan cara yang persis sama. Roket dan muatan satelitnya hancur.
http://www.SoftwareEngineering-9.com/Web/DependabilityEng/Ariane/
komponen sistem memiliki tipe yang berbeda, sehingga meningkatkan kemungkinan bahwa mereka
tidak akan gagal dengan cara yang persis sama.
Kami menggunakan redundansi dan keragaman untuk meningkatkan ketergantungan dalam kehidupan kita sehari-hari.
Sebagai contoh redundansi, kebanyakan orang menyimpan bola lampu cadangan di rumah mereka
agar cepat pulih dari kegagalan bola lampu yang sedang digunakan.
Umumnya, untuk mengamankan rumah kita, kita menggunakan lebih dari satu kunci (redundansi)
dan, biasanya, kunci yang digunakan berbeda jenis (keragaman). Ini berarti bahwa jika seorang
penyusup menemukan cara untuk mengalahkan salah satu gembok, mereka harus menemukan
cara lain untuk mengalahkan gembok lainnya sebelum mereka bisa masuk. Sebagai rutinitas, kita
semua harus mencadangkan komputer kita dan dengan demikian memelihara salinan data kita
yang berlebihan. Untuk menghindari masalah dengan kegagalan disk, cadangan harus disimpan di perangkat eksternal yang terp
Sistem perangkat lunak yang dirancang untuk dapat diandalkan dapat mencakup komponen
redundan yang menyediakan fungsionalitas yang sama dengan komponen sistem lainnya. Ini
dialihkan ke sistem jika komponen utama gagal. Jika komponen redundan ini beragam (yaitu, tidak
sama dengan komponen lain), kesalahan umum pada komponen yang direplikasi tidak akan
mengakibatkan kegagalan sistem. Redundansi juga dapat diberikan dengan memasukkan kode
pemeriksaan tambahan, yang tidak sepenuhnya diperlukan agar sistem dapat berfungsi. Kode ini
dapat mendeteksi beberapa jenis kesalahan sebelum menyebabkan kegagalan. Itu dapat meminta
mekanisme pemulihan untuk memastikan bahwa sistem terus beroperasi.
Dalam sistem yang ketersediaannya merupakan persyaratan penting, server redundan biasanya
digunakan. Ini secara otomatis mulai beroperasi jika server yang ditunjuk gagal.
Kadang-kadang, untuk memastikan bahwa serangan pada sistem tidak dapat mengeksploitasi
kerentanan umum, server ini mungkin dari jenis yang berbeda dan dapat menjalankan sistem
operasi yang berbeda. Menggunakan sistem operasi yang berbeda adalah salah satu contoh
keragaman dan redundansi perangkat lunak, di mana fungsionalitas yang sebanding disediakan
dengan cara yang berbeda. Saya membahas keragaman perangkat lunak secara lebih rinci di Bagian 13.3.4.
Keragaman dan redundansi juga dapat digunakan untuk mencapai proses yang dapat diandalkan
dengan memastikan bahwa aktivitas proses, seperti validasi perangkat lunak, tidak bergantung
pada proses atau metode tunggal. Hal ini meningkatkan ketergantungan perangkat lunak karena
mengurangi kemungkinan kegagalan proses, di mana kesalahan manusia yang dibuat selama
proses pengembangan perangkat lunak menyebabkan kesalahan perangkat lunak. Misalnya,
aktivitas validasi dapat mencakup pengujian program, inspeksi program manual, dan analisis statis
sebagai teknik penemuan kesalahan. Ini adalah teknik pelengkap di mana salah satu teknik mungkin
menemukan kesalahan yang terlewatkan oleh metode lain. Selanjutnya, anggota tim yang berbeda
mungkin bertanggung jawab untuk aktivitas proses yang sama (misalnya, inspeksi program).
13.2 Proses yang dapat diandalkan 345
Proses operasional yang dapat diandalkan
Bab ini membahas proses pengembangan yang dapat diandalkan tetapi kontributor yang sama pentingnya untuk
ketergantungan sistem adalah proses operasional sistem. Dalam merancang proses operasional ini, Anda harus
mempertimbangkan faktor manusia dan selalu ingat bahwa orang dapat melakukan kesalahan saat menggunakan
sistem. Proses yang dapat diandalkan harus dirancang untuk menghindari kesalahan manusia dan, ketika kesalahan
dibuat, perangkat lunak harus mendeteksi kesalahan dan memungkinkannya untuk diperbaiki.
http://www.SoftwareEngineering-9.com/Web/DependabilityEng/HumanFactors/
Orang-orang menangani tugas dengan cara yang berbeda tergantung pada kepribadian, pengalaman, dan
pendidikan mereka, sehingga jenis redundansi ini memberikan perspektif yang beragam pada sistem.
Seperti yang saya bahas di Bagian 13.3.4, mencapai keragaman perangkat lunak tidaklah mudah.
Keragaman dan redundansi membuat sistem lebih kompleks dan biasanya lebih sulit untuk dipahami.
Tidak hanya ada lebih banyak kode untuk ditulis dan diperiksa, fungsionalitas tambahan juga harus
ditambahkan ke sistem untuk mendeteksi kegagalan komponen dan untuk mengalihkan kontrol ke komponen
alternatif. Kompleksitas tambahan ini berarti bahwa kemungkinan besar programmer akan membuat
kesalahan dan kecil kemungkinan orang yang memeriksa sistem akan menemukan kesalahan ini.
Akibatnya, beberapa orang berpikir bahwa yang terbaik adalah menghindari redundansi dan keragaman
perangkat lunak. Pandangan mereka adalah bahwa pendekatan terbaik adalah merancang perangkat lunak
sesederhana mungkin, dengan prosedur verifikasi dan validasi perangkat lunak yang sangat ketat (Parnas
et al., 1990). Lebih banyak dapat dihabiskan untuk verifikasi dan validasi karena penghematan yang
dihasilkan dari tidak harus mengembangkan komponen perangkat lunak yang berlebihan.
Kedua pendekatan tersebut digunakan dalam sistem komersial yang kritis terhadap keselamatan.
Misalnya, perangkat keras dan perangkat lunak kontrol penerbangan Airbus 340 beragam dan berlebihan
(Storey, 1996). Perangkat lunak kontrol penerbangan pada Boeing 777 didasarkan pada perangkat keras
yang berlebihan tetapi setiap komputer menjalankan perangkat lunak yang sama, yang telah divalidasi
secara luas. Perancang sistem kontrol penerbangan Boeing 777 telah berfokus pada kesederhanaan
daripada redundansi. Kedua pesawat ini sangat andal, sehingga pendekatan ketergantungan yang beragam
dan sederhana jelas dapat berhasil.
13.2 Proses yang dapat diandalkan
Proses perangkat lunak yang dapat diandalkan adalah proses perangkat lunak yang dirancang untuk
menghasilkan perangkat lunak yang dapat diandalkan. Perusahaan yang menggunakan proses yang dapat
diandalkan dapat yakin bahwa proses tersebut telah dibuat dan didokumentasikan dengan benar dan bahwa
teknik pengembangan yang sesuai telah digunakan untuk pengembangan sistem kritis. Alasan untuk
berinvestasi dalam proses yang dapat diandalkan adalah bahwa proses perangkat lunak yang baik
cenderung mengarah pada perangkat lunak yang dihasilkan yang mengandung lebih sedikit kesalahan dan karena itu lebih kecil kemung
Gambar 13.2 menunjukkan beberapa atribut dari proses perangkat lunak yang dapat diandalkan.
Bukti bahwa proses yang dapat diandalkan telah digunakan seringkali penting untuk meyakinkan
regulator bahwa praktik rekayasa perangkat lunak yang paling efektif telah diterapkan dalam mengembangkan
perangkat lunak. Pengembang sistem biasanya akan mempresentasikan model proses kepada regulator,
bersama dengan bukti bahwa proses tersebut telah
Karakteristik Proses Keterangan
Dapat didokumentasikan Proses harus memiliki model proses yang ditetapkan yang menetapkan kegiatan
dalam proses dan dokumentasi yang akan dihasilkan selama kegiatan ini.
Standar Seperangkat standar pengembangan perangkat lunak yang komprehensif yang

mencakup produksi dan dokumentasi perangkat lunak harus tersedia.
Bisa diaudit Proses harus dapat dimengerti oleh orang-orang selain dari peserta proses, yang dapat
memeriksa bahwa standar proses sedang diikuti dan memberikan saran untuk perbaikan
proses.
Beragam Proses tersebut harus mencakup kegiatan verifikasi dan validasi yang berlebihan dan
beragam.
Kokoh Proses harus dapat pulih dari kegagalan aktivitas proses individu.
diikuti. Regulator juga harus diyakinkan bahwa proses tersebut digunakan secara konsisten
Gambar 13.2
Atribut proses oleh semua peserta proses dan dapat digunakan dalam proyek pembangunan yang berbeda.
yang dapat Ini berarti bahwa proses harus didefinisikan secara eksplisit dan dapat diulang:
diandalkan
1. Proses yang didefinisikan secara eksplisit adalah proses yang memiliki model proses
terdefinisi yang digunakan untuk mendorong proses produksi perangkat lunak. Harus
ada data yang dikumpulkan selama proses yang menunjukkan bahwa semua langkah
yang diperlukan dalam model proses telah diberlakukan.
2. Proses yang dapat diulang adalah proses yang tidak bergantung pada interpretasi dan
penilaian individu. Sebaliknya, proses dapat diulang di seluruh proyek dan dengan
anggota tim yang berbeda, terlepas dari siapa yang terlibat dalam pengembangan. Ini
sangat penting untuk sistem kritis, yang sering kali memiliki siklus pengembangan yang
panjang di mana sering ada perubahan signifikan dalam tim pengembangan.
Proses yang dapat diandalkan memanfaatkan redundansi dan keragaman untuk mencapai
keandalan. Mereka sering mencakup kegiatan yang berbeda yang memiliki tujuan yang sama. Misalnya,
inspeksi dan pengujian program bertujuan untuk menemukan kesalahan dalam suatu program.
Pendekatan-pendekatan tersebut saling melengkapi sehingga secara bersama-sama mereka cenderung
menemukan proporsi kesalahan yang lebih tinggi daripada yang akan ditemukan dengan menggunakan satu teknik saja.
Aktivitas yang digunakan dalam proses yang dapat diandalkan jelas bergantung pada jenis
perangkat lunak yang sedang dikembangkan. Namun, secara umum, aktivitas ini harus
diarahkan untuk menghindari masuknya kesalahan ke dalam sistem, mendeteksi dan
menghilangkan kesalahan, dan memelihara informasi tentang proses itu sendiri. Contoh
kegiatan yang mungkin termasuk dalam proses yang dapat diandalkan meliputi:
1. Tinjauan persyaratan untuk memeriksa bahwa persyaratan, sejauh mungkin,

lengkap dan konsisten.
13.2 Proses yang dapat diandalkan 347
Siklus hidup keselamatan
Komisi Elektroteknik Internasional telah menyusun standar proses (IEC 61508) untuk rekayasa sistem proteksi. Ini
didasarkan pada gagasan tentang siklus hidup keselamatan, yang membuat perbedaan yang jelas antara rekayasa
keselamatan dan rekayasa sistem. Tahap pertama dari siklus hidup keselamatan IEC 61508 menentukan ruang lingkup sistem,
menilai potensi bahaya sistem, dan memperkirakan risiko yang ditimbulkannya. Ini diikuti dengan spesifikasi persyaratan
keselamatan dan alokasi persyaratan keselamatan ini untuk subsistem yang berbeda. Idenya adalah untuk membatasi tingkat
fungsionalitas kritis-keselamatan untuk memungkinkan teknik-teknik khusus untuk rekayasa sistem kritis diterapkan pada
pengembangan sistem kritis-keselamatan.
http://www.SoftwareEngineering-9.com/Web/SafetyLifeCycle/
2. Manajemen persyaratan untuk memastikan bahwa perubahan persyaratan dikendalikan dan

dampak perubahan persyaratan yang diusulkan dipahami oleh semua pengembang yang
terpengaruh oleh perubahan.
3. Spesifikasi formal, dimana model matematis dari perangkat lunak dibuat dan dianalisis. Saya
membahas manfaat spesifikasi formal di Bab 12.
Mungkin manfaat yang paling penting adalah bahwa hal itu memaksa analisis yang sangat
rinci dari persyaratan sistem. Analisis ini sendiri kemungkinan akan menemukan masalah
persyaratan yang mungkin terlewatkan dalam tinjauan persyaratan.
4. Pemodelan sistem, di mana desain perangkat lunak didokumentasikan secara eksplisit sebagai
satu set model grafis, dan hubungan antara persyaratan dan model ini didokumentasikan
secara eksplisit.
5. Inspeksi desain dan program, di mana deskripsi yang berbeda dari sistem diperiksa dan diperiksa
oleh orang yang berbeda. Inspeksi sering didorong oleh daftar periksa desain umum dan
kesalahan pemrograman.
6. Analisis statis, di mana pemeriksaan otomatis dilakukan pada kode sumber program. Ini mencari
anomali yang dapat menunjukkan kesalahan atau kelalaian pemrograman. Saya membahas
analisis statis di Bab 15.
7. Perencanaan dan manajemen pengujian, di mana serangkaian pengujian sistem yang komprehensif
dirancang. Proses pengujian harus dikelola dengan hati-hati untuk menunjukkan bahwa
pengujian ini menyediakan cakupan persyaratan sistem dan telah diterapkan dengan benar
dalam proses pengujian.
Selain aktivitas proses yang berfokus pada pengembangan dan pengujian sistem, juga harus
ada manajemen kualitas dan proses manajemen perubahan yang terdefinisi dengan baik.
Meskipun aktivitas spesifik dalam proses yang dapat diandalkan dapat bervariasi dari satu
perusahaan ke perusahaan lain, kebutuhan akan kualitas yang efektif dan manajemen perubahan bersifat universal.
Proses manajemen mutu (dibahas dalam Bab 24) menetapkan seperangkat standar proses dan
produk. Mereka juga mencakup kegiatan yang menangkap informasi proses untuk menunjukkan
bahwa standar ini telah diikuti. Misalnya, mungkin ada standar yang ditetapkan untuk melaksanakan
inspeksi program. Ketua tim inspeksi bertanggung jawab untuk mendokumentasikan proses untuk
menunjukkan bahwa standar inspeksi telah diikuti.
Manajemen perubahan, yang dibahas dalam Bab 25, berkaitan dengan pengelolaan
perubahan pada sistem, memastikan bahwa perubahan yang diterima benar-benar
diimplementasikan dan memastikan bahwa rilis perangkat lunak yang direncanakan
mencakup perubahan yang direncanakan. Satu masalah umum dengan perangkat lunak
adalah bahwa komponen yang salah disertakan dalam pembuatan sistem. Hal ini dapat
menyebabkan situasi di mana sistem pelaksana mencakup komponen yang belum diperiksa
selama proses pengembangan. Prosedur manajemen konfigurasi harus didefinisikan sebagai
bagian dari proses manajemen perubahan untuk memastikan bahwa ini tidak terjadi.
Ada pandangan luas bahwa pendekatan tangkas, seperti yang dibahas dalam Bab 3,
tidak benar-benar cocok untuk proses yang dapat diandalkan (Boehm, 2002). Pendekatan
tangkas fokus pada pengembangan perangkat lunak daripada mendokumentasikan apa
yang telah dilakukan. Mereka sering memiliki pendekatan yang cukup informal untuk
perubahan dan manajemen kualitas. Pendekatan berbasis rencana untuk pengembangan
sistem yang dapat diandalkan, yang membuat dokumentasi yang dapat dipahami oleh
regulator dan pemangku kepentingan sistem eksternal lainnya, umumnya lebih disukai.
Namun demikian, manfaat dari pendekatan tangkas sama-sama berlaku untuk sistem kritis.
Ada laporan keberhasilan dalam menerapkan metode tangkas di bidang ini (Lindvall, et al.,
2004) dan kemungkinan varian metode tangkas yang cocok untuk rekayasa sistem kritis akan dikembangkan.
13.3 Arsitektur sistem yang dapat diandalkan
Seperti yang telah saya diskusikan, pengembangan sistem yang dapat diandalkan harus
didasarkan pada proses yang dapat diandalkan. Namun, meskipun Anda mungkin
memerlukan proses yang dapat diandalkan untuk membuat sistem yang dapat diandalkan,
ini saja tidak cukup untuk memastikan keandalan. Anda juga perlu merancang arsitektur
sistem agar dapat diandalkan, terutama ketika toleransi kesalahan diperlukan. Ini berarti
bahwa arsitektur harus dirancang untuk memasukkan komponen dan mekanisme yang
berlebihan yang memungkinkan kontrol dialihkan dari satu komponen ke komponen lainnya.
Contoh sistem yang mungkin memerlukan arsitektur toleransi kesalahan adalah sistem
di pesawat udara yang harus beroperasi selama durasi penerbangan, sistem telekomunikasi,
dan sistem komando dan kontrol kritis. Pullum (2001) menjelaskan berbagai jenis arsitektur
toleransi kesalahan yang telah diusulkan dan Torres Pomales mensurvei teknik toleransi
kesalahan perangkat lunak (2000).
Realisasi paling sederhana dari arsitektur yang dapat diandalkan adalah di server yang
direplikasi, di mana dua atau lebih server melakukan tugas yang sama. Permintaan untuk
diproses disalurkan melalui komponen manajemen server yang mengarahkan setiap permintaan ke server tertentu.
Komponen ini juga melacak respons server. Jika terjadi kegagalan server, yang biasanya
terdeteksi oleh kurangnya respons, server yang rusak akan dimatikan dari sistem. Permintaan
yang belum diproses dikirim ulang ke server lain untuk diproses.
Pendekatan server yang direplikasi ini banyak digunakan untuk sistem pemrosesan
transaksi di mana mudah untuk memelihara salinan transaksi yang akan diproses. Sistem
pemrosesan transaksi dirancang agar data hanya diperbarui setelah transaksi selesai
dengan benar sehingga penundaan dalam pemrosesan tidak memengaruhi integritas sistem.
13.3 Arsitektur sistem yang dapat diandalkan 349
Ini bisa menjadi cara yang efisien dalam menggunakan perangkat keras jika server cadangan adalah salah
satu yang jarang digunakan untuk tugas-tugas berprioritas rendah. Jika terjadi masalah dengan server
utama, pemrosesannya ditransfer ke server cadangan, yang memberikan pekerjaan itu prioritas tertinggi.
Server yang direplikasi menyediakan redundansi tetapi biasanya tidak keragaman. Perangkat kerasnya adalah
biasanya identik dan mereka menjalankan versi perangkat lunak yang sama. Oleh karena itu, mereka dapat
mengatasi kegagalan perangkat keras dan kegagalan perangkat lunak yang dilokalisasi ke satu
mesin. Mereka tidak dapat mengatasi masalah desain perangkat lunak yang menyebabkan semua versi
perangkat lunak untuk gagal pada saat yang sama. Untuk menangani kegagalan desain perangkat lunak, sebuah sistem memiliki:
untuk memasukkan beragam perangkat lunak dan perangkat keras, seperti yang telah saya bahas di Bagian 13.1.
Keragaman dan redundansi perangkat lunak dapat diimplementasikan dalam sejumlah

gaya arsitektur. Saya menjelaskan beberapa di antaranya di sisa bagian ini.
13.3.1 Sistem proteksi

Sistem proteksi adalah sistem khusus yang diasosiasikan dengan beberapa sistem lain. Ini biasanya
merupakan sistem kontrol untuk beberapa proses, seperti proses pembuatan bahan kimia atau sistem
kontrol peralatan, seperti sistem pada driverless.
kereta. Contoh sistem proteksi mungkin sistem di kereta api yang mendeteksi jika
kereta telah melewati sinyal merah. Jika demikian, dan tidak ada indikasi bahwa kereta api
sistem kontrol memperlambat kereta, maka sistem perlindungan secara otomatis
menggunakan rem kereta untuk menghentikannya. Sistem proteksi secara mandiri memantau
lingkungannya dan, jika sensor menunjukkan masalah yang tidak ditangani oleh sistem yang dikendalikan,
maka sistem proteksi diaktifkan untuk mematikan sistem.
proses atau peralatan.
Gambar 13.3 mengilustrasikan hubungan antara sistem proteksi dan sistem yang dikendalikan. Sistem
proteksi memantau peralatan yang dikendalikan dan
lingkungan. Jika masalah terdeteksi, itu mengeluarkan perintah ke aktuator untuk menutup
turunkan sistem atau gunakan mekanisme perlindungan lain seperti membuka katup pelepas tekanan.
Perhatikan bahwa ada dua set sensor. Satu set digunakan untuk normal
sistem monitoring dan lainnya khusus untuk sistem proteksi. Dalam acara
kegagalan sensor, ada cadangan yang akan memungkinkan sistem perlindungan untuk melanjutkan
dalam operasi. Mungkin juga ada aktuator yang berlebihan dalam sistem.
Sistem perlindungan hanya mencakup fungsionalitas penting yang diperlukan untuk
memindahkan sistem dari keadaan yang berpotensi tidak aman ke keadaan aman (sistem shutdown). Dia
adalah contoh dari arsitektur toleransi kesalahan yang lebih umum di mana sistem utama didukung oleh
sistem cadangan yang lebih kecil dan lebih sederhana yang hanya mencakup penting
Kegunaan. Misalnya, perangkat lunak kontrol pesawat ulang-alik AS memiliki sistem cadangan yang
mencakup fungsionalitas 'sampaikan di rumah'; yaitu, sistem cadangan dapat mendarat
kendaraan jika sistem kontrol utama gagal.
Keuntungan dari arsitektur semacam ini adalah bahwa perangkat lunak sistem proteksi dapat
jauh lebih sederhana daripada perangkat lunak yang mengendalikan proses yang dilindungi. Satu-satunya
Fungsi sistem proteksi adalah untuk memantau operasi dan memastikan bahwa sistem
dibawa ke keadaan aman jika terjadi keadaan darurat. Oleh karena itu, adalah mungkin untuk berinvestasi
lebih banyak upaya dalam menghindari kesalahan dan deteksi kesalahan. Anda dapat memeriksa bahwa perangkat lunak
Lingkungan Sistem
Perlindungan
Sensor
Sensor
Perlindungan Kontrol
Sistem Sistem
Aktuator
Terkendali
Peralatan
Gambar 13.3 Arsitektur
sistem proteksi
spesifikasi benar dan konsisten dan perangkat lunak benar sehubungan dengan spesifikasinya.
Tujuannya adalah untuk memastikan bahwa keandalan sistem proteksi sedemikian rupa sehingga
memiliki kemungkinan kegagalan yang sangat rendah sesuai permintaan (katakanlah, 0,001).
Mengingat bahwa permintaan pada sistem proteksi seharusnya jarang terjadi, kemungkinan
kegagalan pada permintaan 1/1.000 berarti bahwa kegagalan sistem proteksi seharusnya sangat jarang terjadi.
13.3.2 Arsitektur pemantauan mandiri

Arsitektur self-monitoring adalah arsitektur sistem di mana sistem dirancang untuk memantau
operasinya sendiri dan mengambil beberapa tindakan jika masalah terdeteksi. Hal ini dicapai
dengan melakukan perhitungan pada saluran yang terpisah dan membandingkan output dari
perhitungan ini. Jika keluarannya identik dan tersedia pada waktu yang sama, maka dinilai bahwa
sistem beroperasi dengan benar. Jika outputnya berbeda, maka diasumsikan terjadi kegagalan.
Ketika ini terjadi, sistem biasanya akan memunculkan pengecualian kegagalan pada jalur keluaran
status, yang akan menyebabkan kontrol dipindahkan ke sistem lain. Hal ini diilustrasikan pada
Gambar 13.4.
Agar efektif dalam mendeteksi kesalahan perangkat keras dan perangkat lunak, pemantauan mandiri
sistem harus dirancang sedemikian rupa sehingga:
1. Perangkat keras yang digunakan di setiap saluran beragam. Dalam praktiknya, ini mungkin
berarti bahwa setiap saluran menggunakan jenis prosesor yang berbeda untuk melakukan
komputasi yang diperlukan, atau chipset yang membentuk sistem mungkin bersumber dari
pabrikan yang berbeda. Hal ini mengurangi kemungkinan kesalahan desain prosesor umum
yang mempengaruhi komputasi.
2. Perangkat lunak yang digunakan di setiap saluran beragam. Jika tidak, kesalahan perangkat
lunak yang sama dapat muncul pada waktu yang sama di setiap saluran. Saya membahas
kesulitan mencapai perangkat lunak yang benar-benar beragam di Bagian 13.3.4.

Status
Saluran 1
Nilai Masukan
Pemisah pembanding
Nilai Keluaran
Saluran 2
Gambar 13.4
Arsitektur pemantauan mandiri
Dengan sendirinya, arsitektur ini dapat digunakan dalam situasi di mana penting untuk
perhitungan yang benar, tetapi di mana ketersediaan tidak penting. Jika jawaban dari setiap
saluran berbeda, sistem dimatikan. Untuk banyak perawatan medis dan sistem diagnostik,
keandalan lebih penting daripada ketersediaan karena respons sistem yang salah dapat
menyebabkan pasien menerima perawatan yang salah. Namun, jika sistem hanya dimatikan jika
terjadi kesalahan, ini merupakan ketidaknyamanan tetapi pasien biasanya tidak akan dirugikan
oleh sistem.
Dalam situasi di mana ketersediaan tinggi diperlukan, Anda harus menggunakan beberapa
sistem pemeriksaan mandiri secara paralel. Anda memerlukan unit switching yang mendeteksi
kesalahan dan memilih hasil dari salah satu sistem, di mana kedua saluran menghasilkan
respons yang konsisten. Pendekatan semacam itu digunakan dalam sistem kontrol penerbangan
untuk pesawat seri Airbus 340, di mana lima komputer pemeriksaan mandiri digunakan. Gambar
13.5 adalah diagram sederhana yang menggambarkan organisasi ini.
Dalam sistem kontrol penerbangan Airbus, masing-masing komputer kontrol penerbangan
melakukan perhitungan secara paralel, menggunakan input yang sama. Output terhubung ke
filter perangkat keras yang mendeteksi jika status menunjukkan kesalahan dan, jika demikian,
output dari komputer itu dimatikan. Keluaran tersebut kemudian diambil dari sistem alternatif.
Oleh karena itu, ada kemungkinan empat komputer gagal dan operasi pesawat terus berlanjut.
Selama lebih dari 15 tahun beroperasi, tidak ada laporan situasi di mana kendali pesawat hilang
karena kegagalan total sistem kendali penerbangan.
Perancang sistem Airbus telah mencoba untuk mencapai keragaman dalam beberapa cara
berbeda:
1. Komputer kontrol penerbangan utama menggunakan prosesor yang berbeda dari yang kedua
sistem kontrol penerbangan ary.
2. Chipset yang digunakan di setiap saluran dalam sistem primer dan sekunder dipasok oleh
pabrikan yang berbeda.
3. Perangkat lunak dalam sistem kontrol penerbangan sekunder menyediakan fungsi kritis
hanya ality—ini kurang kompleks daripada perangkat lunak utama.
4. Perangkat lunak untuk setiap saluran di sistem primer dan sekunder dikembangkan
menggunakan bahasa pemrograman yang berbeda dan oleh tim yang berbeda.
5. Bahasa pemrograman yang berbeda digunakan dalam sistem sekunder dan primer.
Seperti yang saya bahas di bagian berikut, ini tidak menjamin keragaman tetapi mereka
mengurangi kemungkinan kegagalan umum di saluran yang berbeda.
Memasukkan Sistem Kontrol Penerbangan Utama 1 Keluaran
Status
Saluran 1
Saring
Keluaran
Pemisah pembanding
Saluran 2
Status
Sistem Kontrol Penerbangan Utama 2 Saring

Keluaran
Status
Sistem Kontrol Penerbangan Utama 3 Saring

Keluaran
Sistem Kontrol Penerbangan Sekunder 1
Status
Saluran 1
Saring
Keluaran
Pemisah pembanding
Saluran 2
Status
Sistem Kontrol Penerbangan Sekunder 2 Saring

Keluaran
Gambar 13.5
13.3.3 Pemrograman versi-N
Kontrol
Arsitektur self-monitoring adalah contoh sistem di mana pemrograman multiversi
penerbangan Airbus
sistem
digunakan untuk menyediakan redundansi dan keragaman perangkat lunak. Gagasan
arsitektur pemrograman multiversi ini diturunkan dari sistem perangkat keras di mana gagasan
triple modular redundancy (TMR) telah digunakan selama bertahun-tahun untuk
membangun sistem yang toleran terhadap kegagalan perangkat keras (Gambar 13.6).
Dalam sistem TMR, unit perangkat keras direplikasi tiga (atau terkadang lebih) kali.
Keluaran dari setiap unit diteruskan ke pembanding keluaran yang biasanya
diimplementasikan sebagai sistem pemungutan suara. Sistem ini membandingkan
semua inputnya dan, jika dua atau lebih adalah sama, maka nilai tersebut adalah output.
Jika salah satu unit gagal dan tidak menghasilkan output yang sama dengan unit
lainnya, outputnya diabaikan. Manajer kesalahan dapat mencoba memperbaiki unit yang
rusak secara otomatis tetapi jika ini tidak mungkin, sistem secara otomatis dikonfigurasi
ulang untuk mengeluarkan unit dari layanan. Sistem kemudian terus berfungsi dengan dua unit kerja.
Pendekatan toleransi kesalahan ini bergantung pada sebagian besar kegagalan perangkat
keras sebagai akibat dari kegagalan komponen daripada kesalahan desain. Oleh karena itu,
komponen cenderung gagal secara independen. Ini mengasumsikan bahwa, ketika beroperasi
penuh, semua unit perangkat keras sesuai dengan spesifikasi. Oleh karena itu ada kemungkinan
rendah kegagalan komponen simultan di semua unit perangkat keras.
A1
Memasukkan
A2 Keluaran
pemilih
Gambar 13.6 A3
Redundansi modular tiga kali lipat
Versi 1
Memasukkan
Versi 2 Keluaran
pemilih
Sepakat
Hasil
Versi 3
Kesalahan
Pengelola
Gambar 13.7 Pemrograman N Versi Perangkat Lunak
versi-N
Tentu saja, semua komponen dapat memiliki kesalahan desain yang sama dan dengan demikian
semua menghasilkan jawaban (salah) yang sama. Menggunakan unit perangkat keras yang memiliki
spesifikasi umum tetapi dirancang dan dibuat oleh produsen yang berbeda mengurangi kemungkinan
kegagalan mode umum tersebut. Diasumsikan bahwa kemungkinan tim yang berbeda membuat
kesalahan desain atau manufaktur yang sama kecil.
Pendekatan serupa dapat digunakan untuk perangkat lunak yang toleran terhadap kesalahan di
mana N versi beragam dari sistem perangkat lunak dijalankan secara paralel (Avizienis, 1985; Avizienis, 1995).
Pendekatan toleransi kesalahan perangkat lunak, diilustrasikan pada Gambar 13.7, telah digunakan
dalam sistem sinyal kereta api, sistem pesawat, dan sistem perlindungan reaktor.
Menggunakan spesifikasi umum, sistem perangkat lunak yang sama diimplementasikan oleh
sejumlah tim. Versi ini dijalankan pada komputer terpisah. Keluaran mereka dibandingkan dengan
menggunakan sistem pemungutan suara, dan keluaran yang tidak konsisten atau keluaran yang tidak
diproduksi pada waktunya akan ditolak. Setidaknya tiga versi sistem harus tersedia sehingga dua versi
harus konsisten jika terjadi satu kegagalan.
Pemrograman versi-N mungkin lebih murah daripada arsitektur yang memeriksa sendiri dalam
sistem yang membutuhkan tingkat ketersediaan yang tinggi. Namun, masih memerlukan beberapa tim
berbeda untuk mengembangkan versi perangkat lunak yang berbeda. Hal ini menyebabkan biaya
pengembangan perangkat lunak yang sangat tinggi. Akibatnya, pendekatan ini hanya digunakan dalam
sistem yang tidak praktis untuk menyediakan sistem perlindungan yang dapat melindungi dari kegagalan kritis keselamatan.
13.3.4 Keragaman perangkat lunak
Semua arsitektur toleransi kesalahan di atas bergantung pada keragaman perangkat lunak untuk
mencapai toleransi kesalahan. Hal ini didasarkan pada asumsi bahwa implementasi yang berbeda dari
spesifikasi yang sama (atau bagian dari spesifikasi, untuk sistem proteksi) adalah independen.
Mereka tidak boleh menyertakan kesalahan umum dan karenanya tidak akan gagal dengan cara yang sama, di
waktu yang sama. Hal ini membutuhkan perangkat lunak yang akan ditulis oleh tim yang berbeda
yang tidak boleh berkomunikasi selama proses pengembangan, sehingga mengurangi
kemungkinan kesalahpahaman umum atau salah tafsir spesifikasi.
Perusahaan yang mengadakan sistem dapat menyertakan kebijakan keragaman eksplisit yang
dimaksudkan untuk memaksimalkan perbedaan antara versi sistem. Sebagai contoh:
1. Dengan menyertakan persyaratan bahwa metode desain yang berbeda harus digunakan.
Misalnya, satu tim mungkin diminta untuk menghasilkan desain berorientasi objek dan tim
lain dapat menghasilkan desain berorientasi fungsi.
2. Dengan menetapkan bahwa implementasi harus ditulis dalam bahasa pemrograman yang
berbeda. Misalnya, dalam sistem tiga versi, Ada, C++, dan Java dapat digunakan untuk
menulis versi perangkat lunak.
3. Dengan membutuhkan penggunaan alat dan lingkungan pengembangan yang berbeda untuk sistem.
4. Secara eksplisit membutuhkan algoritma yang berbeda untuk digunakan di beberapa bagian
implementasi. Namun, ini membatasi kebebasan tim desain dan mungkin sulit untuk
menyesuaikan dengan persyaratan kinerja sistem.
Setiap tim pengembangan harus bekerja dengan spesifikasi sistem yang terperinci (kadang-
kadang disebut spesifikasi-V) yang diturunkan dari spesifikasi persyaratan sistem (Avizienis,
1995). Ini harus cukup rinci untuk memastikan bahwa tidak ada ambiguitas dalam spesifikasi.
Selain menentukan fungsionalitas sistem, spesifikasi rinci harus menentukan di mana output
sistem untuk perbandingan harus dihasilkan.
Idealnya, versi sistem yang beragam seharusnya tidak memiliki ketergantungan dan karenanya
harus gagal dengan cara yang sama sekali berbeda. Jika ini masalahnya, maka keandalan
keseluruhan dari sistem yang beragam diperoleh dengan mengalikan keandalan masing-masing saluran.
Jadi, jika setiap saluran memiliki probabilitas kegagalan pada permintaan 0,001, maka POFOD
keseluruhan dari sistem tiga saluran (dengan semua saluran independen) adalah satu juta kali
lebih besar daripada keandalan sistem saluran tunggal.
Namun, dalam praktiknya, mencapai independensi saluran sepenuhnya tidak mungkin. Telah
ditunjukkan secara eksperimental bahwa tim desain independen sering membuat kesalahan yang
sama atau salah memahami bagian spesifikasi yang sama (Brilliant, et., 1990; Knight dan Leveson,
1986; Leveson, 1995). Ada beberapa alasan untuk ini:
1. Anggota tim yang berbeda seringkali berasal dari latar belakang budaya yang sama dan
mungkin telah dididik dengan menggunakan pendekatan dan buku teks yang sama. Ini
berarti bahwa mereka mungkin menemukan hal yang sama sulit untuk dipahami dan
memiliki kesulitan yang sama dalam berkomunikasi dengan pakar domain. Sangat mungkin
bahwa mereka akan, secara independen, membuat kesalahan yang sama dan merancang algoritma yang sama untuk mem
2. Jika persyaratan tidak benar atau didasarkan pada kesalahpahaman tentang lingkungan
sistem, maka kesalahan ini akan tercermin dalam setiap implementasi sistem.
3. Dalam sistem kritis, spesifikasi V adalah dokumen terperinci berdasarkan persyaratan sistem,
yang memberikan detail lengkap kepada tim tentang bagaimana sistem seharusnya
13.4 Pemrograman yang dapat diandalkan 355
berperilaku baik. Tidak ada ruang untuk interpretasi oleh pengembang perangkat
lunak. Jika ada kesalahan dalam dokumen ini, maka ini akan disajikan ke semua tim
pengembangan dan diimplementasikan di semua versi sistem.
Salah satu cara untuk mengurangi kemungkinan kesalahan spesifikasi umum adalah
dengan mengembangkan spesifikasi rinci untuk sistem secara mandiri, dan untuk
menentukan spesifikasi dalam bahasa yang berbeda. Satu tim pengembangan mungkin
bekerja dari spesifikasi formal, yang lain dari model sistem berbasis negara bagian, dan
yang ketiga dari spesifikasi bahasa alami. Ini membantu menghindari beberapa kesalahan
interpretasi spesifikasi, tetapi tidak mengatasi masalah kesalahan spesifikasi. Ini juga
memperkenalkan kemungkinan kesalahan dalam terjemahan persyaratan, yang mengarah ke spesifikasi yang tida
Dalam analisis percobaan, Hatton (1997), menyimpulkan bahwa sistem tiga saluran
berada di antara lima hingga sembilan kali lebih dapat diandalkan daripada sistem saluran
tunggal. Dia menyimpulkan bahwa peningkatan keandalan yang dapat diperoleh dengan
mencurahkan lebih banyak sumber daya ke satu versi tidak dapat menandingi ini dan
pendekatan versi-N cenderung mengarah ke sistem yang lebih andal daripada pendekatan versi tunggal.
Namun, yang tidak jelas adalah apakah peningkatan keandalan dari sistem multiversi
sepadan dengan biaya pengembangan tambahan. Untuk banyak sistem, biaya tambahan
mungkin tidak dapat dibenarkan karena sistem versi tunggal yang dirancang dengan baik
mungkin sudah cukup baik. Hanya dalam sistem keselamatan dan misi kritis, di mana
biaya kegagalan sangat tinggi, perangkat lunak multiversi mungkin diperlukan. Bahkan
dalam situasi seperti itu (misalnya, sistem pesawat ruang angkasa), mungkin cukup untuk
menyediakan cadangan sederhana dengan fungsionalitas terbatas sampai sistem utama dapat diperbaiki dan dihi
13.4 Pemrograman yang dapat diandalkan
Secara umum, saya menghindari diskusi tentang pemrograman dalam buku ini karena
hampir tidak mungkin membahas pemrograman tanpa masuk ke detail bahasa
pemrograman tertentu. Sekarang ada begitu banyak pendekatan dan bahasa berbeda yang
digunakan untuk pengembangan perangkat lunak sehingga saya menghindari penggunaan
satu bahasa sebagai contoh dalam buku ini. Namun, ketika mempertimbangkan rekayasa
ketergantungan, ada serangkaian praktik pemrograman baik yang diterima yang cukup
universal dan yang membantu mengurangi kesalahan dalam sistem yang dikirimkan.
Daftar pedoman praktik yang baik ditunjukkan pada Gambar 13.8. Mereka dapat
diterapkan dalam bahasa pemrograman apa pun yang digunakan untuk pengembangan
sistem, meskipun cara penggunaannya bergantung pada bahasa dan notasi tertentu yang
digunakan untuk pengembangan sistem.
Pedoman 1: Kontrol visibilitas informasi dalam suatu program
Prinsip keamanan yang dianut oleh organisasi militer adalah prinsip 'need to know'. Hanya
orang-orang yang perlu mengetahui informasi tertentu untuk melaksanakan tugas mereka
yang diberikan informasi tersebut. Informasi yang tidak secara langsung relevan dengan
pekerjaan mereka ditahan.
Panduan pemrograman yang dapat diandalkan
1. Batasi visibilitas informasi dalam suatu program 2.

Periksa semua input untuk validitas 3. Sediakan pengendali
untuk semua pengecualian 4. Minimalkan penggunaan
konstruksi rawan kesalahan 5. Sediakan kemampuan restart
6. Periksa batas array 7. Sertakan batas waktu saat
memanggil komponen eksternal 8. Beri nama semua
konstanta yang mewakili nilai dunia nyata
Gambar 13.8 Pedoman

Saat memprogram, Anda harus mengadopsi prinsip analog untuk mengontrol akses
praktik yang baik ke variabel dan struktur data yang Anda gunakan. Komponen program hanya boleh
untuk pemrograman diizinkan mengakses data yang mereka butuhkan untuk implementasinya. Data program
yang dapat diandalkan
lain harus tidak dapat diakses, dan disembunyikan dari mereka. Jika Anda
menyembunyikan informasi, informasi tersebut tidak dapat dirusak oleh komponen
program yang tidak seharusnya menggunakannya. Jika antarmuka tetap sama,
representasi data dapat diubah tanpa mempengaruhi komponen lain dalam sistem.
Anda dapat mencapai ini dengan menerapkan struktur data dalam program Anda
sebagai tipe data abstrak. Tipe data abstrak adalah tipe data di mana struktur internal
dan representasi dari variabel tipe itu disembunyikan. Struktur dan atribut tipe tidak
terlihat secara eksternal dan semua akses ke data melalui operasi. Misalnya, Anda
mungkin memiliki tipe data abstrak yang mewakili antrian permintaan layanan. Operasi
harus mencakup get dan put, yang menambah dan menghapus item dari antrian, dan
operasi yang mengembalikan jumlah item dalam antrian. Anda mungkin awalnya
mengimplementasikan antrian sebagai array tetapi kemudian memutuskan untuk
mengubah implementasi ke daftar tertaut. Ini dapat dicapai tanpa perubahan kode
menggunakan antrian, karena representasi antrian tidak pernah diakses secara langsung.
Anda juga dapat menggunakan tipe data abstrak untuk menerapkan pemeriksaan
bahwa nilai yang ditetapkan berada dalam jangkauan. Misalnya, Anda ingin mewakili
suhu proses kimia, di mana suhu yang diizinkan berada dalam kisaran 20–200 derajat Celcius.
Dengan menyertakan pemeriksaan pada nilai yang ditetapkan dalam operasi tipe data
abstrak, Anda dapat memastikan bahwa nilai suhu tidak pernah berada di luar kisaran yang diperlukan.
Dalam beberapa bahasa berorientasi objek, Anda dapat mengimplementasikan tipe
data abstrak menggunakan definisi antarmuka, di mana Anda mendeklarasikan antarmuka
ke objek tanpa mengacu pada implementasinya. Misalnya, Anda dapat mendefinisikan
Antrian antarmuka, yang mendukung metode untuk menempatkan objek ke dalam
antrean, menghapusnya dari antrean, dan menanyakan ukuran antrean. Di kelas objek
yang mengimplementasikan antarmuka ini, atribut dan metode harus bersifat pribadi untuk kelas itu.
Pedoman 2: Periksa semua input untuk validitas
Semua program mengambil input dari lingkungannya dan memprosesnya. Spesifikasi

membuat asumsi tentang input ini yang mencerminkan penggunaannya di dunia nyata.
Misalnya, dapat diasumsikan bahwa nomor rekening bank selalu delapan digit
bilangan bulat positif. Namun, dalam banyak kasus, spesifikasi sistem tidak menentukan
tindakan apa yang harus diambil jika inputnya salah. Mau tidak mau, pengguna akan
melakukan kesalahan dan terkadang memasukkan data yang salah. Kadang-kadang,
seperti yang saya bahas di Bab 14, serangan berbahaya pada sistem mengandalkan
input yang salah dengan sengaja. Bahkan ketika input berasal dari sensor atau sistem
lain, sistem ini bisa salah dan memberikan nilai yang salah.
Oleh karena itu Anda harus selalu memeriksa validitas input segera setelah ini
dibaca dari lingkungan operasi program. Pemeriksaan yang terlibat jelas bergantung
pada input itu sendiri tetapi kemungkinan pemeriksaan yang dapat digunakan adalah sebagai berikut:
1. Pemeriksaan jangkauan Anda mungkin mengharapkan input berada dalam kisaran

tertentu. Misalnya, input yang mewakili probabilitas harus berada dalam kisaran
0,0 hingga 1,0; input yang mewakili suhu air cair harus antara 0 derajat Celcius
dan 100 derajat Celcius, dan seterusnya.
2. Pemeriksaan ukuran Anda mungkin mengharapkan input berupa sejumlah karakter

tertentu (misalnya, delapan karakter untuk mewakili rekening bank). Dalam kasus
lain, ukurannya mungkin tidak tetap, tetapi mungkin ada batas atas yang realistis.
Misalnya, tidak mungkin nama seseorang memiliki lebih dari 40 karakter.
3. Pengecekan representasi Anda mungkin mengharapkan input dari tipe tertentu, yang
direpresentasikan dengan cara standar. Misalnya, nama orang tidak termasuk
karakter numerik, alamat email terdiri dari dua bagian, dipisahkan oleh tanda @,
dll.
4. Pengecekan kewajaran Jika suatu input adalah salah satu dari deret dan Anda
mengetahui beberapa hal tentang hubungan antara anggota deret tersebut, maka
Anda dapat memeriksa apakah nilai input masuk akal. Misalnya, jika nilai input
mewakili pembacaan meteran listrik rumah tangga, maka Anda akan mengharapkan
jumlah listrik yang digunakan kira-kira sama dengan periode yang sama di tahun
sebelumnya. Tentu saja, akan ada variasi tetapi urutan perbedaan besaran
menunjukkan bahwa masalah telah muncul.
Tindakan yang Anda ambil jika pemeriksaan validasi input gagal bergantung pada
jenis sistem yang diterapkan. Dalam beberapa kasus, Anda melaporkan masalah
tersebut kepada pengguna dan meminta agar nilainya dimasukkan kembali. Jika nilai
berasal dari sensor, Anda dapat menggunakan nilai valid terbaru. Dalam sistem waktu
nyata tertanam, Anda mungkin harus memperkirakan nilai berdasarkan riwayat, sehingga sistem dapat terus b
Pedoman 3: Berikan penangan untuk semua pengecualian
Selama eksekusi program, kesalahan atau kejadian tak terduga pasti terjadi. Ini mungkin
timbul karena kesalahan program atau mungkin akibat dari keadaan eksternal yang
tidak terduga. Kesalahan atau kejadian tak terduga yang terjadi selama eksekusi
program disebut 'pengecualian'. Contoh pengecualian mungkin kegagalan daya sistem,
upaya untuk mengakses data yang tidak ada, atau overflow atau underflow numerik.
Bagian Kode
Aliran Kontrol
Normal
Pengecualian Terdeteksi
Keluar Normal
Pengecualian
Pengolahan
Gambar 13.9 Penanganan
pengecualian Kode Penanganan Pengecualian
Pengecualian mungkin disebabkan oleh kondisi perangkat keras atau perangkat lunak. Ketika
pengecualian terjadi, itu harus dikelola oleh sistem. Ini dapat dilakukan di dalam program itu
sendiri atau mungkin melibatkan transfer kontrol ke mekanisme penanganan pengecualian sistem.
Biasanya, mekanisme manajemen pengecualian sistem melaporkan kesalahan dan mematikan
eksekusi. Oleh karena itu, untuk memastikan bahwa pengecualian program tidak menyebabkan
kegagalan sistem, Anda harus menentukan penangan pengecualian untuk semua kemungkinan
pengecualian yang mungkin muncul, dan memastikan bahwa semua pengecualian terdeteksi dan ditangani secara eksplisit.
Dalam bahasa pemrograman seperti C, pernyataan if harus digunakan untuk mendeteksi
pengecualian dan untuk mentransfer kontrol ke kode penanganan pengecualian. Ini berarti bahwa
Anda harus secara eksplisit memeriksa pengecualian di mana pun dalam program itu mungkin terjadi.
Namun, pendekatan ini menambah kompleksitas yang signifikan untuk tugas penanganan
pengecualian, meningkatkan kemungkinan Anda akan membuat kesalahan dan karena itu salah
menangani pengecualian.
Beberapa bahasa pemrograman, seperti Java, C++, dan Ada, menyertakan konstruksi yang
mendukung penanganan pengecualian sehingga Anda tidak memerlukan pernyataan kondisional
tambahan untuk memeriksa pengecualian. Bahasa pemrograman ini menyertakan tipe bawaan
khusus (sering disebut Pengecualian) dan pengecualian yang berbeda dapat dideklarasikan sebagai tipe ini.
Ketika situasi luar biasa terjadi, pengecualian ditandai dan sistem waktu berjalan bahasa
mentransfer kontrol ke penangan pengecualian. Ini adalah bagian kode yang menyatakan nama
pengecualian dan tindakan yang sesuai untuk menangani setiap pengecualian (Gambar 13.9).
Perhatikan bahwa pengendali pengecualian berada di luar aliran kontrol normal dan bahwa aliran
kontrol normal ini tidak dilanjutkan setelah pengecualian ditangani.
Penangan pengecualian biasanya melakukan satu atau lebih dari tiga hal:
1. Memberi sinyal ke komponen tingkat yang lebih tinggi bahwa pengecualian telah terjadi, dan
memberikan informasi kepada komponen tersebut tentang jenis pengecualian. Anda
menggunakan pendekatan ini ketika satu komponen memanggil yang lain dan komponen
pemanggil perlu mengetahui apakah komponen yang dipanggil telah berhasil dieksekusi.
Jika tidak, terserah pada komponen pemanggil untuk mengambil tindakan untuk memulihkan dari masalah.
2. Lakukan beberapa pemrosesan alternatif dari yang semula dimaksudkan.

Oleh karena itu, penangan pengecualian mengambil beberapa tindakan untuk memulihkan
dari masalah. Pemrosesan kemudian dapat berlanjut seperti biasa atau penangan pengecualian
mungkin menunjukkan bahwa pengecualian telah terjadi sehingga komponen pemanggil

mengetahui masalah tersebut.
3. Melewati kontrol ke sistem pendukung run-time yang menangani pengecualian. Ini sering menjadi
default ketika kesalahan terjadi dalam sebuah program (misalnya, ketika nilai numerik meluap).
Tindakan biasa dari sistem run-time adalah menghentikan pemrosesan. Anda hanya boleh
menggunakan pendekatan ini jika memungkinkan untuk memindahkan sistem ke status aman
dan diam, sebelum menyerahkan kontrol ke sistem run-time.
Menangani pengecualian dalam suatu program memungkinkan untuk mendeteksi dan

memulihkan dari beberapa kesalahan input dan kejadian eksternal yang tidak terduga. Dengan
demikian, ia memberikan tingkat toleransi kesalahan—program mendeteksi kesalahan dan dapat
mengambil tindakan untuk memulihkannya. Karena sebagian besar kesalahan input dan kejadian
eksternal yang tidak terduga biasanya bersifat sementara, seringkali dimungkinkan untuk melanjutkan operasi normal setelah
Pedoman 4: Minimalkan penggunaan konstruksi rawan kesalahan
Kesalahan dalam program, dan karena itu banyak kegagalan program, biasanya merupakan
konsekuensi dari kesalahan manusia. Pemrogram membuat kesalahan karena mereka kehilangan
jejak banyak hubungan antara variabel keadaan. Mereka menulis pernyataan program yang
menghasilkan perilaku tak terduga dan perubahan status sistem. Orang akan selalu membuat
kesalahan, tetapi pada akhir 1960-an menjadi jelas bahwa beberapa pendekatan pemrograman lebih
mungkin untuk memasukkan kesalahan ke dalam program daripada yang lain.
Beberapa konstruksi bahasa pemrograman dan teknik pemrograman secara inheren rawan
kesalahan dan karenanya harus dihindari atau, setidaknya, digunakan sesedikit mungkin.
Konstruksi yang berpotensi rawan kesalahan meliputi:
1. Pernyataan cabang (go-to) tanpa syarat Bahaya pernyataan go-to telah dikenal sejak tahun 1968
(Dijkstra, 1968) dan, sebagai akibatnya, ini telah dikeluarkan dari bahasa pemrograman modern.
Namun, mereka masih diperbolehkan dalam bahasa seperti C. Penggunaan pernyataan masuk
mengarah ke 'kode spageti' yang kusut dan sulit dipahami dan di-debug.
2. Bilangan floating-point Representasi bilangan floating-point dalam kata memori dengan panjang
tetap secara inheren tidak tepat. Ini adalah masalah khusus ketika angka dibandingkan karena
ketidaktepatan representasi dapat menyebabkan perbandingan yang tidak valid. Misalnya,
3.00000000 kadang-kadang dapat direpresentasikan sebagai 2.99999999 dan kadang-kadang
sebagai 3.000.00001. Perbandingan akan menunjukkan ini tidak setara. Angka titik tetap, di
mana angka direpresentasikan ke sejumlah tempat desimal tertentu, umumnya lebih aman
karena perbandingan yang tepat dimungkinkan.
3. Pointer Bahasa pemrograman seperti C dan C++ mendukung konstruksi tingkat rendah yang
disebut pointer, yang menyimpan alamat yang merujuk langsung ke area memori mesin
(mereka menunjuk ke lokasi memori). Kesalahan dalam penggunaan penunjuk bisa berakibat
fatal jika diatur secara tidak benar dan oleh karena itu menunjuk ke kesalahan
daerah ingatan. Mereka juga membuat pemeriksaan terikat array dan struktur lain lebih sulit
untuk diterapkan.
4. Alokasi memori dinamis Memori program dapat dialokasikan pada saat run-time daripada pada
waktu kompilasi. Bahayanya adalah bahwa memori mungkin tidak dialokasikan dengan benar,
sehingga pada akhirnya sistem kehabisan memori yang tersedia.
Ini bisa menjadi kesalahan yang sangat sulit untuk dideteksi karena sistem dapat berjalan
sukses sepenuhnya untuk waktu yang lama sebelum masalah terjadi.
5. Paralelisme Ketika proses dijalankan secara bersamaan, mungkin ada ketergantungan waktu
yang halus di antara mereka. Masalah pengaturan waktu biasanya tidak dapat dideteksi oleh
inspeksi program, dan kombinasi khusus dari keadaan yang menyebabkan masalah
pengaturan waktu mungkin tidak terjadi selama pengujian sistem. Paralelisme mungkin tidak
dapat dihindari, tetapi penggunaannya harus dikontrol dengan hati-hati untuk meminimalkan
ketergantungan antar proses.
6. Rekursi Ketika suatu prosedur atau metode memanggil dirinya sendiri atau memanggil prosedur
lain, yang kemudian memanggil prosedur pemanggilan asli, ini disebut 'rekursi'. Penggunaan
rekursi dapat menghasilkan program yang ringkas; namun mungkin sulit untuk mengikuti
logika program rekursif. Oleh karena itu, kesalahan pemrograman lebih sulit untuk dideteksi.
Kesalahan rekursi dapat mengakibatkan alokasi semua memori sistem saat variabel tumpukan
sementara dibuat.
7. Interupsi Ini adalah cara untuk memaksa kontrol untuk mentransfer ke bagian kode terlepas dari
kode yang sedang dieksekusi. Bahayanya sudah jelas; interupsi dapat menyebabkan operasi
kritis dihentikan.
8. Warisan Masalah dengan pewarisan dalam pemrograman berorientasi objek adalah bahwa kode
yang terkait dengan suatu objek tidak semuanya di satu tempat. Hal ini membuat lebih sulit
untuk memahami perilaku objek. Oleh karena itu, kemungkinan besar kesalahan pemrograman
akan terlewatkan. Selanjutnya, pewarisan, bila dikombinasikan dengan pengikatan dinamis,
dapat menyebabkan masalah waktu pada saat run-time. Instance yang berbeda dari suatu
metode mungkin terikat ke panggilan, tergantung pada tipe parameter. Akibatnya, jumlah
waktu yang berbeda akan dihabiskan untuk mencari contoh metode yang benar.
9. Aliasing Ini terjadi ketika lebih dari satu nama digunakan untuk merujuk ke entitas yang sama
dalam suatu program; misalnya, jika dua pointer dengan nama berbeda menunjuk ke lokasi
memori yang sama. Sangat mudah bagi pembaca program untuk melewatkan pernyataan
yang mengubah entitas ketika mereka memiliki beberapa nama untuk dipertimbangkan.
10. Array tak terbatas Dalam bahasa seperti C, array hanyalah cara mengakses memori dan Anda
dapat membuat tugas di luar akhir array. Sistem run time tidak memeriksa bahwa tugas benar-
benar merujuk ke elemen dalam array. Buffer overflow, di mana penyerang dengan sengaja
membuat program untuk menulis memori di luar akhir buffer yang diimplementasikan sebagai
array, adalah kerentanan keamanan yang diketahui.
11. Pemrosesan input default Beberapa sistem menyediakan default untuk pemrosesan input,
terlepas dari input yang disajikan ke sistem. Ini adalah celah keamanan
bahwa penyerang dapat mengeksploitasi dengan menghadirkan program dengan input tak
terduga yang tidak ditolak oleh sistem.
Beberapa standar untuk pengembangan sistem kritis keselamatan sepenuhnya melarang

penggunaan konstruksi ini. Namun, posisi ekstrem seperti itu biasanya tidak praktis.
Semua konstruksi dan teknik ini berguna, meskipun harus digunakan dengan hati-hati. Jika
memungkinkan, efek yang berpotensi berbahaya harus dikendalikan dengan menggunakannya
dalam tipe data atau objek abstrak. Ini bertindak sebagai 'firewall' alami yang membatasi
kerusakan yang disebabkan jika terjadi kesalahan.
Pedoman 5: Menyediakan kemampuan restart
Banyak sistem informasi organisasi didasarkan pada transaksi singkat di mana pemrosesan
input pengguna membutuhkan waktu yang relatif singkat. Sistem ini dirancang sedemikian rupa
sehingga perubahan pada basis data sistem hanya diselesaikan setelah semua pemrosesan
lainnya berhasil diselesaikan. Jika terjadi kesalahan selama pemrosesan, basis data tidak
diperbarui sehingga tidak menjadi tidak konsisten. Hampir semua sistem e-niaga, di mana Anda
hanya berkomitmen untuk pembelian Anda di layar akhir, bekerja dengan cara ini.
Interaksi pengguna dengan sistem e-commerce biasanya berlangsung beberapa menit dan
melibatkan pemrosesan minimal. Transaksi basis data singkat, dan biasanya selesai dalam
waktu kurang dari satu detik. Namun, jenis sistem lain seperti sistem CAD dan sistem pengolah
kata melibatkan transaksi yang panjang. Dalam sistem transaksi yang panjang, waktu antara
mulai menggunakan sistem dan menyelesaikan pekerjaan mungkin beberapa menit atau jam.
Jika sistem gagal selama transaksi yang lama, maka semua pekerjaan mungkin hilang. Demikian
pula, dalam sistem komputasi intensif seperti beberapa sistem e-sains, menit atau jam
pemrosesan mungkin diperlukan untuk menyelesaikan perhitungan.
Semua waktu ini hilang jika terjadi kegagalan sistem.
Di semua jenis sistem ini, Anda harus menyediakan kemampuan memulai ulang yang
didasarkan pada penyimpanan salinan data yang dikumpulkan atau dihasilkan selama
pemrosesan. Fasilitas restart harus memungkinkan sistem untuk restart menggunakan salinan
ini, daripada harus memulai dari awal. Salinan ini kadang-kadang disebut titik pemeriksaan.
Sebagai contoh:
1. Dalam sistem e-commerce, Anda dapat menyimpan salinan formulir yang diisi oleh pengguna
dan mengizinkan mereka untuk mengakses dan mengirimkan formulir ini tanpa harus mengisinya lagi.
2. Dalam transaksi yang panjang atau sistem yang intensif secara komputasi, Anda dapat
menyimpan data secara otomatis setiap beberapa menit dan, jika terjadi kegagalan sistem,
mulai ulang dengan data yang terakhir disimpan. Anda juga harus mengizinkan kesalahan
pengguna dan menyediakan cara bagi pengguna untuk kembali ke pos pemeriksaan terbaru dan mulai lagi dari sana
Jika pengecualian terjadi dan tidak mungkin untuk melanjutkan operasi normal, Anda dapat
menangani pengecualian menggunakan pemulihan kesalahan mundur. Ini berarti Anda mengatur
ulang status sistem ke status tersimpan di pos pemeriksaan dan memulai kembali operasi dari titik itu.
Pedoman 6: Periksa batas array
Semua bahasa pemrograman memungkinkan spesifikasi array—struktur data sekuensial

yang diakses menggunakan indeks numerik. Array ini biasanya diletakkan di area yang
berdekatan dalam memori kerja suatu program. Array ditentukan untuk menjadi ukuran
tertentu, yang mencerminkan bagaimana mereka digunakan. Misalnya, jika Anda ingin
mewakili usia hingga 10.000 orang, maka Anda dapat mendeklarasikan larik dengan 10.000
lokasi untuk menyimpan data usia.
Beberapa bahasa pemrograman, seperti Java, selalu memeriksa bahwa ketika suatu nilai
dimasukkan ke dalam larik, indeks berada di dalam larik itu. Jadi, jika array A diindeks dari 0
hingga 10.000, upaya untuk memasukkan nilai ke dalam elemen A [-5] atau A [12345] akan
menghasilkan pengecualian. Namun, bahasa pemrograman seperti C dan C++ tidak secara
otomatis menyertakan pemeriksaan terikat array dan hanya menghitung offset dari awal
array. Oleh karena itu, A [12345] akan mengakses kata yang berada di 12345 lokasi dari awal
larik, terlepas dari apakah ini bagian dari larik atau tidak.
Alasan mengapa bahasa-bahasa ini tidak menyertakan pemeriksaan terikat-array otomatis

adalah karena ini menimbulkan overhead setiap kali larik diakses. Mayoritas akses array
sudah benar sehingga pemeriksaan terikat sebagian besar tidak diperlukan dan meningkatkan
waktu eksekusi program. Namun, kurangnya pemeriksaan terikat menyebabkan kerentanan
keamanan, seperti buffer overflow, yang saya bahas di Bab 14. Secara lebih umum, ini
memperkenalkan kerentanan ke dalam sistem yang dapat mengakibatkan kegagalan sistem.
Jika Anda menggunakan bahasa yang tidak menyertakan pemeriksaan terikat array, Anda
harus selalu menyertakan kode tambahan yang memastikan indeks array berada dalam batas.
Ini mudah dicapai dengan mengimplementasikan array sebagai tipe data abstrak, seperti
yang telah saya bahas di Panduan 1.
Pedoman 7: Sertakan batas waktu saat memanggil komponen eksternal
Dalam sistem terdistribusi, komponen sistem dijalankan pada komputer yang berbeda dan
panggilan dilakukan di seluruh jaringan dari komponen ke komponen. Untuk menerima
beberapa layanan, komponen A dapat memanggil komponen B. A menunggu B untuk
merespons sebelum melanjutkan eksekusi. Namun, jika komponen B gagal merespons
karena suatu alasan, maka komponen A tidak dapat melanjutkan. Itu hanya menunggu
jawaban tanpa batas. Seseorang yang menunggu respons dari sistem melihat kegagalan
sistem diam, tanpa respons dari sistem. Mereka tidak memiliki alternatif selain mematikan
proses menunggu dan memulai ulang sistem.
Untuk menghindari hal ini, Anda harus selalu menyertakan batas waktu saat memanggil
komponen eksternal. Timeout adalah asumsi otomatis bahwa komponen yang dipanggil telah
gagal dan tidak akan menghasilkan respons. Anda menentukan periode waktu di mana Anda
mengharapkan untuk menerima respons dari komponen yang dipanggil. Jika Anda belum
menerima respons dalam waktu itu, Anda menganggap kegagalan dan mengambil kembali kendali dari komponen yang d
Anda kemudian dapat mencoba memulihkan dari kegagalan atau memberi tahu pengguna sistem apa yang
telah terjadi dan membiarkan mereka memutuskan apa yang harus dilakukan.
Bab 13 Poin -poin penting 363
Pedoman 8: Sebutkan semua konstanta yang mewakili nilai dunia nyata
Semua program non-trivial menyertakan sejumlah nilai konstan yang mewakili nilai entitas
dunia nyata. Nilai-nilai ini tidak diubah saat program dijalankan.
Kadang-kadang, ini adalah konstanta absolut dan tidak pernah berubah (misalnya, kecepatan
cahaya) tetapi lebih sering mereka adalah nilai yang berubah relatif lambat dari waktu ke
waktu. Misalnya, program untuk menghitung pajak pribadi akan menyertakan konstanta yang
merupakan tarif pajak saat ini. Ini berubah dari tahun ke tahun dan karenanya program harus
diperbarui dengan nilai konstanta yang baru.
Anda harus selalu menyertakan bagian dalam program Anda di mana Anda memberi
nama semua nilai konstanta dunia nyata yang digunakan. Saat menggunakan konstanta, Anda
harus merujuknya dengan nama daripada nilainya. Ini memiliki dua keuntungan sejauh
menyangkut kemampuan ketergantungan:
1. Anda cenderung tidak membuat kesalahan dan menggunakan nilai yang salah. Sangat
mudah untuk salah ketik nomor dan sistem akan sering tidak dapat mendeteksi
kesalahan. Misalnya, katakanlah tarif pajak adalah 34%. Kesalahan transposisi sederhana
dapat menyebabkan kesalahan ketik sebagai 43%. Namun, jika Anda salah mengetik
nama (seperti Tarif pajak standar), ini biasanya dideteksi oleh kompilator sebagai variabel yang tidak dideklarasik
2. Ketika suatu nilai berubah, Anda tidak perlu melihat keseluruhan program untuk menemukan
di mana Anda telah menggunakan nilai tersebut. Yang perlu Anda lakukan adalah
mengubah nilai yang terkait dengan deklarasi konstan. Nilai baru kemudian secara
otomatis disertakan di mana saja yang dibutuhkan.
POIN KUNCI
Keandalan dalam suatu program dapat dicapai dengan menghindari pengenalan kesalahan, dengan mendeteksi dan menghilangkan
kesalahan sebelum penerapan sistem, dan dengan memasukkan fasilitas toleransi kesalahan yang memungkinkan sistem tetap
beroperasi setelah kesalahan menyebabkan kegagalan sistem.
Penggunaan redundansi dan keragaman dalam perangkat keras, proses perangkat lunak, dan sistem perangkat lunak adalah
penting untuk pengembangan sistem yang dapat diandalkan.
Penggunaan proses yang terdefinisi dengan baik dan dapat diulang sangat penting jika kesalahan dalam suatu sistem ingin
diminimalkan. Proses tersebut harus mencakup kegiatan verifikasi dan validasi di semua tahap, mulai dari
definisi kebutuhan hingga implementasi sistem.
Arsitektur sistem yang dapat diandalkan adalah arsitektur sistem yang dirancang untuk toleransi kesalahan.
Ada sejumlah gaya arsitektur yang mendukung toleransi kesalahan termasuk sistem perlindungan,
arsitektur pemantauan mandiri, dan pemrograman versi-N.
Keragaman perangkat lunak sulit dicapai karena hampir tidak mungkin untuk memastikan bahwa setiap versi perangkat lunak benar-
benar independen.
Pemrograman yang dapat diandalkan bergantung pada penyertaan redundansi dalam program untuk memeriksa
validitas input dan nilai variabel program.
Beberapa konstruksi dan teknik pemrograman, seperti pernyataan masuk, pointer, rekursi, pewarisan, dan angka
floating-point, secara inheren rawan kesalahan. Anda harus mencoba menghindari konstruksi ini saat
mengembangkan sistem yang dapat diandalkan.
BACAAN LEBIH LANJUT
Teknik dan Implementasi Toleransi Kesalahan Perangkat Lunak. Diskusi komprehensif tentang teknik untuk mencapai
toleransi kesalahan perangkat lunak dan arsitektur toleransi kesalahan. Buku ini juga mencakup masalah umum ketergantungan
perangkat lunak. (LL Pullum, Artech House, 2001.)
'Rekayasa Keandalan Perangkat Lunak: Peta Jalan'. Makalah survei oleh seorang peneliti terkemuka dalam keandalan perangkat lunak
ini merangkum keadaan seni dalam rekayasa keandalan perangkat lunak serta membahas tantangan penelitian di masa depan. (MR
Lyu, Proc. Future of Software Engineering, IEEE Computer Society, 2007.) http://dx.doi.org/10.1109/FOSE.2007.24.
LATIHAN
13.1. Berikan empat alasan mengapa hampir tidak pernah efektif biaya bagi perusahaan untuk memastikan bahwa
perangkat lunak bebas dari kesalahan.
13.2. Jelaskan mengapa masuk akal untuk mengasumsikan bahwa penggunaan proses yang dapat diandalkan akan mengarah pada
pembuatan perangkat lunak yang dapat diandalkan.
13.3. Berikan dua contoh beragam, aktivitas berlebihan yang mungkin dimasukkan ke dalam proses yang dapat
diandalkan.
13.4. Apa karakteristik umum dari semua gaya arsitektur yang diarahkan untuk mendukung toleransi kesalahan perangkat lunak?
13.5. Bayangkan Anda menerapkan sistem kontrol berbasis perangkat lunak. Sarankan keadaan di mana akan tepat untuk
menggunakan arsitektur yang toleran terhadap kesalahan, dan jelaskan mengapa pendekatan ini diperlukan.
13.6. Anda bertanggung jawab atas desain sakelar komunikasi yang harus menyediakan ketersediaan 24/7, tetapi tidak kritis
terhadap keselamatan. Berikan alasan untuk jawaban Anda, sarankan gaya arsitektur yang mungkin digunakan untuk
sistem ini.
13.7. Disarankan bahwa perangkat lunak kontrol untuk mesin terapi radiasi, yang digunakan untuk merawat pasien dengan kanker,
harus diimplementasikan menggunakan pemrograman versi-N. Beri komentar apakah menurut Anda ini saran yang bagus
atau tidak.
13.8. Berikan dua alasan mengapa versi yang berbeda dari sistem yang didasarkan pada keragaman perangkat lunak mungkin gagal!
dengan cara yang sama.
13.9. Jelaskan mengapa Anda harus secara eksplisit menangani semua pengecualian dalam sistem yang dimaksudkan untuk memiliki
tingkat ketersediaan yang tinggi.
13.10. Penggunaan teknik untuk produksi perangkat lunak yang aman, seperti yang dibahas dalam bab ini,
jelas termasuk biaya tambahan yang cukup besar. Biaya tambahan apa yang dapat dibenarkan jika 100 nyawa akan
diselamatkan selama masa pakai sistem 15 tahun? Apakah biaya yang sama dapat dibenarkan jika 10 nyawa terselamatkan?
Berapa nilai hidup? Apakah kemampuan penghasilan orang-orang yang terkena dampak membuat perbedaan pada penilaian
ini?
REFERENSI
Avizienis, A. (1985). 'Pendekatan Versi-N untuk Perangkat Lunak Toleran Kesalahan'. IEEE Trans. pada Software Eng., SE-11
(12), 1491–501.
Avizienis, AA (1995). 'Sebuah Metodologi Pemrograman N-Version'. Dalam Toleransi Kesalahan Perangkat Lunak.
Lyu, MR (ed.). Chichester: John Wiley & Sons. 23–46.
Boehm, B. (2002). 'Bersiaplah untuk Metode Agile, Dengan Hati-hati'. Komputer IEEE, 35 (1), 64–9.
Brilian, SS, Knight, JC dan Leveson, NG (1990). 'Analisis Kesalahan dalam Eksperimen Perangkat Lunak Versi-N'. IEEE Trans.
Tentang Rekayasa Perangkat Lunak, 16 (2), 238–47.
Dijkstra, EW (1968). 'Pernyataan Goto dianggap berbahaya'. Kom. ACM., 11 (3), 147–8.
Hatton, L. (1997). 'Desain versi-N versus satu versi bagus'. Perangkat Lunak IEEE, 14 (6), 71–6.
Knight, JC dan Leveson, NG (1986). 'Evaluasi eksperimental asumsi independensi dalam pemrograman multi-versi'.
IEEE Trans. tentang Rekayasa Perangkat Lunak., SE-12 (1), 96–109.
Leveson, NG (1995). Safeware: Keamanan Sistem dan Komputer. Membaca, Mass.: Addison-Wesley.
Lindvall, M., Muthig, D., Dagnino, A., Wallin, C., Stupperich, M., Kiefer, D., Mei, J. dan Kahkonen, T.
(2004). 'Pengembangan Perangkat Lunak Tangkas di Organisasi Besar'. Komputer IEEE, 37 (12), 26–34.
Parnas, DL, Van Schouwen, J. dan Shu, PK (1990). 'Evaluasi Perangkat Lunak Keselamatan-Kritis'. Kom.
ACM, 33 (6), 636–51.
Pulum, LL (2001). Teknik dan Implementasi Toleransi Kesalahan Perangkat Lunak. Norwood, Mass.: Rumah Artech.
Storey, N. (1996). Sistem Komputer Keselamatan-Kritis. Harlow, Inggris: Addison-Wesley.
Torres-Pomales, W. (2000). 'Toleransi Kesalahan Perangkat Lunak: Tutorial.' http://

ntrs.nasa.gov/archive/nasa/casi./20000120144_2000175863.pdf.
14
Rekayasa keamanan
Tujuan
Tujuan dari bab ini adalah untuk memperkenalkan isu-isu yang harus dipertimbangkan
ketika Anda merancang sistem aplikasi yang aman. Setelah Anda membaca bab ini, Anda
akan:
memahami perbedaan antara keamanan aplikasi dan keamanan infrastruktur;
mengetahui bagaimana penilaian risiko siklus hidup dan penilaian risiko operasional digunakan
untuk memahami masalah keamanan yang memengaruhi desain sistem;
waspadai arsitektur perangkat lunak dan pedoman desain untuk keamanan

pengembangan sistem;
memahami gagasan tentang kemampuan bertahan sistem dan mengapa analisis

kemampuan bertahan penting untuk sistem perangkat lunak yang kompleks.
Isi
14.1 Manajemen risiko keamanan 14.2
Desain untuk keamanan 14.3 Ketahanan
sistem
Bab 14 Rekayasa Keamanan 367
Meluasnya penggunaan Internet pada 1990-an memperkenalkan tantangan baru bagi para
insinyur perangkat lunak—merancang dan mengimplementasikan sistem yang aman. Karena
semakin banyak sistem yang terhubung ke Internet, berbagai serangan eksternal yang berbeda
dirancang untuk mengancam sistem ini. Masalah memproduksi sistem yang dapat diandalkan
sangat meningkat. Insinyur sistem harus mempertimbangkan ancaman dari penyerang jahat dan
terampil secara teknis serta masalah yang diakibatkan oleh kesalahan gigi dalam proses
pengembangan.
Sekarang penting untuk merancang sistem untuk menahan serangan eksternal dan untuk
pulih dari serangan tersebut. Tanpa tindakan pencegahan keamanan, hampir tidak dapat dihindari
bahwa penyerang akan menjanjikan sistem jaringan. Mereka mungkin menyalahgunakan
perangkat keras sistem, mencuri data rahasia, atau mengganggu layanan yang ditawarkan oleh
sistem. Rekayasa keamanan sistem adalah aspek yang semakin penting dari proses rekayasa sistem.
Rekayasa keamanan berkaitan dengan pengembangan dan evolusi sistem yang dapat
menahan serangan berbahaya, yang dimaksudkan untuk merusak sistem atau datanya.
Rekayasa keamanan perangkat lunak adalah bagian dari bidang keamanan komputer yang lebih umum.
Ini telah menjadi prioritas bagi bisnis dan individu karena semakin banyak penjahat mencoba
mengeksploitasi sistem jaringan untuk tujuan ilegal. Insinyur perangkat lunak harus menyadari
ancaman keamanan yang dihadapi oleh sistem dan cara-cara di mana ancaman ini dapat
dinetralkan.
Tujuan saya dalam bab ini adalah untuk memperkenalkan rekayasa keamanan kepada
insinyur perangkat lunak, dengan fokus pada masalah desain yang memengaruhi keamanan
aplikasi. Bab ini bukan tentang keamanan komputer secara keseluruhan dan tidak mencakup
topik-topik seperti enkripsi, kontrol akses, mekanisme otorisasi, virus dan kuda Troya, dll. Ini
dijelaskan secara rinci dalam teks umum tentang keamanan komputer (Anderson, 2008). ; Bishop,
2005; Pfleeger dan Pfleeger, 2007).
Bab ini menambah diskusi tentang keamanan di bagian lain buku ini. Anda harus
baca materi di sini bersama dengan:
• Bagian 10.1, di mana saya menjelaskan bagaimana keamanan dan ketergantungan terkait erat;
• Bagian 10.4, di mana saya memperkenalkan terminologi keamanan;
• Bagian 12.1, di mana saya memperkenalkan gagasan umum tentang spesifikasi yang digerakkan oleh risiko;
• Bagian 12.4, di mana saya membahas masalah umum spesifikasi persyaratan keamanan;
• Bagian 15.3, di mana saya menjelaskan sejumlah pendekatan untuk pengujian keamanan.
Ketika Anda mempertimbangkan masalah keamanan, Anda harus mempertimbangkan

perangkat lunak aplikasi (sistem kontrol, sistem informasi, dll.) dan infrastruktur di mana sistem
ini dibangun (Gambar 14.1). Infrastruktur untuk aplikasi yang kompleks dapat mencakup:
• platform sistem operasi, seperti Linux atau Windows;
• aplikasi umum lainnya yang berjalan pada sistem tersebut, seperti browser web dan
klien email;
• sistem manajemen basis data;

368 Bab 14 Rekayasa Keamanan
Aplikasi
Komponen dan Pustaka yang Dapat Digunakan Kembali
Middleware
Manajemen Basis Data
Umum, Aplikasi Bersama (Browser, E-mail, Dll.)

Gambar 14.1 Sistem
lapisan di mana keamanan Sistem operasi
mungkin dikompromikan
• middleware yang mendukung komputasi terdistribusi dan akses database;
• perpustakaan komponen yang dapat digunakan kembali yang digunakan oleh perangkat lunak aplikasi.
Mayoritas serangan eksternal berfokus pada infrastruktur sistem karena komponen

infrastruktur (misalnya, browser web) sudah dikenal luas dan tersedia secara luas.
Penyerang dapat menyelidiki kelemahan sistem ini dan berbagi informasi tentang kerentanan
yang mereka temukan. Karena banyak orang menggunakan perangkat lunak yang sama,
serangan memiliki penerapan yang luas. Kerentanan infrastruktur dapat menyebabkan penyerang
mendapatkan akses tidak sah ke sistem aplikasi dan datanya.
Dalam praktiknya, ada perbedaan penting antara keamanan aplikasi dan
keamanan infrastruktur:
1. Keamanan aplikasi adalah masalah rekayasa perangkat lunak di mana insinyur perangkat
lunak harus memastikan bahwa sistem dirancang untuk menahan serangan.
2. Keamanan infrastruktur adalah masalah manajemen di mana manajer sistem mengonfigurasi

infrastruktur untuk menahan serangan. Manajer sistem harus mengatur
infrastruktur untuk membuat penggunaan yang paling efektif dari keamanan infrastruktur apa pun
fitur tersedia. Mereka juga harus memperbaiki kerentanan keamanan infrastruktur yang
terungkap saat perangkat lunak digunakan.
Manajemen keamanan sistem bukanlah tugas tunggal tetapi mencakup berbagai kegiatan
seperti manajemen pengguna dan izin, penyebaran dan pemeliharaan perangkat lunak sistem,
serta pemantauan serangan, deteksi, dan pemulihan:
1. Manajemen pengguna dan izin termasuk menambahkan dan menghapus pengguna dari
sistem, memastikan bahwa mekanisme otentikasi pengguna yang sesuai tersedia
dan mengatur izin dalam sistem sehingga pengguna hanya memiliki akses ke
sumber daya yang mereka butuhkan.
2. Penyebaran dan pemeliharaan perangkat lunak sistem termasuk menginstal perangkat

lunak sistem dan middleware dan mengonfigurasinya dengan benar sehingga kerentanan
keamanan dapat dihindari. Ini juga melibatkan memperbarui perangkat lunak ini secara teratur dengan yang baru
versi atau patch, yang memperbaiki masalah keamanan yang ditemukan.
14.1 Manajemen risiko keamanan 369
Serangan orang dalam dan rekayasa sosial
Serangan orang dalam adalah serangan terhadap sistem yang dilakukan oleh individu yang dipercaya (orang dalam) yang
menyalahgunakan kepercayaan itu. Misalnya, seorang perawat yang bekerja di rumah sakit dapat mengakses catatan medis
rahasia pasien yang tidak dia rawat. Serangan orang dalam sulit untuk dilawan karena teknik keamanan ekstra yang mungkin
digunakan akan mengganggu pengguna sistem yang dapat dipercaya.
Rekayasa sosial adalah cara untuk menipu pengguna terakreditasi agar mengungkapkan kredensial mereka. Oleh karena itu,
penyerang dapat berperilaku sebagai orang dalam saat mengakses sistem.
http://www.SoftwareEngineering-9.com/Web/SecurityEng/insiders.html
3. Pemantauan, deteksi, dan pemulihan serangan mencakup aktivitas yang memantau

sistem untuk akses yang tidak sah, mendeteksi, dan menerapkan strategi untuk
menahan serangan, dan aktivitas pencadangan sehingga operasi normal dapat
dilanjutkan setelah serangan eksternal.
Manajemen keamanan sangat penting, tetapi biasanya tidak dianggap sebagai

bagian dari rekayasa keamanan aplikasi. Sebaliknya, rekayasa keamanan aplikasi
berkaitan dengan merancang sistem sehingga seaman mungkin, mengingat
keterbatasan anggaran dan kegunaan. Bagian dari proses ini adalah 'desain untuk
manajemen', di mana Anda merancang sistem untuk meminimalkan kemungkinan
kesalahan manajemen keamanan yang mengarah pada serangan yang berhasil pada sistem.
Untuk sistem kontrol kritis dan sistem tertanam, adalah praktik normal untuk
memilih infrastruktur yang sesuai untuk mendukung sistem aplikasi. Misalnya,
pengembang sistem tertanam biasanya memilih sistem operasi waktu nyata yang
menyediakan fasilitas yang dibutuhkan aplikasi tertanam. Kerentanan yang diketahui
dan persyaratan keamanan dapat diperhitungkan. Ini berarti bahwa pendekatan holistik
dapat diambil untuk rekayasa keamanan. Persyaratan keamanan aplikasi dapat
diimplementasikan melalui infrastruktur atau aplikasi itu sendiri.
Namun, sistem aplikasi dalam suatu organisasi biasanya diimplementasikan dengan

menggunakan infrastruktur yang ada (sistem operasi, database, dll). Oleh karena itu,
risiko penggunaan infrastruktur tersebut dan fitur keamanannya harus diperhitungkan
sebagai bagian dari proses desain sistem.
14.1 Manajemen risiko keamanan
Penilaian dan manajemen risiko keamanan sangat penting untuk rekayasa keamanan
yang efektif. Manajemen risiko berkaitan dengan menilai kemungkinan kerugian yang
mungkin terjadi dari serangan terhadap aset dalam sistem, dan menyeimbangkan kerugian ini terhadap
biaya prosedur keamanan yang dapat mengurangi kerugian tersebut. Perusahaan kartu kredit
melakukan ini sepanjang waktu. Relatif mudah untuk memperkenalkan teknologi baru untuk
mengurangi penipuan kartu kredit. Namun, seringkali lebih murah bagi mereka untuk
memberikan kompensasi kepada pengguna atas kerugian mereka karena penipuan daripada
membeli dan menggunakan teknologi pengurangan penipuan. Saat biaya turun dan serangan
meningkat, keseimbangan ini dapat berubah. Misalnya, perusahaan kartu kredit sekarang
mengkodekan informasi pada chip di kartu alih-alih strip magnetik. Ini membuat penyalinan kartu jauh lebih sulit.
Manajemen risiko adalah masalah bisnis daripada masalah teknis sehingga insinyur
perangkat lunak tidak boleh memutuskan kontrol apa yang harus disertakan dalam suatu
sistem. Terserah manajemen senior untuk memutuskan apakah akan menerima atau tidak
biaya keamanan atau eksposur yang dihasilkan dari kurangnya prosedur keamanan. Sebaliknya,
peran insinyur perangkat lunak adalah untuk memberikan panduan teknis dan penilaian yang
terinformasi tentang masalah keamanan. Oleh karena itu, mereka adalah peserta penting dalam manajemen risiko
proses.
Seperti yang saya jelaskan di Bab 12, masukan penting untuk penilaian risiko dan proses
manajemen adalah kebijakan keamanan organisasi. Kebijakan keamanan organisasi berlaku
untuk semua sistem dan harus menetapkan apa yang boleh dan tidak boleh diizinkan. Kebijakan
keamanan menetapkan kondisi yang harus selalu dijaga oleh sistem keamanan dan dengan
demikian membantu mengidentifikasi risiko dan ancaman yang mungkin muncul. Oleh karena
itu, kebijakan keamanan mendefinisikan apa yang boleh dan apa yang tidak diperbolehkan.
Dalam proses rekayasa keamanan, Anda merancang mekanisme untuk menerapkan kebijakan
ini.
Penilaian risiko dimulai sebelum keputusan untuk memperoleh sistem dibuat dan harus
berlanjut selama proses pengembangan sistem dan setelah sistem mulai digunakan (Alberts
dan Dorofee, 2002). Saya juga memperkenalkan, dalam Bab 12, gagasan bahwa penilaian risiko
ini adalah proses bertahap:
1. Penilaian risiko awal Pada tahap ini, keputusan tentang persyaratan sistem yang terperinci,
desain sistem, atau teknologi implementasi belum dibuat. Tujuan dari proses penilaian ini
adalah untuk memutuskan apakah tingkat keamanan yang memadai dapat dicapai dengan
biaya yang wajar. Jika demikian, Anda kemudian dapat memperoleh persyaratan keamanan
khusus untuk sistem. Anda tidak memiliki informasi tentang potensi kerentanan dalam
sistem atau kontrol yang disertakan dalam komponen sistem atau middleware yang
digunakan kembali.
2. Penilaian risiko siklus hidup Penilaian risiko ini berlangsung selama siklus hidup
pengembangan sistem dan diinformasikan oleh desain sistem teknis dan keputusan
implementasi. Hasil penilaian dapat menyebabkan perubahan persyaratan keamanan dan
penambahan persyaratan baru. Kerentanan yang diketahui dan potensial diidentifikasi
dan pengetahuan ini digunakan untuk menginformasikan pengambilan keputusan tentang
fungsionalitas sistem dan bagaimana itu diimplementasikan, diuji, dan disebarkan.
3. Penilaian risiko operasional Setelah sistem diterapkan dan digunakan, penilaian risiko harus
terus mempertimbangkan bagaimana sistem tersebut
digunakan dan proposal untuk persyaratan baru dan yang diubah. Asumsi tentang
persyaratan operasi yang dibuat ketika sistem ditentukan mungkin salah. Perubahan organisasi
dapat berarti bahwa sistem digunakan di tempat yang berbeda
cara dari yang semula direncanakan. Oleh karena itu penilaian risiko operasional
mengarah ke persyaratan keamanan baru yang harus diimplementasikan sebagai sistem
berkembang.
Penilaian risiko awal berfokus pada penurunan persyaratan keamanan. Di

Bab 12, saya menunjukkan bagaimana seperangkat persyaratan keamanan awal dapat diturunkan dari a
penilaian risiko awal. Pada bagian ini, saya berkonsentrasi pada siklus hidup dan penilaian risiko
operasional untuk menggambarkan bagaimana spesifikasi dan desain suatu sistem
dipengaruhi oleh teknologi dan cara sistem itu digunakan.
Untuk melakukan penilaian risiko, Anda perlu mengidentifikasi kemungkinan ancaman terhadap sistem.
Salah satu cara untuk melakukan ini adalah dengan mengembangkan serangkaian 'kasus penyalahgunaan' (Alexander, 2003;
Sindre dan Opdahl, 2005). Saya telah membahas bagaimana use case—interaksi tipikal dengan sistem
—dapat digunakan untuk menurunkan persyaratan sistem. Kasus penyalahgunaan adalah
skenario yang mewakili interaksi berbahaya dengan sistem. Anda dapat menggunakan ini untuk
mendiskusikan dan mengidentifikasi kemungkinan ancaman dan, oleh karena itu, juga menentukan
persyaratan keamanan sistem. Mereka dapat digunakan bersama kasus penggunaan saat menurunkan sistem
persyaratan.
Pfleeger dan Pfleeger (2007) mencirikan ancaman di bawah empat judul, yang mungkin:
digunakan sebagai titik awal untuk mengidentifikasi kemungkinan kasus penyalahgunaan. Judul-judul ini adalah
sebagai berikut:
1. Ancaman intersepsi yang memungkinkan penyerang mendapatkan akses ke aset. Jadi, kemungkinan
kasus penyalahgunaan untuk MHC-PMS mungkin adalah situasi di mana penyerang mendapatkan keuntungan
akses ke catatan pasien selebriti individu.
2. Ancaman interupsi yang memungkinkan penyerang membuat bagian dari sistem tidak tersedia. Oleh
karena itu, kemungkinan kasus penyalahgunaan dapat berupa serangan penolakan layanan pada a
server basis data sistem.
3. Ancaman modifikasi yang memungkinkan penyerang merusak aset sistem. Dalam

MHC-PMS, ini dapat diwakili oleh kasus penyalahgunaan di mana penyerang
mengubah informasi dalam catatan pasien.
4. Ancaman fabrikasi yang memungkinkan penyerang memasukkan informasi palsu ke dalam sistem.
Ini mungkin bukan ancaman yang kredibel di MHC-PMS tapi pasti akan
menjadi ancaman dalam sistem perbankan, di mana transaksi palsu dapat ditambahkan ke
sistem yang mentransfer uang ke rekening bank pelaku.
Kasus penyalahgunaan tidak hanya berguna dalam penilaian risiko awal tetapi juga dapat digunakan
untuk analisis keamanan dalam analisis risiko siklus hidup dan analisis risiko operasional. Mereka
memberikan dasar yang berguna untuk memainkan serangan hipotetis pada sistem dan menilai
implikasi keamanan dari keputusan desain yang telah dibuat.
Representasi dan
Organisasi Aset
Nilai aset Paparan

Penilaian Penilaian
Ancaman Menyerang
Identifikasi Penilaian
Teknologi Kontrol Desain dan

Pilihan Identifikasi Persyaratan
Perubahan
Tersedia
Gambar 14.2 Analisis Kontrol
risiko siklus hidup
14.1.1 Penilaian risiko siklus hidup

Berdasarkan kebijakan keamanan organisasi, penilaian risiko awal harus mengidentifikasi
persyaratan keamanan yang paling penting untuk suatu sistem. Ini mencerminkan bagaimana
kebijakan keamanan harus diterapkan dalam aplikasi itu, mengidentifikasi aset yang akan
dilindungi, dan memutuskan pendekatan apa yang harus digunakan untuk memberikan perlindungan itu.
Namun, menjaga keamanan adalah tentang memperhatikan detail. Persyaratan keamanan awal
tidak mungkin memperhitungkan semua detail yang memengaruhi keamanan.
Penilaian risiko siklus hidup mengidentifikasi detail desain dan implementasi yang
memengaruhi keamanan. Ini adalah perbedaan penting antara penilaian risiko siklus hidup dan
penilaian risiko awal. Penilaian risiko siklus hidup mempengaruhi interpretasi persyaratan
keamanan yang ada, menghasilkan persyaratan baru, dan mempengaruhi keseluruhan desain
sistem.
Saat menilai risiko pada tahap ini, Anda harus memiliki informasi yang lebih rinci tentang
apa yang perlu dilindungi, dan Anda juga akan mengetahui sesuatu tentang kerentanan dalam
sistem. Beberapa dari kerentanan ini akan melekat pada pilihan desain yang dibuat. Misalnya,
kerentanan di semua sistem berbasis kata sandi adalah bahwa pengguna yang berwenang
mengungkapkan kata sandi mereka kepada pengguna yang tidak berwenang. Atau, jika suatu
organisasi memiliki kebijakan untuk mengembangkan perangkat lunak dalam C, Anda akan
mengetahui bahwa aplikasi tersebut mungkin memiliki kerentanan karena bahasa tersebut tidak menyertakan pemeriksaan t
Penilaian risiko keamanan harus menjadi bagian dari semua aktivitas siklus hidup mulai
dari rekayasa kebutuhan hingga penerapan sistem. Proses yang diikuti serupa dengan proses
penilaian risiko awal dengan penambahan aktivitas yang berkaitan dengan identifikasi dan
penilaian kerentanan desain. Hasil dari penilaian risiko adalah serangkaian keputusan rekayasa
yang mempengaruhi desain sistem atau implementasi, atau membatasi cara penggunaannya.
Sebuah model proses analisis risiko siklus hidup, berdasarkan proses analisis risiko awal
yang saya jelaskan pada Gambar 12.9, ditunjukkan pada Gambar 14.2. Yang paling
perbedaan penting antara proses ini adalah bahwa Anda sekarang memiliki informasi
tentang representasi dan distribusi informasi dan organisasi database untuk aset tingkat
tinggi yang harus dilindungi. Anda juga mengetahui keputusan desain penting seperti
perangkat lunak yang akan digunakan kembali, kontrol dan perlindungan infrastruktur, dll.
Berdasarkan informasi ini, analisis Anda mengidentifikasi perubahan pada persyaratan
keamanan dan desain sistem untuk memberikan perlindungan tambahan bagi sistem
penting aktiva.
Dua contoh menggambarkan bagaimana persyaratan perlindungan dipengaruhi oleh
keputusan tentang representasi dan distribusi informasi:
1. Anda dapat membuat keputusan desain untuk memisahkan informasi pribadi pasien dan
informasi tentang perawatan yang diterima, dengan kunci yang menghubungkan
catatan-catatan ini. Informasi perawatan jauh lebih sensitif daripada informasi pribadi
pasien sehingga mungkin tidak memerlukan perlindungan yang ekstensif. Jika kunci
dilindungi, maka penyerang hanya akan dapat mengakses informasi rutin, tanpa dapat
menautkannya ke pasien individu.
2. Asumsikan bahwa, pada awal sesi, keputusan desain dibuat untuk menyalin catatan
pasien ke sistem klien lokal. Hal ini memungkinkan pekerjaan untuk melanjutkan jika
server tidak tersedia. Ini memungkinkan pekerja layanan kesehatan untuk mengakses
catatan pasien dari laptop, bahkan jika tidak ada koneksi jaringan yang tersedia.
Namun, Anda sekarang memiliki dua set catatan untuk dilindungi dan salinan klien
memiliki risiko tambahan, seperti pencurian komputer laptop. Oleh karena itu, Anda
harus memikirkan kontrol apa yang harus digunakan untuk mengurangi risiko.
Misalnya, catatan klien di laptop mungkin harus dienkripsi.
Untuk mengilustrasikan bagaimana keputusan tentang pengembangan teknologi

memengaruhi keamanan, asumsikan bahwa penyedia layanan kesehatan telah memutuskan
untuk membangun MHC-PMS menggunakan sistem informasi siap pakai untuk memelihara
catatan pasien. Sistem ini harus dikonfigurasi untuk setiap jenis klinik yang digunakan.
Keputusan ini dibuat karena tampaknya menawarkan fungsionalitas paling luas dengan
biaya pengembangan terendah dan waktu penerapan tercepat.
Saat Anda mengembangkan aplikasi dengan menggunakan kembali sistem yang ada,
Anda harus menerima keputusan desain yang dibuat oleh pengembang sistem itu. Mari kita
asumsikan bahwa beberapa keputusan desain ini adalah sebagai berikut:
1. Pengguna sistem diautentikasi menggunakan kombinasi nama login/kata sandi. Tidak

metode otentikasi lainnya didukung.
2. Arsitektur sistem adalah client-server, dengan klien mengakses data melalui web browser
standar pada PC klien.
3. Informasi disajikan kepada pengguna sebagai formulir web yang dapat diedit. Mereka
dapat mengubah informasi di tempat dan mengunggah informasi yang direvisi ke server.
Pilihan Teknologi Kerentanan
Set Pengguna Pengguna Resmi

Kata sandi masuk Dapat ditebak Mengungkapkan Kata Sandi mereka ke
Autentikasi
Kata sandi Pengguna Tidak Sah
Server Tunduk pada Informasi Rahasia

Kegagalan layanan Mungkin Ditinggalkan di Browser
Server klien Menyerang Cache
Arsitektur Menggunakan
Peramban Web
Keamanan Peramban
Celah Mengarah ke
Akses tidak sah
Pencatatan Perubahan Otorisasi tidak dapat

Penggunaan yang Dapat Diedit
Gambar 14.3
Formulir Web Butir Halus adalah Divariasikan Sesuai
Kerentanan terkait
Mustahil Peran Pengguna
dengan pilihan
teknologi
Untuk sistem generik, keputusan desain ini sangat dapat diterima, tetapi analisis risiko
siklus hidup mengungkapkan bahwa mereka memiliki kerentanan terkait. Contoh
kerentanan yang mungkin terjadi ditunjukkan pada Gambar 14.3.
Setelah kerentanan telah diidentifikasi, Anda kemudian harus membuat keputusan
tentang langkah-langkah apa yang dapat Anda ambil untuk mengurangi risiko terkait. Ini
akan sering melibatkan pengambilan keputusan tentang persyaratan keamanan sistem
tambahan atau proses operasional menggunakan sistem. Saya tidak memiliki ruang di sini
untuk membahas semua persyaratan yang mungkin diusulkan untuk mengatasi kerentanan
yang melekat, tetapi beberapa contoh persyaratan mungkin sebagai berikut:
1. Program pemeriksa kata sandi harus tersedia dan dijalankan setiap hari.
Kata sandi pengguna yang muncul dalam kamus sistem harus diidentifikasi dan
pengguna dengan kata sandi yang lemah dilaporkan ke administrator sistem.
2. Akses ke sistem hanya diperbolehkan untuk komputer klien yang telah

disetujui dan terdaftar dengan administrator sistem.
3. Semua komputer klien harus memiliki satu browser web yang diinstal sebagaimana
disetujui oleh administrator sistem.
Karena sistem siap pakai, tidak mungkin menyertakan pemeriksa kata sandi dalam
sistem aplikasi itu sendiri, jadi sistem terpisah harus digunakan. Pemeriksa kata sandi
menganalisis kekuatan kata sandi pengguna saat disiapkan, dan memberi tahu pengguna
jika mereka memilih kata sandi yang lemah. Oleh karena itu, kata sandi yang rentan dapat diidentifikasi secara wajar
14.2 Desain untuk keamanan 375
dengan cepat setelah mereka diatur, dan tindakan kemudian dapat diambil untuk memastikan bahwa
pengguna mengubah kata sandi mereka.
Persyaratan kedua dan ketiga berarti bahwa semua pengguna akan selalu mengakses sistem melalui
browser yang sama. Anda dapat memutuskan browser apa yang paling aman saat sistem diterapkan dan
menginstalnya di semua komputer klien. Pembaruan keamanan disederhanakan karena tidak perlu
memperbarui browser yang berbeda ketika kerentanan keamanan ditemukan dan diperbaiki.
14.1.2 Penilaian risiko operasional

Penilaian risiko keamanan harus berlanjut sepanjang masa pakai sistem untuk mengidentifikasi risiko
yang muncul dan perubahan sistem yang mungkin diperlukan untuk mengatasi risiko ini. Proses ini
disebut penilaian risiko operasional. Risiko baru mungkin muncul karena perubahan persyaratan sistem,
perubahan infrastruktur sistem, atau perubahan lingkungan di mana sistem digunakan.
Proses penilaian risiko operasional mirip dengan proses penilaian risiko siklus hidup, tetapi dengan
tambahan informasi lebih lanjut tentang lingkungan di mana sistem digunakan. Lingkungan penting
karena karakteristik lingkungan dapat menimbulkan risiko baru pada sistem. Misalnya, katakanlah suatu
sistem sedang digunakan di lingkungan di mana pengguna sering terganggu. Risikonya adalah gangguan
akan berarti bahwa pengguna harus meninggalkan komputer mereka tanpa pengawasan. Kemudian
dimungkinkan bagi orang yang tidak berwenang untuk mendapatkan akses ke informasi dalam sistem.
Ini kemudian dapat menghasilkan persyaratan untuk screen saver yang dilindungi kata sandi untuk
dijalankan setelah beberapa saat tidak aktif.
14.2 Desain untuk keamanan
Secara umum benar bahwa sangat sulit untuk menambahkan keamanan ke sistem setelah
diimplementasikan. Oleh karena itu, Anda perlu mempertimbangkan masalah keamanan selama proses
desain sistem. Di bagian ini, saya fokus terutama pada masalah desain sistem, karena topik ini tidak
mendapat perhatian yang layak dalam buku keamanan komputer.
Masalah dan kesalahan implementasi juga berdampak besar pada keamanan, tetapi ini sering kali
bergantung pada teknologi spesifik yang digunakan. Saya merekomendasikan buku Viega dan McGraw
(2002) sebagai pengantar yang baik untuk pemrograman untuk keamanan.
Di sini, saya fokus pada sejumlah masalah umum yang tidak bergantung pada aplikasi yang relevan
dengan desain sistem yang aman:
1. Desain arsitektur—bagaimana keputusan desain arsitektur memengaruhi keamanan?

dari sebuah sistem?
2. Praktik yang baik—praktik baik apa yang diterima saat merancang sistem yang aman?
3. Desain untuk penyebaran—dukungan apa yang harus dirancang ke dalam sistem untuk menghindari
pengenalan kerentanan saat sistem digunakan untuk digunakan?
Penolakan serangan layanan
Serangan penolakan layanan mencoba untuk menjatuhkan sistem jaringan dengan membombardirnya dengan
sejumlah besar permintaan layanan. Ini menempatkan beban pada sistem yang tidak dirancang dan mereka
mengecualikan permintaan yang sah untuk layanan sistem. Akibatnya, sistem mungkin menjadi tidak tersedia baik
karena macet dengan beban berat atau harus offline oleh manajer sistem untuk menghentikan aliran permintaan.
http://www.SoftwareEngineering-9.com/Web/Security/DoS.html
Tentu saja, ini bukan satu-satunya masalah desain yang penting untuk keamanan. Setiap
aplikasi berbeda dan desain keamanan juga harus mempertimbangkan tujuan, kekritisan,
dan lingkungan operasional aplikasi. Misalnya, jika Anda merancang sistem militer, Anda
perlu mengadopsi model klasifikasi keamanannya (rahasia, sangat rahasia, dll.). Jika
Anda merancang sistem yang memelihara informasi pribadi, Anda mungkin harus
mempertimbangkan undang-undang perlindungan data yang membatasi cara pengelolaan
data.
Ada hubungan erat antara ketergantungan dan keamanan. Penggunaan redundansi
dan keragaman, yang merupakan dasar untuk mencapai ketergantungan, dapat berarti
bahwa suatu sistem dapat bertahan dan pulih dari serangan yang menargetkan
karakteristik desain atau implementasi tertentu. Mekanisme untuk mendukung tingkat
ketersediaan yang tinggi dapat membantu sistem untuk pulih dari apa yang disebut
serangan penolakan layanan, di mana tujuan penyerang adalah untuk menjatuhkan sistem dan menghentikannya be
Merancang sistem agar aman pasti melibatkan kompromi. Sangat mungkin untuk
merancang beberapa langkah keamanan ke dalam sistem yang akan mengurangi
kemungkinan serangan yang berhasil. Namun, langkah-langkah keamanan sering
membutuhkan banyak perhitungan tambahan dan mempengaruhi kinerja keseluruhan
sistem. Misalnya, Anda dapat mengurangi kemungkinan pengungkapan informasi rahasia
dengan mengenkripsi informasi tersebut. Namun, ini berarti bahwa pengguna informasi
harus menunggu untuk didekripsi dan ini dapat memperlambat pekerjaan mereka.
Ada juga ketegangan antara keamanan dan kegunaan. Tindakan keamanan terkadang
mengharuskan pengguna untuk mengingat dan memberikan informasi tambahan
(misalnya, beberapa kata sandi). Namun, terkadang pengguna melupakan informasi ini,
sehingga keamanan tambahan berarti mereka tidak dapat menggunakan sistem. Oleh
karena itu, desainer harus menemukan keseimbangan antara keamanan, kinerja, dan
kegunaan. Ini akan tergantung pada jenis sistem dan di mana ia digunakan. Misalnya,
dalam sistem militer, pengguna terbiasa dengan sistem keamanan tinggi sehingga
bersedia menerima dan mengikuti proses yang memerlukan pemeriksaan rutin. Namun,
dalam sistem perdagangan saham, interupsi operasi untuk pemeriksaan keamanan sama sekali tidak dapat diterima
14.2.1 Desain arsitektural

Seperti yang telah saya diskusikan di Bab 11, pilihan arsitektur perangkat lunak dapat
memiliki efek mendalam pada properti yang muncul dari suatu sistem. Jika arsitektur
yang tidak tepat digunakan, mungkin sangat sulit untuk menjaga kerahasiaan dan
integritas informasi dalam sistem atau untuk menjamin tingkat ketersediaan sistem yang
diperlukan.
Dalam merancang arsitektur sistem yang menjaga keamanan, Anda perlu
mempertimbangkan dua masalah mendasar:
1. Perlindungan—bagaimana sistem harus diatur sehingga aset penting dapat dilindungi

dari serangan eksternal?
2. Distribusi—bagaimana seharusnya aset sistem didistribusikan sehingga efek dari

serangan yang berhasil diminimalkan?
Isu-isu ini berpotensi saling bertentangan. Jika Anda meletakkan semua aset Anda di
satu tempat, maka Anda dapat membangun lapisan perlindungan di sekitarnya. Karena
Anda hanya perlu membangun sistem perlindungan tunggal, Anda mungkin dapat
membeli sistem yang kuat dengan beberapa lapisan perlindungan. Namun, jika
perlindungan itu gagal, maka semua aset Anda akan dikompromikan. Menambahkan
beberapa lapisan perlindungan juga mempengaruhi kegunaan suatu sistem sehingga
dapat berarti lebih sulit untuk memenuhi persyaratan kegunaan dan kinerja sistem.
Di sisi lain, jika Anda mendistribusikan aset, mereka lebih mahal untuk dilindungi
karena sistem perlindungan harus diterapkan untuk setiap salinan. Biasanya, Anda tidak
mampu membeli lapisan perlindungan sebanyak itu. Kemungkinannya lebih besar bahwa
perlindungan akan dilanggar. Namun, jika ini terjadi, Anda tidak mengalami kerugian total.
Dimungkinkan untuk menggandakan dan mendistribusikan aset informasi sehingga jika
satu salinan rusak atau tidak dapat diakses, maka salinan lainnya dapat digunakan.
Namun, jika informasinya rahasia, menyimpan salinan tambahan meningkatkan risiko
penyusup mendapatkan akses ke informasi ini.
Untuk sistem pencatatan pasien sudah tepat menggunakan arsitektur database
terpusat. Untuk memberikan perlindungan, Anda menggunakan arsitektur berlapis
dengan aset yang dilindungi kritis pada tingkat terendah dalam sistem, dengan berbagai
lapisan perlindungan di sekitarnya. Gambar 14.4 mengilustrasikan hal ini untuk sistem
catatan pasien di mana aset penting yang harus dilindungi adalah catatan pasien individu.
Untuk mengakses dan memodifikasi catatan pasien, penyerang harus menembus tiga
lapisan sistem:
1. Perlindungan tingkat platform Tingkat atas mengontrol akses ke platform tempat sistem
rekam pasien berjalan. Ini biasanya melibatkan pengguna yang masuk ke komputer
tertentu. Platform juga biasanya akan menyertakan dukungan untuk menjaga
integritas file pada sistem, backup, dll.
2. Perlindungan tingkat aplikasi Tingkat perlindungan berikutnya dibangun ke dalam

aplikasi itu sendiri. Ini melibatkan pengguna yang mengakses aplikasi, diautentikasi,
dan mendapatkan otorisasi untuk mengambil tindakan seperti melihat atau memodifikasi data.
Dukungan manajemen integritas khusus aplikasi mungkin tersedia.
3. Perlindungan tingkat catatan Tingkat ini dipanggil ketika akses ke catatan tertentu
diperlukan, dan melibatkan pemeriksaan bahwa pengguna berwenang untuk
melakukan operasi yang diminta pada catatan itu. Perlindungan pada tingkat ini mungkin juga melibatkan
Perlindungan Tingkat Platform
Sistem Sistem Integritas File

Autentikasi Otorisasi Pengelolaan
Perlindungan Tingkat Aplikasi
Basis data Basis data Transaksi Basis data

Gabung Otorisasi Pengelolaan Pemulihan
Perlindungan Tingkat Rekor
Akses Rekam Catatan Rekam Integritas

Otorisasi Enkripsi Pengelolaan
Gambar 14.4 Arsitektur Catatan Pasien

perlindungan berlapis
enkripsi untuk memastikan bahwa catatan tidak dapat diakses menggunakan browser file.
Pemeriksaan integritas menggunakan, misalnya, checksum kriptografi, dapat
mendeteksi perubahan yang telah dibuat di luar mekanisme pembaruan catatan normal.
Jumlah lapisan perlindungan yang Anda butuhkan dalam aplikasi tertentu bergantung
pada kekritisan data. Tidak semua aplikasi memerlukan perlindungan pada tingkat rekor
dan, oleh karena itu, kontrol akses yang lebih kasar lebih umum digunakan. Untuk
mencapai keamanan, Anda tidak boleh mengizinkan kredensial pengguna yang sama digunakan di setiap level.
Idealnya, jika Anda memiliki sistem berbasis kata sandi, maka kata sandi aplikasi harus
berbeda dari kata sandi sistem dan kata sandi tingkat rekaman. Namun, banyak kata sandi
sulit diingat oleh pengguna dan mereka menganggap permintaan berulang untuk
mengautentikasi diri mereka menjengkelkan. Oleh karena itu, Anda sering kali harus
mengorbankan keamanan demi kegunaan sistem.
Jika perlindungan data merupakan persyaratan penting, maka arsitektur client-server
harus digunakan, dengan mekanisme perlindungan yang dibangun ke dalam server.
Namun, jika perlindungan dikompromikan, maka kerugian yang terkait dengan serangan
cenderung tinggi, demikian pula biaya pemulihan (misalnya, semua kredensial pengguna mungkin harus diterbitkan u
Sistem ini rentan terhadap serangan penolakan layanan, yang membebani server dan
membuat tidak mungkin bagi siapa pun untuk mengakses database sistem.
Jika Anda berpikir bahwa serangan penolakan layanan adalah risiko besar, Anda dapat
memutuskan untuk menggunakan arsitektur objek terdistribusi untuk aplikasi tersebut.
Dalam situasi ini, diilustrasikan pada Gambar 14.5, aset sistem didistribusikan di sejumlah
bentuk plat yang berbeda, dengan mekanisme perlindungan terpisah yang digunakan
untuk masing-masing. Serangan pada satu node mungkin berarti bahwa beberapa aset tidak tersedia tetapi masih mu
Otentikasi dan Otorisasi Otentikasi dan Otorisasi
Sistem Perdagangan New York Sistem Perdagangan London
Pengguna AS Internasional Pengguna Inggris Internasional

Akun Akun Pengguna Akun Akun Pengguna
Perdagangan AS Perdagangan Inggris

Data Ekuitas AS Data Ekuitas Inggris
Sejarah Sejarah
Internasional Internasional
Data Dana AS Data Dana Inggris
Harga Ekuitas Harga Ekuitas
Otentikasi dan Otorisasi Otentikasi dan Otorisasi
Sistem Perdagangan Frankfurt Sistem Perdagangan Hong Kong
Pengguna Eropa Internasional Pengguna HK Internasional

Akun Akun Pengguna Akun Akun Pengguna
Euro. Sejarah Perdagangan HK

Euro. Data Ekuitas Data Ekuitas Asia
Perdagangan Sejarah
Internasional Internasional
Euro. Data Dana Data Dana Asia
Harga Ekuitas Harga Ekuitas
menyediakan beberapa layanan sistem. Data dapat direplikasi di seluruh node dalam
Gambar 14.5
Aset terdistribusi sistem sehingga pemulihan dari serangan disederhanakan.
dalam sistem Gambar 14.5 menunjukkan arsitektur sistem perbankan untuk perdagangan saham
perdagangan ekuitas dan dana di pasar New York, London, Frankfurt, dan Hong Kong. Sistem ini didistribusikan
sehingga data tentang setiap pasar dipertahankan secara terpisah. Aset yang diperlukan
untuk mendukung aktivitas penting perdagangan ekuitas (akun pengguna dan harga)
direplikasi dan tersedia di semua node. Jika node sistem diserang dan menjadi tidak
tersedia, aktivitas penting perdagangan ekuitas dapat ditransfer ke negara lain dan masih
dapat tersedia bagi pengguna.
Saya telah membahas masalah menemukan keseimbangan antara keamanan dan
kinerja sistem. Masalah desain sistem yang aman adalah bahwa dalam banyak kasus,
gaya arsitektur yang paling cocok untuk memenuhi persyaratan keamanan mungkin
bukan yang terbaik untuk memenuhi persyaratan kinerja. Misalnya, katakan
aplikasi memiliki satu persyaratan mutlak untuk menjaga kerahasiaan database besar dan persyaratan
lain untuk akses yang sangat cepat ke data tersebut. Tingkat perlindungan yang tinggi menunjukkan
bahwa lapisan perlindungan diperlukan, yang berarti harus ada komunikasi antara lapisan sistem. Ini
memiliki overhead kinerja yang tak terhindarkan, sehingga akan memperlambat akses ke data. Jika
arsitektur alternatif digunakan, maka penerapan perlindungan dan jaminan kerahasiaan mungkin lebih
sulit dan mahal. Dalam situasi seperti itu, Anda harus mendiskusikan konflik inheren dengan klien
sistem dan menyepakati bagaimana ini harus diselesaikan.
14.2.2 Pedoman desain

Tidak ada aturan keras dan cepat tentang bagaimana mencapai keamanan sistem. Jenis sistem yang
berbeda memerlukan tindakan teknis yang berbeda untuk mencapai tingkat keamanan yang dapat
diterima oleh pemilik sistem. Sikap dan persyaratan dari berbagai kelompok pengguna sangat
mempengaruhi apa yang dapat dan tidak dapat diterima. Misalnya, di bank, pengguna cenderung
menerima tingkat keamanan yang lebih tinggi, dan karenanya prosedur keamanan yang lebih
mengganggu daripada, katakanlah, di universitas.
Namun, ada pedoman umum yang dapat diterapkan secara luas saat merancang solusi keamanan
sistem, yang merangkum praktik desain yang baik untuk rekayasa sistem yang aman. Pedoman desain
umum untuk keamanan, seperti yang dibahas di bawah, memiliki dua kegunaan utama:
1. Mereka membantu meningkatkan kesadaran akan masalah keamanan dalam tim rekayasa perangkat lunak.
Insinyur perangkat lunak sering berfokus pada tujuan jangka pendek agar perangkat lunak
berfungsi dan dikirimkan ke pelanggan. Sangat mudah bagi mereka untuk mengabaikan masalah
keamanan. Pengetahuan tentang pedoman ini dapat berarti bahwa masalah keamanan
dipertimbangkan ketika keputusan desain perangkat lunak dibuat.
2. Dapat digunakan sebagai checklist review yang dapat digunakan dalam proses validasi sistem. Dari
pedoman tingkat tinggi yang dibahas di sini, pertanyaan yang lebih spesifik dapat diturunkan
yang mengeksplorasi bagaimana keamanan telah direkayasa ke dalam suatu sistem.
10 pedoman desain, diringkas dalam Gambar 14.6, telah diturunkan dari berbagai sumber yang
berbeda (Schneier, 2000; Viega dan McGraw, 2002; Wheeler, 2003). Saya telah fokus di sini pada
pedoman yang secara khusus berlaku untuk spesifikasi perangkat lunak dan proses desain. Prinsip
yang lebih umum, seperti 'Amankan tautan terlemah dalam sistem', 'Tetap sederhana', dan 'Hindari
keamanan melalui ketidakjelasan' juga penting tetapi kurang relevan secara langsung dengan
pengambilan keputusan teknik.
Pedoman 1: Dasarkan keputusan keamanan pada kebijakan keamanan eksplisit
Kebijakan keamanan adalah pernyataan tingkat tinggi yang menetapkan kondisi keamanan mendasar
untuk suatu organisasi. Ini mendefinisikan 'apa' keamanan daripada 'bagaimana', sehingga kebijakan
tidak boleh mendefinisikan mekanisme yang akan digunakan untuk menyediakan dan menegakkan
keamanan. Pada prinsipnya, semua aspek kebijakan keamanan harus tercermin dalam sistem
Pedoman keamanan
1 Dasarkan keputusan keamanan pada kebijakan keamanan eksplisit
2 Hindari satu titik kegagalan
3 Gagal dengan aman
4 Seimbangkan keamanan dan kegunaan
5 Catat tindakan pengguna
6 Gunakan redundansi dan keragaman untuk mengurangi risiko
7 Validasi semua input
8 Pisahkan aset Anda
9 Desain untuk penyebaran

Gambar 14.6 Pedoman
desain untuk rekayasa 10 Desain untuk pemulihan
sistem yang aman
persyaratan. Dalam praktiknya, terutama jika digunakan proses pengembangan aplikasi yang
cepat, hal ini tidak mungkin terjadi. Desainer, oleh karena itu, harus berkonsultasi dengan
kebijakan keamanan karena menyediakan kerangka kerja untuk membuat dan mengevaluasi keputusan desain.
Misalnya, Anda sedang merancang sistem kontrol akses untuk MHC-PMS.
Kebijakan keamanan rumah sakit dapat menyatakan bahwa hanya staf klinis terakreditasi yang
dapat mengubah catatan pasien elektronik. Oleh karena itu, sistem Anda harus menyertakan
mekanisme yang memeriksa akreditasi siapa pun yang mencoba memodifikasi sistem dan yang
menolak modifikasi dari orang yang tidak terakreditasi.
Masalah yang mungkin Anda hadapi adalah banyak organisasi tidak memiliki kebijakan
keamanan sistem yang eksplisit. Seiring waktu, perubahan mungkin telah dilakukan pada sistem
dalam menanggapi masalah yang diidentifikasi, tetapi tanpa dokumen kebijakan menyeluruh
untuk memandu evolusi sistem. Dalam situasi seperti itu, Anda perlu menyusun dan
mendokumentasikan kebijakan dari contoh, dan mengonfirmasikannya dengan manajer di perusahaan.
Pedoman 2: Hindari satu titik kegagalan
Dalam sistem kritis apa pun, praktik desain yang baik adalah mencoba menghindari satu titik
kegagalan. Ini berarti bahwa kegagalan tunggal di bagian sistem tidak boleh mengakibatkan
kegagalan sistem secara keseluruhan. Dalam istilah keamanan, ini berarti bahwa Anda tidak
boleh bergantung pada satu mekanisme untuk memastikan keamanan, melainkan Anda harus
menggunakan beberapa teknik yang berbeda. Ini kadang-kadang disebut 'pertahanan mendalam'.
Misalnya, jika Anda menggunakan kata sandi untuk mengautentikasi pengguna ke suatu
sistem, Anda mungkin juga menyertakan mekanisme autentikasi tantangan/tanggapan di mana
pengguna harus melakukan pra-registrasi pertanyaan dan jawaban dengan sistem. Setelah
otentikasi kata sandi, mereka kemudian harus menjawab pertanyaan dengan benar sebelum diizinkan mengakses. Untuk
integritas data dalam suatu sistem, Anda dapat menyimpan log yang dapat dieksekusi dari semua
perubahan yang dilakukan pada data (lihat Pedoman 5). Jika terjadi kegagalan, Anda dapat memutar
ulang log untuk membuat ulang kumpulan data. Anda juga dapat membuat salinan semua data yang
dimodifikasi sebelum perubahan dilakukan.
Pedoman 3: Gagal dengan aman
Kegagalan sistem tidak dapat dihindari di semua sistem dan, dengan cara yang sama seperti sistem
kritis keselamatan harus selalu gagal-aman, sistem kritis keamanan harus selalu 'gagal aman'. Ketika
sistem gagal, Anda tidak boleh menggunakan prosedur fallback yang kurang aman daripada sistem itu
sendiri. Kegagalan sistem juga tidak berarti bahwa penyerang dapat mengakses data yang biasanya
tidak diizinkan.
Misalnya, dalam sistem informasi pasien, saya menyarankan persyaratan bahwa data pasien harus
diunduh ke klien sistem pada awal sesi klinik.
Ini mempercepat akses dan berarti bahwa akses dimungkinkan jika server tidak tersedia.
Biasanya, server menghapus data ini di akhir sesi klinik. Namun, jika server gagal, maka ada
kemungkinan informasi tersebut akan dipertahankan pada klien. Pendekatan gagal-aman dalam keadaan
tersebut adalah untuk mengenkripsi semua data pasien yang tersimpan di klien. Ini berarti bahwa
pengguna yang tidak sah tidak dapat membaca data.
Pedoman 4: Seimbangkan keamanan dan kegunaan
Tuntutan keamanan dan kegunaan seringkali bertentangan. Untuk membuat sistem aman, Anda harus
memperkenalkan pemeriksaan bahwa pengguna berwenang untuk menggunakan sistem dan bahwa
mereka bertindak sesuai dengan kebijakan keamanan. Semua ini mau tidak mau menuntut pengguna—
mereka mungkin harus mengingat nama login dan kata sandi, hanya menggunakan sistem dari komputer
tertentu, dan seterusnya. Ini berarti pengguna membutuhkan lebih banyak waktu untuk memulai dengan
sistem dan menggunakannya secara efektif. Saat Anda menambahkan fitur keamanan ke sistem, tidak
dapat dihindari bahwa itu akan menjadi kurang bermanfaat. Saya merekomendasikan buku Cranor dan Garfinkel
(2005) yang membahas berbagai masalah di bidang umum keamanan dan kegunaan.
Ada titik di mana kontraproduktif untuk terus menambahkan fitur keamanan baru dengan
mengorbankan kegunaan. Misalnya, jika Anda meminta pengguna untuk memasukkan beberapa kata
sandi atau mengubah kata sandi mereka menjadi string karakter yang tidak mungkin diingat pada
interval yang sering, mereka hanya akan menuliskan kata sandi ini. Penyerang (terutama orang dalam)
kemudian dapat menemukan kata sandi yang telah ditulis dan mendapatkan akses ke sistem.
Pedoman 5: Catat tindakan pengguna
Jika secara praktis memungkinkan untuk melakukannya, Anda harus selalu menyimpan log tindakan pengguna.
Log ini setidaknya harus mencatat siapa yang melakukan apa, aset yang digunakan, serta waktu dan
tanggal tindakan. Seperti yang saya bahas di Panduan 2, jika Anda mempertahankan ini sebagai daftar
perintah yang dapat dieksekusi, Anda memiliki opsi untuk memutar ulang log untuk memulihkan dari
kegagalan. Tentu saja, Anda juga memerlukan alat yang memungkinkan Anda menganalisis log dan
mendeteksi tindakan yang berpotensi anomali. Alat-alat ini dapat memindai log dan menemukan tindakan
anomali, dan dengan demikian membantu mendeteksi serangan dan melacak bagaimana penyerang memperoleh akses ke sistem.
Selain membantu memulihkan dari kegagalan, log tindakan pengguna berguna karena
berfungsi sebagai pencegah serangan orang dalam. Jika orang tahu bahwa tindakan mereka
sedang dicatat, maka mereka cenderung tidak melakukan hal-hal yang tidak sah. Ini paling efektif
untuk serangan biasa, seperti perawat mencari catatan pasien, atau untuk mendeteksi serangan
di mana kredensial pengguna yang sah telah dicuri melalui rekayasa sosial. Tentu saja, ini tidak
mudah, karena orang dalam yang ahli secara teknis juga dapat mengakses dan mengubah log.
Pedoman 6: Gunakan redundansi dan keragaman untuk mengurangi risiko
Redundansi berarti Anda memelihara lebih dari satu versi perangkat lunak atau data dalam suatu
sistem. Keragaman, ketika diterapkan pada perangkat lunak, berarti bahwa versi yang berbeda
tidak boleh bergantung pada platform yang sama atau diimplementasikan menggunakan teknologi yang sama.
Oleh karena itu, kerentanan platform atau teknologi tidak akan memengaruhi semua versi
sehingga menyebabkan kegagalan umum. Saya menjelaskan di Bab 13 bagaimana redundansi
dan keragaman merupakan mekanisme fundamental yang digunakan dalam rekayasa ketergantungan.
Saya telah membahas contoh redundansi—memelihara informasi pasien di server dan klien,
pertama dalam sistem perawatan kesehatan mental, dan kemudian dalam sistem perdagangan
ekuitas terdistribusi yang ditunjukkan pada Gambar 14.5. Dalam sistem catatan pasien, Anda
dapat menggunakan beragam sistem operasi pada klien dan server (misalnya, Linux pada server,
Windows pada klien). Ini memastikan bahwa serangan berdasarkan kerentanan sistem operasi
tidak akan memengaruhi server dan klien. Tentu saja, Anda harus menukar manfaat tersebut
dengan peningkatan biaya manajemen untuk memelihara sistem operasi yang berbeda dalam
suatu organisasi.
Pedoman 7: Validasi semua input
Serangan umum pada suatu sistem melibatkan penyediaan sistem dengan input tak terduga
yang menyebabkannya berperilaku dengan cara yang tidak terduga. Ini mungkin hanya
menyebabkan sistem crash, mengakibatkan hilangnya layanan, atau input dapat terdiri dari kode
berbahaya yang dijalankan oleh sistem. Kerentanan buffer overflow, pertama kali ditunjukkan
pada worm Internet (Spafford, 1989) dan biasanya digunakan oleh penyerang (Berghel, 2001),
dapat dipicu menggunakan string input yang panjang. Apa yang disebut 'keracunan SQL', di
mana pengguna jahat memasukkan fragmen SQL yang ditafsirkan oleh server, adalah serangan
lain yang cukup umum.
Seperti yang saya jelaskan di Bab 13, Anda dapat menghindari banyak masalah ini jika Anda
mendesain validasi input ke dalam sistem Anda. Pada dasarnya, Anda tidak boleh menerima
masukan apa pun tanpa menerapkan beberapa pemeriksaan padanya. Sebagai bagian dari
persyaratan, Anda harus menentukan pemeriksaan yang harus diterapkan. Anda harus
menggunakan pengetahuan tentang input untuk menentukan pemeriksaan ini. Misalnya, jika
nama keluarga akan dimasukkan, Anda dapat memeriksa bahwa tidak ada spasi yang disematkan
dan satu-satunya tanda baca yang digunakan adalah tanda hubung. Anda juga dapat memeriksa jumlah input karakter dan
Misalnya, tidak ada orang yang memiliki nama keluarga lebih dari 40 karakter dan tidak ada
alamat yang panjangnya lebih dari 100 karakter. Jika Anda menggunakan menu untuk menyajikan
input yang diizinkan, Anda menghindari beberapa masalah validasi input.
Pedoman 8: Pisahkan aset Anda
Membagi-bagi berarti Anda tidak boleh memberikan akses semua-atau-tidak sama sekali
ke informasi dalam suatu sistem. Sebaliknya, Anda harus mengatur informasi dalam
sistem ke dalam kompartemen. Pengguna seharusnya hanya memiliki akses ke informasi
yang mereka butuhkan, bukan ke semua informasi dalam suatu sistem. Ini berarti bahwa
efek dari serangan dapat ditampung. Beberapa informasi mungkin hilang atau rusak tetapi
kecil kemungkinannya semua informasi dalam sistem akan terpengaruh.
Misalnya, dalam sistem informasi pasien, Anda harus merancang sistem sehingga di
salah satu klinik, staf klinik biasanya hanya memiliki akses ke catatan pasien yang memiliki
janji temu di klinik tersebut. Mereka biasanya tidak memiliki akses ke semua catatan
pasien dalam sistem. Hal ini tidak hanya membatasi potensi kerugian dari serangan orang
dalam, tetapi juga berarti bahwa jika seorang penyusup mencuri kredensial mereka, maka
jumlah kerusakan yang dapat mereka timbulkan juga terbatas.
Karena itu, Anda juga mungkin harus memiliki mekanisme dalam sistem untuk memberikan
akses yang tidak terduga—misalnya kepada pasien yang sakit parah dan memerlukan perawatan
segera tanpa membuat janji terlebih dahulu. Dalam keadaan tersebut, Anda mungkin menggunakan
beberapa mekanisme aman alternatif untuk mengesampingkan kompartementalisasi dalam sistem.
Dalam situasi seperti itu, di mana keamanan dilonggarkan untuk menjaga ketersediaan sistem,
penting bagi Anda untuk menggunakan mekanisme logging untuk mencatat penggunaan sistem.
Anda kemudian dapat memeriksa log untuk melacak penggunaan yang tidak sah.
Pedoman 9: Desain untuk penerapan
Banyak masalah keamanan muncul karena sistem tidak dikonfigurasi dengan benar saat
digunakan di lingkungan operasionalnya. Oleh karena itu, Anda harus selalu mendesain
sistem Anda sehingga fasilitas disertakan untuk menyederhanakan penerapan di
lingkungan pelanggan dan untuk memeriksa kemungkinan kesalahan konfigurasi dan
kelalaian dalam sistem yang diterapkan. Ini adalah topik penting, yang akan saya bahas secara rinci nanti di Bagian 1
Pedoman 10: Desain untuk pemulihan
Terlepas dari seberapa banyak upaya yang Anda lakukan untuk menjaga keamanan
sistem, Anda harus selalu merancang sistem Anda dengan asumsi bahwa kegagalan
keamanan dapat terjadi. Oleh karena itu, Anda harus memikirkan cara memulihkan dari
kemungkinan kegagalan dan memulihkan sistem ke kondisi operasional yang aman.
Misalnya, Anda dapat menyertakan sistem autentikasi cadangan jika autentikasi kata sandi Anda disusupi.
Misalnya, katakanlah orang yang tidak berwenang dari luar klinik memperoleh akses
ke sistem catatan pasien dan Anda tidak tahu bagaimana mereka memperoleh kombinasi
login/kata sandi yang valid. Anda perlu menginisialisasi ulang sistem otentikasi dan tidak
hanya mengubah kredensial yang digunakan oleh penyusup. Ini penting karena penyusup
mungkin juga telah memperoleh akses ke kata sandi pengguna lain. Oleh karena itu, Anda
perlu memastikan bahwa semua pengguna yang berwenang mengubah kata sandi mereka.
Anda juga harus memastikan bahwa orang yang tidak berwenang tidak memiliki akses ke mekanisme perubahan kata
Oleh karena itu Anda harus merancang sistem Anda untuk menolak akses ke semua orang
sampai mereka mengubah kata sandi mereka dan untuk mengautentikasi pengguna nyata untuk perubahan kata sandi,
Memahami dan Mendefinisikan Instal Perangkat Lunak pada
Operasional Perangkat Lunak Komputer Dimana itu

Lingkungan Akan Beroperasi
Konfigurasikan Perangkat Lunak dengan Konfigurasikan Perangkat Lunak dengan

Detail Lingkungan Detail Komputer
dengan asumsi bahwa kata sandi yang mereka pilih mungkin tidak aman. Salah satu cara untuk
Gambar 14.7 Penerapan
perangkat lunak melakukan ini adalah dengan menggunakan mekanisme tantangan/tanggapan, di mana pengguna
harus menjawab pertanyaan yang telah mereka daftarkan sebelumnya jawabannya. Ini hanya
dipanggil ketika kata sandi diubah, memungkinkan pemulihan dari serangan dengan gangguan pengguna yang relatif sedi
14.2.3 Desain untuk penyebaran

Penyebaran sistem melibatkan konfigurasi perangkat lunak untuk beroperasi di lingkungan
operasi, menginstal sistem pada komputer di lingkungan itu, dan kemudian mengkonfigurasi
sistem yang diinstal untuk komputer ini (Gambar 14.7). Konfigurasi mungkin merupakan proses
sederhana yang melibatkan pengaturan beberapa parameter bawaan dalam perangkat lunak
untuk mencerminkan preferensi pengguna. Namun, terkadang konfigurasi itu rumit dan
memerlukan definisi spesifik dari model bisnis dan aturan yang memengaruhi eksekusi perangkat lunak.
Pada tahap proses perangkat lunak inilah kerentanan dalam perangkat lunak sering kali
muncul secara tidak sengaja. Misalnya, selama penginstalan, perangkat lunak sering kali harus
dikonfigurasi dengan daftar pengguna yang diizinkan. Saat dikirimkan, daftar ini hanya terdiri
dari login administrator umum seperti 'admin' dan kata sandi default, seperti 'password'. Ini
memudahkan administrator untuk mengatur sistem. Tindakan pertama mereka adalah
memperkenalkan nama login dan kata sandi baru, dan menghapus nama login umum. Namun,
mudah untuk melupakan hal ini. Penyerang yang mengetahui login default kemudian dapat
memperoleh akses istimewa ke sistem.
Konfigurasi dan penyebaran sering dilihat sebagai masalah administrasi sistem dan dianggap
berada di luar lingkup proses rekayasa perangkat lunak.
Tentu saja, praktik manajemen yang baik dapat menghindari banyak masalah keamanan yang
muncul dari kesalahan konfigurasi dan penerapan. Namun, perancang perangkat lunak memiliki
tanggung jawab untuk 'mendesain untuk penyebaran'. Anda harus selalu menyediakan dukungan
bawaan untuk penerapan yang akan mengurangi kemungkinan bahwa administrator sistem (atau
pengguna) akan membuat kesalahan saat mengonfigurasi perangkat lunak.
Saya merekomendasikan empat cara untuk memasukkan dukungan penerapan dalam suatu sistem:
1. Menyertakan dukungan untuk melihat dan menganalisis konfigurasi Anda harus selalu
menyertakan fasilitas dalam sistem yang memungkinkan administrator atau pengguna yang
diizinkan untuk memeriksa konfigurasi sistem saat ini. Secara mengejutkan, fasilitas ini
kurang dari kebanyakan sistem perangkat lunak dan pengguna merasa frustrasi dengan
kesulitan menemukan pengaturan konfigurasi. Misalnya, dalam versi pengolah kata yang
saya gunakan untuk menulis bab ini, tidak mungkin untuk melihat atau mencetak pengaturan semua sistem
preferensi pada satu layar. Namun, jika seorang administrator bisa mendapatkan
gambaran lengkap dari konfigurasi, mereka lebih mungkin untuk menemukan kesalahan dan kelalaian.
Idealnya, tampilan konfigurasi juga harus menyoroti aspek konfigurasi yang berpotensi
tidak aman—misalnya, jika kata sandi belum disiapkan.
2. Minimalkan hak istimewa default Anda harus merancang perangkat lunak sehingga
konfigurasi default sistem memberikan hak dasar minimum. Dengan cara ini, kerusakan
yang dapat dilakukan penyerang mana pun dapat dibatasi. Misalnya, otentikasi
administrator sistem default seharusnya hanya mengizinkan akses ke program yang
memungkinkan administrator untuk menyiapkan kredensial baru. Seharusnya tidak
mengizinkan akses ke fasilitas sistem lainnya. Setelah kredensial baru disiapkan, login
dan kata sandi default harus dihapus secara otomatis.
3. Melokalkan pengaturan konfigurasi Saat merancang dukungan konfigurasi sistem, Anda

harus memastikan bahwa segala sesuatu dalam konfigurasi yang memengaruhi bagian
yang sama dari suatu sistem telah diatur di tempat yang sama. Untuk menggunakan
contoh pengolah kata lagi, dalam versi yang saya gunakan, saya dapat mengatur
beberapa informasi keamanan, seperti kata sandi untuk mengontrol akses ke dokumen, menggunakan menu Prefere
Informasi lainnya diatur dalam menu Alat/Proteksi Dokumen. Jika informasi konfigurasi
tidak terlokalisasi, mudah untuk lupa mengaturnya atau, dalam beberapa kasus, bahkan
tidak menyadari bahwa beberapa fasilitas keamanan disertakan dalam sistem.
4. Menyediakan cara mudah untuk memperbaiki kerentanan keamanan Anda harus

menyertakan mekanisme langsung untuk memperbarui sistem untuk memperbaiki
kerentanan keamanan yang telah ditemukan. Ini dapat mencakup pemeriksaan otomatis
untuk pembaruan keamanan, atau mengunduh pembaruan ini segera setelah tersedia.
Adalah penting bahwa pengguna tidak dapat melewati mekanisme ini karena, mau tidak
mau, mereka akan menganggap pekerjaan lain lebih penting. Ada beberapa contoh
rekaman masalah keamanan utama yang muncul (misalnya, kegagalan total jaringan
rumah sakit) karena pengguna tidak memperbarui perangkat lunak mereka ketika diminta untuk melakukannya.
14.3 Kelangsungan hidup sistem
Sejauh ini, saya telah membahas rekayasa keamanan dari perspektif aplikasi yang sedang
dikembangkan. Penyedia dan pengembang sistem memiliki kendali atas semua aspek sistem
yang mungkin diserang. Pada kenyataannya, seperti yang saya sarankan pada Gambar 14.1,
sistem terdistribusi modern pasti bergantung pada infrastruktur yang mencakup sistem siap
pakai dan komponen yang dapat digunakan kembali yang telah dikembangkan oleh organisasi
yang berbeda. Keamanan sistem ini tidak hanya bergantung pada keputusan desain lokal.
Hal ini juga dipengaruhi oleh keamanan aplikasi eksternal, layanan web, dan infrastruktur jaringan.
Ini berarti bahwa, terlepas dari seberapa besar perhatian diberikan pada keamanan, tidak
dapat dijamin bahwa suatu sistem akan mampu menahan serangan eksternal. Akibatnya,
untuk sistem jaringan yang kompleks, Anda harus berasumsi bahwa penetrasi dimungkinkan
dan integritas sistem tidak dapat dijamin. Oleh karena itu, Anda harus memikirkan cara
membuat sistem menjadi tangguh sehingga dapat bertahan untuk memberikan layanan penting kepada pengguna.
14.3 Ketahanan sistem 387
Ketahanan atau ketahanan (Westmark, 2004) adalah properti yang muncul dari suatu
sistem secara keseluruhan, bukan properti komponen individu, yang mungkin tidak dapat
bertahan. Kelangsungan hidup suatu sistem mencerminkan kemampuannya untuk terus
memberikan layanan bisnis atau misi-kritis penting kepada pengguna yang sah saat sedang
diserang atau setelah bagian dari sistem rusak. Kerusakan dapat disebabkan oleh serangan
atau kegagalan sistem.
Bekerja pada ketahanan sistem didorong oleh fakta bahwa kehidupan ekonomi dan sosial
kita bergantung pada infrastruktur kritis yang dikendalikan komputer. Ini termasuk infrastruktur
untuk pengiriman utilitas (listrik, air, gas, dll.) dan, yang sama pentingnya, infrastruktur untuk
pengiriman dan pengelolaan informasi (telepon, Internet, layanan pos, dll.). Namun,
kelangsungan hidup bukan hanya masalah infrastruktur yang kritis. Setiap organisasi yang
bergantung pada sistem komputer jaringan kritis harus memperhatikan bagaimana bisnisnya
akan terpengaruh jika sistem mereka tidak bertahan dari serangan berbahaya atau kegagalan
sistem bencana. Oleh karena itu, untuk sistem kritis bisnis, analisis dan desain kemampuan
bertahan harus menjadi bagian dari proses rekayasa keamanan.
Menjaga ketersediaan layanan kritis adalah inti dari survivability.
Ini berarti Anda harus tahu:
• layanan sistem yang paling penting untuk bisnis;
• minimnya kualitas pelayanan yang harus dipertahankan;
• bagaimana layanan ini dapat dikompromikan;
• bagaimana layanan ini dapat dilindungi;
• bagaimana Anda dapat memulihkan dengan cepat jika layanan menjadi tidak tersedia.
Misalnya, dalam sistem yang menangani pengiriman ambulans dalam menanggapi

panggilan darurat, layanan kritis adalah mereka yang peduli dengan menerima panggilan dan
mengirimkan ambulans ke darurat medis. Layanan lain, seperti pencatatan panggilan dan
manajemen lokasi ambulans, kurang penting, baik karena tidak memerlukan pemrosesan
waktu nyata atau karena mekanisme alternatif dapat digunakan. Misalnya, untuk menemukan
lokasi ambulans, Anda dapat menghubungi kru ambulans dan menanyakan di mana mereka berada.
Ellison dan rekan (1999a; 1999b; 2002) telah merancang metode analisis yang disebut
Analisis Sistem Bertahan. Ini digunakan untuk menilai kerentanan dalam sistem dan untuk
mendukung desain arsitektur sistem dan fitur yang mempromosikan kemampuan bertahan
sistem. Mereka berpendapat bahwa mencapai survivabilitas tergantung pada tiga strategi
pelengkap:
1. Perlawanan Menghindari masalah dengan membangun kemampuan ke dalam sistem untuk

menolak serangan. Misalnya, suatu sistem dapat menggunakan sertifikat digital untuk
mengautentikasi pengguna, sehingga mempersulit pengguna yang tidak berwenang untuk mendapatkan akses.
2. Pengenalan Mendeteksi masalah dengan membangun kemampuan ke dalam sistem untuk

mendeteksi serangan dan kegagalan dan menilai kerusakan yang dihasilkan. Misalnya,
checksum dapat dikaitkan dengan data penting sehingga kerusakan pada data tersebut dapat dideteksi.
3. Pemulihan Menoleransi masalah dengan membangun kemampuan ke dalam sistem untuk

memberikan layanan penting saat diserang, dan memulihkan fungsionalitas penuh setelah
1. Tinjau Persyaratan
dan Arsitektur Sistem
4. Identifikasi Softspots 2. Identifikasi Layanan

dan Strategi Bertahan dan Komponen
Hidup Penting
3. Identifikasi
Serangan dan Komponen
Gambar 14.8 Tahapan yang Dapat Dikompromikan
dalam analisis survivabilitas
menyerang. Misalnya, mekanisme toleransi kesalahan yang menggunakan beragam

implementasi dari fungsi yang sama dapat dimasukkan untuk mengatasi hilangnya layanan
dari satu bagian sistem.
Analisis sistem yang dapat bertahan adalah proses empat tahap (Gambar 14.8) yang
menganalisis persyaratan dan arsitektur sistem saat ini atau yang diusulkan; mengidentifikasi
layanan kritis, skenario serangan, dan 'titik lemah' sistem; dan mengusulkan perubahan untuk
meningkatkan kemampuan bertahan sistem. Kegiatan utama dalam setiap tahapan ini adalah sebagai berikut:
1. Pemahaman sistem Untuk sistem yang ada atau yang diusulkan, tinjau tujuan sistem (kadang-
kadang disebut tujuan misi), persyaratan sistem, dan arsitektur sistem.
2. Identifikasi layanan kritis Layanan yang harus selalu dipelihara dan komponen yang
diperlukan untuk mempertahankan layanan ini diidentifikasi.
3. Simulasi serangan Skenario atau kasus penggunaan untuk kemungkinan serangan

diidentifikasi bersama dengan komponen sistem yang akan terpengaruh oleh serangan ini.
4. Analisis kemampuan bertahan Komponen yang penting dan dapat dikompromikan oleh
serangan diidentifikasi dan strategi bertahan hidup berdasarkan resistensi, pengenalan,
dan pemulihan diidentifikasi.
Ellison dan rekan-rekannya menyajikan studi kasus yang sangat baik tentang metode yang
didasarkan pada sistem untuk mendukung perawatan kesehatan mental (1999b). Sistem ini
mirip dengan MHC-PMS yang saya gunakan sebagai contoh dalam buku ini. Daripada
mengulangi analisis mereka, saya menggunakan sistem perdagangan ekuitas, seperti yang
ditunjukkan pada Gambar 14.5, untuk menggambarkan beberapa fitur analisis survivability.
Seperti yang Anda lihat dari Gambar 14.5, sistem ini telah membuat beberapa ketentuan
untuk bertahan hidup. Akun pengguna dan harga ekuitas direplikasi di seluruh server sehingga
pesanan dapat dilakukan meskipun server lokal tidak tersedia. Mari kita asumsikan bahwa
kemampuan pengguna yang berwenang untuk memesan stok adalah layanan utama yang harus
dipertahankan. Untuk memastikan bahwa pengguna mempercayai sistem, integritas harus dipertahankan.
Pesanan harus akurat dan mencerminkan penjualan atau pembelian aktual yang dilakukan oleh pengguna sistem.
14.3 Ketahanan sistem 389
Menyerang Perlawanan Pengakuan Pemulihan
Pengguna yang tidak sah Memerlukan kata sandi Kirim salinan pesanan melalui Menyediakan mekanisme untuk
menempatkan pesanan transaksi yang berbeda email ke pengguna yang berwenang secara otomatis 'membatalkan'
berbahaya dari kata sandi login dengan nomor telepon kontak perdagangan dan memulihkan
untuk melakukan (sehingga mereka dapat mendeteksi akun pengguna.
pemesanan. pesanan jahat). Mengembalikan dana pengguna
Pertahankan riwayat pesanan untuk kerugian yang disebabkan oleh
pengguna dan periksa pola perdagangan berbahaya.
perdagangan yang tidak biasa.

Asuransikan
terhadap kerugian konsekuensial.
Korupsi database Pertahankan salinan transaksi Pulihkan basis data dari salinan
transaksi Mengharuskan hanya-baca untuk kantor di server cadangan.
pengguna yang internasional. Bandingkan transaksi
Menyediakan mekanisme
memiliki hak istimewa secara berkala untuk memeriksa
untuk memutar ulang
untuk diotorisasi korupsi.
perdagangan dari waktu yang
menggunakan ditentukan untuk membuat kembali basis data transaksi.
mekanisme autentikasi
Memelihara checksum
yang lebih kuat, seperti sertifikat digital.
kriptografi dengan semua
catatan transaksi untuk
mendeteksi korupsi.
Untuk mempertahankan layanan pemesanan ini, ada tiga komponen sistem yang digunakan:
Gambar 14.9
Analisis kelangsungan
hidup dalam sistem
perdagangan ekuitas 1. Otentikasi pengguna Ini memungkinkan pengguna yang berwenang untuk masuk ke sistem.
2. Price Quotation Ini memungkinkan harga beli dan jual saham untuk dikutip.
3. Penempatan pesanan Ini memungkinkan dibuatnya pesanan beli dan jual pada harga tertentu.
Komponen-komponen ini jelas menggunakan aset data penting seperti database akun
pengguna, database harga, dan database transaksi pesanan. Ini harus bertahan dari serangan
jika layanan ingin dipertahankan.
Ada beberapa jenis serangan yang berbeda pada sistem ini yang mungkin dilakukan.
Mari kita pertimbangkan dua kemungkinan di sini:
1. Seorang pengguna jahat memiliki dendam terhadap pengguna sistem terakreditasi. Dia
mendapatkan akses ke sistem menggunakan kredensial mereka. Pesanan jahat ditempatkan
dan stok dibeli dan dijual, dengan maksud menyebabkan masalah bagi pengguna yang berwenang.
2. Pengguna yang tidak sah merusak database transaksi dengan mendapatkan izin untuk
mengeluarkan perintah SQL secara langsung. Oleh karena itu, rekonsiliasi penjualan dan
pembelian tidak mungkin dilakukan.
Gambar 14.9 menunjukkan contoh strategi perlawanan, pengenalan, dan pemulihan yang
mungkin digunakan untuk membantu melawan serangan ini.
Meningkatkan survivabilitas atau ketahanan suatu sistem tentu saja membutuhkan biaya.
Perusahaan mungkin enggan untuk berinvestasi dalam kelangsungan hidup jika mereka tidak
pernah mengalami serangan serius atau kerugian terkait. Namun, seperti yang terbaik untuk
membeli kunci yang baik dan alarm sebelum daripada setelah rumah Anda dirampok, yang terbaik
adalah berinvestasi dalam kelangsungan hidup sebelum, daripada setelah, serangan yang berhasil.
Analisis survivabilitas belum menjadi bagian dari sebagian besar proses rekayasa perangkat lunak
tetapi, karena semakin banyak sistem menjadi kritis bisnis, analisis semacam itu cenderung menjadi lebih banyak digunakan.
POIN KUNCI
Rekayasa keamanan berfokus pada bagaimana mengembangkan dan memelihara sistem perangkat lunak yang dapat menahan
serangan berbahaya yang dimaksudkan untuk merusak sistem berbasis komputer atau datanya.
Ancaman keamanan dapat berupa ancaman terhadap kerahasiaan, integritas, atau ketersediaan sistem atau datanya.
Manajemen risiko keamanan melibatkan penilaian kerugian yang mungkin timbul dari serangan pada sistem, dan menurunkan
persyaratan keamanan yang ditujukan untuk menghilangkan atau mengurangi kerugian ini.
Desain untuk keamanan melibatkan perancangan arsitektur sistem yang aman, mengikuti praktik yang baik untuk desain sistem
yang aman, dan menyertakan fungsionalitas untuk meminimalkan kemungkinan memperkenalkan kerentanan saat sistem
diterapkan.
Masalah utama saat merancang arsitektur sistem yang aman termasuk mengatur sistem
struktur untuk melindungi aset utama dan mendistribusikan aset sistem untuk meminimalkan kerugian dari serangan
yang berhasil.
Pedoman desain keamanan membuat perancang sistem peka terhadap masalah keamanan yang mungkin tidak mereka
pertimbangkan. Mereka memberikan dasar untuk membuat daftar periksa tinjauan keamanan.
Untuk mendukung penerapan yang aman, Anda harus menyediakan cara menampilkan dan menganalisis konfigurasi sistem,
melokalkan pengaturan konfigurasi sehingga konfigurasi penting tidak dilupakan, meminimalkan hak default yang
ditetapkan untuk pengguna sistem, dan menyediakan cara untuk memperbaiki kerentanan keamanan.
Sistem bertahan hidup mencerminkan kemampuan sistem untuk terus memberikan bisnis penting atau layanan misi-kritis kepada
pengguna yang sah saat sedang diserang, atau setelah bagian dari sistem telah rusak.
BACAAN LEBIH LANJUT
'Analisis Sistem Jaringan yang Dapat Bertahan: Studi Kasus.' Makalah luar biasa yang memperkenalkan gagasan
tentang kemampuan bertahan sistem dan menggunakan studi kasus sistem perawatan catatan kesehatan mental untuk
menggambarkan penerapan metode kemampuan bertahan. (RJ Ellison, RC Linger, T. Longstaff dan NR Mead, Perangkat
Lunak IEEE, 16 (4), Juli/Agustus 1999.)
Membangun Perangkat Lunak Aman: Cara Menghindari Masalah Keamanan dengan Cara yang Benar. Buku
praktis yang bagus yang membahas keamanan dari perspektif pemrograman. (J. Viega dan G. McGraw, Addison-Wesley, 2002.)
Rekayasa Keamanan: Panduan untuk Membangun Sistem Terdistribusi yang Dapat Diandalkan, edisi ke-2. Ini
adalah diskusi menyeluruh dan komprehensif tentang masalah membangun sistem yang aman. Fokusnya adalah pada
sistem daripada rekayasa perangkat lunak dengan cakupan perangkat keras dan jaringan yang luas, dengan contoh luar
biasa yang diambil dari kegagalan sistem nyata. (R. Anderson, John Wiley & Sons, 2008.)
LATIHAN
14.1. Jelaskan perbedaan penting antara rekayasa keamanan aplikasi dan

rekayasa keamanan infrastruktur.
14.2. Untuk MHC-PMS, sarankan contoh aset, eksposur, kerentanan, serangan, ancaman,
dan kontrol.
14.3. Jelaskan mengapa perlunya penilaian risiko menjadi proses yang berkelanjutan sejak dini
tahapan rekayasa kebutuhan hingga penggunaan operasional suatu sistem.
14.4. Menggunakan jawaban Anda atas pertanyaan 2 tentang MHC-PMS, menilai risiko yang terkait dengan sistem itu
dan mengusulkan dua persyaratan sistem yang dapat mengurangi risiko ini.
14.5. Jelaskan, dengan menggunakan analogi yang diambil dari konteks rekayasa non-perangkat lunak, mengapa sebuah lapisan
pendekatan perlindungan aset harus digunakan.
14.6. Jelaskan mengapa penting untuk menggunakan beragam teknologi untuk mendukung sistem terdistribusi di
situasi di mana ketersediaan sistem sangat penting.
14.7. Apa itu rekayasa sosial? Mengapa sulit untuk melindunginya di organisasi besar?
14.8. Untuk sistem perangkat lunak siap pakai apa pun yang Anda gunakan (mis. Microsoft Word), analisis
fasilitas konfigurasi yang disertakan dan diskusikan masalah apa pun yang Anda temukan.
14.9. Jelaskan bagaimana strategi pelengkap perlawanan, pengakuan, dan pemulihan mungkin?
digunakan untuk meningkatkan kelangsungan hidup suatu sistem.
14.10. Untuk sistem perdagangan ekuitas yang dibahas dalam Bagian 14.2.1, yang arsitekturnya ditunjukkan pada
Gambar 14.5, menyarankan dua serangan lebih lanjut yang masuk akal pada sistem dan mengusulkan
kemungkinan strategi yang dapat melawan serangan ini.
REFERENSI
Alberts, C. dan Dorofee, A. (2002). Mengelola Risiko Keamanan Informasi: Pendekatan OCTAVE.
Boston: Addison-Wesley.
Alexander, I. (2003). 'Kasus Penyalahgunaan: Kasus Penggunaan dengan Niat Bermusuhan'. Perangkat Lunak IEEE, 20 (1), 58–66.
Anderson, R. (2008). Rekayasa Keamanan, edisi ke-2. Chichester: John Wiley & Sons.
Berghel, H. (2001). 'Kode Cacing Merah'. Kom. ACM, 44 (12), 15–19.
Uskup, M. (2005). Pengantar Keamanan Komputer. Boston: Addison-Wesley.
Cranor, L. dan Garfinkel, S. (2005). Keamanan dan Kegunaan: Merancang sistem aman yang dapat digunakan
orang. Sebastopol, California: O'Reilly Media Inc.
Ellison, R., Linger, R., Lipson, H., Mead, N. dan Moore, A. (2002). 'Yayasan Rekayasa Sistem yang Dapat Bertahan'.
Crosstalk: Jurnal Rekayasa Perangkat Lunak Pertahanan, 12, 10-15.
Ellison, RJ, Fisher, DA, Berlama-lama, RC, Lipson, HF, Longstaff, TA dan Mead, NR (1999a).
'Kelangsungan Hidup: Melindungi Sistem Kritis Anda'. Komputasi Internet IEEE, 3 (6), 55–63.
Ellison, RJ, Linger, RC, Longstaff, T. dan Mead, NR (1999b). 'Analisis Sistem Jaringan yang Bertahan Hidup: Studi
Kasus'. Perangkat Lunak IEEE, 16 (4), 70–7.
Pfleeger, CP dan Pfleeger, SL (2007). Keamanan dalam Komputasi, edisi ke-4. Boston: Addison-Wesley.
Schneier, B. (2000). Rahasia dan Kebohongan: Keamanan Digital di Dunia Jaringan. New York:
John Wiley & Sons.
Sindre, G. dan Opdahl, AL (2005). 'Mendapatkan Persyaratan Keamanan melalui Kasus Penyalahgunaan'.
Rekayasa Persyaratan, 10 (1), 34–44.
Spafford, E. (1989). 'Cacing Internet: Krisis dan Akibat'. Comm ACM, 32 (6), 678–87.
Viega, J. dan McGraw, G. (2002). Membangun Perangkat Lunak Aman. Boston: Addison-Wesley.
Westmark, VR (2004). 'Definisi untuk Kelangsungan Hidup Sistem Informasi'. 37 Hawaii Int. Kon. tentang Ilmu
Sistem, Hawaii: 903–1003.
Wheeler, DA (2003). Pemrograman Aman untuk Linux dan UNIx HOWTO. Web diterbitkan: http://
www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html.
15
Keandalan dan
jaminan keamanan
Tujuan
Tujuan dari bab ini adalah untuk menjelaskan teknik verifikasi dan validasi yang
digunakan dalam pengembangan sistem kritis. Setelah Anda membaca bab ini,
Anda akan:
memahami bagaimana pendekatan yang berbeda untuk analisis statis dapat

digunakan dalam verifikasi sistem perangkat lunak penting;
memahami dasar-dasar pengujian keandalan dan keamanan serta masalah

yang melekat dalam pengujian sistem kritis;
mengetahui mengapa jaminan proses itu penting, terutama untuk perangkat lunak
yang harus disertifikasi oleh regulator;
telah diperkenalkan pada kasus keamanan dan ketergantungan yang menyajikan

argumen dan bukti keamanan dan ketergantungan sistem .
Isi
15.1 Analisis statis 15.2
Pengujian keandalan 15.3
Pengujian keamanan
15.4 Jaminan proses
15.5 Kasus keamanan dan ketergantungan

394 Bab 15 Keandalan dan jaminan keamanan
Keandalan dan jaminan keamanan berkaitan dengan memeriksa bahwa sistem kritis memenuhi
persyaratan ketergantungannya. Ini membutuhkan verifikasi dan validasi
(V & V) proses yang mencari spesifikasi, desain, dan kesalahan program yang mungkin
mempengaruhi ketersediaan, keselamatan, keandalan, atau keamanan suatu sistem.
Verifikasi dan validasi sistem kritis memiliki banyak kesamaan dengan
validasi sistem perangkat lunak lainnya. Proses V & V harus menunjukkan
bahwa sistem memenuhi spesifikasinya dan bahwa layanan dan perilaku sistem mendukung
kebutuhan pelanggan. Dalam melakukannya, mereka biasanya mengungkap persyaratan
dan kesalahan desain dan bug program yang harus diperbaiki. Namun, sistem kritis memerlukan
pengujian dan analisis yang sangat ketat karena dua alasan:
1. Biaya kegagalan Biaya dan konsekuensi dari kegagalan sistem kritis adalah
berpotensi jauh lebih besar daripada untuk sistem non-kritis. Anda menurunkan risiko
kegagalan sistem dengan menghabiskan lebih banyak untuk verifikasi dan validasi sistem.
Biasanya lebih murah untuk menemukan dan menghilangkan cacat sebelum sistem dikirimkan daripada
membayar biaya akibat kecelakaan atau gangguan pada layanan sistem.
2. Validasi atribut ketergantungan Anda mungkin harus membuat kasus formal untuk
pelanggan dan regulator bahwa sistem memenuhi persyaratan ketergantungan yang
ditentukan (ketersediaan, keandalan, keselamatan, dan keamanan). Dalam beberapa kasus,
regulator eksternal, seperti otoritas penerbangan nasional, mungkin harus memastikan bahwa sistem tersebut aman.
sebelum dapat disebarkan. Untuk mendapatkan sertifikasi ini, Anda harus menunjukkan caranya
sistem telah divalidasi. Untuk melakukannya, Anda mungkin juga harus merancang dan melaksanakan
prosedur V & V khusus yang mengumpulkan bukti tentang ketergantungan sistem.
Untuk alasan ini, biaya verifikasi dan validasi untuk sistem kritis biasanya:
jauh lebih tinggi daripada kelas sistem lainnya. Biasanya, lebih dari setengah kritis
biaya pengembangan sistem dihabiskan untuk V & V.
Meskipun biaya V & V tinggi, mereka dibenarkan karena biasanya jauh lebih kecil daripada
kerugian akibat kecelakaan. Misalnya, pada tahun 1996, sistem perangkat lunak misi-kritis pada
roket Ariane 5 gagal dan beberapa satelit hancur. Tidak ada yang terluka tetapi total kerugian
dari kecelakaan ini adalah
ratusan juta dolar. Penyelidikan selanjutnya menemukan bahwa kekurangan dalam sistem V &
V ikut bertanggung jawab atas kegagalan ini. Lebih efektif
ulasan, yang akan relatif murah, dapat menemukan
masalah yang menyebabkan kecelakaan.
Meskipun fokus utama dari ketergantungan dan jaminan keamanan adalah pada validasi
sistem itu sendiri, aktivitas terkait harus memverifikasi bahwa sistem yang ditentukan
proses pengembangan telah diikuti. Seperti yang saya jelaskan di Bab 13, kualitas sistem
dipengaruhi oleh kualitas proses yang digunakan untuk mengembangkan sistem. Singkatnya, bagus
proses menghasilkan sistem yang baik.
Hasil dari proses ketergantungan dan jaminan keamanan adalah kumpulan bukti nyata,
seperti laporan tinjauan, hasil pengujian, dll., tentang ketergantungan suatu sistem. Bukti ini
selanjutnya dapat digunakan untuk membenarkan keputusan bahwa sistem ini
dapat diandalkan dan cukup aman untuk digunakan dan digunakan. Terkadang, buktinya
15.1 Analisis statis 395
ketergantungan sistem dirakit dalam kasus ketergantungan atau keselamatan. Ini digunakan
untuk meyakinkan pelanggan atau regulator eksternal bahwa kepercayaan pengembang dalam
ketergantungan atau keamanan sistem dapat dibenarkan.
15.1 Analisis statis

Teknik analisis statis adalah teknik verifikasi sistem yang tidak melibatkan eksekusi program.
Sebaliknya, mereka bekerja pada representasi sumber perangkat lunak — baik model spesifikasi
atau desain, atau kode sumber program.
Teknik analisis statis dapat digunakan untuk memeriksa spesifikasi dan model desain sistem
untuk mendeteksi kesalahan sebelum versi sistem yang dapat dieksekusi tersedia.
Mereka juga memiliki keuntungan bahwa adanya kesalahan tidak mengganggu pemeriksaan
sistem. Saat Anda menguji sebuah program, cacat dapat menutupi atau menyembunyikan cacat
lain sehingga Anda harus menghapus cacat yang terdeteksi kemudian ulangi proses pengujian.
Seperti yang saya bahas di Bab 8, mungkin teknik analisis statis yang paling umum
digunakan adalah peer review dan inspeksi, di mana spesifikasi, desain, atau program diperiksa
oleh sekelompok orang. Mereka memeriksa desain atau kode secara rinci, mencari kemungkinan
kesalahan atau kelalaian. Teknik lain menggunakan alat pemodelan desain untuk memeriksa
anomali di UML, seperti nama yang sama digunakan untuk objek yang berbeda.
Namun, untuk sistem kritis, teknik analisis statis tambahan dapat digunakan:
1. Verifikasi formal, di mana Anda menghasilkan argumen matematis yang ketat bahwa
program sesuai dengan spesifikasinya.
2. Pengecekan model, di mana sebuah pembuktian teorema digunakan untuk memeriksa

deskripsi formal dari sistem untuk inkonsistensi.
3. Analisis program otomatis, di mana kode sumber program diperiksa untuk pola yang diketahui
berpotensi salah.
Teknik-teknik ini terkait erat. Pengecekan model bergantung pada model formal dari sistem
yang dapat dibuat dari spesifikasi formal. Penganalisis statis dapat menggunakan pernyataan
formal yang disematkan dalam program sebagai komentar untuk memeriksa bahwa kode terkait
konsisten dengan pernyataan ini.
15.1.1 Verifikasi dan metode formal

Metode formal pengembangan perangkat lunak, seperti yang saya bahas di Bab 12, bergantung
pada model mal dari sistem yang berfungsi sebagai spesifikasi sistem. Metode formal ini
terutama berkaitan dengan analisis matematis dari spesifikasi; dengan trans membentuk
spesifikasi ke representasi yang lebih rinci dan setara secara semantik; atau dengan
memverifikasi secara formal bahwa satu representasi dari sistem secara semantik setara dengan
representasi lain.
Pengembangan kamar bersih
Pengembangan perangkat lunak Cleanroom didasarkan pada verifikasi perangkat lunak formal dan pengujian statistik. Objektif
dari proses Cleanroom adalah perangkat lunak tanpa cacat untuk memastikan bahwa sistem yang dikirimkan memiliki tingkat
keandalan. Dalam proses Cleanroom setiap peningkatan perangkat lunak secara formal ditentukan dan spesifikasi ini adalah
diubah menjadi implementasi. Kebenaran perangkat lunak ditunjukkan dengan menggunakan pendekatan formal. Ada
tidak ada pengujian unit untuk cacat dalam proses dan pengujian sistem difokuskan pada penilaian keandalan sistem.
http://www.SoftwareEngineering-9.com/Web/Cleanroom/
Metode formal dapat digunakan pada tahap yang berbeda dalam proses V & V:
1. Sebuah spesifikasi formal dari sistem dapat dikembangkan dan dianalisis secara matematis untuk
inkonsistensi. Teknik ini efektif dalam menemukan spesifikasi
kesalahan dan kelalaian. Pengecekan model, yang dibahas di bagian berikutnya, adalah salah satunya
pendekatan untuk analisis spesifikasi.
2. Anda dapat memverifikasi secara formal, menggunakan argumen matematika, bahwa kode perangkat lunak
sistem sesuai dengan spesifikasinya. Ini membutuhkan spesifikasi formal. Dia
efektif dalam menemukan pemrograman dan beberapa kesalahan desain.
Karena kesenjangan semantik yang lebar antara spesifikasi sistem formal dan kode program, sulit
untuk membuktikan bahwa program yang dikembangkan secara terpisah konsisten
dengan spesifikasinya. Oleh karena itu, bekerja pada verifikasi program sekarang didasarkan pada
pengembangan transformasional. Dalam proses pengembangan transformasional, spesifikasi formal
ditransformasikan melalui serangkaian representasi ke kode program. Perangkat lunak
alat mendukung pengembangan transformasi dan membantu memverifikasi bahwa representasi
sistem yang sesuai adalah konsisten. Metode B mungkin yang paling
banyak digunakan metode transformasi formal (Abrial, 2005; Wordsworth, 1996). Dia
telah digunakan untuk pengembangan sistem kontrol kereta api dan perangkat lunak avionik.
Pendukung metode formal mengklaim bahwa penggunaan metode ini mengarah ke lebih banyak
sistem yang andal dan lebih aman. Verifikasi formal menunjukkan bahwa program yang dikembangkan
memenuhi spesifikasinya dan bahwa kesalahan implementasi tidak akan membahayakan
ketergantungan sistem. Jika Anda mengembangkan model formal sistem konkuren
menggunakan spesifikasi yang ditulis dalam bahasa seperti CSP (Schneider, 1999), Anda dapat
menemukan kondisi yang mungkin mengakibatkan kebuntuan dalam program akhir, dan dapat
alamat ini. Ini sangat sulit dilakukan dengan pengujian saja.
Namun, spesifikasi dan bukti formal tidak menjamin bahwa perangkat lunak akan
dapat diandalkan dalam penggunaan praktis. Alasan untuk ini adalah sebagai berikut:
1. Spesifikasi mungkin tidak mencerminkan kebutuhan sebenarnya dari pengguna sistem. Seperti
yang saya bahas di Bab 12, pengguna sistem jarang memahami notasi formal sehingga mereka
tidak dapat langsung membaca spesifikasi formal untuk menemukan kesalahan dan kelalaian. Ini
berarti bahwa ada kemungkinan signifikan bahwa spesifikasi formal mengandung
kesalahan dan bukan merupakan representasi akurat dari persyaratan sistem.
2. Bukti mungkin mengandung kesalahan. Bukti program besar dan kompleks, jadi, seperti
program besar dan kompleks, mereka biasanya mengandung kesalahan.
3. Pembuktian dapat membuat asumsi yang salah tentang cara sistem digunakan. Jika sistem tidak
digunakan seperti yang diharapkan, buktinya mungkin tidak valid.
Memverifikasi sistem perangkat lunak non-sepele membutuhkan banyak waktu dan membutuhkan
keahlian matematika dan perangkat lunak khusus, seperti pembuktian teorema. Oleh karena itu, ini
merupakan proses yang mahal dan, seiring dengan bertambahnya ukuran sistem, biaya verifikasi
formal meningkat secara tidak proporsional. Oleh karena itu, banyak insinyur perangkat lunak
berpikir bahwa verifikasi formal tidak efektif dari segi biaya. Mereka percaya bahwa tingkat
kepercayaan yang sama dalam sistem dapat dicapai dengan lebih murah dengan menggunakan
teknik validasi lainnya, seperti inspeksi dan pengujian sistem.
Terlepas dari kekurangannya, pandangan saya adalah bahwa metode formal dan verifikasi
formal memiliki peran penting dalam pengembangan sistem perangkat lunak kritis.
Spesifikasi formal sangat efektif dalam menemukan masalah spesifikasi yang merupakan penyebab
paling umum dari kegagalan sistem. Meskipun verifikasi formal masih tidak praktis untuk sistem
besar, itu dapat digunakan untuk memverifikasi komponen kritis keselamatan dan keamanan.
15.1.2 Pemeriksaan model

Program verifikasi formal menggunakan pendekatan deduktif sulit dan mahal tetapi pendekatan
alternatif untuk analisis formal telah dikembangkan yang didasarkan pada gagasan kebenaran yang
lebih terbatas. Yang paling sukses dari pendekatan ini disebut model checking (Baier dan Katoen,
2008). Ini telah banyak digunakan untuk memeriksa desain sistem perangkat keras dan semakin
banyak digunakan dalam sistem perangkat lunak penting seperti perangkat lunak kontrol di
kendaraan eksplorasi Mars NASA (Regan dan Hamilton, 2004) dan perangkat lunak pemrosesan
panggilan telepon (Chandra et al., 2002).
Pengecekan model melibatkan pembuatan model sistem dan pengecekan kebenaran model
tersebut menggunakan perangkat lunak khusus. Banyak alat pemeriksaan model yang berbeda telah
dikembangkan—untuk perangkat lunak, yang paling banyak digunakan mungkin adalah SPIN
(Holzmann, 2003). Tahapan yang terlibat dalam pengecekan model ditunjukkan pada Gambar 15.1.
Proses pengecekan model melibatkan pembangunan model formal dari suatu sistem, biasanya
sebagai mesin keadaan terbatas yang diperluas. Model diekspresikan dalam bahasa sistem
pemeriksaan model apa pun yang digunakan—misalnya, pemeriksa model SPIN menggunakan
bahasa yang disebut Promela. Seperangkat properti sistem yang diinginkan diidentifikasi dan ditulis
dalam notasi formal, biasanya berdasarkan logika temporal. Contoh sifat seperti itu dalam sistem
cuaca hutan belantara adalah bahwa sistem akan selalu mencapai status 'transmisi' dari status
'merekam'.
Pemeriksa model kemudian mengeksplorasi semua jalur melalui model (yaitu, semua transisi
status yang mungkin), memeriksa apakah properti tersebut berlaku untuk setiap jalur. Jika ya, maka
pemeriksa model mengonfirmasi bahwa model tersebut benar sehubungan dengan properti itu. Jika
tidak berlaku untuk jalur tertentu, pemeriksa model mengeluarkan contoh tandingan yang
menggambarkan di mana properti tidak benar. Pengecekan model sangat berguna dalam
Diperpanjang
Model
Negara-Terbatas
Bangunan
Model Sistem
Persyaratan, Model
Desain, atau Pemeriksa
Program
Properti Sistem yang diinginkan
Spesifikasi Properti
Konfirmasi atau
Contoh Kontra
validasi sistem bersamaan, yang sangat sulit untuk diuji karena kepekaannya terhadap
Gambar 15.1
Pemeriksaan model
waktu. Pemeriksa dapat menjelajahi transisi yang disisipkan dan bersamaan dan
menemukan potensi masalah.
Masalah utama dalam pemeriksaan model adalah pembuatan model sistem. Jika model
harus dibuat secara manual (dari persyaratan atau dokumen desain), itu adalah proses
yang mahal karena pembuatan model membutuhkan banyak waktu. Selain itu, ada
kemungkinan model yang dibuat tidak akan menjadi model yang akurat dari persyaratan
atau desain. Oleh karena itu, sebaiknya model dapat dibuat secara otomatis dari kode
sumber program. Sistem Java Pathfinder (Visser et al., 2003) adalah contoh sistem
pengecekan model yang bekerja langsung dari representasi kode Java.
Pengecekan model secara komputasi sangat mahal karena menggunakan pendekatan
lengkap untuk memeriksa semua jalur melalui model sistem. Ketika ukuran sistem
meningkat, demikian juga jumlah status, dengan konsekuensi peningkatan jumlah jalur
yang akan diperiksa. Ini berarti bahwa, untuk sistem yang besar, pemeriksaan model
mungkin tidak praktis, karena waktu komputer yang diperlukan untuk menjalankan pemeriksaan.
Namun, karena algoritma untuk mengidentifikasi bagian-bagian dari keadaan yang
tidak dieksplorasi untuk memeriksa properti tertentu meningkat, akan menjadi semakin
praktis untuk menggunakan pemeriksaan model secara rutin dalam pengembangan sistem
kritis. Ini tidak benar-benar berlaku untuk sistem organisasi berorientasi data, tetapi dapat
digunakan untuk memverifikasi sistem perangkat lunak tertanam yang dimodelkan sebagai mesin negara.
15.1.3 Analisis statis otomatis

Seperti yang saya bahas di Bab 8, inspeksi program sering kali didorong oleh daftar
kesalahan dan heuristik. Ini mengidentifikasi kesalahan umum dalam bahasa pemrograman
yang berbeda. Untuk beberapa kesalahan dan heuristik, dimungkinkan untuk
mengotomatiskan proses pemeriksaan program terhadap daftar ini, yang telah
menghasilkan pengembangan penganalisis statis otomatis yang dapat menemukan fragmen kode yang mungkin sala
Alat analisis statis bekerja pada kode sumber sistem dan, setidaknya untuk beberapa
jenis analisis, tidak diperlukan input lebih lanjut. Ini berarti programmer tidak perlu
mempelajari notasi khusus untuk menulis spesifikasi program sehingga manfaat analisis
dapat segera jelas. Hal ini membuat analisis statis otomatis lebih mudah untuk dimasukkan
ke dalam proses pengembangan daripada verifikasi formal atau pemeriksaan model. Oleh
karena itu, mungkin teknik analisis statis yang paling banyak digunakan.
Kelas kesalahan Pemeriksaan analisis statis
Kesalahan data Variabel yang digunakan sebelum inisialisasi

Variabel dideklarasikan tetapi tidak pernah digunakan
Variabel ditugaskan dua kali tetapi tidak pernah digunakan di antara tugas
Kemungkinan pelanggaran terikat array
Variabel yang tidak dideklarasikan
Kontrol kesalahan Kode tidak dapat dijangkau
Cabang tanpa syarat menjadi loop
Kesalahan input/output Variabel menghasilkan dua kali tanpa penugasan intervensi
Kesalahan antarmuka Ketidakcocokan tipe parameter

Ketidakcocokan nomor parameter
Tidak menggunakan hasil fungsi

Fungsi dan prosedur yang tidak dipanggil
Kesalahan manajemen penyimpanan Pointer yang belum ditetapkan

Aritmatika penunjuk
Kebocoran memori
Penganalisis statis otomatis adalah alat perangkat lunak yang memindai teks sumber program
Gambar 15.2
Statis otomatis dan mendeteksi kemungkinan kesalahan dan anomali. Mereka mengurai teks program dan dengan demikian
pemeriksaan analisis mengenali berbagai jenis pernyataan dalam suatu program. Mereka kemudian dapat mendeteksi
apakah pernyataan terbentuk dengan baik atau tidak, buat kesimpulan tentang aliran kontrol di
program, dan, dalam banyak kasus, hitung himpunan semua nilai yang mungkin untuk program
data. Mereka melengkapi fasilitas deteksi kesalahan yang disediakan oleh penyusun bahasa, dan
dapat digunakan sebagai bagian dari proses inspeksi atau sebagai proses V & V yang terpisah
aktivitas. Analisis statis otomatis lebih cepat dan lebih murah daripada tinjauan kode terperinci.
Namun, tidak dapat menemukan beberapa kelas kesalahan yang dapat diidentifikasi dalam pertemuan
inspeksi program.
Maksud dari analisis statis otomatis adalah untuk menarik perhatian pembaca kode ke
anomali dalam program, seperti variabel yang digunakan tanpa inisialisasi, variabel yang tidak
digunakan, atau data yang nilainya bisa keluar dari jangkauan. Contoh dari
masalah yang dapat dideteksi dengan analisis statis ditunjukkan pada Gambar 15.2. Tentu saja,
pemeriksaan khusus yang dilakukan adalah khusus bahasa pemrograman dan bergantung pada apa yang
dan tidak diperbolehkan dalam bahasa tersebut. Anomali sering kali merupakan hasil dari pemrograman
kesalahan atau kelalaian, sehingga mereka menyoroti hal-hal yang bisa salah saat program
dieksekusi. Namun, Anda harus memahami bahwa anomali ini tidak selalu merupakan kesalahan
program; mereka mungkin merupakan konstruksi yang disengaja yang diperkenalkan oleh programmer,
atau anomali mungkin tidak memiliki konsekuensi yang merugikan.
Ada tiga tingkat pemeriksaan yang dapat diterapkan dalam penganalisis statis:
1. Pemeriksaan kesalahan karakteristik Pada tingkat ini, penganalisis statis mengetahui tentang
kesalahan umum yang dibuat oleh programmer dalam bahasa seperti Java atau C.
Alat ini menganalisis kode untuk mencari pola yang menjadi ciri khasnya
masalah dan menyoroti ini untuk programmer. Meskipun relatif sederhana, analisis berdasarkan
kesalahan umum bisa sangat hemat biaya. Zheng dan rekan-rekannya (2006) mempelajari
penggunaan analisis statis terhadap basis kode besar di C dan C++ dan menemukan bahwa
90% dari kesalahan dalam program dihasilkan dari 10 jenis kesalahan karakteristik.
2. Pemeriksaan kesalahan yang ditentukan pengguna Dalam pendekatan ini, pengguna penganalisis
statis dapat menentukan pola kesalahan, sehingga memperluas jenis kesalahan yang dapat dideteksi.
Ini sangat berguna dalam situasi di mana pemesanan harus dipertahankan (misalnya, metode
A harus selalu dipanggil sebelum metode B). Seiring waktu, organisasi dapat mengumpulkan
informasi tentang bug umum yang terjadi dalam program mereka dan memperluas alat analisis
statis untuk menyoroti kesalahan ini.
3. Pemeriksaan asersi Ini adalah pendekatan yang paling umum dan paling kuat untuk analisis
statis. Pengembang menyertakan pernyataan formal (sering ditulis sebagai komentar bergaya)
dalam program mereka yang menyatakan hubungan yang harus dipegang pada saat itu dalam
suatu program. Misalnya, pernyataan mungkin disertakan yang menyatakan bahwa nilai
beberapa variabel harus berada dalam rentang x..y. Penganalisis secara simbolis mengeksekusi
kode dan menyoroti pernyataan di mana pernyataan tersebut mungkin tidak berlaku.
Pendekatan ini digunakan dalam penganalisis seperti Splint (Evans dan Larochelle, 2002) dan
SPARK Examiner (Croxford dan Sutton, 2006).
Analisis statis efektif dalam menemukan kesalahan dalam program tetapi biasanya menghasilkan
sejumlah besar 'positif palsu'. Ini adalah bagian kode di mana tidak ada kesalahan tetapi di mana
aturan penganalisis statis telah mendeteksi potensi kesalahan. Jumlah positif palsu dapat dikurangi
dengan menambahkan lebih banyak informasi ke program dalam bentuk pernyataan tetapi, jelas,
ini membutuhkan pekerjaan tambahan oleh pengembang kode. Pekerjaan harus dilakukan dalam
menyaring positif palsu ini sebelum kode itu sendiri dapat diperiksa untuk kesalahan.
Analisis statis sangat berharga untuk pemeriksaan keamanan (Evans dan Larochelle, 2002).
Penganalisis statis dapat disesuaikan untuk memeriksa masalah yang terkenal, seperti buffer
overflow atau input yang tidak diperiksa, yang dapat dimanfaatkan oleh penyerang. Memeriksa
masalah yang terkenal efektif untuk meningkatkan keamanan karena sebagian besar penyerang
mendasarkan serangan mereka pada kerentanan umum.
Seperti yang akan saya bahas nanti, pengujian keamanan sulit dilakukan karena penyerang
sering melakukan hal-hal tak terduga yang sulit diantisipasi oleh penguji. Penganalisis statis dapat
menggabungkan keahlian keamanan terperinci yang mungkin tidak dimiliki penguji dan dapat
diterapkan sebelum suatu program diuji. Jika Anda menggunakan analisis statis, Anda dapat
membuat klaim yang benar untuk semua kemungkinan eksekusi program, bukan hanya yang sesuai dengan pengujian yang telah
Analisis statis sekarang secara rutin digunakan oleh banyak organisasi dalam proses
pengembangan perangkat lunak mereka. Microsoft memperkenalkan analisis statis dalam
pengembangan driver perangkat (Larus, et al., 2003) di mana kegagalan program dapat berdampak
serius. Mereka sekarang telah memperluas pendekatan di perangkat lunak mereka yang jauh lebih
luas untuk mencari masalah keamanan serta kesalahan yang mempengaruhi keandalan program
(Ball, et al., 2006). Banyak sistem kritis, termasuk sistem avionik dan nuklir, secara rutin dianalisis
secara statis sebagai bagian dari proses V & V (Nguyen dan Ourghanlian, 2003).
15.2 Pengujian keandalan 401
Mengenali Menghitung
Siapkan Tes Terapkan Diamati
Operasional Himpunan data
Gambar 15.3 Keandalan Profil Tes ke Sistem
Keandalan
pengukuran
15.2 Pengujian keandalan
Pengujian reliabilitas adalah proses pengujian yang bertujuan untuk mengukur keandalan suatu
sistem. Seperti yang saya jelaskan di Bab 10, ada beberapa metrik keandalan seperti POFOD,
probabilitas kegagalan sesuai permintaan dan ROCOF, tingkat terjadinya kegagalan. Ini dapat
digunakan untuk secara kuantitatif menentukan keandalan perangkat lunak yang diperlukan. Anda
dapat memeriksa dalam proses pengujian keandalan jika sistem telah mencapai tingkat keandalan yang diperlukan.
Proses pengukuran keandalan suatu sistem diilustrasikan pada Gambar 15.3.
Proses ini melibatkan empat tahap:
1. Anda mulai dengan mempelajari sistem yang ada dengan tipe yang sama untuk memahami
bagaimana ini digunakan dalam praktik. Ini penting karena Anda mencoba mengukur
keandalan seperti yang terlihat oleh pengguna sistem. Tujuan Anda adalah untuk menentukan
profil operasional. Profil operasional mengidentifikasi kelas input sistem dan kemungkinan
input ini akan terjadi dalam penggunaan normal.
2. Anda kemudian membangun satu set data uji yang mencerminkan profil operasional. Ini berarti
Anda membuat data uji dengan distribusi probabilitas yang sama dengan data uji untuk
sistem yang telah Anda pelajari. Biasanya, Anda akan menggunakan generator data uji untuk
mendukung proses ini.
3. Anda menguji sistem menggunakan data ini dan menghitung jumlah dan jenis kegagalan yang
terjadi. Waktu kegagalan ini juga dicatat. Seperti yang saya bahas di Bab 10, satuan waktu
yang dipilih harus sesuai dengan metrik keandalan yang digunakan.
4. Setelah Anda mengamati sejumlah kegagalan yang signifikan secara statistik, Anda dapat
menghitung keandalan perangkat lunak dan menentukan nilai metrik keandalan yang sesuai.
Pendekatan empat langkah ini kadang-kadang disebut 'pengujian statistik'. Tujuan dari
pengujian statistik adalah untuk menilai keandalan sistem. Ini kontras dengan pengujian cacat,
dibahas dalam Bab 8, di mana tujuannya adalah untuk menemukan kesalahan sistem. Prowell dkk.
(1999) memberikan deskripsi yang baik tentang pengujian statistik dalam buku mereka tentang rekayasa perangkat lunak Cle
Pendekatan konseptual yang menarik untuk pengukuran reliabilitas ini tidak mudah diterapkan
dalam praktik. Kesulitan utama yang muncul adalah:
1. Ketidakpastian profil operasional Profil operasional berdasarkan pengalaman dengan sistem

lain mungkin bukan cerminan akurat dari penggunaan sistem yang sebenarnya.
2. Biaya pembuatan data uji yang tinggi Akan sangat mahal untuk menghasilkan volume data yang
besar yang diperlukan dalam profil operasional kecuali jika prosesnya dapat diotomatisasi
secara total.
3. Ketidakpastian statistik ketika keandalan tinggi ditentukan Anda harus menghasilkan a

jumlah kegagalan yang signifikan secara statistik untuk memungkinkan pengukuran keandalan
yang akurat. Ketika perangkat lunak sudah dapat diandalkan, kegagalan yang terjadi relatif sedikit dan itu
sulit untuk menghasilkan kegagalan baru.
4. Mengenali kegagalan Tidak selalu jelas apakah kegagalan sistem memiliki

muncul. Jika Anda memiliki spesifikasi formal, Anda mungkin dapat mengidentifikasi penyimpangan
dari spesifikasi itu tetapi, jika spesifikasinya dalam bahasa alami, mungkin ada
ambiguitas yang berarti pengamat bisa tidak setuju pada apakah sistem telah gagal.
Sejauh ini cara terbaik untuk menghasilkan kumpulan data besar yang diperlukan untuk pengukuran
keandalan adalah dengan menggunakan generator data uji, yang dapat diatur untuk menghasilkan
masukan yang cocok dengan profil operasional. Namun, biasanya tidak mungkin untuk mengotomatisasi
produksi semua data uji untuk sistem interaktif karena inputnya sering kali
respon terhadap keluaran sistem. Kumpulan data untuk sistem ini harus dibuat secara manual,
dengan biaya yang lebih tinggi. Bahkan di mana otomatisasi lengkap dimungkinkan, menulis perintah
untuk generator data pengujian mungkin memakan banyak waktu.
Pengujian statistik dapat digunakan bersama dengan injeksi kesalahan untuk mengumpulkan data
tentang seberapa efektif proses pengujian cacat telah. Injeksi kesalahan (Voas,
1997) adalah penyuntikan kesalahan yang disengaja ke dalam program. Ketika program dieksekusi, ini
menyebabkan kesalahan program dan kegagalan terkait. Anda kemudian menganalisis kegagalan untuk
mengetahui apakah akar penyebabnya adalah salah satu kesalahan yang telah Anda tambahkan ke program.
Jika Anda menemukan bahwa X% dari kesalahan yang disuntikkan menyebabkan kegagalan, maka para pendukung kesalahan
injeksi berpendapat bahwa ini menunjukkan bahwa proses pengujian cacat juga akan menemukan X%
dari kesalahan yang sebenarnya dalam program.
Ini, tentu saja, mengasumsikan bahwa distribusi dan jenis kesalahan yang disuntikkan cocok
kesalahan aktual yang muncul dalam praktik. Masuk akal untuk berpikir bahwa ini mungkin benar
untuk kesalahan karena kesalahan pemrograman, tetapi injeksi kesalahan tidak efektif dalam memprediksi
jumlah kesalahan yang berasal dari persyaratan atau kesalahan desain.
Pengujian statistik sering mengungkapkan kesalahan dalam perangkat lunak yang belum ditemukan
oleh proses V & V lainnya. Kesalahan ini dapat berarti bahwa keandalan sistem
tidak memenuhi persyaratan dan harus dilakukan perbaikan. Setelah perbaikan ini selesai, sistem dapat
diuji ulang untuk menilai kembali keandalannya. Setelah perbaikan dan pengujian ulang ini
proses telah diulang beberapa kali, dimungkinkan untuk mengekstrapolasi hasilnya
dan memprediksi kapan beberapa tingkat keandalan yang diperlukan akan tercapai. Ini membutuhkan
menyesuaikan data yang diekstrapolasi ke model pertumbuhan keandalan, yang menunjukkan bagaimana
keandalan cenderung meningkat dari waktu ke waktu. Ini membantu dengan perencanaan pengujian. Terkadang,
model pertumbuhan dapat mengungkapkan bahwa tingkat keandalan yang diperlukan tidak akan pernah tercapai,
sehingga persyaratan harus dinegosiasikan ulang.
15.2.1 Profil operasional

Profil operasional sistem perangkat lunak mencerminkan bagaimana hal itu akan digunakan dalam praktek.
Ini terdiri dari spesifikasi kelas input dan probabilitas kemunculannya. Ketika sistem perangkat lunak
baru menggantikan sistem otomatis yang ada, itu adalah:
15.2 Pengujian keandalan 403
Pemodelan pertumbuhan keandalan
Model pertumbuhan keandalan adalah model bagaimana keandalan sistem berubah dari waktu ke waktu selama proses pengujian.
Ketika kegagalan sistem ditemukan, kesalahan mendasar yang menyebabkan kegagalan ini diperbaiki sehingga keandalan
sistem harus meningkat selama pengujian dan debugging sistem. Untuk memprediksi reliabilitas, model pertumbuhan reliabilitas
konseptual kemudian harus diterjemahkan ke dalam model matematis.
http://www.SoftwareEngineering-9.com/Web/DepSecAssur/RGM.html
cukup mudah untuk menilai kemungkinan pola penggunaan perangkat lunak baru. Itu harus sesuai
dengan penggunaan yang ada, dengan beberapa kelonggaran yang dibuat untuk fungsionalitas
baru yang (mungkin) termasuk dalam perangkat lunak baru. Misalnya, profil operasional dapat
ditentukan untuk sistem switching telepon karena perusahaan telekomunikasi mengetahui pola
panggilan yang harus ditangani oleh sistem ini.
Biasanya, profil operasional sedemikian rupa sehingga input yang memiliki probabilitas
tertinggi untuk dihasilkan jatuh ke dalam sejumlah kecil kelas, seperti yang ditunjukkan di sebelah
kiri Gambar 15.4. Ada sejumlah besar kelas di mana input sangat tidak mungkin tetapi bukan tidak
mungkin. Ini ditunjukkan di sebelah kanan Gambar 15.4. Elipsis (. . .) berarti bahwa ada lebih banyak
input yang tidak biasa ini daripada yang ditampilkan.
Musa (1998) membahas perkembangan profil operasional dalam sistem telekomunikasi. Karena
ada sejarah panjang pengumpulan data penggunaan di domain tersebut, proses pengembangan
profil operasional relatif mudah. Ini hanya mencerminkan data penggunaan historis. Untuk sistem
yang membutuhkan upaya pengembangan sekitar 15 orang-tahun, profil operasional dikembangkan
dalam waktu sekitar 1 orang-bulan. Dalam kasus lain, pembuatan profil operasional membutuhkan
waktu lebih lama (2–3 orang-tahun) tetapi biayanya tersebar di sejumlah rilis sistem. Musa
memperhitungkan bahwa perusahaannya memiliki setidaknya 10 kali lipat pengembalian investasi
yang diperlukan untuk mengembangkan profil operasional.
Namun, ketika sistem perangkat lunak baru dan inovatif, sulit untuk mengantisipasi bagaimana
hal itu akan digunakan. Akibatnya, hampir tidak mungkin untuk membuat profil operasional yang
akurat. Banyak pengguna yang berbeda dengan harapan, latar belakang, dan pengalaman yang
berbeda dapat menggunakan sistem baru. Tidak ada basis data penggunaan historis. Pengguna ini
dapat menggunakan sistem dengan cara yang tidak diantisipasi oleh pengembang sistem.
Mengembangkan profil operasional yang akurat tentu dimungkinkan untuk beberapa jenis
sistem, seperti sistem telekomunikasi, yang memiliki pola penggunaan yang terstandarisasi.
Namun, untuk tipe sistem lain, ada banyak pengguna berbeda yang masing-masing memiliki cara
sendiri dalam menggunakan sistem. Seperti yang saya bahas di Bab 10, pengguna yang berbeda
bisa mendapatkan kesan keandalan yang sangat berbeda karena mereka menggunakan sistem dengan cara yang berbeda.
Masalahnya semakin rumit karena profil operasional tidak statis tetapi berubah saat sistem
digunakan. Saat pengguna belajar tentang sistem baru dan menjadi lebih percaya diri dengannya,
mereka mulai menggunakannya dengan cara yang lebih canggih. Karena itu, seringkali tidak
mungkin untuk mengembangkan profil operasional yang dapat dipercaya. Akibatnya, Anda tidak
dapat yakin tentang keakuratan pengukuran keandalan apa pun, karena pengukuran tersebut
mungkin didasarkan pada asumsi yang salah tentang cara sistem digunakan.
Gambar 15.4 ...

Profil operasional Kelas Masukan
15.3 Pengujian keamanan
Penilaian keamanan sistem semakin penting karena semakin banyak sistem kritis yang
mendukung Internet sehingga dapat diakses oleh siapa saja yang memiliki koneksi jaringan.
Ada cerita harian tentang serangan pada sistem berbasis web, dan virus dan worm
didistribusikan secara teratur menggunakan protokol Internet.
Semua ini berarti bahwa proses verifikasi dan validasi untuk sistem berbasis web harus
fokus pada penilaian keamanan, di mana kemampuan sistem untuk menahan berbagai
jenis serangan diuji. Namun, seperti yang dijelaskan Anderson (2001), jenis penilaian
keamanan ini sangat sulit dilakukan. Akibatnya, sistem sering digunakan dengan celah
keamanan. Penyerang menggunakan ini untuk mendapatkan akses ke sistem atau
menyebabkan kerusakan pada sistem atau datanya.
Pada dasarnya, ada dua alasan mengapa pengujian keamanan sangat sulit:
1. Persyaratan keamanan, seperti beberapa persyaratan keselamatan, 'tidak boleh'

diperlukan. Artinya, mereka menentukan apa yang seharusnya tidak terjadi daripada
fungsi sistem atau perilaku yang diperlukan. Biasanya tidak mungkin untuk
mendefinisikan perilaku yang tidak diinginkan ini sebagai batasan sederhana untuk diperiksa oleh sistem.
Jika sumber daya tersedia, Anda dapat menunjukkan, setidaknya pada prinsipnya,
bahwa suatu sistem memenuhi persyaratan fungsionalnya. Namun, tidak mungkin
untuk membuktikan bahwa suatu sistem tidak melakukan sesuatu. Terlepas dari
jumlah pengujian, kerentanan keamanan mungkin tetap ada dalam sistem setelah
diterapkan. Anda dapat, tentu saja, menghasilkan persyaratan fungsional yang
dirancang untuk menjaga sistem dari beberapa jenis serangan yang diketahui. Namun,
Anda tidak dapat memperoleh persyaratan untuk jenis serangan yang tidak diketahui
atau tidak terduga. Bahkan dalam sistem yang telah digunakan selama bertahun-tahun,
penyerang yang cerdik dapat menemukan bentuk serangan baru dan dapat menembus apa yang dianggap sebaga
15.3 Pengujian keamanan 405
2. Orang-orang yang menyerang sistem cerdas dan secara aktif mencari kerentanan yang dapat
mereka eksploitasi. Mereka bersedia bereksperimen dengan sistem dan mencoba hal-hal yang
jauh di luar aktivitas normal dan penggunaan sistem. Misalnya, di bidang nama keluarga mereka
dapat memasukkan 1.000 karakter dengan campuran huruf, tanda baca, dan angka. Selanjutnya,
begitu mereka menemukan kerentanan, mereka dapat bertukar informasi tentang hal ini dan
dengan demikian meningkatkan jumlah penyerang potensial.
Penyerang mungkin mencoba untuk menemukan asumsi yang dibuat oleh pengembang sistem
dan kemudian bertentangan dengan asumsi ini untuk melihat apa yang terjadi. Mereka berada dalam
posisi untuk menggunakan dan menjelajahi sistem selama periode waktu tertentu dan menganalisisnya
menggunakan perangkat lunak untuk menemukan kerentanan yang mungkin dapat mereka eksploitasi.
Mereka mungkin, pada kenyataannya, memiliki lebih banyak waktu untuk mencari kerentanan daripada
insinyur pengujian sistem, karena penguji juga harus fokus pada pengujian sistem.
Untuk alasan ini, analisis statis dapat sangat berguna sebagai alat pengujian keamanan.
Analisis statis suatu program dapat dengan cepat memandu tim pengujian ke area program yang
mungkin mencakup kesalahan dan kerentanan. Anomali yang terungkap dalam analisis statis dapat
langsung diperbaiki atau dapat membantu mengidentifikasi tes yang perlu dilakukan untuk
mengungkapkan apakah anomali ini benar-benar mewakili risiko bagi sistem atau tidak.
Untuk memeriksa keamanan suatu sistem, Anda dapat menggunakan kombinasi pengujian, alat
analisis berbasis, dan verifikasi formal:
1. Pengujian berbasis pengalaman Dalam hal ini, sistem dianalisis terhadap jenis serangan yang
diketahui oleh tim validasi. Ini mungkin melibatkan pengembangan kasus uji atau pemeriksaan
kode sumber suatu sistem. Misalnya, untuk memeriksa bahwa sistem tidak rentan terhadap
serangan keracunan SQL yang terkenal, Anda dapat menguji sistem menggunakan input yang
menyertakan perintah SQL. Untuk memeriksa bahwa kesalahan buffer overflow tidak akan terjadi,
Anda dapat memeriksa semua buffer input untuk melihat apakah program memeriksa bahwa
penugasan ke elemen buffer berada dalam batas.
Jenis validasi ini biasanya dilakukan bersama dengan validasi berbasis alat, di mana alat
tersebut memberi Anda informasi yang membantu memfokuskan pengujian sistem.
Daftar periksa masalah keamanan yang diketahui dapat dibuat untuk membantu proses tersebut.
Gambar 15.5 memberikan beberapa contoh pertanyaan yang mungkin digunakan untuk
mendorong pengujian berbasis pengalaman. Pemeriksaan apakah pedoman desain dan
pemrograman untuk keamanan (Bab 14) telah diikuti mungkin juga disertakan dalam daftar
periksa masalah keamanan.
2. Tim harimau Ini adalah bentuk pengujian berbasis pengalaman di mana dimungkinkan untuk
memanfaatkan pengalaman dari luar tim pengembangan untuk menguji sistem aplikasi.
Anda membentuk 'tim harimau' yang diberi tujuan untuk melanggar keamanan sistem. Mereka
mensimulasikan serangan pada sistem dan menggunakan kecerdikan mereka untuk menemukan
cara baru untuk membahayakan keamanan sistem. Anggota tim Tiger harus memiliki pengalaman
sebelumnya dengan pengujian keamanan dan menemukan kelemahan keamanan dalam sistem.
3. Pengujian berbasis alat Untuk metode ini, berbagai alat keamanan seperti pemeriksa kata sandi
digunakan untuk menganalisis sistem. Pemeriksa kata sandi mendeteksi kata sandi yang tidak
aman seperti nama umum atau rangkaian huruf berurutan. Ini
Daftar periksa keamanan
1. Apakah semua file yang dibuat dalam aplikasi memiliki izin akses yang sesuai? Izin akses yang salah dapat
menyebabkan file-file ini diakses oleh pengguna yang tidak sah.
2. Apakah sistem secara otomatis menghentikan sesi pengguna setelah periode tidak aktif? Sesi yang tersisa
aktif dapat memungkinkan akses yang tidak sah melalui komputer tanpa pengawasan.
3. Jika sistem ditulis dalam bahasa pemrograman tanpa pemeriksaan terikat array, apakah ada situasi?
di mana buffer overflow dapat dieksploitasi? Buffer overflow memungkinkan penyerang mengirim string kode ke
sistem dan kemudian mengeksekusinya.
4. Jika kata sandi ditetapkan, apakah sistem memeriksa apakah kata sandi 'kuat'? Kata sandi yang kuat terdiri dari campuran
huruf, angka, dan tanda baca, dan bukan entri kamus biasa. Mereka lebih sulit untuk dipecahkan daripada kata sandi
sederhana.
5. Apakah input dari lingkungan sistem selalu diperiksa terhadap spesifikasi input? Pemrosesan input yang salah
bentuk adalah penyebab umum kerentanan keamanan.
Pendekatan benar-benar merupakan perpanjangan dari validasi berbasis pengalaman, di mana

Gambar 15.5 Contoh
entri dalam daftar periksa pengalaman kelemahan keamanan diwujudkan dalam alat yang digunakan. Analisis statis, tentu
keamanan saja, adalah jenis lain dari pengujian berbasis alat.
4. Verifikasi formal Sebuah sistem dapat diverifikasi terhadap spesifikasi keamanan formal. Namun,
seperti di daerah lain, verifikasi formal untuk keamanan tidak banyak digunakan.
Pengujian keamanan, mau tidak mau, dibatasi oleh waktu dan sumber daya yang tersedia untuk tim
pengujian. Ini berarti bahwa Anda biasanya harus mengadopsi pendekatan berbasis risiko untuk
pengujian keamanan dan fokus pada apa yang menurut Anda merupakan risiko paling signifikan yang
dihadapi oleh sistem. Jika Anda memiliki analisis risiko keamanan terhadap sistem, ini dapat digunakan
untuk mendorong proses pengujian. Selain menguji sistem terhadap persyaratan keamanan yang
berasal dari risiko ini, tim uji juga harus mencoba memecahkan sistem dengan mengadopsi pendekatan
alternatif yang mengancam aset sistem.
Sangat sulit bagi pengguna akhir suatu sistem untuk memverifikasi keamanannya. Akibatnya,
badan pemerintah di Amerika Utara dan Eropa telah menetapkan serangkaian kriteria evaluasi keamanan
yang dapat diperiksa oleh evaluator khusus (Pfleeger dan Pfleeger, 2007). Pemasok produk perangkat
lunak dapat mengirimkan produk mereka untuk evaluasi dan sertifikasi terhadap kriteria ini. Oleh
karena itu, jika Anda memiliki persyaratan untuk tingkat keamanan tertentu, Anda dapat memilih produk
yang telah divalidasi ke tingkat tersebut. Namun, dalam praktiknya, kriteria ini terutama digunakan
dalam sistem militer dan sampai sekarang belum banyak diterima secara komersial.
15.4 Jaminan proses
Seperti yang saya bahas di Bab 13, pengalaman telah menunjukkan bahwa proses yang dapat
diandalkan mengarah pada sistem yang dapat diandalkan. Artinya, jika suatu proses didasarkan pada
praktik rekayasa perangkat lunak yang baik, maka kemungkinan besar produk perangkat lunak yang dihasilkan akan dapat diandalkan
15.4 Jaminan proses 407
Regulasi perangkat lunak
Regulator dibuat oleh pemerintah untuk memastikan bahwa industri swasta tidak mendapat untung
dengan gagal mengikuti standar nasional untuk keselamatan, keamanan, dan sebagainya. Ada regulator
di berbagai industri seperti tenaga nuklir, penerbangan, dan perbankan. Karena sistem perangkat lunak
menjadi semakin penting dalam infrastruktur kritis negara, regulator ini menjadi semakin peduli dengan
kasus keamanan dan ketergantungan untuk sistem perangkat lunak.
http://www.SoftwareEngineering-9.com/Web/DepSecAssur/Regulation.html
Tentu saja, proses yang baik tidak menjamin ketergantungan. Namun, bukti bahwa proses
yang dapat diandalkan telah digunakan meningkatkan kepercayaan keseluruhan bahwa suatu
sistem dapat diandalkan. Jaminan proses berkaitan dengan pengumpulan informasi tentang
proses yang digunakan selama pengembangan sistem, dan hasil dari proses ini.
Informasi ini memberikan bukti analisis, ulasan, dan pengujian yang telah dilakukan selama
pengembangan perangkat lunak.
Jaminan proses berkaitan dengan dua hal:
1. Apakah kita memiliki proses yang benar? Apakah proses pengembangan sistem yang
digunakan dalam organisasi mencakup kontrol yang sesuai dan subproses V&V untuk
jenis sistem yang dikembangkan?
2. Apakah proses yang kita lakukan sudah benar? Apakah organisasi telah melakukan
pekerjaan pengembangan seperti yang didefinisikan dalam deskripsi proses perangkat
lunaknya dan apakah hasil yang ditentukan dari proses perangkat lunak telah dihasilkan?
Perusahaan yang memiliki pengalaman luas dalam rekayasa sistem kritis telah
mengembangkan proses mereka untuk mencerminkan praktik verifikasi dan validasi yang baik.
Dalam beberapa kasus, ini melibatkan diskusi dengan regulator eksternal untuk menyepakati
proses apa yang harus digunakan. Meskipun ada banyak variasi proses di antara perusahaan,
aktivitas yang Anda harapkan untuk dilihat dalam proses pengembangan sistem kritis meliputi
manajemen persyaratan, manajemen perubahan dan kontrol konfigurasi, pemodelan sistem,
tinjauan dan inspeksi, perencanaan pengujian, dan analisis cakupan pengujian. Gagasan
perbaikan proses, di mana praktik yang baik diperkenalkan dan dilembagakan dalam proses,
dibahas dalam Bab 26.
Aspek lain dari jaminan proses adalah memeriksa bahwa proses telah dilakukan dengan
benar. Ini biasanya melibatkan memastikan bahwa proses didokumentasikan dengan benar
dan memeriksa dokumentasi proses ini. Misalnya, bagian dari proses yang dapat diandalkan
mungkin melibatkan inspeksi program formal. Dokumentasi untuk setiap inspeksi harus
mencakup daftar periksa yang digunakan untuk mendorong inspeksi, daftar orang yang terlibat,
masalah yang diidentifikasi selama inspeksi, dan tindakan yang diperlukan.
Mendemonstrasikan bahwa proses yang dapat diandalkan telah digunakan oleh karena itu
melibatkan pembuatan banyak bukti dokumenter tentang proses dan perangkat lunak yang
sedang dikembangkan. Kebutuhan akan dokumentasi ekstensif ini berarti bahwa proses yang gesit adalah
Lisensi insinyur perangkat lunak
Di beberapa bidang teknik, insinyur keselamatan harus insinyur berlisensi. Insinyur yang tidak berpengalaman dan
berkualifikasi buruk tidak diizinkan untuk bertanggung jawab atas keselamatan. Ini saat ini tidak berlaku untuk insinyur
perangkat lunak, meskipun telah ada diskusi ekstensif tentang lisensi insinyur perangkat lunak di beberapa negara
bagian di Amerika Serikat (Knight dan Leveson, 2002). Namun, standar proses masa depan untuk pengembangan
perangkat lunak yang kritis terhadap keselamatan mungkin mengharuskan insinyur keselamatan proyek harus menjadi
insinyur berlisensi, dengan tingkat kualifikasi dan pengalaman minimum yang ditentukan.
http://www.SoftwareEngineering-9.com/Web/DepSecAssur/Licensing.html
jarang digunakan dalam sistem di mana sertifikasi keselamatan atau keandalan diperlukan.
Proses tangkas fokus pada perangkat lunak itu sendiri dan (benar) berpendapat bahwa banyak
dokumentasi proses tidak pernah benar-benar digunakan setelah diproduksi. Namun, Anda
harus membuat bukti dan mendokumentasikan aktivitas proses saat informasi proses
digunakan sebagai bagian dari kasus keamanan atau ketergantungan sistem.
15.4.1 Proses untuk jaminan keamanan

Sebagian besar pekerjaan pada jaminan proses telah dilakukan di bidang pengembangan
sistem yang kritis terhadap keselamatan. Penting bahwa proses pengembangan sistem yang
kritis terhadap keselamatan mencakup proses V & V yang diarahkan untuk analisis keselamatan dan jaminan untuk dua
alasan:
1. Kecelakaan adalah kejadian langka dalam sistem kritis dan secara praktis tidak mungkin
untuk mensimulasikannya selama pengujian suatu sistem. Anda tidak dapat mengandalkan
pengujian ekstensif untuk meniru kondisi yang dapat menyebabkan kecelakaan.
2. Persyaratan keselamatan, seperti yang saya bahas di Bab 12, terkadang merupakan
persyaratan 'tidak boleh' yang mengecualikan perilaku sistem yang tidak aman. Tidak
mungkin untuk menunjukkan secara meyakinkan melalui pengujian dan kegiatan validasi
lainnya bahwa persyaratan ini telah dipenuhi.
Kegiatan jaminan keamanan khusus harus dimasukkan pada semua tahap dalam proses
pengembangan perangkat lunak. Kegiatan jaminan keselamatan ini merekam analisis yang
telah dilakukan dan orang atau orang yang bertanggung jawab atas analisis tersebut. Aktivitas
jaminan keamanan yang digabungkan ke dalam proses perangkat lunak dapat mencakup hal-hal berikut:
1. Pencatatan dan pemantauan bahaya, yang melacak bahaya dari analisis bahaya awal hingga
pengujian dan validasi sistem.
2. Tinjauan keamanan, yang digunakan selama proses pengembangan.
3. Sertifikasi keselamatan, di mana keamanan komponen kritis disertifikasi secara resmi. Ini
melibatkan grup di luar tim pengembangan sistem
15.4 Jaminan proses 409
memeriksa bukti yang tersedia dan memutuskan apakah suatu sistem atau komponen harus
dianggap aman sebelum tersedia untuk digunakan.
Untuk mendukung proses jaminan keselamatan ini, insinyur keselamatan proyek harus ditunjuk
yang memiliki tanggung jawab eksplisit untuk aspek keselamatan suatu sistem. Ini berarti bahwa
orang-orang ini akan bertanggung jawab jika terjadi kegagalan sistem terkait keselamatan. Mereka
harus dapat menunjukkan bahwa kegiatan jaminan keselamatan telah dilakukan dengan benar.
Insinyur keselamatan bekerja dengan manajer kualitas untuk memastikan bahwa sistem
manajemen konfigurasi terperinci digunakan untuk melacak semua dokumentasi terkait keselamatan
dan menjaganya tetap sejalan dengan dokumentasi teknis terkait. Ini penting dalam semua proses
yang dapat diandalkan. Tidak ada gunanya memiliki prosedur validasi yang ketat jika kegagalan
manajemen konfigurasi berarti bahwa sistem yang salah dikirimkan ke pelanggan. Konfigurasi dan
manajemen kualitas tercakup dalam Bab 24 dan 25.
Proses analisis bahaya yang merupakan bagian penting dari pengembangan sistem kritis
keselamatan adalah contoh dari proses jaminan keselamatan. Analisis bahaya berkaitan dengan
mengidentifikasi bahaya, probabilitas terjadinya, dan probabilitas setiap bahaya yang menyebabkan
kecelakaan. Jika ada kode program yang memeriksa dan menangani setiap bahaya, maka Anda
dapat berargumen bahwa bahaya tersebut tidak akan mengakibatkan kecelakaan. Argumen tersebut
dapat dilengkapi dengan argumen keamanan, seperti yang dibahas nanti dalam bab ini. Dimana
sertifikasi eksternal diperlukan sebelum sistem digunakan (misalnya, di pesawat terbang), biasanya
kondisi sertifikasi bahwa ketertelusuran ini dapat ditunjukkan.
Dokumen keselamatan utama yang harus dibuat adalah hazard log. Dokumen ini memberikan
bukti tentang bagaimana bahaya yang teridentifikasi telah diperhitungkan selama pengembangan
perangkat lunak. Log bahaya ini digunakan pada setiap tahap proses pengembangan perangkat
lunak untuk mendokumentasikan bagaimana tahap pengembangan tersebut telah memperhitungkan
bahaya. Contoh sederhana dari entri log bahaya untuk sistem pengiriman insulin ditunjukkan pada
Gambar 15.6. Formulir ini mendokumentasikan proses analisis bahaya dan menunjukkan persyaratan
desain yang telah dihasilkan selama proses ini. Persyaratan desain ini dimaksudkan untuk
memastikan bahwa sistem kontrol tidak pernah dapat memberikan overdosis insulin kepada
pengguna pompa insulin.
Seperti yang ditunjukkan pada Gambar 15.6, individu yang memiliki tanggung jawab keselamatan harus
diidentifikasi secara eksplisit. Ini penting karena dua alasan:
1. Ketika orang diidentifikasi, mereka dapat dimintai pertanggungjawaban atas tindakan mereka. Ini
berarti bahwa mereka cenderung lebih berhati-hati karena masalah apa pun dapat ditelusuri
kembali ke pekerjaan mereka.
2. Jika terjadi kecelakaan, mungkin ada proses hukum atau penyelidikan. Penting untuk dapat
mengidentifikasi siapa yang bertanggung jawab atas jaminan keamanan sehingga mereka
dapat mempertanggungjawabkan tindakan mereka.
Log Bahaya Halaman 4: Dicetak 20.02.2009
Sistem: Sistem Pompa Insulin File: InsulinPump/Safety/HazardLog

Insinyur Keselamatan: James Brown Versi log: 1/3
Bahaya yang Diidentifikasi Overdosis insulin dikirim ke pasien
Diidentifikasi oleh Jane Williams
Kelas kritis 1
Risiko yang teridentifikasi Tinggi
Pohon kesalahan diidentifikasi YA Tanggal 24.01.07 Lokasi Log Bahaya, Halaman 5
Pembuat pohon kesalahan Jane Williams dan Bill Smith
Pohon kesalahan diperiksa YA Tanggal 28.01.07 Pemeriksa James Brown
Persyaratan desain keamanan sistem
1. Sistem harus menyertakan perangkat lunak pengujian mandiri yang akan menguji sistem sensor, jam, dan insulin
sistem pengantaran.
2. Perangkat lunak pemeriksaan mandiri harus dijalankan sekali per menit.
3. Jika perangkat lunak yang memeriksa sendiri menemukan kesalahan pada salah satu komponen sistem, suara
peringatan harus dikeluarkan dan tampilan pompa harus menunjukkan nama komponen yang mengalami kesalahan
telah ditemukan. Pengiriman insulin harus dihentikan.
4. Sistem harus menggabungkan sistem override yang memungkinkan pengguna sistem untuk memodifikasi dosis yang dihitung dari
insulin yang akan dikirim oleh sistem.
5. Jumlah override tidak boleh lebih besar dari nilai yang telah ditentukan sebelumnya (maxOverride), yang ditetapkan saat
sistem dikonfigurasi oleh staf medis.
Gambar 15.6 Entri log

bahaya yang disederhanakan
15.5 Kasus keamanan dan ketergantungan
Proses jaminan keamanan dan ketergantungan menghasilkan banyak informasi. Ini

dapat mencakup hasil pengujian, informasi tentang proses pengembangan yang digunakan, catatan
pertemuan tinjauan, dll. Informasi ini memberikan bukti tentang keamanan dan
ketergantungan suatu sistem, dan digunakan untuk membantu memutuskan apakah sistem
cukup dapat diandalkan untuk penggunaan operasional.
Kasus keamanan dan ketergantungan adalah dokumen terstruktur yang menguraikan secara rinci
argumen dan bukti bahwa suatu sistem aman atau bahwa tingkat keamanan yang diperlukan atau
ketergantungan telah tercapai. Mereka kadang-kadang disebut kasus jaminan.
Pada dasarnya, kasus keamanan atau ketergantungan mengumpulkan semua bukti yang tersedia
yang menunjukkan bahwa suatu sistem dapat dipercaya. Untuk banyak jenis sistem kritis,
produksi kasus keselamatan adalah persyaratan hukum. Kasing harus memenuhi regulator
atau lembaga sertifikasi sebelum sistem dapat digunakan.
Tanggung jawab regulator adalah untuk memeriksa bahwa sistem yang lengkap aman
atau dapat diandalkan sebagai hal yang praktis, jadi peran mereka terutama berperan ketika a
15.5 Kasus keamanan dan ketergantungan 411
proyek pembangunan selesai. Namun, regulator dan pengembang jarang bekerja sendiri-sendiri;
mereka berkomunikasi dengan tim pengembangan untuk menetapkan apa yang harus disertakan
dalam kasus keselamatan. Regulator dan pengembang bersama-sama memeriksa proses dan
prosedur untuk memastikan bahwa ini diberlakukan dan didokumentasikan untuk kepuasan regulator.
Kasus ketergantungan biasanya dikembangkan selama dan setelah proses pengembangan

sistem. Hal ini terkadang dapat menyebabkan masalah jika aktivitas proses pengembangan tidak
menghasilkan bukti untuk ketergantungan sistem. Graydon dkk. (2007) berpendapat bahwa
pengembangan kasus keamanan dan ketergantungan harus terintegrasi erat dengan desain dan
implementasi sistem. Ini berarti bahwa keputusan desain sistem dapat dipengaruhi oleh persyaratan
kasus ketergantungan. Pilihan desain yang dapat menambah kesulitan dan biaya pengembangan
kasus secara signifikan dapat dihindari.
Kasus ketergantungan adalah generalisasi dari kasus keamanan sistem. Kasus keselamatan
adalah seperangkat dokumen yang mencakup deskripsi sistem yang akan disertifikasi, informasi
tentang proses yang digunakan untuk mengembangkan sistem dan, secara kritis, argumen logis
yang menunjukkan bahwa sistem kemungkinan besar aman. Lebih ringkasnya, Bishop dan Bloomfield
(1998) mendefinisikan kasus keamanan sebagai:
Kumpulan bukti terdokumentasi yang memberikan argumen yang meyakinkan dan valid
bahwa suatu sistem cukup aman untuk aplikasi tertentu dalam lingkungan tertentu.
Organisasi dan isi kasus keselamatan atau ketergantungan bergantung pada jenis sistem yang
akan disertifikasi dan konteks operasinya. Gambar 15.7 menunjukkan satu struktur yang mungkin
untuk kasus keselamatan tetapi tidak ada standar industri yang digunakan secara luas di area ini
untuk kasus keselamatan. Struktur kasus keamanan bervariasi, tergantung pada industri dan
kematangan domain. Misalnya, kasus keselamatan nuklir telah diperlukan selama bertahun-tahun.
Mereka sangat komprehensif dan disajikan dengan cara yang akrab bagi para insinyur nuklir. Namun,
kasus keamanan untuk perangkat medis telah diperkenalkan baru-baru ini. Struktur mereka lebih
fleksibel dan kasusnya sendiri kurang detail dibandingkan kasus nuklir.
Tentu saja, perangkat lunak itu sendiri tidak berbahaya. Hanya ketika tertanam dalam sistem
berbasis komputer atau sosioteknik yang besar, kegagalan perangkat lunak dapat mengakibatkan
kegagalan peralatan atau proses lain yang dapat menyebabkan cedera atau kematian. Oleh karena
itu, kasus keamanan perangkat lunak selalu menjadi bagian dari kasus keamanan sistem yang lebih
luas yang menunjukkan keamanan sistem secara keseluruhan. Saat membangun kasus keamanan
perangkat lunak, Anda harus menghubungkan kegagalan perangkat lunak dengan kegagalan sistem
yang lebih luas dan menunjukkan bahwa kegagalan perangkat lunak ini tidak akan terjadi atau tidak
akan disebarkan sedemikian rupa sehingga kegagalan sistem yang berbahaya dapat terjadi.
15.5.1 Argumen terstruktur

Keputusan apakah suatu sistem cukup dapat diandalkan untuk digunakan harus didasarkan pada
argumen logis. Ini harus menunjukkan bahwa bukti yang disajikan mendukung klaim tentang
keamanan dan ketergantungan sistem. Klaim-klaim ini mungkin absolut (peristiwa X akan atau tidak
akan terjadi) atau probabilistik (probabilitas
Bab Keterangan
Deskripsi sistem Gambaran umum sistem dan deskripsi komponen kritisnya.
Persyaratan keamanan Persyaratan keselamatan disarikan dari spesifikasi persyaratan sistem.

Rincian persyaratan sistem lain yang relevan juga dapat disertakan.
Analisis bahaya Dokumen yang menjelaskan bahaya dan risiko yang telah diidentifikasi dan tindakan
dan risiko yang diambil untuk mengurangi risiko. Analisis bahaya dan log bahaya.
Analisis desain Serangkaian argumen terstruktur (lihat Bagian 15.5.1) yang membenarkan mengapa desain itu aman.
Verifikasi dan Deskripsi prosedur V & V yang digunakan dan, jika sesuai, rencana pengujian untuk
validasi sistem. Ringkasan hasil pengujian yang menunjukkan cacat yang telah terdeteksi dan
diperbaiki. Jika metode formal telah digunakan, spesifikasi sistem formal dan analisis
apa pun dari spesifikasi itu. Rekaman analisis statis dari kode sumber.
Tinjau laporan Rekaman semua tinjauan desain dan keselamatan.
Kompetensi tim Bukti kompetensi semua tim yang terlibat dalam pengembangan dan validasi sistem
terkait keselamatan.
Proses QA Rekaman proses jaminan kualitas (lihat Bab 24) yang dilakukan selama pengembangan
sistem.
Ubah proses manajemen Rekaman semua perubahan yang diusulkan, tindakan yang diambil dan, jika
perlu, justifikasi keamanan perubahan ini. Informasi tentang prosedur manajemen
konfigurasi dan log manajemen konfigurasi.
Kasus keamanan terkait Referensi ke kasus keselamatan lain yang mungkin berdampak pada kasus keselamatan.
terjadinya peristiwa Y adalah 0.n). Argumen menghubungkan bukti dan klaim. Seperti yang
Gambar 15.7 Isi
kasus keamanan ditunjukkan pada Gambar 15.8, argumen adalah hubungan antara apa yang dianggap
perangkat lunak sebagai kasus (klaim) dan kumpulan bukti yang telah dikumpulkan. Argumen tersebut, pada
dasarnya, menjelaskan mengapa klaim, yang merupakan pernyataan tentang keamanan
atau ketergantungan sistem, dapat disimpulkan dari bukti yang tersedia.
Misalnya, pompa insulin adalah perangkat kritis keselamatan yang kegagalannya dapat
menyebabkan cedera pada pengguna. Di banyak negara, ini berarti bahwa otoritas pengatur
(di Inggris, Direktorat Alat Kesehatan) harus diyakinkan tentang keamanan sistem sebelum
perangkat dapat dijual dan digunakan. Untuk membuat keputusan ini, regulator menilai
kasus keamanan untuk sistem, yang menyajikan argumen terstruktur bahwa operasi normal
sistem tidak akan membahayakan pengguna.
Kasus keamanan biasanya mengandalkan argumen terstruktur dan berbasis klaim.
Misalnya, argumen berikut mungkin digunakan untuk membenarkan klaim bahwa
perhitungan yang dilakukan oleh perangkat lunak kontrol tidak akan menyebabkan overdosis
insulin yang dikirim ke pengguna pompa. Tentu saja, ini adalah argumen yang sangat
disederhanakan. Dalam kasus keamanan nyata, referensi yang lebih rinci untuk bukti akan disajikan.
Bukti
Mendukung
Bukti << ARGUMEN >> Mengeklaim
Mendukung Membenarkan
Mendukung
Bukti
Gambar 15.8 Argumen
terstruktur
Klaim: Dosis tunggal maksimum yang dihitung oleh pompa insulin tidak akan melebihi
maxDose, di mana maxDose telah dinilai sebagai dosis tunggal yang aman untuk pasien
tertentu.
Bukti: Argumen keamanan untuk program kontrol perangkat lunak pompa insulin (saya
akan membahas argumen keamanan nanti di bagian ini).
Bukti: Kumpulan data uji untuk pompa insulin. Dalam 400 tes, nilai currentDose dihitung
dengan benar dan tidak pernah melebihi maxDose.
Bukti: Laporan analisis statis untuk program kontrol pompa insulin. Analisis statis
perangkat lunak kontrol mengungkapkan tidak ada anomali yang mempengaruhi nilai
CurrentDose, variabel program yang menahan dosis insulin yang akan dikirimkan.
Argumen: Bukti yang disajikan menunjukkan bahwa dosis maksimum insulin yang dapat
dihitung sama dengan maxDose.
Oleh karena itu masuk akal untuk mengasumsikan, dengan tingkat kepercayaan yang
tinggi, bahwa bukti membenarkan klaim bahwa pompa insulin tidak akan menghitung dosis
insulin yang akan diberikan yang melebihi dosis tunggal maksimum.
Perhatikan bahwa bukti yang disajikan berlebihan dan beragam. Perangkat lunak diperiksa
menggunakan beberapa mekanisme berbeda dengan tumpang tindih yang signifikan di antara
mereka. Seperti yang saya bahas di Bab 13, penggunaan proses yang berlebihan dan beragam
meningkatkan kepercayaan diri. Jika ada kelalaian dan kesalahan yang tidak terdeteksi oleh
satu proses validasi, ada kemungkinan besar bahwa ini akan ditemukan oleh salah satu dari
yang lain.
Tentu saja, biasanya akan ada banyak klaim tentang keandalan dan keamanan suatu
sistem, dengan validitas satu klaim seringkali tergantung pada valid atau tidaknya klaim
lainnya. Oleh karena itu, klaim dapat diatur dalam hierarki. Gambar 15.9 menunjukkan bagian
dari hierarki klaim ini untuk pompa insulin. Untuk menunjukkan bahwa klaim tingkat tinggi
valid, pertama-tama Anda harus menyelesaikan argumen untuk klaim tingkat rendah. Jika Anda
dapat menunjukkan bahwa setiap klaim tingkat yang lebih rendah ini dibenarkan, maka Anda
mungkin dapat menyimpulkan bahwa klaim tingkat yang lebih tinggi dibenarkan.
Pompa insulin tidak

akan memberikan satu
dosis insulin yang tidak
aman
Dosis tunggal maxDose diatur maxDose adalah dosis

maksimum yang dengan benar saat yang aman bagi pengguna
dihitung oleh perangkat pompa dikonfigurasi pompa insulin
lunak pompa tidak akan
melebihi maxDose
dalam keadaan normal

Jika perangkat lunak
operasi, dosis gagal, dosis
maksimum maksimum yang
dihitung tidak akan dihitung tidak akan melebihi maxDose
melebihi maxDose
klaim keamanan15.5.2
untukArgumen keamanan terstruktur Gambar 15.9 Hirarki
pompa insulin
Argumen keamanan terstruktur adalah jenis argumen terstruktur, yang menunjukkan bahwa
suatu program memenuhi kewajiban keamanannya. Dalam argumen keamanan, tidak perlu
membuktikan bahwa program bekerja sebagaimana dimaksud. Anda hanya perlu menunjukkan
bahwa eksekusi program tidak dapat menghasilkan keadaan tidak aman. Ini berarti bahwa
argumen keamanan lebih murah untuk dibuat daripada argumen kebenaran. Anda tidak harus
mempertimbangkan semua status program—Anda cukup berkonsentrasi pada status yang dapat menyebabkan kecelakaan
Asumsi umum yang mendasari pekerjaan dalam keselamatan sistem adalah bahwa jumlah
kesalahan sistem yang dapat menyebabkan bahaya kritis keselamatan secara signifikan lebih
sedikit daripada jumlah total kesalahan yang mungkin ada dalam sistem. Jaminan keamanan
dapat berkonsentrasi pada kesalahan yang memiliki potensi bahaya. Jika dapat ditunjukkan
bahwa kesalahan ini tidak dapat terjadi atau, jika terjadi, bahaya terkait tidak akan
mengakibatkan kecelakaan, maka sistem tersebut aman. Ini adalah dasar dari argumen keamanan terstruktur.
Argumen keamanan terstruktur dimaksudkan untuk menunjukkan bahwa, dengan asumsi
kondisi eksekusi normal, sebuah program harus aman. Mereka biasanya didasarkan pada
kontradiksi. Langkah-langkah yang terlibat dalam menciptakan argumen keamanan adalah sebagai berikut:
1. Anda mulai dengan mengasumsikan bahwa keadaan tidak aman, yang telah diidentifikasi
oleh analisis bahaya sistem, dapat dicapai dengan menjalankan program.
2. Anda menulis predikat (ekspresi logis) yang mendefinisikan status tidak aman ini.
3. Anda kemudian secara sistematis menganalisis model sistem atau program dan
menunjukkan bahwa, untuk semua jalur program yang mengarah ke status tersebut,
kondisi penghentian jalur ini bertentangan dengan predikat status tidak aman. Jika hal
ini terjadi, asumsi awal dari keadaan tidak aman adalah salah.
— Dosis insulin yang akan diberikan adalah fungsi dari — kadar gula darah,
dosis sebelumnya yang diberikan dan — waktu pemberian dosis sebelumnya
currentDose = computeInsulin() ;
// Pemeriksaan keamanan–sesuaikan Dosis saat ini jika perlu.
// jika pernyataan 1
if (sebelumnyaDosis == 0) {
if (currentDose > maxDose/2) currentDose

= maxDose/2 ;
} else
if (currentDose > (previousDose * 2) ) currentDose =
PreviousDose * 2 ;
// jika pernyataan 2
jika ( dosis saat ini < dosis minimum )

dosis saat ini = 0 ;
lain jika ( currentDose > maxDose ) currentDose =
Gambar 15.10 Perhitungan maxDose ; mengelolaInsulin (Dosis saat ini);
dosis insulin dengan

pemeriksaan keamanan
4. Bila Anda telah mengulangi analisis ini untuk semua bahaya yang teridentifikasi, maka Anda
memiliki bukti kuat bahwa sistem tersebut aman.
Argumen keamanan terstruktur dapat diterapkan pada tingkat yang berbeda, mulai dari
persyaratan melalui model desain hingga kode. Pada tingkat persyaratan, Anda mencoba untuk
menunjukkan bahwa tidak ada persyaratan keselamatan yang hilang dan bahwa persyaratan
tersebut tidak membuat asumsi yang tidak valid tentang sistem. Pada tingkat desain, Anda dapat
menganalisis model status sistem untuk menemukan status tidak aman. Pada tingkat kode, Anda
mempertimbangkan semua jalur melalui kode kritis keselamatan untuk menunjukkan bahwa
eksekusi semua jalur mengarah pada kontradiksi.
Sebagai contoh, perhatikan kode pada Gambar 15.10, yang mungkin merupakan bagian dari
implementasi sistem pengiriman insulin. Kode menghitung dosis insulin yang akan dikirim
kemudian menerapkan beberapa pemeriksaan keamanan untuk mengurangi kemungkinan
overdosis insulin akan disuntikkan. Mengembangkan argumen keamanan untuk kode ini
melibatkan menunjukkan bahwa dosis insulin yang diberikan tidak pernah lebih besar dari tingkat
aman maksimum untuk dosis tunggal. Ini ditetapkan untuk setiap pengguna diabetes individu
dalam diskusi dengan penasihat medis mereka.
Untuk menunjukkan keamanan, Anda tidak perlu membuktikan bahwa sistem memberikan
dosis yang 'benar', hanya saja tidak pernah memberikan overdosis kepada pasien. Anda bekerja
dengan asumsi bahwa maxDose adalah tingkat yang aman untuk pengguna sistem tersebut.
Untuk menyusun argumen keamanan, Anda mengidentifikasi predikat yang mendefinisikan
status tidak aman, yaitu currentDose maxDose. Anda kemudian menunjukkan bahwa semua jalur
program mengarah ke kontradiksi dari pernyataan tidak aman ini. Jika ini masalahnya,
Overdosis
Dikelola
mengelola insulin
Dosis saat ini> Pra-Kondisi

dosis maksimal untuk Keadaan Tidak Aman
atau
Kontradiksi
currentDose >= minimumDose dan

currentDose <= maxDose
Kontradiksi Kontradiksi
dosis saat ini =

dosis saat ini = 0
dosis maks
Menetapkan Menetapkan
Jika Pernyataan 2 dosis saat ini =

dosis saat ini = 0
Tidak Dieksekusi dosis maks
Jika Pernyataan 2 Jika Pernyataan 2

Kemudian Cabang Cabang Lain
Gambar 15.11 Argumen
Dieksekusi Dieksekusi
keamanan informal
berdasarkan demonstrasi
kontradiksi
kondisi tidak aman tidak mungkin benar. Jika Anda dapat melakukan ini, Anda dapat yakin bahwa
program tidak akan menghitung dosis insulin yang tidak aman. Anda dapat menyusun dan
menyajikan argumen keamanan secara grafis, seperti yang ditunjukkan pada Gambar 15.11.
Untuk menyusun argumen terstruktur agar program tidak membuat perhitungan yang tidak
aman, Anda terlebih dahulu mengidentifikasi semua jalur yang mungkin melalui kode yang
dapat mengarah ke keadaan yang berpotensi tidak aman. Anda bekerja mundur dari keadaan
tidak aman ini dan mempertimbangkan tugas terakhir untuk semua variabel keadaan di setiap
jalur yang mengarah ke keadaan tidak aman ini. Jika Anda dapat menunjukkan bahwa tidak
ada nilai dari variabel ini yang tidak aman, maka Anda telah menunjukkan bahwa asumsi awal Anda (bahwa perhitungannya
Bekerja mundur itu penting karena itu berarti Anda dapat mengabaikan semua status selain
status akhir yang mengarah ke kondisi keluar untuk kode. Nilai-nilai sebelumnya tidak penting
bagi keamanan sistem. Dalam contoh ini, yang perlu Anda perhatikan adalah kumpulan nilai
yang mungkin dari Dosis saat ini segera
sebelum metodeadmininsulin dijalankan. Anda dapat mengabaikan perhitungan, seperti

jika-pernyataan 1 pada Gambar 15.10, dalam argumen keamanan karena hasilnya akan
ditimpa dalam pernyataan program selanjutnya.
Dalam argumen keamanan yang ditunjukkan pada Gambar 15.11, ada tiga kemungkinan
jalur program yang mengarah ke panggilan ke metodeadmininsulin. Anda harus menunjukkan
bahwa jumlah insulin yang diberikan tidak pernah melebihi maxDose. Semua jalur program
yang mungkin untuk mengelolaInsulin dipertimbangkan:
1. Tidak ada cabang dari pernyataan if 2 yang dieksekusi. Ini hanya dapat terjadi jika
currentDose lebih besar dari atau sama dengan minimumDose dan kurang dari atau
sama dengan maxDose. Ini adalah post-condition—pernyataan yang benar setelah
pernyataan dieksekusi.
2. Cabang-kemudian dari pernyataan if 2 dieksekusi. Dalam hal ini, pengaturan penetapan

currentDose ke nol dijalankan. Oleh karena itu, kondisi pascanya adalah currentDose
0.
3. Cabang else-if dari pernyataan if 2 dieksekusi. Dalam kasus ini, penetapan set ting
currentDose ke maxDose dijalankan. Oleh karena itu, setelah pernyataan ini dijalankan,
kita tahu bahwa kondisi pascanya adalah currentDose maxDose.
Dalam ketiga kasus, pascakondisi bertentangan dengan prakondisi tidak aman bahwa
dosis yang diberikan lebih besar dari maxDose. Oleh karena itu, kami dapat mengklaim
bahwa komputasi tersebut aman.
Argumen terstruktur dapat digunakan dengan cara yang sama untuk menunjukkan
bahwa properti keamanan tertentu dari suatu sistem adalah benar. Misalnya, jika Anda ingin
menunjukkan bahwa penghitungan tidak akan pernah menyebabkan izin pada sumber daya
diubah, Anda mungkin dapat menggunakan argumen keamanan terstruktur untuk
menunjukkannya. Namun, bukti dari argumen terstruktur kurang dapat diandalkan untuk
validasi keamanan. Ini karena ada kemungkinan penyerang dapat merusak kode sistem.
Dalam kasus seperti itu, kode yang dieksekusi bukanlah kode yang Anda klaim aman.
POIN KUNCI
Analisis statis adalah pendekatan V & V yang memeriksa kode sumber (atau representasi lain) dari suatu sistem, mencari
kesalahan dan anomali. Hal ini memungkinkan semua bagian dari program untuk diperiksa, bukan hanya bagian-bagian
yang dilakukan oleh pengujian sistem.
Pengecekan model adalah pendekatan formal untuk analisis statis yang secara mendalam memeriksa semua status dalam
sistem untuk kemungkinan kesalahan.
Pengujian statistik digunakan untuk memperkirakan keandalan perangkat lunak. Itu bergantung pada pengujian sistem dengan
kumpulan data uji yang mencerminkan profil operasional perangkat lunak. Data uji dapat dibuat secara otomatis.
Validasi keamanan sulit karena persyaratan keamanan menyatakan apa yang seharusnya tidak terjadi dalam sistem, daripada apa yang
seharusnya. Selain itu, penyerang sistem cerdas dan mungkin memiliki lebih banyak waktu untuk menyelidiki kelemahan daripada
yang tersedia untuk pengujian keamanan.
Validasi keamanan dapat dilakukan dengan menggunakan analisis berbasis pengalaman, analisis berbasis alat, atau
'tim harimau' yang mensimulasikan serangan pada sistem.
Penting untuk memiliki proses yang terdefinisi dengan baik dan bersertifikat untuk pengembangan sistem yang kritis terhadap keselamatan.
Proses tersebut harus mencakup identifikasi dan pemantauan potensi bahaya.
Kasus keamanan dan ketergantungan mengumpulkan semua bukti yang menunjukkan sistem aman dan dapat diandalkan. Kasus
keamanan diperlukan ketika regulator eksternal harus mengesahkan sistem sebelum digunakan.
Kasus keamanan biasanya didasarkan pada argumen terstruktur. Argumen keamanan terstruktur menunjukkan bahwa kondisi berbahaya
yang teridentifikasi tidak akan pernah terjadi dengan mempertimbangkan semua jalur program yang mengarah ke kondisi tidak aman,
dan menunjukkan bahwa kondisi tersebut tidak dapat dipertahankan.
BACAAN LEBIH LANJUT
Rekayasa Keandalan Perangkat Lunak: Perangkat Lunak Lebih Handal, Lebih Cepat dan Lebih Murah, edisi ke-2.
Ini mungkin buku definitif tentang penggunaan profil operasional dan model keandalan untuk penilaian keandalan. Ini
mencakup rincian pengalaman dengan pengujian statistik. (JD Musa, McGraw-Hill, 2004.)
'Misi NASA Dapat Diandalkan'. Sebuah diskusi tentang bagaimana NASA telah menggunakan analisis statis dan
pemeriksaan model untuk memastikan keandalan perangkat lunak pesawat ruang angkasa. (P. Regan dan S. Hamilton,
IEEE Computer, 37 (1), Januari 2004.) http://dx.doi.org/10.1109/MC.2004.1260727.
Kasus ketergantungan. Pengantar berbasis contoh untuk mendefinisikan kasus ketergantungan. (CB
Weinstock, JB Goodenough, JJ Hudak, Software Engineering Institute, CMU/SEI-2004-TN-016, 2004.) http://
www.sei.cmu.edu/publications/documents/04.reports/04tn016.html.
Cara Memecah Perangkat Lunak Web: Pengujian Fungsional dan Keamanan Aplikasi Web dan Layanan Web.
Buku pendek yang memberikan saran praktis yang baik tentang cara menjalankan tes keamanan pada aplikasi
jaringan. (M. Andrews dan JA Whittaker, Addison-Wesley, 2006.)
'Menggunakan analisis statis untuk menemukan bug'. Makalah ini menjelaskan Findbugs, penganalisis statis Java yang
menggunakan teknik sederhana untuk menemukan potensi pelanggaran keamanan dan kesalahan runtime. (N. Ayewah
dkk., IEEE Software, 25 (5), Sept/Oct 2008.) http://dx.doi.org/10.1109/MS.2008.130.
Bab 15 Latihan 419
LATIHAN
15.1. Jelaskan kapan mungkin hemat biaya untuk menggunakan spesifikasi formal dan verifikasi dalam pengembangan
sistem perangkat lunak yang kritis terhadap keselamatan. Menurut Anda mengapa para insinyur sistem kritis
menentang penggunaan metode formal?
15.2. Sarankan daftar kondisi yang dapat dideteksi oleh penganalisis statis untuk Java, C++, atau apa pun
bahasa pemrograman lain yang Anda gunakan. Komentar pada daftar ini dibandingkan dengan daftar yang diberikan
pada Gambar 15.2.
15.3. Jelaskan mengapa secara praktis tidak mungkin untuk memvalidasi spesifikasi keandalan ketika ini dinyatakan dalam
jumlah kegagalan yang sangat kecil selama masa hidup total suatu sistem.
15.4. Jelaskan mengapa memastikan keandalan sistem bukan merupakan jaminan keamanan sistem.
15.5. Dengan menggunakan contoh, jelaskan mengapa pengujian keamanan adalah proses yang sangat sulit.
15.6. Sarankan bagaimana Anda akan memvalidasi sistem perlindungan kata sandi untuk aplikasi yang telah Anda kembangkan.
Jelaskan fungsi alat apa saja yang menurut Anda mungkin berguna.
15.7. MHC-PMS harus aman dari serangan yang mungkin mengungkapkan rahasia pasien
informasi. Beberapa dari serangan ini telah dibahas dalam Bab 14. Dengan menggunakan informasi ini, perluas daftar
periksa pada Gambar 15.5 untuk memandu penguji MHC-PMS.
15.8. Sebutkan empat jenis sistem yang mungkin memerlukan kasus keamanan perangkat lunak, jelaskan mengapa kasus keamanan
diperlukan.
15.9. Mekanisme kontrol kunci pintu di fasilitas penyimpanan limbah nuklir dirancang untuk keamanan
operasi. Ini memastikan bahwa masuk ke gudang hanya diizinkan ketika perisai radiasi berada di tempatnya atau ketika
tingkat radiasi di dalam ruangan turun di bawah nilai tertentu (tingkat bahaya). Jadi:
saya. Jika pelindung radiasi yang dikendalikan dari jarak jauh dipasang di dalam ruangan, operator resmi dapat
membuka pintu.
ii. Jika tingkat radiasi dalam ruangan di bawah nilai yang ditentukan, operator resmi dapat membuka
pintu.
aku aku aku. Operator resmi diidentifikasi dengan memasukkan kode entri pintu resmi.
Kode yang ditunjukkan pada Gambar 15.12 (lihat di bawah) mengontrol mekanisme penguncian pintu. Perhatikan
bahwa keadaan aman adalah bahwa entri tidak boleh diizinkan. Dengan menggunakan pendekatan yang dibahas di
bagian 15.5.2, kembangkan argumen keamanan untuk kode ini. Gunakan nomor baris untuk merujuk ke pernyataan
tertentu. Jika Anda menemukan bahwa kode tersebut tidak aman, sarankan bagaimana kode tersebut harus dimodifikasi
agar aman.
1 entryCode = kunci.getEntryCode() ; if (EntryCode

2 == lock.authorizedCode) {
34 shieldStatus = Perisai.getStatus();
5 radiasiLevel = RadSensor.get();
6 if (radiationLevel < hazardLevel)
7 negara = aman;
8 kalau tidak
keadaan = tidak
9 aman; if (shieldStatus == Shield.inPlace() )
10 11 negara = aman;
12 jika (status == aman)
13 {
14 Door.locked = salah ;
15 Pintu.buka ();
16 }
17 kalau tidak
18 {
19 Kunci pintu ( );
20 Door.locked := benar ;
21 }
22 }
Gambar 15.12 Pintu
kode masuk
15.10. Asumsikan Anda adalah bagian dari tim yang mengembangkan perangkat lunak untuk pabrik kimia, yang gagal,
menyebabkan insiden polusi yang serius. Bos Anda diwawancarai di televisi dan menyatakan bahwa
proses validasi komprehensif dan tidak ada kesalahan dalam perangkat lunak. Dia
menegaskan bahwa masalah harus disebabkan oleh prosedur operasional yang buruk. Koran
mendekati Anda untuk pendapat Anda. Diskusikan bagaimana Anda harus menangani wawancara semacam itu.
REFERENSI
Abrial, JR (2005). Buku B: Menugaskan Program ke Makna. Cambridge, Inggris: Cambridge

Pers Universitas.
Anderson, R. (2001). Rekayasa Keamanan: Panduan untuk Membangun Sistem Terdistribusi yang Dapat Diandalkan.
Chichester, Inggris: John Wiley & Sons.
Baier, C. dan Katoen, J.-P. (2008). Prinsip Pemeriksaan Model. Cambridge, Mass.: MIT Press.
Bola, T., Bounimova, E., Masak, B., Levin, V., Lichtenberg, J., McGarvey, C., Ondrusek, B., SK, R.
dan Ustuner, A. (2006). 'Analisis Statis Menyeluruh dari Driver Perangkat'. Prok. EuroSys 2006, Leuven,
Belgium.
Uskup, P. dan Bloomfield, RE (1998). 'Sebuah metodologi untuk pengembangan kasus keselamatan'. Prok.
Simposium Sistem Keselamatan-kritis, Birmingham, Inggris: Springer.
Chandra, S., Godefroid, P. dan Palm, C. (2002). 'Pemeriksaan model perangkat lunak dalam praktik: Studi kasus industri'.
Prok. 24th Int. Kon. pada Perangkat Lunak Eng. (ICSE 2002), Orland, Fla.: IEEE Computer Society, 431–41.
Croxford, M. dan Sutton, J. (2006). 'Menerobos Kemacetan V dan V'. Prok. 2nd Int.
Eurospace—Ada-Europe Symposium tentang Ada di Eropa, Frankfurt, Jerman: Springer-LNCS,
344–54.
Evans, D. dan Larochelle, D. (2002). 'Meningkatkan Keamanan Menggunakan Analisis Statis Ringan yang Dapat
Diperluas'. Perangkat Lunak IEEE, 19 (1), 42–51.
Graydon, PJ, Knight, JC dan Strunk, EA (2007). 'Pengembangan Sistem Kritis Berbasis Jaminan'. Prok. Konferensi
IEEE Tahunan ke-37 pada Sistem dan Jaringan yang Dapat Diandalkan, Edinburgh, Skotlandia:
347–57.
Holzmann, GJ (2003). Pemeriksa Model SPIN. Boston: Addison-Wesley.
Knight, JC dan Leveson, NG (2002). 'Haruskah insinyur perangkat lunak dilisensikan?' Kom. ACM, 45 (11), 87–90.
Larus, JR, Bola, T., Das, M., Deline, R., Fahndrich, M., Pincus, J., Rajamani, SK dan Venkatapathy, R.
(2003). 'Perangkat Lunak Kanan'. Perangkat Lunak IEEE, 21 (3), 92–100.
Musa, JD (1998). Rekayasa Keandalan Perangkat Lunak: Perangkat Lunak Lebih Handal, Pengembangan dan
Pengujian Lebih Cepat. New York: McGraw-Hill.
Nguyen, T. dan Ourghanlian, A. (2003). 'Penilaian keandalan perangkat lunak sistem kritis keselamatan dengan metode
analisis statis'. Prok. IEEE Conf. pada Sistem dan Jaringan yang Dapat Diandalkan (DSN'2003), San Francisco, California:
IEEE Computer Society, 75–9.
Pfleeger, CP dan Pfleeger, SL (2007). Keamanan dalam Komputasi, edisi ke-4. Boston: Addison-
Wesley.
Prowell, SJ, Trammell, CJ, Berlama-lama, RC dan Poore, JH (1999). Rekayasa Perangkat Lunak Cleanroom: Teknologi
dan Proses. Membaca, Mass.: Addison-Wesley.
Regan, P. dan Hamilton, S. (2004). 'Misi NASA Dapat Diandalkan'. Komputer IEEE, 37 (1), 59–68.
Schneider, S. (1999). Sistem Konkuren dan Real-time: Pendekatan CSP. Chichester, Inggris: John Wiley and Sons.
Visser, W., Havelund, K., Brat, G., Park, S. dan Lerda, F. (2003). 'Program Pengecekan Model'.
Rekayasa Perangkat Lunak Otomatis J., 10 (2), 203–32.
Voas, J. (1997). 'Injeksi Kesalahan untuk Massa'. Komputer IEEE, 30 (12), 129–30.
Wordsworth, J. (1996). Rekayasa Perangkat Lunak dengan B. Wokingham: Addison-Wesley.
Zheng, J., Williams, L., Nagappan, N., Snipes, W., Hudepohl, JP dan Vouk, MA (2006). 'Pada nilai analisis statis untuk
deteksi kesalahan dalam perangkat lunak'. IEEE Trans. pada Software Eng., 32 (4), 240–5.
halaman ini sengaja dibiarkan kosong

BAGIAN
Saya memberi judul bagian buku ini 'Rekayasa Perangkat Lunak Lanjutan'
karena Anda harus memahami dasar-dasar disiplin, tercakup dalam
Bab 1–9, untuk mengambil manfaat dari materi yang dibahas di sini. Banyak topik
dibahas di sini mencerminkan praktek rekayasa perangkat lunak industri dalam pengembangan
sistem terdistribusi dan real-time.
Penggunaan kembali perangkat lunak kini telah menjadi paradigma pengembangan yang dominan
untuk sistem informasi berbasis web dan sistem perusahaan. Yang paling
pendekatan umum untuk penggunaan kembali adalah penggunaan kembali COTS di mana
sistem besar dikonfigurasi untuk kebutuhan organisasi dan sedikit atau tidak ada perangkat lunak asli
pengembangan diperlukan. Saya memperkenalkan topik umum penggunaan kembali di Bab
16 dan fokus dalam bab ini pada penggunaan kembali sistem COTS.
Bab 17 juga berkaitan dengan penggunaan kembali komponen perangkat lunak

daripada keseluruhan sistem perangkat lunak. Rekayasa perangkat lunak berbasis komponen adalah
proses komposisi komponen, dengan kode baru sedang dikembangkan untuk
mengintegrasikan komponen yang dapat digunakan kembali. Dalam bab ini, saya menjelaskan apa yang dimaksud dengan
komponen dan mengapa model komponen standar diperlukan untuk penggunaan kembali
komponen yang efektif. Saya juga membahas proses umum rekayasa perangkat lunak
berbasis komponen dan masalah komposisi komponen.
Mayoritas sistem besar sekarang adalah sistem terdistribusi dan Bab 18

mencakup isu-isu dan masalah membangun sistem terdistribusi. saya perkenalkan
pendekatan client-server sebagai paradigma dasar rekayasa sistem terdistribusi,

dan menjelaskan berbagai cara menerapkan gaya arsitektur ini. Bagian terakhir
dalam bab ini menjelaskan bagaimana menyediakan perangkat lunak sebagai
layanan aplikasi terdistribusi akan secara radikal mengubah pasar produk perangkat
lunak.
Bab 19 memperkenalkan topik terkait arsitektur berorientasi layanan, yang

menghubungkan pengertian distribusi dan penggunaan kembali. Layanan dapat digunakan kembali
komponen perangkat lunak yang fungsinya dapat diakses melalui Internet dan
tersedia untuk berbagai klien. Dalam bab ini, saya menjelaskan apa yang terlibat
dalam pembuatan layanan (service engineering) dan penyusunan layanan untuk
membuat sistem perangkat lunak baru.
Sistem tertanam adalah contoh sistem perangkat lunak yang paling banyak
digunakan dan Bab 20 membahas topik penting ini. Saya memperkenalkan ide
sistem tertanam waktu nyata dan menjelaskan tiga pola arsitektur yang digunakan
dalam desain sistem tertanam. Saya kemudian menjelaskan proses analisis waktu
dan menyimpulkan bab dengan diskusi tentang sistem operasi waktu nyata.
Akhirnya, Bab 21 mencakup pengembangan perangkat lunak berorientasi aspek (AOSD).

AOSD juga terkait dengan penggunaan kembali dan mengusulkan pendekatan baru,
berdasarkan aspek, untuk mengatur dan menyusun sistem perangkat lunak.
Meskipun belum menjadi rekayasa perangkat lunak arus utama, AOSD memiliki
potensi untuk secara signifikan meningkatkan pendekatan kami saat ini untuk implementasi perangkat lunak.
16
Penggunaan kembali perangkat lunak
Tujuan
Tujuan dari bab ini adalah untuk memperkenalkan penggunaan kembali perangkat lunak
dan untuk menggambarkan pendekatan pengembangan sistem berdasarkan penggunaan kembali
sistem skala besar. Setelah Anda membaca bab ini, Anda akan:
memahami manfaat dan masalah penggunaan kembali perangkat lunak saat

mengembangkan sistem baru;
memahami konsep kerangka kerja aplikasi sebagai kumpulan objek yang dapat
digunakan kembali dan bagaimana kerangka kerja dapat digunakan dalam
pengembangan aplikasi;
telah diperkenalkan ke lini produk perangkat lunak, yang terdiri dari arsitektur inti umum dan
komponen yang dapat dikonfigurasi dan digunakan kembali ;
telah mempelajari bagaimana sistem dapat dikembangkan dengan mengonfigurasi dan

menyusun sistem perangkat lunak aplikasi yang siap pakai.
Isi
16.1 Lanskap penggunaan kembali
16.2 Kerangka aplikasi 16.3 Lini
produk perangkat lunak 16.4
Penggunaan kembali produk COTS

426 Bab 16 Penggunaan kembali perangkat lunak
Rekayasa perangkat lunak berbasis penggunaan kembali adalah strategi rekayasa perangkat lunak di mana
proses pengembangan diarahkan untuk menggunakan kembali perangkat lunak yang ada. Meskipun
penggunaan kembali diusulkan sebagai strategi pengembangan lebih dari 40 tahun yang lalu (McIlroy, 1968),
hanya sejak tahun 2000 'pengembangan dengan penggunaan kembali' telah menjadi norma untuk sistem bisnis baru.
Perpindahan ke pengembangan berbasis penggunaan kembali sebagai tanggapan atas tuntutan akan biaya
produksi dan pemeliharaan perangkat lunak yang lebih rendah, pengiriman sistem yang lebih cepat, dan
peningkatan kualitas perangkat lunak. Semakin banyak perusahaan melihat perangkat lunak mereka sebagai aset berharga.
Mereka mempromosikan penggunaan kembali untuk meningkatkan laba atas investasi perangkat lunak.
Ketersediaan perangkat lunak yang dapat digunakan kembali telah meningkat secara dramatis. Pergerakan
open source berarti bahwa ada basis kode besar yang dapat digunakan kembali yang tersedia dengan biaya rendah.
Ini mungkin dalam bentuk perpustakaan program atau seluruh aplikasi. Ada banyak sistem aplikasi khusus
domain yang tersedia yang dapat disesuaikan dan disesuaikan dengan kebutuhan perusahaan tertentu.
Beberapa perusahaan besar menyediakan berbagai komponen yang dapat digunakan kembali untuk pelanggan
mereka. Standar, seperti standar layanan web, telah mempermudah pengembangan layanan umum dan
menggunakannya kembali di berbagai aplikasi.
Rekayasa perangkat lunak berbasis penggunaan kembali adalah pendekatan pengembangan yang
mencoba memaksimalkan penggunaan kembali perangkat lunak yang ada. Unit perangkat lunak yang
digunakan kembali mungkin memiliki ukuran yang sangat berbeda. Sebagai contoh:
1. Penggunaan kembali sistem aplikasi Seluruh sistem aplikasi dapat digunakan kembali dengan
menggabungkannya tanpa mengubah ke sistem lain atau dengan mengkonfigurasi aplikasi untuk
pelanggan yang berbeda. Atau, keluarga aplikasi yang memiliki arsitektur umum, tetapi yang disesuaikan
untuk pelanggan tertentu, dapat dikembangkan. Saya membahas penggunaan kembali sistem aplikasi
nanti dalam bab ini.
2. Penggunaan kembali komponen Komponen aplikasi, mulai dari ukuran subsistem hingga objek tunggal,
dapat digunakan kembali. Misalnya, sistem pencocokan pola yang dikembangkan sebagai bagian dari
sistem pemrosesan teks dapat digunakan kembali dalam sistem manajemen basis data. Saya membahas
penggunaan kembali komponen di Bab 17 dan 19.
3. Penggunaan kembali objek dan fungsi Komponen perangkat lunak yang mengimplementasikan fungsi
tunggal, seperti fungsi matematika, atau kelas objek dapat digunakan kembali. Bentuk penggunaan
kembali ini, berdasarkan perpustakaan standar, telah umum selama 40 tahun terakhir.
Banyak perpustakaan fungsi dan kelas tersedia secara bebas. Anda menggunakan kembali kelas dan
fungsi di pustaka ini dengan menautkannya dengan kode aplikasi yang baru dikembangkan. Di bidang-
bidang seperti algoritma matematika dan grafik, di mana keahlian khusus diperlukan untuk
mengembangkan objek dan fungsi yang efisien, ini adalah pendekatan yang sangat efektif.
Sistem dan komponen perangkat lunak berpotensi menjadi entitas yang dapat digunakan kembali, tetapi
sifat spesifiknya terkadang berarti bahwa memodifikasinya untuk situasi baru memerlukan biaya yang mahal.
Bentuk pelengkap dari penggunaan kembali adalah 'penggunaan kembali konsep' di mana, alih-alih
menggunakan kembali komponen perangkat lunak, Anda menggunakan kembali sebuah ide, cara, atau
pekerjaan atau algoritma. Konsep yang Anda gunakan kembali direpresentasikan dalam notasi abstrak
(misalnya, model sistem), yang tidak menyertakan detail implementasi. Oleh karena itu, dapat dikonfigurasi
dan disesuaikan untuk berbagai situasi. Penggunaan kembali konsep dapat diwujudkan dalam pendekatan seperti desain
Bab 16 Penggunaan kembali perangkat lunak 427
Keuntungan Penjelasan
Peningkatan ketergantungan Perangkat lunak yang digunakan kembali, yang telah dicoba dan diuji dalam sistem kerja, harus
lebih dapat diandalkan daripada perangkat lunak baru. Kesalahan desain dan implementasinya
seharusnya ditemukan dan diperbaiki.
Mengurangi risiko proses Biaya perangkat lunak yang ada sudah diketahui, sedangkan biaya pengembangan
selalu menjadi pertimbangan. Ini adalah faktor penting untuk proyek
manajemen karena mengurangi margin kesalahan dalam estimasi biaya proyek.
Ini terutama benar ketika komponen perangkat lunak yang relatif besar seperti:
subsistem digunakan kembali.
Penggunaan spesialis yang efektif Alih-alih melakukan pekerjaan yang sama berulang-ulang, spesialis aplikasi dapat
mengembangkan perangkat lunak yang dapat digunakan kembali yang merangkum pengetahuan mereka.
Kepatuhan standar Beberapa standar, seperti standar antarmuka pengguna, dapat diimplementasikan sebagai seperangkat
komponen yang dapat digunakan kembali. Misalnya, jika menu di antarmuka pengguna diimplementasikan
menggunakan komponen yang dapat digunakan kembali, semua aplikasi menyajikan format menu yang sama untuk
pengguna. Penggunaan antarmuka pengguna standar meningkatkan ketergantungan karena pengguna
membuat lebih sedikit kesalahan saat disajikan dengan antarmuka yang familier.
Perkembangan yang dipercepat Membawa sistem ke pasar sedini mungkin seringkali lebih penting daripada
biaya pengembangan secara keseluruhan. Menggunakan kembali perangkat lunak dapat mempercepat produksi sistem
karena waktu pengembangan dan validasi dapat dikurangi.
pola (dibahas dalam Bab 7), produk sistem yang dapat dikonfigurasi, dan generator program. Ketika konsep
Gambar 16.1 Manfaat
penggunaan kembali perangkat lunak digunakan kembali, proses penggunaan kembali mencakup aktivitas di mana
konsep abstrak dipakai untuk membuat komponen yang dapat digunakan kembali yang dapat dieksekusi.
Keuntungan yang jelas dari penggunaan kembali perangkat lunak adalah bahwa biaya pengembangan secara keseluruhan harus:
dikurangi. Lebih sedikit komponen perangkat lunak yang perlu ditentukan, dirancang, diimplementasikan,
dan divalidasi. Namun, pengurangan biaya hanya satu keuntungan dari penggunaan kembali. Pada Gambar 16.1,
Saya telah membuat daftar keuntungan lain dari menggunakan kembali aset perangkat lunak.
Namun, ada biaya dan masalah yang terkait dengan penggunaan kembali (Gambar 16.2). Di sana
adalah biaya signifikan yang terkait dengan pemahaman apakah suatu komponen
cocok untuk digunakan kembali dalam situasi tertentu, dan dalam pengujian komponen tersebut untuk memastikan
keteguhan. Biaya tambahan ini berarti bahwa pengurangan biaya pengembangan secara keseluruhan melalui
penggunaan kembali mungkin kurang dari yang diantisipasi.
Seperti yang saya bahas di Bab 2, proses pengembangan perangkat lunak harus disesuaikan
untuk mempertimbangkan penggunaan kembali. Secara khusus, harus ada penyempurnaan persyaratan
tahap di mana persyaratan untuk sistem dimodifikasi untuk mencerminkan perangkat lunak yang dapat digunakan
kembali yang tersedia. Tahap desain dan implementasi sistem juga dapat:
termasuk kegiatan eksplisit untuk mencari dan mengevaluasi komponen kandidat untuk digunakan kembali.
Penggunaan kembali perangkat lunak paling efektif bila direncanakan sebagai bagian dari seluruh organisasi
program penggunaan kembali. Program penggunaan kembali melibatkan pembuatan aset yang dapat digunakan kembali dan
adaptasi proses pengembangan untuk memasukkan aset ini ke dalam perangkat lunak baru.
Pentingnya perencanaan penggunaan kembali telah diakui selama bertahun-tahun di Jepang
(Matsumoto, 1984), di mana penggunaan kembali merupakan bagian integral dari pendekatan 'pabrik' Jepang
Masalah Penjelasan
Peningkatan biaya perawatan Jika kode sumber dari sistem atau komponen perangkat lunak yang digunakan kembali
tidak tersedia, maka biaya pemeliharaan mungkin lebih tinggi karena elemen sistem yang
digunakan kembali dapat menjadi semakin tidak sesuai dengan perubahan sistem.
Kurangnya dukungan alat Beberapa perangkat lunak tidak mendukung pengembangan dengan penggunaan
kembali. Mungkin sulit atau tidak mungkin untuk mengintegrasikan alat-alat ini dengan
sistem perpustakaan komponen. Proses perangkat lunak yang diasumsikan oleh alat-
alat ini mungkin tidak memperhitungkan penggunaan kembali. Hal ini terutama berlaku
untuk alat yang mendukung rekayasa sistem tertanam, kurang untuk alat pengembangan berorientasi objek.
Sindrom yang tidak ditemukan di sini Beberapa insinyur perangkat lunak lebih suka menulis ulang komponen karena
mereka yakin dapat memperbaikinya. Ini sebagian berkaitan dengan kepercayaan dan
sebagian berkaitan dengan fakta bahwa menulis perangkat lunak asli dipandang lebih
menantang daripada menggunakan kembali perangkat lunak orang lain.
Membuat, memelihara, dan Mengisi pustaka komponen yang dapat digunakan kembali dan memastikan
menggunakan pustaka komponen pengembang perangkat lunak dapat menggunakan pustaka ini bisa jadi mahal. Proses
pengembangan harus disesuaikan untuk memastikan bahwa perpustakaan digunakan.
Menemukan, memahami, dan Komponen perangkat lunak harus ditemukan di perpustakaan, dipahami dan, kadang-
mengadaptasi komponen yang dapat kadang, disesuaikan untuk bekerja di lingkungan baru. Insinyur harus cukup yakin
digunakan kembali menemukan komponen di perpustakaan sebelum mereka memasukkan pencarian
komponen sebagai bagian dari proses pengembangan normal mereka.
untuk pengembangan perangkat lunak (Cusamano, 1989). Perusahaan seperti Hewlett-Packard juga sangat
Gambar 16.2 Masalah dengan
penggunaan kembali berhasil dalam program penggunaan kembali mereka (Griss dan Wosser, 1995), dan pengalaman mereka telah
didokumentasikan dalam sebuah buku oleh Jacobson et al. (1997).
16.1 Lanskap penggunaan kembali
Selama 20 tahun terakhir, banyak teknik telah dikembangkan untuk mendukung penggunaan kembali
perangkat lunak. Teknik ini memanfaatkan fakta bahwa sistem dalam domain aplikasi yang sama serupa dan
memiliki potensi untuk digunakan kembali; bahwa penggunaan kembali dimungkinkan pada tingkat yang
berbeda dari fungsi sederhana hingga aplikasi yang lengkap; dan bahwa standar untuk komponen yang dapat
digunakan kembali memfasilitasi penggunaan kembali. Gambar 16.3 menjelaskan sejumlah cara yang mungkin
untuk mengimplementasikan penggunaan kembali perangkat lunak, dengan masing-masing dijelaskan secara singkat pada Gambar 16.4.
Mengingat susunan teknik untuk digunakan kembali ini, pertanyaan kuncinya adalah “teknik mana yang
paling tepat untuk digunakan dalam situasi tertentu?” Jelas, ini tergantung pada persyaratan untuk sistem
yang sedang dikembangkan, teknologi dan aset yang dapat digunakan kembali yang tersedia, dan keahlian
tim pengembangan. Faktor kunci yang harus Anda pertimbangkan saat merencanakan penggunaan kembali
adalah:
1. Jadwal pengembangan perangkat lunak Jika perangkat lunak harus dikembangkan dengan cepat, Anda
harus mencoba menggunakan kembali sistem yang sudah ada daripada komponen individual. Ini adalah
aset besar yang dapat digunakan kembali. Meskipun cocok untuk
16.1 Lanskap penggunaan kembali 429
Rancangan Arsitektur
Pola Pola
Aplikasi Produk Perangkat Lunak tempat tidur bayi

Sistem ERP
Kerangka kerja Garis Integrasi
Vertikal yang Dapat Dikonfigurasi Sistem Warisan

Aplikasi Pembungkus
Berbasis Komponen Berbasis Model Berorientasi Layanan

Rekayasa Perangkat Lunak Rekayasa Sistem
Berorientasi pada aspek Program Program

Pengembangan perangkat lunak Generator Perpustakaan
Gambar 16.3 Lanskap

penggunaan kembali
persyaratan mungkin tidak sempurna, pendekatan ini meminimalkan jumlah

pengembangan yang diperlukan.
2. Masa pakai perangkat lunak yang diharapkan Jika Anda mengembangkan sistem yang
tahan lama, Anda harus fokus pada pemeliharaan sistem. Anda seharusnya tidak hanya
memikirkan manfaat langsung dari penggunaan kembali tetapi juga implikasi jangka panjangnya.
Selama masa pakainya, Anda harus menyesuaikan sistem dengan persyaratan baru,
yang berarti membuat perubahan pada bagian-bagian sistem. Jika Anda tidak memiliki
akses ke kode sumber, Anda mungkin memilih untuk menghindari komponen dan sistem
yang tersedia dari pemasok eksternal; pemasok mungkin tidak dapat melanjutkan
dukungan untuk perangkat lunak yang digunakan kembali.
3. Latar belakang, keterampilan, dan pengalaman tim pengembangan Semua teknologi reuse
cukup kompleks dan Anda memerlukan cukup banyak waktu untuk memahami dan
menggunakannya secara efektif. Oleh karena itu, jika tim pengembangan memiliki
keterampilan di bidang tertentu, mungkin di sinilah Anda harus fokus.
4. Kekritisan perangkat lunak dan persyaratan non-fungsionalnya Untuk sistem kritis yang
harus disertifikasi oleh regulator eksternal, Anda mungkin harus membuat kasus
ketergantungan untuk sistem (dibahas dalam Bab 15). Ini sulit jika Anda tidak memiliki
akses ke kode sumber perangkat lunak. Jika perangkat lunak Anda memiliki persyaratan
kinerja yang ketat, mungkin tidak mungkin untuk menggunakan strategi seperti
penggunaan kembali berbasis generator, di mana Anda menghasilkan kode dari
representasi khusus domain yang dapat digunakan kembali dari suatu sistem. Sistem ini
sering menghasilkan kode yang relatif tidak efisien.
5. Domain aplikasi Dalam beberapa domain aplikasi, seperti manufaktur dan sistem informasi
medis, ada beberapa produk generik yang dapat digunakan kembali dengan
mengonfigurasinya ke situasi lokal. Jika Anda bekerja di domain seperti itu, Anda harus
selalu mempertimbangkan ini sebagai opsi.
Mendekati Keterangan
Pola arsitektur Arsitektur perangkat lunak standar yang mendukung jenis umum
sistem aplikasi digunakan sebagai dasar aplikasi.
Dijelaskan dalam Bab 6, 13, dan Bab 20.
Pola desain Abstraksi umum yang terjadi di seluruh aplikasi adalah

direpresentasikan sebagai pola desain yang menunjukkan abstrak dan konkret
objek dan interaksi. Dijelaskan dalam Bab 7.
Pengembangan berbasis komponen Sistem dikembangkan dengan mengintegrasikan komponen (kumpulan

objek) yang sesuai dengan standar model komponen. Dijelaskan
di Bab 17.
Kerangka kerja aplikasi Koleksi kelas abstrak dan konkret diadaptasi dan
diperluas untuk membuat sistem aplikasi.
Pembungkus sistem lama Sistem lama (lihat Bab 9) 'dibungkus' dengan mendefinisikan satu set
antarmuka dan menyediakan akses ke sistem warisan ini
melalui antarmuka ini.
Sistem berorientasi layanan Sistem dikembangkan dengan menghubungkan layanan bersama, yang mungkin
disediakan secara eksternal. Dijelaskan dalam Bab 19.
Lini produk perangkat lunak Jenis aplikasi digeneralisasi di sekitar arsitektur umum
sehingga dapat disesuaikan untuk pelanggan yang berbeda.
Penggunaan kembali produk COTS Sistem dikembangkan dengan mengkonfigurasi dan mengintegrasikan yang sudah ada
sistem aplikasi.
sistem ERP Sistem skala besar yang merangkum bisnis generik

fungsionalitas dan aturan dikonfigurasi untuk organisasi.
Aplikasi vertikal yang dapat dikonfigurasi Sistem generik dirancang sedemikian rupa sehingga dapat dikonfigurasi untuk
kebutuhan pelanggan sistem tertentu.
Pustaka program Pustaka kelas dan fungsi yang mengimplementasikan yang umum digunakan
abstraksi tersedia untuk digunakan kembali.
Rekayasa berbasis model Perangkat lunak direpresentasikan sebagai model domain dan implementasi
model dan kode independen dihasilkan dari model ini.
Dijelaskan dalam Bab 5.
Pembangkit program Sistem generator menanamkan pengetahuan tentang jenis aplikasi

dan digunakan untuk menghasilkan sistem dalam domain tersebut dari
model sistem yang disediakan pengguna.
Pengembangan perangkat lunak berorientasi aspek Komponen bersama dijalin menjadi aplikasi di berbagai
tempat ketika program dikompilasi. Dijelaskan dalam Bab 21.
6. Platform di mana sistem akan menjalankan Beberapa model komponen, seperti:

Gambar 16.4
.NET, khusus untuk platform Microsoft. Demikian pula, sistem aplikasi generik mungkin khusus
Pendekatan yang
mendukung perangkat lunak platform dan Anda hanya dapat menggunakannya kembali jika Anda
penggunaan kembali
sistem dirancang untuk platform yang sama.
16.2 Kerangka kerja aplikasi 431
Penggunaan kembali berbasis generator
Penggunaan kembali berbasis generator melibatkan penggabungan konsep dan pengetahuan yang dapat digunakan kembali ke dalam alat otomatis dan
menyediakan cara mudah bagi pengguna alat untuk mengintegrasikan kode tertentu dengan pengetahuan umum ini. Pendekatan ini adalah
biasanya paling efektif dalam aplikasi khusus domain. Solusi yang diketahui untuk masalah dalam domain itu adalah
tertanam dalam sistem generator dan dipilih oleh pengguna untuk membuat sistem baru.
http://www.SoftwareEngineering-9.com/Web/Reuse/Generator.html
Kisaran teknik penggunaan kembali yang tersedia sedemikian rupa sehingga, dalam kebanyakan situasi, ada:
kemungkinan penggunaan kembali beberapa perangkat lunak. Apakah penggunaan kembali tercapai atau tidak sering kali
manajerial daripada masalah teknis. Manajer mungkin tidak mau berkompromi

persyaratan mereka untuk memungkinkan komponen yang dapat digunakan kembali untuk digunakan.
Mereka mungkin tidak memahami risiko yang terkait dengan penggunaan kembali serta mereka memahami risiko asli
perkembangan. Meskipun risiko pengembangan perangkat lunak baru mungkin lebih tinggi, beberapa
manajer mungkin lebih memilih risiko yang diketahui daripada risiko yang tidak diketahui.
16.2 Kerangka aplikasi
Penggemar awal untuk pengembangan berorientasi objek menyarankan bahwa salah satu kuncinya:
manfaat menggunakan pendekatan berorientasi objek adalah bahwa objek dapat digunakan kembali
dalam sistem yang berbeda. Namun, pengalaman telah menunjukkan bahwa objek seringkali terlalu kecil dan
khusus untuk aplikasi tertentu. Butuh waktu lebih lama untuk memahami dan beradaptasi
objek daripada mengimplementasikannya kembali. Sekarang menjadi jelas bahwa penggunaan kembali berorientasi objek
paling baik didukung dalam proses pengembangan berorientasi objek melalui butiran yang lebih besar
abstraksi yang disebut framework.
Seperti namanya, kerangka kerja adalah struktur generik yang diperluas untuk membuat subsistem
atau aplikasi yang lebih spesifik. Schmidt dkk. (2004) mendefinisikan kerangka kerja menjadi:
“. . . seperangkat artefak perangkat lunak yang terintegrasi (seperti kelas, objek, dan komponen)
yang berkolaborasi untuk menyediakan arsitektur yang dapat digunakan kembali untuk keluarga perangkat lunak.
aplikasi terkait.”
Kerangka kerja memberikan dukungan untuk fitur umum yang kemungkinan besar akan digunakan di semua
aplikasi sejenis. Misalnya, kerangka kerja antarmuka pengguna akan menyediakan
dukungan untuk penanganan acara antarmuka dan akan menyertakan satu set widget yang dapat digunakan
untuk membangun tampilan. Kemudian diserahkan kepada pengembang untuk mengkhususkan ini dengan menambahkan
fungsionalitas khusus untuk aplikasi tertentu. Misalnya, dalam antarmuka pengguna

framework, developer mendefinisikan layout tampilan yang sesuai dengan aplikasi yang sedang
diimplementasikan.
Kerangka mendukung penggunaan kembali desain karena mereka menyediakan arsitektur kerangka untuk
aplikasi serta penggunaan kembali kelas tertentu dalam sistem. Arsitektur
Pengguna Status Pengendali Lihat Modifikasi Lihat Status

Masukan Pesan
Metode Pengontrol Lihat Metode
Model Pertanyaan dan

Suntingan Status Model
Pembaruan Model
Gambar 16.5 Model-

View-Controller Metode Model
pola
didefinisikan oleh kelas objek dan interaksinya. Kelas digunakan kembali secara
langsung dan dapat diperluas menggunakan fitur seperti pewarisan.
Kerangka diimplementasikan sebagai kumpulan kelas objek konkret dan abstrak
dalam bahasa pemrograman berorientasi objek. Oleh karena itu, kerangka kerja
bersifat khusus bahasa. Ada kerangka kerja yang tersedia di semua bahasa
pemrograman berorientasi objek yang umum digunakan (misalnya, Java, C#, C++,
serta bahasa dinamis seperti Ruby dan Python). Bahkan, sebuah kerangka kerja dapat
menggabungkan beberapa kerangka kerja lain, di mana masing-masing kerangka
tersebut dirancang untuk mendukung pengembangan bagian dari aplikasi. Anda dapat
menggunakan kerangka kerja untuk membuat aplikasi lengkap atau mengimplementasikan bagian dari aplikasi, s
Fayad dan Schmidt (1997) membahas tiga kelas kerangka kerja:
1. Kerangka kerja infrastruktur sistem Kerangka kerja ini mendukung pengembangan

infrastruktur sistem seperti komunikasi, antarmuka pengguna, dan kompiler
(Schmidt, 1997).
2. Kerangka integrasi middleware Ini terdiri dari seperangkat standar dan kelas objek
terkait yang mendukung komunikasi komponen dan pertukaran informasi. Contoh
kerangka kerja jenis ini termasuk Microsoft .NET dan Enterprise Java Beans
(EJB). Kerangka kerja ini memberikan dukungan untuk model komponen standar,
seperti yang dibahas dalam Bab 17.
3. Kerangka aplikasi perusahaan Ini berkaitan dengan domain aplikasi tertentu seperti
telekomunikasi atau sistem keuangan (Baumer, et al., 1997). Ini menanamkan
pengetahuan domain aplikasi dan mendukung pengembangan aplikasi pengguna
akhir.
Kerangka kerja aplikasi web (WAF) adalah jenis kerangka kerja yang lebih baru dan
sangat penting. WAF yang mendukung pembangunan situs web dinamis sekarang
tersedia secara luas. Arsitektur WAF biasanya didasarkan pada pola komposit Model-
View Controller (MVC) (Gamma et al., 1995), ditunjukkan pada Gambar 16.5.
Pola MVC awalnya diusulkan pada 1980-an sebagai pendekatan desain GUI yang
memungkinkan beberapa presentasi objek dan gaya interaksi terpisah dengan masing-
masing presentasi ini. Ini memungkinkan pemisahan aplikasi
16.2 Kerangka kerja aplikasi 433
status dari antarmuka pengguna ke aplikasi. Kerangka kerja MVC mendukung penyajian data
dengan cara yang berbeda dan memungkinkan interaksi dengan masing-masing presentasi ini.
Ketika data dimodifikasi melalui salah satu presentasi, model sistem diubah dan pengontrol yang
terkait dengan setiap tampilan memperbarui presentasi mereka.
Kerangka kerja sering kali merupakan implementasi dari pola desain, seperti yang dibahas
dalam Bab 7. Misalnya, kerangka kerja MVC mencakup pola Pengamat, pola Strategi, pola
Komposit, dan sejumlah lainnya yang dibahas oleh Gamma et al. (1995). Sifat umum dari pola dan
penggunaan kelas abstrak dan konkret memungkinkan untuk diperpanjang. Tanpa pola, kerangka
kerja hampir pasti tidak praktis.
Kerangka kerja aplikasi web biasanya menggabungkan satu atau lebih kerangka kerja khusus
yang mendukung fitur aplikasi tertentu. Meskipun setiap kerangka memiliki fungsionalitas yang
sedikit berbeda, sebagian besar kerangka kerja aplikasi web mendukung fitur-fitur berikut:
1. WAF Keamanan dapat menyertakan kelas untuk membantu mengimplementasikan otentikasi

pengguna (login) dan kontrol akses untuk memastikan bahwa pengguna hanya dapat
mengakses fungsi yang diizinkan dalam sistem.
2. Halaman web dinamis Kelas disediakan untuk membantu Anda menentukan templat halaman
web dan untuk mengisinya secara dinamis dengan data spesifik dari database sistem.
3. Database support Frameworks biasanya tidak menyertakan database, melainkan mengasumsikan

bahwa database yang terpisah, seperti MySQL, akan digunakan. Kerangka kerja dapat
menyediakan kelas yang menyediakan antarmuka abstrak ke database yang berbeda.
4. Manajemen sesi Kelas untuk membuat dan mengelola sesi (sejumlah interaksi dengan sistem
oleh pengguna) biasanya merupakan bagian dari WAF.
5. Interaksi pengguna Sebagian besar kerangka kerja web sekarang menyediakan dukungan AJAX
(Holdener, 2008), yang memungkinkan lebih banyak halaman web interaktif dibuat.
Untuk memperluas kerangka kerja, Anda tidak mengubah kode kerangka kerja. Sebaliknya,
Anda menambahkan kelas konkret yang mewarisi operasi dari kelas abstrak dalam kerangka
kerja. Selain itu, Anda mungkin harus menentukan panggilan balik. Callback adalah metode yang
dipanggil sebagai respons terhadap peristiwa yang dikenali oleh framework. Schmidt dkk. (2004)
menyebutnya 'inversi kontrol'. Objek kerangka kerja, bukan objek khusus aplikasi, bertanggung
jawab untuk kontrol dalam sistem. Menanggapi peristiwa dari antarmuka pengguna, database,
dll., objek kerangka kerja ini memanggil 'metode kait' yang kemudian ditautkan ke fungsionalitas
yang disediakan pengguna. Fungsionalitas khusus aplikasi merespons kejadian dengan cara
yang tepat (Gambar 16.6). Misalnya, kerangka kerja akan memiliki metode yang menangani klik
mouse dari lingkungan. Metode ini
memanggil metode kait, yang harus Anda konfigurasikan untuk memanggil metode aplikasi yang
sesuai untuk menangani klik mouse.
Aplikasi yang dibangun menggunakan kerangka kerja dapat menjadi dasar untuk digunakan
kembali lebih lanjut melalui konsep lini produk perangkat lunak atau keluarga aplikasi. Karena
aplikasi ini dibangun menggunakan kerangka kerja, memodifikasi anggota keluarga untuk
Peristiwa
GUI
Lingkaran
Panggilan balik
Kelas Khusus Aplikasi
Panggilan balik Panggilan balik
Peristiwa Peristiwa
Basis data Platform
Gambar 16.6 Pembalikan kontrol Lingkaran Lingkaran
dalam kerangka kerja
membuat instance dari sistem seringkali merupakan proses yang mudah. Ini melibatkan penulisan
ulang kelas dan metode konkret yang telah Anda tambahkan ke kerangka kerja.
Namun, kerangka kerja biasanya lebih umum daripada lini produk perangkat lunak, yang berfokus
pada keluarga sistem aplikasi tertentu. Misalnya, Anda dapat menggunakan kerangka kerja berbasis
web untuk membangun berbagai jenis aplikasi berbasis web. Salah satunya mungkin lini produk
perangkat lunak yang mendukung meja bantuan berbasis web. 'Lini produk help desk' ini kemudian
dapat dispesialisasikan lebih lanjut untuk menyediakan jenis dukungan help desk tertentu.
Kerangka kerja adalah pendekatan yang efektif untuk digunakan kembali, tetapi mahal untuk
dimasukkan ke dalam proses pengembangan perangkat lunak. Mereka secara inheren kompleks dan
dapat memakan waktu beberapa bulan untuk belajar menggunakannya. Mungkin sulit dan mahal untuk
mengevaluasi kerangka kerja yang tersedia untuk memilih yang paling tepat. Men-debug aplikasi
berbasis kerangka kerja sulit karena Anda mungkin tidak mengerti bagaimana metode kerangka kerja
berinteraksi. Ini adalah masalah umum dengan perangkat lunak yang dapat digunakan kembali. Alat
debugging dapat memberikan informasi tentang komponen sistem yang digunakan kembali, yang tidak
dipahami oleh pengembang.
16.3 Lini produk perangkat lunak
Salah satu pendekatan yang paling efektif untuk menggunakan kembali adalah untuk membuat lini
produk perangkat lunak atau keluarga aplikasi. Lini produk perangkat lunak adalah seperangkat
aplikasi dengan arsitektur umum dan komponen bersama, dengan setiap aplikasi khusus untuk
mencerminkan kebutuhan yang berbeda. Sistem inti dirancang untuk dikonfigurasi dan disesuaikan
agar sesuai dengan kebutuhan pelanggan sistem yang berbeda. Ini mungkin melibatkan konfigurasi
beberapa komponen, mengimplementasikan komponen tambahan, dan memodifikasi beberapa
komponen untuk mencerminkan persyaratan baru.
16.3 Lini produk perangkat lunak 435
Mengembangkan aplikasi dengan mengadaptasi versi generik aplikasi berarti bahwa sebagian
besar kode aplikasi digunakan kembali. Selain itu, pengalaman aplikasi sering kali dapat
ditransfer dari satu sistem ke sistem lainnya. Akibatnya, ketika insinyur perangkat lunak
bergabung dengan tim pengembangan, proses pembelajaran mereka dipersingkat.
Pengujian disederhanakan karena pengujian untuk sebagian besar aplikasi juga dapat digunakan
kembali, sehingga mengurangi waktu pengembangan aplikasi secara keseluruhan.
Lini produk perangkat lunak biasanya muncul dari aplikasi yang sudah ada. Artinya, sebuah
organisasi mengembangkan aplikasi kemudian, ketika sistem serupa diperlukan, informasi
menggunakan kembali kode dari ini di aplikasi baru. Proses yang sama digunakan saat aplikasi
serupa lainnya dikembangkan. Namun, perubahan cenderung merusak struktur aplikasi sehingga,
semakin banyak instance baru dikembangkan, semakin sulit untuk membuat versi baru.
Akibatnya, keputusan untuk merancang lini produk generik kemudian dapat dibuat. Ini melibatkan
pengidentifikasian fungsionalitas umum dalam instans produk dan memasukkannya ke dalam
aplikasi dasar, yang kemudian digunakan untuk pengembangan di masa mendatang.
Aplikasi dasar ini sengaja disusun untuk menyederhanakan penggunaan kembali dan konfigurasi ulang.
Kerangka kerja aplikasi dan lini produk perangkat lunak jelas memiliki banyak kesamaan.
Keduanya mendukung arsitektur dan komponen umum, dan memerlukan pengembangan baru
untuk membuat versi sistem tertentu. Perbedaan utama antara pendekatan ini adalah sebagai
berikut:
1. Kerangka kerja aplikasi mengandalkan fitur berorientasi objek seperti pewarisan dan
polimorfisme untuk mengimplementasikan ekstensi ke kerangka kerja. Umumnya, kode
kerangka kerja tidak dimodifikasi dan kemungkinan modifikasi terbatas pada apa pun yang
diizinkan oleh kerangka kerja. Lini produk perangkat lunak tidak harus dibuat menggunakan
pendekatan berorientasi objek. Komponen aplikasi diubah, dihapus, atau ditulis ulang.
Tidak ada batasan, setidaknya pada prinsipnya, untuk perubahan yang dapat dilakukan.
2. Kerangka kerja aplikasi terutama berfokus pada penyediaan dukungan teknis daripada khusus
domain. Misalnya, terdapat framework aplikasi untuk membuat aplikasi berbasis web. Lini
produk perangkat lunak biasanya menyematkan domain dan informasi platform yang
terperinci. Misalnya, mungkin ada lini produk perangkat lunak yang berkaitan dengan
aplikasi berbasis web untuk manajemen catatan kesehatan.
3. Lini produk perangkat lunak sering kali merupakan aplikasi kontrol untuk peralatan. Misalnya,
mungkin ada lini produk perangkat lunak untuk keluarga printer. Ini berarti bahwa lini
produk harus menyediakan dukungan untuk antarmuka perangkat keras.
Kerangka kerja aplikasi biasanya berorientasi pada perangkat lunak dan jarang memberikan
dukungan untuk antarmuka perangkat keras.
4. Lini produk perangkat lunak terdiri dari keluarga aplikasi terkait, yang dimiliki oleh organisasi
yang sama. Saat Anda membuat aplikasi baru, titik awal Anda sering kali adalah anggota
terdekat dari keluarga aplikasi, bukan aplikasi inti generik.
Jika Anda mengembangkan lini produk perangkat lunak menggunakan bahasa pemrograman
berorientasi objek, maka Anda dapat menggunakan kerangka kerja aplikasi sebagai dasar sistem.
Anda membuat inti dari lini produk dengan memperluas kerangka kerja dengan domain-spesifik
komponen menggunakan mekanisme bawaannya. Kemudian ada fase pengembangan

kedua di mana versi sistem untuk pelanggan yang berbeda dibuat.
Berbagai jenis spesialisasi lini produk perangkat lunak dapat dikembangkan:
1. Spesialisasi platform Versi aplikasi dikembangkan untuk platform yang berbeda.

Misalnya, versi aplikasi mungkin ada untuk platform Windows, Mac OS, dan
Linux. Dalam hal ini, fungsionalitas aplikasi biasanya tidak berubah; hanya
komponen yang berinteraksi dengan perangkat keras dan sistem operasi yang
dimodifikasi.
2. Spesialisasi lingkungan Versi aplikasi dibuat untuk menangani lingkungan operasi

dan perangkat periferal tertentu. Misalnya, sistem untuk layanan darurat mungkin
ada dalam versi yang berbeda, tergantung pada sistem komunikasi kendaraan.
Dalam hal ini, komponen sistem diubah untuk mencerminkan fungsionalitas
peralatan komunikasi yang digunakan.
3. Spesialisasi Fungsional Versi aplikasi dibuat untuk pelanggan tertentu yang

memiliki kebutuhan berbeda. Misalnya, sistem otomatisasi perpustakaan dapat
dimodifikasi tergantung pada apakah digunakan di perpustakaan umum,
perpustakaan referensi, atau perpustakaan universitas. Dalam hal ini, komponen
yang mengimplementasikan fungsionalitas dapat dimodifikasi dan komponen baru ditambahkan ke sistem.
4. Spesialisasi proses Sistem ini disesuaikan untuk mengatasi proses bisnis tertentu.
Misalnya, sistem pemesanan dapat disesuaikan untuk mengatasi proses
pemesanan terpusat di satu perusahaan dan proses terdistribusi di perusahaan lain.
Arsitektur lini produk perangkat lunak sering kali mencerminkan gaya atau pola
arsitektur khusus aplikasi. Misalnya, pertimbangkan sistem lini produk yang dirancang
untuk menangani pengiriman kendaraan untuk layanan darurat. Operator sistem ini
menerima panggilan tentang insiden, menemukan kendaraan yang sesuai untuk
menanggapi insiden tersebut dan mengirimkan kendaraan ke lokasi kejadian.
Pengembang sistem semacam itu dapat memasarkan versi ini untuk layanan polisi,
pemadam kebakaran, dan ambulans.
Sistem pengiriman kendaraan ini adalah contoh dari arsitektur manajemen sumber
daya (Gambar 16.7). Anda dapat melihat bagaimana struktur empat lapis ini dibuat
pada Gambar 16.8, yang menunjukkan modul yang mungkin disertakan dalam lini
produk sistem pengiriman kendaraan. Komponen-komponen pada setiap level dalam
sistem lini produk adalah sebagai berikut:
1. Pada tingkat interaksi, terdapat komponen yang menyediakan antarmuka tampilan

operator dan antarmuka dengan sistem komunikasi yang digunakan.
2. Pada level manajemen I/O (level 2), terdapat komponen yang menangani otentikasi
operator, menghasilkan laporan insiden dan kendaraan yang dikirim, mendukung
output peta dan perencanaan rute, dan menyediakan mekanisme bagi operator
untuk meng-query database sistem.
Interaksi
Antarmuka pengguna
Manajemen I/O
Pengguna Sumber Pertanyaan

Autentikasi Pengiriman Pengelolaan
Pengelolaan sumber daya
Sumber Kebijakan Sumber Daya Sumber

Pelacakan Kontrol Alokasi
Manajemen Basis Data
Gambar 16.7
Arsitektur alokasi Pengelolaan transaksi
sumber daya Basis Data Sumber Daya
sistem
Sistem Komunikasi
Antarmuka Operator Antarmuka
Operator Peta dan Rute Laporan Pertanyaan

Autentikasi Perencana Generator Pengelola
Status Kendaraan Kejadian Kendaraan Peralatan Kendaraan
Pengelola Pencatat Orang yg memberangkatkan Pengelola pencari lokasi
Pengelolaan transaksi Catatan Insiden

Peralatan
Gambar 16.8
Basis data
Arsitektur lini produk dari Basis Data Kendaraan Basis Data Peta
sistem operator kendaraan
3. Pada tingkat manajemen sumber daya (tingkat 3) ada komponen yang

memungkinkan kendaraan ditempatkan dan dikirim, komponen untuk
memperbarui status kendaraan dan peralatan, dan komponen untuk mencatat rincian insiden.
4. Pada tingkat basis data, serta dukungan manajemen transaksi biasa, terdapat
basis data kendaraan, peralatan, dan peta yang terpisah.
Negosiasi ulang
Persyaratan
Memperoleh Memilih
Pemangku Kepentingan Paling-Fit
Persyaratan Contoh Sistem
Sesuaikan yang Ada Kirim Baru
Sistem Contoh Sistem
Untuk membuat versi tertentu dari sistem ini, Anda mungkin harus memodifikasi komponen
Gambar 16.9
Pengembangan instans produk
individual. Misalnya, polisi memiliki jumlah kendaraan yang banyak tetapi jenis kendaraannya sedikit,
sedangkan dinas pemadam kebakaran memiliki banyak jenis kendaraan khusus. Oleh karena itu, Anda
mungkin harus menentukan struktur database kendaraan yang berbeda saat menerapkan sistem untuk
layanan yang berbeda ini.
Gambar 16.9 menunjukkan langkah-langkah yang terlibat dalam memperluas lini produk perangkat lunak untuk menciptakan
makan aplikasi baru. Langkah-langkah yang terlibat dalam proses umum ini adalah sebagai berikut:
1. Dapatkan persyaratan pemangku kepentingan Anda dapat memulai dengan proses rekayasa
persyaratan normal. Namun, karena sistem sudah ada, Anda perlu mendemonstrasikan sistem
dan meminta pemangku kepentingan bereksperimen dengannya, menyatakan persyaratan mereka
sebagai modifikasi fungsi yang disediakan.
2. Pilih sistem yang ada yang paling sesuai dengan persyaratan Saat membuat anggota baru dari lini
produk, Anda dapat memulai dengan instans produk terdekat. Persyaratan dianalisis dan anggota
keluarga yang paling cocok dipilih untuk dimodifikasi.
3. Negosiasi ulang persyaratan Ketika lebih banyak rincian perubahan yang diperlukan muncul dan
proyek direncanakan, mungkin ada beberapa persyaratan negosiasi ulang untuk meminimalkan
perubahan yang diperlukan.
4. Menyesuaikan sistem yang ada Modul baru dikembangkan untuk sistem yang ada dan modul sistem
yang ada disesuaikan untuk memenuhi persyaratan baru.
5. Mengirimkan anggota keluarga baru Instance baru dari lini produk dikirimkan ke pelanggan. Pada
tahap ini, Anda harus mendokumentasikan fitur-fitur utamanya sehingga dapat digunakan sebagai
dasar untuk pengembangan sistem lainnya di masa mendatang.
Saat Anda membuat anggota baru lini produk, Anda mungkin harus menemukan kompromi antara
menggunakan kembali sebanyak mungkin aplikasi generik dan memenuhi persyaratan pemangku
kepentingan yang terperinci. Semakin rinci persyaratan sistem, semakin kecil kemungkinan komponen
yang ada akan memenuhi persyaratan ini. Namun, jika pemangku kepentingan bersedia untuk fleksibel
dan membatasi modifikasi sistem yang diperlukan, Anda biasanya dapat mengirimkan sistem lebih
cepat dan dengan biaya lebih rendah.
Lini produk perangkat lunak dirancang untuk dikonfigurasi ulang dan konfigurasi ulang ini mungkin
melibatkan penambahan atau penghapusan komponen dari sistem, mendefinisikan parameter dan
batasan untuk komponen sistem, dan termasuk pengetahuan bisnis.
Konfigurasi
Alat Perencanaan
Sistem Umum
Konfigurasi
Basis data
Gambar 16.10
Basis Data Sistem
Konfigurasi waktu
penerapan
proses. Konfigurasi ini dapat terjadi pada tahap yang berbeda dalam pengembangan
proses:
1. Konfigurasi desain-waktu Organisasi yang mengembangkan perangkat lunak

memodifikasi inti lini produk umum dengan mengembangkan, memilih, atau
mengadaptasi komponen untuk membuat sistem baru bagi pelanggan.
2. Konfigurasi waktu penyebaran Sebuah sistem generik dirancang untuk konfigurasi oleh
pelanggan atau konsultan yang bekerja dengan pelanggan. Pengetahuan tentang
kebutuhan spesifik pelanggan dan lingkungan operasi sistem tertanam dalam satu
set file konfigurasi yang digunakan oleh sistem generik.
Ketika sebuah sistem dikonfigurasi pada waktu desain, pemasok memulai dengan
sistem generik atau instans produk yang sudah ada. Dengan memodifikasi dan memperluas
modul dalam sistem ini, mereka menciptakan sistem khusus yang memberikan
fungsionalitas pelanggan yang diperlukan. Ini biasanya melibatkan perubahan dan
perluasan kode sumber sistem sehingga fleksibilitas yang lebih besar dimungkinkan dibandingkan dengan konfig
Konfigurasi Deployment-time melibatkan penggunaan alat konfigurasi untuk membuat
konfigurasi sistem tertentu yang direkam dalam database konfigurasi atau sebagai satu
set file konfigurasi (Gambar 16.10). Sistem pelaksana berkonsultasi dengan database ini
saat mengeksekusi sehingga fungsinya dapat dikhususkan untuk konteks eksekusinya.
Ada beberapa tingkat konfigurasi waktu penyebaran yang mungkin disediakan dalam
suatu sistem:
1. Pemilihan komponen, di mana Anda memilih modul dalam sistem yang menyediakan
fungsionalitas yang diperlukan. Misalnya, dalam sistem informasi pasien, Anda dapat
memilih komponen manajemen citra yang memungkinkan Anda untuk menautkan
citra medis (rontgen, CT scan, dll.) ke rekam medis pasien.
2. Alur kerja dan definisi aturan, di mana Anda menentukan alur kerja (bagaimana informasi
diproses, tahap demi tahap) dan aturan validasi yang harus diterapkan pada informasi
yang dimasukkan oleh pengguna atau dihasilkan oleh sistem.
3. Definisi parameter, di mana Anda menentukan nilai parameter sistem tertentu yang mencerminkan
instance aplikasi yang Anda buat. Misalnya, Anda dapat menentukan panjang maksimum bidang
untuk input data oleh pengguna atau karakteristik perangkat keras yang terpasang pada sistem.
Konfigurasi waktu penerapan bisa sangat rumit dan mungkin diperlukan waktu berbulan-bulan untuk
mengonfigurasi sistem untuk pelanggan. Sistem besar yang dapat dikonfigurasi dapat mendukung proses
konfigurasi dengan menyediakan alat perangkat lunak, seperti alat perencanaan konfigurasi, untuk
mendukung proses konfigurasi. Saya membahas konfigurasi waktu penerapan lebih lanjut di Bagian 16.4.1.
Ini mencakup penggunaan kembali sistem COTS yang harus dikonfigurasi untuk bekerja di lingkungan
operasional yang berbeda.
Konfigurasi waktu desain digunakan ketika tidak mungkin menggunakan fasilitas konfigurasi waktu
penyebaran yang ada dalam suatu sistem untuk mengembangkan versi sistem baru. Namun, seiring waktu,
ketika Anda telah membuat beberapa anggota keluarga dengan fungsionalitas yang sebanding, Anda dapat
memutuskan untuk memfaktorkan ulang lini produk inti untuk menyertakan fungsionalitas yang telah
diterapkan di beberapa anggota keluarga aplikasi. Anda kemudian membuat fungsionalitas baru itu dapat
dikonfigurasi ketika sistem disebarkan.
16.4 penggunaan kembali produk COTS
Produk komersial-off-the-shelf (COTS) adalah sistem perangkat lunak yang dapat disesuaikan dengan
kebutuhan pelanggan yang berbeda tanpa mengubah kode sumber sistem. Hampir semua perangkat lunak
desktop dan berbagai macam produk server adalah perangkat lunak COTS. Karena perangkat lunak ini
dirancang untuk penggunaan umum, biasanya memiliki banyak fitur dan fungsi. Oleh karena itu memiliki
potensi untuk digunakan kembali di lingkungan yang berbeda dan sebagai bagian dari aplikasi yang berbeda.
Torchiano dan Morisio (2004) juga menemukan bahwa menggunakan produk open source sering digunakan
sebagai produk COTS. Artinya, sistem open source digunakan tanpa perubahan dan tanpa melihat kode
sumbernya.
Produk COTS diadaptasi dengan menggunakan mekanisme konfigurasi built-in yang memungkinkan
fungsionalitas sistem disesuaikan dengan kebutuhan spesifik pelanggan. Misalnya, dalam sistem catatan
pasien rumah sakit, formulir masukan dan laporan keluaran terpisah dapat ditentukan untuk jenis pasien
yang berbeda. Fitur konfigurasi lainnya memungkinkan sistem menerima plug-in yang memperluas
fungsionalitas atau memeriksa input pengguna untuk memastikan validitasnya.
Pendekatan untuk penggunaan kembali perangkat lunak ini telah diadopsi secara luas oleh perusahaan
besar selama 15 tahun terakhir, karena menawarkan manfaat yang signifikan dibandingkan pengembangan
perangkat lunak yang disesuaikan:
1. Seperti jenis penggunaan kembali lainnya, penerapan sistem yang andal mungkin lebih cepat
mungkin.
16.4 Penggunaan kembali produk COTS 441
2. Dimungkinkan untuk melihat fungsionalitas apa yang disediakan oleh aplikasi sehingga lebih
mudah untuk menilai apakah mereka cocok atau tidak. Perusahaan lain mungkin sudah
menggunakan aplikasi sehingga pengalaman sistem tersedia.
3. Beberapa risiko pengembangan dihindari dengan menggunakan perangkat lunak yang ada. Namun, ini
pendekatan memiliki risiko sendiri, seperti yang saya bahas di bawah ini.
4. Bisnis dapat fokus pada aktivitas inti mereka tanpa harus mencurahkan banyak sumber daya
untuk pengembangan sistem TI.
5. Seiring berkembangnya platform operasi, pembaruan teknologi dapat disederhanakan karena

ini adalah tanggung jawab vendor produk COTS daripada pelanggan.
Tentu saja, pendekatan rekayasa perangkat lunak ini memiliki masalah sendiri:
1. Persyaratan biasanya harus disesuaikan untuk mencerminkan fungsionalitas dan mode

pengoperasian produk COTS. Hal ini dapat menyebabkan perubahan yang mengganggu
proses bisnis yang ada.
2. Produk COTS mungkin didasarkan pada asumsi yang secara praktis tidak mungkin diubah.
Oleh karena itu, pelanggan harus menyesuaikan bisnis mereka untuk mencerminkan asumsi
ini.
3. Memilih sistem COTS yang tepat untuk suatu perusahaan dapat menjadi proses yang sulit,
terutama karena banyak produk COTS tidak didokumentasikan dengan baik. Membuat pilihan
yang salah bisa menjadi bencana karena mungkin tidak mungkin membuat sistem baru
bekerja sesuai kebutuhan.
4. Mungkin ada kekurangan keahlian lokal untuk mendukung pengembangan sistem.

Akibatnya, pelanggan harus bergantung pada vendor dan konsultan eksternal untuk saran
pengembangan. Nasihat ini mungkin bias dan diarahkan untuk menjual produk dan layanan,
daripada memenuhi kebutuhan nyata pelanggan.
5. Vendor produk COTS mengontrol dukungan dan evolusi sistem. Mereka mungkin gulung tikar,
diambil alih, atau mungkin membuat perubahan yang menyebabkan kesulitan bagi
pelanggan.
Penggunaan kembali perangkat lunak berdasarkan COTS telah menjadi semakin umum.
Sebagian besar sistem pemrosesan informasi bisnis baru sekarang dibangun menggunakan COTS
daripada menggunakan pendekatan berorientasi objek. Meskipun sering ada masalah dengan
pendekatan ini untuk pengembangan sistem (Tracz, 2001), kisah sukses (Baker, 2002; Balk dan
Kedia, 2000; Brownsword dan Morris, 2003; Pfarr dan Reis, 2002) menunjukkan bahwa penggunaan
kembali berbasis COTS mengurangi upaya dan waktu untuk menerapkan sistem.
Ada dua jenis penggunaan kembali produk COTS, yaitu sistem solusi COTS dan sistem
terintegrasi COTS. Sistem solusi COTS terdiri dari aplikasi generik dari satu vendor yang
dikonfigurasi untuk kebutuhan pelanggan. Sistem terintegrasi COTS melibatkan pengintegrasian
dua atau lebih sistem COTS (mungkin dari
Sistem solusi COTS Sistem terintegrasi COTS
Produk tunggal yang menyediakan fungsionalitas Beberapa produk sistem heterogen adalah:
dibutuhkan oleh pelanggan terintegrasi untuk menyediakan fungsionalitas yang disesuaikan
Berbasis di sekitar solusi umum dan standar Solusi fleksibel dapat dikembangkan untuk pelanggan
proses proses
Fokus pengembangan adalah pada konfigurasi sistem Fokus pengembangan adalah pada integrasi sistem
Vendor sistem bertanggung jawab untuk pemeliharaan Pemilik sistem bertanggung jawab untuk pemeliharaan
Vendor sistem menyediakan platform untuk sistem Pemilik sistem menyediakan platform untuk sistem
vendor) untuk membuat sistem aplikasi. Gambar 16.11 merangkum perbedaan

Gambar 16.11 Solusi
COTS dan sistem antara pendekatan yang berbeda ini.
terintegrasi COTS
16.4.1 Sistem solusi COTS

Sistem solusi COTS adalah sistem aplikasi generik yang mungkin dirancang untuk:
mendukung jenis bisnis tertentu, aktivitas bisnis, atau kadang-kadang, lengkap
perusahaan bisnis. Misalnya, sistem solusi COTS dapat diproduksi untuk:
dokter gigi yang menangani janji temu, catatan gigi, penarikan kembali pasien, dll. Pada skala yang lebih besar
skala besar, sistem Enterprise Resource Planning (ERP) dapat mendukung semua aktivitas
manufaktur, pemesanan, dan manajemen hubungan pelanggan dalam skala besar.
perusahaan.
Sistem solusi COTS khusus domain, seperti sistem untuk mendukung bisnis
fungsi (misalnya, manajemen dokumen), menyediakan fungsionalitas yang mungkin
dibutuhkan oleh berbagai pengguna potensial. Namun, mereka juga menggabungkan built-in
asumsi tentang bagaimana pengguna bekerja dan ini dapat menyebabkan masalah dalam
situasi tertentu. Misalnya, sistem untuk mendukung pendaftaran mahasiswa di universitas mungkin
berasumsi bahwa siswa akan terdaftar untuk satu gelar di satu universitas. Namun, jika
universitas berkolaborasi untuk menawarkan gelar bersama, maka itu mungkin hampir tidak mungkin
untuk mewakili ini dalam sistem.
Sistem ERP, seperti yang diproduksi oleh SAP dan BEA, adalah sistem terintegrasi
berskala besar yang dirancang untuk mendukung praktik bisnis seperti pemesanan dan
penagihan, manajemen inventaris, dan penjadwalan manufaktur (O'Leary, 2000). Itu
proses konfigurasi untuk sistem ini melibatkan pengumpulan informasi rinci
tentang bisnis dan proses bisnis pelanggan, dan menyematkannya dalam database
konfigurasi. Ini sering membutuhkan pengetahuan rinci tentang notasi dan alat konfigurasi
dan biasanya dilakukan oleh konsultan yang bekerja bersama sistem
pelanggan.
Sistem ERP generik mencakup sejumlah modul yang dapat disusun

dengan cara yang berbeda untuk membuat sistem untuk pelanggan. Proses konfigurasi
Pembelian Rantai pasokan Logistik CRM
Proses Proses Proses Proses
Peraturan bisnis
Gambar 16.12
Arsitektur sistem ERP Basis Data Sistem
melibatkan pemilihan modul mana yang akan dimasukkan, mengkonfigurasi modul individu ini,
mendefinisikan proses bisnis dan aturan bisnis, dan mendefinisikan struktur dan organisasi
database sistem. Sebuah model arsitektur keseluruhan sistem ERP yang mendukung berbagai
fungsi bisnis ditunjukkan pada Gambar 16.12.
Fitur utama dari arsitektur ini adalah:
1. Sejumlah modul untuk mendukung fungsi bisnis yang berbeda. Ini adalah modul biji-bijian
besar yang dapat mendukung seluruh departemen atau divisi bisnis.
Pada contoh yang ditunjukkan pada Gambar 16.12, modul yang telah dipilih untuk
dimasukkan ke dalam sistem adalah modul untuk mendukung pembelian, modul untuk
mendukung manajemen rantai pasokan, modul logistik untuk mendukung pengiriman
barang, dan manajemen hubungan pelanggan ( CRM) modul untuk menjaga informasi
pelanggan.
2. Serangkaian proses bisnis yang ditentukan, terkait dengan setiap modul, yang berhubungan
dengan aktivitas dalam modul tersebut. Misalnya, mungkin ada definisi proses pemesanan
yang mendefinisikan bagaimana pesanan dibuat dan disetujui. Ini akan menentukan peran
dan aktivitas yang terlibat dalam menempatkan pesanan.
3. Basis data umum yang memelihara informasi tentang semua fungsi bisnis terkait
tion. Ini berarti bahwa tidak perlu mereplikasi informasi, seperti detail pelanggan, di berbagai
bagian bisnis.
4. Seperangkat aturan bisnis yang berlaku untuk semua data dalam database. Oleh karena itu,
ketika data dimasukkan dari satu fungsi, aturan ini harus memastikan bahwa itu konsisten
dengan data yang dibutuhkan oleh fungsi lain. Misalnya, mungkin ada aturan bisnis bahwa
semua klaim pengeluaran harus disetujui oleh seseorang yang lebih senior daripada orang
yang mengajukan klaim.
Sistem ERP digunakan di hampir semua perusahaan besar untuk mendukung sebagian atau
seluruh fungsinya. Oleh karena itu, mereka adalah bentuk penggunaan kembali perangkat lunak yang
sangat banyak digunakan. Namun, batasan yang jelas dari pendekatan penggunaan kembali ini adalah bahwa fungsionalitas siste
dibatasi pada fungsionalitas inti generik. Selanjutnya, proses dan operasi perusahaan harus
dinyatakan dalam bahasa konfigurasi sistem, dan mungkin ada ketidaksesuaian antara konsep
dalam bisnis dan konsep yang didukung dalam bahasa konfigurasi.
Misalnya, dalam sistem ERP yang dijual ke universitas, konsep pelanggan harus didefinisikan.
Hal ini menyebabkan kesulitan besar ketika mengkonfigurasi sistem.
Namun, universitas memiliki banyak jenis pelanggan, seperti mahasiswa, lembaga pendanaan
penelitian, badan amal pendidikan, dll, yang masing-masing memiliki karakter yang berbeda. Tak
satu pun dari mereka yang benar-benar sebanding dengan gagasan pelanggan komersial (yaitu,
orang atau bisnis yang membeli produk atau jasa). Ketidakcocokan yang serius antara model bisnis
yang digunakan oleh sistem dan pembeli sistem membuat kemungkinan besar bahwa sistem ERP
tidak akan memenuhi kebutuhan nyata pembeli (Scott, 1999).
Baik produk COTS spesifik domain maupun sistem ERP biasanya memerlukan konfigurasi
ekstensif untuk menyesuaikannya dengan persyaratan setiap organisasi tempat mereka diinstal.
Konfigurasi ini mungkin melibatkan:
1. Memilih fungsionalitas yang diperlukan dari sistem (misalnya, dengan memutuskan apa yang
modul harus disertakan).
2. Menetapkan model data yang mendefinisikan bagaimana data organisasi akan distruktur
dimasukkan ke dalam database sistem.
3. Mendefinisikan aturan bisnis yang berlaku untuk data tersebut.
4. Mendefinisikan interaksi yang diharapkan dengan sistem eksternal.
5. Merancang form input dan laporan output yang dihasilkan oleh sistem.
6. Merancang proses bisnis baru yang sesuai dengan model proses yang mendasari yang didukung
oleh sistem.
7. Mengatur parameter yang menentukan bagaimana sistem dikerahkan pada dasarnya

platform.
Setelah pengaturan konfigurasi selesai, sistem solusi COTS siap untuk diuji. Pengujian adalah
masalah utama ketika sistem dikonfigurasi daripada diprogram menggunakan bahasa konvensional.
Karena sistem ini dibangun menggunakan platform yang andal, kegagalan dan kerusakan sistem
yang jelas relatif jarang terjadi.
Sebaliknya masalah sering halus dan berhubungan dengan interaksi antara proses operasional dan
konfigurasi sistem. Ini mungkin hanya dapat dideteksi oleh pengguna akhir dan mungkin tidak
ditemukan selama proses pengujian sistem.
Selanjutnya, pengujian unit otomatis, yang didukung oleh kerangka kerja pengujian seperti JUnit,
tidak dapat digunakan. Sistem yang mendasarinya tidak mungkin mendukung segala jenis
otomatisasi pengujian dan mungkin tidak ada spesifikasi sistem lengkap yang dapat digunakan
untuk memperoleh pengujian sistem.
16.4.2 Sistem terintegrasi COTS

Sistem terintegrasi COTS adalah aplikasi yang mencakup dua atau lebih produk COTS atau,
terkadang, sistem aplikasi lama. Anda dapat menggunakan pendekatan ini ketika tidak ada sistem
COTS tunggal yang memenuhi semua kebutuhan Anda atau ketika Anda ingin mengintegrasikan
produk COTS baru dengan sistem yang sudah Anda gunakan. Produk COTS dapat berinteraksi
melalui API (Application Programming Interfaces) atau antarmuka layanan jika ini ditentukan.
Atau, mereka dapat disusun dengan menghubungkan output dari satu sistem ke input lain atau
dengan memperbarui database yang digunakan oleh aplikasi COTS.
Untuk mengembangkan sistem menggunakan produk COTS, Anda harus membuat sejumlah desain
pilihan:
1. Produk COTS mana yang menawarkan fungsionalitas yang paling sesuai? Biasanya, akan ada
beberapa produk COTS yang tersedia, yang dapat digabungkan dengan cara yang berbeda.
Jika Anda belum memiliki pengalaman dengan produk COTS, mungkin sulit untuk
memutuskan produk mana yang paling cocok.
2. Bagaimana data akan dipertukarkan? Produk yang berbeda biasanya menggunakan struktur
dan format data yang unik. Anda harus menulis adaptor yang mengubah dari satu
representasi ke representasi lainnya. Adaptor ini adalah sistem run-time yang beroperasi
bersama produk COTS.
3. Fitur produk apa yang sebenarnya akan digunakan? Produk COTS mungkin menyertakan lebih
banyak fungsionalitas daripada yang Anda butuhkan dan fungsionalitas dapat diduplikasi di
berbagai produk. Anda harus memutuskan fitur mana dalam produk apa yang paling sesuai
dengan kebutuhan Anda. Jika memungkinkan, Anda juga harus menolak akses ke
fungsionalitas yang tidak digunakan karena ini dapat mengganggu operasi sistem normal.
Kegagalan penerbangan pertama roket Ariane 5 (Nuseibeh, 1997) merupakan akibat dari
kegagalan sistem navigasi inersia yang digunakan kembali dari sistem Ariane 4. Namun,
fungsi yang gagal sebenarnya tidak diperlukan di Ariane 5.
Pertimbangkan skenario berikut sebagai ilustrasi integrasi COTS. Sebuah organisasi besar
bermaksud untuk mengembangkan sistem pengadaan yang memungkinkan staf untuk memesan
dari meja mereka. Dengan memperkenalkan sistem ini di seluruh organisasi, perusahaan
memperkirakan dapat menghemat $5 juta per tahun. Dengan memusatkan pembelian, sistem
pengadaan yang baru dapat memastikan bahwa pesanan selalu dibuat dari pemasok yang
menawarkan harga terbaik dan harus mengurangi biaya dokumen yang terkait dengan pesanan.
Seperti halnya sistem manual, sistem ini melibatkan pemilihan barang yang tersedia dari pemasok,
membuat pesanan, menyetujui pesanan, mengirim pesanan ke pemasok, menerima barang, dan
mengonfirmasi bahwa pembayaran harus dilakukan.
Perusahaan memiliki sistem pemesanan warisan yang digunakan oleh kantor pusat
pengadaan. Perangkat lunak pemrosesan pesanan ini terintegrasi dengan sistem faktur dan
pengiriman yang ada. Untuk membuat sistem pemesanan baru, sistem legacy terintegrasi dengan
platform e-commerce berbasis web dan sistem email yang
Klien
Peramban Web Sistem Email
Server
Perdagangan elektronik Memesan dan

Adaptor
Sistem Sistem Faktur
Gambar 16.13 Sistem Email Adaptor

Pengadaan terpadu COTS
sistem
menangani komunikasi dengan pengguna. Struktur sistem pengadaan akhir, yang dibangun dengan
menggunakan COTS, ditunjukkan pada Gambar 16.13.
Sistem pengadaan ini berbasis klien-server dan, pada klien, web standar
browsing dan perangkat lunak e-mail yang digunakan. Di server, platform e-niaga harus
mengintegrasikan dengan sistem pemesanan yang ada melalui adaptor. Sistem e-commerce memiliki
format sendiri untuk pesanan, konfirmasi pengiriman, dan sebagainya, dan ini:
harus diubah ke dalam format yang digunakan oleh sistem pemesanan. perdagangan elektronik
sistem menggunakan sistem email untuk mengirim pemberitahuan kepada pengguna, tetapi sistem pemesanan
tidak pernah dirancang untuk ini. Oleh karena itu, adaptor lain harus ditulis untuk mengonversi
notifikasi dari sistem pemesanan menjadi pesan email.
Berbulan-bulan, terkadang bertahun-tahun, upaya implementasi dapat dihemat, dan waktu untuk
mengembangkan dan menerapkan sistem dapat dikurangi secara drastis menggunakan COTS-integrated
mendekati. Sistem pengadaan yang dijelaskan di atas telah diterapkan dan diterapkan
di sebuah perusahaan yang sangat besar dalam sembilan bulan, daripada tiga tahun yang mereka
perkirakan akan dibutuhkan untuk mengembangkan sistem di Jawa.
Integrasi COTS dapat disederhanakan jika pendekatan berorientasi layanan digunakan.
Pada dasarnya, pendekatan berorientasi layanan berarti mengizinkan akses ke aplikasi
fungsionalitas sistem melalui antarmuka layanan standar, dengan layanan untuk masing-masing
unit fungsi diskrit. Beberapa aplikasi mungkin menawarkan antarmuka layanan tetapi,
terkadang, antarmuka layanan ini harus diimplementasikan oleh integrator sistem.
Pada dasarnya, Anda harus memprogram pembungkus yang menyembunyikan aplikasi dan menyediakan
layanan yang terlihat secara eksternal (Gambar 16.14). Pendekatan ini sangat berharga untuk
sistem lama yang harus diintegrasikan dengan sistem aplikasi yang lebih baru.
Pada prinsipnya, pengintegrasian produk COTS sama dengan pengintegrasian komponen lainnya.
Anda harus memahami antarmuka sistem dan menggunakannya secara eksklusif untuk
berkomunikasi dengan perangkat lunak; Anda harus menukar persyaratan khusus dengan
pengembangan dan penggunaan kembali yang cepat; dan Anda harus merancang arsitektur sistem yang
memungkinkan sistem COTS untuk beroperasi bersama.
Pembungkus Layanan
Aplikasi
Sistem
Gambar
16.14 Pembungkus aplikasi Jasa Jasa
Namun, fakta bahwa produk ini biasanya merupakan sistem besar dalam dirinya sendiri, dan
sering dijual sebagai sistem mandiri yang terpisah, menimbulkan masalah tambahan.
Boehm dan Abts (1999) membahas empat masalah integrasi sistem COTS yang penting:
1. Kurangnya kontrol atas fungsionalitas dan kinerja Meskipun antarmuka produk yang
dipublikasikan mungkin tampak menawarkan fasilitas yang diperlukan, ini mungkin tidak
diterapkan dengan benar atau mungkin berkinerja buruk. Produk mungkin memiliki operasi
tersembunyi yang mengganggu penggunaannya dalam situasi tertentu. Memperbaiki
masalah ini mungkin menjadi prioritas bagi integrator produk COTS tetapi mungkin tidak
menjadi perhatian nyata bagi vendor produk. Pengguna mungkin hanya perlu mencari solusi
untuk masalah jika mereka ingin menggunakan kembali produk COTS.
2. Masalah dengan interoperabilitas sistem COTS Kadang-kadang sulit untuk membuat produk
COTS bekerja sama karena setiap produk memiliki asumsi sendiri tentang bagaimana
produk itu akan digunakan. Garlan dkk. (1995), melaporkan pengalaman mereka mencoba
mengintegrasikan empat produk COTS, menemukan bahwa tiga dari produk ini berbasis
peristiwa tetapi masing-masing menggunakan model peristiwa yang berbeda. Setiap sistem
berasumsi bahwa ia memiliki akses eksklusif ke antrian acara. Akibatnya, integrasi menjadi
sangat sulit. Proyek ini membutuhkan upaya lima kali lebih banyak dari yang diperkirakan semula.
Jadwal itu diperpanjang menjadi dua tahun daripada yang diperkirakan enam bulan. Dalam
analisis retrospektif pekerjaan mereka 10 tahun kemudian, Garlan et al. (2009) menyimpulkan
bahwa masalah integrasi yang mereka temukan belum terpecahkan. Torchiano dan Morisio
(2004) menemukan bahwa kurangnya kepatuhan terhadap standar dalam beberapa produk
COTS berarti bahwa integrasi lebih sulit daripada yang diantisipasi.
3. Tidak ada kendali atas evolusi sistem Vendor produk COTS membuat keputusan sendiri
tentang perubahan sistem, sebagai tanggapan terhadap tekanan pasar. Untuk produk PC,
khususnya, versi baru sering kali diproduksi dan mungkin tidak kompatibel dengan semua
versi sebelumnya. Versi baru mungkin memiliki fungsi tambahan yang tidak diinginkan, dan
versi sebelumnya mungkin menjadi tidak tersedia dan tidak didukung.
4. Dukungan dari vendor COTS Tingkat dukungan yang tersedia dari vendor COTS sangat
bervariasi. Dukungan vendor sangat penting ketika masalah muncul sebagai
pengembang tidak memiliki akses ke kode sumber dan dokumentasi rinci dari sistem. Meskipun
vendor mungkin berkomitmen untuk memberikan dukungan, perubahan pasar dan keadaan
ekonomi dapat mempersulit mereka untuk memenuhi komitmen ini. Misalnya, vendor sistem
COTS dapat memutuskan untuk menghentikan produk karena permintaan yang terbatas, atau
mereka dapat diambil alih oleh perusahaan lain yang tidak ingin mendukung semua produk yang
telah diperoleh.
Boehm dan Abts memperhitungkan bahwa, dalam banyak kasus, biaya pemeliharaan dan evolusi
sistem mungkin lebih besar untuk sistem yang terintegrasi dengan COTS. Semua kesulitan di atas
adalah masalah siklus hidup; mereka tidak hanya mempengaruhi pengembangan awal sistem.
Semakin jauh orang-orang yang terlibat dalam pemeliharaan sistem dipindahkan dari pengembang
sistem asli, semakin besar kemungkinan kesulitan nyata akan muncul dengan produk COTS terintegrasi.
POIN KUNCI
Sebagian besar sistem perangkat lunak bisnis baru sekarang dikembangkan dengan menggunakan kembali pengetahuan dan kode dari
sistem yang telah diterapkan sebelumnya.
Ada banyak cara berbeda untuk menggunakan kembali perangkat lunak. Ini berkisar dari penggunaan kembali kelas dan metode di
perpustakaan hingga penggunaan kembali sistem aplikasi yang lengkap.
Keuntungan penggunaan kembali perangkat lunak adalah biaya yang lebih rendah, pengembangan perangkat lunak yang lebih cepat, dan risiko yang lebih rendah.
Keandalan sistem meningkat. Spesialis dapat digunakan secara lebih efektif dengan memusatkan keahlian mereka pada
desain komponen yang dapat digunakan kembali.
Kerangka kerja aplikasi adalah kumpulan objek konkret dan abstrak yang dirancang untuk digunakan kembali melalui spesialisasi dan
penambahan objek baru. Mereka biasanya menggabungkan praktik desain yang baik melalui pola desain.
Lini produk perangkat lunak adalah aplikasi terkait yang dikembangkan dari satu atau lebih basis
aplikasi. Sistem generik diadaptasi dan dispesialisasikan untuk memenuhi persyaratan khusus untuk fungsionalitas,
platform target, atau konfigurasi operasional.
Penggunaan kembali produk COTS berkaitan dengan penggunaan kembali sistem skala besar yang siap pakai. Ini
menyediakan banyak fungsi dan penggunaannya kembali secara radikal dapat mengurangi biaya dan waktu pengembangan.
Sistem dapat dikembangkan dengan mengonfigurasi satu produk COTS generik atau dengan mengintegrasikan dua atau lebih
produk COTS.
Sistem Perencanaan Sumber Daya Perusahaan adalah contoh penggunaan kembali COTS skala besar. Anda membuat
contoh sistem ERP dengan mengkonfigurasi sistem generik dengan informasi tentang proses dan aturan bisnis pelanggan.
Potensi masalah dengan penggunaan kembali berbasis COTS termasuk kurangnya kontrol atas fungsionalitas dan
kinerja, kurangnya kontrol atas evolusi sistem, kebutuhan akan dukungan dari vendor eksternal, dan kesulitan dalam
memastikan bahwa sistem dapat beroperasi.
Bab 16 Latihan 449
BACAAN LEBIH LANJUT
Rekayasa Perangkat Lunak berbasis penggunaan kembali. Sebuah diskusi komprehensif tentang pendekatan yang berbeda untuk
penggunaan kembali perangkat lunak. Penulis membahas masalah penggunaan kembali teknis dan mengelola proses penggunaan kembali.
(H. Mili, A. Mili, S. Yacoub dan E. Addy, John Wiley & Sons, 2002.)
'Aspek yang Diabaikan dari Pengembangan Berbasis COTS'. Artikel menarik yang membahas tentang survey
developer menggunakan pendekatan berbasis COTS, dan permasalahan yang mereka temui.
(M. Torchiano dan M. Morisio, IEEE Software, 21 (2), Maret–April 2004.) http://dx.doi.org/
10.1109/MS.2004.1270770.
'Konstruksi dengan Konfigurasi: Tantangan Baru untuk Rekayasa Perangkat Lunak'. Ini adalah makalah undangan yang
saya tulis di mana saya membahas masalah dan kesulitan membangun aplikasi baru dengan mengkonfigurasi sistem
yang ada. (I. Sommerville, Proc. 19th Australian Software Engineering Conference, 2008.) http://dx.doi.org/10.1109/
ASWEC.2008.75.
'Ketidakcocokan Arsitektur: Mengapa Penggunaan Kembali Masih Sangat Sulit'. Artikel ini melihat kembali makalah
sebelumnya yang membahas masalah penggunaan kembali dan pengintegrasian sejumlah sistem COTS. Penulis
menyimpulkan bahwa, meskipun beberapa kemajuan telah dicapai, masih ada masalah dalam asumsi yang saling
bertentangan yang dibuat oleh perancang sistem individual. (D. Garlan dkk., IEEE Software, 26 (4), Juli–Agustus 2009.)
http://dx.doi.org//10.1109/MS.2009.86.
LATIHAN
16.1. Apa faktor teknis dan nonteknis utama yang menghambat penggunaan kembali perangkat lunak? Apakah kamu
secara pribadi menggunakan kembali banyak perangkat lunak dan, jika tidak, mengapa tidak?
16.2. Sarankan mengapa penghematan biaya dari penggunaan kembali perangkat lunak yang ada tidak hanya proporsional
dengan ukuran komponen yang digunakan kembali.
16.3. Berikan empat keadaan di mana Anda mungkin merekomendasikan untuk tidak menggunakan kembali perangkat lunak.
16.4. Jelaskan apa yang dimaksud dengan 'inversi kontrol' dalam kerangka kerja aplikasi. Jelaskan mengapa
pendekatan ini dapat menyebabkan masalah jika Anda mengintegrasikan dua sistem terpisah yang awalnya
dibuat menggunakan kerangka kerja aplikasi yang sama.
16.5. Menggunakan contoh sistem stasiun cuaca yang dijelaskan dalam Bab 1 dan
Bab 7, menyarankan arsitektur lini produk untuk keluarga aplikasi yang berkaitan dengan pemantauan
jarak jauh dan pengumpulan data. Anda harus menampilkan arsitektur Anda sebagai model berlapis,
menunjukkan komponen yang mungkin disertakan di setiap level.
16.6. Sebagian besar perangkat lunak desktop, seperti perangkat lunak pengolah kata, dapat dikonfigurasi dalam beberapa
cara berbeda. Periksa perangkat lunak yang biasa Anda gunakan dan buat daftar opsi konfigurasi untuk perangkat
lunak tersebut. Menyarankan kesulitan yang mungkin dialami pengguna dalam mengonfigurasi perangkat lunak.
Jika Anda menggunakan Microsoft Office atau Open Office, ini adalah contoh yang baik untuk digunakan dalam
latihan ini.
16.7. Mengapa banyak perusahaan besar memilih sistem ERP sebagai dasar sistem informasi organisasi mereka? Masalah apa
yang mungkin muncul ketika menerapkan sistem ERP skala besar dalam suatu organisasi?
16.8. Identifikasi enam kemungkinan risiko yang dapat muncul ketika sistem dibangun menggunakan COTS. Apa
langkah-langkah yang dapat diambil perusahaan untuk mengurangi risiko ini?
16.9. Jelaskan mengapa adaptor biasanya dibutuhkan ketika sistem dibangun dengan mengintegrasikan produk COTS. Sarankan tiga
masalah praktis yang mungkin muncul dalam penulisan perangkat lunak adaptor untuk menghubungkan dua produk aplikasi
COTS.
16.10. Penggunaan kembali perangkat lunak menimbulkan sejumlah masalah hak cipta dan kekayaan intelektual. Jika pelanggan
membayar kontraktor perangkat lunak untuk mengembangkan sistem, siapa yang berhak menggunakan kembali kode
yang dikembangkan? Apakah kontraktor perangkat lunak memiliki hak untuk menggunakan kode itu sebagai dasar untuk
komponen generik? Mekanisme pembayaran apa yang mungkin digunakan untuk mengganti penyedia komponen yang dapat
digunakan kembali? Diskusikan masalah ini dan masalah etika lainnya yang terkait dengan penggunaan kembali perangkat
lunak.
REFERENSI
Baker, T. (2002). 'Pelajaran yang Dipetik Mengintegrasikan COTS ke dalam Sistem'. Prok. ICCBSS 2002 (Konferensi Int. Pertama
tentang Sistem Perangkat Lunak berbasis COTS), Orlando, Fla:: Springer, 21–30.
Balk, LD dan Kedia, A. (2000). 'PPT: Studi Kasus Integrasi COTS'. Prok. Int. Kon. pada Software Eng., Limerick, Irlandia: ACM
Press, 42–9.
Baumer, D., Gryczan, G., Knoll, R., Lilienthal, C., Riehle, D. dan Zullighoven, H. (1997). 'Pengembangan Kerangka Kerja untuk
Sistem Besar'. Kom. ACM, 40 (10), 52–9.
Boehm, B. dan Abts, C. (1999). 'Integrasi COTS: Plug and Pray?' Komputer IEEE, 32 (1), 135–38.
Brownsword, L. dan Morris, E. (2003). 'Kabar Baik tentang COTS'. http://www.sei.cmu.edu/news-at-sei/features/2003/1q03/

feature-1-1q03.htm
Cusamano, M. (1989). 'Pabrik Perangkat Lunak: Interpretasi Historis'. Perangkat Lunak IEEE, 6 (2), 23–30.
Fayad, ME dan Schmidt, DC (1997). 'Kerangka Aplikasi Berorientasi Objek'. Kom. ACM, 40 (10), 32–38.
Gamma, E., Helm, R., Johnson, R. dan Vlissides, J. (1995). Pola Desain: Elemen Perangkat Lunak Berorientasi Objek yang
Dapat Digunakan Kembali. Membaca, Mass.: Addison-Wesley.
Garlan, D., Allen, R. dan Ockerbloom, J. (1995). 'Ketidakcocokan Arsitektur: Mengapa Penggunaan Kembali Begitu Sulit'.
Garlan, D., Allen, R. dan Ockerbloom, J. (2009). 'Ketidakcocokan Arsitektur: Mengapa Penggunaan Kembali Masih Begitu Sulit'.
Griss, ML dan Wosser, M. (1995). 'Membuat penggunaan kembali berfungsi di Hewlett-Packard'. Perangkat Lunak IEEE, 12 (1), 105–7.
Holdener, AT (2008). Ajax: Panduan Definitif. Sebastopol, California: O'Reilly and Associates.
Jacobson, I., Griss, M. dan Jonsson, P. (1997). Penggunaan Kembali Perangkat Lunak. Membaca, Mass.: Addison-Wesley.
Matsumoto, Y. (1984). 'Beberapa Pengalaman dalam Mempromosikan Perangkat Lunak yang Dapat Digunakan Kembali: Presentasi di
Tingkat Abstrak yang Lebih Tinggi'. IEEE. Trans. tentang Rekayasa Perangkat Lunak, SE-10 (5), 502–12.
McIlroy, MD (1968). 'Komponen perangkat lunak yang diproduksi secara massal'. Prok. Konferensi NATO pada Software Eng.,
Garmisch, Jerman: Springer-Verlag.
Nuseibeh, B. (1997). 'Ariane 5: Siapa Entahlah?' Perangkat Lunak IEEE, 14 (3), 15–6.
O'Leary, DE (2000). Sistem Perencanaan Sumber Daya Perusahaan: Sistem, Siklus Hidup, Perdagangan Elektronik, dan
Risiko. Cambridge, Inggris: Cambridge University Press.
Pfarr, T. dan Reis, JE (2002). 'Integrasi COTS/GOTS dalam Sistem Komando dan Kontrol HST NASA'. Prok. ICCBSS 2002
(Konferensi Int. Pertama tentang Sistem Perangkat Lunak berbasis COTS), Orlando, Fla.: Springer, 209–21.
Schmidt, DC (1997). 'Menerapkan pola desain dan kerangka kerja untuk mengembangkan perangkat lunak komunikasi berorientasi
objek'. Dalam Buku Pegangan Bahasa Pemrograman, Vol. 1. (ed.). New York: Penerbitan Komputer Macmillan.
Schmidt, DC, Gokhale, A. dan Natarajan, B. (2004). 'Memanfaatkan Kerangka Aplikasi'. Antrean ACM, 2 (5 (Juli/Agustus)), 66–75.
Scott, JE (1999). 'Kebangkrutan Obat FoxMeyer: Apakah Itu Kegagalan ERP'. Prok. Asosiasi untuk Sistem Informasi 5th Americas
Conf. tentang Sistem Informasi, Milwaukee, WI.
Torchiano, M. dan Morisio, M. (2004). 'Aspek yang Diabaikan dari Pengembangan Berbasis COTS'.
Tracz, W. (2001). 'Mitos COTS dan Pelajaran Lain yang Dipetik dalam Pengembangan Perangkat Lunak Berbasis
Komponen'. Dalam Rekayasa Perangkat Lunak Berbasis Komponen. Heineman, GT dan Councill, WT (ed.). Boston: Addison-
Wesley, 99-112.
17
Rekayasa perangkat
lunak berbasis komponen
Tujuan
Tujuan dari bab ini adalah untuk menjelaskan pendekatan penggunaan kembali
perangkat lunak berdasarkan komposisi komponen standar yang dapat digunakan
kembali. Setelah Anda membaca bab ini, Anda akan:
mengetahui bahwa rekayasa perangkat lunak berbasis komponen berkaitan dengan

pengembangan komponen standar berdasarkan model komponen, dan
menyusunnya ke dalam sistem aplikasi;
memahami apa yang dimaksud dengan komponen dan model komponen;
mengetahui kegiatan utama dalam proses CBSE untuk digunakan kembali dan
proses CBSE dengan penggunaan kembali;
memahami beberapa kesulitan dan masalah yang muncul selama

proses komposisi komponen.
Isi
17.1 Komponen dan model komponen 17.2 Proses
CBSE 17.3 Komposisi komponen
Bab 17 Rekayasa Perangkat Lunak Berbasis Komponen 453
Seperti yang saya jelaskan di Bab 16, banyak sistem bisnis baru sekarang dikembangkan dengan
mengonfigurasi sistem yang siap pakai. Namun, ketika sebuah perusahaan tidak dapat menggunakan off-the-shelf
sistem karena tidak memenuhi persyaratan mereka, perangkat lunak yang mereka butuhkan harus
khusus dikembangkan. Untuk perangkat lunak khusus, rekayasa perangkat lunak berbasis komponen adalah
cara yang efektif dan berorientasi pada penggunaan kembali untuk mengembangkan sistem perusahaan baru.
Rekayasa perangkat lunak berbasis komponen (CBSE) muncul pada akhir 1990-an sebagai
pendekatan pengembangan sistem perangkat lunak berdasarkan penggunaan kembali komponen perangkat lunak. Nya
penciptaan dimotivasi oleh frustrasi desainer bahwa pengembangan berorientasi objek telah
tidak menyebabkan penggunaan kembali yang ekstensif, seperti yang awalnya disarankan. Kelas objek tunggal adalah
terlalu detail dan spesifik, dan sering kali harus terikat dengan aplikasi saat dikompilasi
waktu. Anda harus memiliki pengetahuan mendetail tentang kelas untuk menggunakannya, dan ini biasanya
berarti Anda harus memiliki kode sumber komponen. Ini berarti bahwa menjual atau mendistribusikan objek
sebagai komponen individu yang dapat digunakan kembali secara praktis tidak mungkin.
Komponen adalah abstraksi tingkat yang lebih tinggi daripada objek dan didefinisikan olehnya
antarmuka. Mereka biasanya lebih besar dari objek individu dan semua implementasi
detail disembunyikan dari komponen lain. CBSE adalah proses mendefinisikan, menerapkan, dan
mengintegrasikan atau menyusun komponen independen yang digabungkan secara longgar
ke dalam sistem. Ini telah menjadi pendekatan pengembangan perangkat lunak yang penting karena
sistem perangkat lunak menjadi lebih besar dan lebih kompleks. Pelanggan menuntut
perangkat lunak yang lebih andal yang dikirimkan dan digunakan lebih cepat. Satu-satunya
cara agar kami dapat mengatasi kerumitan dan menghadirkan perangkat lunak yang lebih baik dengan lebih cepat adalah dengan
menggunakan kembali daripada mengimplementasikan kembali komponen perangkat lunak.
Inti dari rekayasa perangkat lunak berbasis komponen adalah:
1. Komponen independen yang sepenuhnya ditentukan oleh antarmuka mereka. Di sana

harus ada pemisahan yang jelas antara antarmuka komponen dan implementasinya. Ini berarti bahwa
satu implementasi komponen dapat digantikan oleh
lain, tanpa mengubah bagian lain dari sistem.
2. Standar komponen yang memfasilitasi integrasi komponen. Standar ini diwujudkan dalam model komponen.
Mereka mendefinisikan, paling tidak,
bagaimana antarmuka komponen harus ditentukan dan bagaimana komponen berkomunikasi. Beberapa
model melangkah lebih jauh dan mendefinisikan antarmuka yang harus diimplementasikan oleh semua
komponen konforman. Jika komponen sesuai dengan standar, maka
operasi mereka tidak tergantung pada bahasa pemrograman mereka. Komponen yang ditulis sepuluh
dalam bahasa yang berbeda dapat diintegrasikan ke dalam sistem yang sama.
3. Middleware yang menyediakan dukungan perangkat lunak untuk integrasi komponen. Untuk membuat
independen, komponen terdistribusi bekerja sama, Anda memerlukan dukungan middleware
yang menangani komunikasi komponen. Middleware untuk dukungan komponen menangani masalah
tingkat rendah secara efisien dan memungkinkan Anda untuk fokus pada aplikasi yang terkait
masalah. Selain itu, middleware untuk dukungan komponen dapat memberikan dukungan untuk
alokasi sumber daya, manajemen transaksi, keamanan, dan konkurensi.
4. Proses pengembangan yang diarahkan pada rekayasa perangkat lunak berbasis komponen.
Anda memerlukan proses pengembangan yang memungkinkan persyaratan berkembang, tergantung
454 Bab 17 Rekayasa Perangkat Lunak Berbasis Komponen
Masalah dengan CBSE
CBSE sekarang menjadi pendekatan utama untuk rekayasa perangkat lunak—ini adalah cara yang baik untuk
membangun sistem. Namun, ketika digunakan sebagai pendekatan untuk menggunakan kembali, masalah termasuk
kepercayaan komponen, sertifikasi komponen, kompromi persyaratan, dan memprediksi sifat komponen, terutama ketika
mereka terintegrasi dengan komponen lain.
http://www.SoftwareEngineering-9.com/Web/CBSE/problems.html
pada fungsionalitas komponen yang tersedia. Saya membahas proses pengembangan

CBSE di Bagian 17.2.
Pengembangan berbasis komponen mewujudkan praktik rekayasa perangkat lunak yang

baik. Masuk akal untuk merancang sistem menggunakan komponen, bahkan jika Anda harus
mengembangkan daripada menggunakan kembali komponen ini. CBSE yang mendasari adalah
prinsip-prinsip desain yang mendukung konstruksi perangkat lunak yang dapat dimengerti dan dipelihara:
1. Komponen bersifat independen sehingga tidak mengganggu operasi satu sama lain. Detail
implementasi disembunyikan. Implementasi komponen dapat diubah tanpa mempengaruhi
sistem lainnya.
2. Komponen berkomunikasi melalui antarmuka yang terdefinisi dengan baik. Jika antarmuka
ini dipertahankan, satu komponen dapat diganti dengan yang lain, yang menyediakan
fungsionalitas tambahan atau ditingkatkan.
3. Infrastruktur komponen menawarkan berbagai layanan standar yang dapat digunakan dalam
sistem aplikasi. Ini mengurangi jumlah kode baru yang harus dikembangkan.
Motivasi awal untuk CBSE adalah kebutuhan untuk mendukung penggunaan kembali dan
rekayasa perangkat lunak terdistribusi. Komponen dilihat sebagai elemen dari sistem
perangkat lunak yang dapat diakses, menggunakan mekanisme panggilan prosedur jarak
jauh, oleh komponen lain yang berjalan pada komputer terpisah. Setiap sistem yang
menggunakan kembali komponen harus memasukkan salinan komponennya sendiri. Ide
komponen ini memperluas gagasan objek terdistribusi, seperti yang didefinisikan dalam model
sistem terdistribusi seperti spesifikasi CORBA (Pope, 1997). Beberapa protokol dan standar
yang berbeda telah dikembangkan untuk mendukung pandangan komponen ini, seperti
Enterprise Java Beans (EJB) Sun, COM dan .NET Microsoft, dan CCM CORBA (Lau dan Wang, 2007).
Dalam praktiknya, berbagai standar ini telah menghambat penyerapan CBSE. Tidak
mungkin komponen yang dikembangkan menggunakan pendekatan yang berbeda untuk bekerja sama.
Komponen yang dikembangkan untuk platform yang berbeda, seperti .NET atau J2EE, tidak
dapat beroperasi. Selain itu, standar dan protokol yang diusulkan rumit dan sulit dipahami. Ini
juga merupakan penghalang untuk adopsi mereka.
Menanggapi masalah ini, gagasan komponen sebagai layanan dikembangkan, dan standar
diusulkan untuk mendukung rekayasa perangkat lunak berorientasi layanan.
17.1 Komponen dan model komponen 455
Perbedaan paling signifikan antara komponen sebagai layanan dan gagasan asli tentang
komponen adalah bahwa layanan adalah entitas yang berdiri sendiri yang berada di luar program
yang menggunakannya. Saat Anda membangun sistem berorientasi layanan, Anda mereferensikan
layanan eksternal daripada menyertakan salinan layanan itu di sistem Anda.
Rekayasa perangkat lunak berorientasi layanan, yang saya bahas di Bab 19, oleh karena itu
merupakan jenis rekayasa perangkat lunak berbasis komponen. Ini menggunakan gagasan
komponen yang lebih sederhana daripada yang awalnya diusulkan di CBSE. Ini telah didorong,
dari awal, oleh standar. Dalam situasi di mana penggunaan kembali berbasis COTS tidak praktis,
CBSE berorientasi layanan menjadi pendekatan dominan untuk pengembangan sistem bisnis.
17.1 Komponen dan model komponen
Ada kesepakatan umum di komunitas CBSE bahwa komponen adalah unit perangkat lunak
independen yang dapat dikomposisikan dengan komponen lain untuk membuat sistem perangkat
lunak. Di luar itu, bagaimanapun, orang telah mengusulkan berbagai definisi komponen perangkat
lunak. Councill dan Heineman (2001) mendefinisikan komponen sebagai:
"Sebuah elemen perangkat lunak yang sesuai dengan model komponen standar dan dapat
digunakan secara independen dan disusun tanpa modifikasi sesuai dengan standar
komposisi."
Definisi ini pada dasarnya didasarkan pada standar sehingga unit perangkat lunak yang
sesuai dengan standar tersebut adalah komponen. Szyperski (2002), bagaimanapun, tidak
menyebutkan standar dalam definisi komponen tetapi berfokus pada karakteristik kunci dari
komponen:
“Komponen perangkat lunak adalah unit komposisi dengan antarmuka yang ditentukan
secara kontraktual dan dependensi konteks eksplisit saja. Komponen perangkat lunak
dapat digunakan secara independen dan tunduk pada komposisi oleh pihak ketiga.”
Kedua definisi ini didasarkan pada pengertian komponen sebagai elemen yang termasuk
dalam suatu sistem, bukan layanan yang direferensikan oleh sistem.
Namun, mereka juga kompatibel dengan gagasan layanan sebagai komponen.
Szyperski juga menyatakan bahwa suatu komponen tidak memiliki keadaan yang dapat
diamati secara eksternal. Ini berarti bahwa salinan komponen tidak dapat dibedakan. Namun,
beberapa model komponen, seperti model Enterprise Java Beans, mengizinkan komponen
stateful, jadi ini tidak sesuai dengan definisi Szyperski. Meskipun komponen stateless tentu lebih
mudah digunakan, ada beberapa sistem di mana komponen stateful lebih nyaman dan mengurangi
kompleksitas sistem.
Persamaan definisi di atas adalah bahwa mereka setuju bahwa komponen adalah independen,
dan bahwa mereka adalah unit dasar komposisi dalam suatu sistem.
Dalam pandangan saya, definisi komponen yang lebih baik dapat diturunkan dengan menggabungkan ini
Karakteristik Komponen Keterangan
Standar Standarisasi komponen berarti bahwa komponen yang digunakan

dalam proses CBSE harus sesuai dengan model komponen standar. Model
ini dapat mendefinisikan antarmuka komponen, metadata komponen,
dokumentasi, komposisi, dan penerapan.
Mandiri Sebuah komponen harus independen—harus memungkinkan untuk

menyusun dan menyebarkannya tanpa harus menggunakan komponen
spesifik lainnya. Dalam situasi di mana komponen membutuhkan layanan
yang disediakan secara eksternal, ini harus ditetapkan secara eksplisit
dalam spesifikasi antarmuka 'memerlukan'.
Dapat disusun Agar komponen dapat dikomposisi, semua interaksi eksternal harus
dilakukan melalui antarmuka yang ditentukan secara publik. Selain itu, ia
harus menyediakan akses eksternal ke informasi tentang dirinya sendiri,
seperti metode dan atributnya.
Dapat diterapkan Agar dapat digunakan, komponen harus mandiri. Itu harus dapat beroperasi
sebagai entitas yang berdiri sendiri pada platform komponen yang
menyediakan implementasi model komponen. Ini biasanya berarti bahwa
komponen adalah biner dan tidak harus dikompilasi sebelum disebarkan.
Jika komponen diimplementasikan sebagai layanan, komponen tersebut
tidak harus digunakan oleh pengguna komponen. Sebaliknya, itu digunakan
oleh penyedia layanan.
didokumentasikan Komponen harus didokumentasikan sepenuhnya sehingga pengguna

potensial dapat memutuskan apakah komponen memenuhi kebutuhan
mereka atau tidak. Sintaks dan, idealnya, semantik semua antarmuka
komponen harus ditentukan.
proposal. Gambar 17.1 menunjukkan apa yang saya anggap sebagai karakteristik penting dari suatu
Gambar
17.1 komponen seperti yang digunakan dalam CBSE.
Karakteristik komponen Cara berpikir yang berguna tentang suatu komponen adalah sebagai penyedia satu atau lebih es
layanan. Ketika suatu sistem membutuhkan layanan, ia memanggil komponen untuk menyediakan
layanan itu tanpa peduli di mana komponen itu dieksekusi atau bahasa pemrograman yang digunakan
untuk mengembangkan komponen. Misalnya, komponen dalam sistem perpustakaan mungkin
menyediakan layanan pencarian yang memungkinkan pengguna untuk mencari katalog perpustakaan yang berbeda.
Sebuah komponen yang mengkonversi dari satu format grafis ke yang lain (misalnya, TIFF ke JPEG)
menyediakan layanan konversi data, dll.
Melihat komponen sebagai penyedia layanan menekankan dua karakteristik penting dari komponen
yang dapat digunakan kembali:
1. Komponen adalah entitas executable independen yang ditentukan oleh antar mukanya. Anda tidak
memerlukan pengetahuan tentang kode sumbernya untuk menggunakannya. Itu dapat
direferensikan sebagai layanan eksternal atau disertakan langsung dalam suatu program.
2. Layanan yang ditawarkan oleh komponen tersedia melalui antarmuka dan semua interaksi melalui
antarmuka itu. Antarmuka komponen dinyatakan dalam operasi parameter dan keadaan internalnya
tidak pernah diekspos.
Komponen dan objek
Komponen sering diimplementasikan dalam bahasa berorientasi objek dan, dalam beberapa kasus, mengakses antarmuka
'menyediakan' komponen dilakukan melalui pemanggilan metode. Namun, komponen dan kelas objek bukanlah hal yang
sama. Tidak seperti kelas objek, komponen dapat digunakan secara independen, tidak mendefinisikan tipe, tidak
bergantung pada bahasa, dan didasarkan pada model komponen standar.
http://www.SoftwareEngineering-9.com/Web/CBSE/objects.html
Komponen memiliki dua antarmuka terkait, seperti yang ditunjukkan pada Gambar 17.2.
Antar muka ini mencerminkan layanan yang disediakan komponen dan layanan yang
diperlukan komponen untuk beroperasi dengan benar:
• Antarmuka 'menyediakan' mendefinisikan layanan yang disediakan oleh komponen.

Antarmuka ini, pada dasarnya, adalah komponen API. Ini mendefinisikan metode yang
dapat dipanggil oleh pengguna komponen. Dalam diagram komponen UML, antarmuka
'menyediakan' untuk komponen ditandai dengan lingkaran di akhir baris dari ikon komponen.
• Antarmuka 'memerlukan' menentukan layanan apa yang harus disediakan oleh komponen
lain dalam sistem jika komponen ingin beroperasi dengan benar. Jika ini tidak tersedia,
maka komponen tidak akan berfungsi. Ini tidak mengkompromikan independensi atau
penerapan komponen karena antarmuka 'memerlukan' tidak menentukan bagaimana
layanan ini harus disediakan. Dalam UML, simbol untuk antarmuka 'memerlukan' adalah
setengah lingkaran di akhir garis dari ikon komponen. Perhatikan bahwa ikon antarmuka
'menyediakan' dan 'memerlukan' dapat saling cocok seperti bola dan soket.
Untuk mengilustrasikan antarmuka ini, Gambar 17.3 menunjukkan model komponen yang
telah dirancang untuk mengumpulkan dan menyusun informasi dari serangkaian sensor. Ini
berjalan secara mandiri untuk mengumpulkan data selama periode waktu tertentu dan,
berdasarkan permintaan, menyediakan data yang dikumpulkan ke komponen pemanggil.
Antarmuka 'menyediakan' mencakup metode untuk menambah, menghapus, memulai,
menghentikan, dan menguji sensor. Metode report mengembalikan data sensor yang telah
dikumpulkan, dan metode listAll memberikan informasi tentang sensor yang terpasang.
Meskipun saya belum menunjukkan ini di sini, metode ini memiliki parameter terkait yang menentukan pengidentifikasi
Antarmuka 'memerlukan' digunakan untuk menghubungkan komponen ke sensor. Ini
mengasumsikan bahwa sensor memiliki antarmuka data, diakses melalui sensorData, dan manajemen
Membutuhkan Antarmuka Menyediakan Antarmuka
Mendefinisikan Mendefinisikan layanan

layanan yang dibutuhkan dan yang disediakan
Komponen
Gambar harus disediakan oleh komponen ke
17.2 oleh komponen lain komponen lain
Antarmuka komponen
Membutuhkan Antarmuka Menyediakan Antarmuka
tambahkanSensor
hapusSensor
mulaiSensor
manajemen sensor
stopSensor
Pengumpul data
testSensor
sensorData inisialisasi
Gambar 17.3 Model daftar
komponen pengumpul
laporanSemua
data
antarmuka, diakses melalui sensorManagement. Antarmuka ini telah dirancang untuk

terhubung ke berbagai jenis sensor sehingga tidak mencakup operasi sensor tertentu
seperti Test, provideReading, dll. Sebaliknya, perintah yang digunakan oleh jenis sensor
tertentu disematkan dalam string, yang merupakan parameter untuk operasi di
antarmuka 'memerlukan'. Komponen adaptor mengurai string ini dan menerjemahkan
perintah yang disematkan ke antarmuka kontrol khusus dari setiap jenis sensor. Saya
membahas penggunaan adaptor nanti dalam bab ini, di mana saya menunjukkan
bagaimana komponen pengumpul data dihubungkan ke sensor (Gambar 17.12).
Perbedaan penting antara komponen sebagai layanan eksternal dan komponen
sebagai elemen program adalah bahwa layanan adalah entitas yang sepenuhnya
independen. Mereka tidak memiliki antarmuka 'memerlukan'. Program yang berbeda
dapat menggunakan layanan ini tanpa perlu menerapkan dukungan tambahan yang diperlukan oleh layanan.
17.1.1 Model komponen

Model komponen adalah definisi standar untuk implementasi komponen, dokumentasi,
dan penerapan. Standar ini untuk pengembang komponen untuk memastikan bahwa
komponen dapat beroperasi. Mereka juga untuk penyedia infrastruktur eksekusi
komponen yang menyediakan middleware untuk mendukung operasi komponen.
Banyak model komponen telah diusulkan, tetapi model yang paling penting sekarang
adalah model WebServices, model Enterprise Java Beans (EJB) Sun, dan model .NET
Microsoft (Lau dan Wang, 2007).
Elemen dasar dari model komponen ideal dibahas oleh Weinreich dan Sametinger
(2001). Saya meringkas elemen model ini pada Gambar 17.4. Diagram ini menunjukkan
bahwa elemen model komponen menentukan antarmuka komponen, informasi yang
Anda perlukan untuk menggunakan komponen dalam program, dan bagaimana
komponen harus disebarkan:
1. Antarmuka Komponen didefinisikan dengan menentukan antarmuka mereka. Model

komponen menentukan bagaimana antarmuka harus didefinisikan dan elemen,
seperti nama operasi, parameter, dan pengecualian, yang harus disertakan dalam
definisi antarmuka. Model juga harus menentukan bahasa yang digunakan untuk
mendefinisikan antarmuka komponen. Untuk layanan web, ini adalah WSDL, yang saya bahas di
Kustomisasi
Penamaan
Konvensi
Komposisi Dokumentasi
Antarmuka Spesifik Meta-Data Evolusi

Definisi Antarmuka Mengakses Kemasan Mendukung
Penggunaan Penerapan dan

Antarmuka
Informasi Penggunaan
Gambar 17.4
Elemen dasar Model Komponen
model komponen
Bab 19; EJB khusus untuk Java sehingga Java digunakan sebagai bahasa
definisi antarmuka; di .NET, antarmuka didefinisikan menggunakan Common
Intermediate Language (CIL). Beberapa model komponen memerlukan
antarmuka khusus yang harus ditentukan oleh komponen. Ini digunakan untuk
menyusun komponen dengan infrastruktur model komponen, yang menyediakan
layanan standar seperti keamanan dan manajemen transaksi.
2. Penggunaan Agar komponen dapat didistribusikan dan diakses dari jarak jauh,
mereka harus memiliki nama atau pegangan unik yang terkait dengannya. Ini
harus unik secara global—misalnya, di EJB, nama hierarki dibuat dengan root
berdasarkan nama domain Internet. Layanan memiliki URI (Uniform Resource
Identifier) yang unik.
Meta-data komponen adalah data tentang komponen itu sendiri, seperti

informasi tentang antarmuka dan atributnya. Meta-data penting karena
memungkinkan pengguna komponen untuk mengetahui layanan apa yang disediakan dan dibutuhkan
Implementasi model komponen biasanya mencakup cara tertentu (seperti
penggunaan antarmuka refleksi di Java) untuk mengakses meta-data komponen ini.
Komponen adalah entitas generik dan, ketika digunakan, mereka harus

dikonfigurasi agar sesuai dengan sistem aplikasi. Misalnya, Anda dapat
mengonfigurasi komponen Pengumpul data (Gambar 17.2) dengan menentukan
jumlah maksimum sensor dalam larik sensor. Oleh karena itu, model komponen
dapat menentukan bagaimana komponen biner dapat dikustomisasi untuk lingkungan penerapan tert
3. Deployment Model komponen mencakup spesifikasi tentang bagaimana

komponen harus dikemas untuk penyebaran sebagai entitas independen yang dapat dieksekusi.
Karena komponen adalah entitas independen, mereka harus dikemas dengan
semua perangkat lunak pendukung yang tidak disediakan oleh infrastruktur
komponen, atau tidak didefinisikan dalam antarmuka 'memerlukan'. Informasi
Deployment mencakup informasi tentang isi paket dan organisasi binernya.
Tak pelak, ketika persyaratan baru muncul, komponen harus diubah atau
diganti. Oleh karena itu, model komponen dapat mencakup aturan yang
mengatur kapan dan bagaimana penggantian komponen diperbolehkan. Akhirnya, model komponen m
Layanan Dukungan
Komponen Transaksi Sumber

Pengelolaan Pengelolaan Pengelolaan
Konkurensi Kegigihan Keamanan
Layanan Platform
Gambar
Antarmuka Pengecualian Komponen
17.5 Layanan Mengatasi Definisi Pengelolaan Komunikasi
middleware didefinisikan
dalam model komponen
menentukan dokumentasi komponen yang harus diproduksi. Ini digunakan untuk

menemukan komponen dan memutuskan apakah itu sesuai.
Untuk komponen yang diimplementasikan sebagai unit program daripada layanan

eksternal, model komponen menetapkan layanan yang akan disediakan oleh
middleware yang mendukung komponen pelaksana. Weinreich dan Sametinger (2001)
menggunakan analogi sistem operasi untuk menjelaskan model komponen. Sebuah
sistem operasi menyediakan satu set layanan generik yang dapat digunakan oleh
aplikasi. Implementasi model komponen menyediakan layanan bersama yang
sebanding untuk komponen. Gambar 17.5 menunjukkan beberapa layanan yang
mungkin disediakan oleh implementasi model komponen.
Layanan yang disediakan oleh implementasi model komponen terbagi dalam dua
kategori:
1. Layanan platform, yang memungkinkan komponen untuk berkomunikasi dan

beroperasi dalam lingkungan terdistribusi. Ini adalah layanan dasar yang harus
tersedia di semua sistem berbasis komponen.
2. Layanan pendukung, yaitu layanan umum yang kemungkinan akan dibutuhkan

oleh banyak komponen yang berbeda. Misalnya, banyak komponen memerlukan
otentikasi untuk memastikan bahwa pengguna layanan komponen diotorisasi.
Masuk akal untuk menyediakan satu set standar layanan middleware untuk
digunakan oleh semua komponen. Hal ini mengurangi biaya pengembangan
komponen dan potensi ketidaksesuaian komponen dapat dihindari.
Middleware mengimplementasikan layanan komponen dan menyediakan antarmuka

ke layanan ini. Untuk memanfaatkan layanan yang disediakan oleh infrastruktur
model komponen, Anda dapat menganggap komponen tersebut digunakan dalam 'wadah'.
Wadah adalah implementasi dari layanan dukungan ditambah definisi antarmuka
yang harus disediakan oleh komponen untuk mengintegrasikannya dengan wadah.
Memasukkan komponen ke dalam wadah berarti bahwa komponen dapat mengakses
layanan dukungan dan wadah dapat mengakses antarmuka komponen. Saat
digunakan, antarmuka komponen itu sendiri tidak diakses secara langsung oleh komponen lain;
17.2 Proses CBSE 461
alih-alih, mereka diakses melalui antarmuka wadah yang memanggil kode untuk mengakses
antarmuka komponen yang disematkan.
Wadah berukuran besar dan kompleks, dan saat Anda menerapkan komponen dalam wadah,
Anda mendapatkan akses ke semua layanan middleware. Namun, komponen sederhana mungkin
tidak memerlukan semua fasilitas yang ditawarkan oleh middleware pendukung. Oleh karena itu,
pendekatan yang diambil dalam layanan web untuk penyediaan layanan umum agak berbeda. Untuk
layanan web, standar telah ditetapkan untuk layanan umum seperti manajemen transaksi dan
keamanan dan standar ini telah diimplementasikan sebagai perpustakaan program. Jika Anda
menerapkan komponen layanan, Anda hanya menggunakan layanan umum yang Anda butuhkan.
17.2 Proses CBSE

Proses CBSE adalah proses perangkat lunak yang mendukung rekayasa perangkat lunak berbasis
komponen. Mereka memperhitungkan kemungkinan penggunaan kembali dan aktivitas proses yang
berbeda yang terlibat dalam pengembangan dan penggunaan komponen yang dapat digunakan
kembali. Gambar 17.6 (Kotonya, 2003) menyajikan gambaran proses di CBSE. Pada level tertinggi,
ada dua jenis proses CBSE:
1. Pengembangan untuk penggunaan kembali Proses ini berkaitan dengan pengembangan

komponen atau layanan yang akan digunakan kembali dalam aplikasi lain. Biasanya melibatkan
generalisasi komponen yang ada.
2. Pengembangan dengan penggunaan kembali Ini adalah proses pengembangan aplikasi baru
menggunakan komponen dan layanan yang ada.
Proses-proses ini memiliki tujuan yang berbeda dan oleh karena itu, mencakup aktivitas yang
berbeda. Dalam pengembangan untuk proses reuse, tujuannya adalah untuk menghasilkan satu
atau lebih komponen yang dapat digunakan kembali. Anda tahu komponen yang akan Anda kerjakan
dan Anda memiliki akses ke kode sumbernya untuk menggeneralisasikannya. Dalam pengembangan
dengan penggunaan kembali, Anda tidak tahu komponen apa yang tersedia, jadi Anda perlu
menemukan komponen ini dan merancang sistem Anda untuk memanfaatkannya secara efektif.
Anda mungkin tidak memiliki akses ke kode sumber komponen.
Anda dapat melihat dari Gambar 17.6 bahwa proses dasar CBSE dengan dan untuk digunakan
kembali memiliki proses pendukung yang berkaitan dengan akuisisi komponen, manajemen
komponen, dan sertifikasi komponen:
1. Akuisisi komponen adalah proses perolehan komponen untuk digunakan kembali atau
dikembangkan menjadi komponen yang dapat digunakan kembali. Ini mungkin melibatkan
mengakses komponen atau layanan yang dikembangkan secara lokal atau menemukan komponen ini dari sumber ekster
2. Manajemen komponen berkaitan dengan pengelolaan komponen perusahaan yang dapat

digunakan kembali, memastikan bahwa mereka dikatalogkan dengan benar, disimpan, dan
tersedia untuk digunakan kembali.
Proses CBSE
penentu,
CBSE untuk CBSE dengan Perancang,
Penggunaan kembali Penggunaan kembali
pengintegrasi,
Pemelihara
Analis Domain,
Perancang,
pelaksana, Pustakawan,
Pemelihara, Komponen
Penjual,
Analis Pasar Akuisisi Makelar
Luar
Komponen Komponen Pustakawan Sumber
Sertifikasi Pengelolaan
lokal atau
Luar
Pemberi Sertifikat
Komponen
Gudang
Gambar 17.6 Proses
CBSE
3. Sertifikasi komponen adalah proses pemeriksaan komponen dan sertifikasi

bahwa itu memenuhi spesifikasinya.
Komponen yang dipelihara oleh suatu organisasi dapat disimpan dalam repositori komponen
teori yang mencakup komponen dan informasi tentang penggunaannya.
17.2.1 CBSE untuk digunakan kembali
CBSE untuk digunakan kembali adalah proses pengembangan komponen yang dapat digunakan
kembali dan membuatnya tersedia untuk digunakan kembali melalui sistem manajemen
komponen. Visi pendukung awal CBSE (Szyperski, 2002) adalah bahwa pasar komponen yang
berkembang akan berkembang. Akan ada penyedia komponen spesialis dan vendor komponen
yang akan mengatur penjualan komponen dari pengembang yang berbeda.
Pengembang perangkat lunak akan membeli komponen untuk dimasukkan ke dalam sistem
atau membayar layanan saat digunakan. Namun, visi tersebut belum terwujud. Ada relatif sedikit
pemasok komponen dan membeli komponen jarang terjadi. Pada saat penulisan, pasar layanan
juga belum berkembang meskipun ada prediksi bahwa itu akan berkembang secara signifikan
selama beberapa tahun ke depan.
Akibatnya, CBSE untuk penggunaan kembali kemungkinan besar terjadi di dalam organisasi
yang telah membuat komitmen untuk rekayasa perangkat lunak berbasis penggunaan kembali.
Mereka ingin mengeksploitasi aset perangkat lunak yang telah dikembangkan di berbagai bagian
perusahaan. Namun, komponen yang dikembangkan secara internal ini biasanya tidak dapat
digunakan kembali tanpa perubahan. Mereka sering menyertakan fitur dan antarmuka khusus
aplikasi yang tidak mungkin diperlukan dalam program lain di mana komponen digunakan kembali.
Untuk membuat komponen dapat digunakan kembali, Anda harus menyesuaikan dan memperluas
komponen khusus aplikasi untuk membuat versi yang lebih umum dan karenanya lebih dapat digunakan kembali.
Jelas, adaptasi ini memiliki biaya yang terkait. Jadi Anda harus memutuskan terlebih dahulu,
apakah suatu komponen kemungkinan akan digunakan kembali dan kedua, apakah penghematan biaya
dari penggunaan kembali di masa depan membenarkan biaya untuk membuat komponen dapat digunakan kembali.
Untuk menjawab pertanyaan pertama ini, Anda harus memutuskan apakah komponen tersebut
mengimplementasikan satu atau lebih abstraksi domain yang stabil atau tidak. Abstraksi domain yang
stabil adalah elemen dasar dari domain aplikasi yang berubah secara perlahan. Untuk
contoh, dalam sistem perbankan, abstraksi domain mungkin termasuk akun, akun
pemegang, dan pernyataan. Dalam sistem manajemen rumah sakit, abstraksi domain
mungkin termasuk pasien, perawatan, dan perawat. Abstraksi domain ini terkadang disebut 'objek bisnis'.
Jika komponen tersebut merupakan implementasi dari abstraksi domain yang umum digunakan atau
kelompok objek bisnis terkait, itu mungkin dapat
digunakan kembali.
Untuk menjawab pertanyaan tentang efektivitas biaya, Anda harus menilai biaya
perubahan yang diperlukan untuk membuat komponen dapat digunakan kembali. Biaya-biaya tersebut adalah
biaya dokumentasi komponen, validasi komponen, dan membuat komponen lebih umum. Perubahan yang
mungkin Anda lakukan pada komponen untuk membuatnya lebih banyak
dapat digunakan kembali meliputi:
• menghapus metode khusus aplikasi;
• mengubah nama untuk membuatnya lebih umum;
• menambahkan metode untuk menyediakan cakupan fungsional yang lebih lengkap;
• membuat penanganan pengecualian konsisten untuk semua metode;
• menambahkan antarmuka 'konfigurasi' untuk memungkinkan komponen disesuaikan dengan perbedaan

situasi penggunaan ent;
• mengintegrasikan komponen-komponen yang diperlukan untuk meningkatkan kemandirian.
Masalah penanganan pengecualian adalah salah satu yang sangat sulit. Komponen
seharusnya tidak menangani pengecualian sendiri, karena setiap aplikasi akan memilikinya sendiri
persyaratan untuk penanganan pengecualian. Sebaliknya, komponen harus mendefinisikan apa
pengecualian dapat muncul dan harus mempublikasikannya sebagai bagian dari antarmuka. Misalnya,
komponen sederhana yang mengimplementasikan struktur data tumpukan harus mendeteksi dan mempublikasikan
stack overflow dan stack underflow pengecualian. Namun dalam praktiknya, ada dua
masalah dengan ini:
1. Memublikasikan semua pengecualian mengarah ke antarmuka yang membengkak yang lebih sulit untuk
dipahami. Ini dapat menunda calon pengguna komponen.
2. Pengoperasian komponen mungkin bergantung pada penanganan pengecualian lokal,

dan mengubah ini mungkin memiliki implikasi serius untuk fungsi
komponen.
Mili dkk. (2002) membahas cara memperkirakan biaya untuk membuat komponen dapat
digunakan kembali dan pengembalian dari investasi tersebut. Manfaat menggunakan kembali
daripada mengembangkan kembali komponen bukan hanya peningkatan produktivitas. Ada
juga peningkatan kualitas, karena komponen yang digunakan kembali harus lebih dapat
diandalkan, dan keuntungan dari waktu ke pasar. Ini adalah peningkatan hasil yang diperoleh
dari penerapan perangkat lunak lebih cepat. Mili dkk. menyajikan berbagai formula untuk
memperkirakan keuntungan ini, seperti halnya model COCOMO yang dibahas dalam Bab 23
(Boehm, et al., 2000). Namun, parameter formula ini sulit untuk diestimasi secara akurat, dan
formula tersebut harus disesuaikan dengan keadaan setempat, sehingga sulit untuk digunakan.
Saya menduga bahwa beberapa manajer proyek perangkat lunak menggunakan model ini untuk
memperkirakan laba atas investasi dari penggunaan kembali komponen.
Jelas, apakah suatu komponen dapat digunakan kembali atau tidak tergantung pada domain
dan fungsionalitas aplikasinya. Saat Anda menambahkan generalitas ke komponen, Anda
meningkatkan kegunaannya kembali. Namun, ini biasanya berarti bahwa komponen memiliki
lebih banyak operasi dan lebih kompleks, yang membuat komponen lebih sulit untuk dipahami dan digunakan.
Oleh karena itu, ada trade-off yang tak terhindarkan antara reusability dan usability dari
suatu komponen. Untuk membuat komponen dapat digunakan kembali, Anda harus menyediakan
satu set antarmuka generik dengan operasi yang memenuhi semua cara di mana komponen
dapat digunakan. Membuat komponen dapat digunakan berarti menyediakan antarmuka
sederhana dan minimal yang mudah dipahami. Penggunaan kembali menambah kompleksitas
dan karenanya mengurangi pemahaman komponen. Oleh karena itu lebih sulit untuk
memutuskan kapan dan bagaimana menggunakan kembali komponen tersebut. Saat merancang
komponen yang dapat digunakan kembali, Anda harus, oleh karena itu, menemukan kompromi antara umum dan dapat dime
Sumber komponen potensial adalah sistem warisan yang ada. Seperti yang saya bahas di
Bab 9, ini adalah sistem yang memenuhi fungsi bisnis yang penting tetapi ditulis dengan
menggunakan teknologi perangkat lunak yang sudah usang. Karena itu, mungkin sulit untuk
menggunakannya dengan sistem baru. Namun, jika Anda mengonversi sistem lama ini menjadi
komponen, fungsinya dapat digunakan kembali di aplikasi baru.
Tentu saja, sistem warisan ini biasanya tidak memiliki antarmuka 'memerlukan' dan
'menyediakan' yang jelas. Untuk membuat komponen ini dapat digunakan kembali, Anda harus
membuat pembungkus yang mendefinisikan antarmuka komponen. Pembungkus
menyembunyikan kompleksitas kode yang mendasarinya dan menyediakan antarmuka untuk
komponen eksternal untuk mengakses layanan yang disediakan. Meskipun pembungkus ini
adalah bagian dari perangkat lunak yang cukup kompleks, biaya pengembangan pembungkus
seringkali jauh lebih sedikit daripada biaya implementasi ulang sistem lama. Saya membahas
pendekatan ini secara lebih rinci di Bab 19, di mana saya menjelaskan bagaimana fitur dalam sistem warisan dapat diakses m
Setelah Anda mengembangkan dan menguji komponen atau layanan yang dapat digunakan
kembali, ini harus dikelola untuk digunakan kembali di masa mendatang. Manajemen melibatkan
memutuskan bagaimana mengklasifikasikan komponen sehingga dapat ditemukan, membuat
komponen tersedia baik dalam repositori atau sebagai layanan, memelihara informasi tentang
penggunaan komponen dan melacak versi komponen yang berbeda. Jika komponen adalah
open source, Anda dapat membuatnya tersedia di repositori publik seperti Sourceforge. Jika
dimaksudkan untuk digunakan di perusahaan, maka Anda dapat menggunakan sistem repositori internal.
Perusahaan dengan program penggunaan kembali dapat melakukan beberapa bentuk
sertifikasi komponen sebelum komponen tersedia untuk digunakan kembali. Sertifikasi berarti bahwa
Memodifikasi
Garis besar
Identifikasi Kandidat Persyaratan
Sistem
Komponen Menurut Ditemukan
Persyaratan
Komponen
Arsitektur Menyusun
Identifikasi Kandidat
Komponen untuk
Rancangan Komponen
Gambar 17.7 CBSE dengan Buat Sistem
penggunaan kembali
seseorang selain pengembang memeriksa kualitas komponen. Mereka menguji komponen

dan menyatakan bahwa komponen tersebut telah mencapai standar kualitas yang dapat
diterima, sebelum tersedia untuk digunakan kembali. Namun, ini bisa menjadi proses yang
mahal dan banyak perusahaan hanya menyerahkan pengujian dan pemeriksaan kualitas kepada pengembang kompon
17.2.2 CBSE dengan penggunaan kembali
Keberhasilan penggunaan kembali komponen memerlukan proses pengembangan yang

disesuaikan dengan CBSE. CBSE dengan proses reuse harus mencakup aktivitas yang
menemukan dan mengintegrasikan komponen yang dapat digunakan kembali. Struktur
proses seperti itu dibahas dalam Bab 2 dan Gambar 17.7 menunjukkan kegiatan utama dalam
proses itu. Beberapa aktivitas dalam proses ini, seperti penemuan awal kebutuhan pengguna,
dilakukan dengan cara yang sama seperti pada proses perangkat lunak lainnya. Namun,
perbedaan penting antara CBSE dengan penggunaan kembali dan proses perangkat lunak
untuk pengembangan perangkat lunak asli adalah:
1. Persyaratan pengguna awalnya dikembangkan secara garis besar daripada detail, dan
pemangku kepentingan didorong untuk sefleksibel mungkin dalam mendefinisikan
persyaratan mereka. Persyaratan yang terlalu spesifik membatasi jumlah komponen
yang dapat memenuhi persyaratan tersebut. Namun, tidak seperti pengembangan
inkremental, Anda memerlukan seperangkat persyaratan lengkap sehingga Anda dapat
mengidentifikasi sebanyak mungkin komponen untuk digunakan kembali.
2. Persyaratan disempurnakan dan dimodifikasi di awal proses tergantung pada komponen

yang tersedia. Jika persyaratan pengguna tidak dapat dipenuhi dari komponen yang
tersedia, Anda harus mendiskusikan persyaratan terkait yang dapat didukung. Pengguna
mungkin bersedia berubah pikiran jika ini berarti pengiriman sistem yang lebih murah
atau lebih cepat.
3. Adanya aktivitas pencarian komponen dan penyempurnaan desain lebih lanjut setelah
arsitektur sistem dirancang. Beberapa komponen yang tampaknya dapat digunakan
mungkin menjadi tidak cocok atau tidak berfungsi dengan baik dengan komponen lain yang dipilih.
Meskipun tidak ditunjukkan pada Gambar 17.7, ini menyiratkan bahwa perubahan
persyaratan lebih lanjut mungkin diperlukan.
Gambar 17.8
Identifikasi Komponen Komponen Komponen
Mencari Pilihan Validasi
komponen
proses
4. Pengembangan adalah proses komposisi dimana komponen-komponen yang ditemukan

terintegrasi. Ini melibatkan pengintegrasian komponen dengan infrastruktur model
komponen dan, seringkali, mengembangkan adaptor yang menyatukan antarmuka
komponen yang tidak kompatibel. Tentu saja, fungsionalitas tambahan mungkin juga
diperlukan di atas dan di atas yang disediakan oleh komponen yang digunakan kembali.
Tahap desain arsitektur sangat penting. Jacobson dkk. (1997) menemukan bahwa
mendefinisikan arsitektur yang kuat sangat penting untuk keberhasilan penggunaan
kembali. Selama aktivitas desain arsitektur, Anda dapat memilih model komponen dan
platform implementasi. Namun, banyak perusahaan memiliki platform pengembangan
standar (misalnya, .NET) sehingga model komponen telah ditentukan sebelumnya. Seperti
yang saya diskusikan di Bab 6, Anda juga menetapkan organisasi tingkat tinggi dari
sistem pada tahap ini dan membuat keputusan tentang distribusi dan kontrol sistem.
Aktivitas yang unik untuk proses CBSE adalah mengidentifikasi calon komponen atau
layanan untuk digunakan kembali. Ini melibatkan sejumlah subkegiatan, seperti yang
ditunjukkan pada Gambar 17.8. Awalnya, fokus Anda harus pada pencarian dan seleksi.
Anda perlu meyakinkan diri sendiri bahwa ada komponen yang tersedia untuk memenuhi kebutuhan Anda.
Jelas, Anda harus melakukan pemeriksaan awal bahwa komponen tersebut cocok tetapi
pengujian terperinci mungkin tidak diperlukan. Pada tahap selanjutnya, setelah arsitektur
sistem dirancang, Anda harus meluangkan lebih banyak waktu untuk validasi komponen.
Anda harus yakin bahwa komponen yang diidentifikasi benar-benar cocok untuk aplikasi
Anda; jika tidak, maka Anda harus mengulang proses pencarian dan seleksi.
Langkah pertama dalam mengidentifikasi komponen adalah mencari komponen yang
tersedia secara lokal atau dari pemasok terpercaya. Seperti yang saya katakan di bagian
sebelumnya, hanya ada sedikit vendor komponen sehingga kemungkinan besar Anda
akan mencari komponen yang telah dikembangkan di perusahaan Anda sendiri.
Perusahaan pengembang perangkat lunak dapat membangun database mereka sendiri
untuk komponen yang dapat digunakan kembali tanpa risiko yang melekat dalam
penggunaan komponen dari pemasok eksternal. Atau, Anda dapat memutuskan untuk
mencari pustaka kode yang tersedia di Web, seperti Sourceforge atau Google Code, untuk
melihat apakah kode sumber untuk komponen yang Anda butuhkan tersedia. Jika Anda
mencari layanan, maka ada sejumlah mesin pencari web khusus yang tersedia yang dapat menemukan layanan web p
Setelah proses pencarian komponen mengidentifikasi komponen yang mungkin, Anda
harus memilih komponen kandidat untuk penilaian. Dalam beberapa kasus, ini akan
menjadi tugas yang mudah. Komponen dalam daftar akan langsung mengimplementasikan
persyaratan pengguna dan tidak akan ada komponen pesaing yang cocok dengan
persyaratan ini. Namun, dalam kasus lain, proses seleksi jauh lebih kompleks. Tidak akan
ada pemetaan persyaratan yang jelas ke dalam komponen dan Anda mungkin menemukan
bahwa beberapa komponen harus diintegrasikan untuk memenuhi persyaratan atau kelompok persyaratan tertentu.
Kegagalan peluncur Ariane 5
Saat mengembangkan peluncur luar angkasa Ariane 5, para perancang memutuskan untuk menggunakan kembali perangkat
lunak referensi inersia yang telah berhasil dilakukan di peluncur Ariane 4. Perangkat lunak referensi inersia menjaga stabilitas
roket. Mereka memutuskan untuk menggunakan kembali ini tanpa perubahan (seperti yang akan Anda lakukan dengan
komponen), meskipun itu menyertakan fungsionalitas tambahan yang tidak diperlukan di Ariane 5.
Dalam peluncuran pertama Ariane 5, perangkat lunak navigasi inersia gagal dan roket tidak dapat dikendalikan.
Pengendali darat menginstruksikan peluncur untuk menghancurkan diri sendiri dan roket serta muatannya dihancurkan.
Penyebab masalah adalah pengecualian yang tidak tertangani ketika konversi nomor titik tetap ke bilangan bulat menghasilkan
luapan numerik. Hal ini menyebabkan sistem run-time untuk mematikan sistem referensi inersia dan stabilitas peluncur tidak
dapat dipertahankan. Kesalahan tidak pernah terjadi di Ariane 4 karena memiliki mesin yang kurang bertenaga dan nilai yang
dikonversi tidak cukup besar untuk konversi ke overflow.
Kesalahan terjadi pada kode yang tidak diperlukan untuk Ariane 5. Tes validasi untuk perangkat lunak yang digunakan kembali adalah:
berdasarkan persyaratan Ariane 5. Karena tidak ada persyaratan untuk fungsi yang gagal, tidak ada pengujian yang
dikembangkan. Akibatnya, masalah dengan perangkat lunak tidak pernah ditemukan selama tes simulasi peluncuran.
Oleh karena itu, Anda harus memutuskan komposisi komponen mana yang memberikan usia
Gambar 17.9 Contoh
perlindungan terbaik dari persyaratan.
kegagalan validasi dengan
perangkat lunak yang Setelah Anda memilih komponen untuk kemungkinan penyertaan dalam sistem, Anda kemudian
digunakan kembali
harus memvalidasinya untuk memeriksa apakah mereka berperilaku seperti yang diiklankan.
Tingkat validasi yang diperlukan tergantung pada sumber komponen. Jika Anda menggunakan
komponen yang telah dikembangkan oleh sumber yang dikenal dan terpercaya, Anda mungkin
memutuskan bahwa pengujian komponen tidak diperlukan. Anda cukup menguji komponen
tersebut saat sudah terintegrasi dengan komponen lain. Di sisi lain, jika Anda menggunakan
komponen dari sumber yang tidak dikenal, Anda harus selalu memeriksa dan menguji komponen
tersebut sebelum memasukkannya ke dalam sistem Anda.
Validasi komponen melibatkan pengembangan satu set kasus uji untuk suatu komponen (atau,
mungkin, memperluas kasus uji yang disertakan dengan komponen itu) dan mengembangkan
rangkaian uji untuk menjalankan pengujian komponen. Masalah utama dengan validasi komponen
adalah bahwa spesifikasi komponen mungkin tidak cukup rinci untuk memungkinkan Anda
mengembangkan serangkaian pengujian komponen yang lengkap. Komponen biasanya ditentukan
untuk informasi, dengan satu-satunya dokumentasi formal adalah spesifikasi antarmukanya. Ini
mungkin tidak mencakup informasi yang cukup bagi Anda untuk mengembangkan serangkaian
pengujian lengkap yang akan meyakinkan Anda bahwa antarmuka komponen yang diiklankan adalah yang Anda butuhkan.
Selain menguji bahwa komponen untuk digunakan kembali melakukan apa yang Anda perlukan,
Anda mungkin juga harus memeriksa bahwa komponen tersebut tidak menyertakan kode berbahaya
atau fungsionalitas yang tidak Anda perlukan. Pengembang profesional jarang menggunakan
komponen dari sumber yang tidak dipercaya, terutama jika sumber tersebut tidak menyediakan
kode sumber. Oleh karena itu, masalah kode berbahaya biasanya tidak muncul. Namun, komponen
mungkin sering berisi fungsionalitas yang tidak Anda perlukan dan Anda harus memeriksa bahwa
fungsionalitas ini tidak akan mengganggu penggunaan komponen oleh Anda.
Masalah dengan fungsionalitas yang tidak perlu adalah mungkin diaktifkan oleh komponen itu
sendiri. Ini dapat memperlambat komponen, menyebabkannya menghasilkan hasil yang
mengejutkan atau, dalam beberapa kasus, menyebabkan kegagalan sistem yang serius. Gambar
17.9 merangkum situasi di mana fungsionalitas yang tidak perlu dalam sistem yang digunakan
kembali menyebabkan kegagalan perangkat lunak yang dahsyat.
Masalah pada peluncur Ariane 5 muncul karena asumsi yang dibuat tentang perangkat
lunak untuk Ariane 4 tidak valid untuk Ariane 5. Ini adalah masalah umum dengan
komponen yang dapat digunakan kembali. Mereka awalnya diimplementasikan untuk
lingkungan aplikasi dan, tentu saja, menanamkan asumsi tentang lingkungan itu. Asumsi
ini jarang didokumentasikan sehingga, ketika komponen digunakan kembali, tidak
mungkin untuk memperoleh tes untuk memeriksa apakah asumsi tersebut masih valid.
Jika Anda menggunakan kembali komponen di lingkungan yang berbeda, Anda mungkin
tidak menemukan asumsi lingkungan tertanam sampai Anda menggunakan komponen dalam sistem operasional.
17.3 Komposisi komponen
Komposisi komponen adalah proses pengintegrasian komponen satu sama lain, dan
dengan 'kode lem' yang ditulis khusus untuk membuat sistem atau komponen lain. Ada
beberapa cara berbeda di mana Anda dapat menyusun komponen, seperti yang ditunjukkan pada Gambar 17.10.
Dari kiri ke kanan diagram ini menggambarkan komposisi berurutan, komposisi hierarki
dan komposisi aditif. Dalam pembahasan di bawah ini, saya berasumsi bahwa Anda
sedang menyusun dua komponen (A dan B) untuk membuat komponen baru:
1. Komposisi berurutan adalah situasi (a) pada Gambar 17.10. Anda membuat komponen
baru dari 2 komponen yang ada dengan memanggil komponen yang ada secara berurutan.
Anda dapat menganggap komposisi sebagai komposisi 'menyediakan antarmuka'.
Artinya, layanan yang ditawarkan oleh komponen A dipanggil dan hasil yang
dikembalikan oleh A kemudian digunakan dalam panggilan ke layanan yang
ditawarkan oleh komponen B. Komponen tidak saling memanggil dalam komposisi
berurutan. Beberapa kode glue tambahan diperlukan untuk memanggil layanan
komponen dalam urutan yang benar dan untuk memastikan bahwa hasil yang
dikirimkan oleh komponen A kompatibel dengan input yang diharapkan oleh
komponen B. Antarmuka 'menyediakan' komposisi bergantung pada fungsionalitas
gabungan dari A dan B tetapi biasanya tidak akan menjadi komposisi 'menyediakan
antarmuka' mereka. Jenis komposisi ini dapat digunakan dengan komponen yang merupakan elemen program a
2. Komposisi hierarki adalah situasi (b) pada Gambar 17.10. Jenis komposisi ini terjadi
ketika satu komponen memanggil secara langsung layanan yang disediakan oleh
komponen lain. Komponen yang dipanggil menyediakan layanan yang dibutuhkan
oleh komponen pemanggil. Oleh karena itu, antarmuka 'menyediakan' dari komponen
yang dipanggil harus kompatibel dengan antarmuka 'memerlukan' dari komponen yang dipanggil.
Komponen A memanggil komponen B secara langsung dan, jika antarmukanya
cocok, mungkin tidak diperlukan kode tambahan. Namun, jika ada ketidakcocokan
antara antarmuka 'memerlukan' A dan antarmuka 'menyediakan' B, maka beberapa
kode konversi mungkin diperlukan. Karena layanan tidak memiliki antarmuka
'memerlukan', mode komposisi ini tidak digunakan saat komponen diimplementasikan sebagai layanan web.
3. Komposisi aditif sesuai dengan situasi (c) pada Gambar 17.10. Hal ini terjadi ketika dua
atau lebih komponen disatukan (ditambahkan) untuk membuat komponen baru,
17.3 Komposisi komponen 469
SEBUAH SEBUAH
SEBUAH
B
B B
Gambar 17.10 Jenis

komposisi komponen (sebuah) (b) (c)
yang menggabungkan fungsi mereka. Antarmuka 'menyediakan' dan antarmuka

'memerlukan' komponen baru adalah kombinasi dari antarmuka yang sesuai dalam
komponen A dan B. Komponen dipanggil secara terpisah melalui antarmuka eksternal
dari komponen yang disusun. A dan B tidak tergantung dan tidak saling memanggil.
Jenis komposisi ini dapat digunakan dengan komponen yang merupakan unit program
atau komponen yang bersifat jasa.
Anda dapat menggunakan semua bentuk komposisi komponen saat membuat sistem.
Dalam semua kasus, Anda mungkin harus menulis 'kode lem' yang menghubungkan
komponen. Misalnya, untuk komposisi berurutan, output komponen A biasanya menjadi
input ke komponen B. Anda memerlukan pernyataan perantara yang memanggil komponen
A, mengumpulkan hasilnya, dan kemudian memanggil komponen B dengan hasil tersebut
sebagai parameter. Ketika satu komponen memanggil yang lain, Anda mungkin perlu
memperkenalkan komponen perantara yang memastikan bahwa antarmuka 'menyediakan' dan antarmuka 'memerluk
Saat Anda menulis komponen baru terutama untuk komposisi, Anda harus mendesain
antarmuka komponen ini agar kompatibel dengan komponen lain dalam sistem. Oleh karena
itu, Anda dapat dengan mudah menyusun komponen-komponen ini menjadi satu kesatuan.
Namun, ketika komponen dikembangkan secara independen untuk digunakan kembali,
Anda akan sering dihadapkan pada ketidakcocokan antarmuka. Ini berarti antarmuka
komponen yang ingin Anda buat tidak sama. Tiga jenis ketidakcocokan dapat terjadi:
1. Ketidakcocokan parameter Operasi pada setiap sisi antarmuka memiliki nama yang sama
tetapi jenis parameter atau jumlah parameternya berbeda.
2. Ketidakcocokan operasi Nama operasi dalam antarmuka 'menyediakan' dan 'memerlukan'

berbeda.
3. Ketidaklengkapan operasi Antarmuka 'menyediakan' suatu komponen adalah subset dari

antarmuka 'memerlukan' komponen lain atau sebaliknya.
Dalam semua kasus, Anda mengatasi masalah ketidakcocokan dengan menulis adaptor
yang merekonsiliasi antarmuka dari dua komponen yang digunakan kembali. Komponen
adaptor mengubah satu antarmuka ke antarmuka lainnya. Bentuk yang tepat dari adaptor tergantung pada jenisnya
lokasi string (string pn)
phoneDatabase (perintah string) pemilik string (string pn)

pencari alamat
string propertyType (string pn)
displayMap (string postCode, skala)

mapDB (perintah string)
pembuat peta
Gambar 17.11 printMap (kode pos string, skala)
Komponen dengan
antarmuka yang tidak kompatibel
komposisi. Terkadang, seperti pada contoh berikutnya, adaptor mengambil hasil dari satu
komponen dan mengubahnya menjadi bentuk yang dapat digunakan sebagai input ke
komponen lainnya. Dalam kasus lain, adaptor dapat dipanggil oleh komponen A sebagai proxy untuk komponen B.
Situasi ini terjadi jika A ingin memanggil B tetapi detail antarmuka 'memerlukan' A tidak
cocok dengan detail antarmuka 'menyediakan' B. Adaptor merekonsiliasi perbedaan ini
dengan mengubah parameter inputnya dari A menjadi input yang diperlukan parameter
untuk B. Kemudian memanggil B untuk memberikan layanan yang dibutuhkan oleh A.
Untuk mengilustrasikan adaptor, pertimbangkan dua komponen yang ditunjukkan pada
Gambar 17.11, yang antarmukanya tidak kompatibel. Ini mungkin bagian dari sistem yang
digunakan oleh layanan darurat. Saat operator darurat menerima panggilan, nomor telepon
dimasukkan ke komponen pencari alamat untuk menemukan alamat. Kemudian, dengan
menggunakan komponen mapper, operator mencetak peta untuk dikirim ke kendaraan
yang diberangkatkan ke keadaan darurat. Sebenarnya, komponen akan memiliki antarmuka
yang lebih kompleks daripada yang ditampilkan di sini, tetapi versi yang disederhanakan
menggambarkan konsep adaptor.
Komponen pertama, addressFinder, menemukan alamat yang cocok dengan nomor
telepon. Itu juga dapat mengembalikan pemilik properti yang terkait dengan nomor telepon
dan jenis properti. Komponen mapper mengambil kode pos (di Amerika Serikat, kode ZIP
standar dengan empat digit tambahan yang mengidentifikasi lokasi properti) dan
menampilkan atau mencetak peta jalan area di sekitar kode tersebut pada skala tertentu.
Komponen-komponen ini pada prinsipnya dapat dikomposisi karena lokasi properti
menyertakan kode pos atau ZIP. Namun, Anda harus menulis komponen adaptor yang
disebut postCodeStripper yang mengambil data lokasi dari addressFinder dan menghapus
kode pos. Kode pos ini kemudian digunakan sebagai input ke mapper dan peta jalan
ditampilkan dalam skala 1:10.000. Kode berikut, yang merupakan contoh komposisi
berurutan, menggambarkan urutan panggilan yang diperlukan untuk mengimplementasikan
ini:
alamat = addressFinder.location (nomor telepon); postCode =

postCodeStripper.getPostCode (alamat); mapper.displayMap(Kodepos,
10.000);
tambahkanSensor
hapusSensor
Mulailah manajemen sensor
mulaiSensor
berhenti stopSensor
Sensor Adaptor Pengumpul data
testSensor
sensorData inisialisasi
dapatkan data
Gambar 17.12 daftar
Adaptor yang laporanSemua

menghubungkan pengumpul data dan sensor
Kasus lain di mana komponen adaptor dapat digunakan adalah dalam posisi komposisi
hierarkis, di mana satu komponen ingin menggunakan komponen lain tetapi ada
ketidaksesuaian antara antarmuka 'menyediakan' dan antarmuka 'memerlukan' komponen
dalam komposisi. Saya telah mengilustrasikan penggunaan adaptor pada Gambar 17.12 di
mana adaptor digunakan untuk menghubungkan pengumpul data dan komponen sensor. Ini
dapat digunakan dalam penerapan sistem stasiun cuaca hutan belantara, seperti yang dibahas
dalam Bab 7.
Komponen sensor dan pengumpul data disusun menggunakan adaptor yang menyatukan
antarmuka 'memerlukan' komponen pengumpulan data dengan antarmuka 'menyediakan'
komponen sensor. Komponen pengumpul data telah dirancang dengan antarmuka
'memerlukan' generik yang mendukung pengumpulan data sensor dan manajemen sensor.
Untuk setiap operasi ini, parameternya adalah string teks yang mewakili perintah sensor
tertentu. Misalnya, untuk mengeluarkan perintah kumpulkan, Anda akan mengatakan
sensorData("collect"). Seperti yang saya tunjukkan pada Gambar 17.12, sensor itu sendiri
memiliki operasi terpisah seperti start, stop, dan getdata.
Adaptor mem-parsing string input, mengidentifikasi perintah (misalnya, mengumpulkan)

dan kemudian memanggil Sensor.getdata untuk mengumpulkan nilai sensor. Kemudian
mengembalikan hasilnya (sebagai string karakter) ke komponen pengumpul data. Gaya
antarmuka ini berarti bahwa pengumpul data dapat berinteraksi dengan berbagai jenis sensor.
Adaptor terpisah, yang mengubah perintah sensor dari Pengumpul data ke antarmuka sensor
sebenarnya, diimplementasikan untuk setiap jenis sensor.
Pembahasan komposisi komponen di atas mengasumsikan Anda dapat mengetahui dari
dokumentasi komponen apakah antarmuka kompatibel atau tidak. Tentu saja, definisi
antarmuka mencakup nama operasi dan jenis parameter, sehingga Anda dapat membuat
penilaian kompatibilitas dari ini. Namun, Anda bergantung pada dokumentasi komponen
untuk memutuskan apakah antarmuka kompatibel secara semantik.
Untuk mengilustrasikan masalah ini, perhatikan komposisi yang ditunjukkan pada Gambar
17.13. Komponen-komponen ini digunakan untuk mengimplementasikan sistem yang
mengunduh gambar dari kamera digital dan menyimpannya di perpustakaan foto. Pengguna
sistem dapat memberikan informasi tambahan untuk mendeskripsikan dan membuat katalog foto. Untuk menghindari
dapatkan gambar
Tambahkan Barang
Gambar
Adaptor
Pengelola
Foto mengambil
Perpustakaan
getCatalogEntry
kucingMasuk
Pengguna
Gambar 17.13 Komposisi Antarmuka
perpustakaan foto
Saya belum menunjukkan semua metode antarmuka di sini. Sebaliknya, saya hanya
menunjukkan metode yang diperlukan untuk menggambarkan masalah dokumentasi
komponen. Metode dalam antarmuka Photo Library adalah:
public void addItem (Identifier pid ; Foto p; CatalogEntry photodesc); pengambilan foto publik (ID pengenal);
KatalogEntry catEntry publik (Pid pengenal);
Asumsikan bahwa dokumentasi untuk metode addItem di Perpustakaan Foto adalah:
Metode ini menambahkan foto ke perpustakaan dan mengaitkan pengidentifikasi

foto dan deskriptor katalog dengan foto tersebut.
Deskripsi ini tampaknya menjelaskan apa yang dilakukan komponen, tetapi pertimbangkan:
pertanyaan berikut:
• Apa yang terjadi jika pengenal foto sudah dikaitkan dengan foto?
di dalam perpustakaan?
• Apakah deskriptor foto terkait dengan entri katalog serta foto? Artinya, jika Anda
menghapus foto, apakah Anda juga menghapus informasi katalog?
Tidak ada informasi yang cukup dalam deskripsi informal addItem untuk menjawab
pertanyaan-pertanyaan ini. Tentu saja, dimungkinkan untuk menambahkan lebih banyak
informasi ke deskripsi bahasa alami metode ini, tetapi secara umum, cara terbaik untuk
menyelesaikan ambiguitas adalah dengan menggunakan bahasa formal untuk
menggambarkan antarmuka. Spesifikasi yang ditunjukkan pada Gambar 17.14 adalah
bagian dari deskripsi antarmuka Perpustakaan Foto yang menambahkan informasi ke deskripsi informal.
Spesifikasi pada Gambar 17.14 menggunakan kondisi pra dan pasca yang didefinisikan
dalam notasi berdasarkan bahasa kendala objek (OCL), yang merupakan bagian dari UML
(Warmer dan Kleppe, 2003). OCL dirancang untuk menggambarkan batasan dalam model
objek UML; itu memungkinkan Anda untuk mengekspresikan predikat yang harus selalu benar, yang harus
— Kata kunci konteks menamai komponen yang ketentuannya berlaku

konteks tambahkanItem
— Prasyarat menentukan apa yang harus benar sebelum eksekusi addItem

pra: PhotoLibrary.libSize() > 0
PhotoLibrary.retrieve(pid) = null
— Postconditions menentukan apa yang benar setelah eksekusi

pos: libSize () = libSize()@pre + 1
PhotoLibrary.retrieve(pid) = p
PhotoLibrary.catEntry(pid) = photodesc
hapus konteks
pra: PhotoLibrary.retrieve(pid) <>null ;
pos: PhotoLibrary.retrieve(pid) = null

PhotoLibrary.catEntry(pid) = PhotoLibrary.catEntry(pid)@pre
PhotoLibrary.libSize() = libSize()@pre—1
true sebelum suatu metode dieksekusi; dan itu pasti benar setelah suatu metode terpotong. Ini
Gambar 17.14
adalah invarian, pra-kondisi, dan pasca-kondisi. Untuk mengakses nilai
Deskripsi OCL
dari Perpustakaan Foto variabel sebelum operasi, Anda menambahkan @pre setelah namanya. Oleh karena itu, menggunakan usia
antarmuka sebagai contoh:
umur = umur@pra + 1
Pernyataan ini berarti bahwa nilai usia setelah operasi adalah satu lebih dari itu
adalah sebelum operasi itu.
Pendekatan berbasis OCL semakin banyak digunakan untuk menambahkan informasi semantik ke UML
model, dan deskripsi OCL dapat digunakan untuk menggerakkan generator kode dalam model-driven
rekayasa. Pendekatan umum telah diturunkan dari Meyer's Design oleh
Pendekatan kontrak (Meyer, 1992), di mana antarmuka dan kewajiban berkomunikasi objek secara
formal ditentukan dan ditegakkan oleh sistem run-time. meyer
menyarankan bahwa menggunakan Design by Contract sangat penting jika kita ingin mengembangkan
komponen terpercaya (Meyer, 2003).
Gambar 17.14 menyertakan spesifikasi untuk metode addItem dan delete di
Perpustakaan Foto. Metode yang ditentukan ditunjukkan oleh konteks kata kunci dan
kondisi pra dan pasca dengan kata kunci pra dan pasca. Prasyarat untuk
addItem menyatakan bahwa:
1. Tidak boleh ada foto di perpustakaan dengan pengenal yang sama dengan
foto yang akan dimasukkan.
2. Perpustakaan harus ada — asumsikan bahwa membuat perpustakaan menambahkan satu item ke dalamnya sehingga
bahwa ukuran perpustakaan selalu lebih besar dari nol.

3. Kondisi akhir untuk addItem menyatakan bahwa:
Ukuran perpustakaan telah meningkat sebesar 1 (jadi hanya satu entri yang dibuat).
Jika Anda mengambil menggunakan pengenal yang sama, maka Anda mendapatkan kembali
foto yang Anda tambahkan.
Jika Anda mencari katalog menggunakan pengenal itu, Anda mendapatkan kembali
entri katalog yang Anda buat.
Spesifikasi penghapusan memberikan informasi lebih lanjut. Prasyarat menyatakan

bahwa untuk menghapus item, item harus ada di perpustakaan dan, setelah dihapus, foto
tidak dapat diambil lagi dan ukuran perpustakaan dikurangi 1. Namun, hapus tidak
menghapus entri katalog— Anda masih dapat mengambilnya kembali setelah foto dihapus.
Alasan untuk ini adalah Anda mungkin ingin menyimpan informasi di catatan kucing tentang
mengapa foto dihapus, lokasi barunya, dan sebagainya.
Saat Anda membuat sistem dengan menyusun komponen, Anda mungkin menemukan
bahwa ada potensi konflik antara persyaratan fungsional dan non-fungsional, kebutuhan
untuk mengirimkan sistem secepat mungkin, dan kebutuhan untuk membuat sistem yang
dapat berkembang saat persyaratan berubah. Keputusan di mana Anda mungkin harus
mempertimbangkan trade-off adalah:
1. Komposisi komponen apa yang paling efektif untuk memberikan fungsi?

persyaratan untuk sistem?
2. Komposisi komponen apa yang akan memudahkan untuk mengadaptasi komposit?

komponen ketika persyaratannya berubah?
3. Apa yang akan menjadi sifat yang muncul dari sistem yang disusun? Ini adalah properti
seperti kinerja dan ketergantungan. Anda hanya dapat menilai ini setelah sistem
lengkap diimplementasikan.
Sayangnya, ada banyak situasi di mana solusi untuk masalah komposisi mungkin
bertentangan. Sebagai contoh, pertimbangkan situasi seperti yang diilustrasikan pada
Gambar 17.15, di mana sebuah sistem dapat dibuat melalui dua komposisi alternatif.
Sistem adalah sistem pengumpulan dan pelaporan data di mana data dikumpulkan dari
sumber yang berbeda, disimpan dalam database dan kemudian laporan yang berbeda
meringkas data yang dihasilkan.
Di sini, ada potensi konflik antara kemampuan beradaptasi dan kinerja.
Komposisi (a) lebih mudah beradaptasi tetapi komposisi (b) mungkin lebih cepat dan lebih
dapat diandalkan. Keuntungan komposisi (a) adalah pelaporan dan pengelolaan data
terpisah, sehingga lebih fleksibel untuk perubahan di masa mendatang. Sistem manajemen
data dapat diganti dan, jika laporan diperlukan yang tidak dapat dihasilkan oleh komponen
pelaporan yang ada, komponen tersebut juga dapat diganti tanpa harus mengubah
komponen manajemen data.
Dalam komposisi (b), komponen database dengan fasilitas pelaporan bawaan (misalnya,
Microsoft Access) digunakan. Keuntungan utama dari komposisi (b) adalah komponennya
lebih sedikit, jadi ini akan menjadi implementasi yang lebih cepat karena tidak ada komponen
Data Data Laporan

(sebuah)
Koleksi Pengelolaan Generator
Laporan
Gambar 17.15 Data

(b) Basis Data
Pengumpulan data dan Koleksi
Laporan
komponen pembuatan laporan
overhead komunikasi. Selanjutnya, aturan integritas data yang berlaku pada database juga
akan berlaku untuk laporan. Laporan ini tidak akan dapat menggabungkan data dengan
cara yang salah. Dalam komposisi (a), tidak ada kendala seperti itu sehingga bisa terjadi kesalahan dalam laporan.
Secara umum, prinsip komposisi yang baik untuk diikuti adalah prinsip pemisahan
kepentingan. Artinya, Anda harus mencoba merancang sistem Anda sedemikian rupa
sehingga setiap komponen memiliki peran yang jelas dan, idealnya, peran ini tidak boleh tumpang tindih.
Namun, mungkin lebih murah untuk membeli satu komponen multi-fungsi daripada dua
atau tiga komponen terpisah. Selain itu, mungkin ada ketergantungan atau penalti kinerja
ketika beberapa komponen digunakan.
POIN KUNCI
Rekayasa perangkat lunak berbasis komponen adalah pendekatan berbasis penggunaan kembali untuk mendefinisikan, mengimplementasikan,
dan menyusun komponen independen yang digabungkan secara longgar ke dalam sistem.
Komponen adalah unit perangkat lunak yang fungsionalitas dan ketergantungannya sepenuhnya ditentukan oleh
satu set antarmuka publik. Komponen dapat disusun dengan komponen lain tanpa mengetahui implementasinya
dan dapat digunakan sebagai unit yang dapat dieksekusi.
Komponen dapat diimplementasikan sebagai unit program yang termasuk dalam sistem atau sebagai eksternal
layanan yang direferensikan dari dalam suatu sistem.
Model komponen mendefinisikan seperangkat standar untuk komponen, termasuk standar antarmuka, standar
penggunaan, dan standar penerapan. Implementasi model komponen menyediakan satu set layanan umum
yang dapat digunakan oleh semua komponen.
Selama proses CBSE , Anda harus menyisipkan proses rekayasa persyaratan dan desain sistem. Anda harus
menukar persyaratan yang diinginkan dengan layanan yang tersedia dari komponen yang dapat digunakan
kembali.
Komposisi komponen adalah proses 'pengkabelan' komponen bersama-sama untuk membuat sebuah sistem.
Jenis komposisi meliputi komposisi sekuensial, komposisi hierarki, dan komposisi aditif.
Saat menyusun komponen yang dapat digunakan kembali yang belum ditulis untuk aplikasi Anda, Anda
mungkin perlu menulis adaptor atau 'kode lem' untuk merekonsiliasi antarmuka komponen yang berbeda.
Saat memilih komposisi, Anda harus mempertimbangkan fungsionalitas sistem yang diperlukan,
persyaratan non-fungsional dan kemudahan penggantian satu komponen ketika sistem diubah.
BACAAN LEBIH LANJUT
Rekayasa Perangkat Lunak Berbasis Komponen: Menyatukan Potongan. Buku ini adalah kumpulan
makalah dari berbagai penulis tentang berbagai aspek CBSE. Seperti semua koleksi, buku ini agak campuran
tetapi memiliki cakupan yang lebih baik tentang masalah umum rekayasa perangkat lunak dengan komponen
daripada buku Szyperski. (GT Heineman dan WT Councill, Addison-Wesley, 2001.)
Perangkat Lunak Komponen: Di Luar Pemrograman Berorientasi Objek, 2nd ed. Edisi terbaru dari buku
pertama CBSE ini mencakup masalah teknis dan nonteknis di CBSE. Ini memiliki lebih banyak detail tentang
teknologi spesifik daripada buku Heineman dan Councill dan mencakup diskusi menyeluruh tentang masalah
pasar. (C. Szyperski, Addison-Wesley, 2002.)
'Spesifikasi, Implementasi dan Penerapan Komponen'. Pengantar yang bagus untuk dasar-dasar
CBSE. Isu yang sama dari CACM mencakup artikel tentang komponen dan pengembangan berbasis
komponen. (I. Crnkovic, B. Hnich, T. Jonsson dan Z. Kiziltan, Comm. ACM, 45 (10), Oktober 2002.) http://
dx.doi.org/10.1145/570907.570928.
'Model Komponen Perangkat Lunak'. Ini adalah diskusi komprehensif tentang model komponen komersial
dan penelitian yang mengklasifikasikan model-model ini dan menjelaskan perbedaan di antara mereka. (KK.
Lau dan Z. Wang, IEEE Transactions on Software Engineering, 33 (10), Oktober 2007.)
http://dx.doi.org/10.1109/TSE.2007.70726.
LATIHAN
17.1. Mengapa penting bahwa semua interaksi komponen didefinisikan melalui antarmuka 'memerlukan'
dan 'menyediakan'?
17.2. Prinsip independensi komponen berarti harus dimungkinkan untuk mengganti satu
komponen dengan yang lain yang diimplementasikan dengan cara yang sama sekali berbeda. Dengan menggunakan sebuah
contoh, jelaskan bagaimana penggantian komponen tersebut dapat menimbulkan konsekuensi yang tidak diinginkan dan dapat
menyebabkan kegagalan sistem.
17.3. Apa perbedaan mendasar antara komponen sebagai elemen program dan?
komponen sebagai layanan?
17.4. Mengapa penting bahwa komponen harus didasarkan pada model komponen standar?
17.5. Menggunakan contoh komponen yang mengimplementasikan tipe data abstrak seperti tumpukan atau daftar, tunjukkan
mengapa biasanya diperlukan untuk memperluas dan mengadaptasi komponen untuk digunakan kembali.
17.6. Jelaskan mengapa sulit untuk memvalidasi komponen yang dapat digunakan kembali tanpa kode sumber komponen.
Dengan cara apa spesifikasi komponen formal menyederhanakan masalah validasi?
17.7. Rancang antarmuka 'menyediakan' dan antarmuka 'memerlukan' komponen yang dapat digunakan kembali yang mungkin
digunakan untuk mewakili pasien di MHC-PMS.
17.8. Dengan menggunakan contoh, gambarkan berbagai jenis adaptor yang diperlukan untuk mendukung komposisi
berurutan, komposisi hierarki, dan komposisi aditif.
17.9. Rancang antarmuka komponen yang mungkin digunakan dalam sistem untuk keadaan darurat
ruang kendali. Anda harus mendesain antarmuka untuk komponen pencatatan panggilan yang mencatat panggilan
yang dilakukan, dan komponen penemuan kendaraan yang, dengan kode pos (kode pos) dan jenis insiden, menemukan
kendaraan terdekat yang sesuai untuk dikirim ke insiden tersebut.
17.10. Disarankan bahwa otoritas sertifikasi independen harus dibentuk.

Vendor akan menyerahkan komponen mereka kepada otoritas ini, yang akan memvalidasi bahwa komponen
tersebut dapat dipercaya. Apa keuntungan dan kerugian dari otoritas sertifikasi semacam itu?
REFERENSI
Boehm, BW, Abts, C., Brown, AW, Chulani, S., Clark, BK, Horowitz, E., Madachy, R., Reifer, D. dan Steece, B. (2000). Estimasi
Biaya Perangkat Lunak dengan COCOMO II. Upper Saddle River, NJ.: Prentice Hall.
Councill, WT dan Heineman, GT (2001). 'Definisi Komponen Perangkat Lunak dan Elemennya'. Dalam Rekayasa Perangkat
Lunak Berbasis Komponen. Heineman, GT dan Councill, WT (ed.). Boston: Addison Wesley, 5–20.
Jacobson, I., Griss, M. dan Jonsson, P. (1997). Penggunaan Kembali Perangkat Lunak. Membaca, Mass.: Addison-Wesley.
Kotonya, G. (2003). 'Proses CBSE: Isu dan Visi Masa Depan'. Prok. Workshop CBSEnet ke-2, Budapest, Hongaria.
Lau, K.-K. dan Wang, Z. (2007). 'Model Komponen Perangkat Lunak'. IEEE Trans. pada Software Eng., 33 (10), 709–24.
Meyer, B. (1992). 'Desain berdasarkan Kontrak'. Komputer IEEE, 25 (10), 40–51.
Meyer, B. (2003). 'Tantangan Besar Komponen Tepercaya'. ICSE 25: Int. Kon. di Software Eng., Portland, Oregon: IEEE Press.
Mili, H., Mili, A., Yacoub, S. dan Addy, E. (2002). Rekayasa Perangkat Lunak berbasis penggunaan kembali. New
York: John Wiley & Sons.
Paus, A. (1997). Panduan Referensi CORBA: Memahami Arsitektur Broker Permintaan Objek Umum. Harlow,
Inggris: Addison-Wesley.
Szyperski, C. (2002). Perangkat Lunak Komponen: Di Luar Pemrograman Berorientasi Objek, 2nd ed. Harlow,
Inggris: Addison-Wesley.
Hangat, J. dan Kleppe, A. (2003). Bahasa Batasan Objek: Mempersiapkan model Anda untuk MDA. Boston: Addison-
Wesley.
Weinreich, R. dan Sametinger, J. (2001). 'Model Komponen dan Layanan Komponen: Konsep dan Prinsip'. Dalam Rekayasa
Perangkat Lunak Berbasis Komponen. Heineman, GT dan Councill, WT (ed.).
Boston: Addison-Wesley, 33–48.
18
Rekayasa perangkat
lunak terdistribusi
Tujuan
Tujuan dari bab ini adalah untuk memperkenalkan rekayasa sistem
terdistribusi dan arsitektur sistem terdistribusi. Setelah Anda membaca bab ini, Anda
akan:
mengetahui isu-isu kunci yang harus dipertimbangkan ketika merancang dan

mengimplementasikan sistem perangkat lunak terdistribusi;
memahami model komputasi klien-server dan berlapis

arsitektur sistem klien-server;
telah diperkenalkan ke pola yang umum digunakan untuk didistribusikan

arsitektur sistem dan mengetahui jenis sistem yang paling dapat diterapkan
pada setiap arsitektur;
memahami gagasan perangkat lunak sebagai layanan, menyediakan akses berbasis

web ke sistem aplikasi yang digunakan dari jarak jauh.
Isi
18.1 Masalah sistem terdistribusi 18.2
Komputasi klien-server 18.3 Pola
arsitektur untuk sistem terdistribusi 18.4 Perangkat lunak
sebagai layanan
480 Bab 18 Rekayasa perangkat lunak terdistribusi
Hampir semua sistem berbasis komputer besar sekarang adalah sistem terdistribusi. Sistem
terdistribusi adalah sistem yang melibatkan beberapa komputer, berbeda dengan sistem terpusat
di mana semua komponen sistem dijalankan pada satu komputer. Tanenbaum dan Van Steen
(2007) mendefinisikan sistem terdistribusi menjadi:
“. . .kumpulan komputer independen yang tampak bagi pengguna sebagai satu sistem yang
koheren.”
Jelas, rekayasa sistem terdistribusi memiliki banyak kesamaan dengan rekayasa perangkat
lunak lainnya. Namun, ada masalah khusus yang harus diperhitungkan saat merancang sistem
jenis ini. Ini muncul karena komponen sistem dapat berjalan pada komputer yang dikelola secara
independen dan mereka berkomunikasi melalui jaringan.
Coulouris dkk. (2005) mengidentifikasi keuntungan berikut menggunakan terdistribusi

pendekatan untuk pengembangan sistem:
1. Resource sharing Sebuah sistem terdistribusi memungkinkan berbagi sumber daya perangkat
keras dan perangkat lunak-seperti disk, printer, file, dan compiler-yang terkait dengan
komputer di jaringan.
2. Keterbukaan Sistem terdistribusi biasanya merupakan sistem terbuka, yang berarti bahwa
mereka dirancang berdasarkan protokol standar yang memungkinkan peralatan dan perangkat
lunak dari vendor yang berbeda untuk digabungkan.
3. Concurrency Dalam sistem terdistribusi, beberapa proses dapat beroperasi pada waktu yang
sama pada komputer terpisah di jaringan. Proses-proses ini mungkin (tetapi tidak perlu)
berkomunikasi satu sama lain selama operasi normalnya.
4. Skalabilitas Pada prinsipnya setidaknya, sistem terdistribusi dapat diskalakan karena

kemampuan sistem dapat ditingkatkan dengan menambahkan sumber daya baru untuk
mengatasi tuntutan baru pada sistem. Dalam praktiknya, jaringan yang menghubungkan
komputer individu dalam sistem dapat membatasi skalabilitas sistem.
5. Toleransi kesalahan Ketersediaan beberapa komputer dan potensi untuk mereplikasi informasi
berarti bahwa sistem terdistribusi dapat toleran terhadap beberapa kegagalan perangkat
keras dan perangkat lunak (lihat Bab 13). Di sebagian besar sistem terdistribusi, layanan
terdegradasi dapat diberikan ketika terjadi kegagalan; hilangnya layanan sepenuhnya hanya
terjadi ketika ada kegagalan jaringan.
Untuk sistem organisasi skala besar, keunggulan ini berarti bahwa sistem terdistribusi sebagian
besar telah menggantikan sistem warisan mainframe yang dikembangkan pada 1990-an. Namun,
ada banyak sistem aplikasi komputer pribadi (misalnya, sistem pengeditan foto) yang tidak
didistribusikan dan dijalankan pada satu sistem komputer.
Sebagian besar sistem tertanam juga merupakan sistem prosesor tunggal.
Sistem terdistribusi secara inheren lebih kompleks daripada sistem terpusat. Hal ini membuat
mereka lebih sulit untuk merancang, mengimplementasikan, dan menguji. Lebih sulit untuk
memahami sifat yang muncul dari sistem terdistribusi karena kompleksitas dari
18.1 Masalah sistem terdistribusi 481
interaksi antara komponen sistem dan infrastruktur sistem. Misalnya, daripada kinerja sistem yang
bergantung pada kecepatan eksekusi satu prosesor, itu tergantung pada bandwidth jaringan, beban
jaringan, dan kecepatan semua komputer yang merupakan bagian dari sistem. Memindahkan sumber
daya dari satu bagian sistem ke bagian lain dapat mempengaruhi kinerja sistem secara signifikan.
Lebih jauh, seperti yang diketahui oleh semua pengguna WWW, sistem terdistribusi tidak dapat
diprediksi dalam responsnya. Waktu respons tergantung pada beban keseluruhan pada sistem,
arsitekturnya, dan beban jaringan. Karena semua ini dapat berubah dalam waktu singkat, waktu yang
dibutuhkan untuk menanggapi permintaan pengguna dapat bervariasi secara dramatis dari satu permintaan ke permintaan lainnya.
Perkembangan terpenting yang mempengaruhi sistem perangkat lunak terdistribusi dalam beberapa
tahun terakhir adalah pendekatan berorientasi layanan. Sebagian besar bab ini berfokus pada masalah
umum sistem terdistribusi, tetapi saya membahas gagasan aplikasi yang digunakan sebagai layanan di
Bagian 18.4. Ini melengkapi materi dalam Bab 19, yang berfokus pada layanan sebagai komponen dalam
arsitektur berorientasi layanan, dan masalah yang lebih umum dari rekayasa perangkat lunak berorientasi
layanan.
18.1 Masalah sistem terdistribusi

Seperti yang saya bahas dalam pengantar bab ini, sistem terdistribusi lebih kompleks daripada sistem
yang berjalan pada satu prosesor. Kompleksitas ini muncul karena secara praktis tidak mungkin untuk
memiliki model kontrol top-down dari sistem ini. Node dalam sistem yang memberikan fungsionalitas
seringkali merupakan sistem independen tanpa otoritas tunggal yang bertanggung jawab atas mereka.
Jaringan yang menghubungkan node-node ini adalah sistem yang dikelola secara terpisah. Ini adalah
sistem yang kompleks dalam dirinya sendiri dan tidak dapat dikendalikan oleh pemilik sistem yang
menggunakan jaringan. Oleh karena itu ada ketidakpastian yang melekat dalam pengoperasian sistem
terdistribusi yang harus diperhitungkan oleh perancang sistem.
Beberapa masalah desain yang paling penting yang harus dipertimbangkan dalam rekayasa sistem
terdistribusi adalah:
1. Transparansi Sejauh mana sistem terdistribusi harus terlihat oleh pengguna sebagai satu sistem?
Kapan berguna bagi pengguna untuk memahami bahwa sistem terdistribusi?
2. Keterbukaan Haruskah sistem dirancang menggunakan protokol standar yang mendukung

interoperabilitas atau haruskah protokol yang lebih khusus digunakan yang membatasi kebebasan
perancang?
3. Skalabilitas Bagaimana sistem dapat dibangun sehingga skalabel? Yaitu, bagaimana keseluruhan
sistem dapat dirancang sehingga kapasitasnya dapat ditingkatkan sebagai respons terhadap
peningkatan permintaan yang dibuat pada sistem?
4. Keamanan Bagaimana kebijakan keamanan yang dapat digunakan didefinisikan dan diimplementasikan yang
berlaku di seluruh rangkaian sistem yang dikelola secara independen?
CORBA – Arsitektur Perantara Permintaan Objek Umum
CORBA adalah spesifikasi terkenal untuk sistem middleware yang dikembangkan pada 1990-an oleh Object
Management Group. Ini dimaksudkan sebagai standar terbuka yang memungkinkan pengembangan
middleware untuk mendukung komunikasi dan eksekusi komponen terdistribusi, ditambah menyediakan
serangkaian layanan standar yang dapat digunakan oleh komponen ini.
Beberapa implementasi CORBA diproduksi tetapi sistem tidak pernah mencapai massa kritis. Pengguna lebih
suka sistem berpemilik atau pindah ke arsitektur berorientasi layanan.
http://www.SoftwareEngineering-9.com/Web/DistribSys/Corba.html
5. Kualitas layanan Bagaimana kualitas layanan yang diberikan kepada pengguna sistem
harus ditentukan dan bagaimana sistem harus diterapkan untuk memberikan kualitas
layanan yang dapat diterima untuk semua pengguna?
6. Manajemen kegagalan Bagaimana kegagalan sistem dapat dideteksi, ditampung (sehingga

memiliki efek minimal pada komponen lain dalam sistem), dan diperbaiki?
Di dunia yang ideal, fakta bahwa suatu sistem didistribusikan akan transparan bagi
pengguna. Ini berarti bahwa pengguna akan melihat sistem sebagai sistem tunggal yang
perilakunya tidak terpengaruh oleh cara sistem didistribusikan. Dalam praktiknya, hal ini
mustahil untuk dicapai. Kontrol pusat dari sistem terdistribusi tidak mungkin dan, sebagai
akibatnya, komputer individu dalam suatu sistem dapat berperilaku berbeda pada waktu yang berbeda.
Lebih jauh lagi, karena selalu membutuhkan waktu yang terbatas untuk mengirimkan sinyal
melintasi jaringan, penundaan jaringan tidak dapat dihindari. Lamanya penundaan ini
tergantung pada lokasi sumber daya dalam sistem, kualitas koneksi jaringan pengguna, dan
beban jaringan.
Pendekatan desain untuk mencapai transparansi bergantung pada pembuatan abstraksi
sumber daya dalam sistem terdistribusi sehingga realisasi fisik sumber daya ini dapat
diubah tanpa harus membuat perubahan dalam sistem aplikasi.
Middleware (dibahas dalam Bagian 18.1.2) digunakan untuk memetakan sumber daya logis
yang dirujuk oleh program ke sumber daya fisik yang sebenarnya, dan untuk mengelola
interaksi antara sumber daya ini.
Dalam praktiknya, tidak mungkin membuat sistem benar-benar transparan dan pengguna,
umumnya, sadar bahwa mereka berurusan dengan sistem terdistribusi. Oleh karena itu,
Anda dapat memutuskan bahwa yang terbaik adalah mengekspos distribusi kepada
pengguna. Mereka kemudian dapat dipersiapkan untuk beberapa konsekuensi distribusi
seperti penundaan jaringan, kegagalan node jarak jauh, dll.
Sistem terdistribusi terbuka adalah sistem yang dibangun sesuai dengan standar yang
berlaku umum. Ini berarti bahwa komponen dari pemasok mana pun dapat diintegrasikan ke
dalam sistem dan dapat beroperasi dengan komponen sistem lainnya. Pada tingkat jaringan,
keterbukaan sekarang diterima begitu saja dengan sistem yang sesuai dengan protokol
Internet tetapi pada tingkat komponen, keterbukaan masih belum universal.
Keterbukaan menyiratkan bahwa komponen sistem dapat dikembangkan secara independen
dalam bahasa pemrograman apa pun dan, jika ini sesuai dengan standar, mereka akan
bekerja dengan komponen lain.
Standar CORBA (Paus, 1997) yang dikembangkan pada 1990-an, dimaksudkan untuk
mencapai hal ini tetapi ini tidak pernah mencapai massa pengadopsi yang kritis. Sebaliknya,
banyak perusahaan memilih untuk mengembangkan sistem menggunakan standar kepemilikan
untuk komponen dari perusahaan seperti Sun dan Microsoft. Ini memberikan implementasi
yang lebih baik dan perangkat lunak pendukung dan dukungan jangka panjang yang lebih baik untuk protokol industri.
Standar layanan web (dibahas dalam Bab 19) untuk arsitektur berorientasi layanan
dikembangkan menjadi standar terbuka. Namun, ada penolakan yang signifikan terhadap
standar ini karena dianggap tidak efisien. Beberapa pengembang sistem berbasis es layanan
telah memilih apa yang disebut protokol RESTful karena ini memiliki overhead yang secara
inheren lebih rendah daripada protokol layanan web.
Skalabilitas suatu sistem mencerminkan kemampuannya untuk memberikan kualitas layanan
yang tinggi seiring dengan meningkatnya permintaan pada sistem. Neuman (1994) mengidentifikasi
tiga dimensi skalabilitas:
1. Ukuran Seharusnya dimungkinkan untuk menambahkan lebih banyak sumber daya ke sistem untuk mengatasinya
peningkatan jumlah pengguna.
2. Distribusi Komponen-komponen dari:

sistem tanpa menurunkan kinerjanya.
3. Manageability Harus dimungkinkan untuk mengelola sebuah sistem seiring bertambahnya

ukuran, bahkan jika bagian dari sistem berada di organisasi independen.
Dalam hal ukuran, ada perbedaan antara scaling up dan scaling out. Scaling up berarti
mengganti sumber daya dalam sistem dengan sumber daya yang lebih kuat. Misalnya, Anda
dapat menambah memori di server dari 16 GB menjadi 64 GB. Scaling out berarti menambahkan
sumber daya tambahan ke sistem (misalnya, server web tambahan untuk bekerja bersama
server yang ada). Scaling out seringkali lebih hemat biaya daripada scaling up tetapi biasanya
berarti bahwa sistem harus dirancang sehingga pemrosesan bersamaan dimungkinkan.
Saya telah membahas masalah keamanan umum dan masalah rekayasa keamanan di
Bagian 2 buku ini. Namun, ketika suatu sistem didistribusikan, jumlah cara sistem dapat
diserang meningkat secara signifikan, dibandingkan dengan sistem terpusat. Jika bagian dari
sistem berhasil diserang maka penyerang mungkin dapat menggunakan ini sebagai 'pintu
belakang' ke bagian lain dari sistem.
Jenis serangan yang harus dipertahankan oleh sistem terdistribusi adalah sebagai berikut:
1. Interception, dimana komunikasi antar bagian dari sistem disadap oleh penyerang sehingga
terjadi kehilangan kerahasiaan.
2. Interupsi, di mana layanan sistem diserang dan tidak dapat dikirimkan seperti yang
diharapkan. Serangan penolakan layanan melibatkan membombardir node dengan
permintaan layanan yang tidak sah sehingga tidak dapat menangani permintaan yang valid.
3. Modifikasi, dimana data atau layanan dalam sistem diubah oleh penyerang.
4. Fabrikasi, di mana penyerang menghasilkan informasi yang seharusnya tidak ada dan kemudian
menggunakannya untuk mendapatkan beberapa hak istimewa. Misalnya, penyerang dapat
membuat entri kata sandi palsu dan menggunakannya untuk mendapatkan akses ke sistem.
Kesulitan utama dalam sistem terdistribusi adalah menetapkan kebijakan keamanan yang
dapat diterapkan secara andal ke semua komponen dalam suatu sistem. Seperti yang saya
bahas di Bab 11, kebijakan keamanan menetapkan tingkat keamanan yang harus dicapai oleh
suatu sistem. Mekanisme keamanan, seperti enkripsi dan otentikasi, digunakan untuk
menegakkan kebijakan keamanan. Kesulitan dalam sistem terdistribusi muncul karena
organisasi yang berbeda mungkin memiliki bagian dari sistem. Organisasi-organisasi ini
mungkin memiliki kebijakan keamanan dan mekanisme keamanan yang saling tidak kompatibel.
Kompromi keamanan mungkin harus dilakukan agar sistem dapat bekerja sama.
Kualitas layanan (QoS) yang ditawarkan oleh sistem terdistribusi mencerminkan kemampuan
sistem untuk memberikan layanannya secara andal dan dengan waktu respons dan throughput
yang dapat diterima oleh penggunanya. Idealnya, persyaratan QoS harus ditentukan terlebih
dahulu dan sistem dirancang dan dikonfigurasi untuk memberikan QoS itu. Sayangnya, ini
tidak selalu praktis, karena dua alasan:
1. Mungkin tidak hemat biaya untuk merancang dan mengkonfigurasi sistem untuk memberikan
QoS yang tinggi di bawah beban puncak. Ini bisa melibatkan penyediaan sumber daya
yang tidak digunakan untuk sebagian besar waktu. Salah satu argumen utama untuk
'komputasi awan' adalah bahwa sebagian mengatasi masalah ini. Menggunakan cloud,
mudah untuk menambahkan sumber daya saat permintaan meningkat.
2. Parameter QoS mungkin saling bertentangan. Misalnya, peningkatan keandalan dapat berarti
pengurangan throughput, karena prosedur pemeriksaan diperkenalkan untuk memastikan
bahwa semua input sistem valid.
QoS sangat penting ketika sistem berurusan dengan data kritis waktu seperti aliran suara
atau video. Dalam keadaan ini, jika QoS turun di bawah nilai ambang batas maka suara atau
video dapat menjadi sangat rusak sehingga tidak mungkin untuk dipahami. Sistem yang
berhubungan dengan suara dan video harus mencakup negosiasi QoS dan komponen
manajemen. Ini harus mengevaluasi persyaratan QoS terhadap sumber daya yang tersedia dan,
jika ini tidak mencukupi, bernegosiasi untuk lebih banyak sumber daya atau untuk target QoS
yang berkurang.
Dalam sistem terdistribusi, tidak dapat dihindari bahwa kegagalan akan terjadi, sehingga
sistem harus dirancang agar tahan terhadap kegagalan tersebut. Kegagalan begitu umum
sehingga salah satu definisi sembrono dari sistem terdistribusi yang disarankan oleh Leslie
Lamport, seorang peneliti sistem terdistribusi terkemuka, adalah:
"Anda tahu bahwa Anda memiliki sistem terdistribusi ketika crash sistem yang belum
pernah Anda dengar menghentikan Anda menyelesaikan pekerjaan apa pun."
Manajemen kegagalan melibatkan penerapan teknik toleransi kesalahan yang dibahas dalam
Bab 13. Oleh karena itu, sistem terdistribusi harus mencakup mekanisme untuk menemukan
jika komponen sistem telah gagal, harus terus memberikan layanan sebanyak mungkin terlepas
dari kegagalan itu dan, sejauh mungkin, harus secara otomatis pulih dari kegagalan.
Pelayan makan malam
Apa yang kamu mau?
Tolong sup tomat
Dan untuk mengikuti?
Daging tak bertulang
Bagaimana Anda ingin dimasak?
Langka tolong
Dengan salad atau kentang goreng?
Gambar 18.1 Interaksi prosedural Tolong saladnya

antara pengunjung dan pelayan
Dll.
18.1.1 Model interaksi

Ada dua tipe dasar interaksi yang mungkin terjadi antara komputer dalam sistem komputasi
terdistribusi: interaksi prosedural dan interaksi berbasis pesan. Interaksi prosedural
melibatkan satu komputer yang memanggil layanan yang dikenal yang ditawarkan oleh
beberapa komputer lain dan (biasanya) menunggu layanan itu dikirimkan.
Interaksi berbasis pesan melibatkan komputer 'pengirim' yang mendefinisikan informasi
tentang apa yang diperlukan dalam sebuah pesan, yang kemudian dikirim ke komputer lain.
Pesan biasanya mengirimkan lebih banyak informasi dalam satu interaksi daripada panggilan
prosedur ke mesin lain.
Untuk mengilustrasikan perbedaan antara interaksi prosedural dan berbasis pesan,
pertimbangkan situasi di mana Anda memesan makanan di restoran. Saat Anda berbicara
dengan pelayan, Anda terlibat dalam serangkaian interaksi prosedural yang sinkron yang
menentukan pesanan Anda. Anda membuat permintaan; pelayan mengakui permintaan itu;
Anda membuat permintaan lain, yang diakui; dan seterusnya. Ini sebanding dengan
komponen yang berinteraksi dalam sistem perangkat lunak di mana satu komponen
memanggil metode dari komponen lain. Pelayan menuliskan pesanan Anda bersama dengan
pesanan orang lain dengan Anda. Dia kemudian melewati pesanan ini, yang mencakup
rincian semua yang telah dipesan, ke dapur untuk menyiapkan makanan.
Pada dasarnya, pelayan menyampaikan pesan kepada staf dapur yang mendefinisikan
makanan yang akan disiapkan. Ini adalah interaksi berbasis pesan.
Saya telah mengilustrasikan ini pada Gambar 18.1, yang menunjukkan proses pemesanan
sinkron sebagai serangkaian panggilan dan pada Gambar 18.2, yang menunjukkan pesan
XML hipotetis yang mendefinisikan pesanan yang dibuat oleh tabel tiga orang. Perbedaan
antara bentuk-bentuk pertukaran informasi ini jelas. Pelayan mengambil pesanan sebagai
serangkaian interaksi, dengan setiap interaksi mendefinisikan bagian dari pesanan. Namun,
<starter>
<nama masakan = “sup” type = “tomat” /> <nama
masakan = “sup” type = “ikan” /> <nama
masakan = “salad merpati” /> </starter> <main
course>
<nama masakan = “steak” type = masakan “sirloin” = “sedang” /> <nama

masakan = “steak” type = masakan “fillet” = “langka” /> <nama masakan =
“sea bass”>
</main>
<iringan>
<nama hidangan = porsi “kentang goreng” = “2” /> <nama
hidangan = porsi “salad” = “1” /> </iringan>
pelayan memiliki interaksi tunggal dengan dapur di mana pesan mendefinisikan

Gambar
18.2 Interaksi pesanan lengkap.
berbasis Komunikasi prosedural dalam sistem terdistribusi biasanya diimplementasikan
pesan antara menggunakan panggilan prosedur jarak jauh (RPC). Dalam RPC satu komponen
pelayan dan
memanggil komponen lain seolah-olah itu adalah prosedur atau metode lokal.
staf dapur
Middleware dalam sistem memotong panggilan ini dan meneruskannya ke komponen
jarak jauh. Ini melakukan perhitungan yang diperlukan dan, melalui middleware, mengembalikan hasilnya ke kom
Di Jawa, pemanggilan metode jarak jauh (RMI) sebanding dengan, meskipun tidak
identik dengan, RPC. Kerangka kerja RMI menangani pemanggilan metode jarak jauh
dalam program Java.
RPC memerlukan 'rintisan' agar prosedur yang dipanggil dapat diakses di komputer
yang memulai panggilan. Stub dipanggil dan menerjemahkan parameter prosedur
menjadi representasi standar untuk transmisi ke prosedur jarak jauh. Melalui
middleware, kemudian mengirimkan permintaan eksekusi ke prosedur jarak jauh.
Prosedur jarak jauh menggunakan fungsi perpustakaan untuk mengubah parameter
ke dalam format yang diperlukan, melakukan perhitungan, dan kemudian
mengomunikasikan hasilnya melalui 'rintisan' yang mewakili pemanggil.
Interaksi berbasis pesan biasanya melibatkan satu komponen yang membuat
pesan yang merinci layanan yang diperlukan dari komponen lain. Melalui middleware
sistem, ini dikirim ke komponen penerima. Penerima mem-parsing pesan, melakukan
perhitungan, dan membuat pesan untuk komponen pengirim dengan hasil yang
diperlukan. Ini kemudian diteruskan ke middleware untuk transmisi ke komponen
pengirim.
Masalah dengan pendekatan RPC untuk interaksi adalah bahwa baik penelepon
dan yang dipanggil harus tersedia pada saat komunikasi, dan mereka harus tahu
bagaimana merujuk satu sama lain. Intinya, RPC memiliki persyaratan yang sama
dengan prosedur lokal atau pemanggilan metode. Sebaliknya, dalam pendekatan
berbasis pesan, ketidaktersediaan dapat ditoleransi karena pesan tetap berada dalam
antrian sampai penerima tersedia. Selain itu, pengirim dan penerima pesan tidak perlu
saling menyadari. Mereka hanya berkomunikasi dengan middleware, yang bertanggung
jawab untuk memastikan bahwa pesan diteruskan ke sistem yang sesuai.
terkoordinasi
Komponen Aplikasi Komponen Aplikasi
Operasi
Informasi
Middleware Pertukaran dan Middleware
Layanan Umum
Logis
Sistem operasi Interaksi Sistem operasi
Fisik
Jaringan Jaringan
Gambar Konektivitas
18.3 Middleware
dalam sistem terdistribusi Sistem 1 Sistem 2
18.1.2 Perangkat Tengah
Komponen dalam sistem terdistribusi dapat diimplementasikan dalam bahasa pemrograman

yang berbeda dan dapat dijalankan pada jenis prosesor yang sama sekali berbeda. Model
data, representasi informasi, dan protokol untuk komunikasi semuanya mungkin berbeda.
Oleh karena itu, sistem terdistribusi memerlukan perangkat lunak yang dapat mengelola
bagian-bagian yang beragam ini, dan memastikan bahwa mereka dapat berkomunikasi dan bertukar data.
Istilah 'middleware' digunakan untuk merujuk pada perangkat lunak ini—ia berada di
tengah-tengah antara komponen sistem yang terdistribusi. Hal ini diilustrasikan pada Gambar
18.3, yang menunjukkan bahwa middleware adalah lapisan antara sistem operasi dan program
aplikasi. Middleware biasanya diimplementasikan sebagai satu set perpustakaan, yang diinstal
pada setiap komputer terdistribusi, ditambah sistem run-time untuk mengelola komunikasi.
Bernstein (1996) menjelaskan jenis middleware yang tersedia untuk mendukung komputasi
terdistribusi. Middleware adalah perangkat lunak tujuan umum yang biasanya dibeli dari rak
daripada ditulis khusus oleh pengembang aplikasi. Contoh middleware termasuk perangkat
lunak untuk mengelola komunikasi dengan database, manajer transaksi, konverter data, dan
pengontrol komunikasi.
Dalam sistem terdistribusi, middleware biasanya menyediakan dua jenis dukungan yang berbeda:
1. Dukungan interaksi, di mana middleware mengoordinasikan interaksi antara berbagai

komponen dalam sistem. Middleware menyediakan transparansi lokasi karena komponen
tidak perlu mengetahui lokasi fisik komponen lain. Ini juga dapat mendukung konversi
parameter jika bahasa pemrograman yang berbeda digunakan untuk mengimplementasikan
komponen, deteksi peristiwa, dan komunikasi, dll.
2. Penyediaan layanan umum, di mana middleware menyediakan implementasi layanan yang

dapat digunakan kembali yang mungkin diperlukan oleh beberapa komponen dalam
sistem terdistribusi. Dengan menggunakan layanan umum ini, komponen dapat dengan
mudah beroperasi dan menyediakan layanan pengguna dengan cara yang konsisten.
c2 c3 c4
c12
c11
c1 s1 s4
Proses Server
c10
c5
s2 s3
c9
Proses Klien
c6
c7 c8
Gambar 18.4 Interaksi
klien-server
Saya telah memberikan contoh dukungan interaksi yang dapat diberikan middleware di Bagian
18.1.1. Anda menggunakan middleware untuk mendukung prosedur jarak jauh dan panggilan
metode jarak jauh, pertukaran pesan, dll.
Layanan umum adalah layanan yang mungkin diperlukan oleh komponen yang berbeda
terlepas dari fungsionalitas komponen ini. Seperti yang saya bahas di Bab 17, ini mungkin
termasuk layanan keamanan (otentikasi dan otorisasi), layanan pemberitahuan dan penamaan,
dan layanan manajemen transaksi, dll. Anda dapat menganggap layanan umum ini disediakan
oleh wadah middleware.
Anda kemudian menyebarkan komponen Anda dalam wadah itu dan dapat mengakses dan
menggunakan layanan umum ini.
18.2 Komputasi klien-server
Sistem terdistribusi yang diakses melalui Internet biasanya diatur sebagai sistem client-server.
Dalam sistem klien-server, pengguna berinteraksi dengan program yang berjalan di komputer
lokal mereka (misalnya, browser web atau aplikasi berbasis telepon).
Ini berinteraksi dengan program lain yang berjalan pada komputer jarak jauh (misalnya, server
web). Komputer jarak jauh menyediakan layanan, seperti akses ke halaman web, yang tersedia
untuk klien eksternal. Model client-server ini, seperti yang saya bahas di Bab 6, adalah model
arsitektur aplikasi yang sangat umum. Ini tidak terbatas pada aplikasi yang didistribusikan di
beberapa mesin. Anda juga dapat menggunakannya sebagai model interaksi logis di mana klien
dan server berjalan di komputer yang sama.
Dalam arsitektur client-server, aplikasi dimodelkan sebagai satu set layanan yang disediakan
oleh server. Klien dapat mengakses layanan ini dan menyajikan hasil kepada pengguna akhir
(Orfali dan Harkey, 1998). Klien perlu mengetahui server yang tersedia tetapi tidak mengetahui
keberadaan klien lain. Klien dan server adalah
proses yang terpisah, seperti yang ditunjukkan pada Gambar 18.4. Ini menggambarkan situasi
di mana ada empat server (s1-s4), yang memberikan layanan yang berbeda. Setiap layanan
memiliki satu set klien terkait yang mengakses layanan ini.
18.2 Komputasi klien-server 489
c1 s1, s2 c2 c3, c4
CC1 SC2 CC2 CC3
Server
Komputer
Jaringan
Gambar 18.5 Pemetaan CC4 SC1 CC5 CC6

klien dan server untuk Klien
komputer berjaringan c5, c6, c7 s3, s4 c8, c9 c10, c11, c12 Komputer
Gambar 18.4 menunjukkan proses klien dan server daripada prosesor. itu normal
untuk beberapa proses klien berjalan pada satu prosesor. Misalnya, di PC Anda,
Anda dapat menjalankan klien email yang mengunduh email dari server email jarak jauh. Kamu boleh
juga menjalankan browser web yang berinteraksi dengan server web jarak jauh dan klien cetak yang
mengirim dokumen ke printer jarak jauh. Gambar 18.5 mengilustrasikan situasi di mana
12 klien logis yang ditunjukkan pada Gambar 18.4 berjalan di enam komputer. Empat server
proses dipetakan ke dua komputer server fisik.
Beberapa proses server yang berbeda dapat berjalan pada prosesor yang sama tetapi, seringkali,
server diimplementasikan sebagai sistem multiprosesor di mana instance terpisah dari
proses server berjalan pada setiap mesin. Perangkat lunak penyeimbang beban mendistribusikan
permintaan layanan dari klien ke server yang berbeda sehingga setiap server melakukan hal yang sama
jumlah pekerjaan. Hal ini memungkinkan volume transaksi yang lebih tinggi dengan klien untuk
ditangani, tanpa menurunkan respons terhadap masing-masing klien.
Sistem klien-server bergantung pada pemisahan yang jelas antara penyajian informasi dan
komputasi yang membuat dan memproses informasi tersebut.
Akibatnya, Anda harus merancang arsitektur sistem klien-server terdistribusi
sehingga mereka terstruktur menjadi beberapa lapisan logis, dengan antarmuka yang jelas antara
lapisan ini. Hal ini memungkinkan setiap lapisan untuk didistribusikan ke komputer yang berbeda. Angka
18.6 mengilustrasikan model ini, menunjukkan aplikasi yang terstruktur ke dalam empat lapisan:
• Lapisan presentasi yang berkaitan dengan penyajian informasi kepada pengguna dan
mengelola semua interaksi pengguna;
• Lapisan manajemen data yang mengelola data yang diteruskan ke dan dari
klien. Lapisan ini dapat menerapkan pemeriksaan pada data, menghasilkan halaman web, dll.;
• Lapisan pemrosesan aplikasi yang berkaitan dengan penerapan logika

aplikasi dan menyediakan fungsionalitas yang diperlukan untuk pengguna akhir;
• Lapisan basis data yang menyimpan data dan menyediakan manajemen transaksi
layanan, dll.
Bagian berikut menjelaskan bagaimana arsitektur client-server yang berbeda mendistribusikan

lapisan logis ini dengan cara yang berbeda. Model client-server juga mendasari
gagasan perangkat lunak sebagai layanan (SaaS), cara penerapan yang semakin penting
perangkat lunak dan mengaksesnya melalui Internet. Saya membahas ini di Bagian 18.4.
Lapisan Presentasi
Lapisan Manajemen Data
Lapisan Pemrosesan Aplikasi
Gambar 18.6 Model

arsitektur berlapis untuk Lapisan Basis Data
aplikasi client-server
18.3 Pola arsitektur untuk sistem terdistribusi

Seperti yang saya jelaskan dalam pengantar bab ini, perancang sistem terdistribusi
harus mengatur desain sistem mereka untuk menemukan keseimbangan antara kinerja,
ketergantungan, keamanan, dan pengelolaan sistem. Tidak ada model organisasi sistem
yang universal yang sesuai untuk semua keadaan sehingga muncul berbagai gaya
arsitektur yang tersebar. Saat merancang aplikasi terdistribusi, Anda harus memilih gaya
arsitektur yang mendukung persyaratan non-fungsional kritis sistem Anda.
Pada bagian ini, saya membahas lima gaya arsitektur:
1. Arsitektur master-slave, yang digunakan dalam sistem real-time di mana guaran

waktu respons interaksi teed diperlukan.
2. Arsitektur client-server dua tingkat, yang digunakan untuk sistem client-server

sederhana, dan dalam situasi di mana penting untuk memusatkan sistem untuk alasan keamanan.
Dalam kasus seperti itu, komunikasi antara klien dan server biasanya dienkripsi.
3. Arsitektur client-server multitier, yang digunakan ketika ada volume tinggi

transaksi yang akan diproses oleh server.
4. Arsitektur komponen terdistribusi, yang digunakan ketika sumber daya dari sistem
dan database yang berbeda perlu digabungkan, atau sebagai model implementasi
untuk sistem client-server multi-tier.
5. Arsitektur peer-to-peer, yang digunakan ketika klien bertukar informasi yang disimpan
secara lokal dan peran server adalah untuk memperkenalkan klien satu sama lain.
Ini juga dapat digunakan ketika sejumlah besar perhitungan independen mungkin harus dilakukan.
18.3.1 Arsitektur master-slave

Arsitektur master-slave untuk sistem terdistribusi umumnya digunakan dalam sistem
waktu nyata di mana mungkin ada prosesor terpisah yang terkait dengan akuisisi data
dari lingkungan sistem, pemrosesan data, dan komputasi dan
18.3 Pola arsitektur untuk sistem terdistribusi 491
Ruang kendali
Prosesor
Koordinasi
Sensor dan Tampilan Kontrol Lampu Lalu Lintas
Prosesor Proses Prosesor
Sensor Menguasai Lampu

Kontrol Kontrol
Proses Proses
Budak Budak
Konsol Operator
Sensor dan Kamera Lampu lalu lintas

Arus Lalu Lintas
manajemen aktuator. Aktuator, seperti yang saya bahas di Bab 20, adalah perangkat
Gambar 18.7 Sistem
manajemen lalu lintas
yang dikendalikan oleh sistem perangkat lunak yang bertindak untuk mengubah
dengan arsitektur lingkungan sistem. Misalnya, aktuator dapat mengontrol katup dan mengubah
master-slave
statusnya dari 'terbuka' menjadi 'tertutup'. Proses 'master' biasanya bertanggung
jawab untuk komputasi, koordinasi, dan komunikasi dan mengontrol proses 'slave'.
Proses 'Slave' didedikasikan untuk tindakan tertentu, seperti akuisisi data dari array
sensor.
Gambar 18.7 mengilustrasikan model arsitektur ini. Ini adalah model sistem
kontrol lalu lintas di kota dan memiliki tiga proses logis yang berjalan pada prosesor
terpisah. Proses master adalah proses ruang kontrol, yang berkomunikasi dengan
proses budak terpisah yang bertanggung jawab untuk mengumpulkan data lalu
lintas dan mengelola pengoperasian lampu lalu lintas.
Satu set sensor terdistribusi mengumpulkan informasi tentang arus lalu lintas. Sen
Sor kontrol proses polling sensor secara berkala untuk menangkap informasi arus
lalu lintas dan menyusun informasi ini untuk diproses lebih lanjut. Prosesor sensor
itu sendiri disurvei secara berkala untuk informasi oleh proses master yang berkaitan
dengan menampilkan status lalu lintas kepada operator, menghitung urutan lampu
lalu lintas dan menerima perintah operator untuk memodifikasi urutan ini. Sistem
ruang kontrol mengirimkan perintah ke proses kontrol lampu lalu lintas yang
mengubahnya menjadi sinyal untuk mengontrol perangkat keras lampu lalu lintas.
Sistem ruang kendali utama itu sendiri diatur sebagai sistem klien-server, dengan
proses klien berjalan di konsol operator.
Anda menggunakan model master-slave dari sistem terdistribusi dalam situasi di
mana Anda dapat memprediksi pemrosesan terdistribusi yang diperlukan, dan di
mana pemrosesan dapat dengan mudah dilokalkan ke prosesor slave. Situasi ini
umum dalam sistem waktu nyata, di mana penting untuk memenuhi tenggat waktu
pemrosesan. Prosesor budak dapat digunakan untuk operasi komputasi intensif,
seperti pemrosesan sinyal dan pengelolaan peralatan yang dikendalikan oleh sistem.
Presentasi
Server
Klien Tipis Basis data
Klien
Model Manajemen data
Pemrosesan Aplikasi
Presentasi
Pemrosesan Aplikasi
Server
Lemak-Klien Basis data
Klien
Gambar 18.8 Model Model Manajemen data
arsitektur klien kurus
dan gemuk
18.3.2 Arsitektur client-server dua tingkat

Pada Bagian 18.2, saya membahas bentuk umum dari sistem client-server di mana bagian
dari sistem aplikasi berjalan di komputer pengguna (klien), dan sebagian berjalan di
komputer jarak jauh (server). Saya juga menyajikan model aplikasi berlapis (Gambar 18.6)
di mana lapisan yang berbeda dalam sistem dapat dijalankan pada komputer yang berbeda.
Arsitektur client-server dua tingkat adalah bentuk paling sederhana dari arsitektur
client-server. Sistem diimplementasikan sebagai server logis tunggal ditambah jumlah
klien yang tidak terbatas yang menggunakan server tersebut. Hal ini diilustrasikan pada
Gambar 18.8, yang menunjukkan dua bentuk model arsitektur ini:
1. Model thin-client, di mana lapisan presentasi diimplementasikan pada klien dan semua
lapisan lainnya (manajemen data, pemrosesan aplikasi, dan basis data)
diimplementasikan pada server. Perangkat lunak klien dapat berupa program yang
ditulis khusus pada klien untuk menangani presentasi. Lebih sering, bagaimanapun,
browser web pada komputer klien digunakan untuk presentasi data.
2. Model klien gemuk, di mana sebagian atau seluruh pemrosesan aplikasi dilakukan pada
klien. Manajemen data dan fungsi database diimplementasikan di server.
Keuntungan dari model thin-client adalah mudah untuk mengelola klien.

Ini adalah masalah utama jika ada banyak klien, karena mungkin sulit dan mahal untuk
menginstal perangkat lunak baru pada semuanya. Jika browser web digunakan sebagai
klien, tidak perlu menginstal perangkat lunak apa pun.
Kelemahan dari pendekatan thin-client, bagaimanapun adalah bahwa hal itu dapat
menempatkan beban pemrosesan yang berat pada server dan jaringan. Server bertanggung
jawab untuk semua perhitungan dan ini dapat menyebabkan generasi lalu lintas jaringan
yang signifikan antara klien dan server. Oleh karena itu, menerapkan sistem menggunakan
model ini mungkin memerlukan investasi tambahan dalam jaringan dan kapasitas server.
Namun, browser dapat melakukan beberapa pemrosesan lokal dengan mengeksekusi
skrip (misalnya, Javascript) di halaman web yang diakses oleh browser.
Model klien gemuk memanfaatkan kekuatan pemrosesan yang tersedia di komputer
yang menjalankan perangkat lunak klien, dan mendistribusikan beberapa atau semua pemrosesan aplikasi
ATM
ATM
Server Akun
Tele Pelanggan
Pengolahan Akun
Memantau Basis data
ATM
Gambar 18.9 Arsitektur

klien gemuk untuk sistem ATM
ATM
dan presentasi kepada klien. Server pada dasarnya adalah server transaksi yang
mengelola semua transaksi basis data. Manajemen data sangat mudah karena tidak
perlu mengelola interaksi antara klien dan sistem pemrosesan aplikasi. Tentu saja,
masalah dengan model klien gemuk adalah memerlukan manajemen sistem tambahan
untuk menyebarkan dan memelihara perangkat lunak pada komputer klien.
Contoh situasi di mana arsitektur klien gemuk digunakan adalah dalam sistem ATM
bank, yang mengirimkan uang tunai dan layanan perbankan lainnya kepada pengguna.
ATM adalah komputer klien dan server, biasanya, merupakan mainframe yang
menjalankan basis data akun pelanggan. Komputer mainframe adalah mesin yang kuat
yang dirancang untuk pemrosesan transaksi. Oleh karena itu dapat menangani volume
besar transaksi yang dihasilkan oleh ATM, sistem teller lainnya, dan perbankan online.
Perangkat lunak di mesin teller melakukan banyak pemrosesan terkait pelanggan yang terkait dengan suatu tra
Gambar 18.9 menunjukkan versi sederhana dari organisasi sistem ATM. Perhatikan
bahwa ATM tidak terhubung langsung ke database pelanggan, melainkan ke monitor
teleprocessing. Monitor teleprocessing (TP) adalah sistem middleware yang mengatur
komunikasi dengan klien jarak jauh dan membuat serial transaksi klien untuk diproses
oleh database. Ini memastikan bahwa transaksi independen dan tidak mengganggu
satu sama lain. Menggunakan transaksi serial berarti bahwa sistem dapat pulih dari
kesalahan tanpa merusak data sistem.
Sementara model klien gemuk mendistribusikan pemrosesan lebih efektif daripada
model klien tipis, manajemen sistem lebih kompleks. Fungsionalitas aplikasi tersebar
di banyak komputer. Ketika perangkat lunak aplikasi harus diubah, ini melibatkan
penginstalan ulang pada setiap komputer klien. Ini bisa menjadi biaya besar jika ada
ratusan klien dalam sistem. Sistem mungkin harus dirancang untuk mendukung
peningkatan perangkat lunak jarak jauh dan mungkin perlu mematikan semua layanan
sistem sampai perangkat lunak klien diganti.
18.3.3 Arsitektur client-server multi-tier

Masalah mendasar dengan pendekatan klien-server dua tingkat adalah bahwa lapisan
logis dalam sistem—presentasi, pemrosesan aplikasi, manajemen data, dan database—
harus dipetakan ke dalam dua sistem komputer: klien dan server.
Tingkat 1. Presentasi
Klien
Interaksi HTTPS
Server Web Server Basis Data

Klien
Layanan Akun Pelanggan

Kueri SQL
SQL Akun
Persediaan
Basis data
Klien
Tingkat 2. Tingkat 3.
Pemrosesan Aplikasi Pemrosesan Basis Data
dan Manajemen Data
Gambar 18.10 Arsitektur Klien
tiga tingkat untuk sistem
perbankan Internet
Hal ini dapat menyebabkan masalah dengan skalabilitas dan kinerja jika model thin-
client yang dipilih, atau masalah manajemen sistem jika model fat-client digunakan.
Untuk menghindari beberapa masalah ini, arsitektur 'multi-tier client-server' dapat digunakan.
Dalam arsitektur ini, berbagai lapisan sistem, yaitu presentasi, manajemen data,
pemrosesan aplikasi, dan basis data, merupakan proses terpisah yang dapat
dijalankan pada prosesor yang berbeda.
Sistem perbankan Internet (Gambar 18.10) adalah contoh arsitektur client-server
multi-tier, di mana ada tiga tingkatan dalam sistem. Basis data nasabah bank
(biasanya di-host di komputer mainframe seperti yang dibahas di atas) menyediakan
layanan basis data. Server web menyediakan layanan manajemen data seperti
pembuatan halaman web dan beberapa layanan aplikasi. Layanan aplikasi seperti
fasilitas untuk mentransfer uang tunai, menghasilkan laporan, membayar tagihan,
dan sebagainya diimplementasikan di server web dan sebagai skrip yang dijalankan
oleh klien. Komputer pengguna sendiri dengan browser Internet adalah klien. Sistem
ini scalable karena relatif mudah untuk menambah server (scale out) seiring dengan bertambahnya jumlah pel
Dalam hal ini, penggunaan arsitektur three-tier memungkinkan transfer informasi
antara web server dan database server dapat dioptimalkan. Komunikasi antara
sistem ini dapat menggunakan protokol pertukaran data tingkat rendah yang cepat.
Middleware efisien yang mendukung kueri basis data dalam SQL (Structured Query
Language) digunakan untuk menangani pengambilan informasi dari basis data.
Model client-server tiga tingkat dapat diperluas ke varian multi-tingkat, di mana
server tambahan ditambahkan ke sistem. Ini mungkin melibatkan penggunaan server
web untuk manajemen data dan server terpisah untuk pemrosesan aplikasi dan
layanan basis data. Sistem multi-tier juga dapat digunakan ketika aplikasi perlu
mengakses dan menggunakan data dari database yang berbeda. Dalam hal ini, Anda
mungkin perlu menambahkan server integrasi ke sistem. Server integrasi
mengumpulkan data terdistribusi dan menyajikannya ke server aplikasi seolah-olah
berasal dari satu database. Seperti yang saya bahas di bagian berikut, arsitektur
komponen terdistribusi dapat digunakan untuk mengimplementasikan sistem client-server multi-tier.
Sistem klien-server multi-tingkat yang mendistribusikan pemrosesan aplikasi di
beberapa server secara inheren lebih terukur daripada arsitektur dua tingkat. Itu
Arsitektur Aplikasi
Arsitektur client-server Aplikasi sistem lama yang digunakan saat memisahkan pemrosesan
dua tingkat dengan thin client aplikasi dan manajemen data tidak praktis. Klien dapat mengakses ini
sebagai layanan, seperti yang dibahas dalam Bagian 18.4.
Aplikasi intensif komputasi seperti kompiler dengan sedikit atau tanpa
manajemen data.
Aplikasi data-intensif (browsing dan query) dengan pemrosesan aplikasi non-
intensif. Menjelajah Web adalah contoh paling umum dari situasi di mana
arsitektur ini digunakan.
Arsitektur client-server Aplikasi di mana pemrosesan aplikasi disediakan oleh perangkat lunak
dua tingkat dengan klien gemuk yang tersedia (misalnya, Microsoft Excel) pada klien.
Aplikasi yang memerlukan pemrosesan data yang intensif secara komputasi
(misalnya, visualisasi data).
Aplikasi seluler di mana konektivitas internet tidak dapat dijamin.
Oleh karena itu, beberapa pemrosesan lokal menggunakan informasi yang di-cache
dari database dimungkinkan.
Arsitektur klien-server Aplikasi skala besar dengan ratusan atau ribuan klien.
multi-tingkat
Aplikasi yang data dan aplikasinya mudah berubah.
Aplikasi di mana data dari berbagai sumber terintegrasi.
Pemrosesan aplikasi sering kali merupakan bagian sistem yang paling mudah berubah dan
Gambar 18.11
Penggunaan dapat dengan mudah diperbarui karena terletak di pusat. Pemrosesan, dalam beberapa
arsitektur client-server kasus, dapat didistribusikan antara logika aplikasi dan server manajemen data, sehingga
pola menghasilkan respons yang lebih cepat terhadap permintaan klien.
Perancang arsitektur client-server harus mempertimbangkan sejumlah faktor ketika
memilih arsitektur distribusi yang paling tepat. Situasi di mana arsitektur client-server yang
dibahas di sini mungkin sesuai dijelaskan pada Gambar 18.11.
18.3.4 Arsitektur komponen terdistribusi

Dengan mengatur pemrosesan ke dalam lapisan, seperti yang ditunjukkan pada Gambar
18.6, setiap lapisan sistem dapat diimplementasikan sebagai server logis yang terpisah.
Model ini bekerja dengan baik untuk banyak jenis aplikasi. Namun, ini membatasi fleksibilitas
perancang sistem karena mereka harus memutuskan layanan apa yang harus disertakan
dalam setiap lapisan. Namun dalam praktiknya, tidak selalu jelas apakah suatu layanan
adalah layanan manajemen data, layanan aplikasi, atau layanan database. Desainer juga
harus merencanakan skalabilitas dan menyediakan beberapa cara agar server dapat direplikasi karena lebih banyak
Pendekatan yang lebih umum untuk desain sistem terdistribusi adalah merancang sistem
sebagai satu set layanan, tanpa mencoba mengalokasikan layanan ini ke lapisan dalam sistem.
Setiap layanan, atau kelompok layanan terkait, diimplementasikan menggunakan komponen
terpisah. Dalam arsitektur komponen terdistribusi (Gambar 18.12) sistem diatur sebagai
satu set komponen atau objek yang berinteraksi. Komponen-komponen ini menyediakan antarmuka
Komp 1 Komp 2 Komp 3 Komp 4

Umum Umum Umum Umum
Jasa Jasa Jasa Jasa
Middleware Komunikasi
Gambar
18.12
Klien Klien Klien Klien
Arsitektur
komponen terdistribusi
untuk satu set layanan yang mereka berikan. Komponen lain memanggil layanan ini melalui
middleware, menggunakan prosedur jarak jauh atau panggilan metode.
Sistem komponen terdistribusi bergantung pada middleware, yang mengelola interaksi
komponen, mendamaikan perbedaan antara jenis parameter yang diteruskan antar komponen,
dan menyediakan serangkaian layanan umum yang dapat digunakan oleh komponen aplikasi.
CORBA (Orfali et al., 1997) adalah contoh awal perangkat tengah tersebut tetapi sekarang tidak
banyak digunakan. Sebagian besar telah digantikan oleh perangkat lunak berpemilik seperti
Enterprise Java Beans (EJB) atau .NET.
Manfaat menggunakan model komponen terdistribusi untuk mengimplementasikan sistem
terdistribusi adalah sebagai berikut:
1. Memungkinkan perancang sistem untuk menunda keputusan tentang di mana dan bagaimana
layanan harus disediakan. Komponen penyedia layanan dapat dijalankan pada setiap node
jaringan. Tidak perlu memutuskan terlebih dahulu apakah suatu layanan merupakan bagian
dari lapisan manajemen data, lapisan aplikasi, dll.
2. Ini adalah arsitektur sistem yang sangat terbuka yang memungkinkan sumber daya baru
ditambahkan sesuai kebutuhan. Layanan sistem baru dapat ditambahkan dengan mudah
tanpa gangguan besar pada sistem yang ada.
3. Sistemnya fleksibel dan terukur. Komponen baru atau komponen yang direplikasi dapat
ditambahkan saat beban pada sistem meningkat, tanpa mengganggu bagian lain dari sistem.
4. Dimungkinkan untuk mengkonfigurasi ulang sistem secara dinamis dengan komponen yang
bermigrasi melintasi jaringan sesuai kebutuhan. Ini mungkin penting di mana ada pola
permintaan yang berfluktuasi pada layanan. Komponen penyedia layanan dapat bermigrasi
ke prosesor yang sama dengan objek yang meminta layanan, sehingga meningkatkan
kinerja sistem.
Arsitektur komponen terdistribusi dapat digunakan sebagai model logis yang memungkinkan
Anda untuk menyusun dan mengatur sistem. Dalam hal ini, Anda berpikir tentang bagaimana
menyediakan fungsionalitas aplikasi hanya dalam hal layanan dan kombinasi layanan. Anda
kemudian mencari cara untuk menyediakan layanan ini menggunakan satu set komponen terdistribusi. Untuk
Basis Data 1
Laporkan gen.
Integrator 1
Basis Data 2
Visualisasi
Integrator 2
Basis Data 3
Menampilkan
Gambar 18.13
Arsitektur
komponen
terdistribusi
untuk sistem data mining klien
misalnya, dalam aplikasi ritel mungkin ada komponen aplikasi yang berkaitan dengan
pengendalian stok, komunikasi pelanggan, pemesanan barang, dan sebagainya.
Sistem data mining adalah contoh yang baik dari jenis sistem di mana arsitektur
komponen terdistribusi adalah pola arsitektur terbaik untuk digunakan. Sistem data
mining mencari hubungan antara data yang disimpan dalam sejumlah basis data
(Gambar 18.13). Sistem penambangan data biasanya menarik informasi dari beberapa
basis data terpisah, melakukan pemrosesan intensif komputasi, dan menampilkan
hasilnya secara grafis.
Contoh aplikasi data mining seperti itu mungkin sistem untuk bisnis ritel yang
menjual makanan dan buku. Departemen pemasaran ingin menemukan hubungan
antara makanan pelanggan dan pembelian buku. Misalnya, sebagian besar orang yang
membeli pizza mungkin juga membeli novel kriminal. Dengan pengetahuan ini, bisnis
dapat secara khusus menargetkan pelanggan yang melakukan pembelian makanan
tertentu dengan informasi tentang novel baru saat diterbitkan.
Dalam contoh ini, setiap database penjualan dapat dienkapsulasi sebagai komponen
terdistribusi dengan antarmuka yang menyediakan akses baca-saja ke datanya.
Komponen integrator masing-masing berkaitan dengan jenis hubungan tertentu, dan
mereka mengumpulkan informasi dari semua database untuk mencoba menyimpulkan
hubungan. Mungkin ada komponen integrator yang berkaitan dengan variasi musiman
dalam barang yang dijual, dan komponen lain yang berkaitan dengan hubungan antara berbagai jenis barang.
Komponen visualizer berinteraksi dengan komponen integrator untuk menghasilkan
visualisasi atau laporan tentang hubungan yang telah ditemukan. Karena volume besar
data yang ditangani, komponen visualizer biasanya menyajikan hasilnya secara grafis.
Akhirnya, komponen tampilan mungkin bertanggung jawab untuk memberikan model
grafis kepada klien untuk presentasi akhir.
Arsitektur komponen terdistribusi daripada arsitektur berlapis lebih sesuai untuk
jenis aplikasi ini karena Anda dapat menambahkan database baru ke sistem
tanpa gangguan besar. Setiap database baru hanya diakses dengan menambahkan
komponen terdistribusi lainnya. Komponen akses database menyediakan antarmuka yang
disederhanakan yang mengontrol akses ke data. Basis data yang diakses mungkin berada
di mesin yang berbeda. Arsitekturnya juga memudahkan untuk menambang jenis hubungan
baru dengan menambahkan komponen integrator baru.
Arsitektur komponen terdistribusi menderita dua kelemahan utama:
1. Mereka lebih kompleks untuk dirancang daripada sistem klien-server. Sistem client-
server multi-layer tampaknya menjadi cara yang cukup intuitif untuk berpikir tentang sistem.
Mereka mencerminkan banyak transaksi manusia di mana orang meminta dan
menerima layanan dari orang lain yang berspesialisasi dalam menyediakan layanan
ini. Sebaliknya, arsitektur komponen terdistribusi lebih sulit untuk divisualisasikan
dan dipahami orang.
2. Middleware standar untuk sistem komponen terdistribusi tidak pernah diterima oleh
masyarakat. Vendor yang agak berbeda, seperti Microsoft dan Sun, telah
mengembangkan middleware yang berbeda dan tidak kompatibel. Middleware ini
kompleks dan ketergantungan padanya meningkatkan kompleksitas keseluruhan
sistem komponen terdistribusi.
Sebagai hasil dari masalah ini, arsitektur berorientasi layanan (dibahas dalam Bab 19)
menggantikan arsitektur komponen terdistribusi dalam banyak situasi.
Namun, sistem komponen terdistribusi memiliki manfaat kinerja dibandingkan sistem
berorientasi layanan. Komunikasi RPC biasanya lebih cepat daripada interaksi berbasis
pesan yang digunakan dalam sistem berorientasi layanan. Oleh karena itu, arsitektur
berbasis komponen lebih sesuai untuk sistem throughput tinggi di mana sejumlah besar
transaksi harus diproses dengan cepat.
18.3.5 Arsitektur peer-to-peer

Model komputasi client-server yang telah saya bahas di bagian sebelumnya dari bab ini
membuat perbedaan yang jelas antara server, yang merupakan penyedia layanan dan
klien, yang merupakan penerima layanan. Model ini biasanya mengarah pada distribusi
beban yang tidak merata pada sistem, di mana server melakukan lebih banyak pekerjaan daripada klien.
Hal ini dapat menyebabkan organisasi menghabiskan banyak pada kapasitas server
sementara ada kapasitas pemrosesan yang tidak digunakan pada ratusan atau ribuan PC
yang digunakan untuk mengakses server sistem.
Sistem peer-to-peer (p2p) adalah sistem terdesentralisasi di mana perhitungan dapat
dilakukan oleh setiap node di jaringan. Setidaknya pada prinsipnya, tidak ada perbedaan
yang dibuat antara klien dan server. Dalam aplikasi peer-to-peer, keseluruhan sistem
dirancang untuk memanfaatkan daya komputasi dan penyimpanan yang tersedia di seluruh
jaringan komputer yang berpotensi besar. Standar dan protokol yang memungkinkan
komunikasi di seluruh node tertanam dalam aplikasi itu sendiri dan setiap node harus
menjalankan salinan aplikasi itu.
Teknologi peer-to-peer sebagian besar telah digunakan untuk pribadi daripada bisnis
sistem (Oram, 2001). Misalnya, sistem berbagi file berdasarkan Gnutella dan
Protokol BitTorrent digunakan untuk bertukar file di PC pengguna. Sistem pesan instan seperti
ICQ dan Jabber menyediakan komunikasi langsung antar pengguna tanpa
server perantara. SETI@home adalah proyek jangka panjang untuk memproses data dari
teleskop radio di PC rumahan untuk mencari indikasi kehidupan di luar bumi.
Freenet adalah database terdesentralisasi yang telah dirancang untuk memudahkan
mempublikasikan informasi secara anonim, dan mempersulit pihak berwenang untuk menekannya.
informasi. Layanan telepon Voice over IP (VOIP), seperti Skype, mengandalkan komunikasi
peer-to-peer antara pihak-pihak yang terlibat dalam panggilan telepon atau konferensi.
Namun, sistem peer-to-peer juga digunakan oleh bisnis untuk memanfaatkan
daya di jaringan PC mereka (McDougall, 2000). Intel dan Boeing keduanya menerapkan sistem
p2p untuk aplikasi intensif komputasi. Ini mengambil keuntungan dari kapasitas pemrosesan
yang tidak digunakan pada komputer lokal. Daripada beli mahal
perangkat keras berperforma tinggi, komputasi teknik dapat dijalankan dalam semalam ketika
komputer desktop tidak digunakan. Bisnis juga menggunakan ekstensif komersial
sistem p2p, seperti pesan dan sistem VOIP.
Adalah tepat untuk menggunakan model arsitektur peer-to-peer untuk sistem dalam dua lingkaran
keadaan:
1. Dimana sistem komputasi intensif dan dimungkinkan untuk memisahkan

pemrosesan yang diperlukan menjadi sejumlah besar komputasi independen. Untuk
Misalnya, sistem peer-to-peer yang mendukung penemuan obat komputasional
mendistribusikan komputasi yang mencari pengobatan kanker potensial dengan menganalisis
sejumlah besar molekul untuk melihat apakah mereka memiliki karakteristik yang
diperlukan untuk menekan pertumbuhan kanker. Setiap molekul dapat dipertimbangkan secara terpisah sehingga
tidak perlu rekan-rekan dalam sistem untuk berkomunikasi.
2. Dimana sistem terutama melibatkan pertukaran informasi antara komputer individu di

jaringan dan tidak perlu informasi ini terpusat
disimpan atau dikelola. Contoh aplikasi tersebut termasuk sistem file-sharing yang:
memungkinkan rekan-rekan untuk bertukar file lokal seperti file musik dan video, dan
sistem telepon yang mendukung komunikasi suara dan video antar komputer.
Pada prinsipnya, setiap node dalam jaringan p2p dapat mengetahui setiap node lainnya.
Node dapat terhubung dan bertukar data secara langsung dengan node lain dalam jaringan.
Dalam praktiknya, tentu saja, ini tidak mungkin, sehingga node diatur ke dalam 'ikatan lokal'
dengan beberapa node bertindak sebagai jembatan ke lokalitas node lainnya. Gambar 18.14 menunjukkan
arsitektur p2p terdesentralisasi ini.
Dalam arsitektur terdesentralisasi, node dalam jaringan tidak hanya berfungsi
elemen tetapi juga switch komunikasi yang dapat merutekan data dan mengontrol sinyal dari
satu node ke node lainnya. Sebagai contoh, asumsikan bahwa Gambar 18.14 mewakili a
desentralisasi, sistem manajemen dokumen. Sistem ini digunakan oleh konsorsium
peneliti untuk berbagi dokumen, dan setiap anggota konsorsium mempertahankan
atau toko dokumennya sendiri. Namun, ketika sebuah dokumen diambil, node yang mengambil
dokumen itu juga membuatnya tersedia untuk node lain.
n4 n6
n8 n13
n7 n12
n2 n3
n13
n9 n10 n11
Gambar
18.14 Arsitektur n1 n5
p2p terdesentralisasi
Jika seseorang membutuhkan dokumen yang disimpan di suatu tempat di jaringan, mereka
mengeluarkan perintah pencarian, yang dikirim ke node di 'lokalitas' mereka. Node ini
memeriksa apakah mereka memiliki dokumen dan, jika demikian, mengembalikannya ke
pemohon. Jika mereka tidak memilikinya, mereka mengarahkan pencarian ke node lain. Oleh
karena itu, jika n1 mengeluarkan pencarian untuk dokumen yang disimpan di n10, pencarian
ini dirutekan melalui node n3, n6, dan n9 ke n10. Ketika dokumen akhirnya ditemukan, node
yang menyimpan dokumen tersebut kemudian mengirimkannya ke node yang meminta secara langsung dengan membuat
Arsitektur terdesentralisasi ini memiliki kelebihan karena sangat redundan dan karenanya
toleran terhadap kesalahan dan toleran terhadap node yang terputus dari jaringan.
Namun, kelemahannya di sini adalah bahwa banyak node yang berbeda dapat memproses
pencarian yang sama, dan ada juga overhead yang signifikan dalam komunikasi rekan yang direplikasi.
Sebuah model arsitektur p2p alternatif, yang berangkat dari arsitektur p2p murni, adalah
arsitektur semi-terpusat di mana, dalam jaringan, satu atau lebih node bertindak sebagai
server untuk memfasilitasi komunikasi node. Ini mengurangi jumlah lalu lintas antar node.
Gambar 18.15 mengilustrasikan model ini.
Dalam arsitektur semisentralisasi, peran server (kadang-kadang disebut super peer)
adalah untuk membantu membangun kontak antara rekan-rekan dalam jaringan, atau untuk
mengkoordinasikan hasil perhitungan. Misalnya, jika Gambar 18.15 mewakili sistem pesan
instan, maka node jaringan berkomunikasi dengan server (ditunjukkan dengan garis putus-
putus) untuk mengetahui node lain yang tersedia. Setelah node ini ditemukan, komunikasi
langsung dapat dibuat dan koneksi ke server tidak diperlukan
penting. Oleh karena itu node n2, n3, n5, dan n6 berada dalam komunikasi langsung.
Dalam sistem p2p komputasi, di mana komputasi intensif prosesor didistribusikan di
sejumlah besar node, adalah normal untuk beberapa node menjadi super peer. Peran mereka
adalah untuk mendistribusikan pekerjaan ke node lain dan untuk menyusun dan memeriksa
hasil perhitungan.
Arsitektur peer-to-peer memungkinkan penggunaan kapasitas yang efisien di seluruh jaringan.
Namun, kekhawatiran utama yang menghambat penggunaannya adalah masalah keamanan
dan kepercayaan. Komunikasi peer-to-peer melibatkan pembukaan komputer Anda untuk
interaksi langsung dengan rekan-rekan lain dan ini berarti bahwa sistem ini berpotensi dapat
mengakses sumber daya Anda. Untuk mengatasi ini, Anda perlu mengatur sistem Anda
sehingga sumber daya ini dilindungi. Jika ini dilakukan dengan tidak benar, maka sistem Anda mungkin tidak aman.
18.4 Perangkat lunak sebagai layanan 501
Server Penemuan
(Super-Rekan)
n4
n1
n3
n6
n5
Gambar 18.15
Arsitektur p2p n2
semi-terpusat
Masalah juga dapat terjadi ketika rekan-rekan di jaringan dengan sengaja berperilaku
jahat. Misalnya, ada kasus di mana perusahaan musik yang percaya bahwa hak cipta
mereka disalahgunakan telah dengan sengaja menyediakan 'rekan-rekan yang diracuni'.
Ketika rekan lain mengunduh apa yang mereka anggap sebagai karya musik, file
sebenarnya yang dikirimkan adalah malware yang mungkin merupakan versi musik yang
sengaja dirusak atau peringatan kepada pengguna tentang pelanggaran hak cipta.
18.4 Perangkat lunak sebagai layanan
Pada bagian sebelumnya, saya membahas model client-server dan bagaimana fungsionalitas
dapat didistribusikan antara klien dan server. Untuk mengimplementasikan sistem klien-
server, Anda mungkin harus menginstal program di komputer klien, yang berkomunikasi
dengan server, mengimplementasikan fungsionalitas sisi klien, dan mengelola antarmuka pengguna.
Misalnya, klien email, seperti Outlook atau Mac Mail, menyediakan fitur manajemen email
di komputer Anda sendiri. Ini menghindari masalah beberapa sistem klien tipis di mana
semua pemrosesan dilakukan di server.
Namun, masalah kelebihan server dapat dikurangi secara signifikan dengan
menggunakan browser modern sebagai perangkat lunak klien. Teknologi web, seperti
AJAX (Holdener, 2008), mendukung manajemen presentasi halaman web yang efisien dan
komputasi lokal melalui skrip. Ini berarti bahwa browser dapat dikonfigurasi dan digunakan
sebagai klien, dengan pemrosesan lokal yang signifikan. Perangkat lunak aplikasi dapat
dianggap sebagai layanan jarak jauh, yang dapat diakses dari perangkat apa pun yang
dapat menjalankan browser standar. Contoh yang terkenal adalah sistem surat berbasis
web, seperti Yahoo! dan Gmail dan aplikasi kantor, seperti Google docs.
Gagasan SaaS ini melibatkan hosting perangkat lunak dari jarak jauh dan menyediakan akses
untuk itu melalui Internet. Elemen kunci SaaS adalah sebagai berikut:
1. Perangkat lunak ditempatkan pada server (atau lebih umum sejumlah server) dan
diakses melalui browser web. Itu tidak digunakan pada PC lokal.
2. Perangkat lunak dimiliki dan dikelola oleh penyedia perangkat lunak, bukan oleh
organisasi yang menggunakan perangkat lunak.
3. Pengguna dapat membayar perangkat lunak sesuai dengan jumlah penggunaan yang mereka
lakukan atau melalui langganan tahunan atau bulanan. Terkadang, perangkat lunak ini
gratis untuk digunakan siapa saja, tetapi pengguna kemudian harus setuju untuk menerima
iklan, yang mendanai layanan perangkat lunak.
Untuk pengguna perangkat lunak, manfaat SaaS adalah bahwa biaya pengelolaan perangkat
lunak ditransfer ke penyedia. Penyedia bertanggung jawab untuk memperbaiki bug dan
menginstal pembaruan perangkat lunak, menangani perubahan pada platform sistem operasi,
dan memastikan bahwa kapasitas perangkat keras dapat memenuhi permintaan. Biaya
manajemen lisensi perangkat lunak adalah nol. Jika seseorang memiliki beberapa komputer,
tidak perlu melisensikan perangkat lunak untuk semua ini. Jika aplikasi perangkat lunak hanya
digunakan sesekali, model bayar per penggunaan mungkin lebih murah daripada membeli
aplikasi. Perangkat lunak dapat diakses dari perangkat seluler, seperti ponsel pintar, dari mana saja di dunia.
Tentu saja, model penyediaan perangkat lunak ini memiliki beberapa kelemahan. Masalah
utama, mungkin, adalah biaya transfer data ke layanan jarak jauh. Transfer data berlangsung
pada kecepatan jaringan sehingga mentransfer sejumlah besar data membutuhkan banyak
waktu. Anda mungkin juga harus membayar penyedia layanan sesuai dengan jumlah yang
ditransfer. Masalah lainnya adalah kurangnya kontrol atas evolusi perangkat lunak (penyedia
dapat mengubah perangkat lunak sesuai keinginan) dan masalah dengan undang-undang dan
peraturan. Banyak negara memiliki undang-undang yang mengatur penyimpanan, pengelolaan,
pelestarian, dan aksesibilitas data dan memindahkan data ke layanan jarak jauh dapat melanggar undang-undang ini.
Gagasan SaaS dan arsitektur berorientasi layanan (SOA), dibahas dalam
Bab 19, jelas terkait tetapi tidak sama:
1. SaaS adalah cara menyediakan fungsionalitas pada server jarak jauh dengan akses klien
melalui browser web. Server memelihara data dan status pengguna selama sesi interaksi.
Transaksi biasanya transaksi panjang (misalnya, mengedit dokumen).
2. SOA adalah sebuah pendekatan untuk menyusun sistem perangkat lunak sebagai satu set
layanan yang terpisah, tanpa status. Ini mungkin disediakan oleh beberapa penyedia dan
dapat didistribusikan. Biasanya, transaksi adalah transaksi singkat di mana layanan
dipanggil, melakukan sesuatu, dan kemudian mengembalikan hasilnya.
SaaS adalah cara memberikan fungsionalitas aplikasi kepada pengguna, sedangkan SOA
adalah teknologi implementasi untuk sistem aplikasi. Fungsionalitas yang diimplementasikan
menggunakan SOA tidak perlu terlihat oleh pengguna sebagai layanan. Demikian pula, layanan
pengguna tidak harus diimplementasikan menggunakan SOA. Namun, jika SaaS
diimplementasikan menggunakan SOA, aplikasi menjadi mungkin untuk menggunakan API
layanan untuk mengakses fungsionalitas aplikasi lain. Mereka kemudian dapat diintegrasikan
ke dalam sistem yang lebih kompleks. Ini disebut mashup dan mewakili pendekatan lain untuk
penggunaan kembali perangkat lunak dan pengembangan perangkat lunak yang cepat.
Dari perspektif pengembangan perangkat lunak, proses pengembangan layanan memiliki
banyak kesamaan dengan jenis pengembangan perangkat lunak lainnya. Namun, konstruksi
layanan biasanya tidak didorong oleh kebutuhan pengguna, tetapi oleh asumsi penyedia
layanan tentang apa yang dibutuhkan pengguna. Oleh karena itu, perangkat lunak harus dapat
18.4 Perangkat lunak sebagai layanan 503
Pengguna 1 Pengguna 2 Pengguna 3 Pengguna 4 Pengguna 5
Profil C1 Profil C2 Profil C3
Gambar 18.16
Konfigurasi a
sistem perangkat lunak
Layanan Aplikasi
yang ditawarkan sebagai layanan
berkembang dengan cepat setelah penyedia mendapat umpan balik dari pengguna tentang kebutuhan mereka.
Pengembangan tangkas dengan pengiriman inkremental oleh karena itu merupakan hal yang umum digunakan
pendekatan untuk perangkat lunak yang akan digunakan sebagai layanan.
Saat Anda menerapkan SaaS, Anda harus memperhitungkan bahwa Anda mungkin
memiliki pengguna perangkat lunak dari beberapa organisasi yang berbeda. Anda harus mengambil
tiga faktor yang dipertimbangkan:
1. Konfigurabilitas Bagaimana Anda mengonfigurasi perangkat lunak untuk kebutuhan spesifik?
organisasi masing-masing?
2. Multi-tenancy Bagaimana Anda memberikan kesan kepada setiap pengguna perangkat lunak bahwa mereka
bekerja dengan salinan sistem mereka sendiri sementara, pada saat yang sama
waktu, memanfaatkan sumber daya sistem secara efisien?
3. Skalabilitas Bagaimana Anda mendesain sistem sehingga dapat diskalakan untuk mengakomodasi
berkencan dengan sejumlah besar pengguna yang tidak terduga?
Gagasan arsitektur lini produk, dibahas dalam Bab 16, adalah salah satu cara untuk
mengkonfigurasi perangkat lunak untuk pengguna yang memiliki persyaratan yang tumpang tindih tetapi tidak identik.
Anda mulai dengan sistem generik dan mengadaptasinya sesuai dengan persyaratan khusus
dari setiap pengguna.
Namun, ini tidak berfungsi untuk SaaS karena itu berarti menggunakan salinan yang berbeda
layanan untuk setiap organisasi yang menggunakan perangkat lunak. Sebaliknya, Anda perlu mendesain
konfigurasi ke dalam sistem dan menyediakan antarmuka konfigurasi yang memungkinkan pengguna
untuk menentukan preferensi mereka. Anda kemudian menggunakan ini untuk menyesuaikan perilaku perangkat lunak
dinamis seperti yang digunakan. Fasilitas konfigurasi memungkinkan hal-hal berikut:
1. Pencitraan merek, di mana pengguna dari setiap organisasi, disajikan dengan antarmuka
yang mencerminkan organisasi mereka sendiri.
2. Aturan dan alur kerja bisnis, di mana setiap organisasi mendefinisikan aturannya sendiri
yang mengatur penggunaan layanan dan datanya.
3. Ekstensi basis data, di mana setiap organisasi mendefinisikan bagaimana layanan generik
model data diperluas untuk memenuhi kebutuhan spesifiknya.
4. Kontrol akses, di mana pelanggan layanan membuat akun individu untuk staf mereka
dan menentukan sumber daya dan fungsi yang dapat diakses oleh masing-masing penggunanya.
Nama Kunci Penyewa Alamat
234 C100 XYZ Corp 43, Anystreet, Sometown
234 C110 BigCorp 2, Jalan Utama, Motown
Gambar 18.17 435 X234 J. Bowie 56, Mill St, Starville

Database multi-
592 PP37 R. Terbakar Alloway, Ayrshire
penyewa
Gambar 18.16 mengilustrasikan situasi ini. Diagram ini menunjukkan lima pengguna layanan aplikasi,
yang bekerja untuk tiga pelanggan berbeda dari penyedia layanan. Pengguna
berinteraksi dengan layanan melalui profil pelanggan yang mendefinisikan konfigurasi layanan untuk
pemberi kerja mereka.
Multi-tenancy adalah situasi di mana banyak pengguna yang berbeda mengakses sistem yang sama
dan arsitektur sistem didefinisikan untuk memungkinkan pembagian sistem yang efisien
sumber daya. Namun, harus terlihat bagi setiap pengguna bahwa mereka memiliki satu-satunya penggunaan
sistem. Multi-tenancy melibatkan perancangan sistem sehingga ada pemisahan mutlak antara
fungsionalitas sistem dan data sistem. Oleh karena itu, Anda harus
merancang sistem sehingga semua operasi tidak memiliki kewarganegaraan. Data harus disediakan
oleh klien atau harus tersedia dalam sistem penyimpanan atau database yang dapat
diakses dari setiap contoh sistem. Database relasional tidak ideal untuk menyediakan
multi-tenancy dan penyedia layanan besar, seperti Google, telah menerapkan database yang lebih
sederhana untuk data pengguna.
Masalah khusus dalam sistem multi-penyewa adalah manajemen data. Yang paling sederhana
cara untuk menyediakan manajemen data adalah untuk setiap pelanggan untuk memiliki database mereka sendiri,
yang dapat mereka gunakan dan konfigurasikan sesuai keinginan. Namun, ini membutuhkan layanan
penyedia untuk memelihara banyak contoh database yang berbeda (satu per pelanggan) dan untuk
membuat ini tersedia sesuai permintaan. Ini tidak efisien dalam hal kapasitas server dan
meningkatkan biaya layanan secara keseluruhan.
Sebagai alternatif, penyedia layanan dapat menggunakan database tunggal dengan berbagai
pengguna yang hampir terisolasi dalam database itu. Hal ini diilustrasikan pada Gambar 18.17,
di mana Anda dapat melihat bahwa entri basis data juga memiliki 'pengidentifikasi penyewa', yang menautkan
entri ini untuk pengguna tertentu. Dengan menggunakan tampilan database, Anda dapat mengekstrak entri
untuk setiap pelanggan layanan dan dengan demikian menghadirkan pengguna dari pelanggan itu dengan
basis data virtual, per pribadi. Ini dapat diperluas untuk memenuhi kebutuhan pelanggan tertentu
menggunakan fitur konfigurasi yang dibahas di atas.
Skalabilitas adalah kemampuan sistem untuk mengatasi peningkatan jumlah pengguna
tanpa mengurangi QoS keseluruhan yang dikirimkan ke pengguna mana pun. Umumnya, ketika
mempertimbangkan skalabilitas dalam konteks SaaS, Anda mempertimbangkan 'penskalaan', bukan
daripada 'meningkatkan'. Ingat bahwa 'scaling out' berarti menambahkan server tambahan dan sebagainya
juga meningkatkan jumlah transaksi yang dapat diproses secara paralel.
Skalabilitas adalah topik kompleks yang tidak dapat saya bahas secara detail di sini, tetapi beberapa hal umum
pedoman untuk mengimplementasikan perangkat lunak yang dapat diskalakan adalah:
1. Kembangkan aplikasi di mana setiap komponen diimplementasikan sebagai layanan tanpa status
sederhana yang dapat dijalankan di server mana pun. Dalam satu transaksi,
Bab 18 Poin - poin penting 505
oleh karena itu pengguna dapat berinteraksi dengan instance layanan yang sama yang berjalan
di beberapa server berbeda.
2. Merancang sistem menggunakan interaksi asinkron sehingga aplikasi tidak perlu menunggu hasil
interaksi (seperti permintaan baca). Ini memungkinkan aplikasi untuk terus melakukan pekerjaan
yang berguna sambil menunggu interaksi selesai.
3. Kelola sumber daya, seperti jaringan dan koneksi basis data, sebagai kumpulan sehingga tidak
ada satu server pun yang mungkin kehabisan sumber daya.
4. Rancang database Anda untuk memungkinkan penguncian butiran halus. Artinya, jangan mengunci
seluruh record dalam database ketika hanya sebagian dari record yang digunakan.
Gagasan SaaS adalah perubahan paradigma utama untuk komputasi terdistribusi. Daripada
organisasi yang menghosting banyak aplikasi di server mereka, SaaS memungkinkan aplikasi ini
disediakan secara eksternal oleh vendor yang berbeda. Kami berada di tengah-tengah transisi dari
satu model ke model lainnya dan, di masa depan, ini kemungkinan akan memiliki efek yang sangat
signifikan pada rekayasa sistem perangkat lunak perusahaan.
POIN KUNCI
Manfaat dari sistem terdistribusi adalah bahwa mereka dapat ditingkatkan untuk mengatasi peningkatan permintaan, dapat
terus menyediakan layanan pengguna (bahkan jika beberapa bagian dari sistem gagal), dan mereka memungkinkan
sumber daya untuk dibagikan.
Masalah yang harus dipertimbangkan dalam desain sistem terdistribusi meliputi transparansi, keterbukaan,
skalabilitas, keamanan, kualitas layanan, dan manajemen kegagalan.
Sistem klien-server adalah sistem terdistribusi di mana sistem terstruktur ke dalam lapisan, dengan lapisan presentasi
diimplementasikan pada komputer klien. Server menyediakan manajemen data, aplikasi, dan layanan basis data.
Sistem klien-server mungkin memiliki beberapa tingkatan, dengan lapisan berbeda dari sistem yang didistribusikan ke
komputer yang berbeda.
Pola arsitektur untuk sistem terdistribusi mencakup arsitektur master-slave, arsitektur client-server dua tingkat dan multi-
tingkat, arsitektur komponen terdistribusi, dan arsitektur peer-to-peer.
Sistem komponen terdistribusi memerlukan middleware untuk menangani komunikasi komponen dan memungkinkan komponen
ditambahkan dan dihapus dari sistem.
Arsitektur peer-to-peer adalah arsitektur terdesentralisasi di mana tidak ada perbedaan

klien dan server. Komputasi dapat didistribusikan melalui banyak sistem di organisasi yang berbeda.
Perangkat lunak sebagai layanan adalah cara menerapkan aplikasi sebagai sistem klien-server tipis, di mana
klien adalah browser web.
BACAAN LEBIH LANJUT
'Middleware: Sebuah model untuk layanan sistem terdistribusi'. Meskipun sedikit ketinggalan zaman, ini adalah makalah ikhtisar
yang sangat baik yang merangkum peran middleware dalam sistem terdistribusi dan membahas berbagai layanan middleware
yang mungkin disediakan. (PA Bernstein, Comm. ACM, 39 (2), Februari 1996.) http://dx.doi.org/10.1145/230798.230809.
Peer-to-Peer: Memanfaatkan Kekuatan Teknologi yang Mengganggu. Meskipun buku ini tidak memiliki banyak informasi
tentang arsitektur p2p, ini adalah pengantar yang sangat baik untuk komputasi p2p dan membahas organisasi dan pendekatan yang
digunakan dalam sejumlah sistem p2p. (A. Oram (ed.), O'Reilly and Associates Inc., 2001.)
'Mengubah perangkat lunak menjadi layanan'. Sebuah makalah gambaran yang baik yang membahas prinsip-prinsip komputasi
berorientasi layanan. Tidak seperti banyak makalah tentang topik ini, tidak menyembunyikan prinsip-prinsip ini di balik diskusi
tentang standar yang terlibat. (M. Turner, D. Budgen dan P. Brereton, IEEE Computer, 36 (10), Oktober 2003.) http://dx.doi.org/
10.1109/MC.2003.1236470.
Sistem Terdistribusi: Prinsip dan Paradigma, edisi ke-2. Buku teks komprehensif yang membahas semua aspek
desain dan implementasi sistem terdistribusi. Namun, itu tidak mencakup banyak diskusi tentang paradigma berorientasi layanan. (AS
Tanenbaum dan M. Van Steen, Addison Wesley, 2007.)
'Perangkat Lunak sebagai Layanan; Percikan yang akan Mengubah Rekayasa Perangkat Lunak. ' Sebuah makalah pendek yang
menyatakan bahwa munculnya SaaS akan mendorong semua pengembangan perangkat lunak ke model berulang. (G. Goth, Sistem
Terdistribusi Online, 9 (7), Juli 2008.) http://dx.doi.org/10.1109/MDSO.2008.21.
LATIHAN
18.1. Apa yang Anda pahami dengan 'skalabilitas'? Diskusikan perbedaan antara 'scaling up' dan 'scaling out' dan jelaskan
kapan pendekatan yang berbeda untuk skalabilitas ini dapat digunakan.
18.2. Jelaskan mengapa sistem perangkat lunak terdistribusi lebih kompleks daripada sistem perangkat lunak terpusat, di mana
semua fungsi sistem diimplementasikan pada satu komputer.
18.3. Dengan menggunakan contoh pemanggilan prosedur jarak jauh, jelaskan bagaimana middleware mengoordinasikan
interaksi komputer dalam sistem terdistribusi.
18.4. Apa perbedaan mendasar antara pendekatan klien gemuk dan klien tipis terhadap arsitektur sistem klien-server?
18.5. Anda telah diminta untuk merancang sistem aman yang memerlukan otentikasi yang kuat dan
otorisasi. Sistem harus dirancang sedemikian rupa sehingga komunikasi antar bagian sistem tidak dapat disadap dan
dibaca oleh penyerang. Sarankan arsitektur klien-server yang paling tepat untuk sistem ini dan, berikan alasan untuk
jawaban Anda, usulkan bagaimana fungsionalitas harus didistribusikan antara klien dan sistem server.
18.6. Pelanggan Anda ingin mengembangkan sistem informasi stok yang dapat diakses oleh dealer
informasi tentang perusahaan dan mengevaluasi berbagai skenario investasi menggunakan simulasi
sistem. Setiap dealer menggunakan simulasi ini dengan cara yang berbeda, sesuai dengan pengalamannya dan jenis
saham yang bersangkutan. Sarankan arsitektur klien-server untuk sistem ini yang menunjukkan di mana fungsionalitas
berada. Membenarkan model sistem klien-server yang telah Anda pilih.
18.7. Menggunakan pendekatan komponen terdistribusi, usulkan arsitektur untuk teater nasional
sistem pemesanan. Pengguna dapat memeriksa ketersediaan kursi dan memesan kursi di sekelompok teater. Sistem
harus mendukung pengembalian tiket sehingga orang dapat mengembalikan tiket mereka untuk dijual kembali pada
menit terakhir kepada pelanggan lain.
18.8. Berikan dua keuntungan dan dua kerugian dari desentralisasi dan semisentralisasi peer-to-peer
ilmu bangunan.
18.9. Jelaskan mengapa menggunakan perangkat lunak sebagai layanan dapat mengurangi biaya dukungan TI untuk perusahaan.
Biaya tambahan apa yang mungkin timbul jika model penerapan ini digunakan?
18.10. Perusahaan Anda ingin beralih dari menggunakan aplikasi desktop ke mengakses yang sama
fungsi jarak jauh sebagai layanan. Identifikasi tiga risiko yang mungkin muncul dan sarankan bagaimana risiko ini dapat
dikurangi.
REFERENSI
Bernstein, PA (1996). 'Middleware: Model untuk Layanan Sistem Terdistribusi'. Kom. ACM, 39 (2), 86–97.
Coulouris, G., Dollimore, J. dan Kindberg, T. (2005). Sistem Terdistribusi: Konsep dan Desain, edisi ke-4. Harlow, Inggris.:
Addison-Wesley.
Holdener, AT (2008). Ajax: Panduan Definitif. Sebastopol, California: O'Reilly and Associates.
McDougall, P. (2000). 'Kekuatan Peer-To-Peer'. Pekan Informasi (28 Agustus 2000).
Neuman, SM (1994). 'Skala dalam Sistem Terdistribusi'. Dalam Bacaan dalam Sistem Komputasi Terdistribusi.
Casavant, T. dan Singal, M. (ed.). Los Alamitos, California: IEEE Computer Society Press.
Oram, A. (2001). 'Peer-to-Peer: Memanfaatkan Manfaat Teknologi yang Mengganggu'.
Orfali, R. dan Harkey, D. (1998). Pemrograman Client/ Server dengan Java dan CORBA. New York: John Wiley & Sons.
Orfali, R., Harkey, D. dan Edwards, J. (1997). CORBA instan. Chichester, Inggris: John Wiley & Sons.
Paus, A. (1997). Panduan Referensi CORBA: Memahami Arsitektur Broker Permintaan Umum. Boston: Addison-
Wesley.
Tanenbaum, AS dan Van Steen, M. (2007). Sistem Terdistribusi: Prinsip dan Paradigma, edisi ke-2. Upper Saddle River,
NJ: Prentice Hall.
19
Arsitektur
berorientasi layanan
Tujuan
Tujuan dari bab ini adalah untuk memperkenalkan arsitektur perangkat lunak berorientasi
layanan sebagai cara membangun aplikasi terdistribusi menggunakan layanan web. Setelah
Anda membaca bab ini, Anda akan:
memahami pengertian dasar dari layanan web, standar layanan web, dan arsitektur berorientasi
layanan;
memahami proses rekayasa layanan yang dimaksudkan untuk menghasilkan layanan

web yang dapat digunakan kembali;
telah diperkenalkan dengan gagasan komposisi layanan sebagai sarana pengembangan aplikasi
berorientasi layanan;
memahami bagaimana model proses bisnis dapat digunakan sebagai dasar untuk
desain sistem berorientasi layanan.
Isi
19.1 Layanan sebagai komponen yang dapat
digunakan kembali 19.2 Rekayasa layanan 19.3
Pengembangan perangkat lunak dengan layanan

Bab 19 Arsitektur berorientasi layanan 509
Perkembangan Web pada 1990-an merevolusi pertukaran informasi organisasi. Komputer

klien dapat memperoleh akses ke informasi di server jauh di luar organisasi mereka sendiri.
Namun, akses hanya melalui browser web dan akses langsung ke informasi oleh program
lain tidak praktis. Ini berarti bahwa koneksi oportunistik antara server di mana, misalnya,
sebuah program menanyakan sejumlah katalog dari pemasok yang berbeda, tidak mungkin.
Untuk mengatasi masalah ini, gagasan tentang layanan web diusulkan. Menggunakan
layanan web, organisasi yang ingin membuat informasi mereka dapat diakses oleh program
lain dapat melakukannya dengan mendefinisikan dan menerbitkan antarmuka layanan web.
Antarmuka ini mendefinisikan data yang tersedia dan bagaimana data tersebut dapat diakses.
Lebih umum, layanan web adalah representasi standar untuk beberapa sumber daya
komputasi atau informasi yang dapat digunakan oleh program lain. Ini mungkin sumber
informasi, seperti katalog suku cadang; sumber daya komputer, seperti prosesor khusus;
atau sumber daya penyimpanan. Misalnya, layanan arsip dapat diterapkan yang secara
permanen dan andal menyimpan data organisasi yang, menurut undang-undang, harus
dipertahankan selama bertahun-tahun.
Layanan web adalah contoh dari gagasan yang lebih umum tentang layanan, yaitu
didefinisikan (Lovelock et al., 1996) sebagai:
“suatu tindakan atau kinerja yang ditawarkan oleh satu pihak kepada pihak lain.
Meskipun prosesnya mungkin terkait dengan produk fisik, kinerjanya pada dasarnya
tidak berwujud dan biasanya tidak menghasilkan kepemilikan atas salah satu faktor produksi”.
Inti dari sebuah layanan, oleh karena itu, adalah bahwa penyediaan layanan tidak
tergantung pada aplikasi yang menggunakan layanan tersebut (Turner et al., 2003). Penyedia
layanan dapat mengembangkan layanan khusus dan menawarkannya kepada berbagai
pengguna layanan dari organisasi yang berbeda.
Arsitektur berorientasi layanan (SOA) adalah cara mengembangkan sistem terdistribusi di
mana komponen sistem adalah layanan yang berdiri sendiri, dijalankan pada komputer yang
terdistribusi secara geografis. Protokol standar berbasis XML, seperti SOAP dan WSDL, telah
dirancang untuk mendukung komunikasi layanan dan pertukaran informasi. Akibatnya,
layanan adalah platform dan bahasa implementasi yang independen. Sistem perangkat lunak
dapat dibangun dengan menyusun layanan lokal dan layanan eksternal dari penyedia yang
berbeda, dengan interaksi tanpa batas antara layanan dalam sistem.
Gambar 19.1 merangkum ide SOA. Penyedia layanan merancang dan mengimplementasikan
layanan dan menentukan antarmuka ke layanan ini. Mereka juga mempublikasikan informasi
tentang layanan ini di registri yang dapat diakses. Pemohon layanan (kadang-kadang disebut
klien layanan) yang ingin menggunakan layanan menemukan spesifikasi layanan itu dan
menemukan penyedia layanan. Mereka kemudian dapat mengikat aplikasi mereka ke layanan
tertentu dan berkomunikasi dengannya, menggunakan protokol layanan standar.
Sejak awal, telah ada proses standardisasi aktif untuk SOA, bekerja bersama perkembangan
teknis. Semua perusahaan perangkat keras dan perangkat lunak utama berkomitmen pada
standar ini. Akibatnya, SOA belum
510 Bab 19 Arsitektur berorientasi layanan
Melayani
Registri
Menemukan Menerbitkan
Melayani Melayani
Melayani
Gambar 19.1 Arsitektur Pemohon Pemberi
mengikat (SOAP)
berorientasi layanan (WSDL)
menderita ketidaksesuaian yang biasanya muncul dengan inovasi teknis, di mana

pemasok yang berbeda mempertahankan versi teknologi milik mereka.
Gambar 19.2 menunjukkan tumpukan standar utama yang telah ditetapkan untuk
mendukung layanan web. Karena standarisasi awal ini, masalah, seperti beberapa
model komponen yang tidak kompatibel dalam CBSE, yang dibahas dalam Bab 17,
tidak muncul dalam pengembangan sistem berorientasi layanan.
Protokol layanan web mencakup semua aspek SOA, dari mekanisme dasar untuk
pertukaran informasi layanan (SOAP) hingga standar bahasa pemrograman (WS-
BPEL). Semua standar ini didasarkan pada XML, notasi yang dapat dibaca manusia
dan mesin yang memungkinkan definisi data terstruktur di mana teks ditandai dengan
pengidentifikasi yang berarti. XML memiliki berbagai teknologi pendukung, seperti
XSD untuk definisi skema, yang digunakan untuk memperluas dan memanipulasi
deskripsi XML. Erl (2004) memberikan ringkasan yang baik tentang teknologi XML dan perannya dalam layanan
Secara singkat, standar utama untuk SOA web adalah sebagai berikut:
1. SOAP Ini adalah standar pertukaran pesan yang mendukung komunikasi antar
layanan. Ini mendefinisikan komponen penting dan opsional dari pesan yang
dikirimkan antar layanan.
2. WSDL Web Service Definition Language (WSDL) adalah standar untuk definisi
antarmuka layanan. Ini menetapkan bagaimana operasi layanan (nama operasi,
parameter, dan jenisnya) dan binding layanan harus didefinisikan.
3. WS-BPEL Ini adalah standar untuk bahasa alur kerja yang digunakan untuk
mendefinisikan program proses yang melibatkan beberapa layanan berbeda.
Saya membahas gagasan program proses di Bagian 19.3.
Standar penemuan layanan, UDDI, juga diusulkan tetapi ini belum diadopsi secara
luas. Standar UDDI (Universal Description, Discovery and Integration) mendefinisikan
komponen spesifikasi layanan, yang dapat digunakan untuk menemukan keberadaan
layanan. Ini termasuk informasi tentang layanan
penyedia, layanan yang disediakan, lokasi deskripsi WSDL dari antarmuka es
layanan, dan informasi tentang hubungan bisnis. Tujuannya adalah bahwa standar
ini akan memungkinkan perusahaan untuk membuat pendaftar dengan deskripsi
UDDI yang mendefinisikan layanan yang mereka tawarkan.
Teknologi XML (XML, XSD, XSLT, ....)
Dukungan (WS-Keamanan, WS-Addressing, ...)
Proses (WS-BPEL)
Definisi Layanan (UDDI, WSDL)
Pesan (SOAP)
Gambar 19.2 Transportasi (HTTP, HTTPS, SMTP, ...)

Standar layanan web
Sejumlah perusahaan, seperti Microsoft, mendirikan pendaftar UDDI di tahun-tahun awal abad
ke-21 tetapi sekarang semuanya telah ditutup. Perbaikan dalam teknologi mesin pencari telah
membuat mereka mubazir. Penemuan layanan menggunakan mesin pencari standar untuk mencari
deskripsi WSDL yang dikomentari dengan tepat sekarang merupakan pendekatan yang lebih
disukai untuk menemukan layanan eksternal.
Standar SOA utama didukung oleh berbagai standar pendukung yang berfokus pada aspek
SOA yang lebih khusus. Ada sejumlah besar standar pendukung karena mereka dimaksudkan untuk
mendukung SOA dalam berbagai jenis aplikasi perusahaan. Beberapa contoh standar tersebut
antara lain sebagai berikut:
1. WS-Reliable Messaging, standar untuk pertukaran pesan yang memastikan pesan hanya akan
terkirim sekali dan hanya sekali.
2. WS-Security, seperangkat standar yang mendukung keamanan layanan web termasuk standar
yang menentukan definisi kebijakan keamanan dan standar yang mencakup penggunaan
tanda tangan digital.
3. WS-Addressing, yang mendefinisikan bagaimana informasi alamat harus direpresentasikan

dalam pesan SOAP.
4. WS-Transactions, yang mendefinisikan bagaimana transaksi di seluruh layanan terdistribusi

harus dikoordinasikan.
Standar layanan web adalah topik besar dan saya tidak memiliki ruang untuk membahasnya
secara rinci di sini. Saya merekomendasikan buku Erl (2004; 2005) untuk tinjauan umum tentang standar-standar ini.
Deskripsi rinci mereka juga tersedia sebagai dokumen publik di Web.
Standar layanan web saat ini telah dikritik sebagai standar 'kelas berat' yang terlalu umum dan
tidak efisien. Menerapkan standar ini memerlukan sejumlah besar pemrosesan untuk membuat,
mengirimkan, dan menafsirkan pesan XML terkait. Untuk alasan ini, beberapa organisasi, seperti
Amazon, menggunakan pendekatan yang lebih sederhana dan lebih efisien untuk komunikasi
layanan menggunakan apa yang disebut layanan RESTful (Richardson dan Ruby, 2007). Pendekatan
RESTful mendukung layanan yang efisien
Layanan web yang tenang
REST (REpresentational State Transfer) adalah gaya arsitektur yang didasarkan pada pemindahan representasi sumber daya
dari server ke klien. Ini adalah gaya yang mendasari web secara keseluruhan dan telah digunakan sebagai metode yang jauh lebih
sederhana daripada SOAP/WSDL untuk mengimplementasikan layanan web.
Layanan web RESTful diidentifikasi oleh URI (Pengidentifikasi Sumber Daya Universal) dan berkomunikasi menggunakan protokol
HTML. Ini merespons metode HTML GET, PUT, POST, dan DELETE dan mengembalikan representasi sumber daya ke klien. Secara
sederhana, POST berarti membuat, GET berarti membaca, PUT berarti memperbarui, dan DELETE berarti menghapus.
Layanan RESTFul melibatkan overhead yang lebih rendah daripada yang disebut 'layanan web besar' dan digunakan oleh banyak
organisasi yang menerapkan sistem berbasis layanan yang tidak bergantung pada layanan yang disediakan secara eksternal.
http://www.SoftwareEngineering-9.com/Web/Services/REST/
interaksi tetapi tidak mendukung fitur tingkat perusahaan seperti WS-Reliability dan WS-
Transactions. Pautaso dkk. (2008) membandingkan pendekatan RESTful dengan layanan web
standar.
Membangun aplikasi berdasarkan layanan memungkinkan perusahaan dan organisasi
lain untuk bekerja sama dan memanfaatkan fungsi bisnis satu sama lain. Dengan demikian,
sistem yang melibatkan pertukaran informasi yang luas melintasi batas-batas perusahaan,
seperti sistem rantai pasokan di mana satu perusahaan memesan barang dari yang lain, dapat
dengan mudah diotomatisasi. Aplikasi berbasis layanan dapat dibangun dengan
menghubungkan layanan dari berbagai penyedia menggunakan bahasa pemrograman standar
atau bahasa alur kerja khusus, seperti yang dibahas dalam Bagian 19.3.
SOA adalah arsitektur yang digabungkan secara longgar di mana pengikatan layanan
dapat berubah selama eksekusi. Ini berarti bahwa versi layanan yang berbeda tetapi setara
dapat dijalankan pada waktu yang berbeda. Beberapa sistem hanya akan dibangun
menggunakan layanan web dan yang lain akan menggabungkan layanan web dengan
komponen yang dikembangkan secara lokal. Untuk mengilustrasikan bagaimana aplikasi yang
menggunakan campuran layanan dan komponen dapat diatur, pertimbangkan skenario berikut:
Sistem informasi dalam mobil memberikan informasi kepada pengemudi tentang cuaca,
kondisi lalu lintas jalan, informasi lokal, dan sebagainya. Hal ini terkait dengan radio
mobil sehingga informasi disampaikan sebagai sinyal pada saluran radio tertentu.
Mobil dilengkapi dengan penerima GPS untuk mengetahui posisinya dan, berdasarkan
posisi itu, sistem mengakses berbagai layanan informasi. Informasi kemudian dapat
disampaikan dalam bahasa yang ditentukan pengemudi.
Gambar 19.3 mengilustrasikan kemungkinan organisasi untuk sistem seperti itu. Perangkat
lunak dalam mobil mencakup lima modul. Ini menangani komunikasi dengan pengemudi,
dengan penerima GPS yang melaporkan posisi mobil dan dengan radio mobil. Modul Pemancar
dan Penerima menangani semua komunikasi dengan layanan eksternal.
Mobil berkomunikasi dengan layanan informasi seluler eksternal yang mengumpulkan
informasi dari berbagai layanan lain, memberikan informasi tentang cuaca,
Info Lalu Lintas Jalan
Cuaca Fasilitas Jalan Lalu lintas

Info Info pencari lokasi Info
Koordinat GPS
Koordinat GPS
Koordinat GPS
Layanan Info Seluler Penemuan Layanan

Penerjemah
Mengumpulkan Informasi Temukan Tersedia
Jasa
Bahasa
Info
Info Memerintah
Sungai kecil Koordinat GPS
Penerima Pemancar Antarmuka pengguna
menerima Mengirim Posisi dan Menerima Permintaan

Aliran Informasi Permintaan Informasi ke Dari Pengguna
Dari Layanan Layanan
Radio pencari lokasi
Menerjemahkan Digital Menemukan Mobil

Aliran Info ke Posisi
Gambar 19.3
Sinyal Radio
Sistem informasi dalam
Sistem Perangkat Lunak Dalam Mobil
mobil berbasis layanan
informasi lalu lintas, dan fasilitas lokal. Penyedia yang berbeda di tempat yang berbeda
menawarkan layanan ini, dan sistem dalam mobil menggunakan layanan penemuan untuk
menemukan layanan informasi yang sesuai dan mengikatnya. Layanan penemuan juga
digunakan oleh layanan informasi seluler untuk mengikat layanan cuaca, lalu lintas, dan
fasilitas yang sesuai. Layanan pertukaran pesan SOAP yang menyertakan informasi
posisi GPS yang digunakan oleh layanan untuk memilih informasi yang sesuai. Informasi
yang terkumpul kemudian dikirim ke mobil melalui layanan yang menerjemahkan informasi
tersebut ke dalam bahasa pilihan pengemudi.
Contoh ini menggambarkan salah satu keuntungan utama dari pendekatan berorientasi
layanan. Tidak perlu memutuskan kapan sistem diprogram atau disebarkan penyedia
layanan apa yang harus digunakan atau layanan spesifik apa yang harus diakses.
Saat mobil bergerak, perangkat lunak dalam mobil menggunakan layanan penemuan
layanan untuk menemukan layanan informasi yang paling tepat dan mengikatnya. Karena
penggunaan layanan terjemahan, layanan ini dapat berpindah lintas batas dan oleh karena
itu membuat informasi lokal tersedia bagi orang-orang yang tidak berbicara bahasa lokal.
Pendekatan berorientasi layanan untuk rekayasa perangkat lunak adalah paradigma rekayasa perangkat
lunak baru yang, dalam pandangan saya, sama pentingnya dengan pengembangan perangkat lunak berorientasi objek.
Rekayasa perangkat lunak berorientasi layanan dan berorientasi komponen
Layanan dan komponen jelas memiliki banyak kesamaan. Keduanya merupakan elemen yang dapat digunakan
kembali dan, seperti yang saya bahas di Bab 17, adalah mungkin untuk menganggap komponen sebagai penyedia layanan. Namun, ada
perbedaan penting antara layanan dan komponen, dan antara pendekatan berorientasi layanan dan berorientasi
komponen pada rekayasa perangkat lunak.
http://www.SoftwareEngineering-9.com/Web/Services/Comps.html
rekayasa. Pergeseran paradigma ini akan dipercepat oleh pengembangan 'cloud

komputasi' (Carr, 2009), di mana layanan ditawarkan pada infrastruktur komputasi utilitas yang
diselenggarakan oleh penyedia utama, seperti Google dan Amazon. Ini telah dan akan
terus memiliki efek mendalam pada produk sistem dan proses bisnis.
Pendatang baru dan Lomow (2005), dalam buku mereka tentang SOA, merangkum potensi
pendekatan berorientasi layanan:
“Didorong oleh konvergensi teknologi utama dan adopsi universal dari

Layanan web, perusahaan berorientasi layanan berjanji untuk meningkatkan secara signifikan
kelincahan perusahaan, mempercepat waktu ke pasar untuk produk dan layanan baru, mengurangi
biaya TI dan meningkatkan efisiensi operasional.”
Kami masih pada tahap yang relatif awal dalam pengembangan berorientasi layanan
aplikasi yang diakses melalui Web. Namun, kita sudah melihat mayor
perubahan cara perangkat lunak diimplementasikan dan disebarkan, dengan munculnya
sistem seperti Google Apps dan Salesforce.com. Pendekatan berorientasi layanan di
baik aplikasi dan tingkat implementasi berarti bahwa Web berkembang
dari penyimpanan informasi ke platform implementasi sistem.
19.1 Layanan sebagai komponen yang dapat digunakan kembali
Dalam Bab 17, saya memperkenalkan rekayasa perangkat lunak berbasis komponen (CBSE), di
sistem perangkat lunak mana yang dibangun dengan menyusun komponen perangkat lunak yang
berdasarkan model komponen standar. Layanan adalah pengembangan alami dari komponen
perangkat lunak di mana model komponen pada dasarnya adalah seperangkat standar yang
diasosiasikan dengan layanan web. Oleh karena itu, layanan dapat didefinisikan sebagai berikut:
Komponen perangkat lunak yang dapat digunakan kembali dan digabungkan secara longgar yang merangkum diskrit
fungsionalitas, yang dapat didistribusikan dan diakses secara terprogram.

Layanan web adalah layanan yang diakses menggunakan Internet standar dan protokol
berbasis XML.
19.1 Layanan sebagai komponen yang dapat digunakan kembali 515
Perbedaan penting antara layanan dan komponen perangkat lunak, sebagaimana

didefinisikan dalam CBSE, adalah bahwa layanan harus independen dan digabungkan secara
longgar; yaitu, mereka harus selalu beroperasi dengan cara yang sama, terlepas dari lingkungan eksekusinya.
Antarmuka mereka adalah antarmuka 'menyediakan' yang memungkinkan akses ke
fungsionalitas layanan. Layanan dimaksudkan untuk independen dan dapat digunakan dalam konteks yang berbeda.
Oleh karena itu, mereka tidak memiliki antarmuka 'memerlukan' yang, dalam CBSE,
mendefinisikan komponen sistem lain yang harus ada.
Layanan berkomunikasi dengan bertukar pesan, dinyatakan dalam XML, dan pesan ini
didistribusikan menggunakan protokol transportasi Internet standar seperti HTTP dan TCP/IP.
Saya telah membahas pendekatan berbasis pesan ini untuk komunikasi komponen di Bagian
18.1.1. Sebuah layanan mendefinisikan apa yang dibutuhkannya dari layanan lain dengan
menetapkan persyaratannya dalam sebuah pesan dan mengirimkannya ke layanan itu.
Layanan penerima mem-parsing pesan, melakukan perhitungan dan, setelah selesai,
mengirimkan balasan, sebagai pesan, ke layanan yang meminta. Layanan ini kemudian mem-
parsing balasan untuk mengekstrak informasi yang diperlukan. Tidak seperti komponen
perangkat lunak, layanan tidak menggunakan prosedur jarak jauh atau panggilan metode untuk mengakses fungsional
Saat Anda bermaksud menggunakan layanan web, Anda perlu mengetahui di mana lokasi
layanan (URI-nya) dan detail antarmukanya. Ini dijelaskan dalam deskripsi layanan yang
dinyatakan dalam bahasa berbasis XML yang disebut WSDL. Spesifikasi WSDL mendefinisikan
tiga hal tentang layanan web: apa yang dilakukan layanan, bagaimana berkomunikasi, dan di
mana menemukannya:
1. Bagian 'apa' dari dokumen WSDL, yang disebut antarmuka, menentukan operasi apa yang
didukung layanan, dan mendefinisikan format pesan yang dikirim dan diterima oleh
layanan.
2. Bagian 'bagaimana' dari dokumen WSDL, yang disebut binding, memetakan antarmuka
abstrak ke seperangkat protokol yang konkret. Pengikatan menentukan detail teknis
tentang cara berkomunikasi dengan layanan web.
3. Bagian 'di mana' dari dokumen WSDL menjelaskan lokasi implementasi layanan web
tertentu (titik akhirnya).
Model konseptual WSDL (Gambar 19.4) menunjukkan elemen deskripsi layanan. Masing-
masing dinyatakan dalam XML dan dapat disediakan dalam file terpisah. Bagian-bagian ini
adalah:
1. Bagian pengantar yang biasanya mendefinisikan ruang nama XML yang digunakan dan
yang mungkin termasuk bagian dokumentasi yang menyediakan informasi tambahan
tentang layanan.
2. Deskripsi opsional tentang jenis yang digunakan dalam pesan yang dipertukarkan oleh
melayani.
3. Deskripsi antarmuka layanan; yaitu, operasi yang disediakan layanan untuk layanan atau
pengguna lain.
4. Deskripsi pesan input dan output yang diproses oleh layanan.

Definisi Layanan WSDL
Pendahuluan
Deklarasi Namespace XML
Jenis Deklarasi
Antarmuka Abstrak Deklarasi Antarmuka
Deklarasi Pesan
Konkret Deklarasi yang Mengikat

Penerapan Deklarasi titik akhir
Gambar 19.4 Organisasi
spesifikasi WSDL
5. Deskripsi pengikatan yang digunakan oleh layanan (yaitu, protokol pengiriman pesan
yang akan digunakan untuk mengirim dan menerima pesan). Standarnya adalah
SOAP tetapi binding lain juga dapat ditentukan. Pengikatan menetapkan bagaimana
pesan input dan output yang terkait dengan layanan harus dikemas ke dalam
pesan, dan menentukan protokol komunikasi yang digunakan. Pengikatan juga
dapat menentukan bagaimana informasi pendukung, seperti kredensial keamanan
atau pengidentifikasi transaksi, disertakan.
6. Spesifikasi titik akhir yang merupakan lokasi fisik layanan, dinyatakan sebagai
Uniform Resource Identifier (URI)—alamat sumber daya yang dapat diakses melalui
Internet.
Deskripsi layanan lengkap, ditulis dalam XML, panjang, terperinci, dan membosankan
untuk dibaca. Mereka biasanya menyertakan definisi ruang nama XML, yang merupakan
kualifikasi untuk nama. Pengidentifikasi ruang nama dapat mendahului pengidentifikasi
apa pun yang digunakan dalam deskripsi XML, sehingga memungkinkan untuk
membedakan antara pengidentifikasi dengan nama yang sama yang telah ditentukan di
bagian yang berbeda dari deskripsi XML. Anda tidak perlu memahami detail ruang nama
untuk memahami contoh di sini. Anda hanya perlu mengetahui bahwa nama dapat
diawali dengan pengidentifikasi namespace dan pasangan name space:name harus unik.
Spesifikasi WSDL sekarang jarang ditulis dengan tangan dan sebagian besar
informasi dalam spesifikasi dapat dibuat secara otomatis. Anda tidak perlu mengetahui
detail spesifikasi untuk memahami prinsip-prinsip WSDL, jadi saya fokus di sini pada
deskripsi antarmuka abstrak. Ini adalah bagian dari spesifikasi WSDL yang setara
dengan antarmuka 'menyediakan' komponen perangkat lunak. Gambar 19.5 menunjukkan
bagian dari antarmuka untuk layanan sederhana yang, dengan diberi tanggal dan
tempat, ditetapkan sebagai kota dalam suatu negara, mengembalikan suhu maksimum
dan minimum yang tercatat di tempat itu pada tanggal tersebut. Pesan input juga
menentukan apakah suhu ini akan dikembalikan dalam derajat Celcius atau derajat Fahrenheit.
Pada Gambar 19.5, bagian pertama dari deskripsi menunjukkan bagian dari definisi
elemen dan tipe yang digunakan dalam spesifikasi layanan. Ini mendefinisikan elemen
PlaceAndDate, MaxMinTemp, dan InDataFault. Saya hanya menyertakan spesifikasi
PlaceAndDate, yang dapat Anda anggap sebagai catatan dengan tiga bidang—kota,
negara, dan tanggal. Pendekatan serupa akan digunakan untuk mendefinisikan MaxMinTemp dan InDataFault.
19.1 Layanan sebagai komponen yang dapat digunakan kembali 517
Tentukan beberapa jenis yang digunakan. Asumsikan bahwa awalan namespace 'ws' mengacu
pada URI namespace untuk skema XML dan awalan namespace yang terkait dengan definisi ini
adalah weathns.
<types>
<xs: schema targetNameSpace = “http://.../weathns” xmlns:
weathns = “http://. . ./weathns” > <xs:nama elemen =
“PlaceAndDate” type = “pdrec” /> <xs:element name =
“MaxMinTemp” type = “mmtrec” /> <xs:element name =
“InDataFault” type = “errmess ” />
<xs:complexType name = “pdrec”

<xs:urutan>
<xs:nama elemen = “kota” type = “xs:string”/> <xs:nama
elemen = “negara” type = “xs:string”/> <xs:nama elemen =
“hari” type = “xs: tanggal” /> </xs:complexType>
Definisi MaxMinType dan InDataFault di sini

</skema>
</jenis>
Sekarang tentukan antarmuka dan operasinya. Dalam hal ini, hanya ada satu operasi untuk
mengembalikan suhu maksimum dan minimum.
<nama antarmuka = “info cuaca” >
<nama operasi = “getMaxMinTemps” pattern = “wsdlns: in-out”> <input
messageLabel = “In” element = “weathns: PlaceAndDate” /> <output
messageLabel = “Out” element = “weathns:MaxMinTemp” /> < outfault
messageLabel = “Out” element = “weathns:InDataFault” /> </operation> </interface>
Bagian kedua dari deskripsi menunjukkan bagaimana antarmuka layanan

didefinisikan. Pada Gambar 19.5 Bagian dari contoh ini, layanan weatherInfo memiliki operasi
tunggal,
operasi yang dapat ditentukan.meskipun tidak operasi
WeatherInfo ada deskripsi
layananWSDL untuk pembatasan
web memiliki jumlah
pola masuk-keluar
satu pesan output. Spesifikasi
terkait yangWSDL
berarti
2.0bahwa
memungkinkan
dibutuhkansejumlah
satu pesan
polainput
pertukaran
dan menghasilkan
pesan yang
berbeda seperti in-only, in-out, out-only, in-optional-out, out-in, dll. Pesan
input dan output, yang mengacu pada definisi dibuat sebelumnya di bagian
jenis, kemudian didefinisikan.
Masalah utama dengan WSDL adalah bahwa definisi antarmuka layanan

tidak mencakup informasi apa pun tentang semantik layanan atau
karakteristik non-fungsionalnya, seperti kinerja dan ketergantungan. Ini
hanyalah deskripsi tanda tangan layanan (yaitu, operasi dan parameternya). Programmer
siapa yang berencana menggunakan layanan harus mengetahui apa yang sebenarnya dilakukan
layanan dan apa arti bidang yang berbeda dalam pesan input dan output. Kinerja dan
ketergantungan harus ditemukan dengan bereksperimen dengan layanan. Nama dan
dokumentasi yang bermakna membantu memahami fungsi yang ditawarkan tetapi masih
mungkin bagi pembaca untuk salah memahami layanan tersebut.
19.2 Rekayasa layanan
Rekayasa layanan adalah proses pengembangan layanan untuk digunakan kembali dalam
aplikasi berorientasi layanan. Ini memiliki banyak kesamaan dengan rekayasa komponen.
Insinyur layanan harus memastikan bahwa layanan tersebut mewakili abstraksi yang dapat
digunakan kembali yang dapat berguna dalam sistem yang berbeda. Mereka harus merancang
dan mengembangkan fungsi yang secara umum berguna terkait dengan abstraksi tersebut dan
memastikan bahwa layanan tersebut kuat dan dapat diandalkan. Mereka harus
mendokumentasikan layanan sehingga dapat ditemukan dan dipahami oleh pengguna potensial.
Ada tiga tahap logis dalam proses rekayasa layanan, seperti yang ditunjukkan pada:
Gambar 19.6. Ini adalah sebagai berikut:
1. Identifikasi kandidat layanan, di mana Anda mengidentifikasi kemungkinan layanan yang mungkin
diimplementasikan dan menentukan persyaratan layanan.
2. Desain layanan, di mana Anda mendesain antarmuka layanan logis dan WSDL.
3. Implementasi dan penerapan layanan, di mana Anda mengimplementasikan dan menguji

layanan dan membuatnya tersedia untuk digunakan.
Seperti yang saya bahas di Bab 16, pengembangan komponen yang dapat digunakan
kembali dapat dimulai dengan komponen yang sudah ada yang telah diimplementasikan dan
digunakan dalam aplikasi. Hal yang sama berlaku untuk layanan—titik awal untuk proses ini
sering kali berupa layanan yang sudah ada atau komponen yang akan diubah menjadi layanan.
Dalam situasi ini, proses desain melibatkan generalisasi komponen yang ada sehingga fitur
khusus aplikasi dihapus. Implementasi berarti mengadaptasi komponen dengan menambahkan
antarmuka layanan dan mengimplementasikan generalisasi yang diperlukan.
19.2.1 Identifikasi kandidat layanan

Gagasan dasar komputasi berorientasi layanan adalah bahwa layanan harus mendukung proses
bisnis. Karena setiap organisasi memiliki rentang proses yang luas, maka ada banyak
kemungkinan layanan yang dapat diimplementasikan. Oleh karena itu, identifikasi kandidat
layanan melibatkan pemahaman dan analisis proses bisnis organisasi untuk memutuskan
layanan yang dapat digunakan kembali mana yang dapat diterapkan untuk mendukung proses
ini.
19.2 Rekayasa layanan 519
Melayani Melayani
Calon Desain Layanan Implementasi
Identifikasi dan Penerapan
Melayani Antarmuka Layanan Divalidasi dan

Persyaratan Spesifikasi Layanan yang Diterapkan
Gambar 19.6 Proses
rekayasa layanan
Erl menyarankan bahwa ada tiga jenis layanan mendasar yang dapat diidentifikasi:
1. Layanan utilitas Ini adalah layanan yang mengimplementasikan beberapa fungsionalitas

umum yang mungkin digunakan oleh proses bisnis yang berbeda. Contoh layanan
utilitas adalah layanan konversi mata uang yang dapat diakses untuk menghitung
konversi satu mata uang (misalnya, dolar) ke mata uang lainnya (misalnya, euro).
2. Layanan bisnis Ini adalah layanan yang terkait dengan fungsi bisnis tertentu. Contoh
fungsi bisnis di universitas adalah pendaftaran mahasiswa untuk suatu mata kuliah.
3. Koordinasi atau layanan proses Ini adalah layanan yang mendukung proses bisnis
yang lebih umum yang biasanya melibatkan pelaku dan aktivitas yang berbeda.
Contoh layanan koordinasi dalam suatu perusahaan adalah layanan pemesanan
yang memungkinkan pemesanan dilakukan dengan pemasok, penerimaan barang, dan pembayaran dilakuk
Erl juga menyarankan bahwa layanan dapat dianggap sebagai berorientasi tugas
atau berorientasi entitas. Layanan berorientasi tugas adalah yang terkait dengan beberapa
aktivitas, sedangkan layanan berorientasi entitas seperti objek. Mereka terkait dengan
entitas bisnis seperti, misalnya, formulir lamaran kerja. Gambar 19.7 menunjukkan
beberapa contoh layanan yang berorientasi pada tugas atau entitas. Layanan utilitas atau
bisnis mungkin berorientasi pada entitas atau tugas tetapi layanan koordinasi selalu berorientasi pada tugas.
Tujuan Anda dalam identifikasi kandidat layanan adalah untuk mengidentifikasi layanan yang
koheren secara logis, independen, dan dapat digunakan kembali. Klasifikasi Erl sangat membantu
dalam hal ini karena menunjukkan bagaimana menemukan layanan yang dapat digunakan kembali
dengan melihat entitas bisnis dan aktivitas bisnis. Namun, mengidentifikasi kandidat layanan
terkadang sulit karena Anda harus membayangkan bagaimana layanan akan digunakan. Anda harus
memikirkan kandidat yang mungkin kemudian mengajukan serangkaian pertanyaan tentang mereka
untuk melihat apakah mereka mungkin merupakan layanan yang berguna. Kemungkinan pertanyaan
yang mungkin Anda tanyakan untuk mengidentifikasi layanan yang berpotensi dapat digunakan kembali adalah:
1. Untuk layanan berorientasi entitas, apakah layanan terkait dengan entitas logis tunggal
yang digunakan dalam proses bisnis yang berbeda? Operasi apa yang biasanya
dilakukan pada entitas yang harus didukung?
Kegunaan Bisnis Koordinasi
Tugas Konverter mata uang Validasi formulir klaim Klaim biaya proses
pencari karyawan Periksa peringkat kredit Bayar pemasok eksternal
Kesatuan Pemeriksa gaya dokumen Formulir pengeluaran

Konverter formulir web ke XML Formulir pendaftaran siswa
2. Untuk layanan berorientasi tugas, apakah tugas tersebut dilakukan oleh orang yang berbeda
Gambar 19.7 Klasifikasi
layanan dalam organisasi? Akankah mereka bersedia menerima standarisasi yang tak terhindarkan
yang terjadi ketika layanan dukungan tunggal disediakan?
3. Apakah layanan independen (yaitu, sejauh mana bergantung pada ketersediaan layanan lain)?
4. Untuk pengoperasiannya, apakah layanan harus mempertahankan status? Layanan tidak memiliki
kewarganegaraan, yang berarti bahwa mereka tidak mempertahankan status internal. Jika
informasi negara diperlukan, database harus digunakan dan ini dapat membatasi penggunaan
kembali layanan. Secara umum, layanan di mana status diteruskan ke layanan lebih mudah
digunakan kembali, karena tidak diperlukan pengikatan basis data.
5. Apakah layanan tersebut dapat digunakan oleh klien di luar organisasi? Misalnya, layanan
berorientasi entitas yang terkait dengan katalog dapat diakses oleh pengguna internal dan
eksternal.
6. Apakah pengguna layanan yang berbeda cenderung memiliki kebutuhan nonfungsional yang
berbeda? Jika ya, maka ini menunjukkan bahwa lebih dari satu versi layanan mungkin harus
diimplementasikan.
Jawaban atas pertanyaan-pertanyaan ini membantu Anda memilih dan memperbaiki abstraksi
yang dapat diimplementasikan sebagai layanan. Namun, tidak ada cara formula untuk memutuskan
layanan mana yang terbaik sehingga identifikasi layanan adalah proses berbasis keterampilan dan pengalaman.
Output dari proses pemilihan layanan adalah serangkaian layanan yang diidentifikasi dan
persyaratan terkait untuk layanan ini. Persyaratan layanan fungsional harus menentukan apa yang
harus dilakukan layanan. Persyaratan non-fungsional harus mendefinisikan persyaratan keamanan,
kinerja, dan ketersediaan layanan.
Untuk membantu Anda memahami proses identifikasi dan implementasi kandidat layanan,
perhatikan contoh berikut:
Sebuah perusahaan besar, yang menjual peralatan komputer, telah mengatur harga khusus
untuk konfigurasi yang disetujui untuk beberapa pelanggan. Untuk memfasilitasi pemesanan
otomatis, perusahaan ingin menghasilkan layanan katalog yang memungkinkan pelanggan
memilih peralatan yang mereka butuhkan. Tidak seperti katalog konsumen, pesanan tidak
ditempatkan secara langsung melalui antarmuka katalog. Sebaliknya, barang dipesan melalui
sistem pengadaan berbasis web dari masing-masing perusahaan yang mengakses katalog
sebagai layanan web. Sebagian besar perusahaan memiliki penganggaran sendiri dan
prosedur persetujuan untuk pesanan dan proses pemesanan mereka sendiri harus
diikuti ketika pesanan ditempatkan.
Layanan katalog adalah contoh layanan berorientasi entitas yang mendukung bisnis
operasi ness. Persyaratan layanan katalog fungsional adalah sebagai berikut:
1. Versi khusus dari katalog harus disediakan untuk setiap perusahaan pengguna. Ini harus
mencakup konfigurasi dan peralatan yang dapat dipesan oleh karyawan perusahaan
pelanggan dan harga yang disepakati untuk item katalog.
2. Katalog akan memungkinkan karyawan pelanggan untuk mengunduh versi kata

log untuk penjelajahan offline.
3. Katalog akan memungkinkan pengguna untuk membandingkan spesifikasi dan harga hingga
enam item katalog.
4. Katalog harus menyediakan fasilitas penelusuran dan pencarian bagi pengguna.
5. Pengguna katalog harus dapat menemukan perkiraan tanggal pengiriman untuk sejumlah
item katalog tertentu.
6. Pengguna katalog harus dapat menempatkan 'pesanan virtual' di mana barang-barang yang
dibutuhkan akan dipesan untuk mereka selama 48 jam. Pesanan virtual harus dikonfirmasi
oleh pesanan nyata yang ditempatkan oleh sistem pengadaan. Ini harus diterima dalam
waktu 48 jam dari pesanan virtual.
Selain persyaratan fungsional ini, katalog memiliki sejumlah persyaratan non fungsional:
1. Akses ke layanan katalog harus dibatasi untuk karyawan yang terakreditasi

organisasi.
2. Harga dan konfigurasi yang ditawarkan kepada satu pelanggan harus bersifat rahasia dan
tidak akan tersedia untuk karyawan pelanggan lain.
3. Katalog akan tersedia tanpa gangguan layanan mulai pukul 0700 GMT hingga
1100 GMT.
4. Layanan katalog harus dapat memproses hingga 10 permintaan per detik beban puncak.
Perhatikan bahwa tidak ada persyaratan non-fungsional yang terkait dengan waktu respons
layanan katalog. Ini tergantung pada ukuran katalog dan jumlah pengguna simultan yang
diharapkan. Karena ini bukan layanan yang kritis terhadap waktu, tidak perlu menentukannya
pada tahap ini.
19.2.2 Desain antarmuka layanan

Setelah Anda memilih kandidat layanan, tahap selanjutnya dalam proses rekayasa layanan
adalah merancang antarmuka layanan. Ini melibatkan mendefinisikan operasi yang terkait
dengan layanan dan parameternya. Anda juga harus berpikir dengan hati-hati
Operasi Keterangan
BuatKatalog Membuat versi katalog yang disesuaikan untuk pelanggan tertentu. Termasuk opsional
parameter untuk membuat katalog versi PDF yang dapat diunduh.
Membandingkan Memberikan perbandingan hingga enam karakteristik (misalnya, harga, dimensi, prosesor
kecepatan, dll.) hingga empat item katalog.
Lihatlah Menampilkan semua data yang terkait dengan item katalog tertentu.
Mencari Operasi ini mengambil ekspresi logis dan mencari katalog sesuai dengan itu
ekspresi. Ini menampilkan daftar semua item yang cocok dengan ekspresi pencarian.
CekPengiriman Mengembalikan tanggal pengiriman yang diprediksi untuk item jika dipesan hari itu.
BuatPesanan Virtual Cadangan jumlah item yang akan dipesan oleh pelanggan dan menyediakan item
informasi untuk sistem pengadaan pelanggan itu sendiri.
tentang desain operasi layanan dan pesan. Tujuan Anda harus minimal Gambar 19.8
Fungsional
deskripsi katalog meniru jumlah pertukaran pesan yang harus dilakukan untuk menyelesaikan layanan
operasi layanan meminta. Anda harus memastikan bahwa sebanyak mungkin informasi diteruskan ke
layanan dalam pesan daripada menggunakan interaksi layanan sinkron.
Anda juga harus ingat bahwa layanan tidak memiliki kewarganegaraan dan mengelola
status aplikasi khusus layanan adalah tanggung jawab pengguna layanan dan bukan
layanan itu sendiri. Oleh karena itu, Anda mungkin harus meneruskan informasi negara bagian ini ke dan dari
layanan dalam pesan input dan output.
Ada tiga tahap untuk desain antarmuka layanan:
1. Desain antarmuka logis, di mana Anda mengidentifikasi operasi yang terkait dengan
layanan, input dan output mereka dan pengecualian yang terkait dengan ini
operasi.
2. Desain pesan, di mana Anda mendesain struktur pesan yang dikirim

dan diterima oleh layanan.
3. Pengembangan WSDL, di mana Anda menerjemahkan desain logis dan pesan Anda ke
deskripsi antarmuka abstrak yang ditulis dalam WSDL.
Tahap pertama, desain antarmuka logis, dimulai dengan persyaratan layanan dan
mendefinisikan nama operasi dan parameter. Pada tahap ini, Anda juga harus mendefinisikan
pengecualian yang mungkin timbul ketika operasi layanan dipanggil. Gambar 19.8 dan
Gambar 19.9 menunjukkan operasi yang mengimplementasikan persyaratan dan input,
output, dan pengecualian untuk setiap operasi katalog. Pada tahap ini, tidak perlu
agar ini ditentukan secara rinci — Anda menambahkan detail pada tahap desain berikutnya
proses.
Mendefinisikan pengecualian dan bagaimana ini dapat dikomunikasikan kepada
pengguna layanan sangat penting. Insinyur layanan tidak tahu bagaimana layanan mereka akan digunakan.
gdIn
ukuran (cID) = 6
cID: string
ukuran (catNum) = 10
catNum: string
numItems > 0
numItems: integer
gdOut
size (catNum) = 10
catNum: string delivDate > Today
delivTanggal: tanggal
ID perusahaan tidak
gdFault valid errCode = 1
Nomor katalog tidak valid

errCode: integer
errCode = 2
Tidak ada
ketersediaan errCode = 3
Nol item yang diminta

Gambar 19.9 Desain errCode = 4
antarmuka katalog
Biasanya tidak bijaksana untuk membuat asumsi bahwa pengguna layanan akan sepenuhnya
memahami spesifikasi layanan. Pesan input mungkin salah sehingga Anda harus menentukan
pengecualian yang melaporkan input yang salah ke klien layanan. Secara umum, praktik yang
baik dalam pengembangan komponen yang dapat digunakan kembali adalah menyerahkan
semua penanganan pengecualian kepada pengguna komponen. Pengembang layanan tidak
boleh memaksakan pandangan mereka tentang bagaimana pengecualian harus ditangani.
Setelah Anda menetapkan deskripsi logis informal tentang apa yang harus dilakukan layanan,
tahap selanjutnya adalah menentukan struktur pesan input dan output dan jenis yang digunakan
dalam pesan ini. XML adalah notasi yang canggung untuk digunakan pada tahap ini. Saya pikir
lebih baik merepresentasikan pesan sebagai objek dan mendefinisikannya menggunakan UML
atau dalam bahasa pemrograman, seperti Java. Mereka kemudian dapat secara manual atau
otomatis dikonversi ke XML. Gambar 19.10 menunjukkan struktur pesan input dan output untuk
operasi getDelivery dalam layanan katalog.
Perhatikan bagaimana saya telah menambahkan detail ke deskripsi dengan membubuhi

keterangan diagram UML dengan batasan. Ini menentukan panjang string yang mewakili
perusahaan dan item katalog, dan menentukan bahwa jumlah item harus lebih besar dari nol
dan pengiriman harus setelah tanggal saat ini. Anotasi juga menunjukkan kode kesalahan mana
yang terkait dengan setiap kemungkinan kesalahan.
Tahap akhir dari proses desain layanan adalah menerjemahkan desain antarmuka layanan
ke dalam WSDL. Seperti yang telah saya bahas di bagian sebelumnya, representasi WSDL
panjang dan detail sehingga mudah untuk membuat kesalahan pada tahap ini jika Anda
melakukannya secara manual. Namun, sebagian besar lingkungan pemrograman yang
mendukung pengembangan berorientasi layanan (misalnya, lingkungan ECLIPSE) menyertakan
alat yang dapat menerjemahkan deskripsi antarmuka logis ke dalam representasi WSDL yang
sesuai.
Operasi Masukan Keluaran Pengecualian
BuatKatalog mcIn mcOut mcFault
Identitas perusahaan URL katalog untuk ID perusahaan tidak valid

PDF-bendera perusahaan itu
Membandingkan compIn compOut kesalahan

Identitas perusahaan URL halaman yang ID perusahaan tidak valid
Atribut entri (hingga 6) menampilkan tabel perbandingan Nomor katalog tidak valid
Nomor katalog (hingga 4) Atribut tidak diketahui
Lihatlah Lihat kedalam mencari lihatKesalahan
Identitas perusahaan URL halaman dengan ID perusahaan tidak valid

Nomor katalog informasi item Nomor katalog tidak valid
Mencari mencari cari Keluar cariFault
Identitas perusahaan URL halaman web dengan ID perusahaan tidak valid

Cari string hasil pencarian String pencarian yang terbentuk dengan buruk
CekPengiriman gdIn gdOut gdFault

Identitas perusahaan Nomor katalog ID perusahaan tidak valid
Nomor katalog Tanggal pengiriman yang diharapkan Nomor katalog tidak valid
Tidak tersedia
Jumlah item yang dibutuhkan Nol item yang diminta
TempatPesanan titik keluar poFault

Identitas perusahaan Nomor katalog ID perusahaan tidak valid
Jumlah item yang dibutuhkan Jumlah item yang Nomor katalog tidak valid
Nomor katalog dibutuhkan Nol item yang diminta
Tanggal pengiriman yang diprediksi
Estimasi harga satuan
Total perkiraan harga
Gambar 19.10 Definisi

UML dari pesan input dan
output
19.2.3 Implementasi dan penerapan layanan

Setelah Anda mengidentifikasi kandidat layanan dan mendesain antarmukanya, tahap
akhir dari proses rekayasa layanan adalah implementasi layanan. Implementasi ini
mungkin melibatkan pemrograman layanan menggunakan bahasa pemrograman standar
seperti Java atau C#. Kedua bahasa ini termasuk perpustakaan dengan dukungan
ekstensif untuk pengembangan layanan.
Sebagai alternatif, layanan dapat dikembangkan dengan mengimplementasikan
antarmuka layanan ke komponen yang ada atau, seperti yang saya bahas di bawah, ke
sistem lama. Ini berarti bahwa aset perangkat lunak yang telah terbukti bermanfaat dapat
dibuat lebih banyak tersedia. Dalam kasus sistem lama, ini mungkin berarti bahwa
fungsionalitas sistem dapat diakses oleh aplikasi baru. Anda juga dapat mengembangkan
layanan baru dengan menentukan komposisi layanan yang ada. Saya membahas pendekatan pengembangan layanan
Setelah layanan diimplementasikan, layanan tersebut harus diuji sebelum disebarkan.
Ini melibatkan pemeriksaan dan partisi input layanan (seperti yang dijelaskan
di Bab 8), membuat pesan input yang mencerminkan kombinasi input ini, lalu
memeriksa bahwa output yang diharapkan. Anda harus selalu mencoba menghasilkan pengecualian
selama pengujian untuk memeriksa apakah layanan dapat mengatasi input yang tidak valid. Alat pengujian
tersedia yang memungkinkan layanan diperiksa dan diuji, dan yang menghasilkan pengujian
dari spesifikasi WSDL. Namun, ini hanya dapat menguji kesesuaian antarmuka layanan dengan WSDL.
Mereka tidak dapat menguji perilaku fungsional layanan tersebut.
Penyebaran layanan, tahap akhir dari proses, melibatkan pembuatan layanan yang tersedia untuk
digunakan di server web. Sebagian besar perangkat lunak server membuat ini sangat sederhana. Anda hanya punya
untuk menginstal file yang berisi layanan yang dapat dieksekusi di direktori tertentu. Kemudian
secara otomatis menjadi tersedia untuk digunakan. Jika layanan dimaksudkan untuk tersedia untuk umum, Anda
kemudian harus memberikan informasi untuk pengguna eksternal layanan. Informasi ini membantu
calon pengguna eksternal untuk memutuskan apakah layanan tersebut mungkin memenuhi kebutuhan mereka dan apakah mereka
dapat mempercayai Anda, sebagai penyedia layanan, untuk memberikan layanan dengan andal dan aman.
Informasi yang mungkin Anda sertakan dalam deskripsi layanan mungkin sebagai berikut:
1. Informasi tentang bisnis Anda, detail kontak, dll. Ini penting untuk kepercayaan
alasan. Pengguna layanan harus yakin bahwa layanan tersebut tidak akan berperilaku jahat
dengan bijaksana. Informasi tentang penyedia layanan memungkinkan mereka untuk memeriksa
kredensial dengan agen informasi bisnis.
2. Deskripsi informal tentang fungsionalitas yang disediakan oleh layanan. Ini membantu
calon pengguna untuk memutuskan apakah layanan yang mereka inginkan. Namun, deskripsi
fungsional dalam bahasa alami, jadi itu bukan semantik yang jelas
deskripsi tentang apa yang dilakukan layanan.
3. Penjelasan rinci tentang jenis antarmuka dan semantik.
4. Informasi berlangganan yang memungkinkan pengguna mendaftar untuk mendapatkan informasi tentang
pembaruan ke layanan.
Seperti yang telah saya diskusikan, masalah umum dengan spesifikasi layanan adalah bahwa
perilaku fungsional layanan biasanya ditentukan secara informal, sebagai bahasa alami.
keterangan. Deskripsi bahasa alami mudah dibaca, tetapi dapat disalahartikan. Untuk mengatasi
masalah ini, ada komunitas penelitian aktif yang peduli dengan menyelidiki bagaimana semantik
layanan dapat ditentukan. Yang paling
pendekatan yang menjanjikan untuk spesifikasi semantik didasarkan pada deskripsi berbasis
ontologi, di mana arti khusus dari istilah dalam deskripsi didefinisikan dalam ontologi.
Ontologi adalah cara menstandardisasi cara terminologi digunakan dan mendefinisikannya
hubungan antara istilah yang berbeda. Mereka menjadi semakin terbiasa untuk membantu
menetapkan semantik untuk deskripsi bahasa alami. Sebuah bahasa yang disebut OWL-S telah
dikembangkan untuk menggambarkan ontologi layanan web (OWL_Services_Coalition, 2003).
19.2.4 Layanan sistem lama

Sistem warisan adalah sistem perangkat lunak lama yang digunakan oleh suatu organisasi. Biasanya,
mereka mengandalkan teknologi usang tetapi masih penting untuk bisnis. Mungkin tidak
hemat biaya untuk menulis ulang atau mengganti sistem ini dan banyak organisasi ingin
"melayani" "melayani" "melayani"

Pemeliharaan Fasilitas Masuk
getJob addEquipment addRequest

suspendJob deleteEquipment deleteRequest
completeJob editEquipment queryRequests
Dukungan Pemeliharaan
Gambar 19.11 Layanan Aplikasi Warisan
yang menyediakan
akses ke sistem lama
untuk menggunakannya bersama dengan sistem yang lebih modern. Salah satu kegunaan
layanan yang paling penting adalah untuk mengimplementasikan 'pembungkus' untuk sistem
lama yang menyediakan akses ke fungsi dan data sistem. Sistem ini kemudian dapat diakses
melalui Web dan terintegrasi dengan aplikasi lain.
Untuk mengilustrasikan hal ini, bayangkan sebuah perusahaan besar memelihara inventaris
peralatannya dan database terkait yang melacak pemeliharaan dan perbaikan peralatan. Ini
melacak permintaan pemeliharaan apa yang telah dibuat untuk bagian peralatan yang berbeda,
pemeliharaan rutin apa yang dijadwalkan, kapan pemeliharaan dilakukan, berapa banyak waktu
yang dihabiskan untuk pemeliharaan, dll. Sistem warisan ini awalnya digunakan untuk
menghasilkan pekerjaan sehari-hari daftar untuk staf pemeliharaan tetapi, seiring waktu, fasilitas
baru telah ditambahkan. Ini memberikan data tentang berapa banyak yang telah dihabiskan untuk
pemeliharaan setiap peralatan dan informasi untuk membantu biaya pekerjaan pemeliharaan
yang harus dilakukan oleh kontraktor eksternal. Sistem berjalan sebagai sistem klien-server
dengan perangkat lunak klien tujuan khusus yang berjalan pada PC.
Perusahaan sekarang ingin memberikan akses real-time ke sistem ini dari terminal portabel
yang digunakan oleh staf pemeliharaan. Mereka akan memperbarui sistem secara langsung
dengan waktu dan sumber daya yang dihabiskan untuk pemeliharaan dan akan menanyakan
sistem untuk menemukan pekerjaan pemeliharaan berikutnya. Selain itu, staf pusat panggilan
memerlukan akses ke sistem untuk mencatat permintaan pemeliharaan dan memeriksa statusnya.
Praktis tidak mungkin untuk meningkatkan sistem untuk mendukung persyaratan ini sehingga
perusahaan memutuskan untuk menyediakan aplikasi baru untuk pemeliharaan dan staf pusat
panggilan. Aplikasi ini mengandalkan sistem warisan, yang akan digunakan sebagai dasar untuk
mengimplementasikan sejumlah layanan. Ini diilustrasikan pada Gambar 19.11, di mana saya
telah menggunakan stereotip UML untuk menunjukkan layanan. Aplikasi baru bertukar pesan
dengan layanan ini untuk mengakses fungsionalitas sistem lama.
Beberapa layanan yang diberikan adalah sebagai berikut:
1. Layanan pemeliharaan Ini termasuk operasi untuk mengambil pekerjaan pemeliharaan sesuai
dengan nomor pekerjaan, prioritas, dan lokasi geografisnya, dan untuk mengunggah rincian
pemeliharaan yang telah dilakukan ke database pemeliharaan.
19.3 Pengembangan perangkat lunak dengan layanan 527
Layanan ini juga menyediakan operasi yang memungkinkan pekerjaan pemeliharaan yang
telah dimulai tetapi tidak lengkap untuk ditangguhkan dan dimulai kembali.
2. Sebuah layanan fasilitas Ini termasuk operasi untuk menambah dan menghapus peralatan
baru dan untuk mengubah informasi yang terkait dengan peralatan dalam database.
3. Layanan pencatatan Ini termasuk operasi untuk menambahkan permintaan layanan baru,
menghapus permintaan pemeliharaan, dan menanyakan status permintaan yang belum diselesaikan.
Perhatikan bahwa sistem warisan yang ada tidak hanya direpresentasikan sebagai es
layanan tunggal. Sebaliknya, layanan yang dikembangkan untuk mengakses sistem lama bersifat
koheren dan mendukung satu area fungsionalitas. Ini mengurangi kerumitannya dan membuatnya
lebih mudah dipahami dan digunakan kembali di aplikasi lain.
19.3 Pengembangan perangkat lunak dengan layanan
Pengembangan perangkat lunak menggunakan layanan didasarkan pada gagasan bahwa Anda
menyusun dan mengonfigurasi layanan untuk membuat layanan komposit baru. Ini dapat
diintegrasikan dengan antarmuka pengguna yang diimplementasikan di browser untuk membuat
aplikasi web, atau dapat digunakan sebagai komponen dalam beberapa komposisi layanan
lainnya. Layanan yang terlibat dalam komposisi dapat dikembangkan secara khusus untuk
aplikasi, mungkin layanan bisnis yang dikembangkan dalam perusahaan, atau mungkin layanan dari penyedia eksternal.
Banyak perusahaan sekarang mengubah aplikasi perusahaan mereka menjadi sistem
berorientasi layanan, di mana blok bangunan aplikasi dasar adalah layanan daripada komponen.
Ini membuka kemungkinan penggunaan kembali yang lebih luas di dalam perusahaan. Tahap
selanjutnya adalah pengembangan aplikasi antar organisasi antara pemasok terpercaya, yang
akan menggunakan layanan satu sama lain. Realisasi akhir dari visi jangka panjang SOA akan
bergantung pada pengembangan 'pasar layanan', di mana layanan dibeli dari pemasok eksternal.
Komposisi layanan dapat digunakan untuk mengintegrasikan proses bisnis terpisah untuk
menyediakan proses terintegrasi yang menawarkan fungsionalitas yang lebih luas. Katakanlah
sebuah maskapai penerbangan ingin menyediakan paket liburan lengkap untuk pelancong.
Selain memesan penerbangan, wisatawan juga dapat memesan hotel di lokasi pilihan mereka,
mengatur penyewaan mobil atau memesan taksi dari bandara, menelusuri panduan perjalanan,
dan membuat reservasi untuk mengunjungi atraksi lokal. Untuk membuat aplikasi ini, maskapai
membuat layanan pemesanan sendiri dengan layanan yang ditawarkan oleh agen pemesanan
hotel, perusahaan penyewaan mobil dan taksi, dan layanan reservasi yang ditawarkan oleh
pemilik atraksi lokal. Hasil akhirnya adalah layanan tunggal yang mengintegrasikan layanan dari penyedia yang berbeda.
Anda dapat menganggap proses ini sebagai urutan langkah-langkah terpisah seperti yang
ditunjukkan pada Gambar 19.12. Informasi diteruskan dari satu langkah ke langkah berikutnya—
misalnya, perusahaan persewaan mobil diberitahu tentang waktu penerbangan dijadwalkan tiba.
Urutan langkah-langkahnya disebut alur kerja—seperangkat aktivitas yang diurutkan dalam
waktu, dengan setiap aktivitas melakukan beberapa bagian dari pekerjaan. Alur kerja adalah model bisnis
Buku Buku Mengatur Jelajahi Buku

Penerbangan
Hotel Mobil atau Taksi Atraksi Atraksi
Gambar 19.12 Alur kerja Kedatangan keberangkatan Tanggal/Preferensi

Tanggal/Waktu Lokasi Hotel
paket liburan
proses (yaitu, menetapkan langkah-langkah yang terlibat dalam mencapai tujuan tertentu yang
penting untuk bisnis). Dalam hal ini, proses bisnisnya adalah layanan pemesanan liburan yang
ditawarkan oleh maskapai.
Alur kerja adalah ide sederhana dan skenario pemesanan liburan di atas tampaknya mudah.
Dalam praktiknya, komposisi layanan jauh lebih kompleks daripada yang disiratkan oleh model
sederhana ini. Misalnya, Anda harus mempertimbangkan kemungkinan kegagalan layanan dan
menggabungkan mekanisme untuk menangani kegagalan ini. Anda juga harus mempertimbangkan
permintaan luar biasa yang dibuat oleh pengguna aplikasi. Misalnya, katakanlah seorang pelancong
cacat dan memerlukan kursi roda untuk disewa dan diantar ke bandara. Ini akan membutuhkan
layanan tambahan untuk diimplementasikan dan disusun, dan langkah-langkah tambahan untuk
ditambahkan ke alur kerja.
Anda harus dapat mengatasi situasi di mana alur kerja harus diubah karena eksekusi normal
salah satu layanan biasanya menghasilkan ketidaksesuaian dengan beberapa eksekusi layanan
lainnya. Misalnya, penerbangan dipesan untuk berangkat pada 1 Juni dan kembali pada 7 Juni. Alur
kerja kemudian berlanjut ke tahap pemesanan hotel. Namun, resor ini mengadakan konvensi besar
hingga 2 Juni, jadi tidak ada kamar hotel yang tersedia. Layanan pemesanan hotel melaporkan
kurangnya ketersediaan ini. Ini bukan kegagalan; kurangnya ketersediaan adalah situasi umum.
Oleh karena itu, Anda kemudian harus 'membatalkan' pemesanan penerbangan dan memberikan
informasi tentang kurangnya ketersediaan kembali kepada pengguna. Dia kemudian harus
memutuskan apakah akan mengubah tanggal atau resor mereka.
Dalam terminologi alur kerja, ini disebut 'tindakan kompensasi'. Tindakan kompensasi digunakan
untuk membatalkan tindakan yang telah diselesaikan tetapi harus diubah sebagai hasil dari aktivitas
alur kerja selanjutnya.
Proses merancang layanan baru dengan menggunakan kembali layanan yang ada pada
dasarnya adalah proses desain perangkat lunak dengan penggunaan kembali (Gambar 19.13).
Desain dengan penggunaan kembali pasti melibatkan kompromi persyaratan. Persyaratan 'ideal'
untuk sistem harus dimodifikasi untuk mencerminkan layanan yang benar-benar tersedia, yang
biayanya sesuai anggaran dan kualitas layanannya dapat diterima.
Pada Gambar 19.13, saya telah menunjukkan enam tahap utama dalam proses konstruksi
layanan berdasarkan komposisi:
1. Merumuskan alur kerja garis besar Pada tahap awal desain layanan ini, Anda menggunakan
persyaratan untuk layanan gabungan sebagai dasar untuk membuat desain layanan yang
'ideal'. Anda harus membuat desain yang cukup abstrak pada tahap ini dengan tujuan
menambahkan detail setelah Anda mengetahui lebih banyak tentang layanan yang tersedia.
2. Temukan layanan Selama tahap proses ini, Anda mencari pendaftar atau katalog layanan untuk
menemukan layanan apa yang ada, siapa yang menyediakan layanan ini, dan perincian
penyediaan layanan.
Merumuskan Membuat
Menemukan Pilih Menyaring Uji
Garis besar alur kerja
Jasa Jasa alur kerja Melayani
alur kerja Program
alur kerja Melayani alur kerja Dapat dieksekusi Dapat diterapkan

Daftar Layanan
Rancangan spesifikasi Rancangan alur kerja Melayani
3. Pilih layanan yang memungkinkan Dari kumpulan kandidat layanan yang mungkin telah Anda
Gambar 19.13 Konstruksi
temukan, Anda kemudian memilih layanan yang memungkinkan yang dapat
layanan berdasarkan
komposisi mengimplementasikan aktivitas alur kerja. Kriteria pemilihan Anda jelas akan mencakup
fungsionalitas layanan yang ditawarkan. Mereka juga dapat mencakup biaya layanan dan
kualitas layanan (daya tanggap, ketersediaan, dll.) yang ditawarkan. Anda dapat memutuskan
untuk memilih sejumlah layanan yang setara secara fungsional, yang dapat terikat pada
aktivitas alur kerja tergantung pada rincian biaya dan kualitas layanan.
4. Perbaiki alur kerja Berdasarkan informasi tentang layanan yang telah Anda pilih, Anda
kemudian menyaring alur kerja. Ini melibatkan penambahan detail ke deskripsi abstrak dan
mungkin menambahkan atau menghapus aktivitas alur kerja. Anda kemudian dapat
mengulangi tahap penemuan dan pemilihan layanan. Setelah serangkaian layanan yang
stabil telah dipilih dan desain alur kerja akhir ditetapkan, Anda melanjutkan ke tahap
berikutnya dalam proses.
5. Membuat program alur kerja Selama tahap ini, desain alur kerja abstrak diubah menjadi
program yang dapat dijalankan dan antarmuka layanan ditentukan. Anda dapat menggunakan
bahasa pemrograman konvensional, seperti Java atau C#, untuk implementasi layanan atau
bahasa alur kerja, seperti WS-BPEL. Seperti yang saya bahas di bagian sebelumnya,
spesifikasi antarmuka layanan harus ditulis dalam WSDL. Tahap ini mungkin juga melibatkan
pembuatan antarmuka pengguna berbasis web untuk memungkinkan layanan baru diakses
dari browser web.
6. Uji layanan atau aplikasi yang telah selesai Proses pengujian layanan komposit yang telah
selesai lebih kompleks daripada pengujian komponen dalam situasi di mana layanan
eksternal digunakan. Saya membahas masalah pengujian di Bagian 19.3.2.
Di sisa bab ini, saya fokus pada desain dan pengujian alur kerja. Dalam praktiknya, penemuan
layanan tampaknya tidak menjadi masalah besar. Masih menjadi kasus bahwa sebagian besar
penggunaan kembali layanan berada di dalam organisasi, di mana layanan dapat ditemukan
menggunakan pendaftar internal dan komunikasi informal antara insinyur perangkat lunak.
Mesin pencari standar dapat digunakan untuk menemukan layanan yang tersedia untuk umum.
19.3.1 Desain dan implementasi alur kerja

Desain alur kerja melibatkan analisis proses bisnis yang ada atau yang direncanakan untuk
memahami berbagai aktivitas yang berlangsung dan bagaimana pertukaran informasi ini.
Mencoba kembali
Membatalkan
Tidak ada kamar Hotel.

Tidak tersedia
Hotel. Hotel.
Dapatkan Persyaratan Cek ketersediaan Hotel.
Kamar Oke Kamar Cadangan
Hotel.
Konfirmasi Reservasi
Pelanggan
Anda kemudian menentukan proses bisnis baru dalam notasi desain alur kerja. Ini menetapkan
Gambar 19.14
tahapan yang terlibat dalam memberlakukan proses dan informasi yang dilewatkan antara
Sebuah fragmen dari
alur kerja pemesanan hotel tahapan proses yang berbeda. Namun, proses yang ada mungkin bersifat informal dan
bergantung pada keterampilan dan kemampuan orang-orang yang terlibat—mungkin tidak
ada cara kerja atau definisi proses yang 'normal'. Dalam kasus seperti itu, Anda harus
menggunakan pengetahuan Anda tentang proses saat ini untuk merancang alur kerja yang mencapai tujuan yang sama.
Alur kerja mewakili model proses bisnis dan biasanya direpresentasikan menggunakan
notasi grafis seperti diagram aktivitas UML atau BPMN, Notasi Pemodelan Proses Bisnis
(White, 2004a; White and Miers, 2008). Ini menawarkan fitur serupa (White, 2004b). Saya pikir
ada kemungkinan bahwa diagram aktivitas BPMN dan UML akan diintegrasikan di masa depan
dan standar untuk pemodelan alur kerja yang ditentukan akan didasarkan pada bahasa
terintegrasi ini. Saya menggunakan BPMN untuk contoh dalam bab ini.
BPMN adalah bahasa grafis yang cukup mudah dipahami. Pemetaan telah ditetapkan untuk
menerjemahkan bahasa ke tingkat yang lebih rendah, deskripsi berbasis XML di WS-BPEL.
Oleh karena itu BPMN sesuai dengan tumpukan standar layanan web yang saya tunjukkan
pada Gambar 19.2.
Gambar 19.14 adalah contoh model BPMN sederhana dari bagian skenario paket liburan
di atas. Model menunjukkan alur kerja yang disederhanakan untuk pemesanan hotel dan
mengasumsikan keberadaan layanan Hotel dengan operasi terkait yang disebut
GetRequirements, CheckAvailability, ReserveRooms, NoAvailability, Confirm Reservation,
dan CancelReservation. Prosesnya melibatkan mendapatkan persyaratan dari pelanggan,
memeriksa ketersediaan kamar, dan kemudian, jika kamar tersedia, membuat pemesanan
untuk tanggal yang diperlukan.
Model ini memperkenalkan beberapa konsep inti BPMN yang digunakan untuk membuat
model alur kerja:
1. Kegiatan diwakili oleh persegi panjang dengan sudut membulat. Suatu kegiatan dapat
dijalankan oleh manusia atau oleh layanan otomatis.
2. Peristiwa diwakili oleh lingkaran. Event adalah sesuatu yang terjadi selama proses
bisnis. Lingkaran sederhana digunakan untuk mewakili acara awal dan lingkaran
gelap untuk mewakili acara akhir. Lingkaran ganda (tidak ditampilkan) digunakan
untuk mewakili peristiwa perantara. Peristiwa dapat berupa peristiwa jam, sehingga
memungkinkan alur kerja dieksekusi secara berkala atau habis waktu.
3. Sebuah berlian digunakan untuk mewakili sebuah gerbang. Gateway adalah tahap
dalam proses di mana beberapa pilihan dibuat. Misalnya, pada Gambar 19.14, ada
pilihan yang dibuat berdasarkan apakah kamar tersedia atau tidak.
4. Sebuah panah padat digunakan untuk menunjukkan urutan kegiatan; perwakilan

panah putus-putus mengirimkan aliran pesan di antara aktivitas. Pada Gambar
19.14, pesan-pesan ini diteruskan antara layanan pemesanan hotel dan pelanggan.
Fitur utama ini cukup untuk menggambarkan esensi dari sebagian besar alur kerja.
Namun, BPMN menyertakan banyak fitur tambahan yang tidak dapat saya jelaskan di
sini. Ini menambahkan informasi ke deskripsi proses bisnis yang memungkinkannya
diterjemahkan secara otomatis ke dalam layanan yang dapat dieksekusi. Oleh karena
itu, layanan web, berdasarkan komposisi layanan yang dijelaskan dalam BPMN, dapat
dihasilkan langsung dari model proses bisnis.
Gambar 19.14 menunjukkan proses yang berlaku di satu organisasi, perusahaan
yang menyediakan layanan pemesanan. Namun, manfaat utama dari pendekatan
berorientasi layanan adalah mendukung komputasi antar organisasi. Ini berarti bahwa
komputasi melibatkan layanan di perusahaan yang berbeda. Ini diwakili dalam BPMN
dengan mengembangkan alur kerja terpisah untuk setiap organisasi yang terlibat
dengan interaksi di antara mereka.
Untuk mengilustrasikan hal ini, saya menggunakan contoh berbeda, yang diambil
dari komputasi kinerja tinggi. Pendekatan berorientasi layanan telah diusulkan untuk
memungkinkan berbagi sumber daya seperti komputer berkinerja tinggi. Dalam contoh
ini, asumsikan bahwa komputer pemrosesan vektor (mesin yang dapat melakukan
komputasi paralel pada array nilai) ditawarkan sebagai layanan (VectorProcService)
oleh laboratorium penelitian. Ini diakses melalui layanan lain yang disebut
SetupComputation. Layanan ini dan interaksinya ditunjukkan pada Gambar 19.15.
Dalam contoh ini, alur kerja untuk layanan SetupComputation meminta akses ke
prosesor vektor dan, jika prosesor tersedia, menetapkan komputasi yang diperlukan
dan mengunduh data ke layanan pemrosesan. Setelah perhitungan selesai, hasilnya
disimpan di komputer lokal. Alur kerja untuk VectorProcService memeriksa apakah
prosesor tersedia, mengalokasikan sumber daya untuk komputasi, menginisialisasi
sistem, menjalankan komputasi, dan mengembalikan hasilnya ke layanan klien.
Dalam istilah BPMN, alur kerja untuk setiap organisasi diwakili dalam kumpulan
terpisah. Ini ditunjukkan secara grafis dengan melampirkan alur kerja untuk setiap
peserta dalam proses dalam sebuah persegi panjang, dengan nama yang ditulis secara
vertikal di tepi kiri. Alur kerja yang ditentukan di setiap kumpulan dikoordinasikan
dengan bertukar pesan; urutan aliran antara kegiatan di kolam yang berbeda tidak
diperbolehkan. Dalam situasi di mana berbagai bagian organisasi terlibat dalam alur kerja, ini dapat ditunjukk
Mengulang kembali
Tanpa Prosesor
Gagal
Meminta Pekerjaan Pengaturan

Unduh Awal
Prosesor Parameter Data Komputasi
Oke Oke
Toko Laporan
Hasil Penyelesaian
Memeriksa Alokasikan
Inisialisasi Menghitung
Ketersediaan Sumber daya
Kembali
Hasil
memisahkan kolam menjadi 'jalur' bernama. Setiap jalur menunjukkan kegiatan di bagian
Gambar 19.15
organisasi itu.
Alur kerja yang saling berinteraksi
Setelah model proses bisnis telah dirancang, ini harus disempurnakan tergantung
pada layanan yang telah ditemukan. Seperti yang saya sarankan dalam pembahasan
Gambar 19.13, model dapat melalui sejumlah iterasi sampai desain yang memungkinkan
penggunaan kembali maksimum dari layanan yang tersedia telah dibuat.
Setelah desain akhir tersedia, maka harus dikonversi ke pro yang dapat dieksekusi
gram. Ini mungkin melibatkan dua kegiatan:
1. Menerapkan layanan yang tidak tersedia untuk digunakan kembali. Karena layanan
adalah bahasa implementasi independen, layanan ini dapat ditulis dalam bahasa apa
pun. Lingkungan pengembangan Java dan C# menyediakan dukungan untuk
komposisi layanan web.
2. Membuat versi model alur kerja yang dapat dieksekusi. Ini biasanya melibatkan
menerjemahkan model ke WS-BPEL, baik secara otomatis atau dengan tangan.
Meskipun ada beberapa alat yang tersedia untuk mengotomatisasi proses BPMN-
WS-BPEL, ada beberapa keadaan di mana sulit untuk menghasilkan kode WS-BPEL
yang dapat dibaca dari model alur kerja.
Untuk memberikan dukungan langsung untuk implementasi komposisi layanan web,

beberapa standar layanan web telah dikembangkan. Seperti yang saya jelaskan di bab
pendahuluan, bahasa standar berbasis XML adalah WS-BPEL (Business Process
Execution Language) yang merupakan 'bahasa pemrograman' untuk mengontrol interaksi.
antar layanan. Hal ini didukung oleh standar tambahan seperti Koordinasi WS (Cabrera et al.,
2005), yang digunakan untuk menentukan bagaimana layanan dikoordinasikan, dan WS-CDL
(Bahasa Deskripsi Koreografi) (Kavantzas et al., 2004), yang merupakan sarana untuk
mendefinisikan pertukaran pesan antara peserta (Andrews et al., 2003).
19.3.2 Pengujian layanan

Pengujian penting dalam semua proses pengembangan sistem karena menunjukkan bahwa sistem
memenuhi persyaratan fungsional dan non-fungsional dan untuk mendeteksi cacat yang telah
diperkenalkan selama proses pengembangan. Banyak teknik pengujian, seperti inspeksi program
dan pengujian cakupan, bergantung pada analisis kode sumber perangkat lunak. Namun, ketika
layanan ditawarkan oleh penyedia eksternal, kode sumber implementasi layanan tidak tersedia.
Oleh karena itu, pengujian sistem berbasis layanan tidak dapat menggunakan teknik berbasis
kode sumber yang telah terbukti.
Selain masalah dalam memahami implementasi layanan, penguji juga mungkin menghadapi
kesulitan lebih lanjut saat menguji layanan dan komposisi layanan:
1. Layanan eksternal berada di bawah kendali penyedia layanan daripada pengguna layanan.
Penyedia layanan dapat menarik layanan ini kapan saja atau dapat membuat perubahan pada
layanan tersebut, yang membatalkan pengujian aplikasi sebelumnya. Masalah ini ditangani
dalam komponen perangkat lunak dengan mempertahankan versi komponen yang berbeda.
Saat ini, bagaimanapun, tidak ada standar yang diusulkan untuk menangani versi layanan.
2. Visi jangka panjang SOA adalah agar layanan terikat secara dinamis ke aplikasi berorientasi
layanan. Ini berarti bahwa aplikasi mungkin tidak selalu menggunakan layanan yang sama
setiap kali dijalankan. Oleh karena itu, pengujian mungkin berhasil ketika aplikasi terikat ke
layanan tertentu, tetapi tidak dapat dijamin bahwa layanan tersebut akan digunakan selama
eksekusi sistem yang sebenarnya.
3. Perilaku non-fungsional suatu layanan tidak hanya bergantung pada bagaimana layanan itu
digunakan oleh aplikasi yang sedang diuji. Sebuah layanan dapat bekerja dengan baik
selama pengujian karena tidak beroperasi di bawah beban berat. Dalam praktiknya, perilaku
layanan yang diamati mungkin berbeda karena tuntutan yang dibuat oleh pengguna layanan
lain.
4. Model pembayaran untuk layanan dapat membuat pengujian layanan menjadi sangat mahal.
Ada kemungkinan model pembayaran yang berbeda—beberapa layanan mungkin tersedia
secara bebas, beberapa dibayar dengan berlangganan, dan yang lainnya dibayar berdasarkan penggunaan.
Jika layanan gratis, maka penyedia layanan tidak akan menginginkannya dimuat oleh aplikasi
yang sedang diuji; jika langganan diperlukan, maka pengguna layanan mungkin enggan
untuk masuk ke dalam perjanjian berlangganan sebelum menguji layanan.
Demikian pula, jika penggunaan didasarkan pada pembayaran untuk setiap penggunaan, pengguna layanan
mungkin menemukan biaya pengujian menjadi penghalang.

5. Saya telah membahas gagasan tindakan kompensasi yang dilakukan ketika pengecualian
terjadi dan komitmen sebelumnya yang telah dibuat (seperti reservasi penerbangan)
harus dicabut. Ada masalah dalam menguji tindakan seperti itu karena mungkin
bergantung pada kegagalan layanan lain. Memastikan bahwa layanan ini benar-benar
gagal selama proses pengujian mungkin sangat sulit.
Masalah-masalah ini sangat akut ketika layanan eksternal digunakan. Mereka kurang serius
ketika layanan digunakan dalam perusahaan yang sama atau di mana perusahaan yang
bekerja sama mempercayai layanan yang ditawarkan oleh mitra mereka. Dalam kasus
seperti itu, kode sumber mungkin tersedia untuk memandu proses pengujian dan
pembayaran untuk layanan tidak mungkin menjadi masalah. Menyelesaikan masalah
pengujian ini dan menghasilkan pedoman, alat, dan teknik untuk menguji aplikasi berorientasi layanan tetap menjadi m
POIN KUNCI
Arsitektur berorientasi layanan adalah pendekatan untuk rekayasa perangkat lunak di mana layanan
standar yang dapat digunakan kembali adalah blok bangunan dasar untuk sistem aplikasi.
Antarmuka layanan dapat didefinisikan dalam bahasa berbasis XML yang disebut WSDL. Spesifikasi WSDL
mencakup definisi jenis dan operasi antarmuka, protokol pengikatan yang digunakan oleh layanan dan lokasi
layanan.
Layanan dapat diklasifikasikan sebagai layanan utilitas yang menyediakan fungsionalitas tujuan umum,
layanan bisnis yang mengimplementasikan bagian dari proses bisnis, atau layanan koordinasi yang
mengoordinasikan pelaksanaan layanan lain.
Proses rekayasa layanan melibatkan pengidentifikasian layanan kandidat untuk implementasi, mendefinisikan
antarmuka dan implementasi layanan, serta menguji dan menyebarkan layanan .
Antarmuka layanan dapat ditentukan untuk sistem perangkat lunak lama yang terus berguna bagi organisasi.
Fungsionalitas sistem warisan kemudian dapat digunakan kembali di aplikasi lain.
Pengembangan perangkat lunak menggunakan layanan didasarkan pada gagasan bahwa program dibuat
dengan menyusun dan mengonfigurasi layanan untuk membuat layanan komposit baru.
Model proses bisnis mendefinisikan aktivitas dan pertukaran informasi yang terjadi di
sebuah proses bisnis. Aktivitas dalam proses bisnis dapat diimplementasikan oleh layanan sehingga model
proses bisnis mewakili komposisi layanan.
BACAAN LEBIH LANJUT
Ada banyak sekali materi tutorial di Web yang mencakup semua aspek layanan web.
Namun, saya menemukan dua buku berikut oleh Thomas Erl sebagai ikhtisar terbaik dan deskripsi layanan dan
standar layanan. Tidak seperti kebanyakan buku, Erl menyertakan beberapa diskusi tentang perangkat lunak
Bab 19 Latihan 535
masalah rekayasa dalam komputasi berorientasi layanan. Dia juga telah menulis lebih banyak buku khusus tentang desain layanan
dan pola desain SOA, meskipun ini umumnya ditujukan untuk pembaca dengan pengalaman mengimplementasikan SOA.
Arsitektur Berorientasi Layanan: Panduan Lapangan untuk Mengintegrasikan XML dan Layanan Web. Fokus utama buku ini
adalah teknologi berbasis XML yang mendasari (SOAP, WSDL, BPEL, dll.) yang merupakan kerangka kerja untuk SOA. (T. Erl,
Prentice Hall, 2004.)
Arsitektur Berorientasi Layanan: Konsep, Teknologi, dan Desain. Ini adalah buku yang lebih umum tentang rekayasa
sistem berorientasi layanan. Ada sedikit tumpang tindih dengan teks di atas tetapi Erl sebagian besar berkonsentrasi pada
membahas bagaimana pendekatan berorientasi layanan dapat digunakan di semua tahap proses perangkat lunak. (T. Erl, Prentice
Hall, 2005.)
'Realisasi SOA: Prinsip-prinsip desain layanan'. Artikel web singkat ini adalah gambaran yang sangat baik tentang masalah
yang harus dipertimbangkan dalam merancang layanan. (DJN Artus, IBM, 2006.) http://www.ibm.com/developerworks/
webservices/library/ws-soa-design/.
LATIHAN
19.1. Apa perbedaan terpenting antara layanan dan komponen perangkat lunak?
19.2. Jelaskan mengapa SOA harus didasarkan pada standar.
19.3. Dengan menggunakan notasi yang sama, perluas Gambar 19.5 untuk memasukkan definisi MaxMinType dan
InDataFault. Suhu harus direpresentasikan sebagai bilangan bulat dengan bidang tambahan yang menunjukkan
apakah suhu dalam derajat Fahrenheit atau derajat Celcius. InDataFault harus berupa tipe sederhana yang terdiri dari
kode kesalahan.
19.4. Tentukan spesifikasi antarmuka untuk layanan Konverter Mata Uang dan Periksa peringkat kredit
ditunjukkan pada Gambar 19.7.
19.5. Rancang pesan input dan output yang mungkin untuk layanan yang ditunjukkan pada Gambar 19.11. Anda dapat
menentukan ini dalam UML atau XML.
19.6. Berikan alasan untuk jawaban Anda, sarankan dua jenis aplikasi penting di mana Anda tidak akan merekomendasikan
penggunaan arsitektur berorientasi layanan.
19.7. Di Bagian 19.2.1, saya memperkenalkan contoh perusahaan yang telah mengembangkan layanan katalog yang digunakan
oleh sistem pengadaan berbasis web pelanggan. Menggunakan BPMN, rancang alur kerja yang menggunakan layanan
katalog ini untuk mencari dan memesan peralatan komputer.
19.8. Jelaskan apa yang dimaksud dengan 'tindakan kompensasi' dan, dengan menggunakan contoh, tunjukkan mengapa ini
tindakan mungkin harus disertakan dalam alur kerja.
19.9. Untuk contoh layanan reservasi paket liburan, rancang alur kerja yang akan
memesan transportasi darat untuk sekelompok penumpang yang tiba di bandara. Mereka harus diberikan pilihan untuk
memesan taksi atau menyewa mobil. Anda mungkin berasumsi bahwa perusahaan taksi dan persewaan mobil
menawarkan layanan web untuk membuat reservasi.
19.10. Dengan menggunakan contoh, jelaskan secara rinci mengapa pengujian menyeluruh atas layanan yang
mencakup tindakan kompensasi sulit dilakukan.
REFERENSI
Andrews, T., Curbera, F., Goland, Y., Klein, J. dan Al., E. (2003). 'Bahasa Eksekusi Proses Bisnis untuk Layanan Web'.
http://www-128.ibm.com/developerworks/library/ws-bpel/.
Cabrera, LF, Copeland, G. dan Al., E. 2005. 'Koordinasi Layanan Web (Koordinasi WS)'. ftp://
www6.software.ibm.com/software/developer/library/WS-Coordination.pdf.
Carr, N. (2009). The Big Switch: Rewiring Dunia dari Edison ke Google, edisi cetak ulang. New York: WW Norton &
Co.
Erl, T. (2004). Arsitektur Berorientasi Layanan: Panduan Lapangan untuk Mengintegrasikan XML dan Layanan Web.
Upper Saddle River, NJ: Prentice Hall.
Erl, T. (2005). Arsitektur Berorientasi Layanan: Konsep, Teknologi, dan Desain. Upper Saddle River, NJ: Prentice
Hall.
Kavantzas, N., Burdett, D. dan Ritzinger, G. 2004. 'Layanan Web Koreografi Deskripsi Bahasa Versi 1.0'. http://www.w3.org/
TR/2004/WD-ws-cdl-10-20040427/.
Lovelock, C., Vandermerwe, S. dan Lewis, B. (1996). Pemasaran Jasa. Englewood Cliffs, NJ: Prentice Hall.
Pendatang baru, E. dan Lomow, G. (2005). Memahami SOA dengan Layanan Web. Boston: Addison-Wesley.
Owl_Services_Coalition. 2003. 'OWL-S: Markup Semantik untuk Layanan Web'. http://

www.daml.org/services/owl-s/1.0/owl-s.pdf.
Pautasso, C., Zimmermann, O. dan Leymann, F. (2008). 'Layanan Web RESTful vs Layanan Web "Besar": Membuat
Keputusan Arsitektur yang Tepat'. Prok. WWW 2008, Beijing, Tiongkok: 805–14.
Richardson, L. dan Ruby, S. (2007). Layanan Web RESTful. Sebastopol, California: O'Reilly Media Inc.
Turner, M., Budgen, D. dan Brereton, P. (2003). 'Mengubah Perangkat Lunak menjadi Layanan'. Komputer IEEE, 36
(10), 38–45.
Putih, SA (2004a). 'Pengantar BPMN'. http://www.bpmn.org/

Documents/Introduction%20to%20BPMN.
Putih, SA (2004b). 'Proses Pemodelan Notasi dan Pola Alur Kerja'. Dalam Workflow Handbook 2004. Fischer, L. (ed.).
Lighthouse Point, Florida: Future Strategies Inc. 265–294.
Putih, SA dan Miers, D. (2008). Panduan Pemodelan dan Referensi BPMN: Memahami dan Menggunakan BPMN.
Lighthouse Point, Florida: Future Strategies Inc.
20
Perangkat lunak tertanam
Tujuan
Tujuan dari bab ini adalah untuk memperkenalkan beberapa fitur karakteristik
dari sistem waktu nyata tertanam dan rekayasa perangkat lunak waktu nyata.
Setelah Anda membaca bab ini, Anda akan:
memahami konsep perangkat lunak tertanam, yang digunakan untuk

mengontrol sistem yang harus bereaksi terhadap peristiwa eksternal di
lingkungan mereka;
telah diperkenalkan ke proses desain untuk sistem waktu nyata, di mana sistem
perangkat lunak diatur sebagai satu set proses yang bekerja sama ;
memahami tiga pola arsitektur yang umum digunakan di

desain sistem waktu nyata tertanam;
memahami organisasi sistem operasi waktu-nyata dan peran yang dimainkannya

dalam sistem waktu-nyata yang tertanam.
Isi
20.1 Desain sistem tertanam 20.2
Pola arsitektur 20.3 Analisis waktu
20.4 Sistem operasi waktu nyata
538 Bab 20 Perangkat lunak tertanam
Komputer digunakan untuk mengontrol berbagai sistem dari rumah tangga sederhana
mesin, melalui pengontrol permainan, ke seluruh pabrik. Komputer ini berinteraksi langsung dengan
perangkat keras. Perangkat lunak mereka harus bereaksi terhadap peristiwa yang dihasilkan oleh
perangkat keras dan, seringkali, mengeluarkan sinyal kontrol sebagai tanggapan terhadap peristiwa ini.
Sinyal-sinyal ini menghasilkan suatu tindakan, seperti inisiasi panggilan telepon, gerakan
karakter di layar, pembukaan katup, atau tampilan sistem
status. Perangkat lunak dalam sistem ini tertanam dalam perangkat keras sistem, sering kali dalam
memori hanya baca, dan biasanya merespon, secara real time, terhadap kejadian dari lingkungan
sistem. Secara real time, maksud saya sistem perangkat lunak memiliki tenggat waktu untuk merespons
terhadap peristiwa eksternal. Jika tenggat waktu ini terlewatkan, maka keseluruhan perangkat keras-perangkat lunak
sistem tidak akan beroperasi dengan benar.

Perangkat lunak tertanam sangat penting secara ekonomi karena hampir setiap perangkat listrik
sekarang menyertakan perangkat lunak. Oleh karena itu ada lebih banyak sistem perangkat lunak
tertanam daripada jenis sistem perangkat lunak lainnya. Jika Anda melihat-lihat rumah Anda
Anda mungkin memiliki tiga atau empat komputer pribadi. Tetapi Anda mungkin memiliki 20 atau 30
sistem tertanam, seperti sistem di telepon, kompor, microwave, dll.
Responsif dalam waktu nyata adalah perbedaan penting antara sistem tertanam
dan sistem perangkat lunak lainnya, seperti sistem informasi, sistem berbasis web, atau sistem
perangkat lunak pribadi, yang tujuan utamanya adalah pemrosesan data. Untuk waktu non-nyata
sistem, kebenaran suatu sistem dapat ditentukan dengan menentukan bagaimana input sistem
memetakan ke output yang sesuai yang harus dihasilkan oleh sistem. Sebagai tanggapan terhadap
input, output yang sesuai harus dihasilkan oleh sistem dan, seringkali, beberapa
data harus disimpan. Misalnya, jika Anda memilih perintah buat pada pasien
sistem informasi, maka respon sistem yang benar adalah membuat catatan pasien baru
dalam database, dan untuk mengkonfirmasi bahwa ini telah dilakukan. Dalam batas yang wajar, memang
tidak peduli berapa lama ini berlangsung.
Namun, dalam sistem waktu nyata, kebenarannya bergantung pada respons terhadap
masukan dan waktu yang dibutuhkan untuk menghasilkan respons tersebut. Jika sistem membutuhkan waktu terlalu lama untuk
merespons, maka respons yang diperlukan mungkin tidak efektif. Misalnya, jika disematkan
perangkat lunak yang mengendalikan sistem pengereman mobil terlalu lambat, maka kecelakaan dapat terjadi
karena tidak mungkin menghentikan mobil tepat waktu.
Oleh karena itu, waktu melekat dalam definisi sistem perangkat lunak waktu nyata:
Sistem perangkat lunak waktu-nyata adalah sistem yang operasinya benar bergantung pada:
baik hasil yang dihasilkan oleh sistem dan waktu di mana hasil ini
diproduksi. Sebuah 'soft real-time system' adalah sistem yang operasinya menurun jika
hasil tidak dihasilkan sesuai dengan persyaratan waktu yang ditentukan. Jika
hasil tidak dihasilkan sesuai dengan spesifikasi waktu dalam 'sistem waktu nyata yang sulit',
ini dianggap sebagai kegagalan sistem.
Respons tepat waktu merupakan faktor penting dalam semua sistem tertanam tetapi tidak semua
embedded system membutuhkan respon yang sangat cepat. Misalnya, perangkat lunak pompa insulin
yang saya gunakan sebagai contoh dalam beberapa bab buku ini adalah perangkat lunak tertanam
sistem. Namun, meskipun perlu memeriksa kadar glukosa secara berkala, itu
tidak perlu merespon dengan sangat cepat terhadap peristiwa eksternal. Cuaca di hutan belantara
Bab 20 Perangkat lunak tertanam 539
perangkat lunak stasiun juga merupakan sistem tertanam tetapi, sekali lagi, tidak memerlukan
respons cepat terhadap peristiwa eksternal.
Selain kebutuhan akan respons waktu nyata, ada perbedaan penting lainnya antara sistem
tertanam dan jenis sistem perangkat lunak lainnya:
1. Sistem tertanam umumnya berjalan terus menerus dan tidak berhenti. Mereka mulai ketika
perangkat keras diaktifkan dan harus dijalankan sampai perangkat keras
dimatikan. Ini berarti bahwa teknik untuk rekayasa perangkat lunak yang andal, seperti
yang dibahas dalam Bab 13, mungkin harus digunakan untuk memastikan operasi yang berkelanjutan.
Sistem waktu nyata dapat mencakup mekanisme pembaruan yang mendukung konfigurasi
ulang dinamis sehingga sistem dapat diperbarui saat dalam layanan.
2. Interaksi dengan lingkungan sistem tidak terkendali dan tidak dapat diprediksi. Dalam sistem
interaktif, kecepatan interaksi dikendalikan oleh sistem dan, dengan membatasi pilihan
pengguna, peristiwa yang akan diproses diketahui sebelumnya. Sebaliknya, sistem tertanam
waktu nyata harus dapat merespons kejadian tak terduga kapan saja. Ini mengarah pada
desain untuk sistem waktu nyata berdasarkan konkurensi, dengan beberapa proses yang
dijalankan secara paralel.
3. Mungkin ada keterbatasan fisik yang mempengaruhi desain sistem. Contohnya termasuk
keterbatasan daya yang tersedia untuk sistem dan ruang fisik yang digunakan oleh
perangkat keras. Keterbatasan ini dapat menimbulkan persyaratan untuk perangkat lunak
yang disematkan, seperti kebutuhan untuk menghemat daya dan dengan demikian
memperpanjang masa pakai baterai. Keterbatasan ukuran dan berat dapat berarti bahwa
perangkat lunak harus mengambil alih beberapa fungsi perangkat keras karena kebutuhan untuk membatasi
jumlah chip yang digunakan dalam sistem.
4. Interaksi perangkat keras langsung mungkin diperlukan. Dalam sistem interaktif dan sistem
informasi, ada lapisan perangkat lunak (pengandar perangkat) yang menyembunyikan
perangkat keras dari sistem operasi. Hal ini dimungkinkan karena Anda hanya dapat
menghubungkan beberapa jenis perangkat ke sistem ini, seperti keyboard, mouse, layar,
dll. Sebaliknya, sistem tertanam mungkin harus berinteraksi dengan berbagai perangkat
keras yang tidak memiliki perangkat terpisah. driver.
5. Masalah keamanan dan keandalan dapat mendominasi desain sistem. Banyak perangkat
kontrol sistem tertanam yang kegagalannya mungkin menimbulkan biaya manusia atau
ekonomi yang tinggi. Oleh karena itu, ketergantungan sangat penting dan desain sistem
harus memastikan perilaku kritis terhadap keselamatan setiap saat. Ini sering mengarah
pada pendekatan konservatif untuk desain di mana teknik yang dicoba dan diuji digunakan
daripada teknik yang lebih baru yang dapat memperkenalkan mode kegagalan baru.
Sistem tertanam dapat dianggap sebagai sistem reaktif; yaitu, mereka harus bereaksi terhadap
peristiwa di lingkungan mereka dengan kecepatan lingkungan itu (Berry, 1989; Lee, 2002). Waktu
respons sering diatur oleh hukum fisika daripada dipilih untuk kenyamanan manusia. Ini berbeda
dengan jenis perangkat lunak lain di mana sistem mengontrol kecepatan interaksi. Misalnya,
pengolah kata bahwa saya
menggunakan untuk menulis buku ini dapat memeriksa ejaan dan tata bahasa dan tidak ada batasan
praktis pada waktu yang dibutuhkan untuk melakukan ini.
20.1 Desain sistem tertanam

Proses desain untuk sistem tertanam adalah proses rekayasa sistem di mana perancang perangkat lunak
harus mempertimbangkan secara rinci desain dan kinerja perangkat keras sistem. Bagian dari proses
desain sistem mungkin melibatkan penentuan kemampuan sistem mana yang akan diimplementasikan
dalam perangkat lunak dan perangkat keras. Bagi banyak sistem waktu nyata yang tertanam dalam
produk konsumen, seperti sistem di ponsel, biaya, dan konsumsi daya perangkat keras sangat penting.
Prosesor khusus yang dirancang untuk mendukung sistem tertanam dapat digunakan dan, untuk
beberapa sistem, perangkat keras dengan tujuan khusus mungkin harus dirancang dan dibangun.
Ini berarti bahwa proses desain perangkat lunak top-down, di mana desain dimulai dengan model
abstrak yang didekomposisi dan dikembangkan dalam serangkaian tahapan, tidak praktis untuk sebagian
besar sistem waktu nyata. Keputusan tingkat rendah pada perangkat keras, perangkat lunak pendukung,
dan waktu sistem harus dipertimbangkan di awal proses. Ini membatasi fleksibilitas perancang sistem
dan dapat berarti bahwa fungsionalitas perangkat lunak tambahan, seperti baterai dan manajemen daya,
harus disertakan dalam sistem.
Mengingat bahwa sistem tertanam adalah sistem reaktif yang bereaksi terhadap peristiwa di
lingkungan mereka, pendekatan paling umum untuk desain perangkat lunak tertanam dan real-time
didasarkan pada model stimulus-respons. Stimulus adalah peristiwa yang terjadi di lingkungan sistem
perangkat lunak yang menyebabkan sistem bereaksi dalam beberapa cara; respon adalah sinyal atau
pesan yang dikirim oleh perangkat lunak ke lingkungannya.
Anda dapat menentukan perilaku sistem waktu nyata dengan mendaftar rangsangan yang diterima
oleh sistem, respons terkait, dan waktu di mana respons harus dihasilkan. Misalnya, Gambar 20.1
menunjukkan kemungkinan rangsangan dan respons sistem untuk sistem alarm pencuri. Saya
memberikan informasi lebih lanjut tentang sistem ini di Bagian 20.2.1.
Stimulus terbagi menjadi dua kelas:
1. Rangsangan periodik Ini terjadi pada interval waktu yang dapat diprediksi. Misalnya, sistem dapat
memeriksa sensor setiap 50 milidetik dan mengambil tindakan (merespons) tergantung pada nilai
sensor tersebut (stimulus).
2. Rangsangan aperiodik Ini terjadi secara tidak teratur dan tidak terduga dan biasanya ditandai dengan
menggunakan mekanisme interupsi komputer. Contoh dari stimulus tersebut adalah interupsi yang
menunjukkan bahwa transfer I/O telah selesai dan bahwa data tersedia dalam buffer.
Rangsangan datang dari sensor di lingkungan sistem dan tanggapan dikirim ke aktuator, seperti
yang ditunjukkan pada Gambar 20.2. Pedoman desain umum untuk sistem waktu nyata
20.1 Desain sistem tertanam 541
Rangsangan Tanggapan
Sensor tunggal positif Mulai alarm; nyalakan lampu di sekitar lokasi

sensor positif.
Dua atau lebih sensor positif Mulai alarm; nyalakan lampu di sekitar lokasi
sensor positif; hubungi polisi dengan lokasi
dugaan pembobolan.
Penurunan tegangan antara 10% Beralih ke cadangan baterai; menjalankan

dan 20% tes catu daya.
Penurunan tegangan lebih dari 20% Beralih ke cadangan baterai; memulai alarm;
panggil polisi; menjalankan tes catu daya.
Kegagalan catu daya Hubungi teknisi servis.
Kegagalan sensor Hubungi teknisi servis.
Tombol panik konsol positif Mulai alarm; menyalakan lampu di sekitar konsol;
panggil polisi.
Gambar 20.1 Rangsangan
dan tanggapan untuk Hapus alarm Matikan semua alarm aktif; matikan semua lampu
sistem alarm pencuri yang telah dinyalakan.
memiliki proses terpisah untuk setiap jenis sensor dan aktuator (Gambar 20.3).
Aktuator ini mengontrol peralatan, seperti pompa, yang kemudian membuat perubahan pada
lingkungan sistem. Aktuator itu sendiri juga dapat menghasilkan rangsangan. Itu
rangsangan dari aktuator sering menunjukkan bahwa beberapa masalah telah terjadi, yang harus
ditangani oleh sistem.
Untuk setiap jenis sensor, mungkin ada proses manajemen sensor yang menangani data
koleksi dari sensor. Proses pemrosesan data menghitung respons yang diperlukan
terhadap rangsangan yang diterima oleh sistem. Proses kontrol aktuator dikaitkan dengan
Sensor Sensor Sensor Sensor Sensor Sensor
rangsangan
Waktu sebenarnya
Sistem pengaturan
Tanggapan
Gambar 20.2 Seorang jenderal

model tertanam Aktuator Aktuator Aktuator Aktuator
sistem waktu nyata

Sensor Aktuator
Rangsangan Tanggapan
Sensor Data Aktuator

Gambar 20.3 Proses Kontrol Prosesor Kontrol
sensor dan aktuator
setiap aktuator dan mengatur pengoperasian aktuator tersebut. Model ini memungkinkan
data dikumpulkan dengan cepat dari sensor (sebelum ditimpa oleh input berikutnya)
dan memungkinkan pemrosesan dan respons aktuator terkait dilakukan kemudian.
Sebuah sistem real-time harus merespon rangsangan yang terjadi pada waktu yang
berbeda. Oleh karena itu Anda harus mengatur arsitektur sistem sehingga, segera
setelah stimulus diterima, kontrol ditransfer ke penangan yang benar. Ini tidak praktis
dalam program sekuensial. Akibatnya, sistem perangkat lunak real-time biasanya
dirancang sebagai satu set bersamaan, proses bekerja sama. Untuk mendukung
pengelolaan proses ini, platform eksekusi di mana sistem real-time dijalankan dapat
mencakup sistem operasi real-time (dibahas dalam Bagian 20.4). Fungsi-fungsi yang
disediakan oleh sistem operasi ini diakses melalui sistem pendukung run-time untuk
bahasa pemrograman real-time yang digunakan.
Tidak ada proses desain sistem tertanam standar. Sebaliknya, proses yang berbeda
digunakan yang bergantung pada jenis sistem, perangkat keras yang tersedia, dan
organisasi yang mengembangkan sistem. Aktivitas berikut dapat dimasukkan dalam
proses desain perangkat lunak waktu nyata:
1. Pemilihan platform Dalam aktivitas ini, Anda memilih platform eksekusi untuk sistem
(yaitu, perangkat keras dan sistem operasi waktu nyata yang akan digunakan).
Faktor-faktor yang mempengaruhi pilihan ini termasuk batasan waktu pada sistem,
keterbatasan daya yang tersedia, pengalaman tim pengembangan, dan target
harga untuk sistem yang dikirimkan.
2. Identifikasi rangsangan /respons Ini melibatkan pengidentifikasian rangsangan yang

harus diproses oleh sistem dan tanggapan atau tanggapan terkait untuk setiap rangsangan.
3. Analisis waktu Untuk setiap stimulus dan respons terkait, Anda mengidentifikasi
batasan waktu yang berlaku untuk pemrosesan stimulus dan respons. Ini
digunakan untuk menetapkan tenggat waktu untuk proses dalam sistem.
4. Desain proses Pada tahap ini, Anda menggabungkan proses stimulus dan respons
ke dalam sejumlah proses bersamaan. Titik awal yang baik untuk merancang
arsitektur proses adalah pola arsitektur yang saya jelaskan di Bagian 20.2. Anda
kemudian mengoptimalkan arsitektur proses untuk mencerminkan persyaratan
spesifik yang harus Anda terapkan.
5. Desain algoritma Untuk setiap stimulus dan respon, Anda merancang algoritma
untuk melakukan perhitungan yang diperlukan. Desain algoritma mungkin harus
dikembangkan relatif awal dalam proses desain untuk memberikan indikasi jumlah
pemrosesan yang diperlukan dan waktu yang dibutuhkan untuk menyelesaikan proses
tersebut. Ini sangat penting untuk tugas komputasi intensif, seperti pemrosesan sinyal.
6. Desain data Anda menentukan informasi yang dipertukarkan oleh proses dan peristiwa yang
mengoordinasikan pertukaran informasi, dan merancang struktur data untuk mengelola
pertukaran informasi ini. Beberapa proses bersamaan dapat berbagi struktur data ini.
7. Penjadwalan proses Anda merancang sistem penjadwalan yang akan memastikan bahwa proses
dimulai tepat waktu untuk memenuhi tenggat waktu mereka.
Urutan aktivitas ini dalam proses desain perangkat lunak waktu nyata tergantung pada jenis
sistem yang dikembangkan, serta proses dan persyaratan platformnya.
Dalam beberapa kasus, Anda mungkin dapat mengikuti pendekatan yang cukup abstrak di mana
Anda memulai dengan rangsangan dan pemrosesan terkait, dan memutuskan perangkat keras dan
platform eksekusi di akhir proses. Dalam kasus lain, pilihan perangkat keras dan sistem operasi
dibuat sebelum desain perangkat lunak dimulai. Dalam situasi seperti itu, Anda harus merancang
perangkat lunak untuk memperhitungkan kendala yang dikenakan oleh kemampuan perangkat keras.
Proses dalam sistem real-time harus dikoordinasikan dan berbagi informasi.
Mekanisme koordinasi proses memastikan pengecualian bersama untuk sumber daya bersama.
Ketika satu proses memodifikasi sumber daya bersama, proses lain seharusnya tidak dapat
mengubah sumber daya itu. Mekanisme untuk memastikan pengecualian bersama termasuk sema
phores (Dijkstra, 1968), monitor (Hoare, 1974), dan daerah kritis (Brinch Hansen, 1973). Mekanisme
sinkronisasi proses ini dijelaskan di sebagian besar teks sistem operasi (Silberschatz et al., 2008;
Tanenbaum, 2007).
Saat merancang pertukaran informasi antar proses, Anda harus memperhitungkan fakta bahwa
proses ini mungkin berjalan pada kecepatan yang berbeda. Salah satu prosesnya adalah
menghasilkan informasi; proses lain mengkonsumsi informasi itu. Jika produsen berjalan lebih
cepat daripada konsumen, informasi baru dapat menimpa item informasi yang telah dibaca
sebelumnya sebelum proses konsumen membaca informasi asli. Jika proses konsumen berjalan
lebih cepat dari proses produsen, item yang sama dapat dibaca dua kali.
Untuk mengatasi masalah ini, Anda harus menerapkan pertukaran informasi menggunakan
buffer bersama dan menggunakan mekanisme pengecualian bersama untuk mengontrol akses ke buffer tersebut. Ini
berarti bahwa informasi tidak dapat ditimpa sebelum dibaca dan informasi itu
tidak bisa dibaca dua kali. Gambar 20.4 mengilustrasikan gagasan buffer bersama. Ini biasanya
diimplementasikan sebagai antrian melingkar, sehingga ketidaksesuaian kecepatan antara proses
produsen dan konsumen dapat diakomodasi tanpa harus menunda eksekusi proses.
Proses produser selalu memasukkan data di lokasi buffer di bagian ekor antrian
(direpresentasikan sebagai v10 pada Gambar 20.4). Proses konsumen selalu mengambil informasi
dari kepala antrian (direpresentasikan sebagai v1 pada Gambar 20.4). Setelah proses konsumen
mengambil informasi, kepala daftar disesuaikan untuk menunjuk pada item berikutnya (v2). Setelah
proses produser menambahkan informasi, ekor daftar disesuaikan untuk menunjuk pada slot
kosong berikutnya dalam daftar.
penyangga melingkar
Produsen
Proses
v10
Ekor
v9
v8 Kepala Konsumen
v1
Proses
v7 v2
Gambar 20.4 Proses v6 v3

produsen/konsumen v5 v4
berbagi buffer melingkar
Jelas, penting untuk memastikan bahwa proses produsen dan konsumen tidak mencoba
mengakses item yang sama pada waktu yang sama (yaitu, ketika Kepala = Ekor). Anda juga harus
memastikan bahwa proses produsen tidak menambahkan item ke buffer penuh dan proses
konsumen tidak mengambil item dari buffer kosong. Untuk melakukannya, Anda
mengimplementasikan buffer melingkar sebagai proses dengan operasi Get and Put untuk
mengakses buffer. Operasi Put disebut oleh proses produsen dan operasi Get oleh proses
konsumen. Primitif sinkronisasi, seperti semaphore atau daerah kritis, digunakan untuk memastikan
bahwa operasi Get dan Put disinkronkan, sehingga mereka tidak mengakses lokasi yang sama
pada waktu yang sama. Jika buffer penuh, proses Put harus menunggu sampai slot kosong; jika
buffer kosong, proses Get harus menunggu hingga entri dibuat.
Setelah Anda memilih platform eksekusi untuk sistem, merancang arsitektur proses, dan
memutuskan kebijakan penjadwalan, Anda mungkin perlu memeriksa apakah sistem akan
memenuhi persyaratan waktunya. Anda dapat melakukan ini melalui analisis statis sistem
menggunakan pengetahuan tentang perilaku pengaturan waktu komponen, atau melalui simulasi.
Analisis ini dapat mengungkapkan bahwa sistem tidak akan bekerja secara memadai. Arsitektur
proses, kebijakan penjadwalan, platform eksekusi, atau semua ini mungkin harus didesain ulang
untuk meningkatkan kinerja sistem.
Kendala waktu atau persyaratan lain kadang-kadang dapat berarti bahwa yang terbaik adalah
mengimplementasikan beberapa fungsi sistem, seperti pemrosesan sinyal, dalam perangkat keras.
Komponen perangkat keras modern, seperti FPGA, fleksibel dan dapat disesuaikan dengan fungsi
yang berbeda. Komponen perangkat keras memberikan kinerja yang jauh lebih baik daripada
perangkat lunak setara yang dipinjamkan. Kemacetan pemrosesan sistem dapat diidentifikasi dan
digantikan oleh perangkat keras, sehingga menghindari pengoptimalan perangkat lunak yang mahal.
20.1.1 Pemodelan sistem waktu nyata

Peristiwa yang harus ditanggapi oleh sistem waktu nyata sering kali menyebabkan sistem berpindah
dari satu keadaan ke keadaan lain. Untuk alasan ini, model keadaan, yang saya perkenalkan di Bab
5, sering digunakan untuk menggambarkan sistem waktu nyata. Model keadaan suatu sistem mengasumsikan bahwa,
Waktu habis
Membaca Inisialisasi
lakukan:
lakukan:
dapatkan detail CC inisialisasi tampilan
Kartu Dimasukkan Kartu Selang Selang masuk
ke Pembaca DIHAPUS Keluar dari Sarung Tempat penyimpan pistol
Kartu Oke
Menyampaikan
Menunggu Memvalidasi Siap
lakukan: validasi
lakukan: tampilan
lakukan: berikan
selamat datang kartu kredit Nozel
tampilan pembaruan bahan bakar
Pemicu Aktif
Nozel Nozel
Tidak sah
Waktu habis Pemicu Pemicu
Kartu
Mati Pada
Berhenti
Menyetel
ulang lakukan: tampilan

kesalahan CC
Pembayaran
Konfirmasi pembayaran Selang di Sarung
lakukan: debit
akun CC
setiap saat, sistem berada di salah satu dari sejumlah kemungkinan keadaan. Ketika
Gambar 20.5 Model
mesin keadaan pompa stimulus diterima, ini dapat menyebabkan transisi ke keadaan yang berbeda. Misalnya,
bensin (gas) sistem yang mengontrol katup dapat berpindah dari keadaan 'Katup terbuka' ke keadaan
'Katup tertutup' ketika perintah operator (stimulus) diterima.
Model negara adalah cara bahasa-independen untuk mewakili desain sistem waktu
nyata dan karena itu merupakan bagian integral dari metode desain sistem waktu nyata
(Gomaa, 1993). UML mendukung pengembangan model negara berdasarkan Statecharts
(Harel, 1987; Harel, 1988). Statechart adalah model mesin status formal yang mendukung
status hierarki, sehingga kelompok status dapat dianggap sebagai satu kesatuan.
Douglass membahas penggunaan UML dalam pengembangan sistem real-time
(Douglass, 1999). Model keadaan digunakan dalam rekayasa model-driven, yang saya
bahas di Bab 5, untuk mendefinisikan operasi suatu sistem. Mereka dapat diubah secara
otomatis menjadi program yang dapat dieksekusi.
Saya telah mengilustrasikan pendekatan ini untuk pemodelan sistem di Bab 5 di
mana saya menggunakan contoh model oven microwave sederhana. Gambar 20.5
adalah contoh lain dari model state machine yang menunjukkan pengoperasian sistem
perangkat lunak pengiriman bahan bakar yang tertanam dalam pompa bensin (gas).
Persegi panjang bulat mewakili keadaan sistem dan panah mewakili rangsangan yang
memaksa transisi dari satu keadaan ke keadaan lain. Nama-nama yang dipilih dalam
diagram mesin negara bersifat deskriptif. Informasi terkait menunjukkan tindakan yang
diambil oleh aktuator sistem atau informasi yang ditampilkan. Perhatikan bahwa sistem
ini tidak pernah berhenti tetapi menganggur dalam keadaan menunggu saat pompa tidak beroperasi.
Sistem pengiriman bahan bakar dirancang untuk memungkinkan pengoperasian tanpa

pengawasan. Pembeli memasukkan kartu kredit ke pembaca kartu yang terpasang di
pompa. Ini menyebabkan transisi ke status Membaca di mana detail kartu dibaca dan
pembeli kemudian diminta untuk mengeluarkan kartu. Penghapusan kartu memicu
transisi ke status Validasi di mana kartu divalidasi. Jika kartu tersebut valid, sistem akan
menginisialisasi pompa dan, ketika selang bahan bakar dilepaskan dari holsternya,
beralih ke status Pengiriman, di mana ia siap mengirimkan bahan bakar. Mengaktifkan
pelatuk pada nosel menyebabkan bahan bakar dipompa; ini berhenti ketika pelatuk
dilepaskan (untuk kesederhanaan, saya telah mengabaikan sakelar tekanan yang
dirancang untuk menghentikan tumpahan bahan bakar). Setelah pengiriman bahan bakar
selesai dan pembeli telah mengganti selang di holsternya, sistem beralih ke status
Membayar di mana akun pengguna didebet. Setelah pembayaran, perangkat lunak pompa kembali ke status Menungg
20.1.2 Pemrograman waktu nyata

Bahasa pemrograman untuk pengembangan sistem waktu nyata harus menyertakan
fasilitas untuk mengakses perangkat keras sistem, dan harus memungkinkan untuk
memprediksi waktu operasi tertentu dalam bahasa ini. Sistem hard real-time terkadang
masih diprogram dalam bahasa assembly sehingga tenggat waktu yang ketat dapat
dipenuhi. Bahasa tingkat sistem, seperti C, yang memungkinkan kode yang efisien dihasilkan juga banyak digunakan
Keuntungan menggunakan bahasa pemrograman sistem seperti C adalah
memungkinkan pengembangan program yang sangat efisien. Namun, bahasa ini tidak
menyertakan konstruksi untuk mendukung konkurensi atau pengelolaan sumber daya bersama.
Konkurensi dan manajemen sumber daya diimplementasikan melalui panggilan ke primitif
yang disediakan oleh sistem operasi waktu nyata, seperti semaphore untuk pengecualian
bersama. Panggilan ini tidak dapat diperiksa oleh kompiler, sehingga kesalahan
pemrograman lebih mungkin terjadi. Program juga seringkali lebih sulit dipahami karena
bahasanya tidak menyertakan fitur waktu nyata. Selain memahami program, pembaca
juga harus mengetahui bagaimana dukungan real-time diberikan menggunakan panggilan sistem.
Karena sistem real-time harus memenuhi batasan waktunya, Anda mungkin tidak
dapat menggunakan pengembangan berorientasi objek untuk sistem hard real-time.
Pengembangan berorientasi objek melibatkan penyembunyian representasi data dan
mengakses nilai atribut melalui operasi yang didefinisikan dengan objek. Ini berarti bahwa
ada overhead kinerja yang signifikan dalam sistem berorientasi objek karena kode
tambahan diperlukan untuk memediasi akses ke atribut dan menangani panggilan ke
operasi. Konsekuensi hilangnya kinerja mungkin membuat tidak mungkin untuk memenuhi tenggat waktu real-time.
Versi Java telah dirancang untuk pengembangan sistem tertanam (Dibble, 2008),
dengan implementasi dari berbagai perusahaan seperti IBM dan Sun. Bahasa ini
mencakup mekanisme utas yang dimodifikasi, yang memungkinkan utas ditentukan yang
tidak akan terganggu oleh mekanisme pengumpulan sampah bahasa. Penanganan
kejadian asinkron dan spesifikasi waktu juga telah disertakan. Namun, pada saat
penulisan, ini sebagian besar telah digunakan pada platform yang memiliki prosesor dan
kapasitas memori yang signifikan (misalnya, ponsel) daripada sistem tertanam yang lebih
sederhana, dengan sumber daya yang lebih terbatas. Sistem ini biasanya masih diimplementasikan di C.
20.2 Pola arsitektur 547
Jawa waktu nyata
Bahasa pemrograman Java telah dimodifikasi dalam beberapa cara agar cocok untuk pengembangan sistem waktu
nyata. Modifikasi ini termasuk komunikasi asinkron; penambahan waktu, termasuk waktu absolut dan relatif; model
utas baru di mana utas tidak dapat diganggu oleh pengumpulan sampah; dan model manajemen memori baru yang
menghindari penundaan tak terduga yang dapat diakibatkan oleh pengumpulan sampah.
http://www.SoftwareEngineering-9.com/Web/RTS/Java.html
20.2 Pola arsitektur

Pola arsitektur, yang saya perkenalkan di Bab 6, adalah deskripsi bergaya abstrak
dari praktik desain yang baik. Mereka merangkum pengetahuan tentang organisasi
arsitektur sistem, kapan arsitektur ini harus digunakan dan kelebihan dan
kekurangannya. Anda tidak boleh, bagaimanapun, memikirkan pola arsitektur sebagai
desain generik untuk dipakai. Sebaliknya, Anda menggunakan pola untuk memahami
arsitektur dan sebagai titik awal untuk membuat desain arsitektur spesifik Anda sendiri.
Seperti yang Anda harapkan, perbedaan antara perangkat lunak tertanam dan
interaktif berarti bahwa pola arsitektur yang berbeda digunakan untuk sistem tertanam,
daripada pola arsitektur yang dibahas dalam Bab 6. Pola sistem tertanam lebih
berorientasi pada proses daripada berorientasi objek atau komponen. Pada bagian
ini, saya membahas tiga pola arsitektur real-time yang umum digunakan:
1. Amati dan Bereaksi Pola ini digunakan ketika satu set sensor dipantau dan
ditampilkan secara rutin. Ketika sensor menunjukkan bahwa beberapa peristiwa
telah terjadi (misalnya, panggilan masuk pada ponsel), sistem bereaksi dengan
memulai proses untuk menangani peristiwa itu.
2. Pengendalian Lingkungan Pola ini digunakan ketika suatu sistem menyertakan

sensor, yang memberikan informasi tentang lingkungan dan aktuator yang dapat
mengubah lingkungan. Menanggapi perubahan lingkungan yang terdeteksi oleh
sensor, sinyal kontrol dikirim ke aktuator sistem.
3. Process Pipeline Pola ini digunakan ketika data harus ditransformasikan dari satu
representasi ke representasi lainnya sebelum dapat diproses. Transformasi
diimplementasikan sebagai urutan langkah-langkah pemrosesan, yang dapat
dilakukan saat ini. Ini memungkinkan pemrosesan data yang sangat cepat, karena
inti atau prosesor yang terpisah dapat menjalankan setiap transformasi.
Pola-pola ini tentu saja dapat digabungkan dan Anda akan sering melihat lebih dari
satu pola dalam satu sistem. Misalnya, ketika pola Kontrol Lingkungan digunakan,
sangat umum untuk aktuator dipantau menggunakan pola Amati dan Bereaksi. Jika
terjadi kegagalan aktuator, sistem dapat:
Nama Amati dan Bereaksi
Keterangan Nilai input dari satu set sensor dari jenis yang sama
dikumpulkan dan dianalisis. Nilai-nilai ini ditampilkan
dalam beberapa cara. Jika nilai sensor menunjukkan
bahwa beberapa kondisi luar biasa telah muncul, maka
tindakan dimulai untuk menarik perhatian operator ke
nilai itu dan, dalam kasus tertentu, untuk mengambil
tindakan dalam menanggapi nilai luar biasa.
rangsangan Nilai dari sensor yang terpasang pada sistem.
Tanggapan Output untuk ditampilkan, pemicu alarm, sinyal ke sistem

yang bereaksi.
Proses Pengamat, Analisis, Tampilan, Alarm, Reaktor.

Gambar 20.6 Pola
Amati dan Bereaksi Digunakan dalam
Sistem pemantauan, sistem alarm.
bereaksi dengan menampilkan pesan peringatan, mematikan aktuator, beralih dalam

sistem cadangan, dll.
Pola-pola yang saya bahas di sini adalah pola arsitektur yang menggambarkan
struktur keseluruhan dari sebuah sistem tertanam. Douglass (2002) menjelaskan tingkat
yang lebih rendah, pola desain real-time yang digunakan untuk membantu Anda membuat
keputusan desain yang lebih rinci. Pola-pola ini termasuk pola desain untuk kontrol
eksekusi, komunikasi, alokasi sumber daya, dan keamanan dan keandalan.
Pola arsitektur ini harus menjadi titik awal untuk desain sistem tertanam; namun itu
bukan template desain. Jika Anda menggunakannya seperti itu, Anda mungkin akan
berakhir dengan arsitektur proses yang tidak efisien. Oleh karena itu Anda harus
mengoptimalkan struktur proses untuk memastikan bahwa Anda tidak memiliki terlalu
banyak proses. Anda juga harus memastikan bahwa ada korespondensi yang jelas
antara proses dan sensor dan aktuator dalam sistem.
20.2.1 Amati dan Bereaksi

Sistem pemantauan adalah kelas penting dari sistem waktu nyata tertanam. Sistem
pemantauan memeriksa lingkungannya melalui serangkaian sensor dan, biasanya,
menampilkan keadaan lingkungan dalam beberapa cara. Ini bisa pada layar internal,
pada tampilan instrumen tujuan khusus atau pada tampilan jarak jauh. Jika beberapa
kejadian luar biasa atau status sensor terdeteksi oleh sistem, sistem pemantauan
mengambil beberapa tindakan. Seringkali, ini melibatkan membunyikan alarm untuk
menarik perhatian operator ke acara tersebut. Terkadang sistem dapat memulai beberapa
tindakan pencegahan lainnya, seperti mematikan sistem untuk melindunginya dari kerusakan.
Pola Observe and React (Gambar 20.6 dan Gambar 20.7) merupakan pola yang umum
digunakan dalam sistem monitoring. Nilai-nilai sensor diamati dan ketika
Sensor Menampilkan
Sensor Menampilkan
Pengamat Nilai Analisis Nilai Menampilkan

Proses Proses Proses
Alarm Reaktor
Proses Proses
Gambar 20.7 Amati

dan Bereaksi struktur
Peralatan lainnya
proses Alarm
nilai-nilai tertentu terdeteksi, sistem bereaksi dalam beberapa cara. Sistem pemantauan
dapat terdiri dari beberapa contoh pola Amati dan Bereaksi, satu untuk setiap jenis
sensor dalam sistem. Tergantung pada persyaratan sistem, Anda kemudian dapat
mengoptimalkan desain dengan menggabungkan proses (misalnya, Anda dapat
menggunakan proses tampilan tunggal untuk menampilkan informasi dari semua jenis sensor yang berbeda
Sebagai contoh penggunaan pola ini, perhatikan desain alarm pencuri
sistem yang mungkin dipasang di gedung perkantoran:
Sistem perangkat lunak akan diimplementasikan sebagai bagian dari sistem

alarm pencuri untuk bangunan komersial. Ini menggunakan beberapa jenis
sensor yang berbeda. Ini termasuk detektor gerakan di masing-masing kamar,
sensor pintu yang mendeteksi pembukaan pintu koridor, dan sensor jendela di
jendela lantai dasar yang dapat mendeteksi saat jendela dibuka.
Ketika sensor mendeteksi keberadaan penyusup, sistem secara otomatis

memanggil polisi setempat dan, menggunakan synthesizer suara, melaporkan
lokasi alarm. Ini menyalakan lampu di ruangan di sekitar sensor aktif dan
menyalakan alarm yang dapat didengar. Sistem sensor biasanya ditenagai oleh
daya listrik tetapi dilengkapi dengan baterai cadangan. Kehilangan daya
dideteksi menggunakan monitor sirkuit daya terpisah yang memantau tegangan
listrik. Jika penurunan tegangan terdeteksi, sistem mengasumsikan bahwa
penyusup telah mengganggu catu daya sehingga alarm dibunyikan.
Arsitektur proses yang mungkin untuk sistem alarm ditunjukkan pada Gambar
20.8. Dalam diagram ini, panah mewakili sinyal yang dikirim dari satu proses ke
proses lainnya. Sistem ini adalah sistem real-time 'lunak' yang tidak memiliki
persyaratan waktu yang ketat. Sensor tidak perlu mendeteksi kejadian berkecepatan
tinggi, jadi mereka hanya perlu disurvei secara relatif jarang. Persyaratan waktu untuk sistem ini tercakup da
Saya telah memperkenalkan rangsangan dan tanggapan dalam sistem alarm ini
pada Gambar 20.1. Ini digunakan sebagai titik awal untuk desain sistem. Yang Mengamati
Sensor Pintu Panel kendali

Proses Proses Proses Pengujian
Pergerakan
Proses Detektor
Sistem Tampilan Konsol
Pengontrol Proses
Pemantau Tegangan
Proses
Manajemen daya
Proses
Sensor Jendela
Proses
Gambar 20.8 Struktur Alarm terdengar Peringatan Eksternal

Kontrol Pencahayaan
proses untuk sistem Proses Proses Proses
alarm pencuri
dan pola React digunakan dalam desain ini. Ada proses pengamat yang terkait
dengan setiap jenis sensor dan proses reaktor untuk setiap jenis reaksi. Ada
proses analisis tunggal yang memeriksa data dari semua sensor. Proses tampilan
dalam pola digabungkan menjadi satu proses tampilan.
20.2.2 Pengendalian Lingkungan
Mungkin penggunaan yang paling luas dari perangkat lunak tertanam adalah
dalam sistem kontrol. Dalam sistem ini, perangkat lunak mengontrol pengoperasian
peralatan, berdasarkan rangsangan dari lingkungan peralatan. Misalnya, sistem
pengereman anti selip di mobil memantau roda mobil dan sistem rem (lingkungan
sistem). Ini mencari tanda-tanda bahwa roda tergelincir saat tekanan rem
diterapkan. Jika ini masalahnya, sistem akan menyesuaikan tekanan rem untuk
menghentikan penguncian roda dan mengurangi kemungkinan selip.
Sistem kontrol dapat menggunakan pola Kontrol Lingkungan, yang merupakan
pola kontrol umum yang mencakup proses sensor dan aktuator. Pola ini dijelaskan
pada Gambar 20.9, dengan arsitektur proses yang ditunjukkan pada Gambar 20.10.
Varian dari pola ini mengabaikan proses tampilan. Varian ini digunakan dalam
situasi di mana tidak ada persyaratan untuk intervensi pengguna atau di mana
tingkat kontrol sangat tinggi sehingga tampilan tidak akan berarti.
Pola ini dapat menjadi dasar untuk desain sistem kontrol dengan instantiasi
pola Kontrol Lingkungan untuk setiap aktuator (atau jenis aktuator) yang
dikendalikan. Anda kemudian mengoptimalkan desain untuk mengurangi jumlah
proses. Misalnya, Anda dapat menggabungkan pemantauan aktuator dan proses
kontrol aktuator, atau mungkin memiliki satu proses pemantauan dan kontrol
untuk beberapa aktuator. Pengoptimalan yang Anda pilih bergantung pada
persyaratan waktu. Anda mungkin perlu memantau sensor lebih sering daripada
mengirim sinyal kontrol, dalam hal ini mungkin tidak praktis untuk menggabungkan proses kontrol dan pem
Nama Pengendalian Lingkungan
Keterangan Sistem menganalisis informasi dari seperangkat

sensor yang mengumpulkan data dari lingkungan
sistem. Informasi lebih lanjut juga dapat
dikumpulkan tentang keadaan aktuator yang
terhubung ke sistem. Berdasarkan data dari sensor
dan aktuator, sinyal kontrol dikirim ke aktuator yang
kemudian menyebabkan perubahan pada lingkungan
sistem. Informasi tentang nilai sensor dan status aktuator
dapat ditampilkan.
rangsangan Nilai dari sensor yang terpasang pada sistem dan status
aktuator sistem.
Tanggapan Kontrol sinyal ke aktuator, tampilkan informasi.
Proses Monitor, Kontrol, Tampilan, Driver Aktuator, monitor

Aktuator.
Gambar 20.9 Pola
Pengendalian Digunakan dalam
Sistem kontrol.
Lingkungan
umpan balik langsung antara kontrol aktuator dan proses pemantauan aktuator.
Hal ini memungkinkan keputusan kontrol butiran halus dibuat oleh proses kontrol aktuator.
Anda dapat melihat bagaimana pola ini digunakan pada Gambar 20.11, yang
menunjukkan contoh pengontrol untuk sistem pengereman mobil. Titik awal untuk
desain adalah mengasosiasikan contoh pola dengan setiap jenis aktuator dalam
sistem. Dalam hal ini, ada empat aktuator, dengan masing-masing mengendalikan
rem pada satu roda. Proses sensor individu digabungkan menjadi satu proses
pemantauan roda yang memantau sensor di semua roda. Ini memantau keadaan setiap roda untuk memerik
Menampilkan
Sensor
Sensor Menampilkan
Memantau Nilai Kontrol Nilai Menampilkan

Proses proses Proses
Kontrol Aktuator
instruksi Negara
Aktuator Monitor Aktuator

Proses Pengemudi Proses
Gambar 20.10
Struktur proses
Pengendalian Lingkungan Aktuator
Sensor Tekanan Pedal
Rem 1 Rem 2
Pedal
Memantau
Rem 1 Rem 2
Proses Proses
Analisis
Proses
Rem 3 Rem 4
Proses Proses
Roda
Gambar 20.11 Memantau
Arsitektur sistem Rem 3 Rem 4

kontrol untuk sistem
pengereman anti-selip Sensor Roda
berputar atau terkunci. Proses terpisah memantau tekanan pada pedal rem yang
diberikan oleh pengemudi mobil.
Sistem ini mencakup fitur anti-selip, yang dipicu jika sensor menunjukkan bahwa
roda terkunci saat rem telah diterapkan. Ini berarti tidak ada gesekan yang cukup
antara jalan dan ban; dengan kata lain, mobil selip.
Jika roda terkunci, pengemudi tidak dapat mengemudikan roda tersebut. Untuk
mengatasi hal ini, sistem mengirimkan urutan sinyal on/off yang cepat ke rem pada
roda tersebut, yang memungkinkan roda berputar dan kontrol kembali.
20.2.3 Pipa Proses

Banyak sistem waktu nyata berkaitan dengan pengumpulan data dari lingkungan
sistem, kemudian mengubah data tersebut dari representasi aslinya menjadi beberapa
representasi digital lain yang dapat lebih mudah dianalisis dan diproses oleh sistem.
Sistem juga dapat mengubah data digital menjadi data analog, yang kemudian
dikirimkan ke lingkungannya. Misalnya, radio perangkat lunak menerima paket data
digital yang masuk yang mewakili transmisi radio dan mengubahnya menjadi sinyal
suara yang dapat didengarkan orang.
Pemrosesan data yang terlibat dalam banyak sistem ini harus dilakukan dengan
sangat cepat. Jika tidak, data yang masuk dapat hilang dan sinyal keluar dapat
terputus karena informasi penting hilang. Pola Process Pipeline memungkinkan
pemrosesan cepat ini dengan memecah pemrosesan data yang diperlukan menjadi
urutan transformasi terpisah, dengan setiap transformasi dilakukan oleh proses
independen. Ini adalah arsitektur yang sangat efisien untuk sistem yang menggunakan
banyak prosesor atau prosesor multicore. Setiap proses dalam pipeline dapat
diasosiasikan dengan prosesor atau inti yang terpisah, sehingga langkah-langkah
pemrosesan dapat dilakukan secara paralel.
Nama Pipa Proses
Keterangan Sebuah pipa proses diatur dengan data yang bergerak secara berurutan
dari satu ujung pipa ke yang lain. Proses sering dihubungkan oleh buffer
yang disinkronkan untuk memungkinkan proses produsen dan konsumen
berjalan pada kecepatan yang berbeda. Puncak dari sebuah pipeline
dapat berupa tampilan atau penyimpanan data atau pipeline dapat berakhir
di sebuah aktuator.
rangsangan Nilai masukan dari lingkungan atau proses lainnya
Tanggapan Nilai keluaran ke lingkungan atau buffer bersama
Proses Produsen, Penyangga, Konsumen

Gambar 20.12 Pola
Proses Pipeline Digunakan dalam
Sistem akuisisi data, sistem multimedia
Gambar 20.12 adalah deskripsi singkat dari pola jalur pipa data, dan Gambar 20.13
menunjukkan arsitektur proses untuk pola ini. Perhatikan bahwa proses yang terlibat dapat
menghasilkan dan mengkonsumsi informasi. Mereka dihubungkan oleh buffer yang
disinkronkan, seperti yang dibahas dalam Bagian 20.1. Hal ini memungkinkan proses
produsen dan konsumen untuk beroperasi pada kecepatan yang berbeda tanpa kehilangan data.
Contoh sistem yang mungkin menggunakan jalur pipa proses adalah sistem akuisisi
data berkecepatan tinggi. Sistem akuisisi data mengumpulkan data dari sensor untuk
pemrosesan dan analisis selanjutnya. Sistem ini digunakan dalam situasi di mana
sensor mengumpulkan banyak data dari lingkungan sistem dan tidak mungkin atau
tidak perlu memproses data tersebut secara real time. Sebaliknya, itu dikumpulkan dan
disimpan untuk analisis nanti. Sistem akuisisi data sering digunakan dalam eksperimen
ilmiah dan sistem kontrol proses di mana proses fisik, seperti reaksi kimia, sangat
cepat. Dalam sistem ini, sensor dapat menghasilkan data dengan sangat cepat dan
sistem akuisisi data harus memastikan bahwa pembacaan sensor dikumpulkan
sebelum nilai sensor berubah.
Gambar 20.14 adalah model sederhana dari sistem akuisisi data daripada yang
mungkin menjadi bagian dari perangkat lunak kontrol dalam reaktor nuklir. Ini adalah
sistem yang mengumpulkan data dari sensor yang memantau fluks neutron (densitas neutron) di dalam reakto
Data sensor ditempatkan dalam buffer dari mana ia diekstraksi dan diproses. Tingkat
Gambar 20.13 Struktur
fluks rata-rata ditampilkan pada layar operator dan disimpan untuk pemrosesan
proses Pipeline Proses
selanjutnya.
Diproduksi dikonsumsi
Produsen Data Penyangga Data Konsumen
...
Sensor Fluks Neutron

Sensor Penyimpanan
pengenal dan Diproses

Nilai Fluks Tingkat Fluks
IKLAN Data mentah Aliran Nilai Fluks

Konverter Penyangga Pengolahan Penyangga
Menampilkan
Gambar 20.14 Akuisisi data

fluks neutron
20.3 Analisis waktu

Seperti yang saya bahas di pendahuluan, kebenaran sistem waktu nyata tidak hanya
bergantung pada kebenaran keluarannya tetapi juga pada waktu di mana keluaran ini
diproduksi. Ini berarti bahwa aktivitas penting dalam proses pengembangan perangkat
lunak real-time yang tertanam adalah analisis waktu. Dalam analisis seperti itu, Anda
menghitung seberapa sering setiap proses dalam sistem harus dijalankan untuk
memastikan bahwa semua input diproses dan semua respons sistem dihasilkan tepat
waktu. Hasil analisis waktu digunakan untuk memutuskan seberapa sering setiap proses
harus dijalankan dan bagaimana proses ini harus dijadwalkan oleh sistem operasi waktu nyata.
Analisis waktu untuk sistem waktu nyata sangat sulit ketika sistem harus berurusan
dengan campuran rangsangan dan respons periodik dan aperiodik. Karena rangsangan
aperiodik tidak dapat diprediksi, Anda harus membuat asumsi tentang probabilitas
rangsangan ini terjadi dan oleh karena itu membutuhkan layanan pada waktu tertentu.
Asumsi ini mungkin salah dan kinerja sistem setelah pengiriman mungkin tidak memadai.
Buku Cooling (2003) membahas teknik untuk analisis kinerja sistem waktu-nyata yang
memperhitungkan peristiwa aperiodik.
Namun, karena komputer menjadi lebih cepat, di banyak sistem, menjadi mungkin
untuk merancang hanya dengan menggunakan rangsangan periodik. Ketika prosesor
lambat, rangsangan aperiodik harus digunakan untuk memastikan bahwa peristiwa kritis
diproses sebelum batas waktunya, karena penundaan dalam pemrosesan biasanya
melibatkan beberapa kerugian pada sistem. Misalnya, kegagalan catu daya dalam sistem
tertanam dapat berarti bahwa sistem harus mematikan peralatan yang terpasang dengan
cara yang terkendali, dalam waktu yang sangat singkat (katakanlah 50 milidetik). Ini
dapat diimplementasikan sebagai interupsi 'daya gagal'. Namun, itu juga dapat
diimplementasikan dengan menggunakan proses periodik yang berjalan sangat sering
dan memeriksa daya. Selama waktu antara pemanggilan proses pendek, masih ada
waktu untuk melakukan shutdown terkontrol dari sistem sebelum kekurangan daya menyebabkan kerusakan. Untuk
Ketika Anda menganalisis persyaratan waktu dari sistem waktu nyata tertanam dan
merancang sistem untuk memenuhi persyaratan ini, ada tiga faktor utama yang harus
Anda pertimbangkan: 1. Tenggat Waktu di mana rangsangan harus diproses dan
beberapa respons yang dihasilkan oleh sistem . Jika sistem tidak memenuhi tenggat
waktu, jika
20.3 Analisis waktu 555
sistem hard-real time, ini adalah kegagalan sistem; dalam sistem waktu-nyata yang lembut,
ini menghasilkan layanan sistem yang terdegradasi.
2. Frekuensi Jumlah kali per detik bahwa suatu proses harus dijalankan sehingga
Anda yakin bahwa itu selalu dapat memenuhi tenggat waktu.
3. Execution time Waktu yang dibutuhkan untuk memproses suatu stimulus dan menghasilkan respon.
Seringkali, Anda harus mempertimbangkan dua waktu eksekusi—waktu eksekusi rata-rata
dari suatu proses dan waktu eksekusi kasus terburuk untuk proses tersebut.
Waktu eksekusi tidak selalu sama karena eksekusi kode bersyarat, penundaan menunggu
proses lain, dll. Dalam sistem waktu nyata yang sulit, Anda mungkin harus membuat asumsi
berdasarkan waktu eksekusi kasus terburuk untuk memastikan bahwa tenggat waktu tidak
ketinggalan. Dalam sistem waktu nyata lunak, Anda mungkin dapat mendasarkan perhitungan
Anda pada waktu eksekusi rata-rata.
Untuk melanjutkan contoh kegagalan catu daya, mari kita asumsikan bahwa, setelah peristiwa
kegagalan, dibutuhkan 50 ms agar tegangan yang disuplai turun ke tingkat di mana peralatan
mungkin rusak. Oleh karena itu, proses shutdown peralatan harus dimulai dalam waktu 50 ms dari
peristiwa kegagalan daya. Dalam kasus seperti itu, akan lebih bijaksana untuk menetapkan batas
waktu yang lebih pendek 40 ms, karena variasi fisik pada peralatan. Ini berarti bahwa instruksi
shutdown untuk semua peralatan terpasang yang berisiko harus dikeluarkan dan diproses dalam
waktu 40 ms, dengan asumsi bahwa peralatan tersebut juga bergantung pada catu daya yang rusak.
Jika Anda mendeteksi kegagalan daya dengan memantau level tegangan, Anda harus
melakukan lebih dari satu pengamatan untuk mendeteksi bahwa tegangan turun. Jika Anda
menjalankan proses 250 kali per detik, ini berarti proses ini berjalan setiap 4 ms dan Anda mungkin
memerlukan hingga dua periode untuk mendeteksi penurunan tegangan. Oleh karena itu,
dibutuhkan waktu hingga 8 ms untuk mendeteksi masalah tersebut. Akibatnya, waktu eksekusi
kasus terburuk dari proses shutdown tidak boleh melebihi 16 ms, untuk memastikan bahwa
tenggat waktu 40 ms terpenuhi. Angka ini dihitung dengan mengurangkan periode proses (8 mdtk)
dari batas waktu (40 mdtk) dan membagi hasilnya dengan dua, karena diperlukan dua eksekusi proses.
Pada kenyataannya, Anda biasanya akan menargetkan sesuatu yang kurang dari 16 ms untuk
memberi Anda margin keamanan jika perhitungan Anda salah. Faktanya, waktu yang diperlukan
untuk memeriksa sensor dan memeriksa bahwa tidak ada kehilangan tegangan yang signifikan
harus kurang dari 16 ms. Ini hanya melibatkan perbandingan sederhana dari dua nilai. Waktu
eksekusi rata-rata dari proses monitor daya harus kurang dari 1 ms.
Titik awal untuk analisis waktu dalam sistem waktu nyata adalah persyaratan waktu, yang
harus menetapkan tenggat waktu untuk setiap respons yang diperlukan dalam sistem. Gambar
20.15 menunjukkan kemungkinan persyaratan waktu untuk sistem alarm pencuri gedung kantor
yang dibahas dalam Bagian 20.2.1. Untuk menyederhanakan contoh ini, mari kita abaikan
rangsangan yang dihasilkan oleh prosedur pengujian sistem dan sinyal eksternal untuk mengatur
ulang sistem jika terjadi alarm palsu. Ini berarti hanya ada dua jenis stimulus yang akan diproses oleh sistem:
1. Kegagalan daya Hal ini dideteksi dengan mengamati penurunan tegangan lebih dari 20%.
Tanggapan yang diperlukan adalah mengalihkan sirkuit ke daya cadangan dengan memberi
sinyal perangkat pengalih daya elektronik, yang mengalihkan daya listrik ke cadangan baterai.
Stimulus/Respons Persyaratan Waktu
Masalah listrik Peralihan ke daya cadangan harus diselesaikan dalam waktu

batas waktu 50 ms.
Alarm pintu Setiap alarm pintu harus disurvei dua kali per detik.
Alarm jendela Setiap jendela alarm harus disurvei dua kali per detik.
Detektor gerakan Setiap detektor gerakan harus disurvei dua kali per
detik.
Alarm terdengar Alarm yang dapat didengar harus diaktifkan dalam waktu setengah
detik alarm yang dibangkitkan oleh sensor.
Saklar lampu Lampu harus dinyalakan dalam waktu setengah detik

alarm yang dibangkitkan oleh sensor.
Komunikasi Panggilan ke polisi harus dimulai dalam 2 detik

dari alarm yang dibangkitkan oleh sensor.
Gambar 20.15 Waktu Sintesis suara Pesan yang disintesis harus tersedia dalam waktu 2
persyaratan untuk detik setelah alarm dibangkitkan oleh sensor.
sistem alarm pencuri
2. Alarm penyusup Ini adalah stimulus yang dihasilkan oleh salah satu sensor sistem. Itu
respons terhadap stimulus ini adalah menghitung nomor kamar dari sensor aktif, set
menelepon polisi, memulai penyintesis suara untuk mengelola panggilan, dan
nyalakan alarm penyusup yang dapat didengar dan lampu gedung di area tersebut.
Seperti yang ditunjukkan pada Gambar 20.15, Anda harus membuat daftar batasan waktu untuk setiap kelas:
sensor secara terpisah, meskipun (seperti dalam kasus ini) keduanya sama. Dengan mempertimbangkan mereka
secara terpisah, Anda meninggalkan ruang lingkup untuk perubahan di masa mendatang dan
membuatnya lebih mudah untuk menghitung berapa kali proses pengendalian harus dijalankan setiap detik.
Mengalokasikan fungsi sistem ke proses bersamaan adalah tahap desain berikutnya.
Ada empat jenis sensor yang harus disurvei secara berkala, masing-masing dengan proses yang terkait.
Ini adalah sensor tegangan, sensor pintu, sensor jendela, dan detektor gerakan. Biasanya, proses yang
terkait dengan sensor akan dijalankan dengan sangat
secepat yang mereka lakukan hanyalah memeriksa apakah sensor telah mengubah statusnya (misalnya,
dari mati ke hidup). Masuk akal untuk mengasumsikan bahwa waktu eksekusi untuk memeriksa
dan menilai keadaan satu sensor tidak lebih dari 1 ms.
Untuk memastikan bahwa Anda memenuhi tenggat waktu yang ditentukan oleh persyaratan waktu, Anda
kemudian harus memutuskan seberapa sering proses terkait harus dijalankan dan berapa banyak
sensor harus diperiksa selama setiap pelaksanaan proses. Ada yang jelas
trade-off di sini antara frekuensi dan waktu eksekusi:
1. Jika Anda memeriksa satu sensor selama setiap eksekusi proses, maka jika ada N sensor
dari jenis tertentu, Anda harus menjadwalkan proses 4N kali per detik untuk memastikan
bahwa Anda memenuhi tenggat waktu untuk mendeteksi perubahan keadaan dalam 0,25 detik.
20.3 Analisis waktu 557
50Hz (0,5 mdtk) B
Sensor Pintu Panel kendali

50Hz (0,5 mdtk) Proses Pengujian
Proses Proses
Pergerakan
50Hz (1 mdtk) 250Hz (1 mdtk)
Proses Detektor
Sistem Tampilan Konsol
Pengontrol Proses 50Hz (1 mdtk)
Pemantau Tegangan
250Hz (0,5 mdtk)
Proses
Manajemen daya
Proses R (20 mdtk)
Sensor Jendela
50Hz (0,5 mdtk)
Proses
Alarm terdengar Kontrol Pencahayaan Peringatan Eksternal

R (5 mdtk) R (5 mdtk) R (10 mdtk)
2. Jika Anda memeriksa empat sensor, katakanlah, selama setiap eksekusi proses, maka
Gambar 20.16 Waktu
waktu eksekusi ditingkatkan menjadi 4 ms, tetapi Anda hanya perlu menjalankan
proses alarm
proses N kali/detik untuk memenuhi persyaratan waktu.
Dalam hal ini, karena persyaratan sistem menentukan tindakan ketika dua atau lebih
sensor positif, mungkin masuk akal untuk memeriksa sensor dalam kelompok, dengan
kelompok berdasarkan kedekatan fisik sensor. Jika penyusup telah memasuki gedung
maka mungkin sensor yang berdekatan yang positif.
Ketika Anda telah menyelesaikan analisis waktu, Anda kemudian dapat membubuhi
keterangan model proses dengan informasi tentang frekuensi eksekusi dan waktu eksekusi
yang diharapkan (lihat Gambar 20.16 sebagai contoh). Di sini, proses periodik dianotasi
dengan frekuensinya, proses yang dimulai sebagai respons terhadap stimulus dianotasi
dengan R, dan proses pengujian adalah proses latar belakang, dianotasi dengan B. Ini
berarti proses tersebut hanya berjalan jika waktu prosesor tersedia. Secara umum, lebih
sederhana untuk merancang suatu sistem sehingga ada sejumlah kecil frekuensi proses.
Waktu eksekusi mewakili waktu eksekusi kasus terburuk yang diperlukan dari proses.
Langkah terakhir dalam proses desain adalah merancang sistem penjadwalan yang
akan memastikan bahwa suatu proses akan selalu dijadwalkan untuk memenuhi tenggat
waktu. Anda hanya dapat melakukan ini jika Anda mengetahui pendekatan penjadwalan
yang didukung oleh sistem operasi real-time yang digunakan (Burns and Wellings, 2009).
Penjadwal dalam OS waktu nyata mengalokasikan proses ke prosesor untuk waktu tertentu.
Waktu dapat tetap, atau dapat bervariasi tergantung pada prioritas proses.
Dalam mengalokasikan prioritas proses, Anda harus mempertimbangkan tenggat waktu setiap proses
sehingga proses dengan tenggat waktu yang singkat menerima waktu prosesor untuk memenuhi tenggat waktu tersebut.
Misalnya, proses monitor tegangan pada alarm pencuri perlu dijadwalkan agar penurunan
tegangan dapat dideteksi dan sakelar dibuat untuk mencadangkan daya sebelum sistem
gagal. Oleh karena itu, ini harus memiliki prioritas lebih tinggi daripada proses yang
memeriksa nilai sensor, karena ini memiliki tenggat waktu yang cukup longgar dibandingkan
dengan waktu eksekusi yang diharapkan.
20.4 Sistem operasi waktu nyata
Platform eksekusi untuk sebagian besar sistem aplikasi adalah sistem operasi yang mengelola
sumber daya bersama dan menyediakan fitur seperti sistem file, manajemen proses run-time, dll.
Namun, fungsionalitas ekstensif dalam sistem operasi konvensional memakan banyak ruang dan
memperlambat pengoperasian pro gram. Selain itu, fitur manajemen proses dalam sistem mungkin
tidak dirancang untuk memungkinkan kontrol halus atas penjadwalan proses.
Untuk alasan ini, sistem operasi standar, seperti Linux dan Windows, biasanya tidak digunakan
sebagai platform eksekusi untuk sistem waktu nyata. Sistem tertanam yang sangat sederhana dapat
diimplementasikan sebagai sistem 'bare metal'. Sistem itu sendiri termasuk sistem startup dan
shutdown, proses dan manajemen sumber daya, dan penjadwalan proses. Lebih umum, bagaimanapun,
aplikasi tertanam dibangun di atas sistem operasi real-time (RTOS), yang merupakan sistem operasi
yang efisien yang menawarkan fitur yang dibutuhkan oleh sistem real-time. Contoh RTOS adalah
Windows/CE, Vxworks, dan RTLinux.
Sistem operasi waktu nyata mengelola proses dan alokasi sumber daya untuk sistem waktu
nyata. Ini memulai dan menghentikan proses sehingga rangsangan dapat ditangani dan
mengalokasikan memori dan sumber daya prosesor. Komponen RTOS (Gambar 20.17) bergantung
pada ukuran dan kompleksitas sistem waktu nyata yang sedang dikembangkan. Untuk semua kecuali
sistem yang paling sederhana, biasanya meliputi:
1. Jam waktu nyata, yang menyediakan informasi yang diperlukan untuk menjadwalkan proses secara
berkala.
2. Penangan interupsi, yang mengelola permintaan layanan aperiodik.
3. Penjadwal, yang bertanggung jawab untuk memeriksa proses yang dapat dijalankan
dipotong dan memilih salah satu dari ini untuk dieksekusi.
4. Manajer sumber daya, yang mengalokasikan memori dan sumber daya prosesor yang sesuai untuk
proses yang telah dijadwalkan untuk dieksekusi.
5. Dispatcher, yang bertanggung jawab untuk memulai eksekusi proses.
Sistem operasi waktu nyata untuk sistem besar, seperti kontrol proses atau sistem komunikasi
telekomunikasi, mungkin memiliki fasilitas tambahan, yaitu manajemen penyimpanan disk, fasilitas
manajemen kesalahan yang mendeteksi dan melaporkan kesalahan sistem, dan manajer konfigurasi
yang mendukung rekonfigurasi dinamis real-time. aplikasi waktu.
20.4.1 Manajemen proses

Sistem waktu nyata harus menangani peristiwa eksternal dengan cepat dan, dalam beberapa kasus,
memenuhi tenggat waktu untuk memproses peristiwa ini. Ini berarti bahwa proses penanganan
peristiwa harus dijadwalkan untuk dieksekusi pada waktunya untuk mendeteksi peristiwa tersebut. Mereka juga harus dialokasikan
20.4 Sistem operasi waktu nyata 559
Penjadwalan
Informasi
Waktu sebenarnya
Penjadwal Mengganggu
Jam Pawang
Sumber Daya Proses

Persyaratan
Proses Tersedia
Sumber
Menunggu Sumber
Sumber daya Pengelola Daftar
Siap Dilepaskan
Proses Sumber daya
Siap Prosesor
Daftar
pengirim Daftar
Gambar 20.17
Komponen
sistem operasi
waktu nyata Proses Eksekusi
sumber daya prosesor yang cukup untuk memenuhi tenggat waktu mereka. Manajer proses
dalam RTOS bertanggung jawab untuk memilih proses untuk dieksekusi, mengalokasikan
sumber daya prosesor dan memori, dan memulai dan menghentikan eksekusi proses pada prosesor.
Manajer proses harus mengelola proses dengan prioritas yang berbeda. Untuk beberapa
rangsangan, seperti yang terkait dengan peristiwa luar biasa tertentu, pemrosesannya harus
diselesaikan dalam batas waktu yang ditentukan. Proses lain dapat ditunda dengan aman jika
proses yang lebih kritis membutuhkan layanan. Akibatnya, RTOS harus mampu mengelola
setidaknya dua tingkat prioritas untuk proses sistem:
1. Interrupt level Ini adalah level prioritas tertinggi. Ini dialokasikan untuk proses yang
membutuhkan respons yang sangat cepat. Salah satu proses ini akan menjadi proses
jam waktu nyata.
2. Tingkat jam Tingkat prioritas ini dialokasikan untuk proses periodik.
Mungkin ada tingkat prioritas lebih lanjut yang dialokasikan untuk proses latar belakang
(seperti proses pemeriksaan mandiri) yang tidak perlu memenuhi tenggat waktu nyata. Proses-
proses ini dijadwalkan untuk dieksekusi ketika kapasitas prosesor tersedia.
Dalam masing-masing tingkat prioritas ini, kelas proses yang berbeda dapat dialokasikan
prioritas yang berbeda. Misalnya, mungkin ada beberapa jalur interupsi. Interupsi dari
perangkat yang sangat cepat mungkin harus mendahului pemrosesan interupsi dari perangkat
yang lebih lambat untuk menghindari kehilangan informasi. Alokasi prioritas proses sehingga
semua proses dilayani tepat waktu biasanya memerlukan analisis dan simulasi yang ekstensif.
Antrian Proses Daftar Prosesor Peta Memori Daftar Siap
Penjadwal Manajer Sumber Daya pengirim
Pilih Proses untuk Alokasikan Memori Mulai Eksekusi pada

Eksekusi dan Prosesor Prosesor yang tersedia
Proses periodik adalah proses yang harus dijalankan pada interval waktu tertentu untuk
Gambar 20.18 Tindakan
akuisisi data dan kontrol aktuator. Di sebagian besar sistem waktu nyata, akan ada beberapa jenis
RTOS yang diperlukan
untuk memulai proses proses periodik. Dengan menggunakan persyaratan waktu yang ditentukan dalam program
aplikasi, RTOS mengatur pelaksanaan proses berkala sehingga semuanya dapat memenuhi
tenggat waktu mereka.
Tindakan yang diambil oleh sistem operasi untuk manajemen proses periodik ditunjukkan
pada Gambar 20.18. Penjadwal memeriksa daftar proses periodik dan memilih proses yang akan
dieksekusi. Pilihannya tergantung pada prioritas proses, periode proses, waktu eksekusi yang
diharapkan, dan tenggat waktu proses siap. Terkadang, dua proses dengan tenggat waktu yang
berbeda harus dieksekusi pada clock tick yang sama. Dalam situasi seperti itu, satu proses harus
ditunda. Biasanya, sistem akan memilih untuk menunda proses dengan tenggat waktu paling lama.
Proses yang harus merespon dengan cepat ke peristiwa asinkron mungkin didorong oleh
interupsi. Mekanisme interupsi komputer menyebabkan kontrol ditransfer ke lokasi memori yang
telah ditentukan sebelumnya. Lokasi ini berisi instruksi untuk melompat ke rutin layanan interupsi
yang sederhana dan cepat. Rutinitas layanan menonaktifkan interupsi lebih lanjut untuk
menghindari interupsi itu sendiri. Ia kemudian menemukan penyebab interupsi dan memulai,
dengan prioritas tinggi, sebuah proses untuk menangani stimulus yang menyebabkan interupsi.
Dalam beberapa sistem akuisisi data berkecepatan tinggi, pengendali interupsi menyimpan data
yang sinyal interupsinya tersedia dalam buffer untuk diproses nanti. Interupsi kemudian diaktifkan
kembali dan kontrol dikembalikan ke sistem operasi.
Pada satu waktu, mungkin ada beberapa proses, semua dengan prioritas berbeda, yang dapat
dieksekusi. Penjadwal proses mengimplementasikan kebijakan penjadwalan sistem yang
menentukan urutan eksekusi proses. Ada dua strategi penjadwalan yang umum digunakan:
1. Penjadwalan non-pre-emptive Setelah sebuah proses dijadwalkan untuk dieksekusi, proses itu
berjalan sampai selesai atau sampai diblokir karena beberapa alasan, seperti menunggu input.
Hal ini dapat menyebabkan masalah, namun, ketika ada proses dengan prioritas yang
berbeda dan proses dengan prioritas tinggi harus menunggu proses dengan prioritas rendah untuk selesai.
2. Penjadwalan pre-emptive Eksekusi proses eksekusi dapat dihentikan jika proses dengan
prioritas lebih tinggi memerlukan layanan. Proses dengan prioritas lebih tinggi mendahului
eksekusi proses dengan prioritas lebih rendah dan dialokasikan ke prosesor.
Dalam strategi ini, algoritma penjadwalan yang berbeda telah dikembangkan.

Ini termasuk penjadwalan round-robin, di mana setiap proses dijalankan secara bergantian;
Bab 20 Poin Kunci 561
tingkat penjadwalan monoton, di mana proses dengan periode terpendek

(frekuensi tertinggi) diberikan prioritas; dan tenggat waktu terpendek
penjadwalan pertama, dimana proses dalam antrian dengan tenggat waktu
terpendek dijadwalkan (Burns dan Wellings, 2009).
Informasi tentang proses yang akan dieksekusi diteruskan ke manajer
sumber daya. Manajer sumber daya mengalokasikan memori dan, dalam sistem
multiprosesor, juga menambahkan prosesor ke proses ini. Proses tersebut
kemudian ditempatkan pada 'ready list', daftar proses yang siap untuk
dieksekusi. Ketika prosesor selesai mengeksekusi proses dan menjadi tersedia,
operator dipanggil. Ini memindai daftar siap untuk menemukan proses yang
dapat dieksekusi pada prosesor yang tersedia dan memulai eksekusinya.
POIN KUNCI
Sistem perangkat lunak tertanam adalah bagian dari sistem perangkat keras/perangkat lunak yang bereaksi terhadap
kejadian di lingkungannya. Perangkat lunak 'tertanam' di perangkat keras. Sistem tertanam biasanya merupakan
sistem waktu nyata.
Sistem waktu nyata adalah sistem perangkat lunak yang harus merespon peristiwa secara waktu nyata. Sistem
kebenaran tidak hanya tergantung pada hasil yang dihasilkannya, tetapi juga pada waktu ketika hasil ini dihasilkan.
Sistem waktu nyata biasanya diimplementasikan sebagai serangkaian proses komunikasi yang bereaksi terhadap
rangsangan untuk menghasilkan tanggapan.
Model keadaan adalah representasi desain yang penting untuk sistem waktu nyata tertanam. Mereka digunakan untuk
menunjukkan bagaimana sistem bereaksi terhadap lingkungannya saat peristiwa memicu perubahan keadaan dalam
sistem.
Ada beberapa pola standar yang dapat diamati dalam berbagai jenis tertanam
sistem. Ini termasuk pola untuk memantau lingkungan sistem untuk kejadian buruk, pola untuk kontrol aktuator dan
pola pemrosesan data.
Perancang sistem waktu nyata harus melakukan analisis waktu, yang didorong oleh tenggat waktu untuk memproses dan
menanggapi rangsangan. Mereka harus memutuskan seberapa sering setiap proses dalam sistem harus dijalankan dan
waktu eksekusi yang diharapkan dan kasus terburuk untuk proses.
Sistem operasi waktu nyata bertanggung jawab atas proses dan manajemen sumber daya. Itu selalu
termasuk penjadwal, yang merupakan komponen yang bertanggung jawab untuk memutuskan proses mana yang harus
dijadwalkan untuk dieksekusi.
BACAAN LEBIH LANJUT
Rekayasa Perangkat Lunak untuk Sistem Real-Time. Ditulis dari perspektif teknik daripada ilmu komputer, buku ini adalah
panduan praktis yang baik untuk rekayasa sistem waktu nyata. Ini memiliki cakupan yang baik dari masalah perangkat keras,
jadi merupakan pelengkap yang sangat baik untuk buku Burns and Wellings (lihat di bawah). (J. Pendinginan, Addison-Wesley,
2003.)
Sistem dan Bahasa Pemrograman Real-time: Ada, Java Real-time dan C/ Real-time POSIX, edisi ke-4. Teks yang
sangat baik dan komprehensif yang menyediakan cakupan luas dari semua aspek sistem waktu nyata. (A. Burns dan A.
Wellings, Addison-Wesley, 2009.)
'Tren dalam Rekayasa Perangkat Lunak Tertanam'. Artikel ini menyarankan bahwa pengembangan berbasis model (seperti
yang dibahas dalam Bab 5 buku ini), akan menjadi pendekatan penting untuk pengembangan sistem tertanam. Ini adalah bagian
dari masalah khusus pada sistem tertanam dan Anda mungkin menemukan bahwa artikel lain juga berguna untuk dibaca.
(Perangkat Lunak IEEE, 26 (3), Mei–Juni 2009.) http://dx.doi.org/10.1109/MS.2009.80.
LATIHAN
20.1. Dengan menggunakan contoh, jelaskan mengapa sistem waktu nyata biasanya harus diimplementasikan
menggunakan proses bersamaan.
20.2. Mengidentifikasi kemungkinan rangsangan dan tanggapan yang diharapkan untuk sistem tertanam yang mengontrol a
kulkas rumah atau mesin cuci rumah tangga.
20.3. Menggunakan pendekatan berbasis negara untuk pemodelan, seperti yang dibahas dalam Bagian 20.1.1, modelkan
pengoperasian sistem perangkat lunak tertanam untuk sistem pesan suara yang disertakan dalam telepon rumah.
Ini akan menampilkan jumlah pesan yang direkam pada layar LED dan harus memungkinkan pengguna untuk masuk
dan mendengarkan pesan yang direkam.
20.4. Jelaskan mengapa pendekatan berorientasi objek untuk pengembangan perangkat lunak mungkin tidak cocok untuk
sistem waktu nyata.
20.5. Tunjukkan bagaimana pola Pengendalian Lingkungan dapat digunakan sebagai dasar perancangan sistem pengendalian
suhu di dalam rumah kaca. Suhu harus antara 10 dan 30 derajat Celcius. Jika turun di bawah 10 derajat, sistem
pemanas harus dinyalakan; jika berjalan di atas 30, jendela akan terbuka secara otomatis.
20.6. Rancang arsitektur proses untuk sistem pemantauan lingkungan yang mengumpulkan data dari serangkaian sensor kualitas
udara yang terletak di sekitar kota. Ada 5.000 sensor yang diatur ke dalam 100 lingkungan. Setiap sensor harus diinterogasi
empat kali per detik. Ketika lebih dari 30% sensor di lingkungan tertentu menunjukkan bahwa kualitas udara di bawah
tingkat yang dapat diterima, lampu peringatan lokal diaktifkan. Semua sensor mengembalikan pembacaan ke komputer
pusat, yang menghasilkan laporan setiap 15 menit tentang kualitas udara di kota.
Bab 20 Latihan 563
Sistem perlindungan kereta api
• Sistem memperoleh informasi tentang batas kecepatan segmen dari pemancar trackside, yang
terus-menerus menyiarkan pengenal segmen dan batas kecepatannya. Pemancar yang sama juga menyiarkan informasi
tentang status sinyal yang mengendalikan segmen trek tersebut. Waktu yang diperlukan untuk menyiarkan segmen trek dan
informasi sinyal adalah 50 ms.
• Kereta dapat menerima informasi dari pemancar trackside ketika berada dalam jarak 10 m dari pemancar. • Kecepatan
maksimum kereta api adalah 180 km/jam. • Sensor di kereta memberikan informasi tentang kecepatan kereta saat ini
(diperbarui setiap 250 mdtk) dan kereta
status rem (diperbarui setiap 100 ms).
• Jika kecepatan kereta melebihi batas kecepatan segmen saat ini lebih dari 5 kpj, peringatan akan dibunyikan di kabin pengemudi.
Jika kecepatan kereta melebihi batas kecepatan segmen saat ini lebih dari 10 kpj, rem kereta secara otomatis diterapkan hingga
kecepatan turun ke batas kecepatan segmen. Rem kereta harus diterapkan dalam waktu 100 ms dari waktu ketika kecepatan
kereta yang berlebihan telah terdeteksi.
• Jika kereta memasuki jalur yang ditandai dengan lampu merah, sistem proteksi kereta akan mengerem kereta dan mengurangi
kecepatan hingga nol. Rem kereta api harus diterapkan dalam waktu 100 ms saat sinyal lampu merah diterima. • Sistem terus
memperbarui tampilan status di kabin pengemudi.
Gambar 20.19
Persyaratan untuk sistem
proteksi kereta api
20.7. Sistem proteksi kereta api secara otomatis mengerem kereta api jika batas kecepatan untuk suatu segmen
lintasan terlampaui atau jika kereta api memasuki segmen lintasan yang saat ini ditandai dengan lampu merah
(yaitu, segmen tersebut tidak boleh dimasuki). Detailnya ditunjukkan pada Gambar 20.19.
Identifikasi rangsangan yang harus diproses oleh sistem kontrol kereta di atas kapal dan respons terkait
terhadap rangsangan ini.
20.8. Sarankan kemungkinan arsitektur proses untuk sistem ini.
20.9. Jika proses periodik dalam sistem proteksi kereta di atas kapal digunakan untuk mengumpulkan data dari
pemancar sisi rel, seberapa sering harus dijadwalkan untuk memastikan bahwa sistem dijamin mengumpulkan
informasi dari pemancar? Jelaskan bagaimana Anda sampai di
menjawab.
20.10. Mengapa sistem operasi tujuan umum, seperti Linux atau Windows, tidak cocok sebagai
platform sistem waktu nyata? Gunakan pengalaman Anda menggunakan sistem tujuan umum untuk membantu
menjawab pertanyaan ini.
REFERENSI
Berry, G. (1989). 'Pemrograman waktu nyata: Bahasa tujuan khusus atau tujuan umum'.
Dalam Pengolahan Informasi. Ritter, G. (ed.). Amsterdam: Penerbit Sains Elsevier, 11–17.
Brinch-Hansen, P. (1973). Prinsip Sistem Operasi. Englewood Cliffs, NJ: Prentice-Hall.
Luka bakar, A. dan Wellings, A. (2009). Sistem dan Bahasa Pemrograman Real-Time: Ada, Java Real-
Time dan C/ Real-Time POSIX. Boston: Addison-Wesley.
Pendinginan, J. (2003). Rekayasa Perangkat Lunak untuk Sistem Real-Time. Harlow, Inggris: Addison-Wesley.
Dibble, PC (2008). Pemrograman Platform Java Real-time, edisi ke-2. Charleston, SC:
Penerbitan Booksurge.
Dijkstra, EW (1968). 'Bekerja Sama Proses Sekuensial'. Dalam Bahasa Pemrograman.

Genuys, F. (ed.). London: Academic Press, 43-112.
Douglass, BP (1999). UML Real-Time: Mengembangkan Objek Efisien untuk Sistem Tertanam, edisi
ke-2. Boston: Addison-Wesley.
Douglass, BP (2002). Pola Desain Real-Time: Arsitektur Scalable yang Kuat untuk Real-Time
Sistem. Boston: Addison-Wesley.
Gomaa, H. (1993). Metode Desain Perangkat Lunak untuk Sistem Konkuren dan Real-Time. Membaca,
Massa.: Addison-Wesley.
Harel, D. (1987). 'Statecharts: Sebuah Formalisme Visual untuk Sistem Kompleks'. Sci. Hitung.
Pemrograman, 8 (3), 231–74.
Harel, D. (1988). 'Tentang Formalisme Visual'. Kom. ACM, 31 (5), 514–30.
Hoare, CAR (1974). 'Monitor: konsep penataan sistem operasi'. Kom. ACM, 21 (8), 666–77.
Lee, EA (2002). 'Perangkat Lunak Tertanam'. Dalam Kemajuan Komputer. Zelkowitz, M. (ed.).
London: Pers Akademik.
Silberschatz, A., Galvin, PB dan Gagne, G. (2008). Konsep Sistem Operasi, edisi ke-8.
New York: John Wiley & Sons.
Tanenbaum, AS (2007). Sistem Operasi Modern, edisi ke-3. Englewood Cliffs, NJ: Prentice Hall.
21
Rekayasa perangkat lunak
berorientasi aspek
Tujuan
Tujuan bab ini adalah untuk memperkenalkan Anda pada pengembangan
perangkat lunak berorientasi aspek, yang didasarkan pada pemisahan masalah.
Setelah Anda membaca bab ini, Anda akan:
pahami mengapa pemisahan kekhawatiran adalah prinsip panduan yang baik

untuk pengembangan perangkat lunak;
telah diperkenalkan dengan ide-ide mendasar yang mendasari aspek dan

pengembangan perangkat lunak berorientasi aspek ;
memahami bagaimana pendekatan berorientasi aspek dapat digunakan

untuk rekayasa kebutuhan, desain perangkat lunak, dan pemrograman;
menyadari kesulitan pengujian sistem berorientasi aspek.
Isi
21.1 Pemisahan masalah 21.2 Aspek,
titik gabung, dan titik potong 21.3 Rekayasa
perangkat lunak dengan aspek
566 Bab 21 Rekayasa perangkat lunak berorientasi aspek
Di sebagian besar sistem besar, hubungan antara persyaratan dan program

komponennya kompleks. Persyaratan tunggal dapat diimplementasikan oleh sejumlah
komponen dan setiap komponen dapat mencakup elemen dari beberapa persyaratan.
Dalam praktiknya, ini berarti bahwa penerapan perubahan persyaratan mungkin melibatkan:
memahami dan mengubah beberapa komponen. Atau, sebuah komponen mungkin
menyediakan beberapa fungsionalitas inti tetapi juga menyertakan kode yang mengimplementasikan beberapa sistem
persyaratan. Bahkan ketika tampaknya ada potensi penggunaan kembali yang signifikan, mungkin saja
mahal untuk menggunakan kembali komponen tersebut. Penggunaan kembali mungkin melibatkan modifikasi untuk menghapus
kode tambahan yang tidak terkait dengan fungsionalitas inti komponen.

Rekayasa perangkat lunak berorientasi aspek (AOSE) adalah pendekatan pengembangan perangkat
lunak yang ditujukan untuk mengatasi masalah ini dan dengan demikian membuat program lebih mudah untuk
memelihara dan menggunakan kembali. AOSE didasarkan pada abstraksi yang disebut aspek, yang
mengimplementasikan fungsionalitas sistem yang mungkin diperlukan di beberapa tempat berbeda di a
program. Aspek merangkum fungsionalitas yang saling bersilangan dan hidup berdampingan dengan yang lain
fungsionalitas yang terdapat dalam suatu sistem. Mereka digunakan bersama abstraksi lain seperti objek
dan metode. Program berorientasi aspek yang dapat dieksekusi adalah
dibuat dengan menggabungkan (menenun) objek, metode, dan aspek secara otomatis,
sesuai dengan spesifikasi yang disertakan dalam kode sumber program.
Karakteristik penting dari aspek adalah bahwa mereka memasukkan definisi di mana
mereka harus dimasukkan dalam sebuah program, serta kode yang mengimplementasikan perhatian lintas
sektoral. Anda dapat menentukan bahwa kode lintas sektor harus disertakan
sebelum atau sesudah pemanggilan metode tertentu atau saat atribut diakses. Pada dasarnya,
aspek tersebut dijalin ke dalam program inti untuk membuat sistem augmented baru.
Manfaat utama dari pendekatan berorientasi aspek adalah mendukung pemisahan
kekhawatiran. Seperti yang saya jelaskan di Bagian 21.1, memisahkan masalah menjadi elemen independen
daripada memasukkan masalah yang berbeda dalam abstraksi logis yang sama adalah baik
praktek rekayasa perangkat lunak. Dengan mewakili keprihatinan lintas sektoral sebagai aspek,
kekhawatiran ini dapat dipahami, digunakan kembali, dan dimodifikasi secara independen, tanpa
memperhatikan di mana kode tersebut digunakan. Misalnya, otentikasi pengguna dapat direpresentasikan
sebagai aspek yang meminta nama login dan kata sandi. Ini dapat secara otomatis dijalin ke dalam program
di mana pun otentikasi diperlukan.
Katakanlah Anda memiliki persyaratan bahwa otentikasi pengguna diperlukan sebelum perubahan apa pun
untuk rincian pribadi dibuat dalam database. Anda dapat menjelaskan ini dalam suatu aspek dengan
menyatakan bahwa kode otentikasi harus disertakan sebelum setiap panggilan ke metode yang
memperbarui detail pribadi. Selanjutnya, Anda dapat memperluas persyaratan autentikasi ke semua
pembaruan basis data. Ini dapat dengan mudah diimplementasikan dengan memodifikasi
aspek. Anda cukup mengubah definisi di mana kode otentikasi akan berada
dirangkai ke dalam sistem. Anda tidak perlu mencari melalui sistem untuk mencari semua
kemunculan metode-metode tersebut. Oleh karena itu Anda cenderung membuat kesalahan dan
memperkenalkan kerentanan keamanan yang tidak disengaja ke dalam program Anda.
Penelitian dan pengembangan dalam orientasi aspek terutama difokuskan pada pemrograman
berorientasi aspek. Bahasa pemrograman berorientasi aspek seperti AspectJ
(Colyer dan Clement, 2005; Colyer et al., 2005; Kiczales, et al., 2001; Laddad,
2003a; Laddad, 2003b) telah dikembangkan yang memperluas pemrograman berorientasi objek untuk
memasukkan aspek. Perusahaan besar telah menggunakan pemrograman berorientasi aspek
21.1 Pemisahan kekhawatiran 567
dalam proses produksi perangkat lunak mereka (Colyer dan Clement, 2005). Namun, kekhawatiran
lintas sektor sama-sama bermasalah pada tahap pengembangan perangkat lunak lainnya
proses. Para peneliti sekarang menyelidiki bagaimana memanfaatkan orientasi aspek dalam
rekayasa persyaratan sistem dan desain sistem, dan bagaimana menguji dan memverifikasi
program berorientasi aspek.
Saya telah menyertakan diskusi tentang AOSE di sini karena fokusnya pada pemisahan
masalah adalah cara penting untuk memikirkan dan menyusun sistem perangkat lunak.
Meskipun beberapa sistem skala besar telah diimplementasikan menggunakan berorientasi aspek
pendekatan, penggunaan aspek masih bukan bagian dari rekayasa perangkat lunak arus utama. Sebagai
dengan semua teknologi baru, para pendukung berfokus pada manfaat daripada masalah
dan biaya. Meskipun akan membutuhkan waktu sebelum AOSE secara rutin digunakan bersama
pendekatan lain untuk rekayasa perangkat lunak, gagasan memisahkan kekhawatiran yang
mendasari AOSE adalah penting. Memikirkan pemisahan kekhawatiran adalah pendekatan umum
yang baik untuk rekayasa perangkat lunak.
Di bagian selanjutnya dari bab ini, karena itu saya fokus pada konsep-konsep yang
bagian dari AOSE dan mendiskusikan keuntungan dan kerugian menggunakan pendekatan
berorientasi aspek pada berbagai tahap proses pengembangan perangkat lunak. sebagai saya
tujuannya adalah untuk membantu Anda memahami konsep yang mendasari AOSE, saya tidak membahasnya secara detail
pendekatan khusus atau bahasa pemrograman berorientasi aspek.
21.1 Pemisahan kekhawatiran

Pemisahan masalah adalah prinsip utama desain dan implementasi perangkat lunak.
Ini berarti Anda harus mengatur perangkat lunak Anda sehingga setiap elemen dalam program
(kelas, metode, prosedur, dll.) melakukan satu hal dan hanya satu hal. Anda kemudian bisa
fokus pada elemen itu tanpa memperhatikan elemen lain dalam program. Kamu bisa
memahami setiap bagian dari program dengan mengetahui perhatiannya, tanpa perlu
memahami elemen lainnya. Ketika perubahan diperlukan, mereka dilokalisasi ke small
jumlah elemen.
Pentingnya memisahkan kekhawatiran diakui pada tahap awal di
sejarah ilmu komputer. Subrutin, yang merangkum unit fungsionalitas,
ditemukan pada awal 1950-an dan mekanisme penataan program berikutnya
seperti prosedur dan kelas objek telah dirancang untuk menyediakan mekanisme yang lebih baik
untuk mewujudkan pemisahan masalah. Namun, semua mekanisme ini
memiliki masalah dalam menangani jenis kekhawatiran tertentu yang melintasi masalah lain.
Kekhawatiran lintas sektor ini tidak dapat dilokalisasi menggunakan mekanisme penataan seperti
objek atau fungsi. Aspek telah ditemukan untuk membantu mengelola ini
keprihatinan lintas sektor.
Meskipun secara umum disepakati bahwa memisahkan kekhawatiran adalah praktik rekayasa
perangkat lunak yang baik, lebih sulit untuk menjelaskan apa yang sebenarnya dimaksud dengan kekhawatiran. Kadang-kadang
itu didefinisikan sebagai gagasan fungsional (yaitu, perhatian adalah beberapa elemen fungsionalitas di
sebuah sistem). Atau, itu dapat didefinisikan secara luas sebagai 'setiap bagian dari kepentingan atau'
fokus dalam sebuah program'. Tak satu pun dari definisi ini sangat berguna dalam praktik.
Kekhawatiran tentu saja lebih dari sekadar elemen fungsional tetapi definisi yang lebih umum
sangat kabur sehingga praktis tidak berguna.
Dalam pandangan saya, sebagian besar upaya untuk mendefinisikan masalah bermasalah
karena mereka mencoba menghubungkan masalah dengan program. Faktanya, seperti yang
dibahas oleh Jacobson dan Ng (2004), kekhawatiran sebenarnya merupakan cerminan dari
persyaratan sistem dan prioritas pemangku kepentingan dalam sistem. Performa sistem
mungkin menjadi perhatian karena pengguna ingin mendapatkan respons yang cepat dari suatu
sistem; beberapa pemangku kepentingan mungkin khawatir bahwa sistem harus mencakup
fungsionalitas tertentu; perusahaan yang mendukung sistem mungkin khawatir bahwa itu
mudah dipelihara. Oleh karena itu, perhatian dapat didefinisikan sebagai sesuatu yang menarik
atau penting bagi pemangku kepentingan atau sekelompok pemangku kepentingan.
Jika Anda menganggap masalah sebagai cara mengatur persyaratan, Anda dapat melihat
mengapa pendekatan implementasi yang memisahkan masalah menjadi elemen program yang
berbeda adalah praktik yang baik. Lebih mudah untuk melacak masalah, yang dinyatakan
sebagai persyaratan atau serangkaian persyaratan terkait, ke komponen program yang
mengimplementasikan masalah ini. Jika persyaratan berubah, maka bagian program yang harus diubah sudah jelas.
Ada beberapa jenis perhatian pemangku kepentingan:
1. Kekhawatiran fungsional, yang terkait dengan fungsionalitas spesifik yang akan dimasukkan
dalam suatu sistem. Misalnya, dalam sistem kontrol kereta api, perhatian fungsional
khusus adalah pengereman kereta api.
2. Kualitas layanan, yang terkait dengan perilaku non-fungsional dari suatu sistem. Ini termasuk
karakteristik seperti kinerja, keandalan, dan ketersediaan.
3. Policy concern, yang berkaitan dengan keseluruhan kebijakan yang mengatur penggunaan
suatu sistem. Kekhawatiran kebijakan mencakup masalah keamanan dan keselamatan
serta masalah yang terkait dengan aturan bisnis.
4. Kekhawatiran sistem, yang terkait dengan atribut sistem secara keseluruhan, seperti:
sebagai rawatan atau konfigurasinya.
5. Keprihatinan organisasi, yang terkait dengan tujuan dan prioritas organisasi. Ini termasuk
memproduksi sistem sesuai anggaran, memanfaatkan aset perangkat lunak yang ada, dan
menjaga reputasi organisasi.
Perhatian inti dari suatu sistem adalah perhatian fungsional yang berhubungan dengan
tujuan utamanya. Oleh karena itu, untuk sistem informasi pasien rumah sakit, perhatian
fungsional inti adalah pembuatan, pengeditan, pengambilan, dan pengelolaan catatan pasien.
Selain masalah inti, sistem besar juga memiliki masalah fungsional sekunder.
Ini mungkin melibatkan fungsionalitas yang berbagi informasi dengan masalah inti, atau yang
diperlukan agar sistem dapat memenuhi persyaratan non-fungsionalnya.
Misalnya, pertimbangkan sistem yang memiliki persyaratan untuk menyediakan akses
bersamaan ke buffer bersama. Satu proses menambahkan data ke buffer dan proses lainnya
21.1 Pemisahan kekhawatiran 569
Pelanggan
Pelanggan baru Akun Pengelolaan
Persyaratan Persyaratan Persyaratan
lintas sektor
Kekhawatiran
Persyaratan Keamanan
Persyaratan Pemulihan
Gambar 21.1
Masalah lintas sektoral Kekhawatiran Inti
mengambil data dari buffer yang sama. Buffer bersama ini merupakan bagian dari sistem
akuisisi data dimana proses produsen memasukkan data ke dalam buffer dan proses
konsumen mengambil data dari buffer. Perhatian inti di sini adalah untuk mempertahankan buffer bersama sehingga
fungsionalitas dikaitkan dengan menambahkan dan menghapus elemen dari buffer.
Namun, untuk memastikan bahwa proses produsen dan konsumen tidak saling mengganggu,
ada perhatian sekunder yang penting dari sinkronisasi. Sistem harus dirancang agar proses
produsen tidak dapat menimpa data yang belum dikonsumsi dan proses konsumen tidak
dapat mengambil data dari buffer kosong.
Selain masalah sekunder ini, masalah lain seperti kualitas layanan dan kebijakan
organisasi mencerminkan persyaratan sistem yang penting. Secara umum, ini adalah
masalah sistem — mereka berlaku untuk sistem secara keseluruhan daripada persyaratan
individu atau realisasi persyaratan ini dalam suatu program. Ini disebut masalah lintas
sektor untuk membedakannya dari masalah inti. Kekhawatiran fungsional sekunder mungkin
juga lintas sektoral meskipun tidak selalu memotong seluruh sistem; melainkan, mereka
terkait dengan pengelompokan masalah inti yang menyediakan fungsionalitas terkait.
Kekhawatiran lintas sektor ditunjukkan pada Gambar 21.1, yang didasarkan pada contoh
sistem perbankan Internet. Sistem ini memiliki persyaratan yang berkaitan dengan pelanggan
baru seperti pengecekan kredit dan verifikasi alamat. Ini juga memiliki persyaratan terkait
dengan pengelolaan pelanggan yang ada dan pengelolaan akun pelanggan. Semua ini
adalah perhatian utama yang terkait dengan tujuan utama sistem—penyediaan layanan
perbankan Internet. Namun, sistem juga memiliki persyaratan keamanan berdasarkan
kebijakan keamanan bank, dan persyaratan pemulihan untuk memastikan bahwa data tidak
hilang jika terjadi kegagalan sistem. Ini adalah masalah lintas sektoral karena dapat
mempengaruhi implementasi semua persyaratan sistem lainnya.
Abstraksi bahasa pemrograman, seperti prosedur dan kelas, adalah mekanisme yang
biasanya Anda gunakan untuk mengatur dan menyusun masalah inti dari suatu sistem.
Namun, implementasi perhatian utama dalam bahasa pemrograman konvensional biasanya
mencakup kode tambahan untuk mengimplementasikan masalah lintas sektoral, fungsional,
kualitas layanan, dan kebijakan. Hal ini menyebabkan dua fenomena yang tidak diinginkan:
kusut dan hamburan.
disinkronkan void put (SensorRecord rec ) {
// Periksa apakah ada ruang di buffer; tunggu jika tidak

if ( numberOfEntries == bufsize)
tunggu () ;
// Tambahkan record di akhir buffer
simpan [kembali] = SensorRecord baru (rec.sensorId, rec.sensorVal) ;
kembali = kembali + 1 ;
// Jika di akhir buffer, entri berikutnya ada di awal
if (kembali == ukuran buf)
kembali = 0 ;
numberOfEntries = jumlahEntries + 1 ;
// menunjukkan bahwa buffer tersedia
memberitahukan () ;
} // taruh
Kekusutan terjadi ketika modul dalam sistem menyertakan kode yang mengimplementasikan
Gambar 21.2 Kekusutan
kebutuhan sistem yang berbeda. Contoh pada Gambar 21.2, yang disederhanakan
manajemen buffer
dan sinkronisasi implementasi bagian dari kode untuk sistem buffer terbatas, menggambarkan fenomena
kode ini. Gambar 21.2 adalah implementasi dari operasi put yang menambahkan item
untuk buffernya. Namun, jika buffer penuh, ia harus menunggu hingga get . yang sesuai
operasi menghapus item dari buffer. Detailnya tidak penting; dasarnya
panggilan wait () dan notify () digunakan untuk menyinkronkan operasi put dan get. Itu
kode yang mendukung perhatian utama (dalam hal ini, memasukkan catatan ke dalam buffer),
kusut dengan kode yang mengimplementasikan sinkronisasi. Kode sinkronisasi, yaitu
terkait dengan perhatian sekunder untuk memastikan pengucilan bersama, harus
termasuk dalam semua metode yang mengakses buffer bersama. Kode yang terkait dengan
masalah sinkronisasi ditampilkan sebagai kode berbayang pada Gambar 21.2.
Fenomena hamburan terkait terjadi ketika implementasi satu perhatian (persyaratan
logis atau serangkaian persyaratan) tersebar di beberapa
komponen dalam sebuah program. Hal ini mungkin terjadi ketika persyaratan yang terkait
dengan masalah fungsional sekunder atau masalah kebijakan diimplementasikan.
Misalnya, sistem manajemen rekam medis, seperti MHC-PMS,
memiliki sejumlah komponen yang berkaitan dengan pengelolaan informasi pribadi,
pengobatan, konsultasi, citra medis, diagnosis, dan perawatan. Alat ini
perhatian utama dari sistem: memelihara catatan pasien. Sistemnya bisa
dikonfigurasi untuk berbagai jenis klinik dengan memilih komponen yang menyediakan
fungsi yang dibutuhkan untuk klinik.
Namun, asumsikan juga ada perhatian sekunder penting yang merupakan tujuan utama
dari informasi statistik; penyedia kode kesehatan ingin mencatat detail dari
berapa banyak pasien yang masuk dan keluar setiap bulan, berapa banyak pasien?
meninggal, obat apa yang dikeluarkan, alasan konsultasi, dan sebagainya. Ini
persyaratan harus diimplementasikan dengan menambahkan kode yang menganonimkan
data (untuk menjaga privasi pasien) dan menulisnya ke database statistik. Komponen
statistik memproses data statistik dan menghasilkan laporan statistik yang diperlukan.
21.2 Aspek , titik gabung, dan titik potong 571
Pasien Gambar Konsultasi
<attribute decls> <attribute decls> <attribute decls>
getName() getModality () makeAppoint ()

editName() arsip () getDate cancelAppoint ()
getAddress() () editDate () assignNurse ()
editAddress() bookEquip ()
... ... ...
Gambar 21.3 Penyebaran
metode yang menerapkan menganonimkan () simpanDiagnosis() menganonimkan ()
... simpanTipe() simpan Konsultasikan ()
masalah sekunder
... ...
Hal ini diilustrasikan pada Gambar 21.3. Diagram ini menunjukkan contoh tiga kelas yang
mungkin disertakan dalam sistem catatan pasien bersama dengan beberapa metode inti untuk
mengelola informasi pasien. Area yang diarsir menunjukkan metode yang diperlukan untuk
mengimplementasikan perhatian statistik sekunder. Anda dapat melihat bahwa perhatian statistik
ini tersebar di seluruh perhatian utama lainnya.
Masalah dengan hamburan dan kusut terjadi ketika persyaratan sistem awal berubah.
Misalnya, katakanlah data statistik baru harus dikumpulkan dalam sistem catatan pasien.
Perubahan pada sistem tidak semuanya terletak di satu tempat sehingga Anda harus
menghabiskan waktu mencari komponen dalam sistem yang harus diubah. Anda kemudian
harus mengubah masing-masing komponen ini untuk memasukkan perubahan yang diperlukan.
Ini mungkin mahal karena waktu yang dibutuhkan untuk menganalisis komponen dan kemudian
membuat dan menguji perubahan. Selalu ada kemungkinan bahwa Anda akan kehilangan
beberapa kode yang harus diubah sehingga statistiknya akan salah.
Selain itu, karena beberapa perubahan harus dilakukan, ini meningkatkan kemungkinan Anda
akan membuat kesalahan dan memasukkan kesalahan ke dalam perangkat lunak.
21.2 Aspek, gabung poin, dan pointcuts
Di bagian ini, saya memperkenalkan konsep baru yang paling penting yang terkait dengan
pengembangan perangkat lunak berorientasi aspek dan menggambarkannya menggunakan
contoh dari MHC PMS. Terminologi yang saya gunakan diperkenalkan oleh pengembang AspectJ
pada akhir 1990-an. Namun, konsep tersebut secara umum dapat diterapkan dan tidak spesifik
untuk bahasa pemrograman AspectJ. Gambar 21.4 merangkum istilah-istilah kunci yang perlu
Anda pahami.
Sistem rekam medis seperti MHC-PMS mencakup komponen yang menangani informasi
pasien yang terkait secara logis. Komponen pasien menyimpan informasi pribadi tentang pasien,
komponen obat menyimpan informasi tentang obat yang mungkin diresepkan, dan seterusnya.
Dengan merancang sistem menggunakan pendekatan berbasis komponen, berbagai instansiasi
sistem dapat dikonfigurasi. Misalnya, versi dapat dikonfigurasi untuk setiap jenis klinik dengan
dokter hanya diperbolehkan untuk meresepkan
Ketentuan Definisi
nasihat Kode yang menerapkan kekhawatiran.
aspek Sebuah abstraksi program yang mendefinisikan perhatian lintas sektoral.

Ini mencakup definisi pointcut dan saran yang terkait dengan
masalah itu.
titik bergabung Suatu peristiwa dalam program yang dijalankan di mana saran
yang terkait dengan suatu aspek dapat dieksekusi.
bergabung dengan model titik Himpunan peristiwa yang dapat direferensikan dalam sebuah pointcut.
titik potong Sebuah pernyataan, termasuk dalam sebuah aspek, yang

mendefinisikan titik gabung di mana saran aspek terkait harus
dijalankan.
Gambar 21.4
Terminologi yang menenun Penggabungan kode saran pada titik gabung yang ditentukan
digunakan dalam rekayasa oleh penenun aspek.
perangkat lunak berorientasi aspek
obat yang relevan dengan klinik itu. Ini menyederhanakan pekerjaan staf klinis dan
mengurangi kemungkinan dokter salah meresepkan obat yang salah.
Namun, organisasi ini berarti bahwa informasi dalam database harus diperbarui dari
sejumlah tempat berbeda dalam sistem. Sebagai contoh, informasi pasien dapat dimodifikasi
ketika informasi pribadi mereka berubah, ketika obat yang ditugaskan berubah, ketika
mereka ditugaskan ke spesialis baru, dll. Untuk kesederhanaan, asumsikan bahwa semua
komponen dalam sistem menggunakan strategi penamaan yang konsisten dan bahwa semua
pembaruan basis data diimplementasikan dengan metode yang dimulai dengan 'pembaruan'.
Oleh karena itu ada metode dalam sistem seperti:
updatePersonalInformation (patientId, infoupdate)
updateMedication (patientId, medicineupdate)
Pasien diidentifikasi oleh patientId dan perubahan yang akan dibuat dikodekan dalam
parameter kedua; rincian pengkodean ini tidak penting untuk contoh ini.
Pembaruan dilakukan oleh staf rumah sakit, yang masuk ke sistem.
Bayangkan bahwa pelanggaran keamanan terjadi di mana informasi pasien diubah
dengan jahat. Mungkin seseorang secara tidak sengaja membiarkan komputernya masuk
dan orang yang tidak berwenang telah mendapatkan akses ke sistem. Atau, orang dalam
yang berwenang mungkin telah memperoleh akses dan dengan jahat mengubah informasi
pasien. Untuk mengurangi kemungkinan hal ini terjadi lagi, kebijakan keamanan baru diperkenalkan.
Sebelum perubahan apa pun pada database pasien dibuat, orang yang meminta perubahan
harus mengautentikasi ulang dirinya sendiri ke sistem. Rincian siapa yang membuat
perubahan juga dicatat dalam file terpisah. Ini membantu melacak masalah jika muncul kembali.
Salah satu cara penerapan kebijakan baru ini adalah dengan memodifikasi metode update
di setiap komponen untuk memanggil metode lain untuk melakukan autentikasi dan logging. Kalau tidak,
otentikasi aspek {
sebelum: call (public void update* (..)) // ini adalah sebuah pointcut {
// ini adalah saran yang harus dijalankan saat dijalin ke // sistem yang mengeksekusi int try = 0 ; string
userPassword = Password.Get (mencoba); while (mencoba < 3 && userPassword != thisUser.password
()){
// izinkan 3 percobaan untuk mendapatkan kata sandi yang

benar percobaan = percobaan; + 1 userPassword = Kata
sandi.Dapatkan ( percobaan);
} jika (userPassword != thisUser.password ( )) maka

//jika password salah, anggap user lupa logout System.Logout (thisUser.uid) ;
} } // autentikasi
sistem dapat dimodifikasi sehingga setiap kali metode pembaruan dipanggil, panggilan metode
Gambar 21.5
ditambahkan sebelum panggilan untuk melakukan otentikasi, dan kemudian setelah mencatat
Aspek otentikasi
perubahan yang dibuat. Namun, tidak satu pun dari ini adalah solusi yang sangat baik untuk masalah ini:
1. Pendekatan pertama mengarah pada implementasi yang kusut. Logikanya, memperbarui

database, mengautentikasi pencetus pembaruan, dan mencatat detail pembaruan adalah
masalah yang terpisah dan tidak terkait. Anda mungkin ingin memasukkan autentikasi di
tempat lain dalam sistem tanpa mencatat atau mungkin ingin mencatat tindakan selain
dari tindakan pembaruan. Otentikasi dan kode logging yang sama harus disertakan dalam
beberapa metode berbeda.
2. Pendekatan alternatif mengarah pada implementasi yang tersebar. Jika Anda secara
eksplisit menyertakan panggilan metode untuk melakukan autentikasi dan pencatatan
sebelum dan sesudah setiap panggilan ke metode pembaruan, maka kode ini disertakan
di beberapa tempat berbeda dalam sistem.
Otentikasi dan logging memotong masalah inti dari sistem dan mungkin harus dimasukkan
di beberapa tempat yang berbeda. Dalam sistem berorientasi aspek, Anda dapat mewakili
masalah lintas sektoral ini sebagai aspek terpisah. Sebuah aspek mencakup spesifikasi di
mana perhatian lintas sektor harus dijalin ke dalam program, dan kode untuk
mengimplementasikan perhatian itu. Ini diilustrasikan pada Gambar 21.5, yang mendefinisikan
aspek otentikasi. Notasi yang saya gunakan dalam contoh ini mengikuti gaya AspectJ tetapi
menggunakan sintaks yang disederhanakan, yang seharusnya dapat dipahami tanpa
pengetahuan tentang Java atau AspectJ.
Aspek benar-benar berbeda dari abstraksi program lain dalam aspek itu sendiri mencakup
spesifikasi di mana harus dieksekusi. Dengan yang lain
abstraksi, seperti metode, ada pemisahan yang jelas antara definisi abstraksi dan
penggunaannya. Anda tidak dapat mengetahuinya dengan memeriksa metode dari mana ia
akan dipanggil; panggilan bisa dari mana saja di mana metode berada dalam ruang lingkup.
Aspek, sebaliknya, menyertakan 'pointcut'—pernyataan yang menentukan di mana aspek
akan dijalin ke dalam program.
Dalam contoh ini, pointcut adalah pernyataan sederhana:
sebelum: panggilan (pembaruan batal publik* (..))
Artinya adalah sebelum eksekusi metode apa pun yang namanya dimulai dengan
pembaruan string, diikuti oleh urutan karakter lainnya, kode dalam aspek setelah definisi
pointcut harus dieksekusi. Karakter * disebut wildcard dan cocok dengan karakter string apa
pun yang diizinkan dalam pengidentifikasi. Kode yang akan dieksekusi dikenal sebagai
'nasihat' dan merupakan implementasi dari perhatian lintas sektoral. Dalam hal ini, saran
mendapatkan kata sandi dari orang yang meminta perubahan dan memeriksa apakah itu
cocok dengan kata sandi pengguna yang saat ini masuk.
Jika tidak, pengguna akan keluar dan pembaruan tidak dilanjutkan.
Kemampuan untuk menentukan, menggunakan pointcuts, di mana kode harus dieksekusi
adalah karakteristik yang membedakan aspek. Namun, untuk memahami apa arti titik potong,
Anda perlu memahami konsep lain—ide titik gabung. Titik gabung adalah peristiwa yang
terjadi selama eksekusi suatu program; jadi, itu bisa berupa pemanggilan metode, inisialisasi
variabel, pembaruan bidang, dll.
Ada banyak kemungkinan jenis kejadian yang mungkin terjadi selama eksekusi program.
Sebuah model titik bergabung mendefinisikan set peristiwa yang dapat direferensikan dalam
program berorientasi aspek. Model titik bergabung tidak distandarisasi dan setiap bahasa
pemrograman berorientasi aspek memiliki model titik gabungnya sendiri. Misalnya, dalam
peristiwa AspectJ yang merupakan bagian dari model titik gabungan meliputi:
panggilan peristiwa—panggilan ke metode atau konstruktor;
acara eksekusi—eksekusi metode atau konstruktor;
peristiwa inisialisasi—inisialisasi kelas atau objek;
peristiwa data—mengakses atau memperbarui bidang;
peristiwa pengecualian—penanganan pengecualian.
Pointcut mengidentifikasi peristiwa tertentu (misalnya, panggilan ke prosedur bernama)

dengan saran yang harus dikaitkan. Ini berarti bahwa Anda dapat menenun saran ke dalam
program dalam banyak konteks berbeda, tergantung pada model titik gabung yang didukung:
1. Saran dapat dimasukkan sebelum eksekusi metode tertentu, daftar metode bernama, atau
daftar metode yang namanya cocok dengan spesifikasi pola (seperti update*).
Aspek Otentikasi Pasien

...
pembaruan kode
Aspek Pencatatan Aspek Weaver otentikasiDetail (...)
kode logging
...
Pasien
...
perbaruiDetail (...)
...
Gambar 21.6 Aspek
menenun
2. Saran dapat dimasukkan setelah pengembalian normal atau luar biasa dari suatu metode.
Dalam contoh yang ditunjukkan pada Gambar 21.5, Anda dapat menentukan sebuah titik potong yang
akan mengeksekusi kode logging setelah semua panggilan untuk memperbarui metode.
3. Saran dapat dimasukkan ketika bidang dalam suatu objek dimodifikasi; Anda dapat
menyertakan saran untuk memantau atau mengubah bidang itu.
Pencantuman saran pada titik sambung yang ditentukan dalam titik potong merupakan
tanggung jawab penenun aspek. Penenun aspek adalah ekstensi untuk kompiler yang
memproses definisi aspek dan kelas objek serta metode yang mendefinisikan sistem.
Penenun kemudian membuat program baru dengan aspek-aspek yang disertakan pada titik
gabung yang ditentukan. Aspek-aspek tersebut terintegrasi sehingga masalah lintas sektoral
dijalankan di tempat yang tepat dalam sistem akhir.
Gambar 21.6 mengilustrasikan penenunan aspek ini untuk otentikasi dan aspek logging yang
harus dimasukkan dalam MHC-PMS. Ada tiga pendekatan berbeda untuk menenun aspek:
1. Pra-pemrosesan kode sumber, di mana seorang penenun mengambil input kode sumber dan
menghasilkan kode sumber baru dalam bahasa seperti Java atau C++, yang kemudian
dapat dikompilasi menggunakan kompiler bahasa standar. Pendekatan ini telah diadopsi
untuk bahasa AspectX dengan XWeaver yang terkait (Birrer et al., 2005).
2. Tautan penenunan waktu, di mana kompiler dimodifikasi untuk memasukkan penenun aspek.
Bahasa berorientasi aspek seperti AspectJ diproses dan bytecode Java standar dihasilkan.
Ini kemudian dapat dieksekusi langsung oleh juru bahasa Java atau diproses lebih lanjut
untuk menghasilkan kode mesin asli.
3. Tenun dinamis pada waktu pelaksanaan. Dalam hal ini, titik bergabung dimonitor dan ketika
suatu peristiwa yang direferensikan dalam pointcut terjadi, saran yang sesuai diintegrasikan
dengan program pelaksana.
Pendekatan yang paling umum digunakan untuk menenun aspek adalah menenun waktu
tautan, karena ini memungkinkan implementasi aspek yang efisien tanpa overhead run-time yang besar.
Tenun dinamis adalah pendekatan yang paling fleksibel tetapi dapat menimbulkan penalti kinerja
yang signifikan selama eksekusi program. Pra-pemrosesan kode sumber sekarang jarang digunakan.
21.3 Rekayasa perangkat lunak dengan aspek
Aspek awalnya diperkenalkan sebagai konstruksi bahasa pemrograman tetapi, seperti yang telah
saya diskusikan, gagasan keprihatinan adalah salah satu yang benar-benar berasal dari persyaratan
sistem. Oleh karena itu, masuk akal untuk mengadopsi pendekatan berorientasi aspek di semua
tahap proses pengembangan sistem. Pada tahap awal rekayasa perangkat lunak, mengadopsi
pendekatan berorientasi aspek berarti menggunakan gagasan memisahkan masalah sebagai dasar
untuk memikirkan persyaratan dan desain sistem.
Mengidentifikasi dan memodelkan masalah harus menjadi bagian dari proses rekayasa dan desain
persyaratan. Bahasa pemrograman berorientasi aspek kemudian memberikan dukungan teknologi
untuk menjaga pemisahan masalah dalam implementasi sistem Anda.
Saat merancang sebuah sistem, Jacobson dan Ng (2004) menyarankan bahwa Anda harus
memikirkan sistem yang mendukung kepentingan pemangku kepentingan yang berbeda sebagai sistem inti plus ekstensi.
Saya telah mengilustrasikan ini pada Gambar 21.7, di mana saya telah menggunakan paket UML
untuk mewakili inti dan ekstensi. Sistem inti adalah seperangkat fitur sistem yang mengimplementasikan
tujuan penting dari suatu sistem. Oleh karena itu, jika tujuan sistem tertentu adalah untuk memelihara
informasi pasien di rumah sakit, maka sistem inti menyediakan sarana untuk membuat, mengedit,
mengelola, dan mengakses database catatan pasien. Perluasan ke sistem inti mencerminkan
kekhawatiran pemangku kepentingan tambahan, yang harus diintegrasikan dengan sistem inti.
Misalnya, penting bahwa sistem informasi medis menjaga kerahasiaan informasi pasien, sehingga
satu ekstensi mungkin berkaitan dengan kontrol akses, yang lain dengan enkripsi, dll.
Ada beberapa jenis ekstensi yang berbeda yang berasal dari berbagai jenis perhatian yang saya
bahas di Bagian 21.1.
1. Ekstensi fungsional sekunder Ini menambah kemampuan tambahan untuk fungsi yang disediakan
dalam sistem inti. Misalnya, dengan menggunakan contoh PMS MHC, pembuatan laporan
tentang obat yang diresepkan pada bulan sebelumnya akan menjadi perluasan fungsional
sekunder ke sistem informasi pasien.
2. Ekstensi kebijakan Ini menambah kemampuan fungsional untuk mendukung kebijakan organisasi.
Ekstensi yang menambahkan fitur keamanan adalah contoh ekstensi kebijakan.
3. Ekstensi QoS Ini menambah kemampuan fungsional untuk membantu mencapai kualitas
persyaratan layanan yang telah ditentukan untuk sistem. Misalnya, ekstensi mungkin
menerapkan cache untuk mengurangi jumlah akses database atau pencadangan otomatis untuk
pemulihan jika terjadi kegagalan sistem.
4. Ekstensi infrastruktur Ekstensi ini menambahkan kemampuan fungsional untuk mendukung

implementasi suatu sistem pada beberapa platform implementasi tertentu. Misalnya, dalam
sistem informasi pasien, perluasan infrastruktur dapat digunakan untuk mengimplementasikan
antarmuka ke sistem manajemen basis data yang mendasarinya.
Perubahan pada antarmuka ini dapat dilakukan dengan memodifikasi ekstensi infrastruktur
terkait.
21.3 Rekayasa perangkat lunak dengan aspek 577
Ekstensi 1 Ekstensi 2 Ekstensi 3
Sistem Inti
Gambar 21.7 Ekstensi 4 Ekstensi 5 Ekstensi 6

Sistem inti dengan ekstensi
Ekstensi selalu menambahkan beberapa jenis fungsi atau fitur tambahan ke

sistem inti. Aspek adalah cara untuk mengimplementasikan ekstensi ini dan mereka dapat
dikomposisikan dengan fungsionalitas sistem inti menggunakan fasilitas tenun di lingkungan
pemrograman berorientasi aspek.
21.3.1 Rekayasa persyaratan berorientasi perhatian

Seperti yang saya sarankan di Bagian 21.1, kekhawatiran mencerminkan persyaratan pemangku kepentingan.
Kekhawatiran ini mungkin mencerminkan fungsionalitas yang dibutuhkan oleh pemangku kepentingan, kualitas
layanan sistem, kebijakan organisasi, atau masalah yang terkait dengan atribut
sistem secara keseluruhan. Oleh karena itu masuk akal untuk mengadopsi pendekatan terhadap persyaratan
rekayasa yang mengidentifikasi dan menentukan keprihatinan pemangku kepentingan yang berbeda. Syarat
'aspek awal' kadang-kadang digunakan untuk merujuk pada penggunaan aspek pada tahap awal dalam
siklus hidup perangkat lunak di mana pemisahan masalah ditekankan.
Pentingnya memisahkan kekhawatiran selama rekayasa persyaratan telah
diakui selama bertahun-tahun. Sudut pandang yang mewakili perspektif sistem yang berbeda
telah dimasukkan ke dalam sejumlah metode rekayasa persyaratan
(Easterbrook dan Nuseibeh, 1996; Finkelstein et al., 1992; Kotonya dan Sommerville,
1996). Metode-metode ini memisahkan keprihatinan para pemangku kepentingan yang berbeda. Sudut pandang
mencerminkan fungsionalitas berbeda yang dibutuhkan oleh kelompok pemangku kepentingan yang berbeda.
Namun, ada juga persyaratan yang memotong semua sudut pandang, seperti yang ditunjukkan pada
Gambar 21.8. Diagram ini menunjukkan bahwa sudut pandang mungkin dari jenis yang berbeda tetapi
kekhawatiran lintas sektor (seperti regulasi, ketergantungan, dan keamanan) menghasilkan
persyaratan yang mungkin berdampak pada semua sudut pandang sistem. Ini adalah yang utama
pertimbangan dalam pekerjaan yang saya lakukan dalam pengembangan metode PreView
(Sommerville dan Sawyer, 1997; Sommerville et al., 1998), yang mencakup langkah-langkah untuk
mengidentifikasi lintas sektoral, masalah non-fungsional.
Untuk mengembangkan sistem yang diatur dalam gaya yang ditunjukkan pada Gambar 21.7, Anda
harus mengidentifikasi persyaratan untuk sistem inti ditambah persyaratan untuk ekstensi sistem.
Pendekatan berorientasi sudut pandang untuk rekayasa persyaratan, di mana:
setiap sudut pandang mewakili persyaratan kelompok pemangku kepentingan terkait, adalah satu
Sudut pandang Kekhawatiran
Peralatan
Pengguna
Manajer SISTEM
Organisasi
Masyarakat
Gambar 21.8 Sudut Pandang

dan Kekhawatiran Peraturan Keandalan Keamanan
cara untuk memisahkan masalah inti dan sekunder. Jika Anda mengatur persyaratan
menurut sudut pandang pemangku kepentingan, Anda kemudian dapat menganalisisnya
untuk menemukan persyaratan terkait yang muncul di semua atau sebagian besar sudut
pandang. Ini mewakili fungsionalitas inti dari sistem. Persyaratan sudut pandang lain
mungkin persyaratan yang khusus untuk sudut pandang itu. Ini dapat diimplementasikan
sebagai ekstensi ke fungsionalitas inti.
Misalnya, bayangkan Anda sedang mengembangkan sistem perangkat lunak untuk
melacak peralatan khusus yang digunakan oleh layanan darurat. Peralatan terletak di
tempat yang berbeda di seluruh wilayah atau negara bagian dan, dalam keadaan darurat
seperti banjir atau gempa bumi, layanan darurat menggunakan sistem untuk menemukan
peralatan apa yang tersedia di dekat lokasi masalah. Gambar 21.9 menunjukkan garis
besar persyaratan dari tiga sudut pandang yang mungkin untuk sistem seperti itu.
Anda dapat melihat dari contoh ini bahwa pemangku kepentingan dari semua sudut
pandang yang berbeda harus dapat menemukan item peralatan tertentu, menelusuri
peralatan yang tersedia di setiap lokasi, dan check in/check out peralatan dari toko. Oleh
karena itu, ini adalah persyaratan untuk sistem inti. Persyaratan sekunder mendukung
kebutuhan yang lebih spesifik dari setiap sudut pandang. Ada persyaratan sekunder
untuk ekstensi sistem yang mendukung penggunaan, pengelolaan, dan pemeliharaan peralatan.
Persyaratan fungsional sekunder yang diidentifikasi dari satu sudut pandang tidak,
tentu saja, memotong persyaratan dari sudut pandang lain. Misalnya, hanya sudut
pandang pemeliharaan yang tertarik untuk menyelesaikan catatan pemeliharaan.
Persyaratan ini mencerminkan kebutuhan sudut pandang itu dan kekhawatiran itu
mungkin tidak dibagikan dengan sudut pandang lain. Selain persyaratan fungsional
sekunder, bagaimanapun, ada masalah lintas sektoral yang menghasilkan persyaratan
penting untuk beberapa atau semua sudut pandang. Ini sering mencerminkan kebijakan
dan kualitas persyaratan layanan yang berlaku untuk sistem secara keseluruhan. Seperti
yang saya bahas di Bab 4, ini adalah persyaratan non-fungsional seperti persyaratan
untuk keamanan, kinerja, dan biaya.
Dalam sistem persediaan peralatan, contoh perhatian lintas sektoral adalah
ketersediaan sistem. Keadaan darurat dapat terjadi dengan sedikit atau tanpa peringatan.
Menyelamatkan nyawa mungkin memerlukan peralatan penting untuk dikerahkan secepat mungkin. Oleh karena itu
1. Pengguna layanan darurat 1.1

Menemukan jenis peralatan tertentu (misalnya, alat angkat berat)
1.2 Melihat peralatan yang tersedia di toko tertentu 1.3
Peralatan check-out 1.4 Peralatan check-in 1.5 Mengatur
peralatan yang akan diangkut ke keadaan darurat 1.6
Menyerahkan laporan kerusakan 1.7 Menemukan toko yang
dekat dengan keadaan darurat
2. Perencana darurat 2.1

Menemukan jenis peralatan tertentu 2.2
Melihat peralatan yang tersedia di lokasi tertentu 2.3
Peralatan check in/check out dari toko 2.4 Memindahkan
peralatan dari satu toko ke toko lain 2.6 Memesan peralatan
baru
3. Staf pemeliharaan
3.1 Check in/check out peralatan untuk pemeliharaan 3.2

Melihat peralatan yang tersedia di setiap toko 3.3
Menemukan jenis peralatan yang ditentukan 3.4 Melihat
jadwal perawatan untuk item peralatan 3.5 Menyelesaikan
catatan perawatan untuk item peralatan 3.6 Menampilkan semua
item di toko yang memerlukan perawatan
persyaratan ketergantungan untuk sistem inventaris peralatan mencakup persyaratan untuk

Gambar 21.9
tingkat ketersediaan sistem yang tinggi. Beberapa contoh dari persyaratan ketergantungan
Sudut pandang
pada sistem inventaris ini, dengan alasan terkait, ditunjukkan pada Gambar 21.10. Dengan menggunakan persyaratan
peralatan ini, Anda kemudian dapat mengidentifikasi ekstensi ke fungsionalitas inti untuk pencatatan
transaksi dan pelaporan status. Ini membuatnya lebih mudah untuk mengidentifikasi masalah dan beralih ke sistem c
Hasil dari proses rekayasa persyaratan harus menjadi seperangkat persyaratan yang
terstruktur di sekitar gagasan sistem inti ditambah ekstensi. Misalnya, dalam sistem
Gambar 21.10 inventaris, contoh persyaratan inti mungkin:
Persyaratan terkait
ketersediaan untuk
sistem inventaris C.1 Sistem harus memungkinkan pengguna yang berwenang untuk melihat deskripsi
peralatan setiap item peralatan dalam inventaris layanan darurat.
AV.1 Harus ada sistem 'hot standby' yang tersedia di lokasi yang secara geografis terpisah dari sistem utama.
Rasional : Keadaan darurat dapat mempengaruhi lokasi utama dari sistem.

AV.1.1 Semua transaksi harus dicatat di situs sistem utama dan di situs siaga jarak jauh.
Dasar Pemikiran: Hal ini memungkinkan transaksi ini untuk diputar ulang dan database sistem dibuat konsisten.
AV.1.2 Sistem harus mengirimkan informasi status ke sistem ruang kendali darurat setiap lima menit.
Rasional: Operator sistem ruang kontrol dapat beralih ke siaga panas jika sistem utama
tidak tersedia.
Sudut pandang
Saya memperkenalkan gagasan sudut pandang di Bab 4, di mana saya menjelaskan bagaimana sudut pandang dapat digunakan sebagai
cara untuk menyusun persyaratan dari pemangku kepentingan yang berbeda. Dengan menggunakan sudut pandang, Anda dapat
mengidentifikasi persyaratan untuk sistem inti dari setiap pengelompokan pemangku kepentingan.
http://www.SoftwareEngineering-9.com/Web/Requirements/Viewpoints.html
C.2 Sistem harus mencakup fasilitas pencarian untuk memungkinkan pengguna yang
berwenang untuk mencari inventaris individu atau inventaris lengkap untuk item peralatan
tertentu atau jenis peralatan tertentu.
Sistem juga dapat mencakup ekstensi yang dimaksudkan untuk mendukung peralatan
pengadaan dan penggantian. Persyaratan untuk ekstensi ini mungkin:
E1.1 Pengguna yang berwenang dapat memesan dengan pemasok terakreditasi untuk
item peralatan pengganti.
E1.1.1 Saat item peralatan dipesan, item tersebut harus dialokasikan ke inventaris tertentu
dan ditandai dalam inventaris tersebut sebagai 'sesuai pesanan'.
Sebagai aturan umum, Anda harus menghindari terlalu banyak masalah atau ekstensi ke
sistem. Ini hanya membingungkan pembaca dan dapat menyebabkan desain prematur. Ini
membatasi kebebasan perancang dan dapat mengakibatkan desain sistem yang tidak dapat
memenuhi persyaratan kualitas layanannya.
21.3.2 Desain dan pemrograman berorientasi aspek

Desain berorientasi aspek adalah proses merancang sistem yang memanfaatkan aspek untuk
mengimplementasikan perhatian dan perluasan lintas sektoral yang diidentifikasi selama
proses rekayasa persyaratan. Pada tahap ini, Anda perlu menerjemahkan kekhawatiran yang
berhubungan dengan masalah yang akan dipecahkan ke aspek yang sesuai dalam program
yang mengimplementasikan solusi. Anda juga perlu memahami bagaimana aspek-aspek ini
akan disusun dengan komponen sistem lainnya dan memastikan bahwa ambiguitas komposisi
tidak muncul.
Pernyataan persyaratan tingkat tinggi memberikan dasar untuk mengidentifikasi beberapa
ekstensi sistem yang dapat diimplementasikan sebagai aspek. Anda kemudian perlu
mengembangkan ini secara lebih rinci untuk mengidentifikasi ekstensi lebih lanjut dan untuk
memahami fungsionalitas yang diperlukan. Salah satu cara untuk melakukannya adalah
dengan mengidentifikasi satu set kasus penggunaan, (dibahas dalam Bab 4 dan 5) yang terkait
dengan setiap sudut pandang. Model use case berfokus pada interaksi dan lebih detail
daripada kebutuhan pengguna. Anda dapat menganggapnya sebagai jembatan antara persyaratan dan desain. Dalam mode
Hapus Peralatan
Dari Toko
Tambahkan
Peralatan ke Toko
Operator
Gambar 21.11 Kasus
penggunaan dari sistem Peralatan Tempat
manajemen inventaris Memesan
langkah-langkah dari setiap interaksi pengguna dan mulailah mengidentifikasi dan mendefinisikan kelas-
kelas dalam sistem.
Jacobson dan Ng (2004) telah menulis sebuah buku yang membahas bagaimana use case dapat
digunakan dalam rekayasa perangkat lunak berorientasi aspek. Mereka menyarankan bahwa setiap use
case mewakili sebuah aspek dan mengusulkan ekstensi ke pendekatan use case untuk mendukung join
point dan pointcuts. Mereka juga memperkenalkan gagasan tentang irisan kasus penggunaan dan modul
kasus penggunaan. Ini termasuk fragmen kelas yang mengimplementasikan suatu aspek. Mereka dapat
disusun untuk membuat sistem yang lengkap.
Gambar 21.11 menunjukkan contoh tiga kasus penggunaan yang mungkin menjadi bagian dari sistem
manajemen inventaris. Ini mencerminkan kekhawatiran menambahkan peralatan ke inventaris dan
memesan peralatan. Pemesanan peralatan dan penambahan peralatan ke toko adalah masalah terkait.
Setelah barang pesanan dikirim, barang tersebut harus ditambahkan ke inventaris dan dikirim ke salah
satu toko peralatan.
UML sudah menyertakan gagasan tentang kasus penggunaan ekstensi. Kasus penggunaan ekstensi
memperluas fungsionalitas kasus penggunaan lain. Gambar 21.12 menunjukkan bagaimana penempatan
pesanan peralatan memperluas kasus penggunaan inti untuk menambahkan peralatan ke toko tertentu.
Jika peralatan yang akan ditambahkan tidak ada, dapat dipesan dan ditambahkan ke toko saat peralatan
dikirimkan. Selama pengembangan model kasus penggunaan, Anda harus mencari fitur umum dan, jika
memungkinkan, menyusun kasus penggunaan sebagai kasus inti ditambah ekstensi. Fitur lintas sektor,
seperti pencatatan semua transaksi, juga dapat direpresentasikan sebagai kasus penggunaan ekstensi.
Jacobsen dan Ng membahas bagaimana ekstensi jenis ini dapat diimplementasikan sebagai aspek.
Peralatan Tempat
Memesan
"memperpanjang"
Tambahkan
Peralatan ke Toko
Gambar 21.12 Ekstensi
kasus penggunaan Operator
Aspek
Sistem Inti Identifikasi Komposisi Analisis dan
Resolusi Konflik Desain Nama
Rancangan Rancangan
dan Desain
Perangkat lunak Penamaan Program

Rancangan
Persyaratan Model Standar
Mengembangkan proses yang efektif untuk desain berorientasi aspek sangat penting jika
aspek Gambar 21.13 Desain berorientasi generik akan diterima dan digunakan. Saya menyarankan bahwa desain
pada Gambar 21.13. Kegiatan tersebutaspek
berorientasi proses
adalah: desain berorientasi aspek harus mencakup kegiatan yang ditunjukkan
proses
1. Desain sistem inti Pada tahap ini, Anda merancang arsitektur sistem untuk mendukung
fungsionalitas inti sistem. Arsitektur juga harus mempertimbangkan kualitas persyaratan
layanan seperti persyaratan kinerja dan ketergantungan.
2. Identifikasi dan desain aspek Dimulai dengan ekstensi yang diidentifikasi dalam persyaratan
sistem, Anda harus menganalisisnya untuk melihat apakah mereka merupakan aspek itu
sendiri atau harus dipecah menjadi beberapa aspek. Setelah aspek diidentifikasi, ini
kemudian dapat dirancang secara terpisah, dengan mempertimbangkan desain fitur sistem
inti.
3. Desain komposisi Pada tahap ini, Anda menganalisis sistem inti dan desain aspek untuk
menemukan di mana aspek harus disusun dengan sistem inti.
Pada dasarnya, Anda mengidentifikasi titik-titik bergabung dalam sebuah program di mana
aspek-aspek akan dijalin.
4. Analisis dan resolusi konflik Masalah dengan aspek adalah bahwa mereka dapat saling
mengganggu ketika mereka disusun dengan sistem inti. Konflik terjadi ketika ada bentrokan
pointcut dengan aspek yang berbeda yang menentukan bahwa mereka harus dikomposisikan
pada titik yang sama dalam program. Namun, mungkin ada konflik yang lebih halus. Ketika
aspek dirancang secara independen, mereka dapat membuat asumsi tentang fungsionalitas
sistem inti yang harus dimodifikasi.
Namun, ketika beberapa aspek disusun, satu aspek dapat mempengaruhi fungsi sistem
dengan cara yang tidak diantisipasi oleh aspek lainnya. Perilaku sistem secara keseluruhan
mungkin tidak seperti yang diharapkan.
5. Desain nama Ini adalah aktivitas desain penting yang mendefinisikan standar penamaan
entitas dalam program. Hal ini penting untuk menghindari masalah pointcuts yang tidak
disengaja. Ini terjadi ketika, pada beberapa titik bergabung program, nama secara tidak
sengaja cocok dengan itu dalam pola pointcut. Oleh karena itu, saran tersebut secara tidak
sengaja diterapkan pada saat itu. Jelas ini tidak diinginkan dan dapat menyebabkan perilaku
program yang tidak terduga. Oleh karena itu, Anda harus merancang skema penamaan
yang meminimalkan kemungkinan terjadinya hal ini.
"aspek" "aspek"
Memantau Pemeliharaan
Inventaris
Peralatan Catatan
«joinpoint»
«joinpoint» Toko Platform
Platform Peralatan
Lokasi
Lokasi DB
Gambar 21.14
"aspek" "aspek"
Model desain
Memerintah Ketersediaan
berorientasi aspek
Proses ini, tentu saja, merupakan proses berulang di mana Anda membuat proposal desain awal
kemudian menyempurnakannya saat Anda menganalisis dan memahami masalah desain.
Biasanya, Anda akan berharap untuk menyempurnakan ekstensi yang diidentifikasi dalam
persyaratan ke sejumlah besar aspek.
Hasil dari proses desain berorientasi aspek adalah model desain berorientasi aspek. Ini dapat
dinyatakan dalam versi UML yang diperluas yang mencakup konstruksi aspek-spesifik baru
seperti yang diusulkan oleh Clarke dan Baniassad (2005) dan Jacobson dan Ng (2004). Elemen
penting dari 'aspek UML' adalah sarana pemodelan aspek dan menentukan titik bergabung di
mana saran aspek harus disusun dengan sistem inti.
Gambar 21.14 adalah contoh model desain berorientasi aspek. Saya telah menggunakan
stereotip UML untuk aspek yang diusulkan oleh Jacobson dan Ng. Gambar 21.14 menunjukkan
sistem inti untuk inventaris layanan darurat ditambah beberapa aspek yang mungkin disusun
dengan inti tersebut. Saya telah menunjukkan beberapa kelas sistem inti dan beberapa aspek.
Ini adalah gambar yang disederhanakan; model yang lengkap akan mencakup lebih banyak kelas
dan aspek. Perhatikan bagaimana saya telah menggunakan catatan UML untuk memberikan
informasi tambahan tentang kelas-kelas yang dilintasi oleh beberapa aspek.
Gambar 21.15 adalah model yang lebih rinci dari suatu aspek. Jelas, sebelum Anda mendesain
aspek, Anda harus memiliki desain sistem inti. Karena saya tidak memiliki ruang untuk
menunjukkan ini di sini, saya telah membuat sejumlah asumsi tentang kelas dan metode dalam
sistem inti.
Bagian pertama dari aspek menetapkan poin-poin yang menentukan di mana ia akan disusun
dengan sistem inti. Sebagai contoh, pointcut pertama menentukan bahwa aspek dapat
dikomposisikan pada titik join getItemInfo (..) panggilan. Bagian berikut mendefinisikan ekstensi
yang diterapkan oleh aspek tersebut. Dalam contoh di sini, pernyataan ekstensi dapat dibaca
sebagai:
“Dalam metode viewItem, setelah panggilan ke metode getItemInfo, panggilan ke metode

displayHistory harus disertakan untuk menampilkan catatan pemeliharaan.”

Software Engineering 9th Edition by Ian Sommerville (301 600)

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Software Engineering 9th Edition by Ian Sommerville (301 600)

Diunggah oleh

Hak Cipta:

Format Tersedia

Machine Translated by Google

284 Bab 10 Sistem Sosioteknik

kegagalan sistem Hambatan

10.5.2 Evolusi sistem

10.5 Operasi sistem 285

286 Bab 10 Sistem Sosioteknik

BACAAN LEBIH LANJUT

Bab 10 Latihan 287

288 Bab 10 Sistem Sosioteknik

Suchman, L. (1987). Rencana dan tindakan terletak: masalah komunikasi manusia-mesin.

mengerti mengapa ketergantungan dan keamanan biasanya lebih

memahami empat dimensi utama ketergantungan, yaitu ketersediaan, keandalan,

waspadai terminologi khusus yang digunakan saat membahas keamanan dan

290 Bab 11 Keandalan dan keamanan

1. Kegagalan sistem mempengaruhi banyak orang. Banyak sistem menyertakan fungsionalitas

11.1 Sifat ketergantungan 291

11.1 Sifat ketergantungan

292 Bab 11 Keandalan dan keamanan

Ketersediaan Keandalan Keamanan Keamanan

11.1 Sifat ketergantungan 293

Gagasan ketergantungan sistem sebagai properti mencakup diperkenalkan karena sifat

294 Bab 11 Keandalan dan keamanan

11.2 Ketersediaan dan keandalan 295

Rendah Sedang Tinggi Sangat Ultra

11.2 Ketersediaan dan keandalan

1. Keandalan Probabilitas operasi bebas kegagalan selama waktu tertentu, dalam

296 Bab 11 Keandalan dan keamanan

Definisi keandalan yang ketat menghubungkan implementasi sistem dengan spesifikasinya.

11.2 Ketersediaan dan keandalan 297

lebih besar atau sama dengan 23.00.

298 Bab 11 Keandalan dan keamanan

Set Masukan Yaitu Masukan Menyebabkan

pemetaan input/ Keluaran

Gambar 11.5 Pola penggunaan

11.3 Keamanan 299 _

1. Penghindaran kesalahan Teknik pengembangan digunakan untuk meminimalkan kemungkinan

300 Bab 11 Keandalan dan keamanan

. . . kesulitan dengan persyaratan adalah akar penyebab utama dari kesalahan

11.3 Keamanan 301 _

Bahaya Suatu kondisi yang berpotensi menyebabkan atau berkontribusi terhadap

Probabilitas bahaya Probabilitas terjadinya peristiwa yang menimbulkan bahaya.

overdosis mungkin rendah.

302 Bab 11 Keandalan dan keamanan

3. Batasan kerusakan Sistem dapat menyertakan fitur perlindungan yang meminimalkan

11.4 Keamanan 303 _

304 Bab 11 Keandalan dan keamanan

Menyerang Peniruan identitas pengguna yang sah.

11.4 Keamanan 305 _

menurunkan kata sandi mereka di tempat-tempat di mana mereka dapat ditemukan.

1. Penghindaran kerentanan Kontrol yang dimaksudkan untuk memastikan bahwa serangan

306 Bab 11 Keandalan dan keamanan

BACAAN LEBIH LANJUT

Bab 11 Latihan 307

11.2. Apa dimensi terpenting dari ketergantungan sistem?

Server Internet yang disediakan oleh ISP dengan ribuan pelanggan

Sistem kontrol arah yang digunakan dalam kendaraan peluncuran satelit

Sistem manajemen keuangan pribadi berbasis Internet

308 Bab 11 Keandalan dan keamanan

Berghel, H. (2001). 'Kode Cacing Merah'. Kom. ACM, 44 (12), 15–19.

memahami bagaimana pendekatan berbasis risiko dapat digunakan untuk mengidentifikasi

menyadari keuntungan dan kerugian menggunakan spesifikasi matematis formal

310 Bab 12 Keandalan dan spesifikasi keamanan

1. Persyaratan fungsional, yang menentukan fasilitas pemeriksaan dan pemulihan yang