Spørsmål og svar

Har du noen spørsmål? Send e-post til kontakt@regemotor.no.

Hva er en regel?

En regel uttrykker et logisk vilkår. Den består av en betingelse (hvis) og en konsekvens (så): Hvis A så B. Regelen sier at hvis betingelsen A oppfylles så blir konsekvensen B sann og skal utføres. En regel kan godt har flere betingelser og konsekvenser. Eksempel: Hvis tanken ikke er tom og batteriet ikke er flatt så kan bilen starte.

Hvordan ser en regel ut?

I Blaze SRL vil den se slik ut: rule sjekk_tank if bilen.tank.nivå = 0 liter then svar = «Fyll tanken».

Hva er forretningsregler?

Forretningsregler eller på engelsk «business rules» betegner grunnleggende vilkår og strategier som styrer en virksomhet. Det kan også være de enkelte regler en lov består av. En kan i det videste tenke seg all kunnskapen en fagansvarlig eller saksbehandler har i sitt hode, som et stort sett av forretningsregler.

Hvorfor er det bra å trekke forretningsreglene ut fra applikasjonskoden?

Forretningregler representerer dynamiske elementer i en applikasjon. Endringer i forretningsstrategier trenger å gjenspeiles raskt i applikasjonen. Ved å identifisere forretningsstrategier og skrive dem som forretningsregler får man skilt forretningsstrategiene fra applikasjonskoden, dermed oppnår man følgende fordeler:

  • Forretningsreglene blir enklere å kommunisere og kan forståes av alle.
  • Forretningsreglene kan vedlikeholdes isolert fra applikasjonskoden.
  • Når forretningsregler endres er det raskt å få endringene inn i applikasjonen.

Hvorfor gå for en løsning med regelmotor?

Forretningsregler innbakt i applikasjonskoden har flere ulemper:

  • Uoversiktlig med forretningsregler i applikasjonskoden
  • Vanskelig å finne og endre forretningslogikk i applikasjonskoden.
  • Må kompilere applikasjonskoden hver gang det gjøres endringer i forretningslogikken.
  • Det tar lang tid å implementere endringer i forretningsregler.

Fordeler ved å gå over til en regelmotorbasert løsning:

  • Forretningsreglene blir enklere å kommunisere og kan forståes av alle.
  • Forretningsreglene kan vedlikeholdes isolert fra applikasjonskoden.
  • Når forretningsregler endres er det raskt å få endringene inn i applikasjonen.

Hvor kan regelmotorer benyttes?

Regelmotorer kan brukes bl.a. som beslutningsstøtte for saksbehandlere, delegering av oppgaver, gjøre risikoberegninger, kontrollfunksjoner, CRM, skjemavalideringer, konfigurering av produkter, utregning av tilbudspriser ut fra en gitt prispolitikk. En bransje hvor regelmotorer er mye brukt er i telekombransjen p.g.a. bransjens behov for å gjøre raske endringer i pris- og produktpolitikken Ved å bruke en regelmotor har telekommunikasjonsbransjen mulighet for å personalisere informasjon og skreddersy prislister til hver enkelt tjenestetilbyder og annonsør. I tillegg kan prispolitikk endres raskt og enkelt uten at det har innvirkning på systemarkitekturen. Med en regelmotor har telekommunikasjonsbransjen et produkt for raskt å reflektere endringer i markedssituasjonen inn i CRM- og billingsystemet.

En regelmotor er også til stor hjelp i implementeringen av et Call Data Record system(CDR). Et CDR system kan være teknisk utfordrende å bygge p.g.a kompleksiteten på prisstrukturen og mengden av data som må samstemmes med andre systemer. Slike system krever også en svært høy ytelse siden CDR prosessering involverer trigging av tusenvis av regler per sekund samtidig med at store mengder data må prosesseres i nær sanntid.

Hva er regelbaserte systemer?

Systemer som setter kunnskapen i sentrum. Automatisering av forretningsregler ved hjelp av verktøy som støtter dette.

Hva er regelbasert utvikling, og hvordan passer den inn i moderne systemutvikling?

Regelbasert utvikling gir fagekspertene en mer aktiv rolle i utvikling og vedlikehold av applikasjonen. I spesifikasjonsfasen blir forretningslogikk og lover brutt ned til enkeltregler. Reglene blir formulert i et regelspråk som er både lesbart for ikke-tekniske fagpersoner og for regelmotoren. Fagpersoner som er ansvarlig for å definere og vedlikeholde forretningsreglene kan nå forstå og modifisere disse selv. Dermed kan fagpersoner medvirke mer aktivt i utviklingen av reglene. Utviklingssyklusen blir kortere fordi spesifikasjon og implementering er det samme.

Ved hjelp av regelspråket og brukervennlige GUI verktøy som de store regelmotorleverandører tilbyr, kan trente fagpersoner selv foreta endringer på reglene og kunne korte ned utviklingssyklusen enda mer. I drift kan regelspesifikasjonene med kommentarer tjene som oppslagsverk for fagpersoner som ønsker å finne hvilke konkrete vilkår som gjelder til enhver tid.

Hva er Structured Rule Language(SRL)?

Et plattformuavhengig, deklarativt og naturlig-språk for beskrivelse av forretningsregler.

Hva er en regelmotor?

Regelmotorer blir brukt i systemutvikling for å separere forretningsreglene fra applikasjonslogikken. En regelmotor er en programvarekomponent som kjører separat fra resten av applikasjonen og eksekverer reglene. I tradisjonelle systemer ligger ofte forretningsreglene innbakt i programkoden til applikasjonen. Dette gjør at endring og vedlikehold av reglene blir mer komplisert og derav mer kostbart. Systemeiere satser i økende grad på regelmotorer for å få ned utviklings- og vedlikeholdskostnader og samtidig øke applikasjonens tilpasning og fleksibilitet i forhold til andre systemer, samt for å få et nærere forhold til reglene i sine systemer. Ytelsen profiterer på regelmotoren fordi de fleste kommersielle inferensdrevne regelmotorer bruker RETE-algoritmen for optimert evaluering og eksekvering av reglene.

