BAB V PERANCANGAN MOXIE Bab ini berisi penjabaran dari hasil perancangan Moxie. Pembahasan pada bab ini mencakup perancangan arsitektur dan model skenario untuk Moxie. Model skenario merupakan produk dari fase perancangan untuk siklus 1, sedangkan arsitektur merupakan produk dari siklus 2. Secara umum, produk dari fase perancangan ini disebut sebagai blueprint atau solution model dari Moxie.
5.1 Perancangan Arsitektur Perancangan arsitektur sangat dipengaruhi oleh stakeholder. Stakeholder utama yang dinilai sangat terkait dengan pengembangan Moxie adalah pengguna dan pihak pengembang. Namun, dalam konteks pengembangan Moxie, perancangan arsitektur ditujukan terutama bagi pihak pengembang selanjutnya. Rancangan arsitektur yang dihasilkan diharapkan dapat menjadi panduan atau alat untuk memahami bagaimana komponen sistem dibangun dan atribut kualitas apa saja yang perlu diperhatikan. Hasil identifikasi atribut kualitas ini dijabarkan lebih lanjut dalam subbab 5.1.1.
5.1.1 Pemilihan Atribut Kualitas Pada dasarnya, pembangunan sebuah sistem yang ideal sebaiknya dapat mempertimbangkan seluruh atribut kualitas yang ada. Namun, Brosseau [BRO07] menyatakan bahwa tidak mungkin (atau sangat sulit) untuk memenuhi seluruh atribut yang ada sekaligus. Selain itu, tidak semua atribut memiliki relevansi terhadap sistem yang dirancang [BRO07]. Oleh sebab itu, dalam siklus pengembangan Moxie saat ini, akan dipilih dua atribut kualitas untuk ditelaah lebih lanjut, yaitu modifiability dan reusability. 5.1.1.1 Modifiability (Kemudahan Modifikasi) Moxie merupakan sebuah sistem yang kompleks karena dibangun atas sejumlah komponen yang berkoordinasi untuk menyediakan layanan bagi pengguna. Kompleksitas ini dapat menyebabkan sistem sulit untuk diubah. Padahal dalam pengembangannya, akan terdapat sejumlah kondisi yang menyebabkan Moxie harus mampu mengakomodasi perubahan, misalnya koreksi terhadap bug atau perubahan spesifikasi oleh pengguna. Selain itu, spesifikasi kebutuhan Moxie yang didefinisikan pada tahap pengembangan ini sendiri belum lengkap dan metodologi prototyping memungkinkan terdefinisinya sejumlah spesifikasi kebutuhan baru di masa mendatang.
V-1
V-2 Adanya kebutuhan untuk menjadikan sistem adaptif terhadap perubahan atau penambahan komponen menyebabkan modifiability perlu dipertimbangkan sebagai atribut kualitas dalam perancangan blueprint sistem. Dalam proses menganalisis atribut ini ada tiga hal yang perlu didefinisikan lebih lanjut, yaitu: 1. Dari hasil perancangan arsitektur sistem perlu didefinisikan modifikasi pada level apa yang dapat diakomodasi oleh sistem. 2. Dari hasil perancangan arsitektur perlu didefinisikan jenis komponen apa yang akan terlibat dalam modifikasi – apakah berupa komponen hardware atau software. 3. Dari hasil perancangan arsitektur perlu didefinisikan konteks modifikasi yang dapat dilakukan terhadap sistem – apakah terjadi di masa pengembangan atau saat runtime sistem. 5.1.1.2 Reusability (Kemudahan untuk Digunakan Kembali) Sesuai dengan tahapan dalam metodologi prototyping, pengembangan Moxie dapat dilakukan secara berkelanjutan, artinya setelah sebuah produk dihasilkan, Moxie masih mungkin untuk terus dikembangkan sehingga menghasilkan produk versi berikutnya. Menggunakan kembali komponen dari produk sebelumnya dapat mereduksi waktu dan biaya. Berdasarkan pertimbangan tersebut, maka reusability menjadi atribut yang perlu dipertimbangkan dalam rancangan arsitektur Moxie. Reusability sendiri sesungguhnya merupakan kasus khusus dari modifiability, meskipun jarang disebutkan sedemikian rupa [BAS98]. Membangun sistem sehingga mudah dimodifikasi akan berakibat pada peningkatan reusability [BAS98]. Hal ini menjadi alasan lain mengapa reusability menjadi atribut lain yang perlu dipertimbangkan bersamaan dengan modifiability. Ada dua hal yang perlu dianalisis lebih lanjut dari atribut reusability, yaitu: 1. Dari hasil perancangan arsitektur perlu didefinisikan level komponen apa yang dapat digunakan kembali – apakah berupa kelas, fungsi, proses, dan sebagainya. 2. Dari hasil perancangan arsitektur perlu diperhatikan batasan dari komponen yang dapat digunakan kembali – apakah dapat digunakan kembali secara penuh (full reuse) atau sebagian (half reuse).
5.1.2 Solusi Arsitektur Moxie Ada dua atribut kualitas yang menjadi spesifikasi dalam arsitrektur Moxie, yaitu modifiability dan reusability. Beberapa strategi yang digunakan agar Moxie dapat mencapai atribut tersebut dapat dijabarkan sebagai berikut:
V-3 1. Membagi sistem menjadi sejumlah modul. Modularitas sistem harus cukup sederhana dan jelas sehingga komponen sistem mudah dipahami, dan dengan demikian, mudah untuk dimodifikasi atau digunakan kembali. 2. Menyembunyikan detail informasi setiap komponen (information hiding) dengan cara enkapsulasi. Setiap modul menyediakan sekumpulan prosedur yang dapat dipanggil oleh modul lain. Prosedur ini memungkinkan terjadinya komunikasi intermodul. Selain prosedur ini, detil informasi dari setiap modul disembunyikan hanya untuk modul tersebut. Strategi semacam ini menjadikan sebuah modul independen terhadap modul lainnya baik dari segi modifikasi maupun kemampuan untuk digunakan kembali. Ringkasan dari penjabaran di atas dapat dilihat pada Tabel V-1. Tabel V-1 Strategi untuk Mencapai Atribut Kualitas Moxie
Atribut kualitas Modifiability Reusability
Strategi untuk mencapai atribut kualitas 1. Modularitas 2. Information hiding
Agar sejalan dengan strategi yang telah ditetapkan, solusi arsitektur Moxie akan direpresentasikan dalam tiga struktur, yaitu module structure, uses structure, dan data flow. Module structure dipilih untuk memperlihatkan bagaimana sistem didekomposisi menjadi sejumlah modul. Struktur ini menjelaskan fungsi setiap modul dan bagaimana suatu modul dibagi menjadi sejumlah submodul. Module structure mendeskripsikan relasi antar komponen selama masa pengembangan sistem. Tujuan yang ingin dicapai dari struktur ini adalah membangun arsitektur sistem yang mendukung modularitas. Uses structure digunakan untuk mengilustrasikan bagaimana ketergantungan antar modul saat proses runtime. Unit dari struktur ini adalah modul. Modul A dikatakan menggunakan (use) modul B jika di dalam modul B terdapat prosedur ataupun data yang dapat menjamin modul A berjalan sesuai spesifikasi. Data flow dipilih untuk menunjukkan data apa saja yang ditransmisikan di antara modul. Unit dari struktur ini adalah modul yang berhubungan dengan modul lain melalui relasi aliran data. Bersamaan dengan use structure, struktur ini menunjukkan arsitektur sistem saat proses runtime, khususnya dalam aspek aliran data. Melalui uses structure dan data flow, dapat diperoleh gambaran apakah suatu modul mengakses modul yang lain, dan jika hal tersebut terjadi, maka informasi ini dapat menjadi modal bagi pengembang untuk menentukan detil apa saja yang dapat diakses dan perlu
V-4 disembunyikan dari sebuah modul. Hal ini terkait dengan information hiding yang menjadi strategi pencapaian atribut kualitas. Ringkasan dari uraian mengenai pemilihan struktur arsitektur dapat dilihat pada Tabel V-2. Tabel V-2 Pemilihan Struktur Arsitektural Moxie
Struktur Module structure
Unit Struktur Modul
Uses structure
Modul
Data flow
Modul
Relasi Antar Unit Merupakan submodul dari (is a submodule of); berbagi informasi dengan (share a secret with) Dapat menggunakan (is allowed to use) Dapat mengirimkan data ke (may-send-datato)
Yang Dijelaskan oleh Struktur Ini 1. Dekomposisi sistem menjadi sejumlah modul 2. Menunjukkan relasi antara modul dengan submodul, relasi antar modul selama masa pengembangan sistem Menunjukkan relasi penggunaan antar modul saat runtime sistem Menunjukkan relasi data antar modul saat runtime sistem
5.1.2.1 Module Structure Berdasarkan fungsionalitas dan tanggung jawabnya, struktur Moxie dibagi menjadi lima modul, yaitu: modul antarmuka, akses dan autentikasi, aplikasi, middleware, dan repositori. Dalam subbab ini akan dijabarkan mengenai deskripsi dan tanggung jawab setiap modul. MODUL 1: ANTARMUKA Merupakan modul yang berhubungan langsung dengan pengguna. Tugas utama dari modul ini adalah menerima input dari pengguna dan memberikan output dalam representasi yang sesuai. Pembagian submodul pada modul antarmuka harus disesuaikan dengan modul aplikasi dan modul repositori. Mengenai hal ini akan dijelaskan lebih lanjut di dalam pembahasan mengenai modul aplikasi. MODUL 2: AKSES DAN AUTENTIKASI Merupakan modul yang terkait dengan pengaturan hak akses, session, dan autentikasi pengguna. Tugas utama dari modul ini adalah mengecek validitas pengguna dalam mengakses layanan yang disediakan oleh Moxie. Modul akses dan autentikasi berhubungan dengan keamanan sistem, khususnya masalah pengaksesan sistem oleh pengguna yang berhak. Pendekatan yang digunakan sebagai solusi dalam domain ini dapat dijabarkan sebagai berikut: 1. Setiap kelompok pengguna memiliki deskripsi hak akses masing-masing. Deskripsi hak akses setiap pengguna disimpan oleh sistem di dalam repositori.
V-5 2. Proses autentikasi dimaksudkan untuk mengecek apakah pengaksesan suatu layanan oleh pengguna sudah sesuai dengan haknya. Oleh sebab itu, sistem melakukan proses autentikasi setiap kali pengguna akan mengakses suatu layanan. Untuk kebutuhan proses autentikasi, sistem perlu mengakses deskripsi hak akses pengguna di repositori. Proses pengaksesan repositori sendiri harus dilakukan melalui API yang terdapat di modul middleware. MODUL 3: APLIKASI Merupakan modul yang terdiri atas ’mesin’ utama dari layanan yang membangun Moxie. Tugas utama dari modul aplikasi adalah menyediakan layanan yang tepat berdasarkan kebutuhan pengguna. Aplikasi yang disediakan oleh Moxie merupakan representasi teknologi dari spesifikasi yang disediakan oleh sistem. Spesifikasi ini sendiri telah dijabarkan sebagai use case dalam subbab 4.3.4. Seperti yang telah dijelaskan pada subbab 4.3.4, use case pada Moxie dapat dikelompokkan ke dalam empat kategori utama, yaitu: use case yang mengakomodasi layanan untuk knowledge creation, knowledge retention, knowledge sharing, dan knowledge utlization. Sebuah use case juga dapat dikelompokkan ke lebih dari satu kategori. Berdasarkan uraian di atas, dapat dinyatakan bahwa pendefinisian aplikasi pada Moxie dilakukan berdasarkan use case. Dalam subbab ini tidak akan dijelaskan lebih rinci mengenai contoh aplikasi yang dapat digunakan untuk mengimplementasikan Moxie. Namun, akan dijabarkan mengenai alternatif bentuk aplikasinya saja. Hal ini dapat dilihat pada Tabel V-3. Sedangkan untuk contoh dari setiap bentuk aplikasi yang ada, terdapat sejumlah referensi yang dapat dibaca, salah satunya adalah [TIW00]. Modul aplikasi berperan sebagai ’mesin’ utama yang menyediakan layanan, sedangkan modul antarmuka adalah representasi layanan yang berinteraksi langsung dengan pengguna. Data-data yang terkait dengan suatu layanan perlu disimpan di dalam repositori. Berdasarkan hubungan antara ketiga modul tersebut, maka pendefinisian submodul pada modul aplikasi harus disesuaikan dengan modul antarmuka dan modul repositori. Sebagai contoh, jika pada Moxie telah ditetapkan untuk mengimplementasikan aplikasi berupa blog, maka pada masing-masing modul aplikasi, modul antarmuka, dan modul repositori perlu dibangun submodul blog.
V-6 Tabel V-3 Alternatif Bentuk Aplikasi untuk Layanan yang Disediakan Moxie
Proses Aliran Pengetahuan yang Diakomodasi
Spesifikasi Moxie Berdasarkan Use Case
Alternatif Bentuk Aplikasi
Mencari dokumen TA
Knowledge creation
Information retrieval
Mencari sumber belajar di World Wide Web
Knowledge creation
Mesin pencari (search engine)
Melakukan korespondensi
Knowledge creation, knowledge utilization
Email, newsgroup (forum), text chat, audio / video conference, expertise yellow pages
Mengkonsumsi sumber belajar secara aktif
Knowledge creation
Document reader dengan perangkat tambahan untuk manipulasi isi dokumen
Mengelola catatan/ringkasan
Knowledge creation, knowledge retention
Mapping tools, aplikasi content management
Mengarsipkan hasil belajar untuk publik
Knowledge sharing
Aplikasi content management, blog, personal website
Melakukan upload dokumen TA
Knowledge sharing
Aplikasi content management, file uploader
Mengelola dokumen TA
Knowledge sharing
Aplikasi content management
Mengelola anggota
--
Personal management, user profiling
Validasi pengguna
--
(ditangani oleh layer akses dan autentikasi)
MODUL 4: MIDDLEWARE Modul ini mendefinisikan middleware yang digunakan dalam Moxie. Middleware adalah teknologi yang menyediakan layanan yang memungkinkan beberapa proses, aplikasi atau program berjalan pada satu atau sejumlah mesin yang terhubung sehingga memungkinkan terjadinya pertukaran data atau pesan. Dalam arsitektur Moxie, middleware diharapkan dapat menjadi jembatan atau antarmuka untuk komunikasi antar submodul aplikasi, modul aplikasi dengan repositori, dan modul akses dan autentikasi dengan repositori. MODUL 5: REPOSITORI Merupakan modul yang terdiri atas sejumlah media penyimpanan, bisa berupa basis data relasional, file data, data warehouse, dan sebagainya. Pemilihan bentuk repositori dapat didefinisikan berdasarkan kebutuhan. Namun, perlu diingat bahwa keragaman bentuk repositori tentunya akan meningkatkan kompleksitas dalam penyimpanan dan pengaksesan data sehingga membutuhkan perancangan lebih lanjut untuk membangunnya.
V-7 Untuk memperjelas uraian mengenai struktur modul pada arsitektur Moxie, dibuat Gambar V-1. Melalui gambar ini dapat dilihat bahwa Moxie dibangun oleh lima modul utama. Setiap modul dapat dibangun oleh sejumlah submodul. Pada modul antarmuka, aplikasi, dan repositori, pendefinisian sebuah submodul harus dibuat sinkron, artinya jika pada modul aplikasi terdapat submodul X, maka pada modul antarmuka dan modul repositori juga perlu dibangun submodul X.
Gambar V-1 Module Structure Moxie
Berdasarkan uraian di atas, maka dapat dilihat bahwa setiap submodul memiliki spesifikasi pekerjaan yang jelas. Komunikasi antar submodul hanya dapat dilakukan melalui prosedur yang memang disediakan oleh sebuah submodul agar dapat diakses oleh submodul lainnya (prosedur ini disebut dengan call procedure [BAS98]). Sedangkan, detil informasi lainnya disembunyikan hanya untuk submodul tersebut. Dengan demikian, pengaruh dari modifikasi suatu submodul hanya perlu dilihat dari call procedure yang dimanfaatkan oleh submodul lain, dan jika tidak ada masalah dalam hal tersebut, maka perubahan pada submodul tersebut tidak akan mempengaruhi submodul lainnya. 5.1.2.2 Uses Structure dan Data Flow Uses structure menjelaskan relasi ‘dapat menggunakan’ atau is-allowed-to-use dari sekumpulan modul yang membangun Moxie. Relasi ini dapat dijelaskan melalui Tabel V-4. Tabel V-4 Spesifikasi Relasi Use pada Arsitektur Moxie
Nama Modul Antarmuka Akses dan Autentikasi Aplikasi Middleware Repositori
…dapat menggunakan modul … Akses dan Autentikasi, Aplikasi Middleware Middleware Aplikasi, Repositori --
Aspek lain yang perlu diperlihatkan dari arsitektur sistem saat runtime adalah aliran data atau data flow. Jika relasi use dan aliran data diilustrasikan ke dalam sebuah gambar, maka
V-8 komponen sistem dapat ditunjukkan sebagai kumpulan layer. Setiap modul direpresentasikan sebagai sebuah layer dan dihubungkan dengan layer lainnya seperti yang tampak pada Gambar V-2. Garis solid menunjukkan relasi use sedangkan garis putus-putus berlabel menunjukkan aliran dan nama data yang ditransmisikan antar modul. Adapun penjelasan mengenai aliran data dari arsitektur pada Gambar V-2 dapat dijabarkan secara garis besar sebagai berikut: 1. Layer antarmuka menerima data berupa input dari pengguna dan memberikan output dalam representasi yang sesuai. Input dari pengguna diubah ke dalam format yang sesuai dan ditransmisikan ke layer akses dan autentikasi. 2. Input terformat dari layer antarmuka diproses oleh layer akses dan autentikasi sehingga menghasilkan data hasil autentikasi. Untuk memperoleh hasil ini, layer akses dan autentikasi harus mengakses deskripsi hak akses pengguna di repositori. Pengaksesan layer repositori sendiri hanya dapat dilakukan melalui layer middleware. Itu sebabnya terjadi aliran data dari layer akses dan autentikasi ke layer middleware, dan sebaliknya. 3. Input terformat dari layer antarmuka juga ada yang diteruskan ke layer aplikasi. Selama proses runtime, layer aplikasi sendiri akan membutuhkan data dari atau mengirim data ke repositori. Karena pengaksesan layer repositori hanya dapat dilakukan oleh layer middleware, maka akan terjadi aliran data dari layer aplikasi ke layer Middleware untuk selanjutnya diteruskan ke layer repositori, dan sebaliknya. 4. Layer middleware tidak hanya menghubungkan layer aplikasi dengan repositori, namun juga menyediakan antarmuka jika sebuah submodul di layer aplikasi perlu berkomunikasi dengan submodul lain di layer tersebut. Dengan demikian, layer middleware menjembatani aliran data dari dan ke layer aplikasi itu sendiri. Seluruh layer yang membangun arsitektur Moxie terintegrasi melalui Web. Dengan demikian, client dapat ditempatkan terpisah dengan server dan client yang satu dapat berkomunikasi dengan client yang lain melalui jaringan.
V-9
Gambar V-2 Arsitektur Layer yang Menggambarkan Uses Structure dan Data Flow Moxie
5.1.3 Kesimpulan atas Solusi Arsitektural Moxie Berdasarkan solusi arsitektural Moxie yang dijabarkan dalam subbab 5.1.2 dapat dijabarkan beberapa kesimpulan sebagai berikut: 1. Prinsip modularitas dan information hiding menjadikan sistem Moxie adaptif terhadap modifikasi di level submodul. Perubahan di suatu submodul setidaknya hanya perlu memperhatikan call procedure yang diakses oleh submodul lainnya, dan jika tidak ada masalah dalam hal tersebut, maka perubahan pada submodul yang bersangkutan seharusnya tidak mengganggu submodul lain. Hal ini menunjang tercapainya modifiability sistem. Argumen yang sama berlaku terhadap atribut reusability. Karena
V-10 submodul yang satu independen terhadap yang lain, maka pemanfaatan kembali submodul tersebut dalam pembangunan produk versi selanjutnya sangat dimungkinkan. 2. Sistem layer dalam arsitektur Moxie lebih berbicara kepada rancangan dari sisi perangkat lunak (software). Arsitektur ini belum memperlihatkan bagaimana keterlibatan komponen mekanis (hardware) di dalam sistem. 3. Aristektur Moxie menunjukkan struktur sistem baik dalam konteks pengembangan maupun saat runtime sistem. Module structure mendeskripsikan relasi antar modul yang membangun sistem dalam konteks pengembangan. Sedangkan, relasi antar komponen sistem saat proses runtime ditunjukkan melalui uses structure dan data flow. 4. Karena setiap komponen memiliki deskripsi fungsionalitas yang jelas, maka komponen dapat digunakan kembali pada sistem lain, baik Moxie atau bukan. Proses reuse dapat dilakukan terhadap sebuah submodul saja, misalnya Database Connection API dari modul middleware, atau rentetan submodul dari beberapa modul sekaligus, misalnya penggunaan kembali submodul blog dari modul aplikasi perlu mempertimbangkan penggunaan submodul blog dari modul antarmuka dan modul repositori. Hal ini dapat disesuaikan dengan kondisi sistem yang akan melakukan reuse.
5.1.4 Rekomendasi terhadap Solusi Arsitektural Moxie Terhadap solusi arsitektural Moxie yang telah dijabarkan dalam subbab 5.1.2, ada beberapa hal yang perlu dipertimbangkan sebagai rekomendasi. Rekomendasi ini dapat menjadi masukan jika rancangan arsitektur akan diterapkan atau disempurnakan lagi di masa mendatang. Penjabaran dari rekomendasi tersebut dapat diuraikan sebagai berikut: 1. Untuk mendukung modifiability sistem, rancangan arsitektur dan implementasi Moxie sebaiknya mempertimbangkan penggunaan bahasa pemrograman yang berorentasi objek. Dengan demikian, perubahan pada sebuah komponen yang mungkin berpengaruh terhadap komponen lain lebih mudah diakomodasi (misalnya dengan membuat antarmuka untuk komponen tersebut). 2. Sebuah sistem yang kompleks membutuhkan integritas agar komponen sistem dapat berkoordinasi dengan baik. Terkait dengan pengembangan Moxie di masa mendatang, integrability merupakan atribut yang perlu dipertimbangkan dalam perbaikan rancangan arsitektur Moxie. Konteks pembahasan yang dicakup dalam atribut ini berhubungan dengan mekanisme agar komponen sistem yang telah dimodifikasi atau akan digunakan kembali (reuse) dapat diintegrasikan ke dalam sistem yang ada. 3. Penambahan modul atau layer pada arsitektur Moxie perlu dipertimbangkan untuk memperluas layanan yang disediakan Moxie. Sebagai contoh, Moxie ingin dilengkapi dengan kemampuan untuk beradaptasi dengan kebutuhan personal pembelajar,
V-11 melakukan klasifikasi sumber belajar menurut ontologi tertentu, atau memberikan rekomendasi sumber belajar sesuai minat pembelajar. Dengan demikian, pada Moxie perlu dipertimbangkan adanya penambahan sebuah modul atau layer yang menangani masalah inteligensia sistem. Namun, penambahan modul atau layer ini perlu memperhatikan uses structure dan data flow dari arsitektur yang telah ada. 4. Pemilihan struktur arsitektural sangat tergantung pada sudut pandang yang ingin ditunjukkan oleh arsitektur. Dalam pengembangan selanjutnya, perancangan sistem telah mencapai tahap yang lebih detil sehingga perlu mempertimbangkan struktur lain untuk merepresentasikan sistem, misalnya: control flow, logical structure, atau class structure.
5.2 Perancangan Skenario Skenario digunakan untuk mengilustrasikan bentuk interaksi yang terjadi antara pengguna dan sistem. Dalam perancangan ini, skenario akan dirancang berdasarkan use case yang telah diidentifikasi pada subbab 4.3.4. Tahapan yang dilakukan dalam perancangan skenario Moxie dapat dijabarkan sebagai berikut: 1. Memetakan metodologi proses belajar pada Gambar IV-3 menjadi sebuah model skenario utama proses belajar. 2. Mengidentifikasi use case prioritas dalam perancangan skenario. Hal ini dilakukan dengan melihat apakah use case yang bersangkutan terkait erat dengan proses belajar. Hasil identifikasi ini dapat dilihat pada Tabel V-5. 3. Memetakan use case prioritas ke dalam proses yang ada di model skenario utama proses belajar. Oleh sebab itu, pada setiap simbol proses di model skenario akan terdapat simbol yang menyatakan daftar use case yang tercakup dalam proses tersebut. Hasil perancangan model skenario belajar ini dapat dilihat pada Gambar V-3. 4. Membuat deskripsi skenario untuk masing-masing use case prioritas. Hasil deskripsi skenario ini dapat dilihat pada Lampiran D. Deskripsi skenario digunakan untuk menunjukkan bagaimana interaksi antara aktor dan sistem. Dalam pengembangan Moxie saat ini, deskripsi skenario Moxie dirancang dalam batasan tertentu, yaitu: a. Skenario yang dirancang adalah skenario normal. b. Skenario yang dirancang bersifat umum atau belum berbicara spesifik terhadap bentuk aplikasi yang akan digunakan, seperti: apakah teknologi untuk korespondensi akan berupa email atau video conference, apakah pengguna dapat membuat catatan dalam bentuk tulisan saja atau juga simbol/gambar, dan sebagainya. Oleh sebab itu, di masa mendatang, skenario yang dihasilkan masih mungkin mengalami penyesuaian terhadap teknologi yang akhirnya dipilih untuk diimplementasikan pada Moxie.
V-12
Tabel V-5 Identifikasi Use Case Prioritas dalam Perancangan Skenario
Kode Use Case UC-01
Mencari Dokumen TA
UC-02
Mencari Sumber Belajar di World Wide Web
UC-03
Melakukan Korespondensi
UC-04
Mengkonsumsi Sumber Belajar Secara Aktif
UC-05
Mengelola Catatan/Ringkasan
UC-06
Mengarsipkan Hasil Belajar untuk Publik
UC-07
Melakukan Upload Dokumen TA
UC-08
Mengelola Dokumen TA
UC-09
Mengelola Anggota
--
UC-10
Validasi Pengguna
--
Use Case
Tergolong ke dalam Use Case Prioritas
Catatan : Simbol ( ) menyatakan use case yang menjadi prioritas dalam perancangan skenario, yaitu use case yang tergolong ke dalam model skenario utama proses belajar
V-13
! $ !"#
%
!$
" !%
!
!$#
!&#
!'
#
#
!$#
!'#
!(
"
" !)#
!*
!
"
Gambar V-3 Model Skenario Utama Belajar Tugas Akhir (TA)
