Tugas Jaringan Komputer 14

Muhammad Irfan Faisal

43A87007150396

S1 / SISTEM INFORMASI 4B P

Tugas Jaringan Komputer 13

Muhammad Irfan Faisal

43A87007150396

S1 / SISTEM INFORMASI 4B P

Testing

Bab8 Testing

Dalam proyek pengembangan perangkat lunak, kesalahan dapat diperkenalkan pada setiap tahap pembangunan. Beberapa kesalahan tetap tidak terdeteksi. Pada akhirnya, tercermin dalam kode kesalahan. Oleh karena itu, kode akhir kemungkinan untuk memiliki beberapa requirements kesalahan dan kesalahan desain.

Ada dua jenis pendekatan untuk mengidentifikasi cacat pada software statis dan dinamis. Dalam analisis statis, kode ini tidak dijalankan tetapi dievaluasi melalui beberapa proses atau beberapa alat untuk mencari cacat. Dibahas dalam bab sebelumnya dalam analisis dinamis, kode adalah dieksekusi. Pengujian adalah teknik paling umum dinamis yang digunakan memang pengujian adalah yang paling umum digunakan. Selama pengujian, perangkat lunak yang diuji dijalankan dengan himpunan kasus uji dan perilaku sistem dievaluasi untuk uji kasus sistem ini.

Dalam bab ini kita akan membahas:

- Konsep dasar dan definisi yang berkaitan dengan pengujian, seperti kesalahan, kegagalan,
  uji kasus, test suite, memanfaatkan uji, dll
- Proses pengujian direncanakan pengujian-bagaimana dan bagaimana pengujian unit adalah
  dilakukan.
- Temukan Uji kasus menggunakan kotak hitam pendekatan pengujian.
- Seleksi kasus uji pendekatan menggunakan kotak putih.
- Beberapa cakupan dan kehandalan metrik seperti bekerja khi PPK Test

8.1 Konsep Pengujian

        Pada bagian ini pertama kami akan mendefinisikan beberapa istilah yang umum digunakan membahas pengujian. Kemudian beberapa dasar kami akan diskusikan masalah yang berhubungan dengan bagaimana dilakukan pengujian, dan pentingnya psikologi tester.

8.1.1 Kesalahan dan Kegagalan

        Ketika mendiskusikan biasanya menggunakan istilah-istilah seperti pengujian kesalahan,kegagalan dll mari kita mulai dengan mendefinisikan konsep digunakan dalam dua cara yang berbeda. Ini mengacu perbedaan tersebut antara nilai hitung, terpantau, atau diukur dan benar atau nilai teoritis yang benar. Artinya, kesalahan perbedaan mengacu untuk output aktual dari perangkat lunak dan output yang benar. Dalam interpretasi ini, kesalahan pada dasarnya adalah ukuran perbedaan antara aktual dan ideal. Kesalahan digunakan untuk merujuk pada hasil tindakan dalam perangkat lunak  atau kesalahan. Definisi ini cukup umum dan mencakup semua tahap dan kondisi penyebab kesalahan sistem. Sebuah kesalahan adalah alasan dasar untuk kerusakan perangkat lunak dan umumnya menggunakan istilah identik dengan bug, ataun lebih umum cacat jangka. Ada konsekuensi langsung pada pengujian,pengujian ini tidak mengamati kesalahan, kami tidak bisa mengatakan sesuatu tentang keberadaan atau kesalahan dalam sistem.

