Drools ile İş Kuralları Motorları Oluşturma - KOBİ'lere Güç

Yazılım geliştirmede çalışmanın en şaşırtıcı yanlarından biri, birçok farklı sektörde çalışabilme yeteneğidir - özellikle de danışmansanız. Bir sektörde çalışırken öğrendiğiniz çoğu yazılım geliştirme becerisi, herhangi bir sayıdaki diğer sektörlere, şirketlere, projelere ve nişlere doğrudan aktarılabilir.

Veritabanı tasarımı, tasarım kalıpları, GUI düzenleri, olay yönetimi vb. konulardan bahsediyorum. Sonra elbette belirli bir sektöre, şirkete veya projeye özgü konular var.

KOBİ BT ile Buluşuyor, Bilgi Transferi Başlıyor

Konu Uzmanının (KOBİ) devreye girdiği yer burasıdır. Bir KOBİ tipik olarak projenin tasarım aşamasına çok dahil olacaktır.

KOBİ, sektörde uzun süredir çalışıyor, lingo'yu biliyor ve kodlamanın arkasındaki iş mantığını anlıyor. KOBİ'nin yazılım geliştirme konusunda biraz bilgisi olabilir, ancak projenin başarılı olması için bu gerekli değildir.

Birçok proje için, yazılım geliştiricisi iş mantığını çok iyi anlamadıkça, başarılı bir yazılım uygulamasını tamamlamak nispeten zor olacaktır. Bilgi aktarımı için harcanması gereken süre, projenin karmaşıklığına bağlı olarak büyük ölçüde değişecektir.

Çevik bir yaklaşımın benimsendiği ve projenin geliştirme aşaması boyunca bir veya daha fazla KOBİ'nin mevcut olduğu varsayıldığında, projenin tüm aşamalarında bilgi aktarımı devam edecektir.

Ya Tam Bilgi Transferi Mümkün Değilse?

Sektöre ve projeye bağlı olarak, bir KOBİ'nin eksiksiz bilgi aktarımı sağlaması mümkün olmayabilir.

Örneğin, KOBİ'nin 25 yıllık deneyime sahip bir hekim olduğunu ve bir projeyi tamamlamak için 6 ayınız olduğunu düşünün. Veya KOBİ'yi 40 yıllık deneyime sahip bir biyolog olarak hayal edin - böyle bir bilgi düzeyi, yazılım geliştirme projeleri için gerçekçi bir zaman diliminde aktarılamaz.

Peki ya bilgi alanı dinamikse?

Tipik olarak, yazılım, zamana veya özelliklere dayalı olarak belirlenmiş bir programa göre yayınlanır. Ancak, bazı endüstrilerdeki iş kuralları çok daha sık değişmektedir.

Çoğu durumda, endüstri değişikliklerine ayak uydurmak için gereken sıklıkta yazılım yayınlamak mümkün olmayabilir. Bir iş kuralları motoru içinde iş kurallarını dışsallaştırma yeteneğine sahip olmak, bu tür senaryolarda anlamlı olabilir. Bir yazılım projesinin değişime dayanabilme yeteneği, nihai uzun vadeli başarısını güvence altına almak için uzun bir yol kat edecektir.

Kural Motorları Ne Zaman ve Nerede Mantıklı?

Birçok yazılım projesi için tam bilgi aktarımının gerçekleşmesi ve iş mantığının C# veya Java gibi bir bilgisayar dilinde kodlanması mümkündür.

Bununla birlikte, belirli bir konunun anlaşılmasının çok büyük olduğu veya iş kurallarının o kadar çok değişikliğe tabi olduğu ve programcı olmayan birinin iş mantığına doğrudan erişiminin daha mantıklı olduğu bir proje alt kümesi vardır. Bu, bu eğitimin konusudur; Bunu akılda tutarak, Kural Motorlarını derinlemesine tartışalım.

İş Kuralları Motoru Nedir?

Kural motoru, iş kurallarını yürütmek için bir araçtır. İş kuralları, gerçeklerden ve koşullu ifadelerden oluşur. Geleneksel iş mantığında görünen herhangi bir "eğer-o zaman" ifadesi bir iş kuralı olarak nitelendirilir.

Örneğin : Bir çalışan 5 günden fazla bir süredir hastaysa ve doktor raporu yoksa , yazılması gerekir. Bir iş ortağıyla 6 aydan uzun süredir iletişim kurulmamışsa ve bu süre içinde herhangi bir satın alma işlemi yapmamışsa, onlara samimi bir e-posta göndermenin zamanı gelmiş olabilir. Bir hastanın vücut ısısı yüksekse, görme sorunları varsa ve ailede glokom öyküsü varsa , ek MRI veya başka testler istemenin zamanı gelmiş olabilir.

