BAB III ANALISIS. 3.1 Deskripsi Sistem III-1

Transkripsi

1 BAB III ANALISIS Kegiatan pengajaran pemrograman pada Program Studi Sarjana Teknik Informatika ITB (S1- IF-ITB) sejak tahun 2006 diikuti oleh mahasiswa dalam jumlah besar, sehingga timbul kebutuhan akan sebuah alat bantu pengajaran untuk menilai source code mahasiswa. Dalam Tugas Akhir ini, akan dibangun sebuah perangkat lunak autograder untuk memenuhi kebutuhan S1-IF-ITB. Pembangunan autograder akan dilakukan dengan menggunakan acuan perangkat lunak autograder yang sudah ada, sebagaimana telah dibahas pada Subbab Autograder ini akan memiliki karakteristik khusus, yaitu dirancang untuk mampu menangani berbagai bahasa pemrograman yang digunakan dalam kegiatan pengajaran S1-IF-ITB, pada Tugas Akhir ini yang diimplementasikan yaitu Lisp dan Pascal. Perangkat lunak autograder yang sudah ada saat ini umumnya hanya menangani bahasa pemrograman C++ dan Java saja. Autograder yang akan dibangun pada Tugas Akhir ini diberi nama Phobos. Dalam bab Analisis ini, akan diberikan penjelasan mengenai konteks pengembangan, analisis proses penilaian, dan spesifikasi kebutuhan untuk autograder yang akan dibangun. Konteks pengembangan untuk autograder Phobos pada Subbab 3.1 akan memberikan deskripsi singkat mengenai Learning Management System milestone dan autograder Phobos sebagai sebuah sistem mandiri. Pembahasan mengenai proses penilaian pada Subbab 3.2 akan memberikan latar belakang perancangan proses penilaian otomatis, dan besaran-besaran penilaian yang akan diterapkan dalam Phobos. Di dalam Subbab 3.3 akan didefinisikan secara formal kebutuhan perangkat lunak untuk Phobos. 3.1 Deskripsi Sistem Dalam pengajaran pemrograman pada S1-IF-ITB, terdapat beberapa bentuk kegiatan dengan hasil berupa program, antara lain praktikum, tugas besar dan ujian praktek. Dalam praktikum, mahasiswa berlatih membuat program dengan topik tertentu di laboratorium. Praktikum umumnya dilaksanakan tiap minggu, dengan batas akhir pengumpulan deliverable berupa source code program bervariasi antara pada akhir waktu praktikum (untuk ujian praktikum dan topik praktikum yang mudah) atau setelah praktikum (untuk topik yang lebih rumit). Tugas besar pada umumnya dilakukan secara berkelompok, dengan jangka waktu pengerjaan berkisar 2-3 minggu, dengan deliverable berupa source code program dan dokumentasinya. Ujian praktek menguji kemampuan siswa untuk membuat program secara individual dalam laboratorium. III-1

2 III-2 Berbagai kegiatan yang berlangsung dalam pengajaran pemrograman pada S1-IF-ITB ini akan ditangani oleh suatu Learning Management System (LMS). Learning Management System adalah sekumpulan perangkat lunak dan proses yang saling terhubung, berbagi data dan berkontribusi dalam manajemen pengalaman pembelajar dalam sebuah institusi [JIS06]. LMS yang dibangun untuk menangani berbagai kegiatan pengajaran pemrograman pada S1- IF-ITB bernama milestone. Saat ini, milestone telah digunakan untuk pengumpulan dan manajemen tugas pemrograman. Representasi Learning Management System milestone sebagai sebuah use case sistem dapat dilihat pada Gambar III-1. System Meng-upload tugas pemrograman Berkomunikasi Mahasiswa Memberi tugas Instruktur Melakukan penilaian Mendeteksi plagiarisme Gambar III-1 Diagram Use-Case Sistem milestone Fungsi penilaian pada LMS milestone akan ditangani secara khusus oleh sebuah sistem autograder terpisah. Tugas Akhir ini akan membahas mengenai pengembangan sebuah sistem penilaian source code otomatis baru yang dinamai Phobos. LMS milestone tidak akan dibahas lebih lanjut, karena hanya melakukan proses pengumpulan source code tugas pemrograman saja dan tidak menangani permasalahan penilaian. Autograder Phobos bertugas melakukan penilaian otomatis terhadap sekumpulan source code yang berasal dari hasil tugas pemrograman yang telah diserahkan oleh mahasiswa. Dengan kata lain, Phobos merupakan alat bantu yang dapat digunakan oleh instruktur untuk menilai tugas pemrograman siswa dalam jumlah besar secara otomatis. Meskipun Phobos direncanakan sebagai salah satu komponen dari LMS milestone, dalam Tugas Akhir ini Phobos dirancang agar dapat juga digunakan dan diuji sebagai suatu sistem mandiri.

3 III-3 Pembangunan autograder Phobos didasari oleh kebutuhan proses pengajaran pemrograman dalam S1-IF-ITB yang belum dipenuhi oleh aplikasi autograder yang sudah ada. Beberapa aplikasi autograder yang telah dibuat, seperti CourseMaster atau GAME, memiliki sifat generik, yaitu mampu menangani source code dalam berbagai bahasa pemrograman. Dari berbagai aplikasi autograder generik yang telah dieksporasi, bahasa yang ditangani umumnya adalah C++ dan Java. Belum ada autograder generik yang mencakup bahasa pemrograman dasar yang digunakan pada S1-IF-ITB, Lisp dan Pascal. Pada Tugas Akhir ini, Phobos dibangun untuk melakukan penilaian source code dalam bahasa pemrograman Lisp, Pascal, namun dirancang agar dapat dikembangkan lebih lanjut untuk menangani bahasa C, C++ dan Java. Autograder Phobos akan melakukan penilaian otomatis dengan masukan berupa skema penilaian dan source code yang akan dinilai dari instruktur. Phobos akan menyimpan skema penilaian dan data uji dalam bentuk file XML, source code yang dinilai dalam bentuk arsip terkompresi, sementara hasil proses penilaian disimpan dalam basis data. Hasil penilaian kemudian dapat ditampilkan dalam bentuk laporan nilai kolektif, yang dapat di-drill down menjadi laporan nilai individu. Source code yang hendak dinilai dapat berasal dari tugas besar, praktikum, ujian praktek, atau dari kegiatan lainnya, misalnya latihan mandiri atau pelatihan lomba pemrograman. Secara umum, dalam pembahasan Tugas Akhir ini, setiap kegiatan dengan hasil berupa source code yang hendak dinilai disebut sebagai penugasan (assignment). Hasil source code yang diserahkan oleh mahasiswa untuk penugasan tertentu disebut sebagai serahan tugas atau tugas yang diserahkan (submitted assignment). Definisi skema penilaian (marking scheme definition) adalah daftar jenis penilaian yang dilakukan terhadap tugas dan bobot relatif masing-masing penilaian terhadap nilai keseluruhan. Secara tidak langsung, definisi skema penilaian juga sekaligus bertindak sebagai skenario penilaian yang dilakukan terhadap source code. Jika penilaian yang hendak dilakukan hanya terdiri dari penilaian eksekusi, maka dalam skema penilaian hanya dicantumkan jenis penilaian eksekusi saja. Jika penilaian yang hendak dilakukan hanya berupa penilaian whitebox, maka dalam definisi skema penilaian hanya dicantumkan penilaian jenis whitebox saja. Definisi skema penilaian juga dapat memuat kombinasi dari berbagai jenis penilaian yang hendak dijalankan. Definisi skema penilaian harus dibuat secara terpisah untuk setiap penugasan yang hasilnya yang hendak dinilai.

