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
7
8
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’
7 – 14
File Name
Nama file yang digunakan
9
Diisi ‘I’ untuk input, ‘U’ untuk update, ‘O’ 15
File Type
untuk output, dan ‘C’ untuk kombinasi input dan output Diisi ‘P’ untuk primary file , ‘S’ untuk secondary file, ‘R’ untuk record address file,
16
File Designation ‘T’ untuk array atau table file, ‘F’ untuk procedural file Diisi blank atau ‘E’ jika semua record harus
17
End of File
diproses sampai selesai sebelum program selesai dijalankan Diisi ‘A’ atau blank untuk ascending, ‘D’
18
Sequence untuk descending Diisi ‘F’ untuk program described file, atau ‘E’
19
File Format 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
Length of key field or record 29 - 30
Diisi angka 1 – 99 atau blank address field Diisi blank , atau ‘A’ untuk character keys, ‘P’
31
Record address type
untuk numeric keys, atau ‘K’ untuk key yang dideklarasikan di program Terisi blank, atau ‘I’ jika file memiliki indeks,
32
File Organization
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
39
Extension Code
Terisi ‘E’ atau ‘L’ jika ada spesifikasi pada
10
baris tipe E dan L Terisi ‘PRINTER’ apabila file yang dideklarasikan adalah report, ‘DISK’ jika file 40 – 46
yang dideklarasikan adalah disk file,
Device
‘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
SEU==> FMT *
RANDI4/QRPGSRC EGTPLN
..... *. 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 **
**
11
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
: Jan, 5th 2015
H* Creation Date
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 0029.00 02500C
PLNKEY N90
CHAINEPLANXL0 MOVELDXCU10
0030.00 02600C
N90 INFO
RETRN
****************** End of data ****************************************
F3=Exit
F4=Prompt
F16=Repeat find
F5=Refresh
F9=Retrieve
F17=Repeat change
F10=Cursor
F11=Toggle
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
12
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 5. Kematian
13
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.
14
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
15
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
16
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
kemungkinan
perlu
test
case
dilakukan dimana
adalah
membuat
masing-masing
semua
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 :
17
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 : 1. Memberikan input A positif dan B negatif
18
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
19
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.
20
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. Contoh Sequence
Contoh Condition
Proses 1
Kondisi 1 F
Proses 1 Proses 2
Contoh Repetition
Kondisi 1
T
Proses 1
F
Gambar 2.2 Elemen pada flowchart
T
Proses 2
21
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
