Indholdsfortegnelse. Systembeskrivelse kapitel 3 Forretningslogik

Transkript

1 Indholdsfortegnelse 3. Forretningslogik Domænemodel BBR-domænemodel er i BBR-domænemodel Modtageboks-domænemodel er i modtageboks-domænemodel Service Interface Lag Service Contract Service Adapter Validering Kontrol af relationer i databasen Logiske kontroller Sandsynlighedskontroller Konsistenstjek Forretningsregler Version 12.0 Side 1 af 10

2 3. Forretningslogik I det følgende beskrives forretningslagets forskellige moduler og komponenter. Forretningslaget er dels opdelt i lag, dels i moduler og entiteter samt de operationer og de betingelser, der skal være opfyldt for at operationerne kan udføres, dvs. validering. Der gøres opmærksom på, at der her er tale om et levende dokument, idet specielt forretningsregler samt ServiceLag vil være genstand for stadig revision, efterhånden som BBR-klientens behov for services og detaljerne i forretningsreglerne kortlægges. 3.1 Domænemodel I den tilbudte løsning (p. 8ff) er forretningslogikken delt op i en række moduler med forskellig funktionalitet. Nedenfor er denne opdeling yderligere detaljeret ved at beskrive en række domænemodeller for de centraler områder for forretningslogikken: BBR og Modtageboks. Domænemodelbegrebet svarer på mange måder til den logiske datamodel og dens entiteter, men domænemodellen er udvidet med en række operationer, der kan udføres på de pågældende entiteter samt nogle relationer mellem dem. I det følgende vises en grafisk fremstilling af modellerne for hvert af de to områder, og de involverede entiteter og de operationer der virker på de enkelte entiteter, bliver beskrevet. Alle kald i Service Interface Laget vil benytte sig af operationer i domænemodellen. Ud over operationerne indeholder entiteterne også datamodellens logiske attributter. De er ikke beskrevet yderligere i dette afsnit, men er indeholdt i bilag C i forbindelse med beskrivelsen af den logiske validering på enkeltfelter. Uanset hvilken datamodificerende operation, der vil blive kaldt, vil den logiske validering altid blive foretaget. Af hensyn til overskueligheden er entiteten Notater udeladt fra den grafiske oversigt, da denne knyttes til stort set alle entiteter BBR-domænemodel BBR-domænemodellen består af flg. entiteter Version 12.0 Side 2 af 10

3 Figur 3.1. Domænemodel for BBR er i BBR-domænemodel Grund Bygning (0-Mange) TekniskAnlæg (0-Mange) Sag (0-Mange) ter en ny grund i en kommune ter oplysningerne om grunden Version 12.0 Side 3 af 10

4 HentBygninger HentTekniskeAnlæg ter en grund Henter oplysningerne om en grund via Henter oplysninger om en grund via den brugervendte nøgle Henter bygningerne på grunden Henter de tekniske anlæg på grunden Matrikel ter en ny matrikel i en kommune ter oplysninger om en matrikel ter en matrikel Henter matrikeloplysninger via id Henter matrikeloplysninger via matrikelnr. og -bogstav Kommune ter en ny kommune ter oplysninger ter en kommune Henter oplysninger via ID Henter oplysninger via kommunenr. Bygning Sag(0-Mange) TekniskAnlæg (0-Mange) Opgang (0 Mange) Etage (0 Mange) Brugsenhed (0- Mange) ter en ny bygning på en grund Version 12.0 Side 4 af 10

