BAB
VII CODING DAN PENGUJAN UNIT
7.1
Prinsip pemrograman dan Pedoman
Tugas utama adalah sebelum seorang
programmer menulis kode yang dapat
dibaca. Menulis kode adalah keterampilan yang solid hanya dapat diperoleh
dengan praktek CO. Berdasarkan pengalaman, beberapa aturan umum dan pedoman
dapat diberikan untuk programmer. Pemrograman yang baik (memproduksi program
yang benar dan sederhana) adalah independen praktek bahasa pemrograman sasaran,
meskipun bahasa pemrograman yang terstruktur dengan baik membuat pekerjaan programmer
sederhana.
7.1.1 Pemrograman Terstruktur
Dalam
pemrograman terstruktur, pernyataan bukanlah pernyataan tugas sederhana
melainkan pernyataan terstruktur. Properti
kunci dari pernyataan terstruktur adalah bahwa ia memiliki satu-masukan dan satu-keluar. Artinya, selama dieksekusi, pernyataan dimulai dari satu titik
didefinisikan dan berakhir pada satu
titik didefinisikan. Dengan pernyataan satu-masukan dan satu-keluar, kita dapat melihat program sebagai urutan
laporan (terstruktur). pernyataan yang paling sering digunakan adalah
Tujuan dasar menggunakan konstruksi terstruktur adalah
untuk linearize aliran kontrol sehingga perilaku eksekusi lebih mudah untuk dimengerti
dan berdebat tentang. Secara keseluruhan, dapat dikatakan bahwa pemrograman
terstruktur mengarah ke program yang lebih mudah dimengerti daripada program
terstruktur, dan bahwa program tersebut lebih mudah untuk secara resmi
membuktikan. Namun, harus diingat bahwa pemrograman terstruktur tidak tujuan
itu sendiri.. Namun, ada beberapa praktik pemrograman umum yang sekarang
dipahami bahwa menggunakan konstruksi yang tidak terstruktur (misal, pernyataan
break, terus pernyataan).
7.1.2 Informasi
Tersembunyi.
Sebuah solusi perangkat lunak untuk masalah
selalu berisi struktur data yang dimaksudkan untuk mewakili informasi dalam
domain masalah. Artinya, ketika perangkat lunak dikembangkan untuk memecahkan masalah, perangkat lunak
menggunakan beberapa struktur data untuk menangkap informasi dalam domain
masalah.
Ketika informasi tersebut direpresentasikan sebagai struktur data, prinsip yang sama harus diterapkan, dan hanya beberapa operasi yang didefinisikan harus dilakukan pada struktur data. Ini, pada dasarnya, adalah prinsip bersembunyi informasi. Informasi yang ditangkap dalam struktur data harus disembunyikan dari sisa dari sistem, dan hanya akses fungsi pada struktur data yang mewakili operasi yang dilakukan pada informasi yang harus terlihat. Dengan kata lain, ketika informasi tersebut ditangkap di struktur data dan kemudian pada struktur data yang mewakili beberapa informasi, untuk setiap operasi pada informasi fungsi akses harus disediakan. Dan sebagai sisa dari sistem dalam domain masalah hanya melakukan operasi ini didefinisikan pada informasi, sisa modul dalam perangkat lunak hanya menggunakan fungsi akses ini untuk mengakses dan memanipulasi struktur data.
Informasi bersembunyi merupakan alat efektif untuk mengelola kompleksitas mengembangkan software-dengan menggunakan informasi bersembunyi kita telah memisahkan perhatian dari mengelola data dari kepedulian menggunakan data untuk menghasilkan beberapa hasil yang diinginkan.
Ketika informasi tersebut direpresentasikan sebagai struktur data, prinsip yang sama harus diterapkan, dan hanya beberapa operasi yang didefinisikan harus dilakukan pada struktur data. Ini, pada dasarnya, adalah prinsip bersembunyi informasi. Informasi yang ditangkap dalam struktur data harus disembunyikan dari sisa dari sistem, dan hanya akses fungsi pada struktur data yang mewakili operasi yang dilakukan pada informasi yang harus terlihat. Dengan kata lain, ketika informasi tersebut ditangkap di struktur data dan kemudian pada struktur data yang mewakili beberapa informasi, untuk setiap operasi pada informasi fungsi akses harus disediakan. Dan sebagai sisa dari sistem dalam domain masalah hanya melakukan operasi ini didefinisikan pada informasi, sisa modul dalam perangkat lunak hanya menggunakan fungsi akses ini untuk mengakses dan memanipulasi struktur data.
Informasi bersembunyi merupakan alat efektif untuk mengelola kompleksitas mengembangkan software-dengan menggunakan informasi bersembunyi kita telah memisahkan perhatian dari mengelola data dari kepedulian menggunakan data untuk menghasilkan beberapa hasil yang diinginkan.
7.1.3 Beberapa
Praktek Pemrograman
Beberapa aturan yang telah ditemukan
untuk membuat kode lebih mudah dibaca serta menghindari beberapa kesalahan.
* Kontrol Constructs: Seperti telah dibahas sebelumnya, hal ini diinginkan bahwa sebanyak mungkin single-entry, konstruksi single-exit digunakan.
* Kontrol Constructs: Seperti telah dibahas sebelumnya, hal ini diinginkan bahwa sebanyak mungkin single-entry, konstruksi single-exit digunakan.
* Gotos: gotos harus digunakan dengan
hemat dan secara disiplin. Jika goto harus digunakan, transfer ke depan (atau
melompat ke pernyataan kemudian) lebih diterima daripada melompat ke belakang.
* Informasi Menyembunyikan: Hanya fungsi akses untuk struktur data harus dibuat terlihat saat bersembunyi struktur data di balik fungsi tersebut.
* Jenis Buatan Pengguna: bahasa modern memungkinkan pengguna untuk menentukan jenis seperti tipe enumerasi. Ketika fasilitas tersebut tersedia, mereka harus ex-ploited mana yang berlaku. Misalnya, ketika bekerja dengan tanggal, tipe dapat didefinisikan untuk hari dalam seminggu.
* Informasi Menyembunyikan: Hanya fungsi akses untuk struktur data harus dibuat terlihat saat bersembunyi struktur data di balik fungsi tersebut.
* Jenis Buatan Pengguna: bahasa modern memungkinkan pengguna untuk menentukan jenis seperti tipe enumerasi. Ketika fasilitas tersebut tersedia, mereka harus ex-ploited mana yang berlaku. Misalnya, ketika bekerja dengan tanggal, tipe dapat didefinisikan untuk hari dalam seminggu.
* Nesting: Jika
bersarang jika-maka-lain konstruksi menjadi terlalu dalam, maka logika menjadi
sulit untuk memahami. Dalam kasus sangat bersarang jika-maka-elses, seringkali sulit
untuk menentukan
jika pernyataan yang klausul lain tertentu terkait. Bila memungkinkan,
bersarang dalam harus dihindari, bahkan jika itu berarti sedikit ine FFI
efisiensi. Sebagai contoh, perhatikan konstruk berikut bersarang
jika-maka-elses:
* Modul Ukuran:
Kami membahas masalah ini selama desain sistem. Seorang programmer harus
hati-hati memeriksa setiap fungsi dengan terlalu banyak laporan (mengatakan
lebih dari 100). modul besar sering tidak akan fungsional kohesif.
* Modul Interface: Sebuah modul dengan antarmuka yang kompleks harus diteliti dengan seksama. Sebagai aturan praktis, setiap modul yang antarmuka memiliki lebih dari lima parameter harus diteliti dengan seksama dan patah menjadi beberapa modul dengan antarmuka sederhana jika mungkin.
* Side E ff proyek-: Ketika sebuah modul dipanggil, kadang-kadang memiliki sisi e proyek-ff memodifikasi program negara di luar modifikasi parameter yang tercantum dalam definisi antarmuka modul, misalnya, memodifikasi variabel global. sisi e ff ects tersebut harus dihindari jika mungkin, dan jika modul memiliki sisi e proyek-ff, mereka harus didokumentasikan dengan benar.
* Kekokohan: Sebuah program adalah kuat jika melakukan sesuatu yang direncanakan bahkan untuk kondisi yang luar biasa. Sebuah program mungkin mengalami seperti masukan yang salah, nilai yang salah dari beberapa variabel, dan melimpah. Jika situasi seperti itu timbul, program seharusnya tidak hanya "kecelakaan" atau "inti sampah"; itu harus menghasilkan beberapa pesan yang bermakna dan keluar dengan anggun.
* Beralih Kasus dengan Default: Jika tidak ada kasus default di "switch" pernyataan, perilaku dapat diprediksi jika kasus yang muncul di beberapa titik waktu yang tidak dapat diprediksi pada tahap pembangunan. praktek tersebut dapat mengakibatkan bug seperti NULL dereference, kebocoran memori, serta jenis lain dari bug serius. Ini adalah praktik yang baik untuk selalu menyertakan kasus default.
* Kosong Menangkap Block: Pengecualian tertangkap, tetapi jika tidak ada tindakan, itu mungkin merupakan skenario di mana beberapa operasi yang akan dilakukan tidak dilakukan. Setiap kali pengecualian tertangkap, itu adalah praktik yang baik untuk mengambil beberapa tindakan default, bahkan jika itu hanya mencetak pesan kesalahan.
* Kosong jika, sementara Pernyataan: Sebuah kondisi diperiksa tapi tidak ada yang dilakukan berdasarkan cek. Hal ini sering terjadi karena beberapa kesalahan dan harus ditangkap. kesalahan serupa lainnya termasuk akhirnya, mencoba, disinkronkan, metode statis kosong kosong, dll cek berguna seperti itu harus dihindari.
* Baca Kembali ke Be Diperiksa: Seringkali nilai kembali dari membaca tidak diperiksa, dengan asumsi bahwa membaca mengembalikan nilai yang diinginkan. Kadang-kadang hasil dari membaca bisa menjadi di ff berbeda dengan apa yang diharapkan, dan ini dapat menyebabkan kegagalan kemudian.
* Modul Interface: Sebuah modul dengan antarmuka yang kompleks harus diteliti dengan seksama. Sebagai aturan praktis, setiap modul yang antarmuka memiliki lebih dari lima parameter harus diteliti dengan seksama dan patah menjadi beberapa modul dengan antarmuka sederhana jika mungkin.
* Side E ff proyek-: Ketika sebuah modul dipanggil, kadang-kadang memiliki sisi e proyek-ff memodifikasi program negara di luar modifikasi parameter yang tercantum dalam definisi antarmuka modul, misalnya, memodifikasi variabel global. sisi e ff ects tersebut harus dihindari jika mungkin, dan jika modul memiliki sisi e proyek-ff, mereka harus didokumentasikan dengan benar.
* Kekokohan: Sebuah program adalah kuat jika melakukan sesuatu yang direncanakan bahkan untuk kondisi yang luar biasa. Sebuah program mungkin mengalami seperti masukan yang salah, nilai yang salah dari beberapa variabel, dan melimpah. Jika situasi seperti itu timbul, program seharusnya tidak hanya "kecelakaan" atau "inti sampah"; itu harus menghasilkan beberapa pesan yang bermakna dan keluar dengan anggun.
* Beralih Kasus dengan Default: Jika tidak ada kasus default di "switch" pernyataan, perilaku dapat diprediksi jika kasus yang muncul di beberapa titik waktu yang tidak dapat diprediksi pada tahap pembangunan. praktek tersebut dapat mengakibatkan bug seperti NULL dereference, kebocoran memori, serta jenis lain dari bug serius. Ini adalah praktik yang baik untuk selalu menyertakan kasus default.
* Kosong Menangkap Block: Pengecualian tertangkap, tetapi jika tidak ada tindakan, itu mungkin merupakan skenario di mana beberapa operasi yang akan dilakukan tidak dilakukan. Setiap kali pengecualian tertangkap, itu adalah praktik yang baik untuk mengambil beberapa tindakan default, bahkan jika itu hanya mencetak pesan kesalahan.
* Kosong jika, sementara Pernyataan: Sebuah kondisi diperiksa tapi tidak ada yang dilakukan berdasarkan cek. Hal ini sering terjadi karena beberapa kesalahan dan harus ditangkap. kesalahan serupa lainnya termasuk akhirnya, mencoba, disinkronkan, metode statis kosong kosong, dll cek berguna seperti itu harus dihindari.
* Baca Kembali ke Be Diperiksa: Seringkali nilai kembali dari membaca tidak diperiksa, dengan asumsi bahwa membaca mengembalikan nilai yang diinginkan. Kadang-kadang hasil dari membaca bisa menjadi di ff berbeda dengan apa yang diharapkan, dan ini dapat menyebabkan kegagalan kemudian.
Dalam
contoh ini, nilai yang dikembalikan baik dalam pengecualian dan nonexception
SCE-narios. Oleh karena itu, di lokasi penelepon, pengguna tidak akan bisa
membedakan antara keduanya.
Sumber
Data: Counter pemeriksaan harus dilakukan sebelum mengakses data input,
terutama jika data input yang disediakan oleh pengguna atau sedang diperoleh
melalui jaringan. Misalnya, saat melakukan operasi copy string, kita harus
memeriksa bahwa string sumber nol diakhiri, atau yang ukurannya seperti yang
kita harapkan.
Kebanyakan
programmer cenderung memberikan sedikit perhatian pada kasus luar biasa mungkin
dan cenderung bekerja dengan arus utama acara, kontrol, dan data.
Untuk
membuat sistem software yang lebih handal, programmer harus mempertimbangkan
semua kemungkinan dan menulis penangan pengecualian cocok untuk mencegah
kegagalan atau kehilangan ketika situasi tersebut terjadi.
7.1.4 Standar Coding
Secara
umum, standar coding memberikan pedoman bagi programmer mengenai penamaan,
organisasi berkas, pernyataan dan deklarasi, dan tata letak.
File
konvensi adalah
tentang bagaimana file harus dinamai, dan apa saja file
yg harus di isi, sehingga pembaca bisa mendapatkan beberapa
ide tentang apa file contains. Beberapa contoh konvensi ini adalah:
- File source Java harus memiliki ekstensi .java ini
diberlakukan oleh sebagian besar kompiler.
- Setiap file harus berisi satu kelas luar dan nama kelas
harus sama dengan nama file.
- Panjang garis harus dibatasi kurang dari 80 kolom dan
khusus charac-ters harus dihindari. Jika garis lebih panjang, hal itu harus
dilanjutkan dan kelanjutan harus dibuat sangat jelas.
Laporan
Tata Cara ini adalah untuk deklarasi dan dieksekusi dalam kode source.Namun, perlu diketahui bahwa tidak semua orang akan
setuju pada cara
ini. Itulah sebabnya organisasi umumnya mengembangkan pedoman mereka sendiri
yang dapat diikuti tanpa membatasi fleksibilitas programmer untuk jenis
pekerjaan organisasi.
Komentar
dan Layout Komentar adalah pernyataan tekstual yang dimaksudkan untuk program
pembaca untuk membantu pemahaman kode. Secara umum, komentar harus menjelaskan
kegunaan kode atau mengapa kode yang ada, sehingga kode dapat menjadi hampir
standalone (berdiri sendiri) untuk memahami
sistem. Komentar umumnya harus disediakan untuk blok kode.
Menyediakan
komentar untuk modul yang paling berguna, sebagai modul membentuk unit pengujian,
kompilasi, verifikasi, dan modifikasi. Perlu dicatat bahwa prolog berguna jika
mereka tetap konsisten. Jika modul tersebut dimodifikasi, maka prolog juga
harus diubah. Java menyediakan komentar dokumentasi yang dibatasi oleh "/
** ... * /", dan yang bisa diambil ke file HTML. Komentar ini sebagian
besar digunakan sebagai prolog metode-metode dan bidang.
Selain
prolog untuk modul, standar pengkodean dapat menentukan bagaimana dan di mana
komentar harus berada. Beberapa pedoman tersebut adalah:
- Satu baris komentar untuk blok kode harus sejajar dengan
kode mereka dimaksudkan untuk.
- Harus ada komentar untuk semua variabel utama menjelaskan
apa yang mereka refensi
- Sebuah blok komentar harus didahului oleh kosong baris
komentar hanya dengan "/ *" dan diakhiri -dengan baris yang berisi hanya "* /".
- Trailing komentar setelah laporan harus singkat, pada
baris yang sama, dan bergeser cukup jauh untuk memisahkan mereka dari laporan.
Pedoman tata letak fokus pada bagaimana program harus
menjorok,
bagaimana harus menggunakan baris kosong, ruang putih, dll, untuk membuatnya
lebih mudah dibaca. pedoman lekukan kadang-kadang disediakan untuk setiap jenis
pemrograman membangun. Namun, kebanyakan programmer belajar ini dengan melihat
kode dari orang lain dan fragmen kode dalam buku-buku dan dokumen, dan banyak
dari ini telah menjadi cukup standar selama bertahun-tahun. Kita tidak akan
membahas mereka lebih jauh kecuali untuk mengatakan bahwa seorang programmer
harus menggunakan beberapa konvensi, dan menggunakannya secara konsisten.
7.2
Bertahap Mengembangkan Kode
Keuntungan dasar mengembangkan kode secara bertahap dengan pengujian yang dilakukan setelah setiap putaran coding adalah untuk memfasilitasi debugging-kesalahan yang ditemukan dalam beberapa pengujian dapat dengan aman dikaitkan dengan kode yang ditambahkan sejak pengujian terakhir yang berhasil. Namun, untuk mengikuti proses ini, adalah penting bahwa pengujian dilakukan melalui tes script yang dapat dijalankan dengan mudah. Dengan skrip tes ini, pengujian dapat dilakukan sesering yang diinginkan, dan uji kasus baru dapat ditambahkan dengan mudah. script tes ini juga merupakan bantuan yang luar biasa ketika kode ditingkatkan di masa-melalui script tes itu dapat dengan cepat memeriksa bahwa fungsi sebelumnya masih bekerja. skrip uji ini juga dapat digunakan dengan beberapa perangkat tambahan untuk unit testing akhir yang sering dilakukan sebelum check-in modul.
7.2.1
Test-Driven
Development (TDD)
Test-Driven
Development (TDD) adalah proses coding yang berbalik pendekatan umum untuk
coding. Alih-alih menulis kode dan kemudian mengembangkan kasus uji untuk
memeriksa kode, di TDD itu adalah sebaliknya-programmer pertama menulis skrip
tes, dan kemudian menulis kode untuk lulus tes.
Beberapa poin yang perlu diperhatikan tentang TDD. Pertama, pendekatan mengatakan bahwa Anda menulis kode hanya cukup untuk lulus tes. Dengan mengikuti ini, kode ini selalu sinkron dengan tes. Hal ini tidak selalu terjadi dengan pendekatan kode-pertama, di mana itu semua terlalu umum untuk menulis sepotong panjang kode, tapi kemudian hanya menulis beberapa tes yang hanya mencakup beberapa bagian kode. Dengan mendorong kode yang ditulis hanya untuk lulus tes, tanggung jawab untuk memastikan bahwa fungsi yang dibutuhkan dibangun digeser ke aktivitas merancang uji kasus. Artinya, itu adalah tugas dari kasus uji untuk memeriksa bahwa kode yang akan dikembangkan memiliki semua fungsi yang diperlukan.
7.2.2
Pair
programming
Pair programming juga merupakan proses coding yang telah diusulkan sebagai metodologi kunci tech-nique dalam pemrograman ekstrim (XP) [7]. Dalam pemrograman pasangan, kode tidak ditulis oleh programmer individu tetapi oleh sepasang programmer. Artinya, pekerjaan coding ditugaskan untuk tidak individu tetapi untuk sepasang individu. Pasangan ini bersama-sama menulis kode.
Proses dipertimbangkan adalah bahwa satu orang akan ketik program sementara yang lain akan secara aktif berpartisipasi dan terus-menerus meninjau apa yang sedang diketik. Ketika kesalahan perhatikan, mereka menunjukkan dan diperbaiki. Jika diperlukan, pasangan membahas algoritma, struktur data, atau strategi yang akan digunakan dalam kode yang akan ditulis. Peran yang diputar sering membuat kedua pasangan sama dan memiliki peran yang sama.
7.3 Managing Evolving Code
Selama
proses coding, kode yang ditulis oleh programmer (atau sepasang) berkembang
mulai dari nol untuk akhirnya memiliki modul diuji dengan baik. Selama proses
ini kode mengalami perubahan. Selain perubahan karena proses pembangunan,
perubahan kode juga dibutuhkan karena perubahan spesifikasi modul, yang mungkin
terjadi karena perubahan persyaratan.
7.3.1 Source Code Control and Build
Sebuah
sistem kontrol sumber kode yang modern berisi repositori, yang pada dasarnya
adalah struktur direktori dikontrol, yang membuat sejarah revisi penuh dari
semua file yang dihasilkan oleh programmer yang berbeda dalam tim proyek. Untuk
efisiensi, sejarah berkas umumnya disimpan sebagai delta atau increment dari
file base. Hal ini memungkinkan setiap versi lama dari file yang akan
diciptakan, sehingga memberikan fleksibilitas untuk dengan mudah membuang
perubahan, harus perlu timbul. repositori adalah juga "resmi" sumber
untuk semua file.
Untuk
proyek, repositori harus diatur dengan izin untuk orang yang berbeda dalam
proyek. File-file repositori akan berisi juga ditentukan ini adalah file yang
evolusi repositori mempertahankan. Programmer menggunakan repositori untuk
membuat mereka perubahan file sumber yang tersedia, serta mendapatkan berkas
sumber lain. Beberapa jenis perintah yang umumnya dilakukan oleh seorang
programmer adalah:
- Dapatkan
salinan lokal. Seorang programmer di sebuah proyek bekerja pada salinan lokal
file. Perintah disediakan untuk membuat salinan lokal dari repositori. Membuat
salinan lokal umumnya disebut checkout. Contoh perintah cvs checkout
<module>, yang salinan satu set file yang dimiliki oleh <module>
pada mesin lokal. Seorang pengguna akan mendapatkan salinan terbaru dari file.
Namun, jika pengguna ingin, setiap versi lama dari file yang bisa diperoleh
dari repositori, sebagai sejarah lengkap dipertahankan. Banyak pengguna dapat
memeriksa file.
- Membuat
perubahan ke file (s). Perubahan yang dibuat ke file lokal dengan programmer
tetap lokal sampai perubahan berkomitmen kembali pada repositori. Dengan
melakukan (misalnya, oleh cvs commit <file>) perubahan yang dibuat ke
file lokal yang dibuat untuk repositori, dan oleh karenanya tersedia untuk
orang lain. Operasi ini juga disebut sebagai check-in.
- Memperbarui
salinan lokal. Perubahan yang dilakukan oleh anggota proyek untuk repositori
tidak tercermin dalam salinan lokal yang dibuat sebelum perubahan itu
dilakukan. Untuk mendapatkan perubahan, salinan lokal dari file harus diperbarui
(misalnya, oleh cvs perintah update). Dengan update, semua perubahan yang
dibuat untuk file-file tersebut tercermin dalam salinan lokal.
- Mendapatkan
laporan. alat kontrol sumber menyediakan sejumlah perintah untuk memberikan
laporan yang berbeda pada evolusi file. Ini termasuk laporan seperti perbedaan
antara file lokal dan versi terbaru dari file, semua perubahan yang dibuat ke
file bersama dengan tanggal dan alasan untuk perubahan (yang biasanya
disediakan saat melakukan perubahan).
Dengan sistem
kontrol kode sumber, programmer tidak perlu mempertahankan semua versi kapan
saja jika beberapa perubahan perlu dibatalkan, versi yang lebih tua dapat
dengan mudah ditemukan. Repositori selalu didukung, sehingga mereka juga
memberikan perlindungan terhadap kerugian disengaja. Selain itu, catatan
perubahan dipertahankan yang membuat perubahan dan kapan, mengapa perubahan
dibuat, apa yang menjadi perubahan yang sebenarnya, dll Yang paling penting,
repositori menyediakan tempat sentral untuk file-file terbaru dan berwibawa
proyek. Ini sangat berharga untuk produk yang memiliki umur panjang dan yang
berevolusi selama bertahun-tahun.
Selain
menggunakan repositori untuk menjaga versi yang berbeda, juga digunakan untuk
membangun sistem perangkat lunak dari sumber kegiatan sering disebut membangun.
membangun mendapatkan versi terbaru (atau versi yang diinginkan) dari
sumber-sumber dari repositori, dan menciptakan executable dari sumber.
7.3.2 Refactoring
Refactoring
adalah teknik untuk meningkatkan kode yang ada dan mencegah kerusakan desain
ini dengan waktu. Refactoring adalah bagian dari coding di bahwa itu dilakukan
selama masa coding, tetapi tidak coding biasa. Refactoring telah dipraktekkan
di masa lalu oleh programmer, tetapi baru-baru ini telah mengambil bentuk yang
lebih konkrit. Refactoring juga
memainkan peran penting dalam test-driven development-kode perbaikan langkah
dalam proses TDD benar-benar melakukan refactoring.
Tujuan
dasar dari refactoring adalah untuk memperbaiki desain. Namun, perlu diketahui
bahwa ini bukan tentang meningkatkan desain selama tahap desain untuk
menciptakan desain yang akan kemudian dilaksanakan (yang merupakan fokus dari
metodologi desain), tetapi tentang meningkatkan desain kode yang sudah ada.
Dengan kata lain, refactoring, meskipun dilakukan pada kode sumber, memiliki
tujuan untuk meningkatkan desain yang kode mengimplementasikan. Oleh karena
itu, prinsip-prinsip dasar desain memandu proses refactoring. Akibatnya,
refactoring umumnya menghasilkan satu atau lebih hal berikut:
1. Mengurangi kopling
2. kohesi Peningkatan
3. kepatuhan yang lebih baik untuk membuka-menutup
prinsip
Risiko
utama dari refactoring adalah bahwa ada kode kerja mungkin
"istirahat" karena perubahan yang dibuat. Ini adalah alasan utama
mengapa sering refactoring tidak dilakukan. (. Alasan lain adalah bahwa hal itu
dapat dilihat sebagai biaya tambahan dan tidak perlu) Untuk mengurangi risiko
ini, dua aturan emas adalah:
1. Refactor dalam langkah-langkah kecil
2. Memiliki tes skrip yang tersedia untuk menguji
fungsi yang ada
Dengan refactoring, kualitas desain membaik, sehingga
lebih mudah untuk melakukan perubahan kode serta menemukan bug. Jika perubahan
baru yang diperlukan yang tidak terpikirkan sebelumnya, atau jika kekurangan
yang ditemukan dalam desain, desain berubah melalui refactoring. Lebih sering
daripada tidak, fleksibilitas tambahan dipertimbangkan dan dirancang tidak
pernah diperlukan, sehingga sistem yang terlalu kompleks.
Kapan
refactoring diperlukan? Ada beberapa tanda-tanda yang mudah-spot dalam kode,
yang kadang-kadang disebut "bau buruk" [36], yang sering menunjukkan
bahwa beberapa sifat desain yang diinginkan dapat melanggar atau bahwa ada
potensi untuk meningkatkan desain. Dengan kata lain, jika Anda "bau"
salah satu dari ini "bau buruk," ini mungkin merupakan tanda bahwa
refactoring diperlukan. Beberapa dari bau buruk dari [36] yang diberikan di
sini:
1.
Kode Duplikat. Ini sangat
umum. Salah satu alasan untuk ini adalah bahwa beberapa fungsi kecil sedang
dijalankan di beberapa tempat (misalnya, usia dari tanggal lahir dapat dihitung
di setiap tempat yang membutuhkan tanggal).
2.
Metode Long. Jika metode
besar, sering menggambarkan situasi di mana ia mencoba untuk melakukan terlalu
banyak hal dan karena itu tidak kohesif.
3.
Panjang Class. Demikian
pula, kelas besar dapat menunjukkan bahwa itu encapsulating beberapa konsep,
membuat kelas tidak kohesif.
4.
Panjang Parameter Daftar.
interface yang kompleks jelas tidak diinginkan-mereka membuat kode lebih sulit
untuk mengerti. Seringkali, kompleksitas tidak intrinsik tetapi tanda desain
yang tidak tepat.
5.
Beralih Laporan. Dalam
program berorientasi objek, jika polimorfisme yang tidak digunakan dengan
benar, kemungkinan untuk menghasilkan pernyataan switch di mana-mana perilaku
adalah untuk menjadi di ff erent tergantung pada properti. Kehadiran laporan
beralih simi-lar di di ff tempat erent adalah tanda bahwa alih-alih menggunakan
hirarki kelas, beralih pernyataan sedang digunakan. Kehadiran pernyataan switch
membuat lebih sulit untuk memperpanjang kode-jika kategori baru yang akan
ditambahkan, semua pernyataan switch akan harus diubah.
6.
Generality spekulatif.
Beberapa hierarki kelas mungkin ada karena benda-benda di subclass tampaknya di
ff erent. Namun, jika perilaku objek subclass erent di ff adalah sama, dan
tidak ada alasan mendesak untuk berpikir bahwa perilaku mungkin berubah, maka
itu adalah kasus kompleksitas yang tidak perlu.
7.
Terlalu Banyak Komunikasi
Antara Objek. Jika metode dalam satu kelas membuat banyak panggilan ke metode
objek lain untuk mencari tahu tentang keadaan, ini adalah tanda kopling kuat.
Ada kemungkinan bahwa ini mungkin tidak diperlukan dan karenanya situasi
tersebut harus diperiksa untuk refactoring.
8.
Pesan Chaining. Salah
satu metode panggilan metode lain, yang hanya melewati panggilan ini ke objek
lain, dan sebagainya. rantai ini berpotensi menyebabkan kopling yang tidak
perlu.
7.4 Unit Testing
Driver memainkan peran
"memanggil" modul dan sering bertanggung jawab untuk mendapatkan data
tes, melaksanakan unit dengan data uji, dan kemudian melaporkan hasilnya.
Bertopik dasarnya "bodoh" modul yang digunakan di tempat modul yang
sebenarnya untuk memfasilitasi unit testing. Jadi, jika modul M menggunakan
layanan dari modul N lain yang belum dikembangkan, maka untuk unit testing M,
beberapa rintisan untuk N harus ditulis sehingga M dapat meminta layanan dalam
beberapa cara pada N sehingga unit testing bisa memproses. Kebutuhan bertopik
dapat dihindari, jika coding dan pengujian hasil dalam bottom-up dengan
cara-modul pada tingkat yang lebih rendah dikodekan dan diuji pertama sehingga
ketika modul pada tingkat yang lebih tinggi dari hirarki diuji, kode untuk
modul-tingkat yang lebih rendah sudah tersedia.
Jika coding tambahan dipraktekkan, seperti dibahas di atas, maka unit testing perlu dilakukan setiap kali programmer menambahkan beberapa kode. Jelas, itu akan jauh lebih e FFI efisien jika bukan melaksanakan unit dan memberikan masukan secara manual, pelaksanaan uji kasus otomatis. Kemudian uji kasus dapat dilaksanakan dengan mudah setiap kali pengujian perlu dilakukan. Beberapa alat yang tersedia untuk memfasilitasi ini. Di sini kita membahas beberapa pendekatan untuk unit testing menggunakan kerangka pengujian.
Jika coding tambahan dipraktekkan, seperti dibahas di atas, maka unit testing perlu dilakukan setiap kali programmer menambahkan beberapa kode. Jelas, itu akan jauh lebih e FFI efisien jika bukan melaksanakan unit dan memberikan masukan secara manual, pelaksanaan uji kasus otomatis. Kemudian uji kasus dapat dilaksanakan dengan mudah setiap kali pengujian perlu dilakukan. Beberapa alat yang tersedia untuk memfasilitasi ini. Di sini kita membahas beberapa pendekatan untuk unit testing menggunakan kerangka pengujian.
7.4.1 Testing Procedural Units
Pengujian
modul dengan kasus uji Maka akan
melibatkan Langkah-Langkah berikut:
1. Mengatur
sistem negara yang diperlukan oleh uji kasus ini.
2. Nilai
Set parameter sesuai.
3. Panggil prosedur f () dengan parameter.
4. Bandingkan
hasil f dengan hasil yang diharapkan
5. Menyatakan
apakah kasus uji telah berhasil atau gagal
Yang
paling sederhana dan umum digunakan pendekatan untuk mengeksekusi urutan
langkah adalah untuk menulis sebuah program utama () yang mengeksekusi tiga
langkah pertama, dengan nilai-nilai yang diberikan sebagai masukan oleh tester
atau membaca dari sebuah file atau hard dikodekan dalam program, dan kemudian
mencetak nilai-nilai penting. programmer kemudian mengeksekusi dua langkah
terakhir, yaitu, membandingkan hasil dengan yang diharapkan dan memutuskan apakah
tes telah berhasil atau gagal. Karena kebutuhan intervensi programmer untuk
mengevaluasi output, dan mungkin juga untuk memberikan masukan, pendekatan ini
tidak mudah untuk skala.
Setelah kasus uji dirancang, ini urutan langkah tetap tetap dan karenanya sangat ideal untuk otomatisasi lengkap. Dalam kerangka pengujian, sering kasus uji akan dinyatakan sebagai fungsi di mana ini urutan langkah-langkah dijalankan untuk itu ujian, termasuk pengecekan hasil dan menyatakan hasil-ini yang dilakukan sering dengan bantuan laporan menegaskan tersedia oleh framework. Sebuah tes suite maka kumpulan fungsi-fungsi ini, dan pelaksanaan tes suite berarti masing-masing fungsi dijalankan. Test suite berhasil jika semua kasus uji sukses. Jika kasus uji gagal, maka kerangka tes akan memutuskan apakah akan melanjutkan mengeksekusi atau berhenti.
Dengan kerangka kerja tes ini, setiap kasus uji didefinisikan sebagai fungsi. Fungsi berakhir dengan beberapa pernyataan (disediakan oleh framework) yang tes untuk beberapa kondisi untuk menyatakan apakah tes telah gagal atau berhasil. Setiap fungsi yang mewakili unit tes ditambahkan ke array atau struktur, yang merupakan test suite. Beberapa suite tes juga dapat dibuat. Seringkali ada satu fungsi pengemudi yang suite ini berlalu dan yang kemudian mengeksekusi semua kasus uji.
Setelah kasus uji dirancang, ini urutan langkah tetap tetap dan karenanya sangat ideal untuk otomatisasi lengkap. Dalam kerangka pengujian, sering kasus uji akan dinyatakan sebagai fungsi di mana ini urutan langkah-langkah dijalankan untuk itu ujian, termasuk pengecekan hasil dan menyatakan hasil-ini yang dilakukan sering dengan bantuan laporan menegaskan tersedia oleh framework. Sebuah tes suite maka kumpulan fungsi-fungsi ini, dan pelaksanaan tes suite berarti masing-masing fungsi dijalankan. Test suite berhasil jika semua kasus uji sukses. Jika kasus uji gagal, maka kerangka tes akan memutuskan apakah akan melanjutkan mengeksekusi atau berhenti.
Dengan kerangka kerja tes ini, setiap kasus uji didefinisikan sebagai fungsi. Fungsi berakhir dengan beberapa pernyataan (disediakan oleh framework) yang tes untuk beberapa kondisi untuk menyatakan apakah tes telah gagal atau berhasil. Setiap fungsi yang mewakili unit tes ditambahkan ke array atau struktur, yang merupakan test suite. Beberapa suite tes juga dapat dibuat. Seringkali ada satu fungsi pengemudi yang suite ini berlalu dan yang kemudian mengeksekusi semua kasus uji.
7.4.2 Pengujian
Unit Kelas
Dalam
program berorientasi objek, unit yang akan diuji biasanya objek kelas. Untuk
menguji kelas, programmer perlu menciptakan sebuah objek dari kelas itu,
mengambil objek untuk negara tertentu, memanggil metode di atasnya, dan
kemudian memeriksa apakah keadaan objek tersebut seperti yang diharapkan.
Urutan ini harus dijalankan berkali-kali untuk sebuah metode, dan harus
dilakukan untuk semua metode. Semua ini difasilitasi jika kita menggunakan
kerangka kerja seperti Junit (www.junit.org). Meskipun Junit sendiri untuk Java, kerangka serupa telah
dikembangkan untuk bahasa lain seperti C ++ dan C #. Untuk memeriksa hasil, Junit menyediakan dua metode
khusus Menegaskan-Benar (ekspresi boolean) dan Menegaskan-Salah (ekspresi boolean).
Untuk unit
pengujian kelas Matrix, jelas kita perlu menguji operasi standar seperti
penciptaan matriks, pengaturan nilai-nilai, dll. Dan perlu menguji apakah operasi seperti menambah,
mengurangi, mengalikan, penentu kinerja seperti yang diharapkan.
7.5 Kode Inspeksi
Kode
inspeksi adalah teknik lain yang sering diterapkan pada
tingkat unit. Hal ini dapat dilihat sebagai "pengujian statis" di
mana cacat terdeteksi dalam kode tidak dengan mengeksekusi kode tetapi melalui
proses manual. Kode inspeksi seperti pengujian, diterapkan hampir seluruhnya
di tingkat unit, yaitu, hanya unit program
yang menjadi sasaran pemeriksaan.
Pemeriksaan adalah pendekatan verifikasi umum yang dapat
diterapkan untuk mendeteksi cacat pada dokumen. Kode
inspeksi pertama kali diusulkan oleh Fagan [31, 32].
Tujuan dasar dari inspeksi adalah untuk meningkatkan kualitas kode.
Beberapa karakteristik kunci dari inspeksi adalah:
- Kode Inspeksi dilakukan oleh programmer dan
untuk programmer.
- Ini adalah proses yang terstruktur dengan peran yang
ditetapkan untuk peserta.
- Fokusnya pada identifikasi cacat, tetapi
tidak memperbaiki.
- Inspeksi data yang dicatat digunakan untuk memantau efektifitas dari proses
pemeriksaan.
Inspeksi
dilakukan oleh tim ulasan (atau inspektur) termasuk penulis, dengan satu dari
mereka menjadi moderator. Moderator memiliki tanggung jawab keseluruhan untuk
memastikan bahwa review dilakukan dengan cara yang tepat dan semua langkah
dalam proses peninjauan.
7.5.1
Perencanaan
Tujuan dari
tahap perencanaan adalah untuk mempersiapkan pemeriksaan. Tim harus terdiri dari setidaknya tiga
orang, meskipun kadang-kadang tim empat atau lima anggota
dan seorang moderator.
Penulis
kode memastikan bahwa kode siap untuk diperiksa.
Tujuan kode inspeksi adalah untuk meningkatkan kualitas. Selain cacat coding, ada masalah kualitas lain,
seperti effisiensi, kepatuhan terhadap standar coding, dll.
Pada fase ini, setiap resensi melakukan tinjauan
diri dari kode. Selama peninjauan diri, resensi melewati seluruh kode dan log
semua cacat potensial ia menemukan di log persiapan diri. Seringkali pengulas
akan menandai cacat pada produk pekerjaan itu sendiri, dan dapat memberikan
ringkasan dari tinjauan diri dalam log. Pengulas juga mencatat waktu yang
mereka habiskan dalam tinjauan diri. Sebuah bentuk standar dapat digunakan
untuk log persiapan diri; contoh formulir ditunjukkan pada gambar di bawah ini:
Idealnya, review diri harus dilakukan dalam satu
rentang waktu kontinu. Waktu yang disarankan adalah kurang dari dua jam-yaitu,
produk kerja cukup kecil sehingga dapat diperiksa secara penuh dalam waktu
kurang dari dua jam. Fase ini dari proses peninjauan berakhir ketika semua
pengulas telah benar dilakukan mereka diri review dan mengisi diri log
peninjauan.
7.5.3 Group Meeting Ulasan
Tujuan dasar dari pertemuan kajian kelompok
adalah untuk datang dengan daftar cacat akhir, berdasarkan daftar awal dari
cacat yang dilaporkan oleh pengulas dan yang baru ditemukan selama pembahasan
dalam pertemuan tersebut. Kriteria masuk untuk langkah ini adalah bahwa
moderator puas bahwa semua pengulas siap untuk pertemuan. Keluaran utama dari
tahap ini adalah log cacat dan ringkasan laporan cacat.
Moderator pertama memeriksa untuk melihat apakah
semua pengulas siap. Hal ini dilakukan dengan upaya pemeriksaan singkat dan
cacat data dalam diri-review log mengkonfirmasi bahwa waktu yang cukup efisien
dan dalam melakukan persiapan. Ketika persiapan tidak memadai, review kelompok
ditangguhkan sampai semua peserta sepenuhnya siap dan langsung review pertemuan
kelompok diadakan. moderator bertugas pertemuan dan harus memastikan bahwa
pertemuan itu tetap fokus pada tujuan dasar identifikasi cacat dan tidak
berubah menjadi sesi brainstorming umum atau serangan pribadi pada penulis.
Cacat log terakhir adalah catatan resmi dari
cacat diidentifikasi dalam inspeksi dan juga dapat digunakan untuk melacak
cacat penutupan. Untuk menganalisis efektivitas pemeriksaan, namun, informasi
hanya ringkasan tingkat yang diperlukan, yang laporan ringkasan siap. Ringkasan
laporan menjelaskan kode, total usaha yang dihabiskan dan perpisahan dalam
kegiatan proses review yang berbeda, jumlah cacat yang ditemukan untuk setiap
kategori, dan ukuran. Jika jenis cacat juga dicatat, maka jumlah cacat dalam
setiap kategori dapat juga disimpan dalam ringkasan. Sebuah laporan Ringkasan
terisi sebagian ditunjukkan pada diatas.
Ringkasan laporan ini cukup jelas. Total jumlah
cacat kecil ditemukan adalah 8, dan jumlah cacat utama yang ditemukan adalah 3.
Artinya, kepadatan cacat ditemukan adalah 8 / 0.250 = 32 cacat kecil per KLOC,
dan 3 / 0,25 = 12 cacat utama per KLOC. Dari pengalaman, kedua angka ini berada
dalam kisaran terlihat di masa lalu; maka dapat diasumsikan bahwa review ini dilakukan
dengan benar. Tim peninjau memiliki 3 anggota, dan masing-masing telah
menghabiskan sekitar 1,5 jam di review individu dan pertemuan kajian
berlangsung 1 jam. Ini berarti bahwa tingkat persiapan sekitar 180 LOC per jam,
dan kelompok ulasan rate 250 LOC per jam, yang keduanya, dari pengalaman masa
lalu, juga tampak diterima.
Jika modifikasi yang diperlukan untuk
memperbaiki cacat dan menyikapi yaitu-menggugat beberapa, maka status ulasan
kelompok "diterima." Jika modifikasi yang diperlukan banyak, pertemuan
tindak lanjut oleh moderator atau peninjauan ulang mungkin diperlukan untuk
memverifikasi apakah perubahan telah dimasukkan dengan benar. moderator
merekomendasikan apa yang harus dilakukan. Selain itu, rekomendasi mengenai
ulasan pada tahap berikutnya juga dapat dilakukan (kode misalnya, dalam
tinjauan rinci-desain itu dapat direkomendasikan yang modul harus menjalani
inspeksi).
7.6.1 Tindakan Ukuran
Ukuran produk adalah ukuran sederhana, yang
dapat mudah untuk menghitung. Ukuran sendiri adalah menggunakan sedikit; itu
adalah hubungan ukuran dengan biaya dan kualitas yang membuat ukuran metrik
penting. Hal ini juga digunakan untuk mengukur produktivitas selama proyek
(misalnya, KLOC per orang-bulan). kualitas akhir yang disampaikan oleh sebuah
proses juga sering dinormalisasi sehubungan dengan ukuran (jumlah cacat per
KLOC).
LOC digunakan sebagai ukuran ukuran. Bahkan
untuk bahasa yang sama, ukuran dapat bervariasi tergantung pada bagaimana garis
dihitung. Meskipun kekurangan ini, LOC tetap menjadi ukuran berguna dan masuk
akal yang digunakan secara luas. Saat ini, mungkin metode penghitungan yang
paling banyak digunakan untuk menentukan ukuran adalah dengan menghitung
noncomment, garis tidak kosong saja.
- n1 adalah jumlah operator yang
berbeda
- n2 adalah jumlah operan yang
berbeda
- jumlah
kejadian dari j operator yang paling sering
- jumlah
kejadian dari j operan yang paling sering
kosakata n dari sebuah
program didefinisikan sebagai:
Dengan parameter terukur
yang terdaftar sebelumnya, dua parameter baru didefinisikan:
N1 adalah total
kejadian operator yang berbeda dalam program dan N2 adalah total
kejadian dari operan yang berbeda. Panjang dari program ini didefinisikan
sebagai:
Dari panjang dan kosa
kata, volume V dari program didefinisikan sebagai
definisi volume program
mewakili jumlah minimum bit diperlukan untuk mewakili program. log2(n)
adalah jumlah bit yang diperlukan untuk mewakili setiap elemen dalam program
unik, dan N adalah total terjadi-rences dari unsur-unsur yang berbeda. Volume
digunakan sebagai ukuran metrik untuk suatu program. Percobaan telah
menunjukkan bahwa volume sebuah program sangat berkorelasi dengan ukuran di
LOC.
7.6.2 Kompleksitas Metrik
Kompleksitas memiliki dampak yang besar pada
biaya pemeliharaan program. Untuk mengukur kompleksitas luar gagasan kabur dari
kemudahan yang program dapat dibangun atau dipahami, beberapa metrik untuk
mengukur kompleksitas program yang dibutuhkan.
Cyclomatic Kompleksitas Berdasarkan kemampuan
pikiran manusia dan pengalaman orang, umumnya diakui bahwa kondisi dan
pernyataan kontrol menambahkan kompleksitas program. Ukuran paling sederhana adalah
jumlah konstruksi yang mewakili cabang di aliran kontrol dari program, seperti
pernyataan if then else, while do, repeat
until dan goto.
Sebuah ukuran yang lebih halus adalah ukuran
kompleksitas cyclomatic diusulkan oleh McCabe, yang merupakan konsep
graph-teori berbasis. Untuk graf G dengan n simpul, e tepi, dan komponen
terhubung p, jumlah cyclomatic V (G) didefinisikan sebagai
Untuk menggunakan ini untuk menentukan
kompleksitas cyclomatic dari modul, aliran kontrol grafik G dari modul pertama
ditarik. Untuk membangun sebuah grafik kontrol aliran dari modul program,
memecah modul ke dalam blok dibatasi oleh laporan yang mempengaruhi aliran
kontrol, seperti jika, sementara, ulangi, dan goto. blok ini membentuk node dari
grafik. Jika kontrol dari blok saya dapat cabang ke blok j, kemudian menarik
busur dari simpul i ke simpul j dalam grafik. Aliran kontrol dari program dapat
dibangun secara mekanis. Sebagai contoh, mempertimbangkan fungsi C-seperti
untuk menyortir bubble, diberikan berikutnya. Grafik kontrol aliran untuk ini
diberikan pada Gambar 7.7.
Grafik modul memiliki simpul entri dan simpul
keluar, sesuai dengan blok pertama dan terakhir dari pernyataan (atau kita
dapat membuat node buatan untuk kesederhanaan, seperti pada contoh). Dalam
grafik tersebut akan ada jalur dari node masuk ke setiap node dan jalur dari
setiap node ke node keluar (dengan asumsi program tidak memiliki anomali
seperti kode unreachable). Untuk grafik tersebut, jumlah cyclomatic dapat 0
jika kode adalah urutan linear dari laporan tanpa pernyataan kontrol. Jika kita
menarik busur dari node keluar ke node entri, grafik akan sangat terhubung
karena ada jalur antara dua node. Jumlah cyclomatic dari grafik untuk program
apapun maka akan nol, dan itu diinginkan untuk memiliki kompleksitas nol untuk
program yang sederhana tanpa persyaratan apa pun (setelah semua, ada beberapa
kompleksitas dalam program seperti itu). Oleh karena itu, untuk menghitung
kompleksitas cyclomatic program, busur ditambahkan dari node keluar ke awal
node, yang membuatnya grafik sangat terhubung. Untuk modul, kompleksitas
cyclomatic didefinisikan sebagai jumlah cyclomatic dari grafik tersebut untuk
modul.
Ternyata kompleksitas cyclomatic dari modul
(atau nomor cyclomatic dari grafiknya) adalah sama dengan jumlah maksimum
sirkuit bebas linear dalam grafik. Satu set rangkaian linear jika ada sirkuit
yang benar-benar terkandung dalam sirkuit lain atau merupakan kombinasi dari
sirkuit lainnya. Jadi, untuk menghitung jumlah cyclomatic dari modul, kita
dapat menarik grafik, membuatnya terhubung dengan menggambar busur dari node
keluar ke node masuk, dan kemudian menghitung jumlah sirkuit atau menghitung
dengan menghitung jumlah tepi dan node. Dalam grafik yang ditunjukkan pada
Gambar 7.7, kompleksitas cyclomatic adalah
McCabe mengusulkan bahwa kompleksitas cyclomatic
modul harus, secara umum, disimpan di bawah 10. Jumlah cyclomatic juga dapat
digunakan sebagai jumlah jalur yang harus diuji selama pengujian. kompleksitas
cyclomatic adalah salah satu langkah kompleksitas yang paling banyak digunakan.
Percobaan menunjukkan bahwa kompleksitas cyclomatic sangat berkorelasi dengan
ukuran modul di LOC (setelah semua, lebih baris kode semakin besar jumlah
keputusan). Ini juga telah ditemukan berkorelasi dengan jumlah kesalahan yang
ditemukan dalam modul
Logika modul tidak secara eksplisit. Logikanya
hanya digunakan untuk menentukan pernyataan pertama dan terakhir dari referensi
untuk variabel. Oleh karena itu, konsep ini kompleksitas cukup berbeda dari
kompleksitas cyclomatic, yang didasarkan sepenuhnya pada logika dan menganggap
data sekunder.
Penggunaan berorientasi Data Konsep lain adalah
rentang, jumlah laporan antara dua penggunaan yang berurutan dari variabel.
Jika variabel direferensikan ditempat yg berbeda dalam modul, maka untuk
variabel yang ada (n - 1) meliputi. Ukuran rentang rata-rata adalah rata-rata
jumlah laporan dieksekusi antara dua referensi yang berurutan dari variabel.
Sebuah rentang besar menyiratkan bahwa pembaca program harus ingat definisi
variabel untuk jangka waktu yang lebih besar (atau untuk laporan lebih). Dengan
kata lain, rentang dapat dianggap sebagai ukuran kompleksitas; semakin besar
rentang, semakin kompleks modul.
Knot Hitung Sebuah metode untuk mengukur
kompleksitas berdasarkan lokasi dari transfer kontrol dari program tersebut
telah diusulkan dalam. Ia dirancang terutama untuk program FORTRAN, di mana
transfer eksplisit kontrol ditunjukkan dengan menggunakan pernyataan goto.
Seorang programmer, untuk memahami program yang diberikan, biasanya menarik
panah dari titik transfer kontrol ke tujuannya, membantu menciptakan gambaran
mental dari program dan transfer kontrol di dalamnya. Menurut metrik ini,
semakin terjalin panah ini menjadi, semakin kompleks program. Gagasan ini
ditangkap di konsep "simpul."
Sebuah simpul pada dasarnya adalah persimpangan
dua panah mentransfer kontrol tersebut. Jika setiap pernyataan dalam program
ini ditulis pada baris terpisah, gagasan ini dapat diformalkan sebagai berikut.
Sebuah melompat dari baris ke baris b diwakili oleh pasangan (a, b). Dua
lompatan (a, b) dan (p, q) menimbulkan simpul jika salah min (a, b) <min (p,
q) <max (a, b) dan max (p, q)> max (a, b); atau min (a, b) <max (p, qa)
<max (a, b) dan min (p, q) <min (a, b).
Masalah bisa timbul saat menentukan jumlah
simpul dari program menggunakan konstruksi terstruktur. Salah satu metode
adalah untuk mengkonversi program seperti itu menjadi salah satu yang secara
eksplisit menunjukkan transfer kontrol dan kemudian menghitung jumlah simpul.
Skema dasar dapat digeneralisasi mengalir grafik, meskipun dengan grafik aliran
hanya batas dapat diperoleh.
Topological Kompleksitas Sebuah ukuran
kompleksitas yang sensitif terhadap bersarang struktur telah diusulkan dalam.
Seperti kompleksitas cyclomatic, itu didasarkan pada grafik aliran modul atau
program. Kompleksitas program dianggap jumlah maksimal berpotongan nya min.
Untuk menghitung berpotongan maksimal, grafik
aliran diubah menjadi grafik sangat terhubung (dengan menggambar panah dari
simpul terminal ke node awal). Sebuah grafik sangat terhubung membagi grafik ke
dalam jumlah terbatas dari daerah. Jumlah daerah adalah (tepi - node + 2). Jika
kita menarik garis yang masuk setiap daerah tepat satu kali, maka jumlah kali
baris ini memotong busur dalam grafik maksimal yang berpotongan min, yang
diambil menjadi kompleksitas program.
Tidak ada komentar:
Posting Komentar