Bab V Implementasi dan Pengujian

Bab V Implementasi dan Pengujian Dari hasil analisis yang dituliskan di Bab III dan hasil perancangan yang dituliskan di Bab IV, dilakukan implementasi dan pengujian terhadap masingmasing komponen sistem pelatihan. Pada Bab ini berisi penjelasan atas implementasi dan pengujian Tugas Akhir ini berturut-turut pada Subbab 5.1 dan Subbab 5.2. 5.1. Implementasi

Subbab ini berisi penjelasan implementasi masing-masing mode deployment yang sudah direncanakan. 5.1.1. Strategi Implementasi

Sistem ini dikembangkan dengan menggunakan framework KohanaPHP versi 2.3. Framework ini merupakan PHP framework yang merupakan turunan dari framework CodeIgniter. Framework KohanaPHP mendukung pengembangan

perangkat lunak berbasis PHP dengan menggunakan pola perancangan MVC. Selain itu framework ini memiliki fitur ORM (Object-Relational Mapping) yakni fitur untuk memetakan atribut sebuah obyek dan relasi antar obyek ke dalam basis data relational. Aplikasi sandbox yang dipilih adalah sandbox yang diambil dari aplikasi MOEval [MAR07]. Untuk mengeksekusi sebuah program, kelas Sandbox akan menjalankan aplikasi tersebut. Pengeksekusian sandbox ini dilakukan dengan menggunakan command line interface dengan parameter seperti yang tertera di Tabel IV-1. Sandbox MO-Eval ini secara khusus menangani pembatasan akses

antara program dengan sistem operasi berbasis Linux.

V-1

V-2

Tabel V-1. Parameter Sandbox MO-Eval Parameter -a

-c -e -E -E = -f -i -m -o -p <path> -p -r -s -s -t -T -v -w

<path>= <sys> <sys>=