8.1.2 Uji Kasus, Test Suite, dan Test Harness

        Sejauh ini digunakan kasus uji istilah atau mengatur kasus uji informal. Mari kita mendefinisikan lebih tepatnya menambahkan. Sekelompok kasus uji terkait umumnya dilaksanakan bersama-sama untuk menguji beberapa perilaku tertentu atau aspek dari pengujian yang dimaksud dengan sering dilakukan adalah tes suite. Catatan dalam kasus uji, masukan uji dan eksekusi disebutkan secara terpisah. Uji input adalah nilai-nilai tertentu dari parameter atau masukan lainnya diberikan kepada pengguna atau program lain. Eksekusi mencerminkan keadaan dari sistem. Jadi, saat uji coba fungsi untuk menambahkan catatan dalam database sudah ada, perilaku fungsi tergantung pada nilai dari keduanya. Tampilan rekor sebagai masukan serta keadaan database. Misalnya, kasus uji untuk fungsi ini mungkin rekord sebagai masukan, dan mungkin dari database sudah ada. Pengujian dapat dilakukan secara manual dengan tester melaksanakan uji kasus ditest suite dan kemudian memeriksa apakah perilaku tersebut dalam kasus uji. Ini adalah proses yang sangat rumit, test suite berisi jumlah kasus uji. Ini menjadi lebih rumit sejak test suite telah akan dieksekusi. Oleh karena itu, saat ini tren adalah untuk otomatis pengujian. Dengan pengujian otomatis, kasus uji biasanya melakukan semua kegiatan uji kasus-set data uji. Hasil yang diharapkan, dan mendeklarasikan untuk tester yang gagal atau lulus. Sebuah test suite mengatur fungsi, masing-masing mewakili kasus uji. Untuk menguji dengan test suite, tes script otomatis umumnya meminta uji kasus dalam urutan yang diinginkan.

        Untuk memiliki suite tes dieksekusi secara otomatis, kami akan membutuhkan kerangka didefinisikan input, masukan dapat digunakan oleh fungsi yang didefinisikan mewakili uji kasus, tes script otomatis dapat dieksekusi oleh script. Dan hasil pengujian seluruh dilaporkan ketester. Banyak kerangka pengujian sekarang ada izin yang harus dilakukan semua dalam cara sederhana. Sebuah kerangka pengujian adalah tes harness juga kadang-kadang pemerintah Indonesia memanfaatkan uji atau kerangka uji tester untuk membuat kehidupan sederhana dengan mudah mendefinisikan test suite. Dengan kerangka tes, tes suite didefinisikan sekali, dan kemudian setiap kali diperlukan,pengujian lengkap dapat dilakukan dengan klik tombol atau memberikan perintah.

8.1.3 Psikologi Pengujian

        Sebuah tujuan dasar pengujian adalah untuk mendeteksi kesalahan yang mungkin ada dalam program ini. Oleh karena itu, seseorang tidak harus memulai pengujian dengan maksud menunjukkan bahwa program bekerja melainkan ; untuk mengungkapkan cacat yang mungkin ada. Karena ini, pengujian juga telah didefinisikan sebagai proses eksekusi program dengan maksud menemukan kesalahan.

8.1.4 Tingkat Pengujian

        Pengujian biasanya diandalkan untuk mendeteksi kesalahan yang tersisa dari tahap awal, di samping kesalahan diperkenalkan selama coding sendiri. Karena ini, tingkat berbeda pengujian yang digunakan dalam proses pengujian; setiap tingkat pengujian bertujuan untuk menguji di aspek berbeda dari sistem.

      Tingkat pertama pengujian disebut unit testing, Unit pengujian pada dasarnya untuk verifikasi kode yang dihasilkan oleh programmer individu, dan biasanya dilakukan oleh programmer dari modul.

        Tingkat berikutnya pengujian sering disebut pengujian integrasi. Dalam hal ini, banyak unit diuji modul digabungkan menjadi subsistem, yang kemudian diuji. Tujuannya di sini adalah untuk melihat apakah modul dapat diintegrasikan dengan benar. Kegiatan pengujian ini dapat dianggap menguji desain.

        Tingkat berikutnya adalah pengujian sistem dan pengujian penerimaan. Berikut seluruh sistem perangkat lunak diuji.pengujian penerimaan sering dilakukan dengan data yang realistis dari klien untuk menunjukkan bahwa perangkat lunak bekerja memuaskan. pengujian penerimaan dasarnya menguji apakah sistem memuaskan memecahkan masalah bagi yang ditugaskan.

        Ada lagi tingkat pengujian, yang disebut pengujian regresi, yang dilakukan ketika beberapa perubahan yang dibuat untuk sistem yang ada. selain memastikan perilaku yang diinginkan dari layanan baru, pengujian harus memastikan bahwa perilaku yang diinginkan dari layanan lama dipertahankan. Ini adalah tugas dari pengujian regresi.

