III-1

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

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

Gambar III-1. Fungsionalitas terkait task.

System

Learner

Task Setter

View Task

Submit Answer

View Result

Manage Task

Manage Task Type

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

berkas 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. Konfigurasi-

konfigurasi yang mungkin didefinisikan antara lain: compiler argument,

run time limit, memory limit, testcase files, point per testcase, dan lain-

lain 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, c++), dan 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 soal-

soal 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 paket-

paket 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 Deskripsi

FR-OLJ-01 Sistem mampu menampilkan daftar soal soal

FR-OLJ-02 Sistem mampu menampilkan soal

FR-OLJ-03 Sistem mampu melakukan grading jawaban pengguna

FR-OLJ--04 Sistem mampu menampilkan hasil jawaban pengguna

FR-CTS-01 Sistem mampu menampilkan daftar kontes

FR-CTS-02 Sistem mampu menampilkan daftar soal kontes

FR-CTS-03 Sistem mampu menampilkan rangking kontes

FR-CTS-04 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 Deskripsi

NFR-01 Sistem mampu melakukan penilaian jawaban peserta dengan stabil tanpa

terpengaruh banyaknya jawaban.

NFR-02 Sistem mampu melakukan penilaian jawaban peserta yang berupa kode

program dengan aman

NFR-03 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

Gambar III-5. Model Use Case Online Judge

System

Coach

Learner

Browse Problems

Manage Problems

Manage Problem Type

Submit Answer

Update Package

Browse Submissions

III-14

3.2.3.1.2. Contest Management

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 Actor Deskripsi

AC-LR Learner Pengguna sistem yang menjadi target utama dari sistem

yakni pelajar sekolah menengah.

AC-CT Contestant Learner yang telah terdaftar sebagai peserta sebuah

kontes.

AC-CH Coach Pengguna sistem yang terdiri atas pembina

AC-CS Contest Supervisor Coach yang telah diassign untuk membantu jalannya

sebuah kontes.

AC-CO Contest Owner Coach yang mengadakan sebuah kontes.

System

Contest Owner

Create Contest

CoachManage Users

Learner

Contestant

Ask Clarification

Manage Contest Problems

Contest Supervisor

Reply Clarification

Browse Contest Problems

Submit Contest Answer

Browse Contest Submissions

Browse Contest Ranking

III-15

3.2.5. Definisi Use Case

Tabel III-4. Daftar Definisi Use Case

ID Use Case Deskripsi

UC-OLJ-01 Browse Problems Melihat daftar soal yang ada. Pengguna juga dapat

melihat soal dari daftar serta mengunduh paket soal

tersebut.

UC-OLJ-02 Submit Answer Mengumpulkan jawaban.

UC-OLJ-03 Browse

Submissions

Melihat daftar jawaban yang sudah dikumpulkan

dan melihat hasil penilaian sebuah jawaban.

UC-OLJ-04 Manage Problem Membuat dan mengatur soal.

UC-OLJ-05 Manage Problem

Type

Membuat dan mengatur tipe soal.

UC-OLJ-06 Update Package Melakukan update paket soal yang ada pada sistem.

UC-CTS-01 Create Contest Membuat sebuah kontes. Pengguna harus mengisi

nama kontes, deskripsi kontes, waktu

penyelenggaraan.

UC-CTS-02 Manage Contest

Users

Melakukan pengaturan role pengguna yang ada di

kontes.

UC-CTS-03 Ask For

Clarification

Meminta klarifikasi jika ada keraguan mengenai

soal kontes.

UC-CTS-04 Reply Clarification Menjawab permintaan klarifikasi

UC-CTS-05 Browse Contest

Ranking

Melihat ranking kontes. Ranking dihitung dari

akumulasi hasil penilaian pengumpulan solusi

peserta.

UC-CTS-06 Manage Contest

Problems

Melakukan manajemen soal yang ada pada kontes

yakni menambahkan soal kontes dari arsip soal,

menghilangkan soal kontes dari daftar soal, dan

menambahkan soal baru.

UC-CTS-07 Browse Contest

Problems

Melihat dan membaca soal-soal yang terdapat

dalam kontes.

UC-CTS-08 Submit Contest

Answer

Mengumpulkan jawaban soal kontes.

UC-CTS-09 Browse Contest

Submissions

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 Nama Use Case Online Portable Standalone

UC-OLJ-01 Browse Problems √ √

UC-OLJ-02 Submit Answer √ √

UC-OLJ-03 Browse Submissions √ √

UC-OLJ-04 Manage Problem √

UC-OLJ-05 Manage Problem Type √ √

UC-OLJ-06 Update Package √

UC-CTS-01 Create Contest √ √

UC-CTS-02 Manage Contest Users √ √

UC-CTS-03 Ask For Clarification √ √

UC-CTS-04 Reply Clarification √ √

UC-CTS-05 Browse Contest Ranking √ √

UC-CTS-06 Manage Contest Problems √ √

UC-CTS-07 Browse Contest Problems √ √

UC-CTS-08 Submit Contest Answer √ √

UC-CTS-09 Browse Contest Submissions √ √

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.