Membangun Mesin Aturan Bisnis dengan Drools - Kekuatan untuk SMEople

Salah satu hal yang paling menakjubkan tentang bekerja dalam pengembangan perangkat lunak adalah kemampuan untuk bekerja di banyak industri yang berbeda - terutama jika Anda seorang konsultan. Sebagian besar keterampilan pengembangan perangkat lunak yang Anda pelajari saat bekerja dalam satu industri secara langsung dapat ditransfer ke sejumlah industri, perusahaan, proyek, dan ceruk lainnya.

Saya berbicara tentang topik seperti desain basis data, pola desain, tata letak GUI, manajemen acara, dll. Kemudian, tentu saja, ada topik khusus untuk satu industri, perusahaan, atau proyek tertentu.

SME Bertemu IT, Transfer Pengetahuan Dimulai

Di sinilah Subject Matter Expert (SME) masuk. UKM biasanya akan sangat terlibat dalam tahap desain proyek.

UKM telah bekerja dalam industri untuk jangka waktu yang lama, mengetahui istilah, dan memahami logika bisnis di balik pengkodean. UKM mungkin memiliki beberapa pemahaman tentang pengembangan perangkat lunak, tetapi ini tidak diperlukan agar proyek berhasil.

Untuk banyak proyek, kecuali jika pengembang perangkat lunak memiliki pemahaman yang baik tentang logika bisnis, menyelesaikan aplikasi perangkat lunak yang sukses akan relatif sulit. Jumlah waktu yang perlu dihabiskan untuk transfer pengetahuan akan sangat bervariasi berdasarkan kompleksitas proyek.

Dengan asumsi bahwa pendekatan tangkas diambil dan satu atau lebih UKM tersedia selama fase pengembangan proyek, transfer pengetahuan akan berlanjut selama semua tahap proyek.

Bagaimana Jika Transfer Pengetahuan Lengkap Tidak Layak?

Tergantung pada industri dan proyeknya, UKM mungkin tidak dapat memberikan transfer pengetahuan yang lengkap.

Misalnya, bayangkan jika UKM adalah seorang dokter dengan pengalaman 25 tahun, dan Anda memiliki 6 bulan untuk menyelesaikan sebuah proyek. Atau, bayangkan UKM sebagai ahli biologi dengan pengalaman 40 tahun – tingkat pengetahuan seperti itu tidak dapat ditransfer dalam kerangka waktu yang realistis untuk proyek pengembangan perangkat lunak.

Tetapi bagaimana jika area pengetahuan itu dinamis?

Biasanya, perangkat lunak dirilis pada jadwal yang ditetapkan berdasarkan waktu atau fitur. Namun, aturan bisnis dalam beberapa industri lebih sering berubah.

Dalam banyak kasus, mungkin tidak layak untuk merilis perangkat lunak sesering yang diperlukan untuk mengikuti perubahan industri. Memiliki kemampuan untuk mengeksternalisasi aturan bisnis dalam mesin aturan bisnis mungkin masuk akal dalam skenario seperti itu. Kemampuan proyek perangkat lunak untuk dapat bertahan terhadap perubahan akan sangat membantu dalam memastikan keberhasilan jangka panjangnya.

Kapan dan Di Mana Mesin Aturan Masuk Akal?

Untuk banyak proyek perangkat lunak, transfer pengetahuan penuh dapat dilakukan, dan logika bisnis dikodekan dalam bahasa komputer seperti C# atau Java.

Namun, ada subset proyek di mana jumlah pemahaman tentang subjek tertentu sangat besar, atau aturan bisnis tunduk pada begitu banyak perubahan sehingga lebih masuk akal bagi non-programmer untuk memiliki akses langsung ke logika bisnis. Ini adalah subjek dari tutorial ini; dengan mengingat hal itu, mari kita bahas Rules Engines secara mendalam.

Apa Itu Mesin Aturan Bisnis?