5 HentTekniskeAnlæg HentOpgange HentEtager HentByggesager HentBrugsenheder ter oplysningerne om en bygning ter en bygning Henter en bygnings oplysninger via Henter en bygnings oplysninger via den brugervendte nøgle (Kommunenr, ejendomsnr og bygningsnr) Henter en bygnings tekniske anlæg Henter en bygnings opgange Henter en bygnings etager Henter byggesagerne på en bygning Henter brugsenhederne i en bygning TekniskAnlæg ter et nyt TekniskAnlæg på en grund ter oplysningerne om et TekniskAnlæg ter et TekniskAnlæg HentByggesager Henter et TekniskAnlægs oplysninger via Henter et TekniskAnlægs oplysninger via den brugervendte nøgle (Kommunenr, ejendomsnr og nr) Henter byggesagerne på et TekniskAnlæg Sag ter en ny sag ter oplysninger om sag, herunder status, mv. ter en sag Henter oplysningerne om en sag Version 12.0 Side 5 af 10

6 Opgang Enhed (0 Mange) ter en ny opgang i en bygning HentEnheder ter oplysningerne om en opgang ter en opgang Henter oplysningerne om en opgang via Henter oplysningerne via den brugervendte nøgle (adressen) Henter en opgangs enheder Etage Enhed (0 Mange) Rum (0 Mange) ter en ny etage i en bygning HentEnheder HentRum ter oplysningerne om en etage ter en etage Henter oplysningerne om en etage via Henter en etages enheder Henter en opgangs rum Rum ter en nyt rum på en etage ter oplysningerne om et rum ter et rum Henter oplysningerne om et rum via Enhed Version 12.0 Side 6 af 10

7 HentRum Rum (0 Mange) ter en ny enhed på en etage ter oplysningerne om en enhed ter en enhed Henter oplysningerne om en enhed via Henter oplysningerne om en enhed via den brugervendte nøgle (Enhedsadressen) Henter en enhedens rum Brugsenhed ter en ny brugsenhed ter oplysningerne om en brugsenhed ter en brugsenhed Henter oplysningerne om en brugsenhed via Henter oplysningerne om en brugsenhed via den brugervendte nøgle (adressen) Geometri ter et nyt geometriske punkt/område ter de geometriske oplysninger ter en geometrisk punkt/område Henter de geometriske oplysninger via Version 12.0 Side 7 af 10

8 3.1.2 Modtageboks-domænemodel Figur 3.3. Domænemodel for amodtageboks Denne domænemodel (Figur 3.3) for Modtageboksen vil blive opdateret i forbindelse med den udvidede funktionalitet der indarbejdes i Modtageboksen er i modtageboks-domænemodel ModtageBoks ter en ny modtageboks ter oplysningerne om modtageboksen ter en modtageboks Henter oplysningerne om en modtageboks via ModtagBoksData ter et nyt sæt af data til modtageboksen ter et sæt modtageboksoplysninger ter et sæt modtageboksoplysninger Henter oplysningerne om modtagboksdata via den tekniske nøgle Version 12.0 Side 8 af 10

