Pertemuan 2

Prerequisites
 Pokok Bahasan
• Membangun PL
• Appeal to Analogy
• Problem-Definition Prerequisite
• Architecture Prerequisite
• Typical Architectural Components
 Membangun PL
Jika Anda menekankan kualitas pada awal proyek, Anda
merencanakan, mengharuskan, dan merancang produk
berkualitas tinggi. Jika Anda memulai proses dengan desain Anda
dapat menguji semua yang Anda inginkan, dan itu tidak akan
pernah berubah menjadi membangun yang terbaik, tetapi jika
Anda menginginkan harus merencanakan dari awal untuk
membangun perangkat lunak, Anda melakukan perencanaan
seperti itu ketika menentukan masalah, ketika Anda menentukan
solusinya, dan ketika Anda merancang solusinya, akan mudah
melakukannya.
 Karena konstruksi berada di tengah-tengah proyek perangkat
lunak, pada saat Anda mencapai konstruksi, bagian-bagian awal
proyek telah meletakkan beberapa dari landasan untuk
keberhasilan atau kegagalan. Namun, selama konstruksi,
setidaknya harus dapat menentukan seberapa baik situasi yang
mendukung, jika melihat awan hitam kegagalan menjulang di
cakrawala. Apakah Anda benar-benar siap untuk memulai
konstruksi.
 Anda mungkin berpikir bahwa semua programmer
profesional tahu tentang pentingnya persiapan dan memeriksa
apakah prasyarat telah dipenuhi sebelum terjun ke konstruksi.
Sayangnya, itu tidak benar.
Penyebab umum dari persiapan yang tidak lengkap adalah
bahwa pengembang yang menandatangani kontrak untuk
mengerjakan kegiatan hulu tidak memiliki keahlian untuk
melaksanakan tugas mereka. Keterampilan yang diperlukan
untuk merencanakan suatu proyek, membuat kasus bisnis yang
menarik, mengembangkan persyaratan yang komprehensif dan
akurat, dan membuat arsitektur berkualitas tinggi jauh dari
mudah, tetapi sebagian besar pengembang belum menerima
pelatihan tentang cara melakukan kegiatan ini.
Kapan pengembang tidak tahu caranya melakukan pekerjaan
hulu, rekomendasi untuk "melakukan lebih banyak pekerjaan
hulu" terdengar seperti omong kosong: Jika pekerjaan itu tidak
dilakukan dengan baik di tempat pertama, melakukan lebih dari
itu tidak akan berguna! Menjelaskan bagaimana melakukan
kegiatan-kegiatan ini berada di luar cakupan ini.
 Beberapa programmer benar-benar tahu bagaimana
melakukan kegiatan hulu, tetapi mereka tidak siap karena
mereka tidak dapat menahan keinginan untuk mulai
mengkodekan sesegera mungkin. Jika Anda memberi makan
kuda Anda di palung ini, saya punya dua saran.
Saran 1: Baca argumen di bagian selanjutnya. Mungkin
memberi tahu Anda beberapa hal yang belum Anda pikirkan.
Saran 2: Perhatikan masalah yang Anda alami. Hanya perlu
beberapa program besar untuk mengetahui bahwa Anda dapat
menghindari banyak kebingungan dengan merencanakan
sebelumnya. Biarkan pengalaman Anda sendiri menjadi panduan
Anda.
 Alasan terakhir yang tidak dipersiapkan programmer adalah
bahwa manajer terkenal tidak simpatik kepada programmer yang
menghabiskan waktu untuk prasyarat konstruksi. Orang-orang
seperti Barry Boehm, Grady Booch, dan Karl Wiegers telah
menggedor persyaratan dan desain drum selama 25 tahun, dan
Anda berharap bahwa manajer akan mulai memahami bahwa
pengembangan perangkat lunak lebih dari sekadar pengkodean.
 Appeal to Analogy
Jika Anda merencanakan proyek yang sangat iteratif, Anda
perlu mengidentifikasi persyaratan penting dan elemen
arsitektur yang berlaku untuk setiap bagian yang Anda
susun sebelum Anda memulai konstruksi. Seorang
pembangun yang sedang membangun pembangunan
perumahan tidak perlu mengetahui setiap detail dari setiap
rumah dalam pembangunan, sebelum memulai konstruksi
di rumah pertama. Tetapi pembangun akan mensurvei situs,
memetakan saluran pembuangan dan saluran listrik, dan
sebagainya. Jika pembangun tidak menyiapkan dengan baik,
konstruksi mungkin tertunda ketika saluran pembuangan
harus digali di bawah rumah yang sudah dibangun.
 Problem-Definition Prerequisite
