Model 1 Versus Model 2


Perbandingan Arsitektur Model 1 Dan Arsitektur Model 2 Dalam Pengembangan Sistem Informasi Akademik Berbasis Web

Bab 1
Pendahuluan

1.1 Latar Belakang

Sebuah arsitektur program atau sistem komputer merupakan struktur dari sistem, di mana terdiri dari komponen software, komponen hardware, dan hubungan di antaranya. Dalam perancangan sebuah arsitektur program sering terjadi masalah akibat sistem yang terlalu rumit. Masalah tersebut dapat dipecahkan oleh pembuat sistem dengan cara memilih struktur data dan algoritma pembuatan dengan benar, serta menggunakan konsep-konsep yang tepat.

Arsitektur program merupakan hal yang cukup baru dalam industri. Awalnya menyusun sebuah arsitektur program tidaklah diperhatikan oleh kebanyakan pembuat sistem, mereka tidak membuat keteraturan dalam pembuatan arsitektur, hal ini membuat lamanya waktu yang dibutuhkan untuk membuat dan mengembangkan sebuah sistem.

Beberapa tahun belakangan ini, untuk membuat arsitektur program digunakan kesamaan pola desain, gaya, bahasa deskripsi, dan logika resmi. Sebagai tindak lanjut karena tidak ada aturan yang resmi dan jelas mengenai hal ini, maka dalam pembuatan arsitektur program masih seperti kesatuan seni dan ilmu. Seni merupakan bagian dari sebuah arsitektur progam, karena saat membuat arsitektur, pembuat sistem harus berpikir tentang kemampuan sebuah software mengenai hal toleransi kesalahan, kecocokan, tahan uji, mudah dikembangkan, keamanan, dan mudah digunakan.

Dalam membuat program dengan menggunakan bahasa Java, dikenal 2 model arsitektur, yaitu Arsitektur Model 1 dan Arsitektur Model 2.

Arsitektur Model 1 merupakan sebuah arsitektur yang sangat sederhana, sebuah halaman interface langsung menangani sebuah proses ketika mendapat perintah dari user. Jika membutuhkan data dari database, halaman itu langsung mengakses database dan menampilkan hasilnya ke user.

Arsitektur Model 2 merupakan pengembangan dari Arsitektur Model 1. Dalam arsitektur ini sistem dibagi menjadi 3 lapisan yaitu Model, View, dan Controller. View merupakan interface yang berhubungan dengan user. Ketika View mendapat perintah dari user, Controller menunjuk View mana yang akan ditampilkan atau jika membutuhkan data dari database, Controller menunjuk Model mana yang akan mengakses data dari database yang kemudian akan ditampilkan oleh View.

Melalui penelitian ini diharapkan para pembuat sistem dapat lebih mengerti mengenai pentingnya arsitektur dalam pembuatan program. Khususnya mengerti perbedaan dari Arsitektur Model 2 dan Arsitektur Model 1. Arsitektur Model 2 merupakan terobosan baru dalam hal arsitektur program, yang merupakan pengembangan dari Arsitektur Model 1. Secara teori Arsitektur Model 2 lebih efektif dan efisien dari Arsitektur Model 1. Beberapa kelebihan Arsitektur Model 2, yaitu dapat menangani banyak View dengan menggunakan Model yang sama, sehingga mempermudah pemeliharaan, pengujian, pengembangan; lebih fleksibel dalam mendesain tampilan karena sistem dalam program terpisah dengan tampilan.

1.2 Perumusan Masalah

  1. Bagaimana membuat spesifikasi Sistem Informasi Akademik untuk membandingkan kedua model arsitektur?
  2. Bagaimana merancang dan mengimplementasikan rancangan tersebut dengan menggunakan kedua model arsitektur?
  3. Bagaimana menguji coba hasil dari implementasi tersebut untuk mendapatkan perbandingan antara kedua model arsitektur?

1.3 Tujuan Penelitian

  1. Membuat spesifikasi Sistem Informasi Akademik untuk membandingkan kedua model arsitektur.
  2. Merancang dan mengimplementasikan rancangan tersebut dengan menggunakan kedua model arsitektur.
  3. Menguji coba hasil dari implementasi tersebut untuk mendapatkan perbandingan antara kedua model arsitektur.

1.4 Batasan Masalah

