Bab IV Perancangan Dari hasil analisis pada Bab III, dilakukan perancangan terhadap masing-masing komponen pembentuk sistem pelatihan kompetisi pemrograman. Perancangan ini dibagi ke dalam dua bagian. Bagian pertama menjelaskan perancangan kelas berdasarkan analisis dari rumusan masalah yang telah dikaji. Bagian kedua menjelaskan perancangan antarmuka. 4.1. Perancangan Kelas
Subbab ini akan menjelaskan perancangan kelas-kelas utama yang diperlukan dalam pengembangan. 4.1.1. Perancangan Kelas Model
Dari analisis yang telah dilakukan pada Bab 3, entitas perangkat lunak dimodelkan ke dalam beberapa kelas. Gambar IV-1 menggambarkan kelas-kelas entity yang ada pada sistem dan relasi satu sama lain. Kelas User memiliki 3 relasi
dengan kelas Contest yakni sebagai contest owner, contest supervisor, dan contestant. Kelas ini juga memiliki relasi sebagai author sebuah problem type dan
sebuah problem.
User
1 1..* owner
+ID +Name
author
1 0..*
1..*
1
1
11
ProblemType +ID +Name
supervisor
1
0..*
0..* 0..* contestant
author
0..*
Contest
answerer
0..*
+ID +StartTime +EndTime
1
Problem 0..* 0..*
+ID +Title
questioner 1 1
1
0..* 0..*
0..*
Clarification +ID +Question +Answer
0..*
0..* 0..* 0..* Submission +ID +SubmitTime
Gambar IV-1. Rancangan Kelas Entitas
IV-1
IV-2
4.1.2. Perancangan Kelas Berdasarkan Analisis Masalah
Bagian ini akan menjelaskan perancangan kelas yang dipakai sebagai solusi dari masalah yang dikaji. 4.1.2.1. Security
Seperti yang telah dijelaskan pada Subbab 3.1.3, peran utama security terdapat pada komponen sandbox. Fungsi utama Sandbox adalah untuk mengeksekusi sebuah program sekaligus membatasi interaksi program tersebut dengan lingkungan serta konsumsi resource. Sekarang ini sudah terdapat beberapa aplikasi sandbox yang ada, salah satunya aplikasi sandbox yang dimiliki oleh MO-Eval [MAR07]. Sandbox ini dipilih karena aplikasi ini memiliki fitur yang sangat lengkap dan memiliki API yang mudah digunakan berupa command line interface. Aplikasi ini berjalan pada lingkungan sistem operasi Linux. Kelas Sandbox yang dibangun nantinya merupakan wrapper class yang akan
mengeksekusi aplikasi tersebut. Aplikasi selanjutnya akan dijelaskan pada Subbab 5.1.1
Sandbox +createTempFile() +createTempDir() +cleanTemporary() +execute()
Gambar IV-2. Diagram Kelas Sandbox
4.1.2.2. Extensibility
Untuk memudahkan pembuatan evaluator, problem-setter dapat menggunakan beberapa kelas API yang telah disediakan seperti Compiler, Comparator, serta Sandbox. Kelas Compiler bertugas untuk melakukan kompilasi kode sesuai
dengan bahasa pemrograman kode tersebut. Kelas ini akan mengeksekusi compiler dengan command line interface. Kelas Comparator bertugas untuk
membandingkan 2 buah berkas byte per byte. Kelas Sandbox bertugas untuk
IV-3
melakukan eksekusi pada lingkungan terisolasi seperti yang telah dijelaskan pada subbab sebelumnya. Compiler +compile() Sandbox Comparator
+createTempFile() +createTempDir() +cleanTemporary() +execute()
+compare()
Gambar IV-3. Diagram Kelas API Extensibility
Di dalam melakukan evaluasi terdapat kelas Dispatcher. Kelas ini pertama-tama mengambil sebuah instansiasi jawaban dari antrian jawaban. Selanjutnya kelas akan meload kelas-kelas API lain dan variabel-variabel konfigurasi. Selanjutnya instansiasi jawaban tersebut beserta kelas-kelas dan variabel konfigurasi akan diteruskan ke evaluator script yang dieksekusi oleh Dispatcher. Tabel IV-1. Format Paket ProblemType Nama Berkas view
Tipe Directory
view/description.html
HTML script
vieww/submit.php
PHP script
view/config.php view/submission.php view/controllers.php evaluator
PHP script PHP script PHP script Directory
evaluator/config.json
JSON script
evaluator/evaluator.php evaluator/files
PHP script Directory
Keterangan Berisi berkas-berkas tampilan sebuah problem type. Default template untuk sebuah soal. Halaman ini berupa HTML merupakan halaman statis. Template tampilan jawaban. Berupa skrip PHP karena memiliki konfigurasi dinamis Template tampilan form konfigurasi. Template tampilan sebuah jawaban. Berisi fungsi-fungsi controller. Berisi berkas-berkas tampilan sebuah problem type. Berkas berisi konfigurasi default untuk sebuah problem. Berkas evaluator. Berisi berkas-berkas pembantu evaluasi pada sebuah problem type.
Tabel IV-2 dan Tabel IV-3 masing-masing menjelaskan format paket problem type dan problem yang akan dipakai oleh sistem. Berkas evaluator.php adalah
berkas skrip PHP yang akan dieksekusi oleh Dispatcher tersebut. Konfigurasi
IV-4
yang akan dibuka oleh Dispatcher direpresentasikan oleh berkas config.json. Format JSON dipilih karena format ini sederhana dan tidak memakan space yang banyak jika dibandingkan dengan format data lainnya seperti XML. Berkasberkas ini disimpan dalam sebuah repositori.
Tabel IV-2. Format Paket Problem Nama Berkas view
Tipe Directory
view/description.html
HTML script
view/files
Directory
evaluator
Directory
evaluator/config.json
JSON script
evaluator/files
Directory
Keterangan Berisi berkas-berkas tampilan sebuah problem. Halaman HTML merupakan halaman statis. Berisi berkas-berkas view files. Yakni berkas-berkas pembantu seperti gambar dll. Berisi berkas-berkas tampilan sebuah problem type. Berkas berisi konfigurasi sebuah problem. Berisi berkas-berkas pembantu evaluasi pada sebuah problem.
ProblemType Packager +getConfig() +getEvaluatorFile() +getViewFile() +getEvaluator()
Dispatcher +dispatch()
Submission +status +gradecontent +submitcontent +dequeueSubmission()
+upack() +pack()
Problem +getConfig() +getEvaluatorFile() +getViewFile()
ProblemController +showDescription() +submitDescription() +showSubmission() +submitSubmission() +showConfig() +submitConfig() +showSubmitForm() +renderViewFile()
Gambar IV-4. Diagram Kelas Utama Extendibilty
IV-5
Kelas ProblemController berguna sebagai controller yang akan mengatur interaksi antara pengguna dengan berkas-berkas soal. Kelas ini berfungsi sebagai gerbang interaksi dari bermacam-macam URL entry ke berkas soal karena berkasberkas ini disimpan pada direktori yang tidak dapat diakses secara langsung melalui URL. Salah satu fungsinya juga adalah melakukan rendering berkasberkas view dari soal seperti gambar, dsb. Secara default semua berkas yang dilampirkan pada halaman description.html akan memiliki relative URL dengan dokumen tersebut. Oleh karena itu semua HTML tag terutama tag
dan tag ![]()
yang mencantu,kan lampiran
tersebut akan dimanipulasi terlebih dahulu oleh ProblemController agar halaman yang sudah dirender dapat menampilkan berkas berkas tersebut. Proses manipulasi dapat dilihat pada Tabel IV-3. Tabel IV-3. Contoh Pengubahan Lampiran pada Berkas Deskripsi Awal
Akhir
Dokum en
Dokumen
Di aspek ini, kelas ProblemType dan Problem memiliki tanggung jawab untuk memberikan data mengenai berkas-berkas yang ada pada keduanya. Operasioperasi yang ada pada kelas tersebut secara detil dijelaskan pada Tabel IV-4. Kelas Submission memiliki 3 buah atribut penting: status, gradecontent, submitcontent. Atribut status menandai sebuah submission ke dalam 4 buah status
antara lain •
NOGRADE
Menandai submission agar tidak dievaluasi. •
UNGRADED
Menandai submission agar dievaluasi. •
PENDING
Menandai submission yang sedang dievaluasi.
IV-6
•
GRADED
Menandai submission yang sudah berhasil dievaluasi. •
ERROR
Menandai submission yang gagal dievaluasi. Tabel IV-4. Penjelasan Kelas ProblemType dan Problem Kelas ProblemType
Operasi getConfig
getEvaluatorFile
getViewFile getEvaluator Problem
getConfig
getEvaluatorFile
getViewFile ProblemController
showDescription
submitDescription showSubmission submitSubmission showConfig submitConfig showSubmitForm renderViewFile
Keterangan Mengembalikan variabel konfigurasi yang ada di config.json pada paket problem type. Mengembalikan path ke berkas pembantu evaluator yang terdapat pada direktori evaluator/files pada paket problem type Mengembalikan path ke berkas-berkas view yang terdapat pada direktori view. Mengembalikan path dari berkas evaluator.php Mengembalikan variabel yang terdapat pada config.json milik paket problem. Jika variabel tersebut tidak ada maka variabel akan diload dari milik problemtype. Mengembalikan path dari sebuah berkas yang terdapat pada direktori evaluator/files Mengembalikan path dari sebuah berkas di direktori view/files Menampilkan deskripsi soal. Method ini melakukan manipulasi tag img dan a seperti yang sudah dijelaskan. Menyunting berkas deskripsi soal. Menampilkan jawaban. Melakukan pemrosesan pengumpulan submission. Menampilkan form pengaturan soal. Melakukan pemrosesan pengaturan soal. Menampilkan form pengumpulan jawaban. Menampilkan berkas view file.
Atribut submitcontent berisi data yang merupakan jawaban dari pengguna. Atribut gradecontent berisi data yang merupakan hasil evaluasi submission. Kedua atribut
ini memiliki format JSON string. Kelas Packager memiliki tugas untuk pemaketan problem. Method pack() memiliki fungsi untuk memaketkan sebuah problem menjadi paket portable problem yakni format soal yang dapat dibuka dan digunakan pada mode
IV-7
standalone. Kedua format paket problem type dan problem pada Tabel IV-1 dan Tabel IV-2 akan direduksi secara cascade menjadi format pada Tabel IV-5.
Format ini akan diarsipkan dengan menggunakan format arsip terkompresi ZIP. Method unpack() akan membuka arsip terkompresi tersebut dan meletakkannya pada filesystem mode standalone. Tabel IV-5. Format Paket Portable Problem Nama Berkas problem.json
Tipe JSON script
views
Directory
views/description.html
HTML script
views/submit.php
PHP script
views/submission.php views/controllers.php evaluators
PHP script PHP script Directory
evaluators/config.json
JSON script
evaluators/evaluator.php evaluators/files
PHP script Directory
Keterangan Berisi data-data mengenai problem seperti judul, pengarang, dll. Berisi berkas-berkas tampilan sebuah problem. Default template untuk sebuah soal. Halaman ini berupa HTML merupakan halaman statis. Template tampilan jawaban. Berupa skrip PHP karena memiliki konfigurasi dinamis Template tampilan sebuah jawaban. Berisi fungsi-fungsi controller. Berisi berkas-berkas tampilan sebuah problem. Berkas berisi konfigurasi default untuk sebuah problem. Berkas evaluator. Berisi berkas-berkas pembantu evaluasi pada sebuah problem.
4.1.2.3. Scalability
Di dalam aspek ini, diperlukan sebuah kelas yakni Slave untuk memodelkan mesin slave yang bekerja. Sebuah Slave akan memiliki 3 method utama yakni fetchSubmission
untuk
mengambil
submission
yang
akan
dievaluasi,
reportSubmission untuk melaporkan submission yang sudah dievaluasi, dan synchronizeProblem untuk melakukan sinkronisasi soal. Setelah melakukan fetchSubmission, kelas Slave akan meneruskan submission tersebut ke kelas Dispatcher.
IV-8
Submission +SubmissionQueue +dequeueSubmission()
Slave +lastCall +lastSynchronize +fetchSubmission() +reportSubmission() +synchronizeProblem()
. Gambar IV-5. Diagram Kelas Slave
Slave akan selalu mencatat pemanggilan terakhirnya pada atribut lastCall dan
sinkronisasi terakhirnya pada lastSync. Dengan demikian master masih bisa memeriksa status sinkronisasi problemnya dengan slave. Untuk mengambil submission
untuk
dievaluasi,
slave
melakukan
invokasi
static
method
dequeueSubmission.
4.2. Perancangan Antar Muka
Sistem ini memiliki antarmuka berupa halaman-halaman web. Setiap role pengguna memiliki navigasi yang mirip. Dari halaman awal, learner akan memiliki 3 pilihan utama yakni problem list, submission list, contest list. Dari problem list, halaman akan menampilan soal yang dapat dipilih. Soal ini akan
ditampilkan sesuai dengan berkas description.html yang ada pada paket soal. Pada deskripsi soal tersebut akan ada link menuju halaman pengumpulan jawaban. Jawaban yang disubmit akan diproses di controller dan halaman akan berganti ke halaman submission. Navigasi dapat dilihat pada Gambar IV-6. Peraga berupa lingkaran hitam adalah titik awal navigasi dan yang memiliki lingkaran di luarnya adalah akhir navigasi. Bagian Learner’s Menu merupakan bagian menu yang ada di semua halaman untuk role Learner. Garis horizontal menandakan link yang bisa diakses dari halaman yang sama.
IV-9
<<page>> Home
<
> Learner's Menu
[link:signout] [link:contests]
[link:problems] [link:submissions] <<page>> ProblemList
<<page>> Submission List
<<page>> Contest List
[select submission]
[select problem] <<page>> Problem
<<page>> Submission View
[select contest] <<page>> Contest
[submit]
<<part>> Submit Form
Gambar IV-6. Diagram Navigasi untuk role Learner
Navigasi untuk role Coach mirip dengan navigasi untuk role Learner. Untuk role ini akan terdapat beberapa halaman tambahan seperti create problem, edit problem, create problem type, dan edit problem type.
<<page>> Home
<> Coach Menu
[link:signout] [link:contests]
[link:problems] [link:submissions] <<page>> ProblemList
<<page>> Submission List
<<page>> Contest List
[link:submission] [select problem] [link:create/edit problem] <<page>> Create/Edit Problem
<<page>> Submission View
[select contest] [link:create contest]
<<page>> Problem <<page>> Create Contest
<<page>> Contest
<<page>> Create/Edit ProblemType
Gambar IV-7. Diagram Navigasi untuk role Coach
IV-10
Antarmuka umum pada sebuah soal maupun jawaban tergantung daripada apa yang didefinisikan oleh task setter pada task view files seperti pada Tabel IV-2 dan Tabel IV-3. Berikut contoh antar muka pada task dengan tipe batch: 1. Description View. View ini menampilkan deskripsi soal yang nantinya dibaca oleh Learner.
Deskripsi ini menjelaskan mengenai gambaran soal dan spesifikasi dari jawaban yang harus dibuat oleh Learner. Dalam tipe soal batch, deskripsi menejelaskan cerita gambaran singkat dari soal, format keluaran, format masukan, contoh masukan, dan contoh keluaran.
Gambar IV-8. Contoh tampilan description view
2. Submit View. View ini berisi form pengumpulan jawaban untuk peserta. Pada tipe soal ini, form berisi upload file field di mana peserta melakukan pengumpulan
jawaban berupa berkas kode.
IV-11
Gambar IV-9. Contoh tampilan submit view.
3. Submission View. Submission View berisi tampilan submission beserta hasil penilaiannya.
Gambar IV-10. Contoh tampilan submission view
IV-12
4. Task Config View. Task config view berisi antarmuka bagi coach untuk melakukan konfigurasi
soal. Untuk tipe soal ini, task config berisi form konfigurasi untuk time limit, execution time limit, memory limit, dan pasangna-pasangan testcase.
Gambar IV-11. Contoh tampilan task config view
Selain itu ada tambahan WYSWYG form untuk melakukan penyuntingan berkas description.html untuk soal.
Gambar IV-12. WYSWYG editor untuk penyuntingan description view.
