Bab III Analisis - digilib.itb.ac.id fileIII-1 Bab III Analisis Bab ini terdiri dari dua bagian...
-
Upload
truongphuc -
Category
Documents
-
view
233 -
download
8
Transcript of Bab III Analisis - digilib.itb.ac.id fileIII-1 Bab III Analisis Bab ini terdiri dari dua bagian...
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.