Membandingkan Arsitektur Model 2 dan Arsitektur Model 1 dalam perancangan dan pengimplementasian Sistem Informasi Akademik berbasis web dengan menggunakan bahasa pemrograman Java dari sudut pandang pembuat sistem.

Hal-hal yang dibandingkan dalam penelitian ini yaitu alur jalannya sistem; waktu yang dibutuhkan dalam pembuatan dan pengembangan sistem; penerapan kerjasama tim; dan validasi data.

Bab 2
Landasan Teori

2.1 Java Web Arsitektur Model

Dalam membuat desain sistem informasi berbasis web dengan menggunakan Java, secara umum terdapat 2 model, yaitu Arsitektur Model 1 dan Arsitektur Model 2. (Ashmore, 2004)

Arsitektur Model 1 sangatlah sederhana. Sebuah permintaan akan ditujukan ke JSP atau Servlet dan kemudian JSP atau Servlet akan menangani semua kebutuhan dari permintaan, seperti proses permintaan, validasi data, logika bisnis, dan menciptakan jawaban. Alur Arsitektur Model 1 dapat dilihat di Gambar 2. 1. (Shenoy, 2004)

Secara teori Arsitektur Model 1 kurang dapat mendukung pembuatan program berskala besar, karena tidak dapat dihindarkannya fungsi-fungsi yang sama di setiap JSP. Arsitektur Model 1 juga membutuhkan ikatan antara lapisan bisnis dan lapisan presentasi. Mempersatukan lapisan bisnis dengan lapisan presentasi membuat susah untuk mengenalkan akses poin dari sebuah program.

Dengan terbatasnya Arsitektur Model 1, maka dikembangkanlah Arsitektur Model 2. Di Arsitektur Model 2 diterapkan Model View Controller untuk membagi presentasi dengan bagian lainnya. Dalam Arsitektur Model 2, View merupakan interface yang berhubungan dengan user. Ketika View mendapat perintah dari user, Controller menunjuk View mana yang akan ditampilkan atau jika membutuhkan data dari database, Controller akan menunjuk Model mana yang akan mengakses data dari database yang kemudian akan ditampilkan oleh View. Alur Arsitektur Model 2 dapat dilihat di Gambar 2. 2. (Shenoy, 2004)

2.2 Model View Controller

Model View Controller merupakan contoh Arsitektur Model 2. Dalam sebuah program komputer yang mempunyai jumlah data yang besar kepada pengguna, Model View Controller sangat berperan penting, karena Model View Controller membagi bagian program menjadi 3 bagian, yaitu

  1. Bagian pertama disebut dengan Model, yaitu bagian yang mempresentasikan data yang digunakan oleh aplikasi sebagaimana proses bisnis yang diasosiasikan terhadapnya. Dengan membaginya sebagai bagian terpisah, seperti penampungan data dan proses manipulasi, terpisah dari bagian lain aplikasi. Model juga dapat digunakan untuk mempresentasikan entity-entity yang terdapat di database.
  2. Bagian kedua disebut dengan View, bagian ini mengandung keseluruhan detail dari implementasi user interface. Disini, komponen grafis menyediakan presentasi proses internal aplikasi dan menuntun alur interaksi user terhadap aplikasi.
  3. Bagian terakhir disebut dengan Controller, bagian ini menyediakan detail alur program dan transisi layer, dan juga bertanggung jawab atas penampungan events yang dibuat oleh user dari View dan melakukan update terhadap komponen Model menggunakan data yang dimasukkan oleh user.

Dalam Model View Controller, alur aplikasi diatur oleh Controller. Controller bertugas untuk mendelegasikan Request, dalam hal ini HTTP Request ke sebuah Handler yang tepat. Handler sendiri tidak lebih dari sekumpulan logika yang digunakan untuk memproses Request. Dalam Struts, Handler ini dikenal dengan nama Action. Handler ini terikat dengan Model dan setiap Handler bertindak sebagai jembatan antara Request dan Model. Handler selanjutnya mengambil informasi yang diperlukan atas Request dari lapisan bisnis dan kemudian memberikannya ke Model. Model dalam Struts dinamakan sebagai ActionForm. Model ini dibentuk dari satu atau lebih JavaBean atau EJB. Controller kemudian melanjutkan proses menuju View. Dalam Struts, Controller dan Model ditentukan menggunakan file konfigurasi berbasis XML yang disebut dengan struts-config.xml. Alur sistem dengan menggunakan Struts dapat dilihat di Gambar 2. 3. (Goodwill, 2002)