Mesin aturan adalah alat untuk menjalankan aturan bisnis. Aturan bisnis terdiri dari fakta dan pernyataan bersyarat. Setiap pernyataan "jika-maka" yang muncul dalam logika bisnis tradisional memenuhi syarat sebagai aturan bisnis.

Misalnya: jika seorang karyawan sakit lebih dari 5 hari berturut-turut dan tidak memiliki surat dokter, maka mereka perlu ditulis. Jika rekan bisnis belum dihubungi selama lebih dari 6 bulan dan mereka tidak melakukan pembelian selama waktu itu , mungkin sudah waktunya untuk mengirimi mereka email ramah. Jika pasien memiliki suhu tubuh yang tinggi, masalah penglihatan, dan ada riwayat glaukoma dalam keluarga, mungkin sudah waktunya untuk meminta MRI tambahan atau tes lainnya.

Bagaimana UKM Menulis Aturan Bisnis?

Alih-alih mengharapkan UKM untuk belajar Java, C#, atau bahasa pemrograman lain, TI akan membuat bahasa mini untuk mengekspresikan aturan bisnis mereka. Blok bangunan dari aturan ini akan terdiri dari fakta yang dapat ditanyakan. Beberapa contoh fakta menurut bidang industri/praktik adalah:

• Sumber Daya Manusia: gaji, posisi, manajer, tahun dengan perusahaan
• Medis: suhu, tekanan darah, obat-obatan saat ini
• Finansial: harga saham saat ini, harga tertinggi/terendah 52 minggu, rasio P/E, tanggal rilis pendapatan berikutnya

Pada dasarnya, informasi yang diperlukan untuk membuat keputusan bisnis harus tersedia untuk UKM secara efisien.

Seperti Apa Rules Ini?

Untuk sisa tutorial mesin aturan ini, saya akan menggunakan Drools, mesin aturan berbasis Java open-source, yang dapat ditemukan di www.drools.org dan merupakan proyek JBoss. Di Drools, aturan ditulis sebagai kode Java dan memiliki struktur berikut:

Pernyataan impor buka di sini:

 rule “Name of rule” when “The if” part of the business logic goes here. then The “then” part of the business logic goes here. end

Mengiler dan Memori Kerja

Drools menggunakan konsep yang disebut Working Memory.

Kode aplikasi akan bertanggung jawab untuk memuat fakta yang sesuai ke dalam Memori Kerja sehingga UKM dapat menulis aturan yang menanyakan fakta tersebut. Hanya fakta yang relevan dengan logika bisnis aplikasi yang harus dimuat ke dalam Memori Kerja, untuk menjaga agar mesin aturan tetap berjalan pada kecepatan tertinggi.

Misalnya, jika sebuah aplikasi menentukan apakah akan menyetujui pinjaman pelanggan, fakta yang relevan akan mencakup gaji, nilai kredit, dan pinjaman yang belum dibayar. Fakta yang tidak relevan akan mencakup hari dalam seminggu atau jenis kelamin.

Evaluasi Aturan

Setelah Memori Kerja Drools dimuat dengan aturan dan fakta, aturan dievaluasi menurut bagian "lalu" dari aturannya. Jika bagian “then” bernilai true, bagian “when” dari aturan akan dieksekusi.

Biasanya, semua aturan dievaluasi sekaligus, meskipun aturan dapat dikelompokkan bersama dan dievaluasi per kelompok. Bagian "kemudian" dari aturan dapat mengubah isi Memori Kerja. Ketika ini terjadi, Drools akan mengevaluasi kembali semua aturan untuk melihat apakah ada aturan yang sekarang dievaluasi menjadi benar. Jika demikian, bagian "kapan" mereka akan dieksekusi.

Sifat rekursif dari evaluasi aturan ini bisa menjadi berkah atau kutukan – jadi aturan perlu dibuat dengan mempertimbangkan arsitektur ini.

Sisi "Jika" dari Aturan Mengiler

Dalam Drools, fakta diwakili oleh objek. Keberadaan atau ketidakberadaan suatu tipe objek dapat ditanyakan. Selain itu, atribut objek dapat ditanyakan juga.