Hva er RETE algoritmen?

RETE-algoritmen ble utviklet av Charles Forgy på Carnegie Mellon University i 1979. RETE er den mest effektive algoritme for «pattern matching» som er kjent i dag. «Pattern matching» er et søkeproblem flere verdier søkes samtidig og ikke en enkelt verdi. I regelsammenheng er problemstillingen å lete fram konsekvenser ut fra kjennskap til utfall av betingelser. RETE algoritmen brukes i regelmotorer for å optimalisere evalueringen av reglene. Reglene blir kompilert til et såkalt «discrimination network» som kan anses som en oppslagstabell. Betingelser som deles av flere regler sjekkes kun en gang. Eksekveringstiden øker kun lineært med antall regler.

Hva er forskjellen mellom forward og backward chaining, eller sagt på norsk: forover eller bakover lenking?

Algoritmen som brukes av inferensdrevne regelmotorer er basert enten på foroverlenking eller bakoverlenking. Bakoverlenking kan sees på som et dybde først søk i reglene hvor en har en hypotese som skal tilfredstilles ved hjelp av underhypoteser, hvor underhypotesene danner en trestruktur. Foroverlenking kan sees på som et breddeførst søk i reglene, hvor alle reglene hvor betingelsen er sann vil fyre samtidig. De første ekspertsystemer var stort sett bakoverlenkede, da de ville prøvde å være speilbilder av hvordan vi som mennesker tar beslutninger. Tanken var at vi har en hypotese, f.eks.: ‘Det er fint vær i dag’, som har hypotesene ‘Solen skinner’ og ‘Vinden er ikke for sterk’ og ‘Temperaturen er bra’ under seg, som avhenger av at flere underhypoteser er sanne for å kunne være sann. De moderne regelmotorer bruker stort sett foroverlenking, da de mener at formålet til et regelsystem er å eksekvere flest mulig regler slik at for de kan påvirke de neste beslutningene (andre regler) som skal tas. I et bakoverlenket system er derimot målet å tilfredsstille hypotesen ved å eksekvere så få regler som mulig for å få hypotesen til å bli sann.

Hva er forskjellen mellom ekspertsystemer og regelmotorer?

Svaret her er at det ikke finnes noen teknisk forskjell, men mer en dreining av assosiasjoner og bruksmåter. Ordet ekspertsystem ble i 90-årene ansett å gi assosiasjoner om å automatisere vekk ekspertene og dermed arbeidsplasser, noe som har vist seg umulig å gjøre, da det alltid vil være noe skjønn med i de fleste beslutningsprosesser. Regelmotorer og regelbaserte systemer, ble de nye «buzzwords», som gir helt andre assosiasjoner.

Hvorfor kjøpe en regelmotor når jeg kan lage den selv?

Det er det 2 hovedgrunner til ikke å lage en regelmotor selv: 1. Noen andre har gjort det før deg – hvorfor finne opp hjulet på nytt, det er kostbart og tidkrevende. 2. Alle hjelpemidlene som kommer med en kommersiell regelmotor. Som for eksempel muligheter til å finne regler som negerer andre regler, verktøy for å legge inn regler, verktøy for å finne igjen regler, verktøy for å teste reglene, kryssreferanser, osv. Dette gjør vedlikeholdet av reglene utrolig mye enklere. Du vil vel ikke lage en relasjonsdatabase (RDBMS) selv?

Finnes det andre generelle regelmotorer enn Blaze Advisor på markedet?

Ja. Noen eksempler er: ILog JRules, CA Aion, Pegasystems.

Finnes det en felles standard for regelmotorer?

Generelt kan vi si at standardisering av regelspråk ikke har kommet så langt som man ønsker.

• Java «Rule Engine API» (JSR-94) er en Java api standard fro Java EE og Java SE. Dette er et felles grensesnitt for å binde inn regeltjenester i Java. APIet beskriver en standard måte for å kalle en regelmotor, legge til/fjerne regler, eksekvere regler og levere resultatet tilbake.

Rule Engine API lover større leverandøruavhengighet ved bruk av regelmotorer ved at regelkomponenter kan brukes mot alle produkter som følger denne standarden.

•Rule Markup Language (RuleML) is er et regelspråk i XML format. Det er definert av Rule Markup Initiative, som er et åpent nettverk av personer og grupper fra både industrien og akademiske miljø.

Hva er rule mining?

Med «data mining» som forbilde har begrepet «rule mining» oppstått. «Rule mining» betegner det å ekstrahere regler fra eksisterende programkode. Motivasjonen er ofte å dokumentere programlogikken i et «legacy»-system hvor der ikke finnes dokumentasjon eventuelt at dokumentasjonen har blitt utdatert. «Rule mining» kan også brukes til å få oversikt over forretningsregler som ligger til bunns i et eksisterende system når dette skal endres eller en vil bygge det om til å bruke en regelmotor. «Rule mining» gjennomføres i fire trinn: arkeologi – å lage en innholdsliste over programmer, protokoller, programflyter; programinspeksjon – avdekke regler i programkoden; dataanalyse – lage datamodell; og rule integration – sammenfatting av regler og avdekking av gjentakelser og inkonsistenser. Eksempler av rule mining programvare er:

  • Mosiac Studio from SEEC
  • HotRod from Netron
  • RescueWare from Relativity
  • Cosmos/ES from Emendo
  • MineIt from Intercomp