Penerapan Design Patterns Pada Rancang Bangun Peranti Lunak Melalui Analisis Commonality & Variability Domain Masalah Aplikasi
1
2
Eko K. Budiardjo , Herson C. Mandiangan , 1
Fakultas Ilmu Komputer – Universitas Indonesia, Gedung Fasilkom UI, Kampus UI Depok, Depok - 16424,
[email protected] 2
Magister Teknologi Informasi – Universitas Indonesia, Gedung MTI, Kampus UI Salemba, Jakarta Pusat - 10002
ABSTRAK
Pengembangan aplikasi baru selalu dimulai dari awal siklus hidup pengembangan peranti lunak, sehingga akan menyita waktu yang sebenarnya terbuang percuma karena tidak lebih dari sekedar pengulangan apa yang pernah dilakukan sebelumnya (reinvent the wheel). Untuk itu perlu dicari bagaimana untuk mempercepat pembangunan ulang suatu produk aplikasi yang pernah dibuat sebelumnya, dengan mempertimbangkan beberapa variasi kebutuhan sesuai dengan organisasi pengguna, dengan tidak mengabaikan kebutuhan dasar sistem tersebut. Untuk mendapat jawaban terhadap keinginan ini dilakukan penelitian terhadap tahapan analisa dan perancangan, dengan mengkaji konsep keanekaragaman peranti lunak, dan menelaah katalog Design Patterns dari Gamma, et al, “Deliverable” dari penelitian ini adalah penerapan dari AbstractFactory Pattern[4] untuk memecahkan permasalahan kesamaan dan perbedaan yang terdapat pada aplikasi HuRIS, sehingga akan terbentuk suatu struktur dasar yang relatif tidak memerlukan perubahan pada pembangunan aplikasi dan struktur tambahan yang tergantung dari kebutuhan spesifik masing-masing organisasi. Kata kunci: Commonality and Variability, Human Resource Information System (HuRIS), Design Patterns I. Pendahuluan Peranti lunak untuk suatu domain aplikasi memiliki banyak kesamaan fitur – commonality – yang mendasar antara satu dengan yang lainnya. Pembeda penerapan satu dengan lainnya bergantung pada prasyarat spesifik organisasi penggunanya, yang selanjutnya disebut sebagai variability. Sebagai contoh apa yang terdapat pada Aplikasi Resource Information System (HuRIS) yang dibangun untuk penguna yang berbeda, akan memiliki kesamaan yang mendasar dan variasi perbedaan, baik dalam basis data, proses komputasi, dan laporan yang dihasilkan. Aplikasi HuRIS akan menyimpan data-data yang umum (commonality ) seperti Nomor Pegawai, Nama Pegawai, Tanggal lahir, serta datadata lain yang hampir serupa, serta data-data yang khusus sesuai dengan keinginan masing-masing perusahaan.
Setiap HuRIS akan memerlukan modul aplikasi administrasi pengelolaan data induk pegawai yang dilengkapi dengan proses-proses, antara lain, menambahan data pegawai, mencari data pegawai, mengubah data pegawai agar data terpelihara, serta menghapus data pegawai yang sudah tidak lagi bekerja dalam lingkungan perusahaan. Proses ini dikenal sebagai Custodial Application yang menjalankan proses CRUD (create, read, update dan delete) Menambah terhadap data pegawai. Data Pegawai End-to-end interaksi antara pengunan dan Mencari Data Pegawai sistem komputer dapat dimodelkan dengan Use Mengubah Case Diagram pada Gb. 1. Pengguna Data Pegawai Basis Data Menghapus Data Pegawai
Gb. 1: Custodial Application Use Case Diagram
II. Pembahasan Dengan mengambil domain aplikasi HuRIS sebagai studi kasus, penelitian dilakukan dengan membuat dua contoh dari dua organisasi yang berbeda, menganalisa dan mendesain dengan orientasi obyek, hingga mendapatkan diagram rancangan kelasnya. Selanjutnya melakukan analisa persamaan dan perbedaan pada keduanya, dan dengan mengambil pola yang cocok serta menerapkannya untuk memecahkan permasalahan kesamaan dan perbedaan ini, kemudian membuat prototype penerapan pada aplikasi dengan menggunakan bahasa pemrograman VB.Net. Pada penelitian ini, fokus ditujukan pada AbstractFactory Pattern[4]. Menurut [Gamma, Erich, et al], penggunaan ini sebaiknya diterapkan apabila: •
Sebuah sistem seharusnya tidak tergantung dari bagaimana produk berikutnya akan dibuat, dirangkai dan ditampilkan.
•
Sebuah sistem akan dikonfigurasi dengan satu dari banyak keluarga produk
•
Suatu keluarga dari obyek produk yang berhubungan, dirancang untuk digunakan bersama-sama dan ada batasan-batasan yang harus dilalui.
•
Kita ingin menghasilkan sebuah kelas pustaka (library) dari sebuah produk yang akan dikemukakan interface-nya, bukan bagaimana implementasinya.
AbstractFactory Pattern ini memiliki keuntungan dan kerugian sebagai berikut: 1. Memisahkan kelas-kelas konkrit. Pattern ini membantu untuk mengendalikan kelaskelas dari obyek yang dihasilkan oleh aplikasi. Pattern ini menyembunyikan (encapsulate) tanggungjawab dan proses pembuatan obyek produk, ia juga mengisolasi klien dari kelas kelas implementasi-nya. Klien memanipulasi hasil instasiasi melalui interface abstraknya. Gb. 2. Struktur Pattern Abstract Factory.
2. Mempermudah pertukaran produk satu keluarga. Kelas konkritnya akan muncul hanya satu kali dalam aplikasi – yaitu dimana ia di instansiasi. Hal ini akan memudahkan untuk mengubah kelas konkrit pada penggunaan aplikasi. Ia dapat menggunakan konfigurasi produk yang berbeda secara mudah hanya dengan mengganti kelas konkritnya. Karena sebuah abstractfactory membuat suatu produk keluarga yang lengkap, keseluruhan produk berubah seketika. 3. Mengutamakan konsistensi di antara produk. Pada saat obyek produk dalam keluarga didesain untuk bekerja bersama-sama, adalah hal yang penting untuk aplikasi menggunakan obyek dari hanya satu keluarga pada saat yang sama. 4. Mendukung suatu jenis produk baru adalah hal yang sulit. Meningkatkan kegunaan abstractfactory untuk menghasilkan jenis baru dari sebuah produk tidaklah mudah. Hal ini dikarenakan interface abstractfactory menentukan sekumpulan produk yang dapat dihasilkan. Dukungan terhadap produk jenis baru membutuhkan untuk memperluas (extend) interface abstractfactory, yang melibatkan perubahan kelas abstractfactory dan seluruh kelas turunannya. Pattern ini memiliki tujuan menyediakan sebuah interface untuk menghasilkan kumpulan keluarga atau obyek-obyek yang saling membutuhkan atau bahkan saling memiliki ketergantungan satu sama lain (dependent), tanpa harus membuat spesifikasi kelas-kelas nyatanya (concrete classes). Permasalahan yang kita hadapi ini memiliki banyak kemungkinan persesuaian dengan kebutuhan pada masing-masing produk. Setiap produk harus memiliki suatu standar kesamaan (commonality) yang umum dan juga variasi kebutuhannya sendiri-sendiri (variant). Untuk menghasilkan sebuah aplikasi yang tidak kaku hanya dapat dipakai pada suatu industri, maka kebutuhan akan variasi (variant) seharusnya tidak dituliskan (hard-code) pada aplikasi tersebut, karena membuat instansiasi dari kelas-kelas yang telah di-hardcode akan menyebabkan aplikasinya susah diubah pada pengembangan berikutnya.
Permasalahan ini akan kita coba pecahkan dengan cara membuat sebuah kelas induk yang akan mendeklarasikan interface untuk menghasilkan setiap hal yang umum (common) dan kemudian juga kelas turunan abstrak untuk setiap kebutuhan yang sesuai dengan requirements-nya masing-masing. Pada saat aplikasi dibangun, para pengembang aplikasi dapat memanfaatkan kelas induk yang umum ini dan menciptakan kelas turunan baru yang memiliki variasi kebutuhan sesuai dengan requirements, kemudian membuat instansiasi dari kelas turunannya yang baru serta menggunakan keseluruhan obyek yang ada baik di kelas induk, maupun di kelas turunan. VISUALIZING CONCEPTS Tujuan kita berikutnya adalah membuat sebuah domain model dan melakukan identifikasi terhadap kelas-kelas konseptual yang diambil dari skenario-skenario pada bahasan-bahasan sebelumnya, dengan mengikuti garis pedoman (guidelines) untuk membuat domain model. a. Daftar kandidat kelas konseptual dan tehnik identifikasi kata benda. b. Menggambarkan kandidat kelas konseptual dalam sebuah domain model. c. Menambahkan hubungan relationship data antar kelas konseptual. d. Menambahkan atribut yang diperlukan. RANCANGAN DIAGRAM KELAS - Pegawai Walaupun secara teori memang sebaiknya pembuatan (design) class diagram mendahului pembuatan kelas konseptual, namun dalam prakteknya hal ini dapat saja terjadi secara paralel dan sinergis. Banyak kelas, metode dan hubungan relasi bisa dibuat pada tahap-tahap awal desain dengan menerapkan pola tugas dan tanggung jawab (responsibility assignment patterns). Dengan berfokus pada pembuatan kelas Pegawai, maka dari kelas konseptual yang sudah ada, kita tambahkan metodemetode dari proses CRUD pada Use Case Diagram sebelumnya, untuk menghasilkan (design) class diagram. Gb. 3: Rancangan Kelas diagram - Pegawai
KESAMAAN (COMMONALITY) PADA HuRIS HuRIS memiliki kesamaan yang harus ada dalam aplikasi yang menangani permasalahan dasar kepegawaian. Pada Modul Administrasi Data Dasar Pegawai dapat kita pilih data yang menjadi sesuatu yang selalu ada dalam kelas pegawai ini, yaitu:
1. data; antara lain adalah nomor induk yang bersifat unik, nama, status nikah dan jumlah tanggungan sebagai dasar dari perhitungan pajak penghasilan yang menjadi kewajiban setiap pekerja, tanggal lahir untuk mengetahui usia saat ini, alamat tempat tinggal dan gaji pokok yang diterima sebagai hak pegawai. 2. fungsionalitas; antara lain adalah operasi pemilihan (select) dan penghapusan (delete) seluruh data dari pegawai tertentu, yang secara umum keduanya hanya membutuhkan satu parameter saja yaitu nomor induk pegawai. PERBEDAAN (VARIABILITY) PADA HuRIS Sedangkan untuk variasi disebabkan karena adanya perbedaan prasyarat (Requirements) pada aplikasi yang merupakan variasi pada penerapan yang berbeda. Maka data yang tidak mutlak harus ada dan menjadi kebutuhan aplikasi kepegawaian umumnya karena tidak semua lingkungan kerja memerlukan data tersebut, yaitu: 1. Data; antara lain adalah jenis kelamin, tempat lahir, kota tempat tinggal, tanggal mulai kerja, tunjangan jabatan, uang makan dan uang transport. 2. Fungsionalitas; antara lain adalah operasi penambahan (add) dan perubahan (update) data pegawai, karena kedua operasi tersebut akan sangat tergantung parameternya pada data yang akan dimanipulasi. RANCANGAN CLASS DIAGRAM BERDASARKAN DESIGN PATTERNS Mengacu pada commonality dan variability yang telah dibahas, serta perancangan dengan AbstractFactory Pattern, maka kita hasilkan terlebih dahulu sebuah kelas induk yang akan menyimpan hal-hal yang memiliki kesamaan mendasar, kemudian yg menangani perbedaan berdasarkan kemung-kinan kebutuhan selan-jutnya, yang selanjutnya akan kita buat HR_Core_AbstractFactory Application Client lagi kelas turunan • NomorInduk • Nama • StatusPernikahan berikutnya. Kelas induk • TanggunganKeluarga • TanggalLahir • Alamat diperlihatkan pada Gd.3. • GajiPokok HR_Core_Product Mengikuti pola CariPegawai(…) HapusPegawai(…) AbstractFactory dapat kita gambarkan rancangHR_Vary_AbsFact_1 HR_Vary_AbsFact_2 an Class Diagram baru • JenisKelamin • Jabatan • TempatLahir • Telpon • Kota • KodePos HR_Vary_Product_1 HR_Vary_Product_2 yang telah menerapkan • TglMasukKerja • TunjanganJabatan • TunjanganJabatan • TunjanganKeluarga • UangMakan • Bank AbstractFactory Pattern, • UangTransport • NomorRekening TambahPegawai(…) seperti yang diperlihatkan TambahPegawai(…) UbahPegawai(…) UbahPegawai(…) pada Gb. 4. Common Produk untuk Data Pegawai
Varian Produk Kedua Varian Produk Pertama
Gb. 4. Rancangan Class Diagram dgn AbstractFactory Pattern
REALISASI RANCANGAN PADA PROTOTIPE MODUL PEMELIHARAAN DATA PEGAWAI Berdasarkan rancangan kelas yang telah diperlihatkan pada Gb.4. dapat dihasilkan 2 kemungkinan penerapan sperti yang diperlihatkan pada Gb. 5. dan Gb.6.:
Gb. 5: Prototipe Pertama
Gb. 6: Prototipe kedua
KESAMAAN (COMMONALITY) KEDUA PROTOTIPE Hal-hal mendasar yang menjadi kesamaan dari kedua contoh realisasi di atas, dalam menangani permasalahan data dasar kepegawaian, sbb: 1. Data; antara lain adalah nomor induk yang bersifat unik, nama, status nikah dan jumlah tanggungan dalam keluarga, tanggal lahir, alamat tempat tinggal dan gaji pokok yang diterima sebagai hak pegawai. 2. Fungsionalitas; antara lain adalah operasi pemilihan (select) dan penghapusan (delete) seluruh data dari pegawai tertentu, yang secara umum keduanya hanya membutuhkan satu parameter saja yaitu nomor induk pegawai. PERBEDAAN (VARIABILITY) KEDUA PROTOTIPE Sedangkan variasi perbedaan dari kedua contoh permasalahan di atas yang dikarenakan adanya perbedaan requirements keduanya adalah sebagai berikut: 1. Data; • Pada prototipe pertama dibutuhkan data tambahan antara lain adalah jenis kelamin, tempat lahir, kota tempat tinggal, tanggal mulai kerja, tunjangan jabatan, uang makan dan uang transport. • Sedangkan pada prototipe kedua dibutuhkan data tambahan lain yaitu jabatan pekerjaan pegawai, nomor telpon yang dapat dihubungi, kode pos tempat tinggal, tunjangan jabatan, tunjangan keluarga, nama bank dan nomor rekening dimana pegawai akan menerima transfer gajinya. 2. Fungsionalitas; antara lain adalah operasi penambahan (add) dan perubahan (update) data pegawai, karena kedua operasi tersebut akan sangat tergantung parameternya pada data yang akan dimanipulasi.
III. Kesimpulan Dari percobaan ini diperoleh commonality dalam hal data yaitu nomor induk yang bersifat unik, nama, status pernikahan dan jumlah tanggungan dalam keluarga, tanggal lahir, alamat tempat tinggal dan gaji pokok; dan dalam hal fungsionalitas yaitu operasi select dan delete data. Sedangkan yang menjadi variability adalah perbedaan requirements data pada masing-masing domain contoh, serta operasi insert dan update data. Pada prototipe pertama, ada variant berupa kebutuhan akan data jenis kelamin, tempat kelahiran, kota dari alamat tempat tinggal, tanggal pertama kali masuk kerja sebagai pegawai, penghasilan tunjangan jabatan, uang makan dan uang transport pegawai. Sedangkan prototipe kedua, variant kebutuhan datanya yaitu data jabatan dalam pekerjaan, nomor telepon yang dapat dihubungi, kodepos dari alamat tempat tinggal, penghasilan tunjangan jabatan, tunjangan keluarga dan nama bank serta nomor rekening yang menjadi tujuan transfer gaji sang karyawan. Operasi insert dan update data yang menjadi fungsi dari kedua domain contohnya pun akan tergantung pada variant datanya masing-masing. Untuk memecahkan masalah commonality dan variability pada pembangunan keluarga produk (family of products) sebuah aplikasi ini, paling cocok adalah dengan menggunakan AbstractFactory Pattern dari Design Patterns. Penerapan Code Program dan Design Patterns dapat diterapkan pada bahasa Visual Basic .NET dengan mudah sebagaimana pada contoh prototype, karena bahasa ini telah mendukung Object Oriented Programming secara penuh. Daftar Pustaka 1 2 3. 4. 5.
6. 7. 8.
Bachmann, F., Bass, L, 2001, Managing Variability in Software Architectures Cooper, J.W., 2001, Visual Basic Design Patterns: VB 6.0 and VB.NET, Addison-Wesley Professional. Dobing, B., Parsons, J., 2006, How UM is Used, Communications of The ACM, May 2006/Vol. 49, No. 5 Gamma, E., et al., 1995, Design Patterns : Elements of Reusable Object-oriented Software, Professional Computing Series. Addison-Wesley. Kouroshfar, E., Shahir, H.Y., Ramsin, R., 2009, Process Patterns for Component-Based Software Development, G.A. Lewis, I. Poernomo, and C. Hofmeister (Eds.): CBSE 2009, LNCS 5582, pp. 54–68, 2009, Springer-Verlag Berlin Heidelberg. Larman, C., 2002, Applying UML and Patterns, Second Edition, Prentice Hall PTR. Leffingwell, D., Widrig, D., 200, Managing Software Requirements - A Unified Approach, AddisonWesley. Stamatakis, W., 2000, Microsoft Visual Basic Design Patterns, Microsoft Press.
ABOUT THE AUTHOR: Dr. Eko K. Budiardjo has been the faculty member of the Faculty of Computer Science - University of Indonesia since 1985. Teaching, research, and practical services are aligned, resulting a full spectrum of academic achievement. Majoring in Software Engineering as professional track record, he has made some scientific contribution such as Software Requirement Specification (SRS) patterns representation method and FrontCRM Framework. Graduated from Bandung Institute of Technology (ITB) in 1985, holds Master of Science in Computer Science from the University of New Brunswick – Canada in 1991, and awarded Philosophical Doctor in Computer Science from the University of Indonesia in 2007. Currently he is one of The National Research Council (DRN) member on ICT Commission, member of ICT Evaluation Working Group of The National ICT Council (DetikNAS), and Chairman of IPKIN.
