IV-1
BAB IV
PERANCANGAN
Pada Tugas Akhir ini, akan dijelaskan mengenai perancangan autograder Phobos.
Berdasarkan deksripsi arsitektural pada Subbab 3.3.4, Phobos secara umum terdiri dari
beberapa tingkatan (tier) : presentation tier, logic tier dan data tier. Pada logic tier Phobos
memiliki dua komponen utama, yaitu engine penilai otomatis dan aplikasi front-end. Pada Subbab 4.1 akan dijelaskan mengenai perancangan yang dilakukan pada komponen engine penilai otomatis. Subbab 4.2 akan menjelaskan mengenai aplikasi front-end dan tampilan pada presentation tier. Penyimpanan data persisten (data tier) akan dibahas pada Subbab 4.3.
Modul interpreter pada Phobos akan dibahas secara khusus pada Subbab 4.4.
4.1 Autograder Engine
Pada Subbab ini akan diberikan penjelasan mengenai perancangan komponen autograder
engine pada Phobos. Autograder engine adalah komponen yang bertanggung jawab melakukan penilaian otomatis pada serahan tugas yang diberikan berdasarkan trigger dari aplikasi front-end. Sebagai komponen pada logic tier, komponen ini mengimplementasikan dari seluruh use case sistem : membuat skema penilaian, menilai tugas source code, melihat laporan nilai, dan menghapus hasil penilaian. Rancangan kelas-kelas dalam autograder
engine dapat dilihat pada Gambar 4.1.
Sebagaimana telah dibahas pada Subbab 3.3.5, Phobos akan menggunakan interpreter
sebagai prosesor bahasa pemrograman. Penggunaan interpreter mengakibatkan beberapa perubahan dalam proses perancangan kelas. Dengan adanya interpreter untuk melakukan seluruh pemrosesan source code, maka source code tidak lagi menjadi masukan kepada subsistem Oracle maupun WhiteboxMarkers, melainkan objek interpreter yang telah mengandung pohon sintaks abstrak hasil parsing terhadap source code saja. Dengan demikian, seluruh kelas untuk melakukan penilaian dapat dirancang secara seragam sebagai realisasi sebuah interface. Interface yang merepresentasikan semua jenis penilaian ini dinamai Marker.
Penggunaan interpreter yang dirancang tersendiri juga mengakibatkan penataan subsistem menjadi berubah. Berdasarkan hasil analisis pada Subbab 3.3.4, kelas-kelas dalam autograder
engine akan dibagi ke dalam subsistem-subsistem yaitu Manager, Oracle dan WhiteboxMarkers. Karena semua penilai diseragamkan sebagai realisasi interface Marker,
maka Oracle dan WhiteboxMarkers tidak lagi menjadi subsistem mandiri melainkan menjadi bagian dari kelompok kelas penilaian yang dinamai Marker. Interpreter diletakkan dalam subsistem khusus Interpreter. Kelas-kelas perancangan untuk Manager akan dijelaskan pada Subbab 4.1.1. Kelas-kelas perancangan untuk Oracle dan WhiteboxMarkers akan dijelaskan pada 4.1.2, dan 4.1.3. Perancangan interaksi antara kelas-kelas untuk melakukan penilaian akan dijelaskan pada Subbab 4.1.4. Kelas perancangan untuk Interpreter akan dibahas terpisah secara lebih mendetil pada Subbab 4.4.
Gambar IV-1 Diagram Kelas Perancangan Autograder Engine Phobos
Manager
Marker
Oracle
WhiteboxMarkers
Daftar kelas dalam autograder engine beserta deskripsi dan lapisannya dijabarkan pada Tabel IV-1.
Tabel IV-1. Daftar Kelas Perancangan untuk Autograder Engine
No Nama Kelas Deskripsi
:: Lapisan Manager
1. SchemaManager Kelas contoller ini bertanggung jawab untuk menyimpan,
mengambil dan mendaftar definisi skema penilaian dari penyimpanan persisten.
2. MarkingSchemaDef Kelas model ini merepresentasikan skema penilaian yang
secara tidak langsung menentukan jalannya proses penilaian.
3. MarkType Kelas model ini merepresentasikan jenis-jenis penilaian yang
terdapat dalam definisi skema penilaian yang dapat dilakukan oleh Phobos.
4. Marker Interface ini merupakan kelas abstrak yang merupakan
parent dari seluruh kelas penilai.
5. MarkingManager Kelas controller ini bertanggung jawab mengendalikan
proses penilaian secara keseluruhan
6. ReportManager Kelas controller ini bertanggung jawab untuk
membangkitkan laporan nilai individu dan kolektif, serta penghapusan laporan penilaian yang tidak digunakan lagi.
7. IndividualReport Kelas model untuk laporan nilai serahan tugas tunggal.
8. CollectiveReport Kelas model untuk laporan nilai kolektif untuk satu batch
serahan tugas yang dinilai (sekumpulan source code untuk penugasan yang sama).
9. MarkingResult Kelas model untuk hasil penilaian dari satu penilai (Marker)
untuk satu serahan tugas.
:: Lapisan Marker / Oracle
4.1 Oracle Kelas pengontrol yang bertanggung jawab untuk
mengendalikan jalannya proses penilaian eksekusi dan menyusun laporan hasil pengujian.
10. OracleException Kelas ini dibangkitkan pada saat timbul kesalahan-kesalahan
pada proses pengujian dinamis.
3.1 BlackboxMarking Kelas model untuk data uji ini berisi semua butir uji yang terkandung dalam definisi skema penilaian.
11. TestItem Kelas model yang merepresentasikan butir uji pada proses
pengujian dinamis.
:: Lapisan Marker / WhiteboxMarkers
4.2 GraderSLOC Kelas implementasi Marker yang merealisasikan penilaian
Source Lines of Code
4.3 GraderCyclomatic Kelas implementasi Marker yang merealisasikan penilaian Kompleksitas Siklomatik
4.4 GraderIdentity Kelas implementasi Marker yang merealisasikan penilaian kelengkapan identitas submisi tugas
4.5 GraderIndentation Kelas implementasi Marker yang merealisasikan penilaian ketepatan indentasi source code
4.6 GraderCommentLines Kelas implementasi Marker yang merealisasikan penilaian jumlah baris komentar
4.7 GraderCommentLength Kelas implementasi Marker yang merealisasikan penilaian rata-rata panjang komentar
4.8 GraderIdenfitierLength Kelas controller turunan dari WhiteboxGrader yang merealisasikan penilaian rata-rata panjang nama identifier
No Nama Kelas Deskripsi :: Lapisan Interpreter
12. Interpreter Kelas abstrak ini merupakan kelas parent untuk tiap
interpreter prosesor bahasa pemrograman,
diimplementasikan oleh satu kelas turunan untuk setiap bahasa pemrograman yang ditangani.
12.1 PascalInterpreter Kelas implementasi Interpreter ini bertindak sebagai
interpreter untuk source code dalam bahasa Pascal
12.2 LispInterpreter Kelas implementasi Interpreter ini bertindak sebagai
interpreter untuk source code dalam bahasa Lisp
13. InterpreterException Kelas ini dibangkitkan pada saat timbul kesalahan-kesalahan
pada proses interpretasi kode.
4.1.1 Manager
Subsistem Manager bertanggung jawab untuk mengendalikan jalannya proses oleh Phobos
secara keseluruhan, dalam pembuatan skema penilaian, proses penilaian maupun pembangkitan laporan nilai. Kelas-kelas yang berada pada subsistem Manager adalah kelas
MarkingManager, SchemaManager, ReportManager, SourceManager, MarkType,
MarkingSchemaDef, MarkingResult, IndividualReport, dan CollectiveReport.
Kelas SchemaManager bertanggungjawab untuk mengatur seluruh proses yang berkaitan dengan skema penilaian – pembuatan skema penilaian baru, pengubahan dan penghapusan skema penilaian yang sudah ada, penyimpanan dan pengambilan dari penyimpanan data persisten. Skema penilaian di dalam sistem Phobos direpresentasikan dalam kelas
MarkingSchemaDef. Kelas MarkingSchemaDef memiliki atribut daftar jenis penilaian
yang harus dilakukan. Tiap jenis penilaian didefinisikan dalam kelas MarkType. Kelas MarkType menyimpan definisi kelas untuk jenis penilaian tertentu, bobot penilaian, aturan penilaian dan keterangan.
Kelas SourceManager bertugas menghasilkan daftar file berisi source code yang akan dinilai, serta menghasilkan daftar semua direktori tugas yang tersedia.
Kelas MarkingManager bertanggungjawab untuk mengendalikan jalannya penilaian. MarkingManager menerima skema penilaian dan daftar file tugas source code yang hendak dinilai, dan mengeksekusi proses penilaian sesuai dengan masukan yang diberikan. Interface Marker merupakan definisi penilai yang menjadi parent untuk seluruh kelas penilai. Kelas realisasi Marker menerima interpreter yang sudah selesai membangun pohon sintaks abstrak dari source code dan menghasilkan nilai sesuai dengan jenis penilaian masing-masing.
Diagram kelas yang diperbesar untuk subsistem Manager bagian manajemen skema dan penilaian dapat dilihat pada Gambar IV-2.
MarkingManager -markers: Marker[1..*] +loadMarkers(schema: MarkingSchemaDef) +executeMarking() MarkingSchemaDef -idSchema: int -assignmentName: String -assignmentDesc: String -sourceLang: String -markPoints: MarkType[1..*] +MarkingSchema(id: int) +MarkingSchema(name: String, lang: String) +getId(): int +getName(): String +getDescription(): String +getSourceLanguage(): String +addMarkType(point: MarkType) +removeMarkPoint(point: MarkType) +setName(name: String) +setDescription(desc: String) +toXmlString(): String MarkType -pointName: String -pointDesc: String -weight: float +MarkPoint(name: String)
+MarkPoint(name: String, desc: String, weight: float) +getName(): String +getDescription(): String +getWeight(): float +setDescription(desc: String) +setWeight(weight: float) +toXmlString(): String SchemaManager +generateMetaschema()
+loadSchemaDef(idSchema: int): MarkingSchemaDef +storeSchemaDef(schema: MarkingSchemaDef) +deleteSchema(schema: MarkingSchemaDef) +listAllSchema(): MarkingSchemaDef[0..*]
SourceManager
+listAllDir(): String [0..*] +listAllSource(dirPath: String): String[0..*]
Marker Interpreter MarkingResult -markPoint: MarkingPoint -numericMark: float -explanation: String +MarkingResult(point: MarkingPoint) +getMarkingPoint(): MarkingPoint +getNumericMark(): float +getExplanation(): String +setNumericMark(mark: float) +setExplanation(explanation: String) +toXmlString(): String
Gambar IV-2 Diagram Kelas Perancangan Subsistem Manager bagian manajemen skema dan penilaian
Kelas MarkingResult merupakan kelas yang merepresentasikan hasil penilaian dari satu jenis penilaian. MarkingResult memiliki atribut berupa nilai, hasil pengukuran besaran yang sesungguhnya, beserta penjelasan dari proses penilaian yang dilakukan.
Kelas ReportManager bertanggungjawab untuk menghasilkan laporan penilaian untuk satu source code dari semua hasil penilaian yang dijalankan terhadap source code tersebut. ReportManager juga bertanggung jawab menyimpan laporan nilai individu serta menyusun laporan nilai kolektif dari sekumpulan source code untuk tugas yang sama. Laporan nilai individu direpresentasikan dalam kelas IndividualReport, dan laporan nilai kolektif ini direpresentasikan dalam kelas CollectiveReport. Diagram kelas yang diperbesar untuk sbsistem manager bagian penanganan laporan dapat dilihat pada Gambar IV-3.
MarkingResult -markPoint: MarkingPoint -numericMark: float -explanation: String +MarkingResult(point: MarkingPoint) +getMarkingPoint(): MarkingPoint +getNumericMark(): float +getExplanation(): String +setNumericMark(mark: float) +setExplanation(explanation: String) +toXmlString(): String ReportManager
+generateReport(schema: MarkingSchemaDef, source: String) +generateCollectiveReport(schema: MarkingSchemaDef) +deleteReport(schema: MarkingSchemaDef) IndividualReport -markingSchema: MarkingSchemaDef -sourceFile: String -results: MarkingResult[1..*] -finalMark: float
+MarkingReport(schema: MarkingSchemaDef, source: String) +getResults(): MarkingResult[1..*]
+setResults(MarkingResult[1..*]) +getFinalMark(): float +toXmlString(): String
+toXmlString(complete: boolean): String
CollectiveReport
-reports: IndividualReport[1..*]
+CollectiveReport(schema: MarkingSchemaDef, sourceDir: String) +getReports(): MarkingReport[1..*]
+setReports(MarkingReport[1..*]) +toXmlString(): String
+toXmlString(complete: boolean): String
Gambar IV-3 Diagram kelas Subsistem Manager bagian manajemen laporan nilai
4.1.2 Oracle
Subsistem Oracle bertindak sebagai penilai blackbox, sebagaimana telah dijelaskan pada
Subbab 2.2.1.3. Kelas Oracle merupakan penilai yang merupakan salah satu implementasi
Marker yang bertugas menghasilkan nilai eksekusi program menggunakan interpreter siap
eksekusi. Kelas OracleException merupakan kelas exception yang merepresentasikan
kesalahan dalam proses eksekusi program. Kelas BlackboxMark merupakan turunan dari
kelas MarkType. Kelas BlackboxMark bertanggungjawab membangkitkan data uji untuk
proses penilaian eksekusi. BlackboxMark memiliki atribut khusus berupa koleksi data uji.
Data uji dalam proses eksekusi direpresentasikan sebagai kelas TestItem. TestItem
memiliki atribut berupa input untuk program dan output yang diharapkan untuk input yang terkait. Diagram kelas untuk subsistem Oracle dapat dilihat pada Gambar IV-4.
Oracle TestItem -itemId: int -testInput: String -correctOutput: String -mandatory: boolean +TestItem(id: int)
+TestItem(input: String, output: String) +getId(): int +getTestInput(): String +getCorrectOutput(): String +isMandatory(): boolean +setTestInput(input: String) +setCorrectOutput(output: String) +setMandatory(mandatory: boolean) +toXmlString(): String +getMetaschema(): String BlackboxMark -testPool: TestItem[1..*] +getTestPool(): TestItem[1..*] +generateTestSet(): TestItem[1..*] +addTestItem(item: TestItem) +removeTestItem(item: TestItem) OracleException +getMessage(): String Marker
Gambar IV-4 Diagram Kelas subsistem Oracle
4.1.3 WhiteboxMarkers
Subsistem WhiteboxMarkers melakukan penilaian besaran kualitatif source code, sebagaimana telah dibahas dalam Subbab 2.2.1.2. Di dalam Subsistem WhiteboxMarker terdapat kelas-kelas realisasi penilai Marker. Setiap kelas merepresentasikan suatu jenis penilaian tertentu. Diagram kelas untuk subsistem WhiteboxMarkers dapat dilihat pada Gambar IV-5.
GraderSloc bertanggungjawab untuk menghitung Source Lines of Code (SLoC) dari
source code dan melakukan penilaian berdasarkan hasil pengukuran tersebut.
GraderCommentLines melakukan menghitung jumlah baris komentar dalam source
code dan melakukan penilaian berdasarkan hasil pengukuran tersebut.
GraderIndentation bertanggungjawab untuk mengukur gradien indentasi dalam source
code terhadap pohon sintaks abstrak yang dibuat dan melakukan penilaian berdasarkan hasil
pengukuran tersebut. GraderCyclomatic mengukur kompleksitas siklomatik dari source
code dan menghasilkan nilai berdasarkan pengukuran yang telah dilakukan.
GraderIdentity bertanggungjawab untuk memeriksa keberadaan identitas pada suatu
source code dan melakukan penilaian berdasarkan pemeriksaan tersebut.
GraderCommentLength bertanggungjawab mengukur rata-rata panjang baris komentar dan melakukan penilaian berdasarkan pengukuran tersebut. GraderIdentifierLength
bertanggungjawab menghitung rata-rata panjang identifier dan melakukan penilaian berdasarkan penilaian tersebut.
Marker GraderSLoC GraderCyclomatic GraderIdentity GraderIndentation GraderCommentLines GraderIdentifierLength GraderCommentLength
Gambar IV-5 Diagram Kelas subsistem WhiteboxMarkers
4.1.4 Perancangan Interaksi Kelas untuk Proses Penilaian
Proses penilaian dalam Phobos akan dilakukan dengan menggunakan kelas-kelas yang telah
dirancang. Detil proses penilaian akan dijelaskan menggunakan diagram kolaborasi pada
Gambar IV-6. Proses penilaian dimulai dengan objek MarkingManager menginvokasi
executeMarking pada dirinya sendiri. MarkingManager akan kemudian mengirim pesan
kepada SchemaManager untuk memulai proses pembangkitan definisi skema penilaian dari
penyimpanan persisten.
Kemudian, MarkingManager akan memicu penciptaan objek Interpreter sesuai dengan
spesifikasi bahasa yang terkandung dalam definisi skema penilaian MarkingSchemaDef.
MarkingManager juga akan memicu penciptaan objek implementasi interface Marker
untuk setiap objek MarkType yang terdapat dalam definisi skema penilaian.
Setelah itu, MarkingManager akan mengirim pesan listAllSource untuk meminta daftar
seluruh source code yang hendak dinilai kepada SourceManager. Untuk setiap source code
dalam daftar yang diberikan, MarkingManager akan :
1. mengirim pesan kepada interpreter agar mengolah source code ke dalam bentuk pohon AST agar siap menjalani proses penilaian.
2. mengirim pesan kepada setiap kelas Marker agar melakukan penilaian menggunakan interpreter yang sudah berisi pohon sintaks abstrak dan menghasilkan objek
MarkingResult
3. membangkitkan IndividualReport yang berisi kumpulan MarkingResult
4. menyimpan IndividualReport ke dalam penyimpanan persisten
Gambar IV-6 Diagram Kolaborasi untuk Proses Penilaian dalam Phobos
Proses penilaian oleh objek Oracle atau objek-objek WhiteboxMarkers akan dijelaskan
sebagai berikut. Sebagaimana telah dibahas pada Subbab 4.1, interface Marker adalah kelas
parent pada seluruh kelas penilai. Interface Marker memiliki satu fungsi yaitu
executeMarking yang menerima objek Interpreter dan menghasilkan objek
MarkingResult. Objek Interpreter yang digunakan sebagai masukan penilaian mempunyai prasyarat khusus yaitu telah selesai melakukan proses parsing sehingga memiliki pohon sintaks abstrak representasi source code.
Oracle akan memerintahkan Interpreter untuk melakukan eksekusi program berdasarkan
proses penelusuran terhadap pohon sintaks abstrak. Implementasi Marker lainnya, yang akan
melakukan penilaian whitebox, akan menggunakan pohon sintaks abstrak dalam
Interpreter dan menggunakannya untuk melakukan penilaian analitik terhadap source
4.2 Aplikasi
Front-End
Aplikasi front-end, dirancang sebagai antarmuka Phobos melalui protokol HTTP.
Berdasarkan analisis pada Subbab 3.3.4, aplikasi front-end memiliki tanggung jawab untuk meneruskan instruksi dari pengguna, menerima masukan, dan memberikan tampilan dalam bentuk HTML dari respon aplikasi berupa XML. Aplikasi front-end tidak memiliki kelas khusus, karena aplikasi ini hanya berfungsi sebagai user interface dan dibuat sebagai web
script menggunakan bahasa pemrograman PHP.
Pada Subbab ini akan dibahas mengenai rancangan tampilan antarmuka halaman web pada Phobos. Tampilan setiap halaman web akan mengikuti rancangan antarmuka generik yang dapat dilihat pada Gambar IV-7. Detil perancangan antarmuka akan dibahas pada Subbab 4.2.1 hingga Subbab 4.2.5.
Gambar IV-7 Rancangan generik antarmuka web Phobos
4.2.1 Halaman Utama
Halaman utama berisi menu untuk memilih fungsionalitas Phobos. Tampilan halaman utama
dapat dilihat pada Gambar IV-8.
4.2.2 Halaman Formulir Skema Penilaian
Halaman formulir skema penilaian menampilkan sebuah formulir yang dapat digunakan untuk membuat skema penilaian baru, mengedit skema penilaian yang sudah ada dan menghapus skema penilaian yang tidak digunakan. Untuk membuat skema penilaian baru, pengguna dapat memasukkan jenis-jenis penilaian beserta bobotnya. Jika terdapat penilaian pengujian dinamis, maka formulir akan secara otomatis menambahkan field untuk data uji. Untuk mengedit skema penilaian, pengguna dapat memilih dari daftar skema penilaian yang sudah ada dan menekan tombol edit. Formulir skema penilaian akan menampilkan jenis, bobot dan data uji yang telah tersimpan pada skema penilaian. Untuk menyimpan skema baru atau skema yang telah diedit, pengguna dapat menekan tombol simpan pada bagian bawah formulir. Untuk menghapus skema penilaian, pengguna dapat memilih dari daftar skema penilaian yang sudah ada dan menekan tombol hapus. Antarmuka form ini dapat dilihat pada Gambar IV-9.
Gambar IV-9 Rancangan Halaman Formulir Skema Penilaian Phobos
4.2.3 Halaman Nilai Source Code
Halaman Nilai Source Code ditampilkan apabila pengguna hendak menjalankan proses
penilaian otomatis pada Phobos. Pengguna hanya perlu memilih skema penilaian dan
direktori tempat source code untuk menjalankan proses penilaian. Rancangan antarmuka untuk halaman ini dapat dilihat pada Gambar IV-10.
Gambar IV-10 Rancangan Halaman Nilai Source Code Phobos
4.2.4 Halaman Laporan Nilai
Laporan nilai dalam Phobos ada dua jenis, yaitu laporan nilai kolektif dan laporan nilai
individu. Pada laporan kolektif, hasil penilaian dari keseluruhan tugas yang telah diserahkan ditampilkan bersamaan, dengan hanya menampilkan nilai akhir dari masing-masing serahan
tugas. Rancangan tampilan antarmuka laporan nilai kolektif Phobos dapat dilihat pada
Gambar IV-11.
Gambar IV-11 Rancangan Halaman Laporan Nilai Kolektif Phobos
Dari laporan kolektif, tersedia link untuk membuka laporan nilai individu secara detil. Pada laporan individu, hasil nilai dan pengukuran untuk tiap jenis penilaian disertai penjelasan dari sistem, bila ada. Rancangan antarmuka laporan nilai individu dapat dilihat pada Gambar IV-12.
Gambar IV-12 Rancangan Halaman Laporan Nilai Phobos
4.2.5 Halaman Hapus Data Penilaian
Pada form menghapus hasil data penilaian terdapat daftar hasil penilaian sehingga pengguna dapat memilih hasil penilaian yang ingin dihapusnya. Rancangan antarmuka halaman dapat dilihat pada Gambar IV-13.
4.3 Penyimpanan Data Persisten
Penyimpanan data persisten pada Phobos sebagaimana telah dibahas pada Subbab 3.3.4,
akan dilakukan menggunakan file XML. Hal ini dimaksudkan agar Phobos di masa yang
akan datang dapat dikembangkan untuk digunakan dalam konteks deployment yang berbeda. Format XML juga dipilih karena dapat digunakan sebagai masukan untuk berbagai basis data, mudah dibaca dan divalidasi. Pada Subbab ini akan dibahas mengenai penyimpanan skema penilaian dan laporan nilai dalam format XML.
Untuk mendefinisikan XML definisi skema penilaian, digunakan sebuah Document Type
Definition (DTD) yang diberi nama metaschema.dtd. Di dalam metaschema terdapat
definisi struktur tiap elemen dari skema penilaian.Untuk mendefinisikan XML definisi hasil
penilaian, juga digunakan sebuah DTD yang diberi nama indivreport.dtd. Spesifikasi
metaschema dan DTD lainnya, beserta contoh file XML untuk definisi skema penilaian dan
laporan hasil penilaian dapat dilihat pada Lampiran G.
4.4 Interpreter
Generik
Phobos
Sebagaimana telah dibahas pada bab 3.3.6, pemroses bahasa pemrograman dalam Phobos
akan mencakup pengembangan interpreter. Untuk tiap bahasa pemrograman yang ditangani, akan diimplementasikan suatu modul interpreter terpisah. Agar proses penilaian dapat dibuat seragam, maka perlu dibuat rancangan untuk interpreter generik terlebih dahulu.
Pemrosesan source code Phobos secara generik dapat dilihat pada Gambar IV-14. Source
code akan dibaca dan kemudian disusun menjadi suatu pohon sintaks abstrak. Pohon sintaks
abstrak akan menjadi masukan untuk baik proses eksekusi maupun proses analisis pohon. Dengan demikian, proses parsing terhadap source code hanya perlu dilakukan satu kali saja,
karena objek pohon sintaks abstrak akan disimpan oleh Interpreter.
Source code harus dieksekusi pada proses penilaian blackbox. Untuk kepentingan penilaian blackbox ini, pohon sintaks abstrak akan mengalami proses penelusuran pohon untuk memicu
instansiasi objek-objek eksekusi. Objek eksekusi ini merupakan representasi program yang siap dijalankan. Setelah instansiasi objek-objek eksekusi selesai, barulah proses eksekusi program dapat dilakukan. Pada proses penilaian whitebox, penilaian dilakukan melalui analisis terhadap pohon sintaks abstrak secara langsung.
Gambar IV-14 Flowchart Pemrosesan Source Code pada Phobos
Berdasarkan proses yang dilakukan terhadap source code tersebut, maka dapat dirancang
sebuah kelas abstrak Interpreter. Kelas ini akan memiliki beberapa metode, yaitu
loadSource untuk melakukan parsing terhadap source code, execute untuk menjalankan
eksekusi terhadap program, getAST untuk mendapatkan pohon sintaks abstrak dari
interpreter dan unloadSource untuk menghapus hasil parsing dari interpreter. Diagram
kelas perancangan untuk interpreter dapat dilihat pada Gambar IV-15.
Pohon sintaks abstrak yang dibangkitkan bersifat generik untuk semua bahasa pemrograman.
Dalam sistem Phobos, pohon sintaks abstrak direpresentasikan oleh kelas DetailAST.
Meskipun pohon tersebut bersifat generik, proses penyusunan pohon dan semantik susunan pohon berbeda-beda karena bergantung pada grammar masing-masing bahasa pemrograman. Dengan demikian, grammar, lexer, parser dan treewalker (beserta kelas-kelas eksekusi) harus dirancangkan secara terpisah untuk setiap bahasa pemrograman.
Pengembangan interpreter Phobos dilakukan dengan bantuan generator parser Antlr. Antlr
dapat menghasilkan parser dan lexer secara otomatis dari grammar bahasa pemrograman
tertentu. Antlr juga dapat menghasilkan treeparser, suatu parser khusus yang menerima
pohon sintaks abstrak dan melakukan penelusuran terhadap pohon tersebut. Kelas implementasi Interpreter akan menggunakan parser dan lexer untuk menghasilkan pohon sintaks abstrak dalam bentuk kelas DetailAST. Kelas Interpreter akan kemudian menggunakan treeparser untuk mengeksekusi pohon sintaks abstrak yang telah
