Penerapan Design Patterns Pada Rancang Bangun Peranti Lunak Melalui Analisis Commonality & Variability Domain Masalah Aplikasi
Eko K. Budiardjo1, Herson C. Mandiangan2,
1
Fakultas Ilmu Komputer – Universitas Indonesia, Gedung Fasilkom UI, Kampus UI Depok, Depok - 16424, eko@cs.ui.ac.id
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
data-data lain yang hampir serupa, serta data-data-data-data yang khusus sesuai dengan keinginan masing-masing perusahaan.
Pengguna Basis Data Menambah Data Pegawai Mencari Data Pegawai Mengubah Data Pegawai Menghapus Data Pegawai
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) terhadap data pegawai.
End-to-end interaksi
antara pengunan dan
sistem komputer dapat
dimodelkan dengan Use
Case Diagram pada Gb. 1. 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
AbstractFactory Pattern ini memiliki keuntungan dan kerugian sebagai berikut:
1. Memisahkan kelas-kelas konkrit. Pattern ini membantu untuk mengendalikan kelas-kelas 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
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
metode-metode 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:
HR_Core_Product
HR_Vary_Product_1
Application Client
Varian Produk Pertama
Varian Produk Kedua Common Produk untuk Data Pegawai
HR_Core_AbstractFactory • NomorInduk • Nama • StatusPernikahan • TanggunganKeluarga • TanggalLahir • Alamat • GajiPokok CariPegawai(…) HapusPegawai(…) HR_Vary_AbsFact_2 • Jabatan • Telpon • KodePos • TunjanganJabatan • TunjanganKeluarga • Bank • NomorRekening TambahPegawai(…) UbahPegawai(…) HR_Vary_AbsFact_1 • JenisKelamin • TempatLahir • Kota • TglMasukKerja • TunjanganJabatan • UangMakan • UangTransport TambahPegawai(…) UbahPegawai(…) HR_Vary_Product_2 HR_Core_Product HR_Core_Product HR_Vary_Product_1 HR_Vary_Product_1 Application Client
Varian Produk Pertama
Varian Produk Kedua Common Produk untuk Data Pegawai
HR_Core_AbstractFactory • NomorInduk • Nama • StatusPernikahan • TanggunganKeluarga • TanggalLahir • Alamat • GajiPokok CariPegawai(…) HapusPegawai(…) HR_Vary_AbsFact_2 • Jabatan • Telpon • KodePos • TunjanganJabatan • TunjanganKeluarga • Bank • NomorRekening TambahPegawai(…) UbahPegawai(…) HR_Vary_AbsFact_1 • JenisKelamin • TempatLahir • Kota • TglMasukKerja • TunjanganJabatan • UangMakan • UangTransport TambahPegawai(…) UbahPegawai(…) HR_Core_AbstractFactory • NomorInduk • Nama • StatusPernikahan • TanggunganKeluarga • TanggalLahir • Alamat • GajiPokok CariPegawai(…) HapusPegawai(…) HR_Vary_AbsFact_2 • Jabatan • Telpon • KodePos • TunjanganJabatan • TunjanganKeluarga • Bank • NomorRekening TambahPegawai(…) UbahPegawai(…) HR_Vary_AbsFact_1 • JenisKelamin • TempatLahir • Kota • TglMasukKerja • TunjanganJabatan • UangMakan • UangTransport TambahPegawai(…) UbahPegawai(…) HR_Vary_Product_2 HR_Vary_Product_2
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
lagi kelas turunan
berikutnya. Kelas induk diperlihatkan pada Gd.3.
Mengikuti pola
AbstractFactory dapat kita gambarkan rancang-an Class Diagram baru yang telah menerapkan
AbstractFactory Pattern, seperti yang diperlihatkan pada Gb. 4.
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 Bachmann, F., Bass, L, 2001, Managing Variability in Software Architectures
2 Cooper, J.W., 2001, Visual Basic Design Patterns: VB 6.0 and VB.NET, Addison-Wesley Professional. 3. Dobing, B., Parsons, J., 2006, How UM is Used, Communications of The ACM, May 2006/Vol. 49, No. 5 4. Gamma, E., et al., 1995, Design Patterns : Elements of Reusable Object-oriented Software, Professional
Computing Series. Addison-Wesley.
5. 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.
6. Larman, C., 2002, Applying UML and Patterns, Second Edition, Prentice Hall PTR.
7. Leffingwell, D., Widrig, D., 200, Managing Software Requirements - A Unified Approach, Addison-Wesley.
8. 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.