8.2 Proses Pengujian

        Tujuan dasar dari proses pengembangan perangkat lunak adalah untuk menghasilkan perangkat lunak yang tidak memiliki kesalahan atau sangat sedikit kesalahan. Pengujian adalah kegiatan pengendalian kualitas yang berfokus pada identifikasi cacat (yang kemudian dihapus). Proses pengujian untuk sebuah proyek terdiri dari perencanaan tiga tingkat tinggi tugas-test, desain uji kasus, dan pelaksanaan tes.

8.2.1 Perencanaan Pengujian

        Secara umum, dalam sebuah proyek, pengujian dimulai dengan rencana uji dan berakhir dengan keberhasilan pelaksanaan pengujian penerimaan. Sebuah rencana uji adalah dokumen-ment umum untuk seluruh proyek yang mendefinisikan ruang lingkup, pendekatan yang akan diambil, dan jadwal pengujian, serta mengidentifikasi item tes untuk pengujian dan personil yang bertanggung jawab untuk kegiatan berbeda  pengujian. Rencana pengujian dapat dilakukan dengan baik sebelum pengujian yang sebenarnya dimulai dan dapat dilakukan di par-alel dengan kegiatan coding dan desain. Input untuk membentuk rencana uji adalah: (1) rencana proyek, (2) dokumen persyaratan, dan (3) arsitektur atau dokumen desain.

        Rencana proyek diperlukan untuk memastikan bahwa rencana uji konsisten dengan rencana mutu secara keseluruhan untuk proyek dan jadwal pengujian cocok dengan rencana proyek. Sebuah rencana uji harus berisi sebagai berikut:

- Spesifikasi Unit Uji
- Fitur yang akan diuji
- Pendekatan untuk pengujian
- Kiriman Uji
- Jadwal dan tugas alokasi

        Merupakan faktor penting saat membentuk unit adalah "testability" dari unit. Sebuah unit harus sedemikian rupa sehingga dapat dengan mudah diuji. Misalnya, sebuah modul yang memanipulasi struktur data yang kompleks dibentuk dari input file dengan modul masukan mungkin tidak menjadi unit yang sesuai dari sudut pandang testability, sebagai pembentuk bermakna kasus uji untuk unit akan sulit, dan sopir rutinitas akan telah ditulis untuk mengkonversi masukan dari file atau terminal yang diberikan oleh tester ke dalam struktur data yang sesuai untuk modul. Sebuah fitur software adalah karakteristik software spesifik atau tersirat oleh persyaratan atau dokumen desain. Ini mungkin termasuk fungsi, kinerja, kendala desain, dan atribut.

        Pendekatan untuk pengujian menentukan pendekatan keseluruhan yang harus diikuti dalam proyek ini. Teknik-teknik yang akan digunakan untuk menilai upaya pengujian juga harus ditentukan. Hal ini kadang-kadang disebut kriteria pengujian atau kriteria untuk mengevaluasi set kasus uji yang digunakan dalam pengujian.

        Kiriman pengujian harus ditentukan dalam rencana uji sebelum pengujian yang sebenarnya dimulai. Kiriman bisa menjadi daftar kasus uji yang digunakan, hasil rinci dari pengujian termasuk daftar cacat yang ditemukan, ringkasan laporan tes, dan data tentang cakupan kode.

        Jadwal ini harus konsisten dengan jadwal proyek secara keseluruhan. Banyak produk besar memiliki tim pengujian terpisah dan karena rencana tes terpisah.

8.2.2 Uji Kasus Desain

        Rencana uji berfokus pada bagaimana pengujian untuk proyek tersebut akan dilanjutkan, yang mana unit akan diuji, dan apa pendekatan (alat) yang akan digunakan selama berbagai tahap pengujian. Namun, itu tidak berurusan dengan rincian pengujian unit, juga tidak menentukan uji kasus yang akan digunakan.

      Pengujian memiliki keterbatasan dan efektivitas pengujian sangat bergantung pada sifat yang tepat dari uji kasus. Oleh karena itu penting untuk memastikan bahwa himpunan kasus uji yang digunakan adalah kualitas tinggi. Evaluasi kasus uji sering dilakukan melalui review uji kasus. Adapun setiap review, dokumen atau pekerjaan produk formal diperlukan untuk meninjau kasus uji. Ini adalah alasan utama untuk mendokumentasikan kasus uji. Kasus uji dokumen spesifikasi ditinjau menggunakan proses formal, untuk memastikan bahwa uji kasus konsisten dengan kebijakan yang ditetapkan dalam rencana, memenuhi kriteria yang dipilih, dan mencakup berbagai aspek unit yang akan diuji.