Berikut adalah beberapa contoh:

Tentukan apakah seorang karyawan berpenghasilan lebih dari 100.000.

 Employee(salary > 100000)

Tentukan apakah seorang pasien memiliki kadar kolesterol lebih besar dari 200 dan menggunakan Lipitor.

 Patient(cholesterol > 200, medications.contains(“lipitor”))

Tentukan apakah harga saham berada dalam 1% dari harga tertinggi tahunannya.

 Stock(price >= (yearHigh * .99))

Menggabungkan Kueri

Saat menulis logika bisnis yang kompleks, aturan bisnis dapat menggabungkan kueri dengan menggunakan operator Boolean AND, OR, dan NOT dan bersarang menggunakan tanda kurung.

Sebagai contoh:

Tentukan apakah ada manajer yang berpenghasilan kurang dari $75.000 atau direktur yang berpenghasilan kurang dari $100.000.

 Employee(position.Equals(“Manager”),salary<75000) OR Employee(position.Equals(“Directory”),salary<100000)

Menggunakan Beberapa Jenis Objek

Semua contoh sejauh ini didasarkan pada satu jenis objek, seperti Karyawan atau Pasien. Namun, Drools memungkinkan kueri didasarkan pada beberapa tipe objek.

Sebagai contoh:

Tentukan apakah pelanggan memiliki gaji lebih tinggi dari $50.000 dan belum mengajukan kebangkrutan.

 Customer(salary>50000) AND not exists Bankruptcy()

Sisi “Lalu” dari Aturan

Sisi "kemudian" dari aturan menentukan apa yang akan terjadi ketika setidaknya ada satu hasil di bagian "kapan" dari aturan.

Di Drools, apa pun yang dapat ditulis di Java dapat ditulis di bagian aturan "lalu". Namun, untuk membuat aturan lebih dapat digunakan kembali, umumnya merupakan ide yang baik untuk tidak menempatkan I/O, kode kontrol aliran, atau kode eksekusi umum apa pun di dalam aturan.

Sebagai alternatif, bagian "kemudian" dari aturan dapat digunakan untuk memodifikasi Memori Kerja. Praktik umum adalah memasukkan fakta ke dalam Memori Kerja ketika aturan dievaluasi sebagai benar.

Sebagai contoh:

 rule “LoanApproved” when Customer(credit>700) && not exist LoanOutstanding() then insert(new LoanApproval()) end

Bagaimana Kita Tahu Ketika Aturan Telah Dievaluasi sebagai Benar?

Setelah semua aturan diaktifkan, aplikasi perlu mengetahui aturan mana yang dievaluasi sebagai benar. Jika aturan memasukkan objek ke dalam Memori Kerja ketika mereka mengevaluasi benar, kode dapat ditulis untuk meminta Memori Kerja untuk objek tersebut.

Dalam contoh di atas, setelah semua aturan diaktifkan, kueri dapat dibuat untuk melihat apakah objek LoanApproval() ada di Memori Kerja.

 query "GetLoanApproval " $result: LoanApproval() end

Bagaimana Mesin Aturan Bisnis Berinteraksi dengan Aplikasi?

Aplikasi khas berisi logika bisnis, GUI, I/O dan aliran kode kontrol.

Misalnya, aplikasi dapat memproses permintaan pengguna seperti ini:

 GUI ? Flow Control ? I/O ? Business Logic ? I/O ? Flow Control ? GUI

Menyematkan mesin aturan menambahkan beberapa langkah ke proses ini:

 GUI ? Flow Control ? I/O ? Create Rules Engine Session ? Add Facts to Working Memory ? Fire Rules ? Determine which rules have evaluated true ? I/O ? Flow Control ? GUI

Bagaimana UKM bekerja dengan Aturan?

Membuat, Mengedit, dan Menghapus Aturan

Agar UKM dapat bekerja dengan aturan, mereka membutuhkan GUI yang mudah digunakan. Beberapa mesin aturan bisnis dikirimkan dengan antarmuka seperti itu.