2.3 Struts

Struts adalah seperangkat aturan atau framework yang berbasis Java yang digunakan untuk membangun sebuah aplikasi web. Inti teknologi Struts terdiri dari :

  1. Java Server Pages adalah teknologi yang digunakan untuk membangun aplikasi web yang melayani isi yang dinamik. Java Server Pages adalah komponen di sisi server yang dibangun dari HTML statik atau komponen XML, tag–tag yang spesifik untuk Java Server Pages, dan potongan kode Java optional yang disebut scriptlet. Java Server Pages digunakan sebagai lapisan presentasi dalam arsitektur web n-tier. Dalam framework Struts, Java Server Pages mewakili View dalam pola perancangan Model View Controller.
  2. Servlet memegang peranan besar dalam pengembangan aplikasi web. Servlet adalah solusi berbasis Java yang berjalan di dalam Java Virtual Machine. Karena Servlet berjalan di dalam Java Virtual Machine, Servlet menjadi teknologi yang sangat portable. Paradigma Request-Response yang ada dalam HTTP juga diterapkan dalam Servlet. Dalam arsitektur Struts, Servlet memegang peranan sebagai Controller.
  3. Custom tag libraries adalah fitur yang ampuh yang sesuai dengan konsep tersebut. Custom tag libraries mengijinkan programer Java untuk menuliskan kode yang menyediakan akses data dan layanan lainnya dalam model sederhana mirip eXtensible Markup Language.
  4. eXtensible Markup Language telah menyebar dalam pengembangan aplikasi web dan web service. Sekarang ini sulit untuk membangun sebuah aplikasi web tanpa berurusan dengan eXtensible Markup Language. eXtensible Markup Language merupakan salah satu teknologi yang luar biasa dalam menangani pertukaran data. eXtensible Markup Language digunakan untuk mewakili struktur dokumen dan data di web. File eXtensible Markup Language dapat disimpan atau dikirimkan antara dua buah aplikasi yang terhubung lewat jaringan. Pada dasarnya, file eXtensible Markup Language hanyalah dokumen berbasis teks biasa yang mengandung tag–tag khusus yang mewakili sebagian dari dokumen atau kumpulan data. Selain digunakan dalam menangani pertukaran data, eXtensible Markup Language sering digunakan dalam konfigurasi web dalam bentuk file web.xml dan digunakan dalam Struts unuk konfigurasi dalam bentuk struts-config.xml, yang digunakan untuk mengkonfigurasi semua aksi yang dapat dijalankan oleh aplikasi Struts. eXtensible Markup Language ini sangat penting terutama dalam membangun sebuah web service karena hampir seluruh operabilitas yang berjalan dalam web service menggunakan dokumen eXtensible Markup Language.
  5. Web server dan aplikasi memegang peranan dalam setiap aplikasi web. Sebuah web server menangani proses HTTP sementara web aplikasi menangani layanan lainnya. (Shenoy, 2004)

Pembagian Model View Controller dengan Struts dapat dilihat di Gambar 2. 4.

2.4 Hibernate

Hibernate merupakan salah satu dari Object Relational Mapping. Object Relational Mapping adalah sebuah teknologi yang menggabungkan antara aplikasi dengan database menjadi satu lapis. Setiap objek di dalam Object Relational Mapping, umumnya mewakili tabel dalam database. Akibat dari teknologi mapping ini membuat sebuah aplikasi yang dikembangkan dengan Object Relational Mapping, tidak terikat dengan database manapun. Sedangkan untuk melakukan query database, dengan Object Relational Mapping digunakan sebuah object relational language, yaitu HQL yang bekerja mirip dengan SQL. Umumnya setiap tabel dan objek di-mapping dengan sebuah XML. (Thamura, 2006)

Hibernate Query Language adalah sebuah query database yang sangat bagus yang diciptakan untuk digunakan dengan Hibernate. Hibernate Query Language sangat mirip dengan SQL, tetapi Hibernate Query Language lebih mudah digunakan, karena menggunakan bahasa yang sangat padat dan merupakan bahasa yang berorientasi objek. (Minter, 2005)