8.2.3 Uji Eksekusi Kasus

        Dengan spesifikasi kasus uji, langkah berikutnya dalam proses pengujian adalah untuk 
mengeksekusi. Langkah ini juga tidak mudah. Test spesifikasi kasus hanya menentukan set 
kasus uji untuk unit yang akan diuji.Namun, melaksanakan uji kasus mungkin memerlukan 
pembangunan modul driver atau bertopik.
        Jika kerangka uji yang digunakan, maka pengaturan lingkungan serta masukan untuk 
kasus uji sudah dilakukan di naskah pengujian dan eksekusi langsung. Selama tes eksekusi 
kasus, ada cacat yang ditemukan. Cacat ini kemudian tetap dan pengujian dilakukan lagi 
untuk memverifikasi perbaikan. Cacat logging sangat penting dalam sebuah proyek software 
besar yang mungkin memiliki ratusan atau ribuan cacat yang ditemukan oleh orang yang 
berbeda pada berbagai tahap proyek. Penggunaan mekanisme informal dapat dengan mudah 
menyebabkan cacat yang ditemukan tetapi kemudian dilupakan, sehingga cacat tidak dapat 
dihapus. Oleh karena itu, cacat yang ditemukan harus dicatat dengan baik dalam sistem dan 
penutupan mereka dilacak. Cacat logging dan pelacakan dianggap sebagai salah satu praktik 
terbaik untuk mengelola proyek dan diikuti oleh organisasi perangkat lunak.
8.3 Pengujian Black-Box


        Sebagaimana telah kita lihat, desain kasus uji adalah kunci untuk pengujian sesuai 
SUT. Tujuan sementara pengujian SUT adalah untuk mendeteksi sebagian besar dari cacat 
melalui serangkaian uji kasus. Karena tujuan dasar ini, penting untuk memilih kasus uji 
dengan hati-hati, yang paling baik adalah uji kasus-kasus yang memiliki probabilitas tinggi.

        Ada dua pendekatan dasar untuk merancang uji kasus yang akan digunakan dalam pengujian, 
yaitu kotak hitam dan kotak putih. Dalam kotak hitam, pengujian program ini tidak dianggap. Uji 
kasus diputuskan hanya berdasarkan persyaratan atau spesifikasi program atau modul dan internal 
dari modul. Pengujian kotak putih akan dibahas pada bagian berikutnya. 
       
        Dalam pengujian black-box, tester hanya tahu masukan yang bisa diberikan ke sistem 
dan apa keluaran sistem. Bentuk pengujian juga disebut uji fungsional atau perilaku.

8.3.1 Kelas Kesetaraan Partisi

        Karena kita tidak dapat melakukan pengujian mendalam, pendekatan alami berikutnya 
adalah untuk membagi domain input ke dalam satu set kelas kesetaraan, sehingga jika 
program itu bekerja dengan benar untuk nilai, maka ia akan bekerja dengan benar untuk 
semua nilai-nilai lain di kelas itu. Jika kita memang bisa mengidentifikasi kelas 
tersebut, maka pengujian program dengan satu nilai dari masing-masing kelas kesetaraan 
setara dengan melakukan tes lengkap dari program.

        Kelas kesetaraan terbentuk dari input yang perilaku sistem ditentukan atau 
diharapkan untuk menjadi serupa. Dasar pemikiran pembentukan kelas kesetaraan 
seperti ini adalah asumsi bahwa jika spesifikasi memerlukan perilaku yang sama 
untuk setiap elemen dalam kelas nilai-nilai, maka program kemungkinan akan dibangun 
sehingga baik berhasil atau gagal untuk masing-masing nilai dalam kelas. Misalnya, 
spesifikasi modul yang menentukan nilai mutlak untuk bilangan bulat menentukan satu 
perilaku untuk bilangan bulat positif dan satu lagi untuk bilangan bulat negatif. 
Dalam hal ini, kita akan membentuk dua kelas kesetaraan salah satu yang terdiri dari 
bilangan bulat positif dan yang lain terdiri dari bilangan bulat negatif.

        Kelas kesetaraan biasanya dibentuk dengan mempertimbangkan kondisi masing-masing 