4 III-4 Jika hendak dilakukan penilaian eksekusi, maka skema penilaian harus memuat data uji. Data uji (test data) adalah sekumpulan butir uji yang akan digunakan untuk uji eksekusi. Butir uji (test item) adalah pasangan data masukan untuk program yang diuji beserta data keluaran yang diharapkan dari program untuk masukan tersebut. Data uji harus mengandung cukup banyak butir uji agar dapat memilih butir uji secara acak. Skenario uji (test scenario) adalah butir uji yang telah dipilih secara acak oleh autograder untuk penilaian eksekusi pada serahan tugas tertentu. Laporan nilai yang dihasilkan oleh autograder Phobos ada dua macam, yaitu laporan nilai kolektif dan laporan nilai individu. Laporan nilai kolektif adalah daftar nilai akhir sekumpulan serahan tugas untuk penugasan tertentu. Laporan nilai individu adalah kombinasi dari nilai kuantitatif hasil pengukuran besaran-besaran penilaian untuk satu serahan tugas, beserta dengan penjelasan tekstual singkat mengenai nilai yang dihasilkan (khususnya jika pengukuran besaran penilaian menghasilkan nilai di luar batas normal). Pada bagian berikutnya, akan dianalisis lebih mendalam mengenai proses penilaian yang dilakukan, masukan yang dibutuhkan dan keluaran dari sistem autograder Phobos. Detil lebih lanjut mengenai definisi skema penilaian, data uji dan laporan nilai akan diberikan pada bab perancangan. 3.2 Penilaian Program Otomatis Sebuah sistem penilai source code otomatis harus dirancang dengan cermat, karena berhubungan langsung dengan proses belajar mahasiswa. Dalam Tugas Akhir ini, sistem autograder dirancang untuk mengikuti proses penilaian yang dilakukan oleh manusia. Sebagaimana telah dibahas pada Subbab 2.1.2, proses penilaian tugas pemrograman secara otomatis menggunakan sistem komputer dapat mengikuti proses penilaian tugas manual sampai dengan level tertentu. Analisis proses penilaian tugas otomatis yang didasarkan pada proses penilaian manual akan dibahas pada Subbab Otomasi proses pengujian program otomatis akan dibahas secara khusus dalam Subbab

5 III Proses Penilaian Source Code Manual Sebagaimana telah dibahas pada Subbab 2.1.2, penilaian tugas source code merupakan sekumpulan proses yang bertujuan melakukan evaluasi terhadap masukan berupa source code, yang hasilnya dinyatakan secara kuantitatif dalam bentuk nilai akhir. Setelah tugas berupa source code diserahkan oleh siswa, dapat dilakukan penilaian blackbox maupun whitebox. Dalam penilaian blackbox, source code dikompilasi untuk menghasilkan sebuah program executable yang dapat dijalankan oleh penilai. Penilai kemudian melakukan penilai terhadap program dengan cara memberikan masukan kepada program dan mengevaluasi hasil keluarannya. Dalam penilaian whitebox, penilai akan melakukan analisis terhadap source code untuk menilai aspek intrinsik kode seperti kompleksitas dan keterbacaan program. Nilai hasil eksekusi program dan/atau nilai source code akan kemudian menjadi masukan untuk proses perhitungan nilai akhir, yang kemudian akan dapat dikembalikan kepada siswa. Pada proses penilaian manual, definisi proses penilaian dan pengujian dapat bersifat intrinsik dalam individu penilai. Skema penilaian atau definisi proses pengujian tidak mutlak harus ditentukan secara konkrit terlebih dahulu. Penilai manusia dapat memberikan nilai dengan mempertimbangkan berbagai aspek sekaligus, termasuk semantik program. Penilai manusia juga dapat menguji program secara langsung pada saat eksekusi dengan memberikan masukan secara impromptu lalu mengevaluasi keluaran yang dihasilkan oleh program. Dalam penilaian manual, penilai dapat memberikan evaluasi terhadap hasil pengerjaan tugas dalam bentuk komentar atau pembahasan solusi kepada siswa secara langsung seperti melalui diskusi dengan siswa, maupun secara tidak langsung ketika siswa bertanya kepada penilai. Sebagaimana telah dibahas pada bab 2.1.1, nilai dan penjelasan ini merupakan umpan balik yang amat berguna terhadap proses pembelajaran siswa. Kelebihan proses penilaian manual yaitu bahwa proses penilaian dapat bersifat fleksibel, dengan proses penilaian yang bervariasi sesuai dengan konteks pemberian tugas dan skala tugas. Konteks pemberian tugas yang diperhitungkan dalam proses penilaian umumnya menyangkut aspek konseptual tugas dan bahasa pemrograman yang digunakan. Aspek konseptual tugas adalah keterkaitan antara tugas dengan konsep tertentu yang harus dikuasai oleh siswa. Sebagai ilustrasi, tugas praktikum bertopik stack membutuhkan penilaian khusus untuk implementasi primitif yang terkait pada konsep stack, seperti push atau pop. Bahasa pemrograman yang digunakan untuk tugas tertentu juga dapat mempengaruhi proses