Hibernate merupakan sebuah teknik yang digunakan dalam pemrograman untuk menggunakan basisdata relasional sebagai penyimpanan data dengan bentuk objek. Teknik ini biasa digunakan dalam bahasa pemrograman berorientasi objek saat harus menggunakan basisdata relasional dalam penyimpanannya.

Hibernate membutuhkan konfigurasi dengan XML. Kelebihan menggunakan konfigurasi dengan XML yaitu file konfigurasi dengan XML mempunyai kemampuan untuk mengkonfigurasi file mapping yang dibutuhkan oleh Hibernate. File konfigurasi dengan XML ini diberi nama hibernate.cfg.xml dan ditempatkan di root di classpath sebuah aplikasi. (Minter, 2005)

Ada 2 cara untuk menggunakan Hibernate, yaitu

  1. Hibernate Core adalah suatu cara penggunaan Hibernate dengan membuat file *.hbm.xml untuk menyatakan mapping antara objek di Java dengan tabel di database.
  2. Hibernate Annotation adalah suatu cara penggunaan Hibernate dengan menyisipkan Annotation pada setiap objek di Java yang akan di-mapping ke tabel di database. (Hibernate Team)

Sedangkan untuk pengembangan aplikasi dengan menggunakan Hibernate dikenal 2 pendekatan, yaitu

  1. Database Structure To Model (Object) adalah suatu cara pembuatan class di sistem secara automatis yang berdasarkan pada tabel yang sudah ada di database.
  2. Model (Object) To Database Structure adalah suatu cara pembuatan tabel di database secara automatis yang berdasarkan pada class yang sudah ada di sistem. (Muhardin, 2006)

Bab 3
Metode Penelitian

3.1 Tahap Pembuatan Spesifikasi

Untuk membandingkan Arsitektur Model 2 dan Arsitektur Model 1 dalam merancang dan mengimplementasikan Sistem Informasi Akademik berbasis web dengan menggunakan bahasa pemrograman Java maka dibuatlah tahapan dalam pembuatan dan pengembangan sistem tersebut.

Secara keseluruhan Sistem Informasi Akademik ini mempunyai 3 tahapan, dengan adanya 3 tahapan ini diharapkan perbandingan Arsitektur Model 2 dan Arsitektur Model 1 dapat terlihat dengan jelas dalam pembuatan dan pengembangan Sistem Informasi Akademik.

Di tahap pertama, tahap pembuatan, Sistem Informasi Akademik dapat melakukan manajemen user, manajemen fakultas, manajemen matakuliah, manajemen ruang, manajemen provinsi, manajemen dosen, manajemen angkatan, manajemen semester, manajemen jadwal, manajemen data mahasiswa, manajemen nilai mahasiswa, melihat kelas, melihat KST, melihat IPS, melihat IPK, dan registrasi.

Setelah tahap pertama selesai, sistem tersebut dikenakan kasus, yaitu sistem tersebut dikembangkan sehingga dapat melakukan manajemen jenis biaya, manajemen pembayaran, dan melihat laporan.

Setelah tahap kedua selesai, sistem tersebut kembali dikenakan kasus, yaitu sistem tersebut dikembangkan sehingga dapat melakukan manajemen jabatan dan manajemen penggajian.

3.2 Perancangan dan Implementasi
3.2.1 Perancangan Activity Diagram

Activity Diagram merepresentasikan bisnis dan juga workflow operasional dalam suatu sistem. Sebuah Activity Diagram adalah variasi dari State Diagram yang mana State merepresentasikan operasi, dan transisinya merepresentasikan aktivitas yang terjadi disaat operasi sudah selesai. Dalam tahap ini, digambarkan berbagai alur aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alur berawal, keputusan yang mungkin terjadi, dan bagaimana mereka berakhir.

Dalam Sistem Informasi Akademik terdapat 5 aktor yang berikteraksi dengan sistem, yaitu Administrator, Akademik, Keuangan, Dosen, dan Mahasiswa.
Administrator merupakan aktor yang mengelola data pokok, mempunyai 7 aktivitas, yaitu manajemen user, manajemen fakultas, manajemen matakuliah, manajemen ruang, manajemen jabatan (diimplementasikan di tahap ketiga), manajemen provinsi, dan manajemen dosen (terlihat di Gambar 3. 1).

Akademik merupakan aktor yang mengelola data yang berkaitan dengan akademik, mempunyai 9 aktivitas, yaitu manajemen angkatan, manajemen semester, manajemen jadwal, manajemen data mahasiswa, manajemen nilai mahasiswa, melihat kelas, melihat KST, melihat IPS, dan melihat IPK (terlihat di Gambar 3. 2).