9 3.2 Service Interface Lag Som beskrevet i kapitel 2. Systemarkitektur udstilles forretningslogikken som WCF-services i Service Interface Laget. Service Interface Laget består af to komponenter: Service Contract og Service Adapter. Komponenterne beskrives i det følgende Service Contract Service Contract komponenten indeholder beskrivelser af, hvilke operationer og hvilke data der skal udveksles. Dette er helt analogt til en webservice beskrevet med WSDL (Web Services Description Language). Udvalget og formen af de enkelte services dikteres af de forretningsprocesser, som BBR-klienten og kommuneklienten (eksterne OIOXML-snitflader) skal understøtte. Når disse er endeligt fastlagt vil systembeskrivelsen blive udvidet med beskrivelser af de nødvendige services. Typisk vil der for hver entitet være behov for services til søg, hent, opret, ret og slet, men forretningsprocesserne kan sagtens diktere at der forekommer services med flere forskellige entiteter Service Adapter Service Adapter-komponenten indeholder selve implementationen af de services, der er beskrevet i Service Contract-komponenten. Den enkelte service implementerer sin funktionalitet ved at tilgå en instans af domænemodellen, beskrevet andet steds i dette kapitel. Service implementationen har endvidere ansvar for at styre transaktionsscope. Dette er især vigtigt når flere entiteter indgår i en given operation. Serviceimplementationen skal også fange de eventuelle fejl, der kan komme fra domænemodellen, og omsætte dem til beskeder som er gyldige i henhold til servicekontrakten. 3.3 Validering Validering af data kan inddeles i 4 forskellige kategorier: 1. Kontrol af relationer i databasen (krav 11.1) 2. Logiske kontroller (krav 11.3 og 11.5) 3. Sandsynlighedskontroller (krav 11.5) 4. Konsistentjek (krav 11.5). De 4 kategorier vil blive implementeret som programmatiske kontroller i forretningslaget på applikationsserveren. Desuden vil transaktionsscope i service interface laget og referentiel integritet i databasen sikre konsistensen i databasen Kontrol af relationer i databasen Da relationer implicerer entiteter fordelt over flere fysiske tabeller i databasen, er det ikke tilstrækkeligt med den programmatiske kontrol i forretningslaget. En yderligere sikring indbygges i databasen i form af referentiel integritet, hvilket garanterer, at de relationer, der oprettes i databasen, er valide. Det vil ikke være muligt at oprette en reference til en anden entitet uden at den pågældende entitet eksisterer. Når der skal gennemføres en opdatering over flere tabeller sikrer det transaktionsscope, der etableres i servicelaget, at opdateringerne alle foretages eller alle afvises. Dette sikrer igen konsistensen således, at en opdatering ikke Version 12.0 Side 9 af 10

10 kun kan gennemføres delvist med referencer til ikke-eksisterende entiteter til følge. Dette gælder for referencerne inden for BBR-domænet. Relationerne til de eksterne systemer valideres ligeledes, men her er der ikke samme garanti for, at relationen efterfølgende er valid, da den ligger udenfor BBR-domænet. Her vil der blive gennemført periodevise batchkørsler for at tjekke konsistensen Logiske kontroller De logiske kontroller kan deles op i 1. Simple valideringer såsom tjek af datatype, værdisæt (f.eks. kodeværdier samt fra- og til-værdier), og formater (f.eks. datoformat). Værdierne for de enkelte entiteters datafelter er angivet i Bilag C. Datatypen vil dog allerede være tjekket i præsentationslaget, da det ikke er muligt for præsentationslaget at kalde applikationslaget via en WCF service uden at datatypen er korrekt. 2. Kontekstafhængige feltvalideringer. Her menes felter hvor valideringen påvirkes af indholdet i andre felter i samme eller anden entitet eller af den operation validering indgår i. Bilag A indeholder de kontekstafhængige feltvalideringer som er implementeret i BBR Sandsynlighedskontroller Sandsynlighedskontroller implementeres i forretningslaget. Sandsynlighedskontrollen defineres i metadatabasen og består af en kontekstbeskrivelse og en validering. I kontekstbeskrivelsen defineres det udtryk der skal aktivere den tilhørende validering. I kontekstbeskrivelsen kan indgå and- og or-operatorer. Sandsynlighedskontroller er vedlagt i Bilag B. Desuden er der vedlagt en oversigt over sammenhængen mellem den fysiske og logiske datamodel i Bilag E Konsistenstjek Konsistenstjek er tjek der sørger for dataintegriteten i forhold til de eksterne systemer. Når udvekslingen af data foregår synkront og realtime, foretages valideringen i forretningslaget. Noget af dataudvekslingen med CPR foretages asynkront, og derfor er det nødvendigt at foretage et periodevist tjek i form af en batchkørsel. 3.4 Forretningsregler De forretningsregler, som er indeholdt i systemet, beskrives i de forskellige afsnit af systembeskrivelsen, hvor de naturligt hører hjemme. Dog er der en mindre gruppe specifikke forretningsregler, der vil blive implementeret, som ikke er beskrevet andre steder. Disse forretningsregler er opsamlet i Bilag D. Version 12.0 Side 10 af 10