6 III-6 penilaian. Sebagai ilustrasi, tugas praktikum yang menggunakan bahasa C dan C++ harus membutuhkan penilaian khusus untuk manajemen memori (karena bahasa-bahasa ini tidak menyediakan manajemen memori otomatis). Penilaian manual dapat ikut mempertimbangkan konteks tugas karena penilai manusia dapat memahami konteks pemberian tugas dengan mudah. Skema penilaian yang digunakan oleh penilai manual dapat berubah-ubah secara fleksibel dari satu tugas ke tugas yang lain, bergantung pada topik dan skala tugas. Proses penilaian manual memiliki kelemahan yaitu menghabiskan banyak sumber daya karena diperlukan waktu, pemikiran dan tenaga penilai untuk melakukan evaluasi terhadap hasil kerja siswa. Selain itu, penilai manusia juga cenderung bersifat subjektif terhadap individu penilai maupun terhadap tugas yang dinilai, terlebih lagi jika skema penilaian dan proses pengujian tidak didefinisikan secara konkrit Proses Penilaian Source Code Otomatis Pada Subbab ini akan dibahas mengenai proses penilaian tugas pemrograman otomatis dengan keterbatasannya, variasi proses penilaian otomatis, serta batasan dan karakteristik pada masing-masing varian. Pada proses penilaian otomatis, sistem komputer yang disebut autograder menggantikan penilai untuk melakukan kompilasi, uji eksekusi program, analisis source code, dan perhitungan nilai. Penilaian eksekusi program siswa secara otomatis dilakukan dengan cara menyediakan masukan yang akan diberikan kepada program siswa, dan kemudian mencocokkan keluaran yang dihasilkan oleh program siswa dengan keluaran yang diharapkan. Penilaian source code dilakukan dengan cara mengukur besaran-besaran penilaian source code yang telah dibahas pada Subbab dan mengubahnya ke dalam nilai. Dengan penilaian eksekusi program dan penilaian source code (yang merupakan proses yang paling memakan sumber daya) dilakukan secara otomatis, proses penilaian dapat dilakukan dengan cepat tanpa menghabiskan banyak waktu dan tenaga penilai manusia. Hal ini merupakan kelebihan dari proses penilaian otomatis. Sebuah autograder dapat menghasilkan nilai kuantitatif dari source code tugas siswa. Penilai otomatis dapat memberikan penjelasan berupa laporan hasil penilaian secara mendetil dan pesan untuk kesalahan yang timbul, namun tidak dapat memberikan evaluasi berupa komentar atau pembahasan sebagaimana pada proses penilaian manual. Hal ini merupakan kelemahan dari proses penilaian otomatis.

7 III-7 Sebuah autograder membutuhkan definisi konkrit langkah-langkah penilaian (termasuk pengujian program siswa) agar dapat menjalankan penilaian secara otomatis, baik dengan cara meletakkannya dalam program / hardcoded, ataupun sebagai masukan autograder. Proses penilaian yang dilakukan terhadap setiap source code menjadi seragam. Di satu sisi, hal ini menjadi kelebihan proses penilaian otomatis karena penilaian oleh autograder bersifat objektif. Di sisi lain, hal ini menyebabkan proses penilaian oleh autograder tidak akan memiliki fleksibilitas dalam menilai tugas sesuai dengan konteks dan skala program sejauh penilaian manual. Implementasi proses penilaian otomatis menggunakan autograder yang definisi langkah penilaian dan pengujiannya terkandung dalam instruksi program / hardcoded adalah implementasi yang paling tidak fleksibel, karena perubahan proses penilaian akan mengakibatkan pengodean ulang pada autograder. Proses penilaian otomatis dapat dibuat lebih fleksibel dengan menjadikan merancang autograder sebagai sebuah alat bantu berisi sekumpulan fungsi penilaian yang dapat dijalankan oleh penilai. Autograder kemudian dirancang untuk menerima definisi skema penilaian, yang berisi daftar penilaian yang akan dijalankan. Dengan demikian, proses penilaian untuk setiap penugasan dapat dibuat berbedabeda satu sama lain. Hal ini disebabkan karena secara tidak langsung, jenis-jenis penilaian yang tercantum pada definisi skema penilaian akan menjadi langkah-langkah proses penilaian yang dijalankan oleh autograder. Meskipun autograder dirancang dengan masukan berupa definisi skema penilaian, kemampuannya untuk melakukan penilaian yang berkorelasi dengan konteks tugas (aspek konseptual dan bahasa pemrograman) masih tetap terbatas. Aspek konseptual tugas bersifat spesifik terhadap masing-masing tugas. Penilaian terhadap aspek konseptual membutuhkan pemahaman terhadap semantik program, yang sebagaimana telah dibahas pada Subbab belum dimiliki oleh autograder manapun. Penilaian kontekstual yang spesifik terhadap bahasa pemrograman tertentu akan mengakibatkan autograder terikat pada bahasa pemrograman tersebut, dan hal ini bukan merupakan karakteristik yang diharapkan. Alternatif implementasi di mana skema penilaian dijadikan sebagai masukan autograder inilah yang akan dibahas lebih lanjut dalam Tugas Akhir ini. Ikhtisar mengenai perbandingan fitur-fitur pada proses penilaian manual dan otomatis dapat dilihat pada Tabel III-1. Pada ikhtisar tersebut juga diberikan ringkasan fitur-fitur penilaian otomatis yang dimiliki oleh ketiga aplikasi autograder yang dibahas pada Subbab dibandingkan dengan Phobos.

8 III-8 Tabel III-1 Perbandingan fitur proses penilaian manual, autograder yang sudah ada & Phobos Fitur Penilaian Penilaian Manual ASSYST [JAC97] Skema penilaian fleksibel Ya Bobot saja Umpan balik kepada siswa Sumber data uji Penilaian konteks program Detil nilai Pesan kesalahan Penjelasan Konsep tugas Bahasa pemrograman Ya, Subjektif Ya Ya, Subjektif Penilai Ya Autograder CourseMaster GAME [ZIN91] [BLU04] Bobot & Proses Bobot saja Phobos Bobot & Proses Tidak Ya Tidak Ya Ya Tidak Terbatas Tidak Terbatas Penilai & submisi siswa Ada Penilai Penilai Penilai C++, Java Tidak Semantik program Ya Tidak C, C++, Java Lisp, Pascal 3.3 Spesifikasi Autograder Phobos Berdasarkan analisis penilaian tugas otomatis yang telah dijelaskan pada Subbab 3.2, maka dibuat spesifikasi untuk sebuah perangkat lunak source code autograder yang dinamai Phobos. Pada Subbab ini diberikan model use case dan skenario penggunaan, spesifikasi fungsional dan non fungsional beserta deskripsi arsitektural dan dekomposisi subsistemsubsistem dalam autograder Phobos Model Use Case untuk Phobos Berdasarkan analisis proses penilaian otomatis pada Subbab 3.2.2, maka dapat dibuat model use case untuk Phobos. Diagram use case untuk Phobos akan dibahas pada Subbab , sementara skenario use case Phobos akan dibahas pada Subbab Diagram Use Case Phobos Berdasarkan kebutuhan fungsional yang telah ditentukan, maka use case yang dimiliki oleh Phobos ada 4, yaitu membuat skema penilaian, menilai tugas source code secara otomatis, melihat laporan nilai, dan menghapus hasil penilaian. Diagram use case untuk Phobos dapat dilihat pada Gambar III-2.

