Bab III Analisis Bab ini terdiri dari dua bagian yakni Analisis Masalah dan Analisis Perangkat Lunak. Bagian pertama menjelaskan masalah yang menjadi fokus utama Tugas Akhir yakni pengembangan sistem pelatihan kompetisi pemrograman komputer beserta analisis solusinya. Bagian selanjutnya berisi analisis perangkat lunak yang dibangun. 3.1. Analisis Masalah Sesuai dengan apa yang telah diacu pada Subbab I.2, masalah yang ingin difokuskan antara lain bagaimana melakukan pemaketan dan pengembangan sebuah task pada kontes pemrograman, bagaimana membuat online system yang mampu melakukan volume penilaian task submission yang berjumlah besar dengan baik, dan bagaimana melakukan penilaian secara aman. Meski Tugas Akhir ini ditujukan untuk pelajar sekolah menengah, masalah yang ini mencakup kompetisi pemrograman secara umum. Di dalam sebuah kontes pemrograman, task adalah sebuah soal yang harus dikerjakan oleh peserta kontes. Format task ini bermacam-macam pada konteskontes pemrograman yang sudah ada. Meski demikian umumnya sistem manajemen kontes pemrograman yang sudah ada hanya menyediakan format task yang sudah ditentukan dan tidak bisa dikembangkan oleh pengguna yang disebut coach, yakni pengguna yang bertugas untuk membuat task-task untuk kontes pemrograman. Untuk memfasilitasi perkembangan variasi soal dan pemaketan task untuk pelajar (learner) yang melakukan latihan mandiri maka dibutuhkan format pemaketan task sehingga dengan sistem yang dibuat nanti coach dapat bebas mengembangkan variasi format task dan pengguna lain dapat menggunakan tanpa harus melakukan perubahan pada sistem. Selain itu sebuah sistem pelatihan kompetisi pemrograman online yang ditujukan untuk pemakaian massal harus memiliki sifat-sifat robust, scalable, dan secure.
III-1
III-2
Kinerja yang ditunjukkan oleh sistem dalam hal ini adalah pengevaluasian submission pelajar. Sistem harus dapat melakukan proses evaluasi secara adil dan memiliki waktu respons yang cepat tanpa terpengaruh banyaknya submission yang dikumpulkan oleh pelajar. Sistem juga harus dapat mengevaluasi submission secara aman dan juga dapat berjalan dengan lancar meski terjadi kerusakan yang diakibatkan oleh submission. Untuk itu diusulkan arsitektur sistem menggunakan sistem dengan beban kerja terdistribusi kepada banyak node. Untuk masalah keamanan dilakukan perancangan berdasarkan jenis-jenis serangan serta panduan yang telah dijelaskan pada Subbab 2.2.1.2. Selain itu juga diusulkan penggunaan Live Operating System untuk sistem pelatihan mandiri bagi pelajar. 3.1.1. Extensibility Umumnya pada sebuah sistem pelatihan dan kontes, fungsionalitas yang disediakan bagi pelajar berkaitan dengan task management adalah view task description, submit answer, dan view result. Setelah pelajar melakukan pengumpulan maka system akan melakukan evaluasi submission untuk mendapatkan nilai dari submission tersebut. Sedangkan bagi task setter adalah manage task. Karena nantinya task setter akan dapat menambahkan atau mengatur task type maka sistem akan mempunyai fungsionalitas tambahan yakni manage task type. System ViewTask Manage Task
Learner
Task Setter
Submit Answer Manage Task Type ViewResult
Gambar III-1. Fungsionalitas terkait task.
III-3
Kebanyakan kontes yang sudah ada menggunakan tipe batch task atau sering disebut input/output task yakni task-type di mana pelajar mengumpulkan jawaban berupa kode program. Kode ini akan kemudian akan dikompilasi. Setelah itu sistem akan menjalankan program ini dengan memberikan test case masukan. Keluaran dari program akan dibandingkan dengan test case keluaran. Kebenaran program ditentukan dari kesamaan test case yang telah disiapkan dengan keluaran yang dihasilkan dalam waktu serta penggunaan resource yang telah ditentukan. Contoh soal untuk batch task dan output only dapat dilihat pada Lampiran B. Meskipun format soal tersebut umum, tipe batch sendiri juga ditemui beberapa variasi penilaian pada kontes-kontes yang ada. Variasi-variasi pada tipe-tipe soal yang memungkinkan antara lain 1. Format Jawaban Format jawaban bervariasi dari mulai sebuah kode program utuh, potongan fungsi program, potongan kelas program, atau juga sebuah berkas teks sederhana. 2. Kompilasi Jawaban Format jawaban yang berupa kode program utuh, potongan fungsi, atau kelas program biasanya perlu dikompilasi terlebih dahulu menjadi format executables. Setiap task type mungkin membutuhkan proses kompilasi yang berbeda-beda mulai dari compiler dan compiler argument yang digunakan. Misalnya untuk tipe jawaban yang berupa potongan fungsi, coach harus menyiapkan template program utama yang akan digunakan untuk mengkompilasi menjadi executables. 3. Eksekusi Program Executables yang telah dihasilkan dari kompilasi program tersebut akan dijalankan untuk mengetahui hasil. Hasil ini diambil dari keluaran program dapat berupa penulisan ke berkas yang telah di tentukan oleh deskripsi task, standard output yang diteruskan ke dalam berkas dengan menggunakan pipe ataupun langsung ditangkap oleh sistem. 4. Pemeriksaan Hasil
III-4
Pemeriksaan hasil biasanya berupa pembandingan antara berkas keluaran dari eksekusi program dengan test case yang sudah didefinisikan sebelumnya. Ada beberapa tipe soal di mana coach menyediakan aplikasi atau skrip yang memeriksa hasil keluaran tersebut. 5. Parameter Penilaian Cara penilaian pada masing-masing peraturan kontes dapat berbeda-beda. Untuk tipe batch sendiri, ada peraturan yang memberikan penilaian parsial pada setiap test case akan tetapi ada juga peraturan yang mengharuskan program menghasilkan keluaran yang sama untuk seluruh test case. Oleh karena itu, untuk memfasilitasi variasi tersebut diputuskan membuat sistem ini menjadi sederhana dan lebih moduler bagi coach untuk mengembangkan variasi task-typenya masing-masing. Di dalam task packaging sebuah task, sebuah task package dibagi ke dalam 2 bagian yakni task-type files dan task files. 1. Task-Type Files Task-type files adalah berkas-berkas yang digunakan untuk mendefinisikan sebuah task-type. a. Views Views adalah berkas-berkas yang mendefinisikan antar muka antara sebuah task dengan pengguna. a) Description View Template Berkas ini mendefinisikan template untuk deskripsi task pada sebuah task-type. b) Task Configuration View Berkas ini mendefinisikan view untuk konfigurasi sebuah task. c) Submit View Berkas ini akan mendefinisikan view bagi pelajar untuk mensubmit jawaban. d) Result View
III-5
Berkas ini akan mendefinisikan umpan balik atau hasil dari evaluasi jawaban. e) View Controller Berkas ini merupakan script yang mendefinisikan kelakuan sistem saat pengguna berinteraksi dengan view di atas. Selain dari view controller, berkas-berkas view merupakan berkas-berkas HTML. b. Evaluator Script. Evaluator script adalah sebuah skrip yang dijalankan oleh sistem saat akan melakukan evaluasi dari sebuah submission. Sistem akan menyediakan fungsi-fungsi dasar yang dapat dipanggil oleh skrip ini: mengambil data submission, melakukan kompilasi, mengambil berkasberkas task, melakukan eksekusi, melakukan validasi, dan lain-lain. c. Configuration Template Berkas ini merupakan template dari berkas konfigurasi yang akan digunakan oleh setiap evaluator script. Berkas ini sendiri merupakan script yang yang menyediakan variabel-variabel beserta nilai-nilai default. d. Task-Type Helpers Helpers adalah kumpulan berkas yang akan dipakai oleh evaluator script. Berkas-berkas ini dapat berupa binary executables ataupun skrip yang dapat dijalankan oleh evaluator script. 2. Task Files a. Description Views Description Views merupakan berkas Description View Template yang telah disunting sedemikian rupa untuk setiap task ditambah dengan berkas-berkas lain seperti gambar yang akan dipakai oleh deskripsi tersebut. Berkas-berkas ini nantinya merupakan antar muka bagi pelajar untuk mengetahui apa yang harus dikerjakan dari sebuah task.
III-6
b. Configuration Configuration file merupakan sebuah skrip yang variabel-variabel yang akan dipakai oleh evaluator script untuk melakukan evaluasi. Evaluator script pertama-tama akan mengambil nilai-nilai default yang terdapat pada configuration template kemudian mengambil nilai-nilai yang didefinisikan pada configuration file pada setiap task. Konfigurasikonfigurasi yang mungkin didefinisikan antara lain: compiler argument, run time limit, memory limit, testcase files, point per testcase, dan lainlain tergantung dari konfigurasi yang dibutuhkan oleh evaluator script. c. Task Helpers. Task Helpers adalah berkas-berkas lain yang dibutuhkan oleh evaluasi. Berkas-berkas ini akan berbeda-beda untuk setiap task pada task-type yang sama. Yang termasuk ke dalam jenis ini adalah berkas-berkas test case. Dengan adanya konfigurasi seperti di atas coach dapat mengembangkan task-type baru secara fleksibel. Untuk pemaketan yang digunakan bagi latihan mandiri, paket akan berisi seluruh berkas yang ada baik dari task-type files dan task files. 3.1.2. Scalability Lamanya sebuah submission dievaluasi berbeda-beda untuk setiap task dari submission yang terus. Sebuah submission untuk tipe batch task misalnya dapat biasanya berlangsung hingga 1 detik untuk setiap test case. Penggunaan test case yang banyak akan meningkatkan waktu evaluasi submission tersebut. Waktu respons hasil evaluasi adalah hal yang penting bagi pengguna. Misalnya pada suatu saat terjadi 20 pengumpulan untuk soal dengan waktu evaluasi total 30 detik maka waktu respons bagi seorang pengguna paling lama adalah sekitar 600 detik atau 10 menit. Oleh karena itu dibutuhkan peningkatan kinerja dengan melakukan evaluasi secara paralel. Sistem ini nantinya akan terdiri dari sebuah source node dan beberapa server node yang identik. Source node adalah komputer yang akan menampung submission sedangkan server node adalah komputer yang akan melakukan evaluasi
III-7
submission. Seluruh server node akan dikondisikan homogen yakni memiliki kesamaan spesifikasi perangkat keras serta perangkat lunak yang sedang dijalankan. Hal ini dimaksudkan untuk menjaga fairness pada saat evaluasi submission. Submission yang dievaluasi pada sebuah server node diharapkan menghasilkan hasil evaluasi yang tidak jauh berbeda dari server node yang lain. Arsitektur ini akan dijelaskan lebih lanjut pada Subbab 3.2.7.1. Algoritma load sharing yang diusulkan menggunakan strategi server initiative. Hal ini dipilih karena source node hanya ada satu sehingga tidak perlu ada overhead untuk melakukan penghitungan untuk memilih source yang untuk job selanjutnya. Data evaluator yang sudah dijelaskan pada Bab 3.1.1. akan disimpan secara rendundan oleh seluruh server node. Data yang perlu dikomunikasikan hanyalah data submission. Data evaluator dapat disimpan karena memiliki volume yang cukup besar dan sifatnya tidak terlalu sering mengalami perubahan. Dengan demikian traffic komunikasi yang terjadi dapat diminimalisasi.
Gambar III-2. State sebuah server node.
Seperti yang ditunjukkan pada Gambar III-2, server node akan mempunyai 4 buah state yakni A. Fetching Fetching adalah state di mana server node akan melakukan permintaan data submission kepada source node untuk dievaluasi. Source node akan mengembalikan data seperti task dari jawaban, kode jawaban, jenis file
III-8
jawaban
(pascal,
c,
dan
c++),
lain-lain.
Gambar III-3. Proses Fetching-Evaluating-Reporting
B. Evaluating Setelah melakukan fetching, server node akan segera melakukan evaluation. Server segera mencari evaluator files yang dari task milik submission bersangkutan. Server akan menjalankan evaluator tersebut terhadap submission. C. Reporting Hasil-hasil yang telah didapatkan dari evaluating akan dilaporkan kepada source. Setelah proses pelaporan selesai maka server node akan kembali melakukan fetching. D. Synchronizing Suatu saat evaluator dapat diubah oleh coach. Jika itu terjadi maka data evaluator yang telah terdapat seluruh server node perlu diupdate untuk proses evaluasi selanjutnya. Meski di dalam melakukan pembagian kerja, source node tidak perlu mencatat status sebuah server tapi untuk melakukan sinkronisasi data, source harus mengetahui kapan terakhir kali server node melakukan sinkronisasi. Ketika server node meminta task dari source node setelah terjadi penyuntingan data maka source node akan memeriksa
waktu
sinkronisasi
terakhir
server
node
dan
akan
mengembalikan perintah sinkronisasi kepada server tersebut. Server
III-9
kemudian akan melakukan sinkronisasi. Sinkronisasi diasumsikan tidak pernah gagal di tengah proses.
Gambar III-4. Proses Synchronizing
3.1.3. Security Berdasarkan panduan pada Subbab 2.2.1.2, proses evaluasi teutama pada saat eksekusi tidak lepas dari penggunaan sandbox. Sandbox adalah bagian yang paling penting di dalam menjaga keamanan pada proses evaluasi. Sandbox ini memiliki tugas untuk mengeksekusi sebuah program dengan membatasi interaksi antara program dengan lingkungannya dan konsumsi resource dari sistem seperti waktu, memori, dan space. Selain digunakan untuk melakukan eksekusi program dari submission, sandbox juga dapat dipakai untuk melakukan eksekusi proses kompilasi atau skrip-skrip lain yang dipanggil pada saat proses evaluasi. Pada saat program dijalanin, sandbox akan memeriksa setiap function call yang dipanggil oleh program. Sandbox ini akan memutuskan apakan function call tersebut boleh dijalankan atau tidak dan program berhak diteruskan atau langsung diterminasi. Function call yang biasanya dilarang pada kontes pemrograman antara lain membuat proses baru (fork), mengakses file-file yang seharusnya tidak boleh diakses, dan menjalankan thread. Pembatasan waktu dapat dilakukan dengan memonitor proses secara periodik. Jika proses melebihi waktu yang ditentukan maka proses akan diterminasi. Pembatasan memori dilakukan dengan menggunakan fungsi yang telah disediakan oleh kernel seperti setrlimit pada Linux. Mekanisme ini sebenarnya menambah overhead dalam proses eksekusi akan tetapi selama setiap submission akan
III-10
dijalankan dengan menggunakan mekanisme yang sama maka proses dianggap adil. 3.2. Analisis Perangkat Lunak Subbab ini akan berisi analisis dari perangkat lunak yang akan dikembangkan pada Tugas Akhir ini. 3.2.1. Deskripsi Sistem Tim Olimpiade Komputer Indonesia Learning Center atau dengan nama singkat TOKI-LC adalah sebuah sistem yang digunakan di dalam proses pelatihan dan seleksi untuk TOKI. Penjelasan mengenai TOKI dapat dilihat pada Lampiran A. Sistem ini nantinya dipakai untuk menggantikan sistem yang sudah dipakai sebelumnya. Pengguna utama dari sistem ini terdiri dari 2 macam: pelajar sekolah menengah dan pembina TOKI. Pelajar sekolah menengah adalah sasaran utama dari pembinaan TOKI. Pembina TOKI adalah kumpulan orang yang menjalankan tahap penjaringan dan pembinaan itu sendiri. Pembina TOKI
terdiri dari anggota institusi-institusi
yang
telah
ditunjuk
untuk
menjalankan proses penjaringan dan pembinaan 3.2.1.1. Fungsionalitas Pada subbab ini akan dibahas mengenai fungsionalitas utama yang dimiliki oleh sistem yakni Online Judge dan Contest System. Fungsionalitas ini diadopsi dari online judge dan programming contest management system yang dijelaskan pada Bab 2. 3.2.1.1.1.
Online Judge
Online Judge adalah sebuah sistem di mana pelajar yang telah terdaftar pada sistem dapat membuka daftar soal dan mengerjakan soal tersebut. Sebuah soal (task) terdiri atas nama soal, pengarang soal, waktu penulisan soal, tipe soal, dan deskripsi soal. Pelajar dapat mencari dan melihat daftar soal berdasarkan data-data tersebut. Pada halaman soal akan terdapat link ke halaman upload jawaban. Selain itu pelajar juga dapat melihat hasil evaluasi dari jawaban tersebut serta sejarah dari pengerjaan soal-soal yang telah dilakukan.
III-11
3.2.1.1.2.
Contest Management
Kontes adalah sebuah acara yang diadakan pada jangka waktu tertentu dan diikuti oleh sejumlah pelajar untuk berkompetisi satu sama lain dalam mengerjakan soalsoal yang diberikan. Kontes terdiri dari 2 macam: terbuka dan tertutup. Pada kontes terbuka, pelajar bebas melakukan registrasi untuk berpartisipasi, sedangkan pada kontes tertutup kontestan hanya terdiri dari pelajar yang telah dipilih. Sebuah kontes ini dipimpin oleh seorang contest owner dan dibantu oleh beberapa contest supervisor. Contest owner bertugas untuk membuat kontes, mengatur konfigurasinya (waktu pelaksanaan, nama kontes, dll), melakukan assignment contest supervisor, melakukan assignment kontestan, melakukan assignment contest task dan lain-lain. Contest supervisor bertugas untuk membantu contest owner dalam pengawasan kontes termasuk menjawab pertanyaan pelajar. Pelajar yang telah melakukan registrasi dan terdaftar sebagai kontestan kemudian dapat melihat soal-soal yang dapat dikerjakan. Kontestan dapat mengirimkan submission dari halaman yang sudah disediakan. Selain itu kontestan dapat melihat daftar ranking yang ada pada kontes jika diperbolehkan oleh contest owner dan juga melihat hasil evaluasi dari submission masing-masing. 3.2.1.2. Mode Deployment Selain fungsionalitas di atas, sistem ini dapat digunakan dalam beberapa mode: online, portable, dan standalone. 3.2.1.2.1. Online Sistem online dapat diakses oleh seluruh pengguna lewat jaringan internet. Sistem ini ditujukan untuk pelatihan atau seleksi dengan sasaran pengguna pelajar sekolah menengah yang tersebar di Indonesia. Sistem ini akan dideploy di lingkungan ITB dan diakses oleh para pelajar tersebut. 3.2.1.2.2. Portable Sistem portable digunakan untuk mengadakan kontes di mana peserta berada di dalam satu jaringan lokal. Mode ini diperlukan untuk memudahkan mengadakan sebuah kontes pada lingkungan berada di dalam jaringan yang tidak terkoneksi ke
III-12
internet. Sistem ini hanya digunakan untuk mengadakan kontes saja. Oleh karena itu mode ini memiliki fungsi yang lebih sedikit daripada mode online. 3.2.1.2.3. Standalone Mode ini ditujukan agar pelajar dapat melakukan latihan tanpa harus memiliki koneksi internet setiap saat. Pada mode ini, pelajar diberikan aplikasi yang sudah berisi paket soal beserta evaluator. Pelajar dapat membuka atau mencari soal yang sudah dipaketkan. Setelah itu pelajar dapat mengerjakan soal dan mengumpulkan jawaban tersebut ke dalam sistem. Jawaban tersebut kemudian akan dievaluasi dengan evaluator yang sudah terintegrasi. Pelajar juga dapat mendownload paketpaket soal secara terpisah dari sistem dan melakukan update soal yang terdapat pada sistem standalone. 3.2.2. Spesifikasi TOKI-LC 3.2.2.1. Spesifikasi Fungsional Seperti yang sudah dibahas sebelumnya, sistem ini akan mengimplementasikan 5 jenis kebutuhan utama: kurikulum, bank soal, bank unit latihan, kontes, dan pelatihan. Untuk mendukung kebutuhan tersebut, fungsi-fungsi yang harus diimplementasikan pada sistem antara lain Tabel III-1. Daftar Fungsionalitas Sistem ID FR-OLJ-01 FR-OLJ-02 FR-OLJ-03 FR-OLJ--04 FR-CTS-01 FR-CTS-02 FR-CTS-03 FR-CTS-04
Deskripsi Sistem mampu menampilkan daftar soal soal Sistem mampu menampilkan soal Sistem mampu melakukan grading jawaban pengguna Sistem mampu menampilkan hasil jawaban pengguna Sistem mampu menampilkan daftar kontes Sistem mampu menampilkan daftar soal kontes Sistem mampu menampilkan rangking kontes Sistem mampu menampilkan klarifikasi kontes
3.2.2.2. Kebutuhan Non Fungsional Karena harus dapat digunakan secara mudah oleh seluruh siswa dan pembina dari seluruh Indonesia, TOKI-LC harus dapat berjalan dengan efisien, memiliki aksesibilitas tinggi, keamanan yang baik, dan juga memiliki antarmuka yang mudah dipahami oleh seluruh pengguna. Selain itu TOKI-LC juga harus
III-13
memiliki ekstensibilitas yang baik sehingga pembina dapat dengan mudah merancang jenis soal yang baru dan mengimplementasikannya pada sistem ini.
Tabel III-2. Daftar Kebutuhan Non Fungsional SRS-ID NFR-01 NFR-02 NFR-03
Deskripsi Sistem mampu melakukan penilaian jawaban peserta dengan stabil tanpa terpengaruh banyaknya jawaban. Sistem mampu melakukan penilaian jawaban peserta yang berupa kode program dengan aman Sistem mampu diakses dengan mudah
3.2.3. Pemodelan Analisis Sistem 3.2.3.1. Model Use Case Subbab ini akan menggambarkan model use case untuk sistem seperti yang telah dijelaskan pada Bab 3.2.1.1. dengan penambahkan fungsionalitas system management yang menyediakan fungsionalitas-fungsionalitas dalam melakukan manajemen sistem dan pengguna. 3.2.3.1.1. Online Judge
System Manage Problems
Browse Problems
Coach
Manage Problem Type Learner Submit Answer
Browse Submissions
Update Package
Gambar III-5. Model Use Case Online Judge
III-14
3.2.3.1.2. Contest Management
System Create Contest Learner
Coach
Manage Users Ask Clarification Manage Contest Problems
Reply Clarification
Contest Owner
Contestant Browse Contest Problems
Submit Contest Answer Contest Supervisor
Browse Contest Submissions
Browse Contest Ranking
Gambar III-6. Model Use Case Contest Management
3.2.4. Definisi Aktor Seperti yang telah dijelaskan pada bagian 3.2, terdapat 2 jenis pengguna yang akan menggunakan TOKI-LC: Pelajar dan Pembina. Pada sistem ini, pengguna pelajar akan direpresentasikan dengan peran Learner sedangkan pengguna Pembina akan direpresentasikan dengan peran Coach. Pada Contest Management akan ada role tambahan yang dikenakan kepada role tersebut.
Tabel III-3. Daftar User Role ID AC-LR
Actor Learner
AC-CT
Contestant
AC-CH AC-CS
Coach Contest Supervisor
AC-CO
Contest Owner
Deskripsi Pengguna sistem yang menjadi target utama dari sistem yakni pelajar sekolah menengah. Learner yang telah terdaftar sebagai peserta sebuah kontes. Pengguna sistem yang terdiri atas pembina Coach yang telah diassign untuk membantu jalannya sebuah kontes. Coach yang mengadakan sebuah kontes.
III-15
3.2.5. Definisi Use Case Tabel III-4. Daftar Definisi Use Case ID UC-OLJ-01
Use Case Browse Problems
UC-OLJ-02 UC-OLJ-03
Submit Answer Browse Submissions Manage Problem Manage Problem Type Update Package Create Contest
UC-OLJ-04 UC-OLJ-05
UC-OLJ-06 UC-CTS-01
UC-CTS-02 UC-CTS-03 UC-CTS-04 UC-CTS-05
Manage Contest Users Ask For Clarification Reply Clarification Browse Contest Ranking
UC-CTS-06
Manage Contest Problems
UC-CTS-07
Browse Contest Problems Submit Contest Answer Browse Contest Submissions
UC-CTS-08 UC-CTS-09
Deskripsi Melihat daftar soal yang ada. Pengguna juga dapat melihat soal dari daftar serta mengunduh paket soal tersebut. Mengumpulkan jawaban. Melihat daftar jawaban yang sudah dikumpulkan dan melihat hasil penilaian sebuah jawaban. Membuat dan mengatur soal. Membuat dan mengatur tipe soal. Melakukan update paket soal yang ada pada sistem. Membuat sebuah kontes. Pengguna harus mengisi nama kontes, deskripsi kontes, waktu penyelenggaraan. Melakukan pengaturan role pengguna yang ada di kontes. Meminta klarifikasi jika ada keraguan mengenai soal kontes. Menjawab permintaan klarifikasi Melihat ranking kontes. Ranking dihitung dari akumulasi hasil penilaian pengumpulan solusi peserta. Melakukan manajemen soal yang ada pada kontes yakni menambahkan soal kontes dari arsip soal, menghilangkan soal kontes dari daftar soal, dan menambahkan soal baru. Melihat dan membaca soal-soal yang terdapat dalam kontes. Mengumpulkan jawaban soal kontes. Melihat daftar jawaban yang sudah dikumpulkan dan melihat hasil penilaian sebuah jawaban.
3.2.6. Pemetaan Use Case Seperti yang sudah dijelaskan pada Subbab 3.2.1.1. sistem online akan memiliki fungsionalitas sebagai Online Judge dan Contest Management. Sistem portable akan memiliki fasilitas Contest Management ditambah dengan manajemen problem type. Aplikasi standalone hanya memiliki fitur-fitur terkait pengerjaan soal yang bebas dari kontes apapun.
III-16
Tabel III-5. Daftar Pemetaan Use Case ID Use Case UC-OLJ-01 UC-OLJ-02 UC-OLJ-03 UC-OLJ-04 UC-OLJ-05 UC-OLJ-06 UC-CTS-01 UC-CTS-02 UC-CTS-03 UC-CTS-04 UC-CTS-05 UC-CTS-06 UC-CTS-07 UC-CTS-08 UC-CTS-09
Nama Use Case Browse Problems Submit Answer Browse Submissions Manage Problem Manage Problem Type Update Package Create Contest Manage Contest Users Ask For Clarification Reply Clarification Browse Contest Ranking Manage Contest Problems Browse Contest Problems Submit Contest Answer Browse Contest Submissions
Online
Portable
√ √ √ √ √
√
√ √ √ √ √ √ √ √ √
√ √ √ √ √ √ √ √ √
Standalone
√ √ √ √
3.2.7. Deskripsi Arsitektural Pada subbab ini akan dibahas mengenai rancangan arsitektural TOKI-LC dekomposisi komponen, pembagian tanggung jawab dan proses yang dilakukan oleh tiap komponen. 3.2.7.1. Online Ada tiga buah tingkatan pada TOKI-LC: presentation tier, logic tier, dan data tier. Antarmuka sistem terhadap pengguna ditangani oleh web browser pada komputer client. Pada logic tier terdapat dua buah komponen utama: front-end dan back-end. Dan pada data tier, terdapat storage di mana seluruh data seperti data pengguna, paket soal, dan data-data lain disimpan. Aplikasi front-end bertugas sebagai antarmuka TOKI-LC dengan protokol HTTP menggunakan bahasa pemrograman PHP. Komponen front-end dirancang sebagai aplikasi web agar aplikasi dapat diakses dari komputer manapun yang terhubung dengan internet, sebagaimana telah disebutkan dalam kebutuhan non fungsional TOKI-LC. PHP dipilih sebagai bahasa pemrograman untuk pengembangan aplikasi web karena PHP merupakan bahasa pemrograman web yang paling populer saat ini. Dengan demikian di masa yang akan datang diharapkan para pengembang yang tertarik dapat dengan mudah untuk ikut mengembangkan.