Keuangan merupakan aktor yang mengelola data yang berkaitan dengan keuangan (Keuangan diimplementasikan di tahap kedua), mempunyai 4 aktivitas, yaitu manajemen jenis biaya, manajemen pembayaran, melihat laporan, dan di tahap ketiga mendapat tambahan manajemen penggajian (terlihat di Gambar 3. 3).

Dosen merupakan aktor yang bertanggung jawab menginput nilai mahasiswa yang diajarnya di akhir semester, mempunyai 2 aktivitas, yaitu manajemen profile dan manajemen nilai (terlihat di Gambar 3. 4).

Mahasiswa merupakan aktor yang dapat melakukan 5 aktivitas, yaitu manajemen profile, registrasi, melihat KST, melihat IPS, dan melihat IPK (terlihat di Gambar 3. 5).

3.2.2 Perancangan Class Diagram dan Database

Dalam penelitian ini, penulis menggunakan teknologi Hibernate, yaitu Hibernate Core, yaitu suatu cara penggunaan Hibernate dengan membuat *.hbm.xml untuk menyatakan mapping antara objek di Java dengan tabel di database, sehingga ketika sistem berjalan tabel yang diperlukan akan terbentuk secara automatis. Karena hal tersebut, di tahap Perancangan Class Diagram sedikit berbeda dengan yang lainnya, yaitu pada tahap ini juga terdapat Perancangan Database.

Class-class yang diciptakan dalam pembuatan Sistem Informasi Akademik, yaitu

  1. class User : class ini diciptakan di tahap pertama, berfungsi sebagai media penyimpanan data User.
  2. class Fakultas : class ini diciptakan di tahap pertama, berfungsi sebagai media penyimpanan data Fakultas.
  3. class Matakuliah : class ini diciptakan di tahap pertama, berfungsi sebagai media penyimpanan data Matakuliah, class ini membutuhkan class Fakultas.
  4. class Ruang : class ini diciptakan di tahap pertama, berfungsi sebagai media penyimpanan data Ruang.
  5. class Provinsi : class ini diciptakan di tahap pertama, berfungsi sebagai media penyimpanan data Provinsi.
  6. class Dosen : class ini diciptakan di tahap pertama, berfungsi sebagai media penyimpanan data Dosen, class ini membutuhkan class Provinsi, di tahap ketiga juga membutuhkan class Jabatan.
  7. class Angkatan : class ini diciptakan di tahap pertama, berfungsi sebagai media penyimpanan data Angkatan.
  8. class Semester : class ini diciptakan di tahap pertama, berfungsi sebagai media penyimpanan data Semester.
  9. class Jadwal : class ini diciptakan di tahap pertama, berfungsi sebagai media penyimpanan data Jadwal, class ini membutuhkan class Matakuliah, Ruang, Dosen, dan Semester.
  10. class Mahasiswa : class ini diciptakan di tahap pertama, berfungsi sebagai media penyimpanan data Mahasiswa, class ini membutuhkan class Fakultas, Angkatan, dan Provinsi.
  11. class RegistrasiMatakuliah : class ini diciptakan di tahap pertama, berfungsi sebagai media penyimpanan data RegistrasiMatakuliah, class ini membutuhkan class Jadwal, Matakuliah, dan Mahasiswa.
  12. class JenisBiaya : class ini diciptakan di tahap kedua, berfungsi sebagai media penyimpanan data JenisBiaya.
  13. class Tagihan : class ini diciptakan di tahap kedua, berfungsi sebagai media penyimpanan data Tagihan, class ini mempunyai sub class TagihanDetail yang membutuhkan class JenisBiaya.
  14. class Jabatan : class ini diciptakan di tahap ketiga, berfungsi sebagai media penyimpanan data Jabatan.
  15. class Penggajian : class ini diciptakan di tahap ketiga, berfungsi sebagai media penyimpanan data Penggajian, class ini membutuhkan class Dosen dan Semester.

Di Gambar 3. 6 terlihat class-class yang telah disebutkan di atas, beserta hubungannya diantaranya. Oleh karena class-class tersebut berfungsi sebagai Model, yaitu sebuah class yang hanya terdiri dari attributes dan tidak ada operations selain setter-getter, maka pada Class Diagram tersebut hanya digambarkan nama class beserta hubungan diantaranya.