Prasyarat pertama yang harus Anda penuhi sebelum memulai
konstruksi adalah pernyataan yang jelas tentang masalah yang
seharusnya diselesaikan oleh sistem. Kadang-kadang ini disebut
"visi produk," "pernyataan misi," dan "definisi produk." Di sini
disebut "definisi masalah." Karena buku ini tentang konstruksi,
akan memberi tahu Anda bagaimana mengenali apakah telah
ditulis sama sekali dan apakah yang ditulis akan membentuk
fondasi yang baik untuk konstruksi.
Definisi masalah mendefinisikan apa masalahnya tanpa
merujuk pada solusi. Ini pernyataan sederhana, mungkin satu
atau dua halaman, dan seharusnya terdengar seperti masalah.
Gambar 1. The problem definition lays the foundation for the rest
of the programming process.
 Definisi masalah harus dalam bahasa pengguna, dan
masalahnya harus dijelaskan dari sudut pandang pengguna.
Biasanya tidak dinyatakan dalam istilah teknis komputer. Solusi
terbaik mungkin bukan program komputer. Misalkan Anda
memerlukan laporan yang menunjukkan laba tahunan Anda.
Anda sudah memiliki laporan terkomputerisasi yang
menunjukkan keuntungan triwulanan. Jika Anda terkunci di set
programmer, Anda akan beralasan bahwa menambahkan
laporan tahunan ke sistem yang sudah melakukan laporan harus
mudah. Maka Anda akan membayar seorang programmer untuk
menulis dan men-debug program yang memakan waktu
menghitung laba tahunan. Jika Anda tidak mengunci pola pikir
komputer, Anda akan membayar sekretaris Anda untuk
membuat angka-angka tahunan dengan mengambil satu menit
untuk menambahkan angka-angka triwulanan pada kalkulator.
 Persyaratan menjelaskan secara terperinci apa yang
seharusnya dilakukan oleh sistem perangkat lunak, dan mereka
adalah langkah pertama menuju solusi. Aktivitas persyaratan
juga dikenal sebagai "pengembangan persyaratan," "analisis
persyaratan," "analisis," "'memerlukan definisi persyaratan
perangkat lunak," "spesifikasi," "spesifikasi fungsional," dan
"spesifikasi.

Gambar 2. Without a good problem definition, you might put effort into solving
the wrong problem. Be sure you know what you’re aiming at before you shoot.
 Menentukan persyaratan secara memadai adalah kunci
keberhasilan proyek, bahkan mungkin lebih penting daripada
teknik konstruksi yang efektif. Banyak buku bagus telah ditulis
tentang cara menentukan persyaratan dengan baik. Akibatnya,
beberapa bagian berikutnya tidak memberi tahu Anda cara
melakukan pekerjaan dengan baik dengan menetapkan
persyaratan, mereka memberi tahu Anda cara menentukan
apakah persyaratan telah dilakukan dengan baik dan bagaimana
469 memanfaatkan sebaik-baiknya persyaratan yang Anda miliki.
 Architecture Prerequisite
Arsitektur perangkat lunak adalah bagian tingkat tinggi dari
desain perangkat lunak, bingkai yang memegang bagian-
bagian yang lebih detail dari desain (Buschman, Fowler; Bass
Clements, Kazman; Clements). Arsitektur juga dikenal sebagai
"arsitektur sistem," "desain tingkat tinggi," dan "desain tingkat
atas." Biasanya, arsitektur dijelaskan dalam satu dokumen
yang disebut sebagai "spesifikasi arsitektur" atau "top-
arsitektur". Beberapa orang membuat perbedaan antara
arsitektur dan desain tingkat tinggi, arsitektur mengacu pada
kendala desain yang diterapkan di seluruh sistem, sedangkan
desain tingkat tinggi mengacu pada batasan desain yang
diterapkan pada subsistem atau tingkat kelas ganda. , tetapi
tidak harus sistem yang luas.
 Kualitas arsitektur menentukan integritas konseptual sistem.