Misalnya, Drools dikirimkan dengan dua GUI yang menurut saya ramah pengguna. Yang pertama menyerupai spreadsheet dan memungkinkan UKM untuk membuat aturan tanpa pernah menulis kode yang sebenarnya. GUI kedua memungkinkan logika bisnis yang lebih kompleks untuk dibuat.

Meskipun kedua GUI ini dapat membantu untuk memasuki kondisi sederhana, keduanya tidak akan berfungsi karena logika bisnis menjadi lebih kompleks. Dalam hal ini Anda harus membuat GUI kustom Anda sendiri.

Elemen GUI Kustom SME

Agar UKM dapat bekerja secara efektif, pertimbangkan untuk membuat GUI kustom dengan kemampuan berikut:

• Pemeriksa Sintaks – tombol “periksa sintaks” dapat memanggil kode Drools untuk memeriksa kemungkinan kesalahan dan nomor barisnya.
• Seret/Lepas – daripada mengharuskan UKM untuk mengingat Objek dan Atribut yang tersedia untuk mereka, pertimbangkan untuk menawarkan mereka daftar pilihan yang dapat mereka seret dan lepas.
• Antarmuka Web – antarmuka klien tipis akan tersedia untuk UKM tanpa masalah distribusi. Ini akan berguna karena GUI membutuhkan fitur tambahan dan pemeliharaan umum.
• Penguji Aturan – memiliki kemampuan untuk menguji aturan individu tanpa berinteraksi dengan seluruh aplikasi akan sangat meningkatkan produktivitas UKM. Izinkan SME GUI untuk menentukan fakta dan kemudian jalankan aturan individu.

Di Mana Seharusnya Aturan Disimpan?

Di Drools biasanya ada dua cara untuk menyimpan aturan. Drools bekerja di luar kotak dengan aturan berbasis file yang biasanya memiliki ekstensi .drl.

Ini bekerja dengan baik ketika jumlah aturan kecil. Seiring bertambahnya jumlah aturan, Anda akan ingin menggunakan database. Menyimpan dan mengambil aturan dari database membutuhkan lebih banyak pekerjaan, tetapi akan memberi Anda arsitektur yang jauh lebih mudah dikelola.

Tutorial mesin aturan ini hanya menyentuh sebagian kecil dari Bahasa Aturan Drools. Untuk deskripsi lengkap, silakan berkonsultasi di dokumentasi referensi resmi.

Keputusan untuk menggunakan mesin aturan tidak boleh dibuat ringan. Sementara mesin aturan akan membuat aplikasi Anda lebih dapat dikembangkan oleh UKM, itu juga akan menjadi lebih rumit untuk dikembangkan, diuji, dan disebarkan. Untuk pertimbangan tambahan tentang topik ini, Anda mungkin ingin meninjau panduan berikut.

Sekarang kami dapat melanjutkan untuk menunjukkan kepada Anda sesuatu yang sedikit lebih menarik – contoh nyata sederhana dari aksi Drools, dalam kasus penggunaan yang sebagian besar pembaca blog Toptal harus kenal.

Menggunakan Air liur Dalam Skenario Kehidupan Nyata

Toptal, penyedia terkemuka bakat Pengembangan Perangkat Lunak tingkat tinggi, saat ini menggunakan perangkat lunak Pelacakan Pelamar untuk membawa pelamar kerja melalui berbagai tahapan dalam proses perekrutan. Berikut adalah diagram alur visual yang disederhanakan dari proses ini:

Saat ini, logika bisnis untuk memutuskan apakah pelamar akan melanjutkan proses perekrutan telah dikodekan ke dalam perangkat lunak. Setiap kali Sumber Daya Manusia perlu mengubah logika bisnis, mereka harus melibatkan TI. Mereka ingin memiliki kemampuan untuk secara langsung mengubah cara perangkat lunak mereka berjalan.