Struktur class User dan tabel User dapat dilihat di Tabel 3. 1.

Struktur class Fakultas dan tabel Fakultas dapat dilihat di Tabel 3. 2.

Struktur class Matakuliah dan tabel Matakuliah dapat dilihat di Tabel 3. 3.

Struktur class Ruang dan tabel Ruang dapat dilihat di Tabel 3. 4.

Struktur class Provinsi dan tabel Provinsi dapat dilihat di Tabel 3. 5.

Struktur class Dosen dan tabel Dosen dapat dilihat di Tabel 3. 6.

Struktur class Angkatan dan tabel Angkatan dapat dilihat di Tabel 3. 7.

Struktur class Semester dan tabel Semester dapat dilihat di Tabel 3. 8.

Struktur class Jadwal dan tabel Jadwal dapat dilihat di Tabel 3. 9.

Struktur class Mahasiswa dan tabel Mahasiswa dapat dilihat di Tabel 3. 10.

Struktur class Registrasi Matakuliah dan tabel Registrasi Matakuliah dapat dilihat di Tabel 3. 11.

Struktur class Jenis Biaya dan tabel Jenis Biaya dapat dilihat di Tabel 3. 12.

Struktur class Tagihan (dan subclassnya, class Tagihan Detail) dan tabel Tagihan (dan tabel Tagihan Detail) dapat dilihat di Tabel 3. 13 dan Tabel 3. 14.

Struktur class Jabatan dan tabel Jabatan dapat dilihat di Tabel 3. 15.

Struktur class Penggajian dan tabel Penggajian dapat dilihat di Tabel 3. 16.

3.2.3 Perancangan Use Case Diagram

Use Case Diagram adalah teknik untuk merekam persyaratan fungsional sebuah sistem. Use Case Diagram mendeskripsikan interaksi tipikal antara para pengguna sistem dengan sistem itu sendiri, dengan memberi sebuah narasi tentang bagaimana sistem tersebut digunakan.

Dalam Sistem Informasi Akademik terdapat 5 aktor yang berinteraksi dengan sistem, yaitu Administrator, Akademik, Keuangan, Dosen, dan Mahasiswa.

Gambar 3. 7 memperlihatkan interaksi antara Administrator dengan Sistem Informasi Akademik. Seorang Administrator dapat memanajemen user, memanajemen fakultas, memanajemen matakuliah, memanajemen ruang, memanajemen jabatan (diimplementasikan di tahap ketiga), memanajemen provinsi, dan memanajemen dosen.

Gambar 3. 8 memperlihatkan interaksi antara Akademik dengan Sistem Informasi Akademik. Seorang Akademik dapat memanajemen angkatan, memanajemen semester, memanajemen jadwal, memanajemen data mahasiswa, memanajemen nilai mahasiswa, melihat kelas, melihat KST, melihat IPS, dan melihat IPK.

Gambar 3. 9 memperlihatkan interaksi antara Keuangan dengan Sistem Informasi Akademik. Seorang Keuangan dapat memanajemen jenis biaya, memanajemen pembayaran, melihat laporan, dan di tahap ketiga dapat memanajemen penggajian.

Gambar 3. 10 memperlihatkan interaksi antara Dosen dengan Sistem Informasi Akademik. Seorang Dosen dapat memanajemen profile dan memanajemen nilai.

Gambar 3. 11 memperlihatkan interaksi antara Mahasiswa dengan Sistem Informasi Akademik. Seorang Mahasiswa dapat memanajemen profile, registrasi matakuliah, melihat KST, melihat IPS, dan melihat IPK.

3.2.4 Perancangan Sequence Diagram

Sequence Diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence Diagram terdiri atas dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).

Sequence Diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai response dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses, dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.

Melalui Sequence Diagram ini, perbandingan Arsitektur Model 2 dan Arsitektur Model 1 dalam perancangan sistem dapat terlihat dengan jelas.
Sequence Diagram dapat dilihat di Lampiran, yaitu di Gambar L. 1 sampai dengan Gambar L. 36.

3.3 Evaluasi Prototype