Itu pada gilirannya menentukan kualitas tertinggi dari sistem.
Arsitektur yang dipikirkan dengan baik menyediakan struktur
yang diperlukan untuk mempertahankan integritas konseptual
sistem dari tingkat atas ke tingkat bawah. Ini memberikan
panduan kepada programmer pada tingkat detail yang sesuai
dengan keterampilan programmer dan pekerjaan yang sedang
dihadapi. Ini mempartisi kerja sehingga banyak pengembang
atau beberapa tim pengembangan dapat bekerja secara
independen. Arsitektur yang baik membuat konstruksi menjadi
mudah. Arsitektur yang buruk membuat konstruksi hampir
mustahil.
Typical Architectural Components
1. Program Organization

Arsitektur sistem pertama-tama membutuhkan gambaran

umum yang menjelaskan sistem secara luas. Tanpa ikhtisar
seperti itu, Anda akan kesulitan membangun gambar yang
koheren dari seribu detail atau bahkan selusin kelas individu.
Jika sistem adalah teka-teki jigsaw. Teka-teki dari 12 kelas
perangkat lunak atau 12 tems lebih sulit untuk disatukan, dan
jika Anda tidak bisa menyatukannya, Anda tidak akan tahan,
bagaimana kelas yang Anda kembangkan apakah dapat
memberikan berkontribusi pada sistem.
 Dalam arsitektur, Anda harus menemukan bukti bahwa
alternatif untuk organisasi akhir dipertimbangkan dan
menemukan alasan mengapa organisasi yang digunakan dipilih
atas alternatif. Sangat frustasi untuk bekerja di kelas ketika
tampaknya peran class dalam sistem belum dipahami secara
jelas. Dengan menggambarkan alternatif dalam organisasi,
arsitektur memberikan alasan untuk sistem organisasi dan
menunjukkan bahwa setiap class telah dipertimbangkan dengan
cermat. Satu pandangan kembali tentang praktik desain
menemukan bahwa dasar pemikiran desain setidaknya sama
pentingnya dengan pemeliharaan itu sendiri.
 Arsitektur harus mendefinisikan blok bangunan utama dalam
