1 i DAFTAR REFERENSI [AAB04] Anthony A. Aaby (2004). Theory Introduction To Programming Languages. < > Tanggal Akses : 26 Januari 2007 [ACM01] The Jo...
(2004). Theory Introduction To Programming Languages.
< http://www.cs.wwc.edu/~aabyan/Logic/index.html > Tanggal Akses : 26 Januari 2007 [ACM01] The Joint Task Force on Computing Curricula IEEE & ACM (2001). Computing Curricula 2001 Computer Science. < http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/education/cc2001/cc2001.pdf > Tanggal Akses : 20 Februari 2007 [ALF05] Enrique Alfonseca, Rosa M. Carro, Manuel Freire, Alvaro Ortigosa, Diana Pérez dan Pilar Rodriguez (2005). Authoring of Adaptive Computer Assisted Assessment of Free-text Answers. Dimuat pada jurnal Educational Technology & Society, Edisi 8 (3), h.53-65. < http://www.ifets.info/journals/8_3/6.pdf > Tanggal Akses : 21 September 2006 [ALG05] Algoshop Documentation, 2005. < http://toko.if.itb.ac.id/ > [BAR97] D. Stephen Barker (1997). CHARLIE : A Computer-Managed Homework, Assignment, and Response Learning and Instruction Environment. Prosiding untuk FIE 1997, Pittsburgh, Philadelphia, Amerika Serikat. < http://fie.engrng.pitt.edu/fie97/papers/1088.pdf > Tanggal Akses : 20 September 2006 [BEN01] Mordechai Ben-Ari (2001). Constructivism in Computer Science Education. Prosiding untuk SIGCSE 1998, Atlanta, Georgia, Amerika Serikat. < http://delivery.acm.org/10.1145/280000/274308/p257-benari.pdf?key1=274308&key2=3827088511&coll=&dl=ACM&CFID=15151515&CFTOKE N=6184618 > Tanggal Akses : 21 September 2006 [BON02] Scott W. Bonham, Duane L. Deardorff, Robert J. Beichner (2002). A comparison of student performance using web and paper-based homework in college-level physics. Dimuat pada Journal of Research in Science Teaching. Volume 40 Issue 10, Pages 1050 - 1071 < http://www.ncsu.edu/per/Articles/HomeworkComparisonResearch.pdf > Tanggal Akses : 20 September 2006 [BLO56] Bloom B. S. (1956). Taxonomy of Educational Objectives, Handbook I: The Cognitive Domain. New York: David McKay Co Inc. [BLU04] Michael Blumenstein, et al (2004). An Experimental Analysis of GAME : A Generic Automated Marking Environment. Prosiding untuk ITiCSE 04, 2830 Juni 2004, Leeds, Inggris. [CAB76] Thomas McCabe (1976). A Complexity Measure. Dimuat pada IEEE Transactions on Software Engineering, Vol SE-2, No.4, Desember 1976.
ii [CAR03] Janet Carter, et al (2003). How Shall We Assess This? Prosiding untuk ITiCSE 2003. [CHI98]
Yu-Liang Chi, Philip M. Wolfe. (1998). A Web-Based Automatic Software Grading System. Prosiding untuk The 50th International Engineering Solution Conference,1999, Phoenix < http://phoenix.mis.cycu.edu.tw/paper/1999-IEESC_Phoenix.pdf > Tanggal Akses : 27 September 2006.
[CAM97] Campbell, J.O.(1997). Evaluating Costs and Benefits of Distributed Learning. Prosiding untuk FIE 1997, Pittsburgh, PA (November 1997). [CHE07] Checkstyle Documentation, 2007. < http://checkstyle.sourceforge.net > [COO03] Keith Cooper, Linda Torczon (2003). Engineering A Compiler. Morgan Kaufman. [CRA01] Michael McCracken, et al. (2001). A multi-national, multi-institutional study of assessment of programming skills of first-year CS students. Dimuat pada kolom Laporan Kelompok Kerja ITICSE 2001 ACM SIGCSE Bulletin Volume 33 , Issue 4 (Desember 2001) [CYN07] Cynthia Kustanto (2007). Deteksi Otomatis Plagiarisme Source Code. Bandung: Departemen Teknik Informatika, Insititut Teknologi Bandung. [DAL01] James Dalziel (2001). Enhancing web-based learning with computer assisted assesments : Pedagogical and technical considerations. Prosiding untuk 5th CAA Conference 2001, Loughborough University, Inggris. < http://www.caaconference.co.uk/pastConferences/2001/proceedings/i2.pdf > Tanggal Akses : 27 September 2006 [DOR02] Edmond van Doren (2002). Maintainability Index Technique for Measuring Program Maintainability < http://www.sei.cmu.edu/str/descriptions/mitmpm.html > Tanggal Akses : 27 September 2006 [EJT07]
Raphael A. Finkel (1995). Advanced Programming Language and Design. Menlo Park : Addison Wesley.
[FOR65] George E. Forsythe, Niklaus Wirth (1965). Automatic Grading Programs. Dimuat pada Technical Report CS17, 12 Februari 1965, Universitas Stanford. < http://historical.ncstrl.org/litesite-data/stan/CS-TR-65-17.pdf > Tanggal Akses : 27 September 2006 [GIB99]
Cleve A Gibbon (1999). Writing Typographically Sound Programs With Ceilidh. Department of Computer Science, University of Nottingham, UK. < http://www.cs.nott.ac.uk/~ceilidh/papers/Typog.html > Tanggal Akses : 27 September 2006
[GRA82] Susan L Graham, Peter B. Kessler, Marshalk K McKusick. gprof : a Call Graph Execution Profiler. Prosiding pada SIGPLAN Symposium on Compiler Construction, 1982 < http://www.cs.virginia.edu/~weimer/415/reading/graham-gprof.pdf > Tanggal Akses : 10 April 2007
ii
iii [GRU98] Dick Grune, Ceriel JH. Jacobs. 1998. Parsing Techniques : A Practical Guide. Amsterdam : Vrije Universiteit Amsterdam. [HOA69] C.A.R. Hoare (1969). An Axiomatic Basis for Computer Programming. Dimuat pada jurnal Communications of the ACM, Volume 12, Issue 10 Oktober 1969. < http://www.spatial.maine.edu/~worboys/processes/hoare%20axiomatic.pdf > Tanggal Akses : 28 Maret 2007 [HOV04] David Hovemeyer, William Pugh. 2004. Finding Bugs is Easy. Dimuat pada SIGPLAN Notice edisi Desember 2004. < http://findbugs.sourceforge.net/docs/oopsla2004.pdf > Tanggal Akses : 11 April 2007 [IOI06]
International Olympics in Informatics. 2006. IOI 2006 Competition Rules < http://www.ioi2006.org/contenidos/ioi06rules.html > Tanggal Akses : 20 September 2006
[JAC97]
David Jackson, Michelle Usher (1997). Grading Student Programs using ASSYST. Prosiding untuk 28th SIGCSE Technical Symposium on Computer Science Education, San Jose, United States, 1997.
[JIS06]
JISC (2006). e-Assessment Glossary. < http://www.jisc.ac.uk/uploaded_documents/eAssess-Glossary-Short-v1-01.pdf > Tanggal Akses : 20 Maret 2007
[KUM02] Amruth N. Kumar (2002). Learning Programs By Solving Problems. < http://phobos.ramapo.edu/~amruth/r/c/ictem/02/paper.pdf > Tanggal Akses : 20 September 2006 [KRI06]
Shriram Krishnamurti (2006). Programming Languages : Application and Interpretation. < http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/PDF/plai-2006-01-15.pdf > Tanggal Akses : 23 Januari 2007
[LEA98] José Paulo Leal, Nelma Moreira (1998). Automatic Grading of Programming Exercises. Dimuat pada Technical Report DCC-98-4, DCC-FC& LIACC, Universidad de Porto, Portugal. < http://www.dcc.fc.up.pt/dcc/Pubs/TReports/TR98/dcc-98-4.ps.gz > Tanggal Akses : 27 September 2006 [LEA03] José Paulo Leal , Fernando Silva (2003). Mooshak: a Web-based multi-site programming contest system. Dimuat pada Jurnal Software- Practice and Experience Volume 33, Issue 6. New York : John Wiley & Sons. [LIE04]
Dr. Ir. Inggriani Liem. (2004). Diktat Kuliah IF1281 Algoritma dan Pemrograman. Bandung: Departemen Teknik Informatika Institut Teknologi Bandung.
[LIU96]
Liu, M.L., Blanc, L. (1996). On the retention of female Computer Science students. Prosiding untuk 27th SIGCSE Technical Symposium, Philadelphia, PA, Maret 1996, 32-36.
[LIS01]
Raymond Lister (2001). Objectives and Objective Assessment in CS1. Prosiding untuk SIGCSE 2001, Charlotte, NC, Amerika Serikat.
iii
iv [LIS03]
Raymond Lister, John Leaney (2003). Introductory Programming, Criterion-Referencing, and Bloom. Prosiding untuk 34th SIGCSE Technical Symposium, Reno, NV, Februari 2003
[LIS04]
Raymond Lister, et al (2004). A multi-national study of reading and tracing skills in novice programmers. Dimuat pada Buletin ACM SIGCSE, Volume 36 , Issue 4 - December 2004. New York : ACM Press
[MAC83] Bruce J. MacLennan (1983). Principles of Programming Languages : Design, Evaluation and Implementation. New York: Holt-Saunders [MAS02] Oliver Mason, Ian Grove-Stephensen. (2002). Automated free-text marking with Paperless School. < http://magpie.lboro.ac.uk/dspace/bitstream/2134/1882/1/Mason_o1.pdf > Tanggal Akses : 21 September 2006 [MOR07] Thiemo Morth, Rainer Oechsle, Hermann Schloß, Markus Schwinn (2007). Automatische Bewertung studentischer Software. < http://openconf.cs.tu-darmstadt.de/DeLFI2007/PDF/ASB.pdf > Tanggal Akses : 5 Maret 2008 [MOO08] Mooshak Documentation, 2008. < http://mooshak.dcc.fc.up.pt/~mooshak-virtual/ > [PAR94] Terrence J. Parr, R.W. Quong. (1994) ANTLR: A Predicated-LL(k) Parser Generator. Dimuat pada Jurnal Software - Practice and Experience, Vol. 25(7), 789–810(July 1995) [PUR03] Ir. Sri Purwanti, M.Sc. (2003). Diktat Lisp. Bandung: Departemen Teknik Informatika Institut Teknologi Bandung. [RAW02] Simon Rawles, Mike Joy, Michael Evans (2002). Computer-Assisted Assesments in Computer Science : Issues and Software. Dimuat pada Technical Report Universitas of Warwick, 2002 Inggris. < http://www.dcs.warwick.ac.uk/reports/cs-rr-387.ps.gz > Tanggal Akses : 27 September 2006 [SCH96] Schollmeyer, M. (1996). Computer Programming in Highschool versus College. Prosiding untuk 26th SIGCSE Technical Symposium, Philadelphia, PA, February 1996, 378-382. SEN98]
Sencer Sultanoðlu, Ümit Karakaþ (1998). Complexity Metrics and Models. < http://yunus.hacettepe.edu.tr/~sencer/complexity.html > Tanggal Akses : 24 Januari 2007
[SLA06] AskSlashdot. (2006). Resources For Programming Course TA? Tanggal Akses : 21 September 2006 [SLO95] Kenneth Slonneger, Barry L Kurtz (1995). Formal Syntax and Semantics of Programming Languages. Menlo Park: Addison Wesley. [SPI03]
Diomidis Spinellis (2003). Code Reading: An Open Source Perspective. Menlo Park: Addison Wesley.
iv
v [SRI94]
Amitabh Srivastava, Alan Eustace. ATOM: a system for building customized program analysis tools. Dimuat pada Jurnal ACM SIGPLAN Notices Volume 29 , Issue 6 (June 1994)
[STE90]
Guy Steele. Common Lisp The Language, 2nd edition. < http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/clm.html > Tanggal Akses : 4 Februari 2008.
[SYM01] Pavlos Symeonidis (2001). An in-depth Review of CourseMaster’s Marking Subsystem. < http://www.cs.nott.ac.uk/CourseMarker/more_info/pdf/AnIndepthReviewofCourseMastersMarkingSubsystem.pdf > Tanggal Akses : 20 September 2006 [SWA06] Fred Swartz (2006). Java : Complexity Measurement < http://www.leepoint.net/notesjava/principles_and_practices/complexity/complexity_measurement.html > [WAT90] David A. Watt (1990). Programming Language Concepts and Paradigms. New York: Prentice Hall. [WIR73] Niklaus Wirth (1973). The Programming Language Pascal (Revised Report). < http://www.standardpascal.org/The_Programming_Language_Pascal_1973.pdf > [ZIN91]
Abdullah Mohd Zin, Dr. Eric Foxley. (2001). Automatic Program Assessment System. < http://www.cs.nott.ac.uk/CourseMarker/more_info/html/ASQA.HTM > Tanggal Akses : 20 September 2006
v
LAMPIRAN A Besaran Kompleksitas Source Code Salah satu jenis penilaian yang dapat dilakukan terhadap serahan tugas adalah terhadap kompleksitas solusi. Besaran-besaran yang dapat digunakan untuk mengukur kompleksitas solusi antara lain kompleksitas Siklomatik, kompleksitas Halstead, dan kompleksitas Henry Kafura
A.1
Kompleksitas Siklomatik
Kompleksitas siklomatik yang pertama kali dikembangkan oleh Thomas McCabe pada tahun 1976 [CAB1976], pada dasarnya menghitung jumlah titik percabangan dalam kode. Secara formal, kompleksitas siklomatik mengukur jumlah jalur independen yang dapat ditempuh dalam suatu program. Sebagai contoh, untuk sebuah fungsi sederhana yang tidak memiliki pernyataan kondisional, hanya ada satu jalur. Kode jalur tunggal ini umumnya mudah diikuti – dan sebaliknya, kode yang memiliki banyak percabangan lebih kompleks.
Kompleksitas siklomatik secara sederhana dapat dirumuskan sebagai : Cyclomatic Complexity (CC) = E - N + p
... (2)
di mana E adalah jumlah sisi graf, N adalah jumlah simpul graf eksekusi, dan p adalah jumlah komponen yang terkoneksi.
Gambar VI-1 Representasi graf berarah untuk perhitungan kompleksitas siklomatik
A-i
Sebuah contoh penerapan perhitungan kompleksitas siklomatik pada sebuah potongan program dalam bahasa Java dapat dilihat pada Gambar VI-1. Kode program dapat ditranslasikan menjadi graf berarah dengan nomor simpul yang bersesuaian dengan nomor di samping baris-baris kode. Pada graf tersebut terdapat 11 simpul, 14 sisi, dan dua simpul yang terkoneksi (1 dengan 11). Maka kompleksitas kode pada contoh tersebut ialah 14 -11 + 2 = 5.
Kompleksitas McCabe untuk sebuah metode/fungsi seharusnya berada di bawah 10 – jika kompleksitas menunjukkan angka di bawah 5 maka metode tersebut cukup sederhana, angka kompleksitas di antara 5-10 dapat diterima, dan kompleksitas di atas 10 menunjukkan bahwa fungsi melakukan terlalu banyak hal, atau kohesinya rendah. Angka kompleksitas siklomatik yang tinggi belum tentu menunjukkan keruwetan – sebuah struktur kondisional seperti switch dapat meningkatkan angka kompleksitas secara drastis meskipun konstruksinya masih dapat dipahami dengan mudah. Walaupun demikian, kompleksitas siklomatik yang tinggi merupakan petunjuk bahwa mungkin dibutuhkan penulisan ulang terhadap kode – nilai yang amat besar (>100) menunjukkan bahwa kode tidak mungkin dapat diuji dengan akurat.
Sebagai besaran perangkat lunak yang umum digunakan, rumus perhitungan terhadap kompleksitas siklomatik dirancang independen terhadap bahasa pemrograman dan formatnya. Perhitungan kompleksitas siklomatik juga dapat diterjemahkan ke dalam program dengan cukup mudah. Sayangnya, perhitungan kompleksitas siklomatik hanya memperhitungkan alur eksekusi program tanpa memasukkan aliran data dalam perhitungan – dan juga tidak memberikan perhatian khusus pada persarangan, khususnya perulangan bersarang (nested loop) di mana tiap persarangan meningkatkan kerumitan.
A.2
Kompleksitas Halstead
Besaran Halstead, yang pertama kali dipublikasikan pada tahun 1977 [SEN98] merupakan besaran yang paling dikenal dan banyak ditelaah. Besaran ini dikembangkan untuk mengukur kompleksitas sebagai fungsi dari jumlah operan (variabel dan konstanta) dan operator (operator aritmatika dan kata kunci yang mengubah alur kendali program) dalam program. Kompleksitas Halstead dapat dihitung menggunakan persamaan-persamaan sebagai berikut.
N = n1 log 2 n1 + n 2 log 2 n 2 N *n D= 1 1 2 * n2
A-ii
... (3) ... (4)
Besaran Halstead terdiri dari ukuran-ukuran primitif (n1, n2, N1, and N2) yang dapat diturunkan dari source code: n1 = jumlah operator unik (if, while, =, echo, [...], etc); n2 = jumlah operan unik (variabel atau konstanta); N1 = jumlah total kemunculan operator; N2 = jumlah total kemunculan operan. N melambangkan estimasi panjang program, sementara D menunjukkan tingkat kesulitan program. Besaran Halstead memiliki beberapa kelebihan, antara lain tidak membutuhkan analisis struktur program secara mendalam, mudah digunakan, dapat diaplikasikan untuk berbagai bahasa pemrograman.
A.3
Kompleksitas Henry dan Kafura
Kompleksitas Henry dan Kafura, atau disebut juga kompleksitas arus informasi, pertama kali dikembangkan oleh Sallie M. Henry dan Dennis Kafura pada tahun 1981 [SEN98]. Besaran ini digunakan untuk menghitung tingkat aliran informasi antara sebuah modul tunggal dengan bagian lain dari sistem.
Dalam pengukuran Henry dan Kafura, terdapat beberapa terminologi yang digunakan untuk menggambarkan arus informasi. Apabila sebuah modul menggunakan modul yang lain dan menyalurkan data kepada modul tersebut, atau jika modul lain yang digunakan mengembalikan sebuah hasil pada modul yang sedang dihitung kompleksitasnya, maka aliran informasi yang terjadi disebut aliran lokal langsung. Sebuah aliran lokal tak langsung terjadi apabila modul luar yang digunakan menyalurkan informasi kepada modul lain. Sebuah aliran global terjadi apabila informasi mengalir dari sebuah modul ke modul lain melalui sebuah struktur data global. Fan-in dari modul M adalah jumlah aliran lokal yang berakhir pada M, ditambah dengan jumlah struktur data global yang informasinya diakses oleh M. Fan-out pada modul M didefinisikan sebagai jumlah aliran lokal yang berasal dari M ditambah dengan jumlah struktur data yang diupdate oleh M.
Berdasarkan konsep-konsep di atas, kompleksitas modul menggunakan metode Henry dan Kafura dihitung menggunakan rumus sebagai berikut : ifc(M) = length(M) x (fan-in(M) x fan-out(M))2 di mana length merupakan panjang modul, fan-in merupakan jumlah aliran data masuk dan fan-out adalah jumlah aliran data keluar dari modul. Panjang kode pada umumnya menggunakan besaran jumlah baris kode, atau dapat juga digunakan kompleksitas siklomatik McCabe. Perhitungan kompleksitas Henry dan Kafura ini amat bergantung pada dekomposisi modul dan pada banyaknya aliran data dari prosedur-prosedur tersebut. Di lain pihak, jika modul sama sekali tidak memiliki aliran data masuk atau keluar, kompleksitas yang dihasilkan bisa jadi nol.
A-iii
LAMPIRAN B Penilaian Tipografi Kode oleh Ceilidh Ceilidh merupakan sebuah program penilai yang telah teruji dan digunakan secara luas
[ZIN91], yang merupakan pendahulu dari salah satu perangkat lunak penilai source code yang sudah dibahas sebelumnya pada Subbab 2.1.3.2, CourseMaster. Ceilidh berpegang pada konvensi bahwa source code yang baik secara tipografis memenuhi karakteristik berikut: a) Bagian-bagian yang kompleks dari kode mempunyai keterangan. b) Terdapat cukup banyak ruang kosong (white space) untuk memecah kode dan memudahkan pembacaan. c) Penggunaan sintaks bahasa yang konsisten. d) Perimbangan delimiter yang tepat (contohnya, dalam bahasa Pascal: beginend; C: {},(),[]). e) Nama identifier (variabel) yang bermakna. f) Kode terindentasi dengan baik.
Panduan tipografi ini telah disesuaikan dengan panduan gaya penulisan kode yang telah dijabarkan oleh Oman dan Cook [ZIN91]. Besaran-besaran gaya tipografi kode ini diimplementasikan oleh Ceilidh dalam poin-poin sebagai berikut [GIB99]. 1)
Rata-rata jumlah huruf dalam tiap baris Baris-baris kode tidak boleh terlalu panjang atau terlalu pendek. Telah jelas bahwa besaran ini merupakan rata-rata, karena ada baris yang memang harus panjang dan baris lain harus pendek. Secara keseluruhan, pengembang Ceilidh telah menemukan rata-rata yang cukup baik untuk rata-rata jumlah huruf dalam tiap baris yaitu sekitar 15-30 huruf.
2)
% baris kosong Penggunaan baris kosong untuk mempermudah pembacaan disarankan pada rentang 1530% dari keseluruhan kode. Baris kosong yang berlebihan atau amat kurang akan mengurangi poin tipografi.
3)
Rata-rata jumlah spasi dalam tiap baris Besaran ini juga digunakan untuk mempermudah pembacaan – spasi harus digunakan di antara operator, setelah koma, setelah tanda kurung buka ( dan sebelum tanda kurung tutup ). Spasi pada awal dan akhir baris tidak dipertimbangkan dalam perhitungan nilai. Rentang yang normal pada Ceilidh yaitu 10-30%.
B-iv
4)
Rata-rata panjang nama identifier Nama identifier (variabel, fungsi) harus informatif dan mampu menggambarkan kegunaannya dengan cepat. Variabel dengan nama seperti counter seperti i, j, k dapat digunakan, nama seperti iCounter, jCounter dan kCounter lebih disukai, karena menggambarkan apa persisnya kegunaan variabel yang bersangkutan. Pada skema Ceilidh, rata-rata panjang nama identifier ditetapkan berkisar antara 5-10 huruf. Nama identifier memang tidak selalu harus sepanjang nilai tersebut, namun rata-rata panjangnya harus tetap berada pada kisaran yang telah ditentukan.
5)
% nama dengan panjang yang memenuhi syarat Meskipun rata-rata panjang nama identifier dapat mengindikasikan nama variabel yang memadai, dalam kenyataannya besaran itu belum tentu menggambarkan keadaan sesungguhnya. Jika nama-nama pendek digunakan bersama dengan beberapa nama yang panjang, rata-rata panjang nama saja tidak akan mampu mendeteksi anomali ini. Ceilidh menetapkan aturan bahwa di atas 70% nama yang digunakan mempunyai
panjang yang cukup. 6)
% baris komentar Ceilidh mengharapkan setiap source code mengandung sebentuk komentar. Besaran
persentase komentar menghitung jumlah komentar, dan bergantung pada ukuran program, ia melaporkan apakah ada terlalu banyak atau terlalu sedikit komentar. Sebuah program harus memiliki antara 10% hingga 60% baris komentar. Komentar harus ada pada bagian awal kode, sebelum tiap fungsi dan setiap fragmen yang membutuhkan penjelasan lebih lanjut. 7)
% karakter dalam komentar Meletakkan tanda komentar pada sebuah baris saja tidak akan mencukupi kebutuhan – komentar perlu diisi dengan teks untuk dapat dipahami. Sistem penilai otomatis sampai saat ini tidak melakukan pemeriksaan terhadap isi semantik dari komentar. Pengembang Ceilidh menganggap bahwa menulis komentar yang tidak berarti nampak ‘kontradiktif’
karena tidak ada gunanya, meskipun pengalaman Ala-Mutka [CAR03] menunjukkan bahwa ada siswa-siswa yang melakukannya hanya untuk memenuhi permintaan pemeriksa gaya. Ceilidh menetapkan rentang 10%-60% dari source code harus berupa komentar. 8)
% indentasi Ceilidh tidak memberikan rentang yang pasti dalam hal indentasi dan cara
pengukurannya secara mendetil, namun perangkat lunak ini mengukurnya dengan menggunakan beberapa heuristik, seperti: −
% kesalahan indentasi pada tanda kurung kurawal {}
B-v
−
% kesalahan indentasi pada tanda kurung siku []
−
% kesalahan indentasi pada tanda kurung ()
Panduan penulisan kode Ceilidh menyatakan bahwa tanda pembuka dan penutup struktur blok (pada C: {}, () dan []) harus berada pada kolom yang sama. Sebagaimana dapat dilihat pada contoh Kode VI-1, setiap penanda struktur blok dimulai pada baris baru dan di dalamnya, penulisan dimulai pada tingkatan indentasi yang lebih jauh. Sebuah perkecualian untuk tanda kurawal pembuka { dapat digunakan pada baris yang sama dengan pernyataan pencabangan (dalam bahasa C : if, else, switch) atau perulangan (dalam bahasa C : do..while, while) yang mendahuluinya. Jika terdapat deklarasi atau ekspresi dalam tanda kurung ( ) atau kurung siku [ ] yang terlalu panjang, maka isi deklarasi atau ekspresi tersebut diletakkan pada baris yang baru, dengan tanda pembuka (tanda ( atau [) berada pada kolom yang sama dengan penutupnya (tanda ) atau ]).
Kode VI-1 Contoh Penulisan Kode yang Tepat
Panduan Ceilidh tidak menyebutkan tentang konvensi metode indentasi, karena pemeriksaan kecocokan penanda struktur dilakukan hanya berdasarkan letak kolom yang sama. Meskipun demikian, penggunaan metode indentasi yang tidak konsisten antara karakter tab (kode ASCII 9) dengan spasi jamak akan menyebabkan penampilan kode yang membingungkan atau bahkan tak dapat dibaca [SPI03]. Penggunaan spasi jamak secara konsisten pada keseluruhan program lebih disukai, karena dapat ditampilkan secara seragam pada berbagai editor, meskipun ukuran kode akan menjadi lebih besar.
B-vi
9)
% akhir struktur blok (dalam C: }) yang tidak diberi komentar Seringkali komentar dibutuhkan untuk memperbaiki keterbacaan kode pada akhir struktur blok, khususnya untuk perulangan dan beberapa percabangan. Jika kurawal penutup berjarak lebih dari 10 baris dari kurawal pembukanya, maka blok tersebut harus diberi komentar. Meskipun tidak semua penutup blok harus diberi komentar, pengalaman pengembang Ceilidh menunjukkan bahwa memberi keterangan pada akhir blok yang penting adalah praktek yang baik. Besaran ini hanya membatasi jika akhir struktur blok yang diberi komentar terlalu sedikit, meskipun tidak disebutkan ukuran yang pasti.
Pemrosesan tipografis di dalam Ceilidh hanya dapat dijabarkan berdasarkan dokumentasi yang tersedia, karena Ceilidh tidak bersifat open source. Namun demikian, konvensi dan besaran yang diberikan oleh Ceilidh tetap merupakan pedoman yang penting untuk penilaian source code, karena ia merupakan perangkat lunak yang murni bertujuan pedagogis. Pada Kode VI-2 terlampir adalah contoh source code dalam bahasa C atau C++ [GIB99] yang menurut panduan tipografi Ceilidh cukup baik.
B-vii
Kode VI-2 Contoh Kode C/C++ yang Mengikuti Panduan Tipografi Ceilidh [GIB99]
#include #include #include #include
<stream.h> <stdio.h> <string.h> <stdlib.h>
// carry out some parsing on the standard input void ScanFile(char *directory) { char line[1000],*ptr; int addTab; char *str = NULL; // cycle through all lines input from the terminal while( fgets( line, 1000, stdin) ) { //remove eric's .so tmac.ef entry if ( ! strncmp(".so",line,3) ) { str = (char*) strdup(line); // check to see if line contains `tmac' string if ( ( strtok(str, " \t") ) && ( ptr = strtok(NULL, " \t") ) && ( strstr(ptr, "tmac") ) ) { if ( directory == NULL ) { continue; } else { sprintf( line, ".so %s/tmac.ef\n", directory ); } } } // end check for `.so' in the line // write out text line to standard output fwrite( line, sizeof(char), strlen(line), stdout ); } // end reading in lines while..loop }// end of ScanFile main(int argc, char **argv) { if (argc == 1) { ScanFile(NULL); } else { if (opendir(argv[1]) == NULL) { exit(EXIT_FAILURE); } else ScanFile(argv[1]); } } // end of main program
B-viii
LAMPIRAN C Survei Bahasa-Bahasa Pemrograman yang Digunakan pada Program Studi Sarjana Informatika ITB (S1-IF-ITB) Dalam S1-IF-ITB, pengajaran pemrograman diterapkan sebagai serangkaian mata kuliah, masing-masing dengan paradigma dan bahasa pemrograman yang berbeda-beda. Pada bagian selanjutnya, akan dijabarkan secara singkat mengenai bahasa-bahasa pemrograman yang digunakan pada mata kuliah pemrograman yang diselenggarakan oleh S1-IF-ITB berdasarkan
kurikulum 2003 yang direvisi. Perbandingan singkat masing-masing bahasa pemrograman dapat dilihat pada Tabel VI-1.
Tabel VI-1 Perbandingan singkat berbagai bahasa pemrograman Bahasa Pemrograman
Lisp (LISt Processing) adalah salah satu bahasa pemrograman tertua yang masih digunakan saat ini. Lisp diciptakan oleh John McCarthy pada tahun 1958 di MIT, awalnya sebagai notasi matematis yang praktis untuk program komputer, berdasarkan pada kalkulus lambda Alonzo Church. Dengan cepat, Lisp menjadi bahasa pemrograman yang populer untuk riset intelegensia buatan. Sebagai salah satu bahasa tertua, Lisp mempelopori banyak ide dalam ilmu komputer, di antaranya struktur data pohon, manajemen penyimpanan otomatis, tipe dinamis, pemrograman berorientasi objek. Seraya waktu berlalu, Lisp telah banyak mengalami perubahan dan juga mempunyai berbagai varian bahasa, atau dialek, beberapa di antaranya yang masih banyak digunakan saat ini adalah Scheme dan Common Lisp.
C-ix
Kode VI-3 Sebuah contoh program kecil dalam bahasa Lisp (defun addlast(c L) (if (null L) (cons c L) (cons (car L) (addLast c (cdr L))) ) ) (defun reverselist(L) (if (null L) L (addLast (car L)(reverselist (cdr L))) ) ) ; eksekusi (addlast 9 ‘(1 3 5 7)) (reverselist ‘(2 3 5 7 11))
;basis-0 ;recc
;basis-0 ;recc
Sebagaimana diimplikasikan oleh akronimnya, salah satu struktur data utama dalam Lisp adalah list berkait. Program ditulis sebagai ekspresi-s, atau list dengan parenthesis/tanda kurung. Sebuah aplikasi fungsi ditulis sebagai list dengan nama fungsi atau operator pada awal list dan argumen fungsi sebagai elemen selanjutnya; sebagai contoh, fungsi f yang menerima tiga argumen dapat diaplikasikan dengan menggunakan perintah (f x y z). Karena program dan data dapat dipertukarkan, maka program Lisp dapat mengubah source code-nya sendiri, membuat pemrogram dapat menciptakan sintaks baru atau bahasa pemrograman mini di atas Lisp.
GNU Common Lisp adalah salah satu dialek Lisp yang digunakan sebagai bahasa implementasi standar untuk paradigma pemrograman fungsional yang diajarkan pada mata kuliah IF1282 Dasar Pemrograman. Mata kuliah ini diambil oleh mahasiswa tahun pertama Sekolah Teknik Elektro dan Informatika pada semester kedua dalam proses studinya menurut kurikulum 2003 yang direvisi.
C.2
Pascal
Pascal merupakan bahasa pemrograman imperatif yang dikembangkan oleh Niklaus Wirth pada tahun 1970 [WIR73], secara khusus cocok untuk pemrograman terstruktur. Bahasa pemrograman ini didasarkan pada bahasa pemrograman ALGOL, dan dinamai menurut nama matematikawan dan filsuf Blaise Pascal. Pada awalnya, Pascal dimaksudkan untuk mengajarkan pemrograman terstruktur kepada siswa, dan secara tradisional, generasi-generasi awal siswa diajar menggunakan Pascal sebagai bahasa pengantar pada mata kuliah tahap sarjana. Berbagai varian Pascal masih digunakan sampai saat ini untuk kepentingan pendidikan dan pengembangan perangkat lunak, antara lain Turbo Pascal, Free Pascal yang
C-x
bersifat open source, serta dalam versi berorientasi objek dari Pascal, yaitu Object Pascal atau Delphi.
Dalam rancangan awalnya, Pascal merupakan bahasa pemrograman prosedural murni, dengan serangkaian konstruksi standar sekuens, kondisional dan perulangan seperti if, while, for, dan sebagainya. Karena dimaksudkan untuk menekankan pemrograman terstruktur, alur kontrol program ditata ke dalam konstruksi-konstruksi yang dimiliki, idealnya tanpa perintah goto. Pascal memiliki tipe dasar real untuk bilangan rasional, integer untuk bilangan bulat, character / huruf, dan tipe enumerasi. Selain itu, Pascal juga memiliki tipe data ordinal (subset dari tipe data dasar) dan tipe bentukan, serta pointer (referensi terhadap suatu variabel). Program ditata ke dalam prosedur dan fungsi yang dapat diletakkan bersarang satu sama lain.
Kode VI-4 Sebuah contoh program kecil dalam bahasa Pascal program mine(output); var i : integer; procedure print_inc(var j: integer); function next(k: integer): integer; begin next := k + 1 end; begin writeln('The total is: ', j); j := next(j) end; begin i := 1; while i <= 10 do print_inc(i) end.
Free Pascal digunakan sebagai bahasa implementasi standar untuk paradigma pemrograman prosedural yang diajarkan pada mata kuliah IF2182 Algoritma dan Struktur Data. Mata kuliah ini diambil oleh mahasiswa program studi Informatika pada semester ketiga masa studinya menurut kurikulum 2003 yang direvisi.
C.3
C
C adalah bahasa pemrograman prosedural imperatif multiguna yang dikembangkan pada tahun 1972 oleh Dennis Ritchie pada Bell Labs untuk digunakan pada sistem operasi Unix. Sejak itu, C telah digunakan pada berbagai platform, dan sekarang merupakan salah satu bahasa yang paling banyak digunakan. C juga mempengaruhi pengembangan bahasa lain, antara lain C++, Java, PHP, dan Perl, yang memiliki sintaks mirip C. Bahasa ini merupakan bahasa yang paling umum digunakan untuk pemrograman sistem, di samping masih digunakan untuk menulis banyak aplikasi.
C-xi
Kode VI-5 Sebuah contoh program kecil dalam bahasa C #include <stdio.h> int i; int next (int k) { return k+1; } void print_inc (int* j) { printf(“The total is %d\n”, *j); (*j)++; } int main() { i = 1; while (i <= 10) { print_inc(&i); } return 0; }
C memiliki fasilitas yang serupa dengan Pascal, seperti konstruksi blok, prosedur, fungsi, serta tipe dasar (character, integer, dan float) dan tipe bentukan, namun C memiliki sintaks yang lebih padat dengan penggunaan banyak karakter non alfanumerik. C juga memiliki beberapa karakteristik bahasa pemrograman tingkat rendah, seperti menyediakan akses memori secara langsung dan aritmatika pointer serta sistem tipe yang lemah. Meskipun demikian, C juga dirancang agar independen terhadap arsitektur mesin – kompilator C kini tersedia untuk platform yang amat beragam, mulai dari peralatan genggam hingga superkomputer.
GNU C digunakan sebagai bahasa implementasi untuk paradigma pemrograman prosedural yang diajarkan pada mata kuliah IF2182 Algoritma dan Struktur Data. Mata kuliah ini diambil oleh mahasiswa program studi Informatika pada semester ketiga masa studinya menurut kurikulum 2003 yang direvisi.
C.4
C++
C++ adalah bahasa pemrograman multiguna yang mampu menangani berbagai paradigma pemrograman. Bjarne Stroustrup mengembangkan C++ pada tahun 1983 pada Bell Labs sebagai perbaikan dari bahasa pemrograman C. Sejak tahun 1990-an, C++ merupakan salah satu bahasa pemrograman yang paling populer untuk aplikasi komersial.
Kode VI-6 Sebuah contoh program kecil dalam bahasa C++ #include class Bird // the "generic" base class { public: virtual void OutputName() { std::cout << "a bird"; } virtual ~Bird() {} }; class Swan : public Bird {
// Swan derives from Bird
C-xii
public: void OutputName() { std::cout << "a swan"; } // overrides virtual function }; int main() { Bird* myBird = new Swan; // Declares a pointer to a generic Bird, // and sets it pointing to a newly created Swan. myBird->OutputName(); // This will output "a swan", not "a bird". delete myBird; return 0; }
Bahasa C++ memiliki sintaks yang sama dengan bahasa C, dengan tambahan fitur-fitur khusus untuk mendukung konsep-konsep baru, seperti pemrograman berorientasi objek. Pengembangan fitur dimulai dengan penambahan kelas, yang kemudian diikuti dengan berbagai fitur lainnya, antara lain, fungsi virtual dan kelas abstrak, operator overloading, pewarisan ganda, template, namespace dan penanganan exception.
GNU C++ digunakan sebagai bahasa implementasi untuk paradigma pemrograman berorientasi objek yang diajarkan pada mata kuliah IF2281 Pemrograman Berorientasi Objek. Mata kuliah ini diambil oleh mahasiswa program studi Informatika pada semester keempat masa studinya menurut kurikulum 2003 yang direvisi.
C.5
Java
Java adalah bahasa pemrograman berorientasi objek yang dikembangkan oleh Sun Microsystems pada awal tahun 1990an. Awalnya, Java mulai dikembangkan dengan nama Oak oleh James Gosling pada tahun 1991 dengan tujuan utama membuat bahasa pemrograman yang dapat berjalan pada berbagai platform menggunakan mesin virtual dengan sintaks yang menyerupai C/C++. Jargon yang sering diusung oleh Java adalah ‘Write Once, Run Anywhere’ – tulis (kode) sekali, jalankan program di mana saja. Sukses Java diawali dalam bentuk applet, yang memungkinkan client-side scripting independen terhadap platform browser. Java segera digunakan secara luas bersama dengan meledaknya popularitas internet dan World Wide Web. Pada perkembangannya, Java (“Java 2”) berkembang menjadi serangkaian paket sesuai dengan library yang dimiliki, di antaranya J2EE untuk aplikasi enterprise dan J2ME untuk aplikasi mobile. Saat ini, Java merupakan salah satu bahasa pemrograman yang paling populer untuk pembuatan aplikasi.
Java memiliki sintaks dan konstruksi yang mirip dengan C/C++, namun memiliki object model yang lebih sederhana dan fasilitas akses level rendah yang lebih sedikit. Java saat ini mendukung berbagai fitur yang dimiliki oleh C++ seperti template, kelas abstrak dan metode virtual, dengan beberapa fitur berbeda yang menonjol, antara lain manajemen memori
C-xiii
otomatis / garbage collection, pewarisan tunggal, serta library standar (API) yang cukup lengkap. Kode dalam bahasa Java umumnya dikompilasi menjadi bytecode, yang kemudian dieksekusi oleh mesin virtual (Java Virtual Machine – JVM) pada mesin target yang bersangkutan. JVM kemudian bertindak sebagai interpreter atau kompilator Just-In-Time untuk mencapai independensi terhadap platform.
Kode VI-7 Sebuah contoh program kecil dalam bahasa Java import java.io.*; public class Bird { public void outputName() { system.out.println("a bird"); } }; public class Swan extends Bird // Swan derives from Bird { public void outputName() { system.out.println("a swan"); } // overrides inherited function }; public static void main(String[] args) { Bird myBird = new Swan(); // instantiates a new swan object myBird.outputName(); // This will output "a swan", not "a bird". }
Java digunakan sebagai bahasa implementasi untuk paradigma pemrograman berorientasi objek yang diajarkan pada mata kuliah IF2281 Pemrograman Berorientasi Objek. Mata kuliah ini diambil oleh mahasiswa program studi Informatika pada semester keempat masa studinya menurut kurikulum 2003 yang direvisi.
C-xiv
LAMPIRAN D Skenario Use Case Phobos D.1
Skenario Use Case Membuat Skema Penilaian
Pada Subbab ini diberikan skenario use case untuk use case menentukan skema penilaian. Dalam pembuatan skema penilaian terdapat tiga kemungkinan skenario, yaitu membuat skema penilaian baru, mengedit, dan menghapus skema penilaian yang sudah ada. Skenario use case untuk masing-masing alternatif dijelaskan pada Subbab-Subbab selanjutnya.
E.1.1 Subskenario Use Case Membuat Skema Penilaian Baru PHB-UC-01. Instruktur. Aplikasi menampilkan form pembuatan skema penilaian baru. Skenario Normal Aksi Aktor Respon Aplikasi Front-End Respon Autograder Engine 1. Memberikan titel tugas, deskripsi dan bahasa pemrograman untuk submisi tugas, memasukkan titik uji beserta data uji yang digunakan, lalu menekan tombol “Simpan skema”. 2. Mengirimkan pesan pada engine penilai otomatis untuk menyimpan skema penilaian yang diterima kepada autograder engine. 4. Memvalidasi masukan aplikasi web untuk membentuk objek skema penilaian. 5. Menyimpan skema penilaian yang telah terbentuk dalam penyimpanan data persisten Phobos. 6. Menampilkan pesan bahwa skema penilaian telah disimpan. Nomor Use Case Aktor Prekondisi
Kondisi Akhir
Skema penilaian tersimpan di dalam penyimpanan data persisten
D-xv
Skenario Alternatif : Terdapat kesalahan pada skema penilaian Aksi Aktor Respon Aplikasi Front-End Respon Autograder Engine 1. Memberikan titel tugas, deskripsi dan bahasa pemrograman untuk submisi tugas, memasukkan titik uji dan data uji, lalu menekan tombol “Simpan skema”. 2. Mengirimkan pesan pada engine penilai otomatis untuk menyimpan skema penilaian yang diterima kepada autograder engine. 3. Memvalidasi masukan aplikasi web untuk membentuk objek skema penilaian. 5. Menampilkan pesan bahwa terdapat kesalahan pada skema penilaian yang hendak disimpan. Skema penilaian yang masih memiliki kesalahan ditampilkan kembali beserta Kondisi Akhir pesan kesalahan. Skema tidak disimpan ke dalam penyimpanan persisten.
E.1.2 Subskenario Use Case Mengedit Skema Penilaian yang Sudah Ada PHB-UC-01. Instruktur. Aplikasi menampilkan daftar semua skema penilaian yang ada pada sistem. Skenario Normal Aksi Aktor Respon Aplikasi Front-End Respon Autograder Engine 1. Memilih skema penilaian yang hendak diedit. 2. Mengirim request skema penilaian yang hendak diedit kepada autograder engine. 3. Mengambil skema penilaian yang diminta dari penyimpanan persisten 4. Menampilkan skema penilaian yang diminta dalam form edit skema penilaian 5. Melakukan perubahanperubahan pada skema penilaian, lalu menekan tombol “Simpan skema”. 7. Mengirimkan pesan pada engine penilai otomatis untuk menyimpan skema penilaian yang diterima kepada aplikasi web. 8. Memvalidasi masukan aplikasi web untuk membentuk objek skema penilaian. 9. Menyimpan skema penilaian yang telah terbentuk dalam penyimpanan persisten Phobos. 10. Menampilkan pesan bahwa skema penilaian telah disimpan. Skema penilaian tersimpan di dalam penyimpanan data persisten Kondisi Akhir Nomor Use Case Aktor Prekondisi
D-xvi
Skenario Alternatif : Skema penilaian yang diminta tidak ada Aksi Aktor Respon Aplikasi Front-End Respon Autograder Engine 1. Memilih skema penilaian yang hendak diedit. 2. Meneruskan permintaan skema penilaian yang hendak diedit 3. Mengambil skema penilaian yang diminta dari penyimpanan persisten 4. Menampilkan pesan bahwa skema penilaian tidak ada. Aplikasi menampilkan daftar semua skema penilaian yang ada pada sistem Kondisi Akhir beserta pesan kesalahan.
Skenario Alternatif : Perubahan skema penilaian yang dilakukan tidak valid Aksi Aktor Respon Aplikasi Front-End Respon Autograder Engine 1. Memilih skema penilaian yang hendak diedit. 2. Meneruskan permintaan skema penilaian yang hendak diedit 3. Mengambil skema penilaian dari penyimpanan persisten 4. Menampilkan skema penilaian yang diminta dalam form edit skema penilaian 5. Melakukan perubahanperubahan pada skema penilaian, lalu menekan tombol “Simpan skema”. 7. Mengirimkan pesan pada autograder engine untuk menyimpan skema penilaian yang 8. Memvalidasi masukan diterima. aplikasi web untuk membentuk objek skema penilaian. 9. Menampilkan pesan bahwa terdapat kekurangan pada skema penilaian yang hendak disimpan. Skema penilaian yang masih memiliki kesalahan ditampilkan kembali beserta Kondisi Akhir pesan kesalahan. Skema tidak disimpan ke dalam penyimpanan persisten.
D-xvii
E.1.2 Subskenario Use Case Menghapus Skema Penilaian PHB-UC-01. Instruktur. Aplikasi menampilkan daftar semua skema penilaian yang ada pada sistem. Skenario Normal Aksi Aktor Respon Aplikasi Front-End Respon Autograder Engine 1. Memilih skema penilaian yang hendak dihapus. 2. Mengirim request skema penilaian yang hendak dihapus 3. Memeriksa apakah skema penilaian masih digunakan untuk menilai serahan tugas source code dalam sistem. 4. Menghapus skema penilaian yang diminta dari penyimpanan persisten 5. Menampilkan pesan bahwa skema penilaian telah dihapus. Skema penilaian sudah terhapus dari penyimpanan data persisten Kondisi Akhir Skenario Alternatif : Skema penilaian masih digunakan oleh serahan tugas tertentu Nomor Use Case Aktor Prekondisi
Aksi Aktor 1. Memilih skema penilaian yang hendak dihapus.
Respon Aplikasi Front-End
Respon Autograder Engine
2. Mengirim request skema penilaian yang hendak dihapus 3. Memeriksa apakah skema penilaian masih digunakan untuk menilai serahan tugas source code dalam sistem.
Kondisi Akhir
4. Menampilkan pesan kesalahan kepada instruktur Aplikasi menampilkan daftar skema penilaian yang ada pada sistem beserta pesan kesalahan.
D-xviii
D.2
Skenario Use Case Menilai Program
PHB-UC-02. Instruktur. Aplikasi menampilkan skema penilaian yang tersedia dalam sistem. Skenario Normal Aksi Aktor Respon Aplikasi Front-End Respon Autograder Engine 1. Memilih file serahan tugas atau source code dan definisi skema penilaian, lalu menekan tombol “Nilai Submisi”. 2. Meneruskan pilihan file serahan tugas atau source code dan definisi skema penilaian kepada Autograder Engine. 3. Memvalidasi pilihan skema dan source code pengguna 4. Memulai proses penilaian terhadap serahan tugas 5. Menyimpan laporan nilai yang dihasilkan Oracle dan WhiteboxMarkers ke dalam penyimpanan persisten Phobos. 6. Menampilkan pesan bahwa proses penilaian telah selesai dilakukan serta menampilkan laporan nilai kolektif Proses penilaian telah selesai dijalankan, laporan nilai tersimpan di dalam Kondisi Akhir penyimpanan data persisten Nomor Use Case Aktor Prekondisi
Skenario Alternatif : Skema penilaian atau source code tidak sesuai Aksi Aktor Respon Aplikasi Front-End Respon Autograder Engine 1. Memilih file serahan tugas atau source code dan definisi skema penilaian, lalu menekan tombol “Nilai Submisi”. 2. Meneruskan pilihan file serahan tugas atau source code dan definisi skema penilaian kepada Autograder Engine. 3. Memvalidasi pilihan skema dan source code pengguna 4. Menampilkan pesan kegagalan proses pengiriman submisi tugas. Aplikasi menampilkan form penilaian serahan tugas beserta pesan kesalahan. Kondisi Akhir
D-xix
D.3
Skenario Use Case Melihat Laporan Nilai
PHB-UC-03. Instruktur. Aplikasi menampilkan daftar semua laporan nilai yang ada pada sistem. Skenario Normal Aksi Aktor Respon Aplikasi Front-End Respon Autograder Engine 1. Memilih laporan nilai yang hendak dilihat. 2. Meneruskan permintaan laporan nilai berdasarkan serahan tugas 3. Mengambil laporan nilai untuk serahan tugas yang diminta dari penyimpanan persisten 4. Menampilkan laporan nilai serahan tugas Aplikasi menampilkan laporan nilai serahan tugas. Kondisi Akhir Nomor Use Case Aktor Prekondisi
D.4
Skenario Use Case Menghapus Laporan Nilai
PHB-UC-04. Instruktur. Aplikasi menampilkan daftar semua laporan nilai yang ada pada sistem. Skenario Normal Aksi Aktor Respon Aplikasi Front-End Respon Autograder Engine 1. Memilih laporan nilai yang hendak dihapus. 2. Meneruskan permintaan penghapusan laporan nilai kepada Autograder Engine 3. Menghapus laporan nilai dari penyimpanan persisten 4. Menampilkan laporan keberhasilan penghapusan Aplikasi menampilkan pesan keberhasilan dan daftar laporan nilai serahan Kondisi Akhir tugas. Nomor Use Case Aktor Prekondisi
D-xx
LAMPIRAN E Diagram Sequence Phobos E.1
Diagram Sequence Membuat Spesifikasi Tugas
E-xxi
E.2
Diagram Sequence Menilai Source Code
E-xxii
E.3
Diagram Sequence Melihat Laporan Nilai
E.4
Diagram Sequence Menghapus Laporan Nilai
E-xxiii
LAMPIRAN F Penyimpanan Data Persisten F.1
Penyimpanan Definisi Skema Penilaian
Untuk mendefinisikan XML definisi skema penilaian, digunakan sebuah Document Type Definition (DTD) yang diberi nama metaschema.dtd, yang isinya dapat dilihat pada Kode VI-1. Di dalam metaschema terdapat definisi struktur tiap elemen dari skema penilaian. Sebuah contoh file XML untuk definisi skema penilaian dapat dilihat pada Kode VI-2.
F-xxiv
Kode VI-8 Definisi Tipe Dokumen untuk Definisi Skema Penilaian
<markingschema id="1" timestamp="1206073347359" version="7"> Palindrome Testlisp <description>a small practice to test for palindromes <model>solutions/3266.lsp <markingtypes> 7887 7221 7368637 relative <description>passed (relative grading). <weight>0.65 <whitebox> slocNumberrelative <description>the longer the source length is, the less grade it will get. <weight>0.09 <whitebox> commentLinesrelative <description>the higher the comment line number is, the more grade it will get. <weight>0.08 <whitebox> identifierLengthrelative <description>the longer the identifiers names are, the more grade it will get. <weight>0.06
Kode VI-9 Sebuah contoh file XML untuk definisi skema penilaian
F-xxv
F.2
Penyimpanan Laporan Hasil Penilaian
Untuk mendefinisikan XML hasil penilaian, digunakan sebuah Document Type Definition (DTD) yang diberi nama indivreport, yang isinya dapat dilihat pada Kode VI-3. Sebuah contoh file XML untuk laporan hasil penilaian dapat dilihat pada Kode VI-4.
Kode VI-10 Definisi Tipe Dokumen untuk Laporan Hasil Penilaian
Kode VI-11 Sebuah contoh file XML untuk laporan hasil penilaian
F-xxvii
LAMPIRAN G Panduan Pembuatan Interpreter Phobos Pembuatan interpreter Phobos dapat dilakukan dalam beberapa tahap, yaitu spesifikasi fitur yang hendak diimplementasikan, definisi grammar dan pembangkitan kelas-kelas prosesor bahasa pemrograman, serta pembuatan kelas-kelas eksekusi. Penjelasan untuk tiap-tiap tahap akan dijelaskan pada Subbab-Subbab berikutnya.
G.1
Spesifikasi Fitur
Langkah pertama yang harus dilakukan adalah menentukan fitur-fitur apa saja yang akan diimplementasikan. Implementasi bahasa yang tersedia selalu memiliki banyak sekali fitur untuk mempermudah proses pembuatan program dalam dunia nyata, sementara fitur yang digunakan untuk pengajaran seringkali hanya subset kecil dari fitur yang tersedia pada bahasa pemrograman tertentu. Karena interpreter ini digunakan untuk kepentingan pengajaran, maka fitur yang diimplementasikan perlu didasarkan pada tujuan tersebut. Penentuan fitur-fitur yang hendak diimplementasikan harus didasari oleh konsep dan fitur-fitur apa saja yang hendak digunakan dalam pengajaran bahasa pemrograman tersebut.
Daftar fitur ini dapat disusun sebagai spesifikasi kebutuhan fungsional untuk referensi proses pengembangan
selanjutnya.
Fitur
dalam
bahasa
pemrograman
Lisp
yang
akan
diimplementasikan selengkapnya dijabarkan sebagai kebutuhan fungsional pada Subbab H.1, sementara fitur untuk bahasa pemrograman Pascal akan dijabarkan pada Subbab I.1.
Selain spesifikasi kebutuhan fungsional, pengembangan interpreter yang akan digunakan pada Phobos perlu mengikuti spesifikasi kebutuhan non fungsional yang ditetapkan secara
seragam terhadap semua bahasa pemrograman. Interpreter, terkait dengan penggunaannya dalam lingkungan pendidikan, harus memiliki nilai pedagogis. Semua interpreter yang hendak diimplementasikan harus mengimplementasikan fitur bahasa yang digunakan dalam materi pengajaran pemrograman. Interpreter juga diharapkan memberikan laporan kesalahan yang baik untuk umpan balik proses belajar siswa. Kebutuhan nonfungsional untuk interpreter Phobos dapat dilihat pada Tabel VI-2. Selain itu, dapat juga ditetapkan kebutuhan non
fungsional tambahan untuk interpreter bahasa tertentu jika dibutuhkan.
G-xxviii
Tabel VI-2 Kebutuhan Non Fungsional pada modul Interpreter Phobos Nomor SRS
Spesifikasi
I-SRS-NF-01
Utilitas
I-SRS-NF-02
Edukatif
G.2
Keterangan Interpreter harus mengimplementasikan semua fitur bahasa yang digunakan dalam pemrograman bahasa dasar Interpreter memiliki laporan kesalahan yang cukup deskriptif untuk membantu proses belajar pemrograman pada siswa.
Definisi Grammar dan Pembangkitan Kelas-Kelas Prosesor
Setelah penentuan fitur yang hendak diimplementasikan, langkah selanjutnya adalah menentukan grammar yang akan digunakan dan membangkitkan kelas-kelas prosesor bahasa pemrograman yang bersesuaian menggunakan Antlr. Grammar yang dibutuhkan ada tiga macam, yaitu grammar leksikal, grammar sintaksis dan tree grammar. Semua grammar ini harus ditulis menggunakan aturan sintaksis Antlr. Versi Antlr yang digunakan dalam Phobos adalah Antlr versi 2.7.7. Hal ini perlu diperhatikan, karena pada versi selanjutnya (>versi 3.0.0) aturan penulisan sintaks Antlr pada mengalami beberapa perubahan.
Grammar dapat ditulis berdasarkan spesifikasi bahasa yang hendak ditangani, atau menggunakan grammar bahasa pemrograman yang telah tersedia pada situs pengembang Antlr http://www.antlr.org. Grammar yang diperlukan pada tahap ini adalah grammar
leksikal dan sintaksis, sementara tree grammar akan dibutuhkan pada tahap selanjutnya. Grammar untuk membangkitkan parser dan lexer dapat menggunakan implementasi gramatik dari spesifikasi bahasa secara utuh, karena digunakan untuk menyusun pohon sintaks abstrak saja. Grammar yang digunakan untuk interpreter Lisp tercantum pada Subbab H.3 dan H.4, sementara grammar yang digunakan untuk interpreter Pascal tercantum pada Subbab I.3 dan I.4.
Penamaan token dan simbol-simbol untuk setiap tata bahasa juga harus menaati konvensi tertentu untuk konstruksi-konstruksi yang akan diukur besarannya, agar penilai analitik dapat bekerja secara generik untuk semua bahasa pemrograman. Token yang harus diseragamkan penamaannya antara lain untuk komentar, iterasi, percabangan, dan identifier. Penyeragaman ini dilakukan dengan cara memberikan prefiks nama token yang sama untuk simbol-simbol dengan arti semantik tertentu Konvensi penamaan prefiks antara lain untuk struktur kendali program (percabangan, iterasi, eksekusi prosedur atau fungsi) diberi prefiks ctrl_, untuk keyword yang merupakan penanda struktur tertentu diberi prefiks prep_, dan untuk operator diberi prefiks opr_.
G-xxix
Grammar leksikal dan sintaksis, menurut konvensi dalam Phobos, ditulis dalam satu file tunggal dengan nama bahasa pemrograman yang dimaksud dan diberi ekstensi .g. File spesifikasi grammar ini diletakkan dalam direktori subpackage langdef sesuai dengan nama bahasa pemrograman yang diharapkan. Lexer dan parser Phobos dapat dibangkitkan secara otomatis dengan menjalankan perintah : java tools.Antlr nama_bahasa.g
Dalam Phobos juga telah tersedia kode bantuan khusus untuk kompilasi grammar, yaitu dalam kelas CompileGrammar dalam subpackage langdef.
Selain itu, perlu dibuat sebuah kelas turunan dari Interpreter yang menurut konvensi Phobos
harus
dinamai
sebagai
NamaBahasaInterpreter.
Kelas
ini
harus
mengimplementasikan method loadSource, execute dan unloadSource. Setelah pembangkitan lexer dan parser, method loadSource, dan unloadSource dapat diimplementasikan untuk menjalankan proses penyusunan pohon sintaks abstrak.
G.3
Perancangan dan Implementasi Kelas-Kelas Eksekusi
Kelas-kelas eksekusi, sebagaimana disebutkan dalam Subbab 5.1.5.1, merupakan definisi behaviour dinamik program saat runtime. Dengan demikian, prasyarat yang harus dipenuhi untuk dapat merancang kelas eksekusi adalah pemahaman terhadap konsep-konsep semantik dari konstruksi-konstruksi sintaksis bahasa pemrograman.
Konsep-konsep semantik inilah yang kemudian diimplementasikan menjadi kelas eksekusi. Sebagai contoh, dalam bahasa pemrograman Pascal, terdapat konsep-konsep semantik seperti tipe dasar dan tipe bentukan, nilai dan variabel, prosedur dan fungsi, serta pernyataan dan ekspresi. Semua konsep ini harus diimplementasikan dalam bentuk kelas, masing-masing dengan karakteristiknya sesuai dengan spesifikasi bahasa pemrograman tersebut. Contoh implementasi konsep semantik ke dalam rancangan kelas telah diberikan dalam Subbab 5.1.5.2. Selain konsep-konsep semantik, beberapa kelas tambahan perlu dibuat untuk membantu proses operasional dan juga sebagai implementasi library internal program, agar eksekusi dapat berjalan dengan baik. Rancangan kelas-kelas eksekusi untuk interpreter Lisp pada Phobos selengkapnya akan dijelaskan dalam Subbab H.5 Lampiran H, dan untuk interpreter Pascal pada Subbab I.5 Lampiran I.
Pembangkitan
kelas-kelas
eksekusi
dipicu
dari
implementasi
TreeParser,
yang
dibangkitkan secara otomatis dari treegrammar oleh Antlr. Tree grammar dapat dibangun dari grammar sintaksis dengan sedikit modifikasi sintaks Antlr. Pada situs pengembang Antlr
G-xxx
juga terdapat beberapa grammar bahasa yang turut menyertakan tree grammar. Setiap aturan dalam tree grammar digunakan untuk mengatur objek eksekusi mana yang hendak dibangkitkan pada saat runtime. Modifikasi tree grammar untuk mengendalikan pembangkitan objek-objek eksekusi ini dapat dilakukan setelah seluruh implementasi kelas eksekusi selesai, namun dalam pengembangan nyata pada Phobos proses modifikasi tree grammar dan implementasi kelas eksekusi berjalan bersamaan.
Tree grammar, menurut konvensi dalam Phobos, ditulis dalam satu file tunggal dengan nama bahasa pemrograman yang dimaksud dan diberi ekstensi .tree.g. File spesifikasi grammar ini diletakkan dalam direktori subpackage langdef sesuai dengan nama bahasa pemrograman yang diharapkan. TreeParser Phobos dapat dibangkitkan secara otomatis menggunakan perintah yang sama dengan pembangkitan Lexer dan Parser.
Setelah pembangkitan treeparser dan seluruh kelas-kelas eksekusi selesai dibuat, method execute dapat diimplementasikan untuk menjalankan proses eksekusi program secara
keseluruhan. Untuk menjalankan penilaian, method execute mutlak harus memiliki parameter masukan dan keluaran yang berupa string. Implementasi interpreter harus secara khusus menangani proses i/o terhadap program dan mengubahnya menjadi parameter masukan dan keluaran terhadap kelas antarmuka interpreter.
G-xxxi
LAMPIRAN H Interpreter Lisp Phobos H.1
Spesifikasi Kebutuhan Fungsional
Fitur bahasa Lisp yang digunakan dalam pengajaran pemrograman dasar ini mengacu pada yang diktat yang ditulis oleh Ir. Sri Purwanti [PUR03]. Daftar kebutuhan fungsional yang akan diimplementasikan selengkapnya dapat dijabarkan sebagai kebutuhan fungsional pada Tabel VI-3. Tabel VI-3 Kebutuhan Fungsional Interpreter Lisp pada Phobos
Nomor SRS
Fitur Bahasa
I-LSP-SRS-F-01
Ekspresi Dasar
I-LSP -SRS-F-02
Ekspresi Kondisional
I-LSP -SRS-F-03
Ekspresi Rekursif
I-LSP -SRS-F-04
Koleksi Objek Berupa List
I-LSP -SRS-F-05
Ekspresi Lambda
I-LSP -SRS-F-06
Komentar
Keterangan Memiliki kemampuan untuk melakukan evaluasi terhadap ekspresi aritmatika melalui penggunaan operator aritmatika. Ekspresi aritmatika akan menghasilkan angka numerik. (+,-,*,/) Memiliki kemampuan untuk melakukan evaluasi terhadap ekspresi relasional melalui penggunaan operator relasional. Ekspresi relasional hanya menerima masukan numerik dan menghasilkan nilai boolean. (and, or, not) Memiliki kemampuan untuk melakukan evaluasi terhadap ekspresi relasional melalui penggunaan operator lojik/boolean. Ekspresi relasional hanya menerima masukan boolean dan menghasilkan nilai boolean. (=,/=,<,<=,>,>=) Memiliki kemampuan untuk melakukan evaluasi terhadap penamaan ekspresi untuk lingkup global dan lokal, beserta aplikasinya. Memiliki kemampuan untuk melakukan evaluasi terhadap pendefinisian fungsi beserta aplikasinya. (defun) Memiliki kemampuan untuk melakukan evaluasi terhadap fungsi dengan ekspresi kondisional yang menggunakan ataupun tidak menggunakan operator boolean. (if, cond) Mampu mengevaluasi fungsi yang menggunakan ekspresi rekursif (mengandung aplikasi terhadap fungsi tersebut). Mampu melakukan evaluasi terhadap fungsi yang menggunakan list sebagai ‘penampung’ koleksi objek dan melakukan manipulasi terhadap list tersebut dengan menggunakan fungsi dasar yang telah disediakan. (list, car, cdr, atom, null, listp, equals) Mampu melakukan evaluasi terhadap fungsi yang menggunakan ekspresi lambda beserta contoh aplikasinya. (lambda, funcall) Mampu menangani komentar untuk diabaikan dari proses pembangunan AST
H-xxxii
H.2
Batasan Implementasi Interpreter Lisp Phobos
Pada Subbab ini akan dibahas mengenai batasan fitur yang diimplementasikan untuk interpreter bahasa pemrograman Lisp. 1. Interpreter Lisp tidak mengimplementasikan tipe data selain atom berupa (karakter, string, integer, atau float) dan list. Tipe data lain seperti rasio (pecahan), bilangan kompleks, array, hashtable dan stream tidak diimplementasikan 2. Fungsi library yang disebutkan dalam diktat Lisp [PUR03] namun tidak diimplementasikan interpreter Lisp adalah fungsi-fungsi yang berkaitan dengan file eksternal.
H.3
Grammar Leksikal
Grammar Lisp yang digunakan dalam Interpreter Phobos dimodifikasi dari grammar LISP yang ditulis oleh Cynthia Kustanto [CYN07] dengan mengacu pada spesifikasi GNU Common Lisp [STE90]. Grammar ditulis dengan aturan penulisan grammar dalam Antlr yang menggunakan teknik parsing LL(1). Perubahan yang dilakukan untuk adaptasi ke dalam interpreter Phobos hanya dilakukan dalam hal penamaan token dan struktur saja untuk mengikuti konvensi penulisan grammar Phobos. Interpreter Lisp Phobos hanya mengimplementasikan subset kecil dari struktur sintaksis macro dan library GNU Common LISP, karena hanya subset kecil LISP yang digunakan dalam pengajaran pemrograman dasar pada S1-IF-ITB.
Untuk dapat melakukan analisis leksikal, sebuah grammar khusus didefinisikan agar dapat kemudian diubah menjadi Lexer oleh Antlr. LispLexer yang dibangkitkan oleh Antlr akan mengubah teks source code menjadi serangkaian token yang dapat dikenali oleh LispParser. Berikut ini merupakan rangkaian karakter yang valid pada bahasa pemrograman LISP disertai pola regular expression yang mendefinisikannya:
// -- konstanta leksikal const_t Æ T const_nil Æ NIL // -- keyword operasi boolean opr_not Æ not opr_and Æ and opr_or Æ or // -- keyword fungsi meta untuk pendefinisian fungsi baru struct_defun Æ defun func_funcall Æ funcall struct_lambda Æ lambda ctrl_return Æ return
H-xxxiii
// -- keyword operasi list opr_car Æ car opr_cdr Æ cdr opr_cadr Æ cadr opr_cddr Æ cddr // -- keyword fungsi library pada list func_list Æ list func_null Æ null func_cons Æ cons func_append Æ append func_atom Æ atom func_listp Æ listp func_equal Æ equal // -- keyword fungsi input/output func_print Æ print func_read Æ read // -- keyword struktur perulangan ctrl_dotimes Æ dotimes ctrl_when Æ when ctrl_loop Æ loop ctrl_do Æ do // -- keyword struktur percabangan ctrl_if Æ if ctrl_cond Æ cond // -- keyword operasi variabel opr_let Æ let opr_setq Æ setq // -- keyword operasi numerik opr_plus Æ + opr_minus Æ opr_times Æ * opr_divide Æ / opr_exp Æ exp // -- keyword operasi relasional opr_equals Æ = opr_nequal Æ /= opr_lthan Æ < opr_gthan Æ > opr_lteq Æ <= opr_gteq Æ >= // -- pola untuk literal karakter dan string // -- delimiter list delim_lparent Æ ( delim_rparent Æ ) // -- karakter spesial dalam Lisp opr_squote Æ ’ vbar Æ | numsign Æ # grave Æ ` comma Æ , colon Æ : // -- pola untuk literal dan identifier literal_char Æ #\(a-z,A-Z) literal_string Æ “ (a-z,A-Z) “ literal_numeric Æ (+|-) (literal_float | literal_integer) literal_float Æ (0-9)* . (0-9)+ (E (literal_integer))? literal_integer Æ (0-9)+ identifier Æ (a-z,A-Z) (a-z,A-Z,0-9)*
Kode VI-12 Grammar leksikal untuk bahasa LISP
H-xxxiv
H.4
Grammar Sintaksis
Rangkaian token yang telah dihasilkan oleh LispLexer akan kemudian disusun oleh LispParser ke dalam suatu pohon sintaks abstrak. Agar dapat menyusun pohon sintaks abstrak, sebuah grammar khusus didefinisikan agar dapat kemudian diubah menjadi Parser oleh Antlr. LispParser yang dibangkitkan oleh Antlr akan mengubah rangkaian token menjadi pohon sintaks abstrak dalam bentuk kelas DetailAST yang kemudian akan digunakan dalam proses interpretasi oleh LispObjectStream. Pada grammar Lisp terdapat sembilan aturan produksi simbol nonterminal saja.
Rangkaian aturan produksi dalam grammar ini kemudian digunakan untuk menginstruksikan instansiasi kelas-kelas runtime. Sebagaimana telah dibahas pada Subbab 4.4, aturan grammar juga akan menentukan desain kelas-kelas perancangan kelas-kelas runtime, karena kelas runtime merupakan instansiasi dinamik dari konstruksi pohon sintaks abstrak dan juga representasi library bahasa pemrograman yang terkait. Diagram kelas untuk interpreter Lisp Phobos dapat dilihat pada Gambar VI-2.
Gambar VI-2 Diagram kelas perancangan Interpreter Lisp Phobos Pada Tabel VI-4 terdapat daftar kelas yang digunakan pada interpreter Lisp dan masingmasing aturan produksi yang menghasilkan kelas tersebut. Beberapa kelas yang tercantum pada daftar kelas merupakan kelas turunan yang tidak ditunjukkan pada diagram kelas untuk menyederhanakan tampilan diagram. Kelas-kelas tersebut merupakan inner class yang tidak tidak dipisahkan dari kelas file induknya. Pada interpreter Lisp terdapat 42 kelas untuk eksekusi kode (dengan 27 kelas untuk implementasi library).
Kelas-kelas eksekusi dalam bahasa Lisp terbagi ke dalam beberapa kelompok : kelompok struktural, yang merepresentasikan entitas dalam Lisp (atom, list, atau literal); kelompok
H-xxxvi
operasional yang bersifat sebagai pembantu dalam proses eksekusi (LispLibrary sebagai referensi library dan simbol); serta kelas-kelas library yang mengimplementasikan fungsi internal atau macro dalam Lisp.
Tabel VI-4 Daftar kelas perancangan interpreter Lisp Phobos No