Di tahap ini dilakukan pengujian terhadap aplikasi yang telah dibuat. Jika masih terdapat beberapa perubahan yang berhubungan dengan kebutuhan di aplikasi maka akan diperbaiki lagi dengan di awali dengan tahap pengumpulan kebutuhan sesuai dengan yang diperlukan saja. Jika aplikasi yang dibuat sudah bisa memenuhi kebutuhan yang diperlukan maka proses di penelitian ini selesai.

Bab 4
Hasil Penelitian Dan Pembahasan

Dengan adanya penelitian terhadap perbandingan Arsitektur Model 2 dan Arsitektur Model 1 dalam pengembangan Sistem Informasi Akademik berbasis web penulis menemukan beberapa perbedaan.

Perbedaan yang pertama, yaitu adanya perbedaan dalam alur jalannya sistem, secara umum perbedaan tersebut dapat dilihat di Tabel 4. 1.

Di Arsitektur Model 1, user berinteraksi dengan JSP, JSP menunjuk JSP lain untuk menjawab, jika membutuhkan data dari database JSP mengakses DAO, DAO mengambil data yang dibutuhkan, JSP menampilkan data tersbut kepada user.

Sedangkan di Arsitektur Model 2, user berinteraksi dengan JSP, JSP meminta struts-config.xml untuk meneruskannya kepada Action, jika membutuhkan data dari database, Action mengakses DAO, DAO mengambil data yang dibutuhkan, Action kembali meminta struts-config.xml untuk meneruskannya kepada JSP, JSP menampilkan data tersebut kepada user.

Untuk lebih jelasnya penulis mengambil contoh dari Sequence Diagram Manajemen User yang dapat dilihat di Gambar L. 7 untuk Arsitektur Model 2 dan Gambar L. 8 untuk Arsitektur Model 1.

Gambar L. 7 terlihat lebih rumit dibanding Gambar L. 8, tetapi jika dilihat dengan seksama terlihat jelas struts-config.xml dan Action mengambil peranan penting dalam alur jalannya sistem, sedangkan bagian JSP hanya bertugas untuk mengambil data dari user dan menampilkan data ke user. Hal ini berarti di awal pembuatan sistem pembuat sistem harus membuat banyak file yang mempunyai fungsi yang berbeda, hal ini mengakibatkan kendala dalam pembuatan sistem dengan Arsitektur Model 2, tetapi ketika sistem tersebut berhasil dibuat dan ingin diperbaiki atau dikembangkan lagi, pengembang sistem tidak akan mengalami kesulitan yang disebabkan oleh banyaknya source code pada suatu file.

Sebaliknya, Gambar L. 8 terlihat lebih sederhana dibanding Gambar L. 7, tetapi jika dilihat dengan seksama terlihat jelas JSP bekerja keras menangani masuknya data dari user dan menampilkan data ke user. Hal ini berarti dalam pembuatan sistem, pembuat sistem menulis semua fungsi dalam JSP yang akan mempermudah dokumentasi, tetapi hal ini mempunyai efek samping yaitu membesarnya ukuran file JSP yang diakibatkan dengan banyaknya source code, jika dilihat lebih jauh lagi pengembang sistem akan mengalami kesusahan dalam perbaikan dan pengembangan sistem yang dikarenakan susahnya mencari letak source code yang akan dikembangkan. Hal ini yang seringkali membuat pengembangan sistem menjadi lebih lama bahkan terhenti.

Perbedaan yang kedua, yaitu adanya perbedaan dalam waktu yang dibutuhkan dalam pembuatan dan pengembangan sistem dengan menggunakan Arsitektur Model 2 dan Arsitektur Model 1, secara umum perbedaan tersebut dapat dilihat di Tabel 4. 2.

Di Arsitektur Model 1, waktu yang dibutuhkan ditahap 1 lebih sedikit, hal ini dikarenakan pembuat sistem hanya fokus dalam pembuatan JSP. Waktu yang dibutuhkan ditahap 2 lebih banyak, hal ini dikarenakan pembuat sistem harus mencari source code yang akan dikembangkan dalam JSP. Apalagi jika pengembang sistem bukanlah pembuat sistem, hal ini akan mengakibatkan pengembang sistem harus terlebih dulu mempelajari sistem dari pembuat sistem (terlihat di Tabel 4. 3).