KOBİ'ler İş Kurallarını Nasıl Yazıyor?

Bir KOBİ'nin Java, C# veya başka bir programlama dili öğrenmesini beklemek yerine BT, onun iş kurallarını ifade etmesi için mini bir dil oluşturacaktır. Bu kuralların yapı taşları, sorgulanabilecek gerçeklerden oluşacaktır. Endüstri/uygulama alanlarına göre bazı gerçek örnekleri şunlardır:

• İnsan Kaynakları: maaş, pozisyon, yönetici, şirketteki yıllar
• Tıbbi: sıcaklık, kan basıncı, mevcut ilaç
• Finansal: mevcut hisse senedi fiyatı, 52 haftalık en yüksek/en düşük fiyat, F/K oranı, bir sonraki kazanç açıklama tarihi

Esasen, iş kararları vermek için gerekli bilgiler KOBİ'ye basitleştirilmiş bir şekilde sunulmalıdır.

Bu Kurallar Neye benziyor?

Bu kural motoru eğitiminin geri kalanında, www.drools.org adresinde bulunabilen ve bir JBoss projesi olan açık kaynaklı Java tabanlı bir kural motoru olan Drools'u kullanacağım. Drools'da kurallar Java kodu olarak yazılır ve aşağıdaki yapıya sahiptir:

İçe aktarma ifadeleri buraya gelir:

 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

Salyalar ve Çalışma Belleği

Drools, Çalışma Belleği adlı bir kavram kullanır.

Uygulama kodu, KOBİ'lerin bu gerçekleri sorgulayan kurallar yazabilmesi için uygun gerçekleri Çalışma Belleğine yüklemekten sorumlu olacaktır. Kural motorunun en yüksek hızda çalışmasını sağlamak için yalnızca uygulama iş mantığıyla ilgili gerçekler Çalışma Belleğine yüklenmelidir.

Örneğin, bir uygulama bir müşterinin krediyi onaylayıp onaylamayacağını belirliyorsa, ilgili gerçekler maaşı, kredi puanlarını ve ödenmemiş kredileri içerir. Alakalı olmayan gerçekler haftanın gününü veya cinsiyeti içerir.

Kural Değerlendirmesi

Drools Working Memory, kurallar ve gerçeklerle yüklendikten sonra kurallar, kurallarının “o zaman” kısmına göre değerlendirilir. "Then" kısmı doğru olarak değerlendirilirse, kuralın "ne zaman" kısmı yürütülür.

Kural olarak, tüm kurallar bir kerede değerlendirilir, ancak kurallar birlikte gruplandırılabilir ve grup bazında değerlendirilebilir. Kuralın “o zaman” kısmı, Çalışma Belleğinin içeriğini değiştirebilir. Bu gerçekleştiğinde, Drools, herhangi bir kuralın artık doğru olarak değerlendirilip değerlendirilmediğini görmek için tüm kuralları yeniden değerlendirecektir. Eğer öyleyse, "ne zaman" kısımları yürütülecektir.

Kural değerlendirmelerinin bu özyinelemeli doğası bir lütuf veya bir lanet olabilir - bu nedenle kuralların bu mimari akılda tutularak oluşturulması gerekir.

Saçmalama Kuralının "Eğer" Tarafı

Drools'da gerçekler nesnelerle temsil edilir. Bir nesne türünün varlığı veya yokluğu sorgulanabilir. Ek olarak, nesnenin nitelikleri de sorgulanabilir.

İşte birkaç örnek:

Bir çalışanın 100.000'den fazla kazanıp kazanmadığını belirleyin.

 Employee(salary > 100000)

Bir hastanın kolesterol seviyesinin 200'ün üzerinde olup olmadığını ve Lipitor alıp almadığını belirleyin.

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

Bir hisse senedinin fiyatının, yıllık en yüksek değerinin %1'i dahilinde olup olmadığını belirleyin.

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

Sorguları Birleştirme

Karmaşık iş mantığı yazarken, iş kuralları, AND, OR ve NOT Boole operatörlerini kullanarak ve parantez kullanarak iç içe geçerek sorguları birleştirebilir.

Örneğin:

75.000 dolardan az kazanan bir yönetici mi yoksa 100.000 dolardan az kazanan bir yönetici mi olduğunu belirleyin.

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

Birden Çok Nesne Türünü Kullanma

Şimdiye kadarki örneklerin tümü, Çalışan veya Hasta gibi tek bir nesne türüne dayanmaktadır. Ancak, Drools, sorguların birden çok nesne türüne dayalı olmasına izin verir.

Örneğin:

Müşterinin 50.000 dolardan yüksek maaşı olup olmadığını ve iflas başvurusunda bulunmamış olup olmadığını belirleyin.

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

Bir Kuralın "Sonra" Tarafı

Bir kuralın "o zaman" tarafı, kuralın "ne zaman" bölümünde en az bir sonuç olduğunda ne olacağını belirler.

Drools'da Java ile yazılabilen her şey kuralın "then" kısmına yazılabilir. Ancak, kuralları daha fazla yeniden kullanılabilir hale getirmek için, bir kurala herhangi bir G/Ç, akış kontrol kodu veya genel yürütme kodu yerleştirmemek genellikle iyi bir fikirdir.

Alternatif olarak, bir kuralın "sonra" kısmı Çalışma Belleğini değiştirmek için kullanılabilir. Yaygın bir uygulama, bir kural doğru olarak değerlendirildiğinde Çalışma Belleğine bir olgu eklemektir.

Örneğin:

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

Bir Kuralın Doğru Olarak Değerlendirildiğini Nasıl Anlarız?

Tüm kurallar tetiklendikten sonra, uygulamanın hangi kuralların doğru olarak değerlendirildiğini bilmesi gerekir. Kurallar, true olarak değerlendirdiklerinde Çalışma Belleğine nesneler eklerse, bu nesneler için Çalışma Belleğini sorgulamak için kod yazılabilir.

Yukarıdaki örnekte, tüm kurallar tetiklendikten sonra, bir LoanApproval() nesnesinin Çalışma Belleğinde olup olmadığını görmek için bir sorgu yapılabilir.

 query "GetLoanApproval " $result: LoanApproval() end

Bir İş Kuralları Motoru Bir Uygulamayla Nasıl Etkileşime Girer?

Tipik uygulamalar iş mantığı, GUI, G/Ç ve kontrol kodu akışını içerir.

Örneğin, bir uygulama aşağıdaki gibi bir kullanıcı isteğini işleyebilir:

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

Bir kural motoru gömmek, bu işleme birkaç adım ekler:

 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

KOBİ'ler Kurallarla nasıl çalışır?

Kural Oluşturma, Düzenleme ve Silme

KOBİ'lerin kurallarla çalışabilmeleri için kullanıcı dostu bir GUI'ye ihtiyaçları olacaktır. Bazı iş kuralları motorları böyle bir arayüzle birlikte gönderilir.

Örneğin, Drools, kullanıcı dostu bulduğum iki GUI ile birlikte gelir. İlki, bir elektronik tabloya benzer ve KOBİ'lerin herhangi bir gerçek kod yazmadan kurallar oluşturmasına olanak tanır. İkinci GUI, daha karmaşık iş mantığının oluşturulmasına izin verir.

Bu GUI'lerin her ikisi de basit koşullara girmek için yardımcı olabilirken, iş mantığı daha karmaşık hale geldikçe çalışmazlar. Bu durumda kendi özel GUI'nizi oluşturmanız gerekecektir.

KOBİ Özel GUI'sinin Öğeleri

KOBİ'lerin verimli çalışabilmesi için aşağıdaki yeteneklere sahip özel bir GUI oluşturmayı düşünün:

• Sözdizimi Denetleyicisi - bir "sözdizimini kontrol et" düğmesi, olası hataları ve satır numaralarını kontrol etmek için Drools kodunu çağırabilir.
• Sürükle/Bırak – bir KOBİ'nin kendilerine sunulan Nesneleri ve Nitelikleri hatırlamasını istemek yerine, onlara sürükleyip bırakabilecekleri bir seçim listesi sunmayı düşünün.
• Web Arayüzü – KOBİ'lere dağıtım endişesi olmadan bir ince istemci arayüzü sunulacaktır. GUI'nin ek özelliklere ve genel bakıma ihtiyacı olduğu için bu kullanışlı olacaktır.
• Rule Tester – Uygulamanın tamamıyla etkileşime girmeden bireysel kuralları test etme yeteneğine sahip olmak, KOBİ üretkenliğini büyük ölçüde artıracaktır. KOBİ GUI'sinin gerçekleri belirlemesine ve ardından bireysel kuralları başlatmasına izin verin.

Kurallar Nerede Saklanmalı?

Drools'da kuralları saklamanın genellikle iki yolu vardır. Drools, genellikle .drl uzantısına sahip olacak dosya tabanlı kurallarla kutudan çıktığı gibi çalışır.

Bu, kural sayısı az olduğunda işe yarar. Kuralların sayısı arttıkça, bir veritabanı kullanmak isteyeceksiniz. Bir veritabanından kuralları depolamak ve almak daha fazla iş gerektirir, ancak size çok daha yönetilebilir bir mimari sağlamalıdır.

Bu kural motoru öğreticisi, Drools Kural Dilinin yalnızca çok küçük bir bölümüne değindi. Tam bir açıklama için lütfen resmi başvuru belgelerine bakın.