9 III-9 Menilai eksekusi program System Membuat definisi skema penilaian <<extend>> Menilai SLOC program Instruktur Menilai Tugas Source Code secara Otomatis Melihat Laporan Nilai <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> Menilai kompleksitas siklomatik Menilai proporsi komentar Menilai identitas file Menilai nama identifier Menghapus Hasil Penilaian Menilai indentasi kode Menilai efisiensi program Gambar III-2 Diagram Use Case Phobos Phobos dirancang sebagai alat bantu pengajaran pemrograman, sehingga aktor yang dilibatkan dalam use case ini adalah instruktur. Di masa depan, Phobos dapat juga dikembangkan dalam skenario interaktif yang melibatkan siswa. Kemungkinan skenario interaktif ini tidak akan dibahas lebih lanjut dalam Tugas Akhir ini. Keterangan selengkapnya mengenai aktor dalam diagram tersebut dapat dilihat pada Tabel III-2. Tabel III-2 Definisi Aktor dalam Diagram Use Case Phobos Aktor Instruktur Keterangan Pengguna Phobos yang bertanggung jawab untuk menyediakan definisi skema penilaian, memulai penilaian otomatis dan memberikan source code. Instruktur juga dapat melihat hasil penilaian. Dalam praktek, peran aktor dapat dilaksanakan oleh dosen atau asisten. Karena instruktur dapat memilih penilaian apa saja yang akan dilakukan oleh autograder, maka use case menilai tugas source code (PHB-UC-02) dapat mencakup berbagai use-case untuk penilaian yang dapat dilakukan oleh Phobos. Proses pemilihan jenis-jenis penilaian yang berkorespondensi dengan masing-masing use case akan dibahas pada Subbab Keterangan selengkapnya mengenai seluruh use case dalam diagram tersebut dapat dilihat pada Tabel III-3.

10 III-10 Tabel III-3 Definisi Use-Case untuk Phobos Nomor Use Case Deskripsi PHB-UC-01 Membuat definisi skema penilaian Membuat skema penilaian, yang berisi spesifikasi tugas (deskripsi tugas dan jenis-jenis penilaian) dan data uji yang akan digunakan dalam proses penilaian oleh sistem autograder PHB-UC-02 Menilai source code Melakukan proses penilaian terhadap serahan tugas yang berupa source code. Proses penilaian dimulai dengan interpretasi source code dan eksekusi bersama data uji untuk menguji ketepatan program. Source code kemudian dianalisis menurut besaran-besaran penilaian analitik. Hasil penilaian kemudian dikombinasikan menurut skema penilaian untuk menghasilkan nilai akhir dari source code. PHB-UC-03 Melihat laporan nilai Melihat laporan nilai hasil proses penilaian oleh autograder. PHB-UC-04 Menghapus hasil penilaian Menghapus data hasil penilaian yang pernah dibuat oleh autograder engine jika tidak lagi diperlukan. PHB-UC-05 Menilai eksekusi program Menilai program berdasarkan hasil eksekusi dengan menggunakan data uji. PHB-UC-06 Menilai SLOC program Menilai kompleksitas program berdasarkan jumlah baris kode (tanpa baris komentar) dari program. PHB-UC-07 Menilai kompleksitas siklomatik Menilai kompleksitas program berdasarkan jumlah alur percabangan eksekusi pada program. PHB-UC-08 Menilai proporsi komentar Menilai keterbacaan kode berdasarkan jumlah baris komentar terhadap total baris source code dan rata-rata panjang baris komentar. PHB-UC-09 Menilai keberadaan identitas pembuat source code Menilai keterbacaan kode berdasarkan kepatuhan terhadap konvensi mengenai pemberian identitas untuk tiap file source code PHB-UC-10 Menilai nama identifier Menilai keterbacaan kode berdasarkan rata-rata panjang nama identifier. PHB-UC-11 Menilai indentasi kode Menilai keterbacaan kode berdasarkan ketepatan indentasi kode. PHB-UC-12 Menilai efisiensi program Menilai efisiensi kode berdasarkan rata-rata jumlah eksekusi perintah source code program Skenario Penggunaan Phobos Pada Subbab ini akan dijelaskan tentang skenario penggunaan Phobos untuk membuat skema penilaian, menilai submisi tugas, dan melihat laporan nilai. Skenario yang digambarkan pada bagian ini merupakan skenario normal. Skenario use case selengkapnya dapat dilihat pada LAMPIRAN D. Skenario penggunaan autograder Phobos untuk membuat definisi skema penilaian dapat dilihat pada Gambar III-3. Pada skenario ini terdapat prekondisi bahwa aplikasi telah menampilkan form pembuatan skema penilaian baru kepada pengguna (instruktur). Berikut ini adalah penjelasan skenario tersebut :

11 III Instruktur membuat definisi skema penilaian pada form aplikasi dan mengirimkannya kepada autograder Phobos melalui web browser. 2. Browser mengirimkan data definisi skema penilaian kepada autograder Phobos 3. Autograder Phobos menyimpan definisi skema penilaian pada persistent storage 4. Autograder Phobos mengirimkan pesan keberhasilan beserta definisi skema penilaian yang telah disimpan. 5. Web browser menampilkan pesan dan definisi skema penilaian yang baru dari autograder. Gambar III-3 Skenario penggunaan Phobos untuk membuat definisi skema penilaian Skenario penggunaan autograder Phobos untuk menilai source code dapat dilihat pada Gambar III-4. Pada skenario ini terdapat prekondisi bahwa aplikasi telah menampilkan form berisi daftar source code dan definisi skema penilaian pada sistem kepada pengguna (instruktur). Berikut ini adalah penjelasan skenario tersebut : 1. Instruktur memberikan alamat tempat file arsip berisi serahan-serahan tugas berupa source code yang hendak dinilai serta definisi skema penilaian yang hendak digunakan kepada halaman aplikasi web Phobos. 2. Web browser meneruskan request tersebut menuju autograder Phobos. 3. Autograder Phobos memulai penilaian terhadap seluruh serahan tugas dalam satu praktikum, termasuk di dalamnya membangkitkan proses penilaian sesuai dengan definisi skema penilaian yang diminta hingga laporan nilai tersimpan pada persistent storage. Selama proses ini, koneksi antara browser dengan Autograder Phobos tetap dipertahankan. 4. Autograder Phobos mengirimkan status bahwa penilaian telah selesai dilakukan. 5. Web browser menampilkan pesan bahwa penilaian otomatis telah selesai dilakukan.