Sedangkan di Arsitektur Model 2, waktu yang dibutuhkan ditahap 1 lebih banyak, hal ini dikarenakan pembuat sistem harus membuat package-package tersendiri untuk Model, View, dan Controller dan melakukan konfigurasi awal Struts. Waktu yang dibutuhkan ditahap 2 lebih sedikit, hal ini dikarenakan pengembang sistem telah tahu bagian mana yang akan dikembangkan, jika bagian Model yang dikembangkan maka pengembang sistem dapat langsung menuju package Model, package Bean, dan package DAO, jika bagian View yang dikembangkan maka pengembang sistem dapat langsung menuju package JSP, jika bagian Controller yang akan dikembangkan maka pengembang sistem dapat langsung menuju package Action. Jika pengembang sistem bukanlah pembuat sistem, pengembang sistem dapat langsung menuju package tertentu, dengan catatan pengembang sistem mengerti sedikit konsep Model View Controller (terlihat di Tabel 4. 3 dan Tabel 4. 4).

Perbedaan yang ketiga, yaitu adanya perbedaan dalam penerapan kerjasama tim dengan menggunakan Arsitektur Model 2 dan Arsitektur Model 1. Arsitektur Model 2 membagi kerjasama tim berdasarkan pembagian Model View Controller sedangkan Arsitektur Model 1 membagi kerjasama tim berdasarkan banyak objek dalam sistem (terlihat di Tabel 4. 5).

Untuk lebih jelasnya penulis mengambil contoh ada beberapa orang pembuat sistem yang akan membuat Sistem Informasi Akademik. Dengan menggunakan Arsitektur Model 1 pembagian kerjasama tim didasarkan pada banyak objek yang akan dibuat pada sistem, hal ini kurang dapat memaksimalkan potensi seseorang, karena potensi orang bermacam-macam, orang yang mempunyai potensi seni akan mengalami masalah ketika harus berhadapan dengan logika yang rumit, sedangkan orang yang mempunyai potensi logika akan mengalami kesulitan ketika harus berhadapan dengan perancangan tampilan.

Sedangkan dengan menggunakan Arsitektur Model 2 pembagian kerjasama tim lebih didasarkan pada Model View Controller, hal ini dapat memaksimalkan potensi seseorang, karena potensi orang bermacam-macam, orang yang mempunyai potensi seni dapat mengerjakan View, sedangkan orang yang mempunyai potensi logika dapat mengerjakan Model dan Controller. Kelemahan Arsitektur Model 2 adalah butuhnya kesepakatan bersama dalam penamaan class dan fungsi yang akan digunakan, tanpa adanya kesepakatan bersama, kerjasama tim akan memperlambat pembuatan dan pengembangan sistem.

Perbedaan yang keempat, yaitu adanya perbedaan dalam validasi data. Arsitektur Model 2 melakukan validasi data dengan cara menuliskan data form yang berupa tag di validation.xml sedangkan Arsitektur Model 1 melakukan validasi data dengan cara menyisipkan source code validasi di setiap JSP.

Bab 5
Kesimpulan

Penulis mendapatkan kesimpulan bahwa Arsitektur Model 2 yang merupakan pengembangan dari Arsitektur Model 1 mempunyai beberapa kelebihan dan juga mempunyai beberapa kelemahan jika dilihat dari sudut pandang pembuat sistem.

Kelebihan Arsitektur Model 2 yaitu membagi source code menjadi 3 bagian (Model View Controller) sehingga mudah untuk dibuat dan dikembangkan, sistem yang dibuat dengan Arsitektur Model 2 dapat dikembangkan dalam waktu yang relatif singkat, pembagian kerjasama tim yang sangat efisien karena memaksimalkan potensi dari setiap anggota tim, dan mudahnya melakukan validasi data.

Selain memiliki kelebihan, Arsitektur Model 2 juga memiliki kelemahan, yaitu pembagian source code menjadi 3 bagian (Model View Controller) sering dianggap merumitkan pembuatan sistem, lamanya waktu yang dibutuhkan dalam pembuatan sistem, dan butuhnya kesepakatan bersama dalam penamaan class dan fungsi yang akan digunakan.

Dengan melihat kelebihan dan kekurangan tersebut, dapat dilihat Arsitektur Model 2 masih tetap lebih unggul dari Arsitektur Model 1, khususnya dalam membuat sistem berskala besar, mengingat di jaman ini tidak ada sistem yang tidak mungkin tidak berkembang.

[download page][download program]

[end-of-file]

Advertisements
%d bloggers like this: