BAB II. LANDASAN TEORI
2.1. RPG
RPG adalah bahasa pemrogamman yang dikembangkan oleh IBM untuk platform iSeries dan OS/400 (IBM, 1994). RPG merupakan bahasa pemrogamman terstruktur, tidak free-format. Setiap penulisan keyword (kecuali comments) harus disesuaikan dengan posisinya masing-masing, baik itu secara baris maupun kolom. Urutan spesifikasi (baris) dalam bahasa pemrogamman RPG meliputi :
• Control Specification (H) menjelaskan informasi mengenai program • File Description Specification (F) menjelaskan semua file yang digunakan
pada program
• Extension Specification (E) menjelaskan arrays dan tabel
• Line Counter Specification (L) mengindikasikan panjang overflow lines • Input specification (I) menjelaskan data struktur, konstan variabel, records
dan fields pada input files, dan mengindikasikan bagaimana records dan fields digunakan
• Calculation Specification (C) menjelaskan komputasi atau fungsi yang dijalankan oleh program secara sekuensial, termasuk mengontrol operasi input dan output
• Output Specification (O) menjelaskan records dan fields, serta mengindikasikan kapan keduanya ditulis oleh program
Untuk posisi kolom sendiri juga berbeda-beda tergantung posisi baris. Sebagai contoh posisi kolom untuk Calculation Specification bisa dilihat pada tabel 2.1
Tabel 2.1. Posisi Kolom untuk Calculation Specification
Position Argument Type Description
6 Form Type Harus diisi dengan ‘C’
7 Comment Jika ini berupa comments, harus diberi tanda ‘*’
9-17 Indicator
Mendandakan indikator apakah kalkulasi akan dijalankan atau tidak
18-27 Factor 1 Variabel 1 yang akan dikenakan suatu operasi
28-32 Operation Code
Operasi yang akan berefek pada factor 1, factor2, dan result
field
33-42 Factor 2 Variabel 2 yang akan dikenakan suatu operasi
43-48 Result Field Variabel 3 yang akan dikenakan suatu operasi
49-51 Field Length
Digunakan untuk mendefinisikan panjang dari variabel yang dibuat
52 Decimal Position Jika ada angka 0, maka variabel dianggap numerik
53 Operation Extender Memberikan atribut tambahan terhadap sebuah operasi
54-59 Resulting Indicators Indikator yang menandakan hasil suatu operasi
60-74 Comment Komentar akan baris kode 75-80 Comment Komentar akan baris kode
Kemudian, posisi kolom untuk file specification :
Tabel 2.2. Posisi Kolom untuk File Specification
Position Argument Type Description
6 Form Type Harus diisi dengan ‘F’
15 File Type
Diisi ‘I’ untuk input, ‘U’ untuk update, ‘O’ untuk output, dan ‘C’ untuk kombinasi input
dan output
16 File Designation
Diisi ‘P’ untuk primary file , ‘S’ untuk
secondary file, ‘R’ untuk record address file,
‘T’ untuk array atau table file, ‘F’ untuk
procedural file
17 End of File
Diisi blank atau ‘E’ jika semua record harus diproses sampai selesai sebelum program
selesai dijalankan
18 Sequence
Diisi ‘A’ atau blank untuk ascending, ‘D’ untuk descending
19 File Format
Diisi ‘F’ untuk program described file, atau ‘E’ untuk externally described file
20 - 23 Kosong Kosong
24 – 27 Record Length Diisi angka 1 - 9999
28 Limit Processing Terisi blank, atau ‘L’ jika ada batasan pada file
29 - 30
Length of key field or record address field
Diisi angka 1 – 99 atau blank
31 Record address type
Diisi blank , atau ‘A’ untuk character keys, ‘P’ untuk numeric keys, atau ‘K’ untuk key yang
dideklarasikan di program
32 File Organization
Terisi blank, atau ‘I’ jika file memiliki indeks, atau ‘T’ jika file memiliki relative record
number
33 – 34 Overflow Indicator Terisi jika menggunakan file bertipe report
35 – 38 Key Field Starting Location Terisi blank atau angka 1 – 9999
baris tipe E dan L
40 – 46 Device
Terisi ‘PRINTER’ apabila file yang dideklarasikan adalah report, ‘DISK’ jika file
yang dideklarasikan adalah disk file, ‘WORKSTN’ jika file merupakan layar
program
47 – 52 Kosong Kosong
53 Continuation Lines Terisi ‘K’ jika ada continuation lines
54 – 59 Routine
Hanya digunakan jika kolom device terisi
special
60 – 65 Kosong Kosong
66 File Addition Diisi ‘A’ jika ada operasi penulisan ke file
67 – 70 Kosong Kosong
71 – 72 File Condition
Diisi ‘UC’ jika file harus di-open dan di-close secara manual oleh program
73 - 74 Kosong Kosong
75 - 80 Comments Berisi komentar jika ada
Contoh untuk program RPG bisa dilihat pada gambar 2.1
Columns . . . : 1 71 Edit RANDI4/QRPGSRC SEU==> EGTPLN FMT * ... *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 *************** Beginning of data ************************************* 0001.00 00100 ***************************************************************** 0002.00 00200 ** PROPRIETARY PROGRAM MATERIAL ** 0003.00 00300 ** ** 0004.00 00400 ** THIS MATERIAL IS PROPRIETARY TO PT. MULTIPOLAR CORP. AND IS ** 0005.00 00500 ** NOT TO BE REPRODUCED, DISCLOSED, OR USED EXCEPT IN ACCORD - ** 0006.00 00600 ** ANCE WITH PROGRAM LICENSE OR OTHER WRITTEN AUTHORIZATION OF ** 0007.00 00700 ** PT. MULTIPOLAR CORP. ** 0008.00 00800 ** **
0009.00 00900 ** BANKVISION VERSION 4.3 ** 0010.00 01000 ** COPYRIGHT (C) 1999 BY PT. MULTIPOLAR CORP. ** 0011.00 01100 ***************************************************************** 0012.00 01200H/TITLE EGTPLN - Program to get field DXCU10 from EPLANX 0013.00 01300H* Created by : Randi Flac 0013.01 H* Creation Date : Jan, 5th 2015 0015.00 01500FEPLANXL0IF E K DISK 0016.00 01600 * 0017.00 C PLNKEY KLIST 0018.00 C KFLD DXAPCD 0019.00 C KFLD DXPLCD 0020.00 C KFLD DXCCYC 0021.00 01600 * 0022.00 01700C *ENTRY PLIST 0023.00 01800C PARM DXAPCD Account Nmbr 0024.00 01900C PARM DXPLCD Participatio 0025.00 01900C PARM DXCCYC Currency 0026.00 01900C PARM INFO 5 Return Var 0027.00 02300 * 0028.00 02400C PLNKEY CHAINEPLANXL0 N90 0029.00 02500C N90 MOVELDXCU10 INFO 0030.00 02600C RETRN ****************** End of data **************************************** F3=Exit F4=Prompt F5=Refresh F9=Retrieve F10=Cursor F11=Toggle F16=Repeat find F17=Repeat change F24=More keys
Gambar 2.1. Contoh Sumber Kode RPG
Salah satu fitur yang dimiliki RPG adalah penggunaan indikator. Setiap operasi yang dilakukan di baris program bisa saling terkait dengan penggunaan indikator, walaupun hal ini tidak mutlak. Indikator adalah sekumpulan variabel yang memiliki dua state, yaitu ON dan OFF. Indikator ini bisa merupakan pemicu apakah sebuah operasi akan berjalan, atau merupakan hasil yang ditimbulkan
akibat jalannya sebuah operasi. Sebagai contoh, pada program diatas, ada operasi CHAIN yang mencari apakah record dengan key yang didefinisikan pada PLNKEY ada atau tidak. Jika record tersebut ada, maka indikator 90 akan bernilai OFF dan operasi memindahkan isi dari field DXCU10 ke variabel INFO akan berjalan. Indikator 90 pada kolom posisi 54-59 merupakan indikator yang menjadi hasil operasi CHAIN, sedangkan indikator 90 pada posisi 9-17 adalah pemicu jalannya operasi MOVEL.
2.2. Software Testing
Software testing adalah kegiatan eksplorasi sistemik dari sistem atau komponen sistem untuk mengurangi resiko dan meningkatkan kualitas dari sebuah perangkat lunak dengan menemukan cacat yang ada pada perangkat lunak (Hambling dan Morgan, 2010). Testing tidak bertujuan untuk memperbaiki cacat, namun cacat yang ditemukan akan diberikan kembali ke programmer untuk diperbaiki. Oleh karena itu, testing menjamin bahwa perubahan dan koreksi yang dilakukan terhadap sistem atau komponen sistem dicek secara komperehensif. Tanpa adanya testing, maka error yang ada pada sebuah program akan berubah menjadi defects yang bisa menyebabkan failure. Menurut Hambling, failure ini bisa menyebabkan beberapa hal yang diantaranya :
1. Kehilangan uang 2. Kehilangan waktu
3. Kehilangan reputasi bisnis 4. Injury
Namun, perlu diperhatikan bahwa exhaustive testing adalah hal yang tidak mungkin. Jika semua kemungkinan test case telah dilakukan, maka sudah pasti program bebas dari cacat. Namun, jika semua test case telah dilakukan, maka proses testing tidak akan pernah selesai, bahkan hingga saat ini (Hambling dan Morgan, 2010).
2.3. Test Case Design Technique
Menurut Hambling (2010), teknik untuk mendesain test case dikategorikan menjadi tiga kategori :
1. Mendesain test case secara langsung dari spesifikasi yang ada. Hal ini juga dikenal dengan nama black box testing. Teknik ini dilakukan berdasarkan dokumentasi yang ada, baik aspek fungsional maupun non fungsional. Namun, teknik ini tidak dibuat berdasarkan informasi struktur internal dari komponen dan sistem yang akan dites.
2. Mendesain test case berdasarkan struktur komponen sistem, atau biasa disebut dengan white box test. Hal ini adalah fokus yang akan dilakukan dalam penelitian ini.
3. Mendesain test case berdasarkan pengalaman tester dalam menangani sistem yang serupa. Hal ini biasa disebut dengan experience based techniques.
Lebih lanjut mengenai ketiga teknik ini akan dijelaskan pada poin dibawah.
2.3.1 Black Box Testing
Black box testing merupakan sebuah teknik testing yang dikembangkan berdasarkan spesifikasi ataupun model lain yang menggambarkan apa yang dijalankan sistem, bukan apa yang seharusnya dijalankan sistem (Hambling dan Morgan, 2010). Teknik ini dibagi menjadi lima macam, yaitu :
1. Equivalence Partitioning
Teknik dengan mengelompokkan input yang sejenis untuk mempermudah pengetesan. Contoh :
Valid Input : Nama dengan panjang hingga dua puluh karakter alfabetik dan tidak boleh kosong.
Maka, valid partition-nya adalah karakter alfabetik dengan panjang dari satu hingga dua puluh karakter, sedangkan invalid partition-nya adalah kosong, karakter alfabetik dengan panjang lebih dari dua puluh karakter, dan kumpulan karakter yang mengandung unsur non alfabetis (angka, special characters).
2. Boundary Value Analysis
Teknik analisa dimana input yang diberikan dalam test case merupakan nilai-nilai batas (atas dan bawah) dari nilai yang diperbolehkan. Contoh pada kasus equivalence partitioning diatas, maka valid boundaries-nya adalah satu hingga dua puluh karakter, dan invalid boundaries-nya adalah karakter yang panjangnya kurang dari satu (kosong) dan karakter yang panjangnya lebih dari
dua puluh karakter. Biasanya teknik ini digunakan bersama-sama dengan equivalence partitioning.
3. Decision Table Testing
Teknik ini dilakukan dengan membuat serangkaian kombinasi kondisi yang ada, dan tindakan apa yang akan dipicu untuk setiap kondisi. Contoh teknik ini bisa dilihat pada tabel berikut :
Tabel 2.3 Contoh Decision Table Testing
Contoh Test Case 1 Test Case 2 Test Case 3 Test Case 4
Kondisi 1 T T F F
Kondisi 2 T F T F
Tindakan Y N N N
4. State Transition Testing
Teknik ini dilakukan dengan membuat sebuah state diagram yang menggambarkan setiap perpindahan kondisi (state) yang bisa terjadi pada sistem. Kemudian, disimulasikan perpindahan dari state ke state lain berdasarkan input yang diberikan.
5. Use Case Testing
Teknik ini menggunakan use case sebagai input dalam pembuatan test case.
2.3.2 White Box Testing
White box testing merupakan sebuah teknik pembuatan test case yang dilakukan dengan melihat struktur internal sistem, dalam hal ini
berupa sumber kode. Teknik ini timbul dikarenakan tidak penting seberapa lengkap dan kompleks black box testing yang dilakukan, mustahil bahwa semua perilaku dan kebutuhan yang ada di dalam sistem bisa terlihat oleh tester. Selain itu, apabila ada malicious code, yang jelas diluar ruang lingkup spesifikasi, tidak dapat dideteksi oleh black box testing (Black, 2014). Hampir sebagian besar dari kegiatan white box testing akan berkaitan dengan coverage, yaitu tingkat kedetilan ruang lingkup testing agar sesuai dengan fungsionalitas sistem yang diharapkan. Diagram alir bisa digunakan untuk menggambarkan struktur internal sebuah program, mulai dari setiap executable statements hingga setiap kondisi (true dan false) pemicu jalannya statements yang ada pada program, sehingga bisa menjadi input pembuatan test case (Hambling, 2010).
2.3.2.1. Statement Coverage
Statement Coverage merupakan teknik white box testing yang memastikan setiap executable statements dijalankan satu kali, sehingga yang perlu dilakukan adalah membuat semua kemungkinan test case dimana masing-masing executable statement dipastikan akan berjalan. Satu statement yang dijalankan hanya merupakan bagian dari satu test case, sehingga tidak mungkin ada test case lain yang menjalankan statement yang sama. Untuk lebih jelas mengenai hal ini, sebagai ilustrasi ada program seperti berikut :
READ A READ B
IF A < 0 THEN PRINT “A Negative” END IF
IF B < 0 THEN PRINT “B Negative” END IF
Berdasarkan definisi statement coverage, maka setiap executable statement harus dijalankan satu kali. Oleh karena itu, test case untuk mencapai statement coverage hanya ada satu, yaitu dengan memberikan input A negatif dan input B negatif.
2.3.2.2. Branch Coverage
Berbeda dengan statement coverage, branch coverage dilakukan dengan membuat semua test case yang mungkin dimana setiap kondisi akan dieksekusi, baik apabila terpenuhi maupun tidak, namun kondisi true dan false dari masing-masing kondisi hanya perlu dijalankan satu kali. Sebagai contoh, berdasarkan program yang digunakan sebagai ilustrasi diatas, maka jumlah test case untuk mencapai branch coverage ada dua, yaitu :
1. Memberikan input A negatif dan B negatif 2. Memberikan input A positif dan B positif
Pilihan selain test case diatas adalah :
2. Memberikan input A negatif dan B positif
2.4. Cyclomatic Complexity
Cyclomatic complexity adalah sebuah metriks yang dikemukakan oleh Thomas McCabe yang mengukur secara kuantitatif tingkat kompleksitas sebuah program (Nidhra dan Dondeti, 2012). Metriks ini merupakan salah satu metriks paling populer di dalam bidang rekayasa piranti lunak untuk mengukur kompleksitas program (Madi, 2013). McCabe menjelaskan bahwa setiap struktur dalam kode dapat dites hanya dengan memperhatikan independent basis paths, dan semua kemungkinan path lain yang tak terhingga jumlahnya adalah merupakan penggunaan basis path ini secara berulang-ulang. Basis path dalam hal ini merupakan sebuah path linear yang independen. Dalam jalur ini, tidak dikenal adanya iterasi. Iterasi dianggap sama seperti kondisi biasa, dimana secara umum hanya akan dieksekusi dua kali, yaitu true (masuk ke dalam statement di dalam perulangan) dan false (keluar dari perulangan). Cyclomatic Complexity ini tidak tergantung pada ukuran (size) sebuah program, namun bergantung pada jumlah kondisi yang menjadi struktur program tersebut. Menurut McCabe, semakin tinggi nilai cyclomatic complexity sebuah program, maka akan semakin banyak jumlah cacat yang ada, dan juga semakin banyak test case yang dibutuhkan untuk melakukan pengujian kualitas sistem.
Rumus untuk menghitung cyclomatic complexity sebuah program adalah : Cylomatic Complexity (CC) = E – N + P + 1, dimana :
E = Jumlah edge yang ada pada graph N = Jumlah node yang ada pada graph
P = Jumlah connected component yang ada pada graph, atau dengan kata lain jumlah fungsi atau modul lain yang dipanggil pada graph
Berdasarkan pendapat McCabe, idealnya, sebuah program (atau modul) hanya boleh memiliki nilai cylomatic complexity di bawah 10. Lebih dari itu berarti program diasumsikan memiliki resiko kesalahan lebih tinggi (Hambling dan Morgan, 2010). Faktor yang menentukan tingginya nilai cyclomatic complexity pada sebuah program adalah jumlah kondisi dan percabangan pada program tersebut, dimana nilai cyclomatic complexity akan tinggi untuk program dengan jumlah percabangan dan perulangan yang banyak (Madi, 2013).
Terkait diagram alir, node merupakan statement yang dieksekusi dan edge adalah panah yang menghubungkan semua statement yang ada.
Langkah-langkah untuk menghasilkan test case dengan menggunakan metode ini adalah (Madi, 2013) :
1. Gambarkan diagram alir berdasarkan sumber kode yang ada 2. Hitung cyclomatic complexity dari diagram yang dihasilkan
3. Membuat test case yang akan mengeksekusi setiap path yang ada pada graph
2.5. DOT Language
DOT language adalah sebuah markup language yang menggambarkan tiga macam objek, yaitu graphs, nodes, dan edge, dan relasi diantaranya (Gansner, 2006). Bahasa ini adalah hasil akhir transformasi dari sumber kode bahasa RPG dalam penelitian ini. Bahasa ini akan diproses menggunakan perangkat lunak open source Graphviz untuk diolah menjadi diagram alir.
Contoh penulisan bahasa ini dan penerapannya dalam pembuatan diagram alir akan dijelaskan lebih detil di bagian selanjutnya.
2.6. Flowchart
Flowchart mendeskripsikan pola visual yang menggambarkan detil prosedural, antara lain urutan, kondisi, dan pengulangan, dimana semua ini merupakan elemen dari pemrogamman struktural (Pressman, 2010). Di dalam flowchart, simbol kotak menggambarkan proses, simbol berlian menggambarkan kondisi dan repetisi, serta panah menunjukkan alur dari program. Gambar di bawah ini menjelaskan ketiga elemen tersebut.
Proses 1 Proses 2 Kondisi 1 Proses 1 Proses 2 F T Kondisi 1 T Proses 1 F Contoh Sequence Contoh Condition Contoh Repetition
2.7. Legacy Systems
Legacy systems adalah sistem yang sudah lama sekali dibuat dan telah secara terus menerus dimodifikasi untuk memenuhi kebutuhan bisnis dan platform komputasi, dimana bagi organisasi, biaya untuk maintenance-nya sangat tinggi dan resiko untuk melakukan evolusi sistem juga tinggi (Pressman, 2010). Namun, legacy systems tetap memberikan dukungan penting dalam fungsi utama bisnis dan tidak tergantikan. Sisi negatif legacy systems adalah kualitasnya yang rendah, antara lain desain yang sulit dikembangkan lebih maju, sumber kode yang berbelit-belit, dokumentasi yang tidak lengkap, test cases dan hasil yang tidak pernah tercapai, kurangnya dokumentasi perubahan program, dan masih banyak lagi daftar yang tidak bisa disebutkan (Pressman, 2010). Menurut Pressman, seiring berkembangnya waktu, legacy systems berubah karena alasan-alasan berikut :
1. Sistem harus beradaptasi untuk menghadapi lingkungan teknologi dan komputasi yang terus berkembang
2. Sistem harus diperbaharui untuk mengimplementasi kebutuhan bisnis baru
3. Sistem harus diekstensifikasi agar bisa beroperasi dengan sistem yang lebih modern
4. Sistem harus di-rearchitected agar dapat berjalan di dalam jaringan lingkungan yang ada