12 III-12 Gambar III-4 Skenario penggunaan Phobos untuk menilai source code Skenario penggunaan autograder Phobos untuk melihat hasil penilaian dapat dilihat pada Gambar III-5. Pada skenario ini terdapat prakondisi bahwa aplikasi telah menampilkan semua laporan nilai yang tersedia pada sistem kepada pengguna (instruksi). Berikut ini adalah penjelasan skenario tersebut : 1. Instruktur memilih laporan nilai tugas yang hendak dilihat melalui web browser. 2. Web browser meneruskan permintaan laporan tersebut menuju autograder Phobos. 3. Autograder Phobos melakukan query pada persistent storage untuk mengambil isi laporan dan mengatur format laporan nilai dalam bentuk HTML. 4. Autograder Phobos mengirimkan laporan nilai kepada pengguna. 5. Web browser menampilkan laporan nilai kepada pengguna. 1 5 Web Browser 2 HTTP 4 Phobos 3 Persistent Storage Instruktur Komputer user Komputer yang terinstalasi Phobos Gambar III-5 Skenario penggunaan Phobos untuk melihat laporan nilai

13 III-13 Skenario penggunaan autograder Phobos untuk menghapus data hasil penilaian dapat dilihat pada Gambar III-5. Pada skenario ini terdapat prakondisi bahwa aplikasi telah menampilkan semua proses penilaian yang telah dilakukan dan hasilnya tersedia pada sistem. Berikut ini adalah penjelasan skenario tersebut : 1. Instruktur memilih laporan nilai tugas yang hendak dihapus melalui web browser. 2. Web browser meneruskan permintaan laporan tersebut menuju autograder Phobos. 3. Autograder Phobos menghapus data hasil penilaian dari persistent storage. 4. Autograder Phobos mengirimkan laporan keberhasilan penghapusan data. 5. Web browser menampilkan laporan keberhasilan penghapusan data kepada pengguna. Gambar III-6 Skenario penggunaan Phobos untuk menghapus hasil penilaian Spesifikasi Fungsional Phobos Autograder Phobos dirancang sebagai alat bantu dengan serangkaian kemampuan penilaian yang dapat dikombinasikan. Kemampuan penilaian yang dimaksud dalam hal ini adalah kemampuan melakukan penilaian dari source code secara kuantitatif sebagaimana telah dibahas pada Subbab 2.2. Dari ringkasan jenis penilaian pada Tabel II-7, dapat disusun daftar jenis penilaian yang dapat dilakukan Phobos pada Tabel III-4. Beberapa jenis penilaian dari Tabel II-7 tidak diimplementasikan karena realisasi penilaian tersebut untuk berbagai bahasa pemrograman terlalu rumit atau tidak sesuai. Deteksi struktur kode yang berbahaya dan pengukuran jumlah instruksi dan memori tidak diimplementasikan karena realisasinya untuk aplikasi multibahasa terlalu rumit. Kompleksitas Henry dan Kafura tidak diimplementasikan karena pengukuran besaran aliran data tidak cocok digunakan untuk tugas pemrograman yang rata-rata berukuran kecil. Penilaian-penilaian yang berkaitan dengan struktur blok juga tidak diimplementasikan, karena struktur blok tidak dikenal dalam paradigma pemrograman fungsional.

14 III-14 Tabel III-4 Jenis penilaian otomatis Phobos Pendekatan Blackbox Pendekatan WhiteBox Aspek penilaian Ketepatan Sintaks & Semantik Efisiensi Kompleksitas Tipografi kode Jenis Penilaian Phobos Besaran Penilaian Kebutuhan Perangkat Lunak Kebenaran sintaksis program Keberadaan struktur kode yang berpotensi menimbulkan bug. Pengujian dinamis Lamanya eksekusi program Jumlah memori yang digunakan program. SLOC Mengkompilasi program dan menangkap kesalahan kompilasi (tidak diimplementasikan) Menghitung persentase data uji benar dan menangkap runtime error Mengukur waktu yang diperlukan untuk eksekusi program (tidak diimplementasikan) Menghitung jumlah baris source code yang diberikan K. Halstead (tidak diimplementasikan) K. Henry & Kafura (tidak diimplementasikan) K. Siklomatik Keberadaan keterangan pada kode Proporsi Whitespace Menghitung jumlah titik percabangan dalam kode Memeriksa keberadaan identitas file kode Menghitung persentase jumlah baris komentar Menghitung persentase karakter dalam komentar Menghitung rata-rata panjang baris Menghitung rata-rata jumlah karakter kosong dalam baris Perimbangan Delimiter Identifier yang bermakna Ketepatan Indentasi Konvensi Spesifik Bahasa Pemrograman (tidak diimplementasikan) Menghitung rata-rata panjang identifier Menghitung persentase indentasi tepat (Tidak diimplementasikan) Kebutuhan fungsional yang harus dipenuhi oleh autograder Phobos dijabarkan pada Tabel III-5. Sebagaimana telah dibahas pada analisis proses penilaian otomatis, skema penilaian dirancang sebagai salah satu masukan pada Phobos. Hal ini menyebabkan Phobos harus memiliki kemampuan untuk membuat dan mengubah skema penilaian. Jenis-jenis penilaian otomatis sebagaimana dijabarkan pada Tabel III-4 juga menjadi kebutuhan fungsional Phobos.

