Salah satu yang membuat jengkel mahasiswa ketika mengerjakan skripsi/tugas akhir adalah tidak adanya standar yang harus diikuti, terutama tema-tema perancangan sistem dan pemrograman. Tetapi saat ini sepertinya mulai berkurang karena era online sudah merambah ke semua lini. Sumber-sumber informasi mudah dijumpai lewat variasi-variasinya seperti dalam bentuk blog, video, ebook, milis, grup dan lain-lain. Akibat tidak adanya standar, sering dijumpai perdebatan yang tidak perlu ketika sidang skripsi. Bahkan ada yang curhat ketika seorang mahasiswa dibimbing oleh dua pembimbing berbeda yang tidak seia-sekata. Disuruh oleh pembimbing A merubah mengikuti petunjuknya tetapi oleh pembimbing B diminta hal sebaliknya.
Khusus analisis dan disain basis data sudah dibahas pada postingan sebelumnya, yakni mencari sumber informasi tentang rancangan yang sudah sering dibuat orang. Pola-pola disain pun sudah umum ditemui, kita tidak perlu menemukan ide baru kecuali jika rancangan yang ingin dibuat khusus dengan karakteristik tertentu.
Standar Pemodelan Sistem
Sejak dulu, standar yang digunakan dalam pendidikan adalah buku referensi. Ketika beragumen, sebuah buku dijadikan rujukan akan kebenaran sebuah konsep. Masalah muncul ketika sebuah buku dianggap “kurang tepat” oleh pihak tertentu. Untuk cara aman biasanya akademisi menggunakan buku berstandar internasional. Hanya saja buku-buku jenis tersebut sulit dipahami oleh mahasiswa-mahasiswa kita, terutama para milenial-milenial yang lebih suka hal-hal yang praktis. Mereka butuh contoh-contoh kasus yang khusus yang ada di negara kita. Mau tidak mau buku-buku panduan berbahasa Indonesia yang ringkas sangat dibutuhkan. Masalah muncul ketika buku tersebut agak “kurang standar” walaupun sangat mudah dipahami. Oleh karena itu sebaiknya mahasiswa diajarkan melihat bentuk-bentuk standar resmi, misalnya untuk pemrograman berorientasi objek dapat dijumpai pada situs UML berikut.
Memang tidak ada orang yang memiliki pengetahuan lengkap akan suatu topik tertentu. Namun di era online, kita harus memanfaatkan fasilitas online tersebut. Amat disayangkan banyak dijumpai di jurnal-jurnal nasional penulisan diagram UML yang tidak mengikuti standar yang ada, padahal rancangannya bagus, hanya presentasi saja yang tidak mengikut standar. Bahayanya adalah, artikel tersebut dijadikan sitasi dan referensi sehingga artikel yang lain pun menjadi tidak mengikuti standar.
Contoh Kasus
Salah satu diagram UML yang paling banyak dibuat adalah diagram kelas dan use case. Bahkan saking seringnya use case digunakan ada istilah use case-driven. UML.org menyediakan unduhan versi terbaru untuk melihat standar yang ada. Standar di sini merupakan kesepakatan dari Object Management Group (OMG) dengan vendor-vendor perangkat lunak seluruh dunia. Jadi, jika kita berpatokan dengan situs resminya, pegangan kita menjadi kuat, jauh lebih kuat dibandingkan hanya berpegang pada buku referensi.
Gambar di atas merupakan salah satu contoh yang dibahas dalam UML.org yang dijumpai ketika membahas use case di halaman 643. Saya sendiri baru tahu kalau ada multiplicity dalam use case yang biasanya dijumpai pada diagram kelas. Perhatikan kesederhanaan yang ditampilkan. Sesuai fungsinya, use case memang diperuntukan sebagai penjelasan “apa” yang dilakukan sistem, bukannya “bagaimana”. Jadi jika rancangan use case kita berupa alur “bagaimana”, sudah dipastikan tidak sesuai dengan fungsi utama use case. Use case menggambarkan kewajiban apa saja yang harus diselesaikan programmer pada program yang diusulkan.
Contoh di atas mengharuskan programmer membuat fungsi-fungsi (dikenal dengan istilah functional requirement) dalam diagram use case di atas antara lain withdraw, transfer, deposit, register ATM, dan Read Log. Bagaimana dengan login? Silahkan tambahkan tapi jangan sampai berubah menjadi alur proses mendaftar Deposito dari login, registrasi, dll yang ujung-ujungnya ribet dan use case tidak memiliki fungsi utamanya. Silahkan jelaskan dengan diagram UML lainnya jika ingin detil, misalnya sequence atau activity diagram. Mungkin kita memiliki bentuk yang sedikit berbeda, misalnya tanpa multiplicity 0..1, 0..*, dll, tapi format garis tanpa anak panah perlu menjadi perhatian mengapa tidak ada panah di sana.
Perhatikan contoh lain bagaimana merinci suatu aktivitas dengan activity diagram di atas. Bagaimana fork dan join diimplementasikan dalam diagram aktivitas sebaiknya tetap mengacu standar. Sekian, silahkan kunjungi situs standar UML tersebut, semoga bisa membantu melerai pertengkaran di meja sidang skripsi/tugas akhir.
Rahmadya Trias Handayanto 