Bab V Implementasi dan Pengujian

(1)

V-1

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 masing-masing 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 MO-Eval [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.

(2)

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

-a Set file access level (0=none, 1=cwd, 2=/etc,/lib,...,

3=whole fs, 9=no checks; needs -f)

-c Change directory to <dir> first

-e Inherit full environment of the parent process

-E <var> Inherit the environment variable <var> from the parent process

-E <var>=<val> Set the environment variable <var> to <val>; unset it if <var> is empty

-f Filter system calls (-ff=very restricted)

-i <file> Redirect stdin from <file>

-m Limit address space to <size> KB

-o <file> Redirect stdout to <file>

-p <path> Permit access to the specified path (or subtree if it ends with a `/')

-p <path>=<act> Define action for the specified path (<act>=yes/no)

-r <file> Redirect stderr to <file>

-s <sys> Permit the specified syscall (be careful)

-s <sys>=<act> Define action for the specified syscall (<act>=yes/no/file)

-t <time> Set run time limit (seconds, fractions allowed)

-T Allow syscalls for measuring run time

-v Be verbose (use multiple times for even more verbosity)

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

(3)

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

Master <<device>> Slave <<device>> MO-EVAL Sandbox <<Application>> MO-EVAL Sandbox <<Application>> Client <<device>> Web Browser <<application>> Web Browser <<application>> Web Server <<application>> TOKI LC <<artifact>> Database Server TOKI-LC Database TOKI-LC Database HTTP 0..* 1 Dispatcher <<artifact>> XML RPC 1..* 1

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

Gambar V-2. Deployment Diagram untuk Mode Portable

Server <<device>> MO-Eval Sandbox <<application>> MO-Eval Sandbox <<application>> Client <<device>> Web Browser <<application>> Web Browser <<application>> Database Server <<application>> TOKI LC Database TOKI LC Database Web Server <<application>> TOKI LC <<artifact>> HTTP 1..* 1 Dispatcher <<artifact>>

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

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.

Client <<device>> Web Browser <<application>> MO-Eval Sandbox <<application>> Web Browser <<application>> MO-Eval Sandbox <<application>> Web Server <<application>> TOKI LC <<artifact>> Dispatcher <<artifact>>

(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 Berkas Status

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

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

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

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; }

(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"); }

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"

(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"

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<int,int> 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; }

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.

(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. Hasil Diharapkan Hasil Didapat

1 Time Limit Exceeded Time Limit Exceeded 2 Forbidden System Call Forbidden System Call 3 Forbidden System Call Forbidden System Call 4 Compile Error Compile Error 5 Compile Error Compile Error 6 Out Of Memory Out Of Memory

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.

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.

(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) Jumlah Persentase

< 0,010 229 12.4 0,010 ≤_{x < 0,100} ₁₄₆ _8.0 0,100 ≤_{x < 1,000} ₁₁₆₁ _63.0 1,000 ≤ x < 10,000 244 13.2 ≥ 10,000 63 3.4 Total 1843 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.

(13)

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.

Gambar V-5. Grafik Hasil Pengujian Untuk Kasus Uji 1 0 20 40 60 80 100 120 140 1 6 11 16 21 26 31 36 41 46 51 J a w a b a n Soal < 0,010 0,010 ≤ x < 0,100 0,100 ≤ x < 1,000 1,000 ≤ x < 10,000 ≥ 10,000 0 100 200 300 400 500 600 10 20 30 40 50 60 70 80 90 100 R e s i d u Jawaban / Menit

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

Gambar V-6 Grafik Hasil Pengujian Untuk Kasus Uji 2 0 50 100 150 200 250 300 350 5 10 15 20 25 30 35 40 R e s i d u Jawaban / Menit

(15)

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.