15 III-15 Tabel III-5. Spesifikasi Fungsional Phobos Nomor SRS Fungsi Keterangan PHB-SRS-F-01 Membuat definisi skema penilaian untuk tugas Autograder dapat membuat definisi skema penilaian yang akan digunakan untuk proses grading. PHB-SRS-F-02 Memproses source code program dan menangkap kesalahan sintaksis Autograder dapat mengubah source code yang akan dinilai ke dalam pohon sintaks abstrak serta menangani dan mencatat kesalahan sintaks yang PHB-SRS-F-03 PHB-SRS-F-04 PHB-SRS-F-05 PHB-SRS-F-06 PHB-SRS-F-07 PHB-SRS-F-08 PHB-SRS-F-09 PHB-SRS-F-10 PHB-SRS-F-11 PHB-SRS-F-12 Menghitung persentase data uji benar dan menangkap runtime error Menghitung jumlah baris source code yang diberikan Menghitung jumlah titik percabangan dalam kode Memeriksa keberadaan identitas file kode Menghitung persentase komentar terhadap kode Menghitung rata-rata panjang identifier Menghitung persentase indentasi tepat Mengukur lamanya eksekusi program Menghasilkan laporan nilai serahan tugas Menghapus data hasil proses penilaian terjadi. Autograder dapat mengeksekusi program menggunakan data uji, memeriksa kebenaran hasil eksekusi program, menghitung proporsi kasus benar serta menangkap kesalahan saat eksekusi Autograder dapat menghitung jumlah baris source code (di luar komentar). Autograder dapat menghitung jumlah titik percabangan logika pada source code Autograder dapat memverifikasi keberadaan identitas pada source code Autograder dapat menghitung jumlah baris komentar dan rata-rata jumlah huruf komentar yang terkandung dalam source code Autograder dapat menghitung rata-rata panjang identifier pada source code Autograder dapat menghitung proporsi indentasi tepat pada source code Autograder dapat mengukur waktu yang dibutuhkan untuk eksekusi program Autograder dapat menghasilkan laporan nilai (nilai & penjelasan) dari proses penilaian yang telah dilakukan terhadap serahan tugas. Laporan yang dihasilkan dapat berupa laporan individu maupun kolektif. Autograder dapat menghapus hasil penilaian yang sudah tidak digunakan. Kebutuhan fungsional yang telah ditetapkan dapat dipetakan kepada use case yang telah dibuat dalam model use case. Pemetaan antara kebutuhan fungsional dengan use case dapat dilihat pada Tabel III-6. Tabel III-6. Pemetaan SRS terhadap Use-Case untuk Phobos Nomor Use Case Nomor SRS PHB-UC-01 PHB-SRS-F-01 PHB-UC-02 PHB-SRS-F-02 PHB-UC-03 PHB-SRS-F-11 PHB-UC-04 PHB-SRS-F-12 PHB-UC-05 PHB-SRS-F-03 PHB-UC-06 PHB-SRS-F-04 PHB-UC-07 PHB-SRS-F-05 PHB-UC-08 PHB-SRS-F-06 PHB-UC-09 PHB-SRS-F-07 PHB-UC-10 PHB-SRS-F-08 PHB-UC-11 PHB-SRS-F-09 PHB-UC-12 PHB-SRS-F-02

16 III Spesifikasi Non Fungsional Phobos Proses penilaian yang dilakukan oleh Phobos harus efisien, karena Phobos akan digunakan dalam kelas dengan ratusan siswa. Selain itu, meskipun dalam Tugas Akhir ini masih bersifat batch processing, Phobos juga direncanakan agar suatu saat dapat dikembangkan menjadi sistem interaktif. Kebutuhan non-fungsional untuk autograder Phobos dijelaskan secara lebih mendetil pada Tabel III-7. Tabel III-7. Kebutuhan Non-Fungsional Phobos Nomor SRS Spesifikasi Keterangan PHB-SRS-NF-01 Aksesibilitas Layanan autograder dan hasil penilaiannya dapat diakses dari komputer manapun yang terhubung pada internet. PHB-SRS-NF-02 Efisiensi Autograder harus mampu menilai source code yang mencapai ratusan dalam waktu yang dapat ditoleransi, yaitu tidak lebih dari setengah hari kerja untuk kelas berisi seratus mahasiswa. PHB-SRS-NF-03 Ekstensibilitas Autograder dapat dikembangkan lebih lanjut agar dapat menambahkan jenis penilaian atau menangani bahasa pemrograman lain tanpa mengembangkan ulang seluruh autograder Deskripsi Arsitektural Phobos Pada Subbab ini akan dibahas mengenai rancangan arsitektural Phobos, dekomposisi komponen, pembagian tanggung jawab dan proses yang dilakukan oleh tiap komponen. Deskripsi arsitektural sistem Phobos terkait dengan proses penilaian dapat dilihat pada Gambar III-7. Phobos secara umum terdiri dari beberapa tingkatan (tier) : presentation tier, logic tier dan data tier. Antarmuka sistem terhadap pengguna pada presentation tier ditangani oleh web browser pada komputer klien. Pada logic tier, terdapat dua komponen utama, yaitu aplikasi front-end dan engine penilai otomatis. Pada data tier, terdapat persistent storage, di mana disimpan seluruh skema penilaian dan laporan nilai yang dihasilkan. Aplikasi front-end bertindak sebagai antarmuka aplikasi Phobos dengan protokol HTTP menggunakan 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 Phobos. PHP dipilih sebagai bahasa pemrograman untuk pengembangan aplikasi web karena PHP telah tersedia pada kebanyakan web server dan LMS milestone dikembangkan dengan menggunakan bahasa PHP. Tanggung jawab utama aplikasi front-end adalah menerima perintah dan masukan dari instruktur dan menampilkan respon yang sesuai dengan perintah yang diterima. Perintah dari instruktur yang ditangani yaitu membuat skema penilaian baru, memulai proses penilaian, meminta laporan nilai atau menghapus data penilaian tertentu.

17 III-17 Data Tier Logic Tier Persistent Storage Engine Penilai Otomatis Server dengan Instalasi Phobos Aplikasi Front-End Manager Oracle Whitebox Markers HTTP Komputer Client Presentation Tier Web Browser Instruktur Gambar III-7 Deskripsi Arsitektural Phobos Autograder engine bertindak sebagai pengendali pada proses penilaian. Sebagaimana telah dibahas pada Subbab 3.3.2, salah satu kebutuhan pada fungsional Phobos adalah kemampuan memproses source code program (PHB-SRS-F-02), sehingga dibutuhkan proses analisis leksikal dan analisis sintaks. Phobos akan menggunakan generator parser Antlr untuk membantu melakukan kedua proses tersebut. Selain itu, proses penilaian akan melibatkan analisis pohon sintaks abstrak, sebagaimana yang dilakukan pada pemeriksa pola Checkstyle. Kedua perangkat lunak tersebut dikembangkan dalam bahasa Java, sehingga komponen autograder engine akan juga dikembangkan menggunakan bahasa Java. Komponen autograder engine sendiri terdiri dari beberapa subsistem berdasarkan tanggung jawabnya dalam proses penilaian. Subsistem yang terdapat dalam komponen autograder engine yaitu subsistem Manager, Oracle dan WhiteboxMarkers. Ikhtisar pembagian tanggung jawab, masukan beserta keluaran dari masing-masing subsistem tercantum pada Tabel III-8.