Description Set file access level (0=none, 1=cwd, 2=/etc,/lib,..., 3=whole fs, 9=no checks; needs -f) Change directory to first Inherit full environment of the parent process Inherit the environment variable from the parent process Set the environment variable to ; unset it if is empty Filter system calls (-ff=very restricted) Redirect stdin from Limit address space to <size> KB Redirect stdout to Permit access to the specified path (or subtree if it ends with a `/') Define action for the specified path (=yes/no) Redirect stderr to Permit the specified syscall (be careful) Define action for the specified syscall (=yes/no/file) Set run time limit (seconds, fractions allowed) Allow syscalls for measuring run time Be verbose (use multiple times for even more verbosity) Set wall clock time limit (seconds, fractions allowed)

#box –f –a 3 –w 1 -- ./test #box –e –f –a 3 –i test.in –o test.out –t 1 -– ls –l #box –m 102400 –c /tmp/ -- /usr/bin/gcc

Kode V-1. Contoh Penggunaan Sandbox MO-Eval

Cara kerja sandbox ini adalah dengan menggunakan 2 buah proses yakni parent process sebagai control process dan child process yang hasil fork yang bertugas

untuk menjalankan program. Sandbox ini mengeksploitasi fungsi-fungsi yang ada pada Linux seperti setrlimit untuk membatasi resource, ptrace untuk melakukan system call monitoring. Untuk mengukur waktu eksekusi, sandbox akan secara

periodik melakukan penghitungan waktu atau membaca CPU time yang dicatat oleh sistem operasi pada berkas /proc/pid/stat.

V-3

<<device>> Master <> Web Server

<<device>> Slave

<<artifact>> TOKI LC

<<artifact>> Dispatcher 1..*

HTTP

1

1 0..*

XML RPC

<<device>> Client <> Web Browser

<<Application>> MO-EVAL Sandbox Database Server TOKI-LC Database

Gambar V-1. Deployment Diagram untuk Mode Online

Deployment diagram pada Gambar V-1 memperlihatkan penyusunan dari sistem TOKI-LC. Seluruh bagian dari perangkat lunak yang bertugas sebagai front-end diletakkan di atas web server pada mesin slave. Komponen back-end yang terdiri dari Dispatcher dan kelas-kelas API lain seperti Compiler, Comparator, dan lainlain diletakkan pada mesin slave. Aplikasi sandbox MO-Eval juga diletakkan pada mesin slave. Komponen backend akan dieksekusi dengan menggunakan PHP Command Line Interface, sehingga aplikasi tidak memerlukan aplikasi web server untuk menjalankannya. Aplikasi akan berjalan sebagai service sistem operasi dengan menggunakan perintah start-stop-daemon. Sistem operasi Linux pada mesin slave akan ditambahkan sebuah init script pada direktori /etc/init.d yang bertugas sebagai shortcut untuk mengeksekusi backend service tersebut. Komunikasi antara slave dan master diimplementasikan dengan menggunakan protokol XML RPC [XML09]. Karena protokol menggunakan pemanggilan di atas protocol HTTP, maka komponen penanganannya dapat diletakkan pada bagian aplikasi yang berada di atas web server. Untuk menanganinya, kelas Slave

V-4

diimplementasikan baik di aplikasi master dan slave sebagai kelas pembungkus operasi XML RPC ini. Untuk melakukan sinkronisasi, slave akan mengeksekusi perintah rsync [TRI99]. Aplikasi rsync adalah sebuah aplikasi yang dapat melakukan sinkronisasi antara dua buah berkas atau direktori secara efisien. Aplikasi ini akan membangkitkan hash di antara keduanya kemudian membangkitkan delta file yakni berkas perbedaan kemudian menambal berkas/direktori yang lain dengan delta file tersebut. Aplikasi rsync juga dapat dipakai untuk melakukan sinkronisasi melalui jaringan. #rysnc –aq –e ssh user@master:/alamat/repositori \ /alamat/repositori/lokal

Kode V-2 Perintah rsync

Perintah pada Kode V-2 akan mengeksekusi rsync untuk melakukan sinkronisasi antara direktori repositori soal pada path /alamat/repository yang terletak di mesin master terhadap repositori soal pada filesystem lokal dengan path /alamat/repositori/lokal.

<<device>> Server <> Database Server TOKI LC Database

<<device>> Client HTTP <> Web Server

<> Web Browser

1 1..*

<<artifact>> TOKI LC

<<artifact>> Dispatcher

<> MO-Eval Sandbox

Gambar V-2. Deployment Diagram untuk Mode Portable

V-5

Gambar V-2 menjelaskan tentang susunan sistem pada mode portable. Pada mode ini, seluruh komponen perangkat lunak berada pada sebuah sistem. Sama halnya dengan mode sebelumnya, komponen Dispatcher berjalan sebagai service dalam sistem operasi. Untuk mengakses data seperti jawaban, soal, dan lain-lain, Dispatcher akan menggunakan kelas entity yang terdapat pada komponen yang berada di atas web server. Karena kedua komponen ini berada pada sebuah framework maka hal ini dapat dilakukan.

<<device>> Client

<> Web Server

<> Web Browser

<<artifact>> TOKI LC

<<artifact>> Dispatcher

<> MO-Eval Sandbox

Gambar V-3. Deployment Diagram untuk Mode Standalone.

Jika pada kedua mode sebelumnya beberapa data disimpan dalam basis data maka pada mode standalone, seluruh data akan disimpan dalam bentuk berkas. Setiap kali peserta mengumpulkan jawaban atau meletakkan paket soal ke dalam sistem, maka berkas data tersebut akan disimpan pada filesystem. Mode ini diimplementasikan di atas LiveCD Ubuntu.

V-6

5.1.2. Lingkungan Implementasi Sistem pelatihan TOKI-LC diimplementasikan pada lingkungan sebagai berikut 1. Sistem Operasi : Ubuntu 9.04 Jaunty Jackalope 2. Perangkat Lunak Utama :

•

Apache 2 Web Server

•

MySQL Server

•

PHP

•

rsync

3. Perangkat Keras :

•

Processor Intel Core 2 Duo

•

Memory 2 GB

•

LAN 100 Mbps

Untuk sistem standalone, spesifikasi minimum yang direkomendasikan adalah processor 700 MHz x86 dan memory 512 MB 5.1.3. Implementasi Kelas Kelas yang diimplementasikan mengacu pada kelas-kelas yang sudah dirancang pada Subbab 4.1. Daftar implementasi kelas dapat dilihat pada tabel di bawah ini.

Tabel V-2. Daftar Implementasi Kelas Kelas User Contest Problem ProblemType Submission Sandbox

Berkas /application/models/user.php /application/models/contest.php /application/models/problem.php /application/models/problemtype.php /application/models/submission.php /modules/evaluator/libraries/Sandbox.php /modules/evaluator/libraries/SandboxException.php Compiler /modules/evaluator/libraries/Compiler.php /modules/evaluator/libraries/CompilerException.php Comparator /modules/evaluator/libraries/Comparator.php /modules/evaluator/libraries/ComparatorException.php Packager /modules/evaluator/libraries/Packager.php /modules/evaluator/libraries/PackagerException.php Slave /modules/evaluator/libraries/Slave.php /modules/evaluator/libraries/SlaveException.php ProblemController /modules/evaluator/libraries/ProblemController.php S : Sudah diimplementasi B : Belum diimplementasi

Status S S S S S S

S S S S S

V-7

5.2. Pengujian Subbab ini berisi pengujian perangkat lunak terhadap solusi dari rumusan masalah: extensibility, security, dan scalability. Setiap pengujian masing-masing terdiri strategi dan 5.2.1. Pengujian aspek extensibility Pengujian ini bertujuan untuk membuktikan bahwa perangkat lunak dapat memfasilitasi pengguna dapat membuat tipe-tipe soal baru. 5.2.1.1. Strategi Pengujian Pada pengujian ini dibuat beberapa tipe soal. Dari tipe soal tersebut dibuat beberapa contoh soal untuk masing-masing tipe soal. Pada soal-soal tersebut akan dicoba dilakukan pengumpulan jawaban yang sesuai untuk soal yang bersangkutan. Untuk tipe soal yang akan dibuat, dipilih dua buah tipe soal yakni simple batch task dan complex batch task. 5.2.1.2. Hasil Pengujian Simple batch task adalah tipe soal yang umum seperti dipakai pada online judge UVA ACM. Pada simple batch ini, sebuah jawaban dianggap benar ketika menghasilkan keluaran yang benar untuk semua test case. Konfigurasi yang ada pada tipe soal ini adalah time limit, memory limit, dan testcases yang menunjuk pada pasangan test case yang ada pada task files. Kode evaluator dapat dilihat pada Lampiran C.1. Complex batch task adalah tipe soal yang lebih customizable daripada tipe soal simple batch. Pada tipe soal ini, coach dapat melakukan konfigurasi compiler argument untuk melakukan kompilasi jawaban, berkas executables untuk melakukan pemeriksaan jawaban, dan skor per test case. Berkas executables ini menerima masukan berupa standard input dan mengembalikan hasil penilaian lewat return value. Dengan adanya mekanisme seperti ini, kode evaluator setidaknya dapat hanya berisi pemanggilan executables yang menjalankan seluruh proses evaluasi. Kode evaluator dapat dilihat pada Lampiran C.2.

V-8

Dari pengumpulan jawaban yang dilakukan didapatkan bahwa tipe soal yang telah dibuat dapat menghasilkan tampilan hasil evaluasi jawaban yang tepat. Sebagai contoh untuk jawaban yang benar untuk sebagian test case, pada tipe soal pertama hasil evaluasi akan ditampilkan sebagai wrong answer dengan poin 0 sedangkan pada tipe soal kedua akan ditampilkan sebagai wrong answer dengan poin sejumlah test case yang benar. 5.2.1.3. Evaluasi Pengujian Pada dasarnya kedua tipe soal merupakan variasi satu sama lain. Perbedaan yang ada pada kedua tipe soal tersebut terdapat pada konfigurasi soal dan penilaian jawaban. Dari hasil pengujian tipe soal yang sudah dibuat disimpulkan bahwa sistem telah mampu memfasilitasi pengembangan soal. Kebenaran sebuah tipe soal dan soal tergantung dari coach yang mebuat tipe soal serta soal yang ada. 5.2.2. Pengujian aspek security Pengujian ini bertujuan untuk membuktikan bahwa aplikasi sandbox yang digunakan dapat berjalan dengan baik pada serangan-serangan yang telah disebutkan pada Subbab 2.4.2. Pengujian dibatasi pada serangan-serangan berupa kode jawaban. 5.2.2.1. Strategi Pengujian Pengujian dilakukan dengan mengumpulkan jawaban berupa kode-kode yang berbahaya. Seluruh kode pengujian masih terbatas pada kode dalam bahasa pemrograman C dan C++. Skenario yang diujikan adalah sebagai berikut 1. Sistem diberikan kode untuk memperlambat waktu kompilasi kode. Kode ini akan terus mengambil data acak dari pembacaan berkas

/dev/random.

Untuk mencegah hal ini maka perlu ditambahkan batas waktu pengeksekusian. #include “/dev/random” #include <stdio.h> int main() { return 0; }

Kode V-3. Kode Skenario 1

V-9

2. Sistem diberikan kode yang berusaha memanipulasi waktu pengerjaan program. Karena sandbox hanya dapat memantau waktu program utama maka program akan melakukan fork. Child process ini akan melakukan pekerjaan yang seharusnya dilakukan tanpa takut proses akan diterminasi. Untuk mencegah hal ini maka sandbox harus membatasi pemangggilan syscall fork. #include <stdio.h> #include <sys/types.h> int main(int argc, char * argv[]) { pid_t childpid = fork(); if (childpid == 0) for(;;)printf("Hello World!"); printf("Program done!"); }

Kode V-4. Kode Skenario 2

3. Sistem diberikan kode yang mengeksekusi perintah ls melalui fungsi system. Kebanyakan peraturan kontes melarang adanya pengeksekusian perintah terminal. Selain itu fungsi ini dapat dimanfaatkan untuk mengeksekusi perintah-perintah yang berbahaya seperti rm. Untuk mencegahnya, sandbox harus membatasi pemanggilan system call #include <stdio.h> int main(int argc, char * argv[]) { system("ls -l"); }

Kode V-5. Kode Skenario 3

4. Sistem diberikan kode yang berusaha untuk melakukan include kode peserta lain yang berada dalam direktori yang sama. Evaluator script biasanya sudah diharuskan untuk membersihkan berkas-berkas yang telah dibuat akan tetapi untuk skenario pengujian ini dianggap terdapat berkas jawaban pada kode jawaban peserta. #include "source1.c"

Kode V-6. Kode Skenario 4

V-10

5. Sistem diberikan kode yang berusaha menebak letak kode milik peserta lain kemudian melakukan include kode tersebut. Di dalam sistem ini jawaban kode peserta tidak disimpan dalam bentuk kode utuh melainkan harus ditulis ulang ke dalam berkas sebelum dievaluasi. #include "/submissions/123/source.c"

Kode V-7. Kode Skenario 5

6. Sistem diberikan kode, seperti yang sudah dijelaskan pada Subbab 2.4.2.2, yang akan memperlambat waktu kompilasi serta menggunakan memori yang terlalu banyak. Seperti halnya pada kode 1, penanganan kode ini harus dilakukan dengan membatasi waktu kompilasi. #include <map> using namespace std; typedef map M1; typedef map<M1,M1> M2; typedef map<M2,M2> M3; typedef map<M3,M3> M4; typedef map<M4,M4> M5; typedef map<M5,M5> M6; typedef map<M6,M6> M7; typedef map<M7,M7> M8; int main() { M8 tmp; }

Kode V-8. Kode Skenario 6

Parameter sandbox yang dipilih untuk seluruh seluruh kode pengujian kompilasi adalah “-w 1 -f –a 2 -m 10000 –c /tmp/” sedangkan parameter sandbox untuk pengujian yang bersifat runtime adalah “-f –a 2 –c /tmp/”. Parameter pertama akan membatasi waktu kompilasi, membatasi waktu kompilasi, membatasi pemanggilan system call, serta mengubah ke direktori tertentu untuk bekerja. Parameter hanya membatasi pemanggilan system call dan mengubah direktori kerja.

V-11

5.2.2.2. Hasil Pengujian Tabel V-3 menunjukkan hasil yang diharapkan untuk ditampilkan oleh aplikasi sandbox dan hasil pengujiannya. Tabel V-3. Pengujian Security No. 1 2 3 4 5 6

Hasil Diharapkan Time Limit Exceeded Forbidden System Call Forbidden System Call Compile Error Compile Error Out Of Memory

Hasil Didapat Time Limit Exceeded Forbidden System Call Forbidden System Call Compile Error Compile Error Out Of Memory

5.2.2.3. Evaluasi Pengujian Berdasarkan pengujian, kode-kode di atas dapat diatasi dengan menyesuaikan parameter-parameter yang telah disediakan oleh sandbox. Seorang task setter memiliki tanggung jawab untuk memanfaatkan sandbox yang disediakan dalam membuat tipe soalnya. 5.2.3. Pengujian aspek scalability Pengujian

ini

bertujuan

untuk

memeriksa

bahwa

penambahan

slave

mempengaruhi kecepatan feedback sistem dalam melakukan evaluasi jawaban peserta. 5.2.3.1. Strategi Pengujian Pada pengujian ini, dibuat skrip yang dapat mengumpulkan sejumlah jawaban yang diambil dari koleksi jawaban secara acak. Setiap jawaban dikumpulkan secara simultan tiap menit selama 10 menit sebanyak 3 kali. Lalu skrip akan memeriksa berapa banyak jawaban yang tersisa pada antrian evaluasi. Jumlah jawaban per menit akan ditingkatkan sampai sistem mengalami saturasi. Saturasi atau keadaan jenuh adalah keadaan di mana setelah waktu tersebut terdapat jawaban yang tersisa pada antrian. Keadaan ini disebabkan oleh jumlah waktu yang diperlukan oleh sistem untuk melakukan evaluasi seluruh antrian tersebut melebihi waktu yang ditentukan.

V-12

Pengujian ini dilakukan untuk 3 skenario yang berbeda. Skenario pertama adalah dengan menjalankan seluruh evaluasi pada sistem portable di mana evaluator berada pada mesin yang sama pada web. Skenario kedua adalah pada sistem online dengan sebuah slave. Skenario terakhir adalah pada sistem online dengan 2 buah slave. Jika terdapat perbedaan signifikan pada tingkat saturasi antara ketiga skenario maka pengerjaan evaluasi secara terdistribusi memberikan signifikansi kinerja. 5.2.3.2. Kasus Uji Untuk pengujian yang dilakukan, digunakan 2 macam kasus uji. Untuk kasus uji pertama, jawaban yang akan dikumpulkan diambil dari kumpulan jawaban hasil penggunaan sistem seperti yang dijelaskan pada Subbab 5.3. Pada kasus uji kedua, skrip akan selalu mengumpulkan jawaban yang sama.

Tabel V-4. Persebaran Waktu Evaluasi Jawaban Waktu Evaluasi (detik) < 0,010 0,010 ≤ x < 0,100 0,100 ≤ x < 1,000 1,000 ≤ x < 10,000 ≥ 10,000 Total

Jumlah 229 146 1161 244 63 1843

Persentase 12.4 8.0 63.0 13.2 3.4 100.0

Persebaran waktu evaluasi pada seluruh jawaban dapat dilihat pada Tabel V-4. Populasi jawaban terbanyak terletak pada rentang waktu 0.1 sampai 1 detik. Grafik pada Gambar V-5 menggambarkan persebaran jawaban tiap waktu evaluasi pada 54 soal yang ada. Untuk kasus pengujian kedua, jawaban akan diambil dari salah satu jawaban. Jawaban ini memiliki waktu evaluasi selama sekitar 5 detik. Kasus pengujian kedua ini ditujukan untuk menguji sistem dengan jawaban yang dengan tingkat kesulitan sedang.

V-13

140 J 120 a 100 w 80 a 60 b a 40 n 20 0 1

6

11

16

21

< 0,010 1,000 ≤ x < 10,000

26

31

36

41

Soal 0,010 ≤ x < 0,100 ≥ 10,000

46

51

0,100 ≤ x < 1,000

Gambar V-4. Grafik Persebaran Waktu Evaluasi Per Soal

5.2.3.3. Hasil Pengujian Hasil pengujian kasus uji pertama diperlihatkan oleh grafik pada Gambar V-5. Sumbu vertikal menggambarkan jumlah residu pada antrian jawaban pada akhir waktu pengujian. Sumbu horizontal menggambarkan jumlah jawaban setiap menitnya selama waktu pengujian berlangsung. Grafik menunjukkan rata-rata jumlah residu pada saat jumlah simultan tertentu per menit untuk setiap skenario. 600 500 R 400 e s 300 i d 200 u 100 0 10

20

30

Skenario 1

40

50

60

Jawaban / Menit Skenario 2

70

80

90

Skenario 3

Gambar V-5. Grafik Hasil Pengujian Untuk Kasus Uji 1

100

V-14

Pada skenario 1, dispatcher telah mencapai saturasi pada saat pengumpulan mencapai 40 buah jawaban per menit sedangkan pada skenario 2 saturasi sudah dicapai pada saat 30 buah per menit. Perbedaan kinerja skenario 2 yang lebih buruk daripada skenario 1 disebabkan oleh adanya tambahan waktu antara lain latensi jaringan dan proses encoding/decoding oleh library XML RPC. Dari log data pengujian, didapatkan rata-rata proses ini menambahkan waktu sekitar 0.32 detik setiap evaluasi. Bagi 63% jawaban (lihat Tabel V-5), waktu ini setara 300% sampai dengan 30% waktu evaluasi. Grafik juga memperlihatkan bahwa pada skenario 3 saturasi telah dicapai pada saat pengumpulan 60 buah jawaban per menit. Hal ini membuktikan bahwa dengan memperbanyak mesin slave untuk evaluasi maka kinerja evaluasi keseluruhan dapat ditingkatkan. Gambar V-6 menunjukkan hasil pengujian untuk kasus uji kedua. Dengan jawaban yang memiliki waktu evaluasi relatif lama, grafik pada skenario 1 dan skenario 2 tidak memiliki perbedaan yang jauh. Meski demikian dengan waktu evaluasi tersebut seluruh skenario mencapai tahap saturasi yang lebih cepat daripada pada kasus uji pertama.

R e s i d u

350 300 250 200 150 100 50 0 5

10

15

20

25

30

35

Jawaban / Menit Skenario 1

Skenario 2

Skenario 3

Gambar V-6 Grafik Hasil Pengujian Untuk Kasus Uji 2

40

V-15

5.2.3.4. Evaluasi Pengujian Dari hasil pengujian dapat disimpulkan bahwa sistem mampu meningkatkan kinerja proses evaluasi jika ditambahkan mesin evaluasi. Hal ini sesuai dengan hasil yang diharapkan. 5.3. Deployment Sistem Sistem pelatihan yang sudah dikembangkan ini telah digunakan untuk kegiatan Pelatihan Jarak Jauh Persiapan Olimpiade Sains Nasional Bidang Komputer yang diadakan oleh Tim Olimpiade Komputer Indonesia dari tanggal 14 Juli sampai dengan tanggal 29 Juli 2009 dan diikuti oleh 98 peserta dari seluruh daerah di Indonesia.

Gambar V-7. Persebaran Penggunaan Sistem TOKI Learning Center

Pada pelatihan ini sistem ditambahkan soal sebanyak 54 buah dengan tipe simple batch task. Jumlah jawaban yang terkumpul sebanyak 1843 buah. Pelatihan ini menggunakan sistem dengan mode portable yang seharusnya ditargetkan untuk penggunaan di jaringan lokal. Gambar V-7 memperlihatkan persebaran penggunaan sistem pelatihan TOKI LC. t