Bir kural motoru kullanma kararı hafife alınmamalıdır. Bir kural motoru, uygulamanızı KOBİ'ler tarafından daha genişletilebilir hale getirirken, geliştirmesi, test etmesi ve dağıtması da daha karmaşık hale gelecektir. Bu konuyla ilgili ek hususlar için aşağıdaki yönergeleri gözden geçirmek isteyebilirsiniz.

Şimdi size biraz daha ilginç bir şey göstermeye devam edebiliriz - çoğu Toptal blog okuyucusunun tanıdık bulması gereken bir kullanım durumunda, Drools'un gerçek hayattan basit bir örneği.

Gerçek Hayat Senaryosunda Drools Kullanmak

Önde gelen bir üst düzey Yazılım Geliştirme yeteneği sağlayıcısı olan Toptal, şu anda işe başvuranları işe alma sürecindeki çeşitli aşamalardan geçirmek için Başvuru Sahibi İzleme yazılımını kullanıyor. İşte bu sürecin basitleştirilmiş bir görsel akış şeması:

Şu anda, bir başvuru sahibinin işe alım sürecine devam edip etmeyeceğine karar vermek için iş mantığı, yazılıma sabit olarak kodlanmıştır. İnsan Kaynaklarının iş mantığını değiştirmesi gerektiğinde, BT'yi dahil etmeleri gerekir. Yazılımlarının çalışma şeklini doğrudan değiştirme yeteneğine sahip olmak istiyorlar.

Başvuru Sahibi İzleme yazılımı, işe alım sürecindeki her karar noktasında İK tarafından sağlanan kuralları çalıştıracak şekilde değiştirilecektir. İK, statüsü bir ilk giriş, çevrimiçi sınavın tamamlanması veya bir dizi farklı faktör tarafından yeni değiştirilen bir iş başvuru sahibini temsil edecek bir 'Aday' nesnesine sahip olacaktır. Aday nesnesi, deneyimi, test puanlarını, görüşme puanlarını vb. temsil edecek alanlara sahip olacaktır.

Aşağıdaki örnek, değerlendirmeniz için basitleştirilmiş bir kurallar kümesi sunar. Yerleştirilmemiştir, yalnızca birbirine bağlı dört kuraldan oluşan basit bir örnektir:

• Gönderildi -> Test Ediliyor
• Test -> Mülakat
• Röportaj -> Proje
• Proje -> İşe Alım

Gönderildi -> Test Ediliyor

Mevcut müşteri ihtiyaçlarına göre İK, bir adayın çevrimiçi test için programlanması gerekip gerekmediğini belirleyecek bir kural yazmak istiyor.

 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

Test -> Mülakat

Aday çevrimiçi sınava girdikten sonra puanlarının değerlendirilmesi gerekir. İK, bu kural üzerinde de kontrol sahibi olmak istiyor. Çevrimiçi sınav, bir adayın yazılım geliştirme teorisini, problem çözmeyi ve sözdizimini anlama yeteneğini test eder. İK, bir adayın teknik bir görüşme için değerlendirilmesini sağlayacak puanların karışımına karar vermek istiyor.

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

Röportaj -> Proje

Teknik bir görüşme, adayın deneyimleri hakkında konuşma, problem çözme sorularını yanıtlama ve genel olarak iletişim kurma becerilerini test edecektir. İK, teknik görüşme için geçme puanını belirleyen kuralı yazacaktır.

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

Proje -> İşe Alım

Bir aday teknik mülakatı geçerse, kendisine bir çevrim dışı programlama projesi verilecektir. Projeyi sunacaklar ve eksiksizlik, mimari ve GUI açısından değerlendirilecekler.

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

Gördüğünüz gibi, bu basit örnek bile İK için bir dizi olasılık sunuyor ve operasyonları kolaylaştırabilir. İK'nın BT'yi sürece dahil etmek zorunda kalmadan kuralları değiştirebilmesi, kaçınılmaz olarak zamandan tasarruf sağlayacak ve tarama sürecini hızlandıracaktır.

Kurallar anında değiştirilebildiğinden, İK departmanı da çok daha fazla esnekliğe sahip olacaktır. Örneğin İK, farklı parametreler ayarlayarak seçim sürecini genişletebilir veya kısıtlayabilir.

Tüm doğru kutuları işaretleyen çok fazla aday varsa, çıta dakikalar içinde yükseltilebilir ve böylece aday sayısı azaltılabilir. Alternatif olarak, süreç tüm gereksinimleri karşılayan az sayıda aday ortaya çıkarırsa veya hiç aday göstermezse, İK standartların bazılarını düşürmeyi veya düşürmeyi seçebilir ve yeterli sayıda aday gereksinimi karşılayana kadar odaklarını daha ilgili becerilere kaydırabilir.