18 III-18 Tabel III-8 Tanggung Jawab Setiap Subsistem pada Autograder Engine Phobos, beserta masukan yang dibutuhkan dan keluaran yang dihasilkan Nama Tanggung jawab subsistem Input yang Hasil proses subsistem Manager Oracle Whitebox Markers Membuat dan menyimpan definisi skema penilaian [PHB-SRS-F-01] Membangkitkan prosesor bahasa pemrograman yang digunakan [PHB-SRS-F-02] Menjalankan proses penilaian. [PHB-SRS-F-02] Membangkitkan laporan penilaian [PHB-SRS-F-03] Menghapus hasil penilaian apabila tidak lagi dibutuhkan [PHB-SRS-F-04] Penilaian eksekusi program (Memroses source code dan mengeksekusi program, menguji kebenaran keluaran program, menghitung waktu eksekusi dan menangkap semua kesalahan yang terjadi dalam interpreter/eksekusi) [PHB-SRS-F-05] Penilaian whitebox (Memroses source code dan melakukan penilaian terhadap pohon sintaks abstrak yang dihasilkan) [PHB-SRS-F-06, PHB-SRS-F-07, PHB-SRS-F-08, PHB-SRS-F-09, PHB-SRS-F-10, PHB-SRS-F-11, PHB-SRS-F-12] dibutuhkan - Nama dan deskripsi tugas - Bahasa pemrograman pada source code target deteksi - Jenis-jenis penilaian & bobotnya. - Data uji yang akan digunakan File definisi skema penilaian - Interpreter - File atau direktori source code yang hendak dinilai Data hasil penilaian Data nilai yang hendak dihapus - Prosesor bahasa pemrograman - Source code - Data uji (dari file skema penilaian) - Prosesor bahasa pemrograman - Source code - Jenis-jenis penilaian & bobotnya. (dari def. skema penilaian) eksekusi File definisi skema penilaian Prosesor bahasa pemrograman (interpreter) Data hasil penilaian Laporan nilai Status keberhasilan penghapusan data Laporan hasil eksekusi Laporan hasil analisis source code Karena komponen front-end dan autograder engine dikembangkan menggunakan bahasa pengembangan yang berbeda, komunikasi antara satu komponen dengan komponen yang lain akan dilakukan menggunakan XML. XML juga digunakan sebagai format untuk skema penilaian dan laporan penilaian dalam penyimpanan persisten. Format XML dipilih karena independen terhadap bahasa pemrograman dan fleksibel. XML juga dipilih karena Phobos diharapkan akan dapat dikembangkan pada masa depan ke dalam konteks penggunaan lainnya, sesuai dengan kebutuhan non fungsional ekstensibilitas pada Subbab Detil perancangan penyimpanan persisten pada Phobos akan diberikan pada Subbab 4.3.

19 III Manager Subsistem Manager bertanggung jawab untuk mengendalikan jalannya proses penilaian oleh Phobos secara keseluruhan. Tanggung jawab Manager mencakup membuat dan menyimpan skema penilaian, membangkitkan prosesor bahasa pemrograman yang digunakan, menjalankan proses penilaian, membangkitkan laporan nilai, dan menghapus hasil penilaian yang tidak digunakan lagi. Tanggung jawab pertama subsistem Manager adalah manajemen definisi skema penilaian. Definisi skema penilaian, sebagaimana telah dibahas pada Subbab 3.2.2, merupakan skenario proses penilaian, yang berisi jenis-jenis penilaian yang akan dijalankan terhadap program, termasuk data uji bila terdapat proses penilaian eksekusi. Subsistem Manager akan mengolah masukan berupa nama tugas dan deskripsi tugas, bahasa pemrograman yang akan digunakan, jenis-jenis penilaian beserta data uji dari instruktur, dan kemudian menyimpannya dalam bentuk XML dalam penyimpanan persisten. Subsistem Manager juga bertanggung jawab untuk membaca definisi skema penilaian XML dari penyimpanan persisten untuk kemudian diubah atau digunakan dalam proses penilaian. Tanggung jawab kedua subsistem Manager adalah pembangkitan prosesor bahasa pemrograman yang digunakan. Definisi bahasa pemrograman adalah detil cara interpretasi untuk bahasa pemrograman tertentu yang dibutuhkan agar source code dapat diproses. Karena Phobos dirancang agar dapat menangani bahasa pemrograman yang beragam, maka pembangkitan prosesor bahasa pemrograman dilakukan secara dinamis, dengan kelas khusus untuk masing-masing bahasa pemrograman. Menggunakan prosesor bahasa pemrograman yang dibangkitkan secara dinamis ini, Oracle dan WhiteboxMarkers akan dapat melakukan penilaian terhadap source code. Tanggung jawab ketiga subsistem Manager adalah untuk mengendalikan jalannya proses penilaian oleh subsistem lain. Manager akan mendelegasikan proses penilaian blackbox kepada subsistem Oracle, memberikan masukan berupa data uji, pemroses bahasa dan source code kepada subsistem tersebut. Manager akan mendelegasikan proses penilaian whitebox kepada subsistem WhiteboxMarkers, memberikan masukan berupa prosesor bahasa pemrograman, source code dan daftar jenis-jenis penilaian kepada subsistem tersebut. Manager akan menerima laporan dari masing-masing subsistem dan menyimpannya ke dalam penyimpanan persisten menggunakan format XML.