ditetapkan pada input sebagai menentukan kelas kesetaraan valid dan satu atau lebih 
valid kelas kesetaraan.


Salah satu pendekatan umum untuk menentukan kelas kesetaraan adalah sebagai berikut. 
Jika ada alasan untuk percaya bahwa seluruh rentang input tidak akan diperlakukan 
dengan cara yang sama, maka kisaran harus dipecah menjadi dua atau lebih kelas kesetaraan, 
masing-masing terdiri dari nilai-nilai yang perilaku diharapkan untuk menjadi serupa. 
Misalnya, untuk input karakter, jika kita memiliki alasan untuk percaya bahwa program 
ini akan melakukan tindakan yang berbeda jika karakter adalah huruf, angka, atau 
karakter khusus, maka kita harus membagi masukan ke dalam tiga kelas kesetaraan valid.

        Pendekatan lain untuk membentuk kelas kesetaraan adalah untuk mempertimbangkan 
nilai khusus yang perilaku dapat berbeda sebagai kelas kesetaraan. Misalnya, nilai 0 bisa 
menjadi nilai khusus untuk input bilangan bulat. Juga, untuk setiap kelas kesetaraan valid, 
satu atau lebih valid kelas kesetaraan harus diidentifikasi.

8.3.2 Analisis Nilai Batas
        Uji kasus yang memiliki nilai-nilai pada batas-batas kelas kesetaraan karena 
itu cenderung "high-yield" uji kasus, dan memilih uji kasus tersebut adalah tujuan dari 
analisis nilai batas. Dalam analisis nilai batas [68], kita memilih masukan untuk kasus 
uji dari kelas kesetaraan, sehingga masukan terletak di tepi kelas ekivalen. nilai batas 
untuk setiap kelas kesetaraan, termasuk kelas ekivalen dari output, harus ditutup. Batas 
nilai uji kasus juga disebut "kasus-kasus ekstrim." Oleh karena itu, kita dapat mengatakan 
bahwa kasus uji batas nilai adalah seperangkat input data yang terletak di tepi atau batas 
dari kelas data input atau yang menghasilkan output yang terletak di batas kelas data keluaran.



8.3.3 Pengujian Berpasangan
        Pada umumnya banyak parameter yang menentukan perilaku sistem perangkat lunak. 
Parameter ini bisa menjadi masukan langsung ke perangkat lunak atau pengaturan implisit 
untuk perangkat. Parameter ini dapat mengambil nilai-nilai yang berbeda, dan untuk beberapa 
dari perangkat lunak mungkin tidak bekerja dengan baik. Ada banyak cacat dalam perangkat 
lunak, pada umumnya melibatkan satu syarat, yaitu, beberapa nilai khusus dari parameter. 
cacat seperti ini disebut kesalahan Single-Mode [70]. Contoh kesalahan sederhana dari 
Single-Mode adalah software tidak mampu mencetak untuk jenis tertentu dari printer, 
sebuah perangkat lunak yang tidak dapat menghitung nilai dengan benar ketika nilai 
tersebut bernilai kecil, dan software billing telepon yang tidak dapat menghitung 
tagihan tertentu dengan benar.

Coding and Unit Testing

Muhammad Irfan Faisal

43A87007150396

S1/SI/3B PAGI

BAB.7 Coding Dan Pengujan Unit