Perangkat lunak Pelacakan Pelamar akan dimodifikasi untuk menjalankan aturan yang disediakan SDM di setiap titik keputusan dalam proses perekrutan. HR akan memiliki objek 'Calon' yang akan mewakili pelamar kerja yang statusnya baru saja diubah oleh entri awal, penyelesaian ujian online, atau sejumlah faktor yang berbeda. Objek Kandidat akan memiliki bidang untuk mewakili pengalaman, nilai ujian, nilai wawancara, dll.

Contoh berikut menyajikan seperangkat aturan yang disederhanakan untuk pertimbangan Anda. Itu belum digunakan, itu hanya contoh sederhana yang terdiri dari empat aturan yang saling berhubungan:

• Dikirim -> Pengujian
• Pengujian -> Wawancara
• Wawancara -> Proyek
• Proyek -> Mempekerjakan

Dikirim -> Pengujian

Berdasarkan kebutuhan klien saat ini, HR ingin menulis aturan yang akan menentukan apakah seorang kandidat harus dijadwalkan untuk pengujian online.

 Rule “Schedule For Testing” when $candidate: Candidate(status=='Submitted',yrsExperience >= 10, skill(name=='Java', yrsExperience>=5) or Skill(name=='C#', yrsExperience>=5)) then $candidate.setStatus('Testing'); end

Pengujian -> Wawancara

Setelah kandidat mengikuti ujian online, skor mereka perlu dievaluasi. HR ingin memiliki kendali atas aturan ini juga. Ujian online menguji kemampuan kandidat untuk memahami teori pengembangan perangkat lunak, pemecahan masalah, dan sintaksis. HR ingin memutuskan campuran skor apa yang memungkinkan kandidat dipertimbangkan untuk wawancara teknis.

 Rule “Schedule For Interview” when $candidate: Candidate(status=='Testing', testScore(theory>.8 && syntax>.6 && problemSolving>.8); then $candidate.setStatus('Interview'); end

Wawancara -> Proyek

Wawancara teknis akan menguji kemampuan kandidat untuk berbicara tentang pengalaman mereka, menjawab pertanyaan pemecahan masalah, dan itu akan menguji kemampuan mereka untuk berkomunikasi secara umum. HR akan menulis aturan yang menentukan skor kelulusan untuk wawancara teknis.

 Rule “Schedule For Project” when $candidate: Candidate(status=='Interview', interviewScore(speakExperience>.9 && problemSolving>.8 && communication>.9 ); then $candidate.setStatus('Project'); end

Proyek -> Mempekerjakan

Jika seorang kandidat lulus wawancara teknis, mereka akan diberikan proyek pemrograman off-line. Mereka akan mengirimkan proyek dan akan dinilai untuk kelengkapan, arsitektur, dan GUI.

 Rule “Schedule For Hiring” when $candidate: Candidate(status=='Project', projectScore(completeness>.8 && architecture>.9 && gui>.7 ); then $candidate.setStatus('Hiring'); end

Seperti yang Anda lihat, bahkan contoh dasar ini menawarkan sejumlah kemungkinan untuk HR, dan dapat merampingkan operasi. Fakta bahwa SDM dapat mengubah aturan tanpa harus melibatkan TI dalam proses pasti akan menghemat waktu dan mempercepat proses penyaringan.

Karena aturan dapat diubah dengan cepat, departemen SDM juga akan memiliki lebih banyak fleksibilitas. Misalnya, HR dapat memperluas atau membatasi proses seleksi dengan menetapkan parameter yang berbeda.

Jika ada terlalu banyak kandidat yang mencentang semua kotak yang tepat, standar dapat dinaikkan dalam hitungan menit, sehingga mengurangi jumlah kandidat. Sebagai alternatif, jika proses menghasilkan sedikit atau tidak ada kandidat yang memenuhi semua persyaratan, SDM dapat memilih untuk mengurangi atau menghilangkan beberapa standar, mengalihkan fokus mereka ke keterampilan yang lebih relevan hingga jumlah kandidat yang memadai memenuhi persyaratan.