20 III-20 Tanggung jawab lain dari subsistem Manager adalah manajemen data hasil penilaian. Subsistem Manager bertanggung jawab menghitung nilai dari hasil pengukuran Oracle dan WhiteboxMarkers yang telah tersimpan dalam penyimpanan persisten. Manager kemudian menyusun laporan nilai dari hasil perhitungan tersebut. Laporan yang disusun dapat berupa laporan nilai individu maupun laporan nilai kolektif seluruh source code yang dikumpulkan untuk satu tugas. Laporan yang telah disusun akan kemudian dikirimkan dalam bentuk XML kepada komponen aplikasi front-end. Subsistem Manager juga bertanggung jawab menangani penghapusan data hasil penilaian yang tidak lagi digunakan oleh instruktur Oracle Subsistem Oracle bertindak sebagai penilai blackbox, sebagaimana telah dijelaskan pada Subbab Subsistem ini menerima masukan berupa source code, source processor dan data uji dari subsistem Manager. Subsistem Oracle menghasilkan laporan hasil eksekusi dan memberikannya kembali kepada Manager. Subsistem Oracle menerima source code dan mengeksekusinya menggunakan prosesor bahasa pemrograman. Eksekusi source code akan menggunakan masukan dari data uji dari skema penilaian yang telah diberikan oleh Manager. Oracle kemudian mencocokkan keluaran program yang sedang diuji dengan data keluaran seharusnya dari data uji; serta mencatat waktu eksekusi program. Laporan persentase data uji yang berhasil ditangani dengan tepat dan waktu eksekusi inilah yang kemudian diberikan Oracle pada Manager. Oracle juga bertanggung jawab menangkap semua kesalahan yang terjadi, baik dalam tahap pemrosesan maupun eksekusi program. Kesalahan sintaktik dibangkitkan apabila Oracle menerima pesan kesalahan dari prosesor bahasa pemrograman. Kesalahan eksekusi dibangkitkan apabila waktu eksekusi program terlalu lama (untuk menangani keadaan program dalam blocking state atau infinite loop) atau menghasilkan exception yang tidak ditangani. Oracle juga bertugas untuk melepaskan resource yang mungkin tersisa dari eksekusi program. Kesalahan-kesalahan yang terjadi akan kemudian dilaporkan kepada Manager. Jika di masa depan Phobos hendak dikembangkan untuk memiliki kemampuan penilaian eksekusi menggunakan data uji yang berasal dari sumber lainnya, hanya subsistem Oracle yang perlu diubah. Oracle juga dirancang sebagai subsistem terpisah untuk mengisolasi kesalahan-kesalahan yang mungkin terjadi pada saat eksekusi program yang sedang diuji.

21 III WhiteboxMarkers Subsistem WhiteboxMarkers melakukan penilaian besaran kualitatif source code, sebagaimana telah dibahas dalam Subbab Subsistem ini menerima masukan berupa source code, source processor dan daftar jenis-jenis penilaian analitik dari subsistem Manager. Subsistem WhiteboxMarkers kemudian menghasilkan laporan nilai serahan tugas untuk kembali diserahkan kepada subsistem Manager. Subsistem WhiteboxMarkers membaca source code dan mengubah source code tersebut menggunakan source processor ke dalam representasi antara pohon sintaks abstrak (PSA). PSA memungkinkan pengukuran besaran-besaran analitik yang berhubungan dengan kompleksitas dan tipografi source code, seperti kompleksitas siklomatik atau rata-rata panjang baris komentar. Laporan proses penilaian inilah yang kemudian akan diberikan WhiteboxMarkers kepada Manager. Jika di masa depan Phobos hendak dikembangkan untuk menangani jenis penilaian whitebox lainnya, hanya subsistem WhiteboxMarkers saja yang perlu dimodifikasi. Jenis penilaian baru dapat ditambahkan dengan mengimplementasikan kelas penilai baru Analisis Prosesor Bahasa Pemrograman dalam Phobos Penilaian eksekusi program merupakan bagian yang penting dari proses penilaian dalam Phobos. Hal inilah yang menyebabkan kemampuan untuk memproses source code program (PHB-SRS-F-02) dan menguji kebenaran program (PHB-SRS-F-03) melalui uji eksekusi menjadi kebutuhan fungsional yang sentral. Kedua kebutuhan fungsional ini mengharuskan Phobos memiliki kemampuan untuk memproses bahasa pemrograman, dengan menjadikan prosesor bahasa pemrograman sebagai salah satu bagian dalam sistem ini. Sebagaimana disebutkan dalam Subbab 2.3.2, teknik implementasi bahasa pemrograman yang umum digunakan adalah kompilasi dan interpretasi. Kompilasi merupakan teknik implementasi bahasa pemrograman yang umum digunakan karena eksekusi kode biner hasil kompilasi jauh lebih cepat dibandingkan dengan eksekusi dengan interpretasi. Di dalam kompilasi, program dieksekusi sebagai proses mandiri dengan resource sistem operasi yang terpisah, sementara dalam interpretasi, eksekusi dijalankan sepenuhnya dalam proses interpreter. Karena itu, interpreter dapat menangani kesalahan-kesalahan yang terjadi dalam proses eksekusi kode dan menghasilkan laporan dari kesalahan saat eksekusi tersebut dengan lebih baik. Karakteristik-karakteristik ini menyebabkan interpretasi memiliki potensi nilai

22 III-22 pedagogik yang lebih baik, khususnya untuk memberikan umpan balik mengenai kesalahan dalam eksekusi program. Sebagai bagian dalam suatu sistem penilai, interpretasi juga memiliki keamanan yang lebih tinggi karena interpreter dapat mengawasi eksekusi program secara penuh. Eksekusi kode biner hasil kompilasi tidak dapat diawasi sepenuhnya, sehingga jika autograder menggunakan kompilator, perlu dibuat pengamanan terpisah yang kuat. Oleh sebab itulah, pemrosesan source code dalam Phobos menggunakan teknik interpretasi. Dalam proses penilaian whitebox, Phobos akan membangkitkan pohon sintaks abstrak dari source code. Interpreter, sebagaimana telah dibahas dalam Subbab 2.3.3, menjalankan eksekusi berdasarkan pohon sintaks abstrak yang dibangun dari hasil parsing terhadap source code. Dengan mengembangkan interpreter khusus untuk melakukan eksekusi berdasarkan pohon sintaks abstrak, source code hanya perlu di-parse satu kali saja. Interpreter dapat menyimpan pohon sintaks abstrak hasil parsing dan kemudian langsung melakukan eksekusi program berdasarkan pohon tersebut. yang mendasari penggunaan interpreter yang dikembangkan sendiri untuk kepentingan penilaian otomatis Phobos, tidak menggunakan komponen yang sudah tersedia. Karena interpreter Phobos digunakan untuk kepentingan penilaian, interpreter dirancang dengan memperhatikan unsur-unsur pengajaran pemrograman, seperti misalnya dengan merancang interpreter untuk mendeteksi konstruksi loop yang salah, ekspresi boolean yang tidak berguna, atau infinite loop dalam source code berbahasa Pascal. Interpreter spesifik ini dapat dirancang untuk melakukan inspeksi terhadap kode sebagaimana yang dilakukan oleh penilai manusia.