Tujuan dari coding atau pemrograman mengimplementasikan kegiatan desain untuk mencetak
Aktivitas coding mempengaruhi baik atau tidaknya tampilan pengujian dan maintenance mendalam. Waktu yang dihabiskan mengcoding adalah kecil persentase dari total biaya perangkat lunak mengurangi tidak hanya untuk biaya pelaksanaan tetapi membantu mengurangi biaya selama coding. Sebuah program memiliki pembacaan jelas dan dimengerti sebagai tujuan. Tujuan diberikan untuk meminimalkan upaya yang diperlukan untuk menyelesaian program, meminimalkan jumlah pernyataan, meminimalkan memory yang diperlukan, memaksimalkan kejelasan program, dan memaksimalkan kejelasan output. Itu ditemukan disebagian besar CO. Masing-masing tim melakukan yang terbaik untuk tujuan itu. Programmer cenderung mencapai tujuan CO. Oleh karena itu, jika dibaca adalah tujuan coding aktifitas adalah kemungkinan program CO mengembangkan coding yang mudah dimengerti.

Hal ini juga menunjukkan jika fokusnya adalah pada CO meminimalkan upaya coding, membutuhkan kejelasan program yang besar. Untuk tujuan, kemudahan pemahaman dan modifikasi adalah tujuan dasar dari kegiatan pemrograman. Dalam bab ini kita akan membahas:

-  Beberapa Prinsip seperti pemrograman terstruktur, informasi bersembunyi, penggunaan Coding  Standar, dapat membantu mengembangkan program yang lebih mudah dibaca.

-  Beberapa proses programmer tingkat tambahan pembangunan seperti pengembangan, berkualitas  tinggi untuk mengembangkan kode efisien.

-    Bagaimana mengelola kode dengan menggunakan kontrol kode sumber yang tepat berkembang dan  refactoring.

-       Bagaimana unit modul tes menggunakan kerangka pengujian unit.

-    Sebuah proses inspeksi kode terstruktur digunakan secara efektif untuk meningkatkan kualitas kode.

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

Tujuan dasar dari kegiatan ini adalah untuk program coding yang mudah dimengerti. Praktek pemrograman membantu mengembangkan program yang mudah dimengerti. Sekarang konsep meliputi begitu banyak program yang berlaku umum dan bahkan terstruktur. Meskipun banyak penekanan pada struktur pemrograman, pemrograman terstruktur sering tidak dipahami dengan baik. Pemrograman terstruktur sering dianggap kurang. Meskipun penggunaan luas ini tentunya tidak diinginkan dari pengguna. Sebuah program memiliki struktur statis serta struktur yang dinamis. Struktur statis adalah struktur teks program, hanya organisasi linear laporan program. Struktur dinamis dari program ini adalah urutan pernyataan dieksekusi oleh pelaksanaan program. Dengan kata lain, kedua tampilan struktur statis dan perilaku dinamis adalah urutan laporan, sedangkan urutan mewakili struktur statis dari sebuah program adalah tetap.

Jelas ini lebih mudah untuk memahami perilaku dinamis dalam struktur dinamis. Jika perilaku menyerupai struktur statis. Semakin dekat korespondensi antara pelaksanaan dan struktur teks, program ini  mudah untuk dipahami. Tujuan dari pemrograman terstruktur adalah untuk memastikan struktur statis dan struktur dinamis adalah sama. Artinya, tujuan dari pemrograman terstruktur adalah untuk menulis program dalam urutan perbandingan laporan pelaksanaan program adalah sama dengan urutan pernyataan dalam teks program CO. Seperti pernyataan dalam program yang terorganisir. Motivasi nyata untuk pemrograman terstruktur adalah verifikasi formal program. Untuk menunjukkan sebuah program adalah CO benar, kita perlu untuk menunjukkan program yang benar. Sebagai program pada input data dan hasil hanya berlaku untuk beberapa berbagai masukan. Umumnya juga menyatakan perlunya program masukan pemesanan. Program ini diharapkan menghasilkan hasil yang valid. Penegasan tentang keadaan akhir dari sebuah program Pemerintah Indonesia pasca-kondisi program Co, dan pernyataan tentang kondisi masukan adalah pra-kondisi GOI program. untuk memverifikasi program, pernyataan dasar tentang segmen program ini dalam bentuk

Interpretasi pernyataan ini adalah co jika sebelum mengeksekusi S P adalah benar, maka Q pernyataan yang benar setelah melaksanakan S, jika eksekusi S berakhir. Sikap tegas P adalah pra-kondisi program dan Q adalah pasca-kondisi. pernyataan ini adalah tentang nilai-nilai yang diambil oleh variabel. Jika program ini adalah urutan pernyataan, maka semantik dari Quyet komposit Menjadi Program Mudah.