suatu program. Tergantung pada ukuran program, setiap blok
bangunan mungkin satu class, atau mungkin merupakan
subsistem yang terdiri dari banyak kelas. Setiap blok penyusun
adalah kelas, 673 atau kumpulan class atau rutin yang bekerja
bersama pada fungsi tingkat tinggi seperti berinteraksi dengan
pengguna, menampilkan halaman web, menafsirkan perintah,
merangkum aturan bisnis, atau mengakses data. Setiap fitur yang
tercantum dalam requirements harus dicakup oleh setidaknya
satu blok bangunan. Jika suatu fungsi diklaim oleh dua atau lebih
blok bangunan, klaim mereka harus bekerja sama, bukan
menjadi konflik.
2. Major Classes
Arsitektur harus menentukan kelas utama yang akan
digunakan. Ini harus mengidentifikasi tanggung jawab masing-
masing kelas utama dan bagaimana kelas akan berinteraksi
dengan kelas lainnya. Ini harus mencakup deskripsi tentang
hierarki kelas, transisi, dan kegigihan objek. Jika sistemnya
cukup besar, itu harus menggambarkan bagaimana kelas
diorganisasikan ke dalam subsistem.
Arsitekturnya harus menggambarkan desain kelas lain yang
dipertimbangkan dan memberikan alasan untuk memilih
organisasi yang dipilih. Arsitektur tidak perlu menentukan
setiap kelas dalam sistem; bertujuan untuk aturan 80/20:
tentukan 20 persen dari kelas yang membentuk 80 persen dari
perilaku sistem (Jacobsen, Booch, dan Rumbaugh).
3. Data Design
Arsitektur harus menggambarkan file utama dan desain tabel
yang akan digunakan. Ini harus menggambarkan alternatif
yang dipertimbangkan dan membenarkan pilihan yang
dibuat. Jika aplikasi mempertahankan daftar ID pelanggan
dan arsitek telah memilih untuk mewakili daftar ID
menggunakan daftar akses sekuensial, dokumen harus
menjelaskan mengapa daftar akses sekuensial lebih baik
daripada daftar akses acak, stack, atau tabel hash. Selama
konstruksi, informasi tersebut memberi Anda wawasan ke
dalam pikiran arsitek. Selama pemeliharaan, wawasan yang
sama adalah bantuan berharga.
4. Business Rule.
Jika arsitektur tergantung pada aturan bisnis tertentu, itu
harus mengidentifikasinya dan menggambarkan dampak
aturan terhadap desain sistem. Sebagai contoh, misalkan
sistem diharuskan untuk mengikuti aturan bisnis bahwa
informasi pelanggan seharusnya tidak lebih dari 30 detik
kedaluwarsa. Dalam hal itu, dampak yang ada pada
pendekatan arsitektur untuk menjaga informasi pelanggan
tetap mutakhir dan sinkronisasi harus dijelaskan.
5. User Interface Design
Terkadang antarmuka pengguna ditentukan pada waktu
persyaratan. Jika tidak, maka harus ditentukan dalam arsitektur
perangkat lunak. Arsitekturnya harus menentukan elemen utama
format halaman web, GUI, antarmuka baris perintah, dan
sebagainya. Arsitektur yang cermat dari antarmuka pengguna
membuat perbedaan antara program yang sangat disukai dan
yang tidak pernah digunakan. Arsitekturnya harus dimodulasi
sehingga antarmuka pengguna baru dapat dirapikan tanpa
mempengaruhi aturan bisnis dan bagian output dari program.
Sebagai contoh, arsitektur seharusnya membuatnya cukup
mudah untuk memenggal sekelompok kelas antarmuka dan
memasukkan sekelompok kelas perintah. Kemampuan ini sering
berguna, terutama karena antarmuka baris perintah sesuai untuk
pengujian perangkat lunak pada tingkat unit.
6. Input/ Output.
Input / output adalah area lain yang patut mendapat perhatian
dalam arsitektur. Tecture harus menentukan skema membaca
yang melihat melihat kedepan, melihat ke belakang, atau hanya
dalam waktu. Dan itu harus menggambarkan tingkat di mana I/O
kesalahan terdeteksi di lapangan.
7. Resource Management.
Manajemen Sumber Daya Arsitektur harus menggambarkan
rencana untuk mengelola sumber daya yang langka seperti
koneksi basis data. Manajemen memori adalah area lain
untuk arsitektur untuk diperlakukan dalam aplikasi yang
dibatasi memori, seperti pengembangan driver dan sistem
embedded. Arsitektur harus memperkirakan waktu sumber
daya yang digunakan untuk kasus nominal dan ekstrim.
Dalam kasus sederhana, perkiraan 748 harus menunjukkan
bahwa sumber daya yang dibutuhkan berada dengan baik di
dalam kemampuan lingkungan yang dimaksud. Dalam kasus
yang lebih kompleks, aplikasi mungkin diperlukan untuk lebih
aktif mengelola sumber dayanya sendiri. Jika ya, manajer
sumber daya harus dirancang dengan hati-hati seperti halnya
bagian lain dari sistem.
8. Security.
Keamanan Arsitektur harus menggambarkan pendekatan untuk
keamanan tingkat desain dan level kode. Jika model ancaman
belum pernah dibangun sebelumnya, itu harus dibangun pada
waktu arsitektur. Pedoman pengkodean harus dikembangkan
dengan mempertimbangkan implikasi keamanan, termasuk
pendekatan untuk menangani buffer; aturan untuk menangani
data tepercaya (input data dari pengguna, cookie, data
konfigurasi, antarmuka eksternal lainnya); enkripsi; tingkat detail
yang terkandung dalam pesan kesalahan; melindungi data
rahasia yang ada di memori; dan masalah lainnya.
9. Performance.
Jika kinerja menjadi perhatian, tujuan kinerja harus
ditetapkan dalam kembali. Sasaran kinerja dapat mencakup
kecepatan dan penggunaan memori. Arsitektur harus
memberikan perkiraan dan menjelaskan mengapa arsitek
percaya bahwa tujuan dapat dicapai. Jika daerah-daerah
tertentu berisiko gagal memenuhi tujuan mereka, arsitektur
seharusnya mengatakannya. Jika area tertentu memerlukan
penggunaan jenis algo tertentu atau tipe data untuk
memenuhi tujuan kinerja mereka, arsitekturnya harus
mengatakan demikian. Arsitekturnya juga dapat menyertakan
anggaran ruang dan waktu untuk setiap class atau object.