Penjelasan notasi ini jika apa yang dinyatakan adalah co di pembilang dapat dibuktikan, penyebut dapat disimpulkan. Menggunakan aturan ini, jika terbukti P1 dan P2 {S1} {S2} Q1 R2, maka semantik S1 untuk S2, Semua Kita perlu menunjukkan adalah co Q1 ⇒ P2, dan kemudian kita bisa bekerja sama jika eksekusi sebelum P1 memegang pra-kondisi, kemudian setelah eksekusi S1, S2 pasca-kondisi Q2 dan seterusnya. Dengan kata lain, untuk membuktikan P {S1, S2} setelah S1 dan S2 dari perilaku, Kami hanya butuh satu langkah tambahan. Ini bukti dari program pembangunan yang lebih besar. Aturan catatan ini menangani urutan yang ketat dari pernyataan. Jadi, jika ingin menerapkan ini, kita perlu untuk membangun program sebagai urutan pernyataan. Dalam sebuah program jelas tidak ada program bisa bermakna sebagai urutan laporan sederhana tanpa percabangan atau Pengulangan. Dalam pemrograman terstruktur, pernyataan ini bukan pernyataan tugas sederhana, itu adalah pernyataan terstruktur. Properti kunci pernyataan terstruktur memiliki single-Co dan satu entri-keluar. Artinya, eksekusi pelaksanaan (terstruktur) pernyataan dimulai dari satu didefinisikan.

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

Bahasa modern memiliki konstruksi seperti lainnya yang membantu  aliran kontrol dari program, yang  secara umum, membuat lebih mudah untuk memahami program. Tujuan dasar, seperti yang kita telah mencoba untuk menekankan, adalah untuk membuat logika program sederhana untuk memahami. Sebuah catatan akhir tentang konstruksi terstruktur. Setiap bagian dari kode dengan single-entry dan single-exit tidak dapat dianggap sebagai konstruk terstruktur. Jika itu terjadi, orang selalu bisa mendefinisikan unit yang tepat dalam program apapun untuk membuatnya muncul sebagai urutan unit-unit ini (dalam kasus terburuk, seluruh program dapat didefinisikan sebagai unit).

Tujuan dasar menggunakan konstruksi terstruktur adalah untuk linearize aliran kontrol sehingga perilaku eksekusi lebih mudah untuk dimengerti. 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 dapat mengurangi coupling antara modul dan membuat sistem lebih dipertahankan. Informasi bersembunyi juga 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.

* Go to: go to 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.

* Nesting: Jika nesting if-then-else konstruksi menjadi terlalu dalam, maka logika menjadi sulit untuk memahami. Dalam kasus sangat bersarang if-then-elses, seringkali sulit  untuk menentukan jika pernyataan yang klausul lain tertentu terkait. Bila memungkinkan, bersarang dalam harus dihindari, bahkan jika itu berarti sedikit tidak efisiensi. Sebagai contoh, perhatikan konstruk berikut bersarang if-then-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 Effect: Ketika sebuah modul dipanggil, kadang-kadang memiliki sisi effect memodifikasi program negara di luar modifikasi parameter yang tercantum dalam definisi antarmuka modul, misalnya, memodifikasi variabel global. sisi effects tersebut harus dihindari jika mungkin, dan jika modul memiliki sisi effect, 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 "crash" atau "core dump"; 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 untuk kembali diperiksa: Seringkali nilai kembali dari membaca tidak diperiksa, dengan asumsi bahwa membaca mengembalikan nilai yang diinginkan. Kadang-kadang hasil dari membaca bisa menjadi berbeda dengan apa yang diharapkan, dan ini dapat menyebabkan kegagalan kemudian.

Dalam contoh ini, nilai yang dikembalikan baik dalam pengecualian dan non exception scenarios. 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.

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

Programmer menghabiskan jauh lebih banyak waktu membaca kode daripada menulis kode. Selama perkembangan kode, penulis saat mengkoding cukup membacanya selama tahap debugging dan peningkatan. Singkatnya, perkembangan kode itu adalah sangat penting untuk menulis kode dengan cara yang mudah dibaca dan dimengerti. Coding standar memberikan aturan dan pedoman untuk beberapa aspek pemrograman untuk membuat kode lebih mudah dibaca. Sebagian besar organisasi yang mengembangkan perangkat lunak secara teratur mengembangkan standar mereka sendiri.

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.

Bertahap Mengembangkan Kode

        Aktivitas coding dimulai ketika beberapa bentuk desain yang telah dilakukan dan spesifikasi dari modul untuk dikembangkan tersedia. Dengan desain, modul ditugaskan untuk pengembang untuk coding. Ketika modul ditugaskan untuk pengembang, mereka menggunakan beberapa proses untuk mengembangkan kode. Di sini kita membahas beberapa proses yang efektif  menggunakan pengembang untuk secara 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.

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.

Pair programming

          Pair programming juga merupakan proses coding yang telah diusulkan sebagai metodologi kunci technique dalam pemrograman ekstrim (XP). 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, history 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. 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 "bad smells" [36], yang sering menunjukkan bahwa beberapa sifat desain yang diinginkan dapat melanggar atau bahwa ada potensi untuk meningkatkan desain. Refactoring diperlukan jika terjadinya bad smells. Beberapa dari bad smells 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 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 f () 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 kode didalam 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 driver 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).

Atribut utama dari kelas dan metode utama digambarkan pada Gambar 7.3.

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. Misalnya, untuk pengujian pembuatan metode test Add ()

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 karena berkaitan ukuran dengan biaya dan kualitas yang membuat ukuran metrik penting. Hal ini juga digunakan untuk mengukur produktivitas selama proyek (misalnya, KLOC per orang dalam satu 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.

   -       n₁ adalah jumlah operator yang berbeda

   -       n₂ adalah jumlah operan yang berbeda

   -    f 1, j jumlah kejadian dari j operator yang paling sering

   -    f 2, j 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:

N₁ adalah total kejadian operator yang berbeda dalam program dan N₂ 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. log₂(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

Sirkuit independen:

Hal ini juga dapat menunjukkan bahwa kompleksitas cyclomatic dari modul adalah sejumlah keputusan dalam modul ditambah satu, di mana keputusan adalah pernyataan kondisional dalam modul. Oleh karena itu, kami juga bisa menghitung kompleksitas cyclomatic hanya dengan menghitung jumlah keputusan dalam modul.

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

Halstead juga mengusulkan sejumlah langkah lainnya berdasarkan ilmu softwarenya. Beberapa ini dapat dianggap tindakan kompleksitas. Ini adalah n₁ (jumlah operator yang unik), n₂ (jumlah operan yang unik), N₁ (total frekuensi operator), dan N₂ (total frekuensi operan). Seperti program apapun harus memiliki minimal dua operator-satu untuk fungsi panggilan dan satu untuk akhir pernyataan-the n₁ rasio / 2 dapat dianggap tingkat relatif kesulitan karena jumlah yang lebih besar dari operator dalam program ini. Rasio N₂ / n₂ merupakan rata-rata jumlah kali operan digunakan. Dalam sebuah program di mana variabel berubah lebih sering, rasio ini akan menjadi lebih besar. Sebagai program tersebut lebih sulit untuk memahami, kemudahan membaca atau menulis didefinisikan sebagai

Halstead ini ukuran kompleksitas berfokus pada kompleksitas internal modul, seperti halnya McCabe ukuran kompleksitas. Dengan demikian, kompleksitas koneksi modul dengan lingkungannya tidak diberikan begitu penting. Dalam ukuran Halstead, sambungan modul dengan lingkungannya tercermin dalam hal operan dan operator. Panggilan untuk modul lain dianggap sebagai operator, dan semua parameter dianggap operan dari operator ini.

Halstead ini ukuran kompleksitas berfokus pada kompleksitas internal modul, seperti halnya McCabe ukuran kompleksitas. Dengan demikian, kompleksitas koneksi modul dengan lingkungannya tidak diberikan begitu penting. Dalam ukuran Halstead, sambungan modul dengan lingkungannya tercermin dalam hal operan dan operator. Panggilan untuk modul lain dianggap sebagai operator, dan semua parameter dianggap operan dari operator ini.

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.