Arena Kundereskontro. Produktrapport

Transkript

1 Arena Kundereskontro Produktrapport

2 FORORD Dette er en rapport skrevet med det formål å dokumentere produktet Arena kundereskontro. Kjært barn har mange navn, og klassebiblioteket vil refereres til ved bruk av flere betegnelser. Både «Arena Kundereskontro», «modulen» og «klassebiblioteket» vil forekomme, og alle sikter til samme produkt, nemlig klassebiblioteket. Bakgrunn, utvikling og endelig produkt vil beskrives og analyseres. Produktet består av et klassebibliotek (modul) som kan implementeres i et nåværende system. Rapporten er laget for de som skal drifte og videreutvikle systemet og vil gi en detaljert innføring i modulens funksjonalitet, oppbygning og virkemåte. ORDBRUK I RAPPORTEN Rapporten forutsetter at leseren har en grunnleggende teknologisk forståelse for den teknologien som er benyttet i prosjektet. Dette omfatter programmeringsspråket C# og rammeverket.net. Grunnleggende kunnskap om applikasjonsutvikling i.net vil dessuten være en fordel. Foruten teknologisk forståelse forutsetter rapporten også at leseren besitter en viss kunnskap om økonomi. Rapporten vil inneholde terminologi som omhandler lagdeling av prosjekter, logiske navngivninger og dessuten referanser til kode som er utviklet i prosjektet. S i d e 2 53

3 INNHOLD Forord... 2 Ordbruk i rapporten Kravspesifikasjon sammendrag Funksjonalitet og egenskaper Config / Oppsett Databasetilkobling Kontekst AKContext RequestContext Oppsett av kontoer Importere konto fra CSV Klient Implementasjon av IArenakundereskontroClient Generering av Transaksjonsforespørsel XML Formatering Hash av forespørsel Checksum Håndtering av Transaksjonsforespørsel Kontrollere Transaksjonsforespørsel Validering Lagring av Transaksjon Oppdatere Request med guid Utsendelse av kvittering Kvitteringer S i d e 3 53

4 3.7.1 ReceiptSender IMessageReceiver Hente ut data Uttak av data til regnskapssystem Feilhåndtering Exceptions Sporbarhet Async/Sync håndtering Oppbygging Prosjektstruktur Organisering av klasser - Namespaces Benyttede biblioteker & rammeverk Microsoft.NET Framework Entity Framework LINQ MOQ FileHelpers Modeller Domenemodeller XML Modeller Datalagring/dataaksessering Sikkerhet Access Modifiers Programmerings standard Retningslinjer Oppdragsgivers retningslinjer S i d e 4 53

5 5.1.1 programmeringsstandard kommentering av kode Navngivning Kravspesifikasjon Funksjonelle Krav Ikke funksjonelle krav S i d e 5 53

6 1 KRAVSPESIFIKASJON Produktet er et resultat av Kredinors etterspørsel etter et system som kan holde oversikt over transaksjoner og sørge for sporbarhet av posteringer tilknyttet disse. Produktet er en selvstendig modul som består av et klassebibliotek. Kravspesifikasjonen til produktet ble utarbeidet i samarbeid med Kredinor, med utgangspunkt i funksjonalitet i daværende system samt ønskene om ny funksjonalitet. Modulen skal være generisk og gjøre implementasjon hos flere klienter mulig, eksempelvis skal den kunne benyttes for både inkasso-, fakturaservice- og kundekontosystemer. Det skal også være enkelt å implementere fremtidige system som brukere av modulen. Modulen skal derfor designes og utvikles som en generell kundereskontro, og ikke være rettet mot en spesiell bransje. Hele kravspesifikasjonen befinner seg i slutten av denne rapporten, punkt 6. De mest sentrale delene av kravspesifikasjonen er gjengitt her: Modulen skal implementeres som en selvstendig modul Modulen skal motta transaksjoner fra klient Modulen skal postere transaksjoner i mottatt fil Alle posterte transaksjoner skal være i balanse Alle transaksjoner/posteringer skal være sporbare Ingen transaksjoner/posteringer skal kunne slettes 2 SAMMENDRAG Modulens kjernefunksjonalitet går ut på å behandle transaksjonsforespørsler mottatt fra en klient som har implementert klassebiblioteket. En forespørsel kan inneholde en eller flere transaksjoner. En forespørsel mottas normalt som en XML fil som konverteres til et objekt som modulen kan behandle. Modulen sjekker først om en transaksjon er behandlet og postert tidligere, i så fall blir den avvist. Transaksjoner som ikke er postert tidligere vil bli behandlet av modulen. Kvittering vil bli sendt til klientens kvitteringsmottaker uavhengig av resultat. Det er også mulig å hente ut posterte transaksjoner til eksternt regnskapssystem. En klient kan velge om den ønsker at transaksjoner skal behandles synkront eller asynkront da modulen tilbyr begge løsninger. S i d e 6 53

7 Figur 1 [Skisse av modulens hovedfunksjonalitet] 3 FUNKSJONALITET OG EGENSKAPER I følgende kapittel beskrives funksjonaliteten til Arena Kundereskontro. Kapittelet vil beskrive hvordan modulen gjøres klar til bruk, deretter gi en detaljert beskrivelse av funksjonalitet og virkemåte til hvert steg i hendelsesforløpet. 3.1 CONFIG / OPPSETT Modulen krever at klienten som skal ta den i bruk gjennomgår et oppsett, for at modulen skal kunne utføre ønsket arbeid med forventet resultat. Her blir en klient omtalt som et system som skal ta modulen i bruk. Dette oppsettet definerer blant annet hvor prosessert data skal lagres i klientens system, hvordan mottak og videre håndtering av transaksjons-kvitteringer skal foregå, hvilken identifikator klient skal refereres via i modulen og hvilke kontoer posteringer skal kunne bokføres til. Følgende punkter må gjennomføres av brukeren før modulen kan tas i bruk: Bruker må implementere logikk for XML-filformattering (TransactionRequest) S i d e 7 53

8 Bruker må konfigurere tilkobling til databasen. (ConnectionString 1 ) Bruker må importere kontoer til modulen, dersom disse ikke er importert fra før Bruker må implementere interfacet IArenakundereskontroClient for å identifisere seg som en klient DATABASETILKOBLING Modulen er nødt til å vite hvor databasen ligger. Dette definerer systemet som implementerer klassebiblioteket i form av en «connection string». Figur 2 [ConnectionString] En connection string kan inneholde mange elementer, men som minimum må den inneholde navn, databaselokasjon og providername. Systemet må definere connection string til de to kontekstene (databasene) som benyttes; «AKContext» og «RequestContext». 3.2 KONTEKST I sammenheng med programmering er konteksten en viktig del av en løsning. En kontekst kan defineres som en klasse som inneholder grunnleggende data i forbindelse med den løsningen den er tilknyttet, primært data med informasjon om forbindelse til database og hvilke objekter den inneholder. Konteksten har flere viktige funksjoner: Refererer til connection stringen. Inneholder metadata som beskriver modellene. Holder kontroll på alle endringer som skjer i objektene via en kontroll-tracker. 1 S i d e 8 53

9 Modulen inneholder en kontekst for sentral funksjonalitetshåndtering navngitt AKContext og en kontekst for funksjonalitetshåndtering av forespørsler navngitt RequestContext. Figur 3 - [Hver klient har sin egen RequestContext] AKCONTEXT AKContext inneholder en databasesett for alle objektene modulen benytter internt. Dette innebærer alle objektene som er tilknyttet hendelsesforløpet rundt kjernefunksjonaliteten. Disse settene er: DbSet<Account> Accounts DbSet<Transaction> Transactions DbSet<Posting> Postings DbSet<Client> Clients DbSet<Reference> References S i d e 9 53

10 Figur 4 - [AKContext] All dataflyt fra og til databasen går via denne konteksten, noe som gjør den svært sentral i modulen. Hvert DbSet håndteres i sine egne repositories. Dette er hensiktsmessig ettersom hvert objekt har unike attributter og metoder, og hvert repository er derfor en skreddersydd aksessor med all nødvendig funksjonalitet for å håndtere dataflyt for sitt objekt. Figur 5 - [Relasjoner mellom Objekt, Repository og AKContext] REQUESTCONTEXT En RequestContext holder oversikt over henvendelser som er sendt inn til modulen. Når en henvendelse blir prosessert hashes denne og sammenlignes mot tidligere henvendelser og på den måten unngår man at den samme henvendelsen blir prosessert flere ganger. Hver enkelt klient har sin egen RequestContext, for å holde oversikt på sine henvendelser. Det er hensiktsmessig fordi det gjør oppslag mot databasen raskere, og en klient vil normalt sett kun være interessert i de forespørslene klienten har sendt selv. S i d e 10 53

11 3.3 OPPSETT AV KONTOER Modulen bokfører transaksjoner som inneholder posteringer som skal posteres mot en gitt konto med et gitt beløp. Kontoene ligger lagret internt i modulen og må eksistere for å kunne benyttes. En konto består av et navn, et kontonummer, et attributt som tilsier om kontoen er aktiv, og et attributt som tilsier om posteringer på kontoen skal kunne overføres til et eksternt regnskapssystem. Dersom en konto er inaktiv vil det ikke være mulig å postere mot denne. Figur 6 - [Konvertering av kontoplan til Konto-objekter] Dersom en fil under prosessering benytter en konto som ikke eksisterer i systemet vil dette resultere i en feilmelding. Mer informasjon om feilhåndtering befinner seg i [feilhåndtering]. Klassen som håndterer kontoer og kommuniserer med AccountRepository heter AccountWriter. Her finnes metoder for å legge til nye kontoer individuelt eller via csv fil, endre egenskapene til eksisterende kontoer og konvertere kontoer til CSV. Figur 7 - [AccountWriter] IMPORTERE KONTO FRA CSV Dersom klient velger å importere kontoene til sitt system ved hjelp av en CSV fil gjøres dette i AccountWriter ved bruk av AccountCSV. Det er en klasse som utgjør en CSVrepresantasjon av et konto objekt. Hver linje i filen vil leses ut som et AccountCSV objekt, før den oversettes til et Account objekt og til slutt lagres i databasen. S i d e 11 53

12 3.4 KLIENT Klienten er som tidligere nevnt et system som tar klassebiblioteket i bruk. For at modulen skal vite hvor transaksjonen kommer fra, må alle transaksjoner knyttes til en klient. Dette gjørs gjennom at en klient sin id sendes sammen med transaksjonsforespørselen. For at modulen skal akseptere en forespørsel må klienten være registrert i modulen IMPLEMENTASJON AV IARENAKUNDERESKONTROCLIENT IArenakundereskontroClient er et interface ment for klientene. Interfacet inneholder metoder for å identifisere klienten internt i modulen og for å gi klienten muligheten til å motta transaksjonskvitteringene modulen returnerer. Etter endt postering av en transaksjon sendes en kvittering tilbake til klienten. Kvitteringen mottas i klienten, og det er opp til klienten å implementere funksjonalitet for videre håndtering. Detaljer om TransactionReceipt beskrives i [2.1.7 Transasksjonskvitteringer]. 3.5 GENERERING AV TRANSAKSJONSFORESPØRSEL Kjernefunksjonaliteten til modulen dreier seg om håndtering av transaksjoner. En klient vil sende inn en samling av transaksjoner som en transaksjonsforespørsel. En transaksjonsforespørsel ankommer normalt modulen i XML format, se underpunkt om XML formattering, og vil her bli omgjort til et TransactionRequest objekt. For å generere en TransactionRequest brukes klassen med navn TransactionRequestCreator. Klassen inneholder funksjonalitet for å konvertere en strøm, en filsti eller en liste av transaksjonsdata til en TransactionRequest som returneres til klienten. Denne kan deretter sendes inn til en annen klasse for behandling. En forespørsel består av: TransactionRequest - Data om selve Transaksjonsforespørselen TransactionData - Data om en gitt transaksjon PostingData - Data om en gitt posering S i d e 12 53

13 Figur 8 - [Parsing av transaksjonsforespørsel] S i d e 13 53

14 3.5.1 XML FORMATERING En forespørsel blir utformet i XML ved hjelp av et XSD-skjema som modulen tilbyr. <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xsi=" xmlns:xsd=" xmlns:xs=" <xsd:element name="transactionrequest"> <xsd:complextype> <xsd:sequence> <xsd:element name="transactions"> <xsd:complextype> <xsd:sequence> <xsd:element maxoccurs="unbounded" name="transaction"> <xsd:complextype> <xsd:sequence> <xsd:element name="date" type="xsd:datetime" /> <xsd:element name="amount" type="xsd:double" /> <xsd:element name="financial_year" type="xsd:integer" /> <xsd:element name="financial_period"> <xsd:simpletype> <xsd:restriction base="xsd:integer"> <xsd:mininclusive value="1" /> <xsd:maxinclusive value="6" /> </xsd:restriction> </xsd:simpletype> </xsd:element> <xsd:element name="postings"> <xsd:complextype> <xsd:sequence> <xsd:element maxoccurs="unbounded" name="posting"> <xsd:complextype> <xsd:sequence> <xsd:element name="account_no" type="xsd:unsignedshort" /> <xsd:element name="parent_guid" /> <xsd:element name="reference" type="xsd:string" /> <xsd:element name="amount" type="xsd:double" /> </xsd:sequence> </xsd:complextype> </xsd:element> </xsd:sequence> </xsd:complextype> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:unsignedshort" use="required" /> </xsd:complextype> </xsd:element> </xsd:sequence> </xsd:complextype> </xsd:element> </xsd:sequence> </xsd:complextype> </xsd:element> </xs:schema> S i d e 14 53

15 Formatet som sendes inn må stå i samsvar med det formatet som forventes, ref. XSDskjemaet. Filer i feil format vil bli avvist av modulen, ved hjelp av en exception som må fanges opp av klienten. Data er pakket inn i en TransactionRequest tag som signaliserer at alt innhold er del av en forespørsel. En forespørsel kan inneholde en eller flere transaksjoner, Transaction, pakket inn i tag en Transactions. En transaksjon kan igjen inneholde to eller flere posteringer, Posting, pakket inn i tag en Postings. Figur 9 - [Beskrivelse av TransactionRequest] HASH AV FORESPØRSEL CHECKSUM Etter at forespørsel er omgjort til et TransactionRequest blir hele forespørselen hashet, og hashen lagret som et attributt kalt Checksum. Denne benyttes både når modulen sender kvitteringer tilbake til klienten, slik at klienten skal vite hvilken forespørsel kvitteringen gjelder, og for å kontrollere om en forespørsel er sendt inn fra før. Mer om det i neste kapittel. S i d e 15 53

16 3.6 HÅNDTERING AV TRANSAKSJONSFORESPØRSEL Etter at data er vellykket omgjort til et TransactionRequest objekt kan klienten sende dette inn til klassen RequestHandler som vil utføre jobben med å prosessere forespørselen. Klassen fungerer som en kontroller i behandlingen av TransactionRequest objektet, og styrer hele prosessen fra mottak av objekt til kvittering er sendt. Den både tar imot objektet, verifiserer data, oppretter transaksjoner og posteringer, fullfører bokføringen og gir tilbakemelding til klienten uavhengig av om resultatet er positivt eller negativt. Alt via kall til andre klasser og metoder. Figur 10 - [RequestHandler - flyt] Hvordan RequestHandler benytter andre klasser er vist i tabellen under. Flyten er svært konsis, noen klasser aksesseres indirekte via klasser RequestHandler kaller direkte. Kolonner markert grønn aksesseres direkte fra RequestHandler klassen, imens kolonner markert med orange farger aksesseres indirekte. S i d e 16 53

17 # Klassenavn Metoder i bruk Hovedhensikt TransactionValidator( ) TransactionRequestHan dler() TransactionHandler() TransactionCreator() PostingCreator() TransactionRepository () ReceiptSender() void VerifyPostings(List<PostingData> list, double transactionamount) bool ExistsAndTrim(TransactionRequest transactionrequest,imessagereceiver messagereceiver) void StoreTransactionRequest(TransactionR equest transactionrequest) bool UpdateCompletedTransactionRequest(St ring checksum, int Id, Guid transactionguid) Guid CreateTransaction(TransactionData data, int clientid) Transaction MapTransactionData(TransactionData data, int clientid) List<Posting> VerifyAndMapPostings(List<Postingdat a> list, Guid transactionid) void TryInsert(Transaction transaction) void SendReceipt(IMessageReceiver receiver, int transactionid, Guid success, string errormessage = null) Verifisering av kontoer og beløp i transaksjonen Kontrollerer om en forespørsel er behandlet fra før. Lagrer nye forespørsler i databasen til klienten (RequestContext). Oppdaterer denne basen med Guid når transaksjonen er behandlet. Kontroller for opprettelse av transaksjon og posteringer ut fra mottatt data, samt lagring av transaksjon til databasen. Oppretter og returnerer en transaction ut fra mottatt data Oppretter og returnerer en liste med postinger ut fra mottatt data Verifiserer parentid og oppretter Reference objekt, som settes inn i Posting objektet. Lagrer transaksjon i databasen (AKContext). Kalles enten som følge av at en transaksjon har blitt innsatt i tabellen, eller som følge av at det har oppstått en feil på veien. S i d e 17 53

18 3.6.1 KONTROLLERE TRANSAKSJONSFORESPØRSEL For å forhindre redundans og ubalanse i regnskapet må ikke samme forespørsel behandles flere ganger, med mindre alle transaksjonene ikke har blitt fullført. Alle forespørsler som mottas blir derfor lagret i databasen RequestContext, og en forespørsel vil alltid bli kontrollert mot denne databasen før modulen forsøker å prosessere den. Kontroll, lagring og oppdatering av forespørsler mot denne databasen vil bli utført i TransactionRequestHandler klassen. En beskrivelse av de forskjellige funksjonene i denne klassen følger nå, før rapporten fortsetter med dette avsnittet SJEKK OM FORESPØRSEL ER BEHANDLET TIDLIGERE Checksummen i TransactionRequest sjekkes mot en tabell med alle tidligere prosesserte forespørsler, som ligger lagret i klientens RequestContext. Dersom checksummen finnes fra før tilsier dette at samme forespørsel har blitt behandlet tidligere. I dette tilfellet trimmes TransactionRequest objektet, hvilket tilsier at tidligere fullførte transaksjoner fjernes fra objektet. Dersom alle transaksjoner er behandlet tidligere og TransactionRequest objektet nå ikke inneholder transaksjoner avsluttes hendelsesforløpet. Hvis det fortsatt inneholder ubehandlet transaksjoner vil disse bli forsøkt behandlet TRIMMING AV FORESPØRSEL Med trimming av forespørsel så menes det at man går gjennom alle transaksjoner i TransactionRequest objektet, og fjerner de transaksjonene som er vellykket behandlet fra før. Dersom er en transaksjon blir fjernet så sendes det en kvittering til klient om at denne er behandlet fra før, med melding «Transacion handled before». S i d e 18 53

19 Figur 11 - [Trimming av TransactionRequest] LAGRING AV FORESPØRSEL En forespørsel som ikke er behandlet før må lagres til RequestContext databasen. Det opprettes et Request objekt, med en liste av RequestTransaction objekter. Dette objektet settes inn i databasen og tilsvarer en forespørsel med tilhørende transaksjoner. Request inneholder: RequestChecksum o Checksummen (hash av forespørselen) som ble generert tidligere. NumberOfTransactions o Antall transaksjoner i forespørselen. RequestTransactions o En liste med RequestTransaction objekt (transaksjoner) RequestTransaction inneholder: RequestChecksum S i d e 19 53

20 o Checksummen (hash av forespørselen) som ble generert tidligere. TransactionId o Id til transaksjonen, satt av klienten før innsending. TransactionGuid o Unik Guid som settes når transaksjonen er lagret. Denne vil alltid være lik Guid.empty ved opprettelse. Det betyr at transaksjonen ikke er behandlet enda. Figur 12 - [Request and RequestTransactions] Fortsettelse til avsnittet over: Modulen har nå fullført all validering av selve filen. Dersom for eksempel et strømbrudd inntreffer idet en forespørsel er under behandling, men kun har fullført 189 av 200 transaksjoner, vil klienten enkelt kunne fullføre resterende transaksjoner. Forespørselen sendes inn på nytt, modulen fjerner de 189 første transaksjonene, og sender klienten kvittering på at disse er behandlet fra før. Transaksjon nr. 190 til 200 vil bli behandlet på vanlig måte. S i d e 20 53

21 Figur 13 - [TransactionRequestHandler] Hovedhensikten til denne klassen kan sammenlignes med en dørvakt på en hipp nattklubb hvor ingen som har vært der før tillates inngang senere. Uten denne klassen ville transaksjoner kunne blitt behandlet igjen og igjen, noe som vil bryte med essensielle regnskapsprinsipper. Modulen ville kort sagt ikke vært pålitelig uten denne funksjonaliteten. Dørvakten(klassen) stopper gjester(transaksjoner) som har vært der før, men slipper inn nye «ansikt», selv om de ankommer med et gammelt følge (forespørsel). S i d e 21 53

22 Figur 13 - [Dørvakt metafor] VALIDERING Etter at forespørselen er sjekket opp mot tidligere innsendte forespørsler, og eventuelt trimmet for behandlede transaksjoner, er neste steg validering av data. Dette er påkrevd for å sikre korrekt informasjon i modulen og regnskapet, samt oppfylling av vilkår i Bokføringsloven. For å spare ressurser er validering lagt etter kontrollen som sjekker om en forespørsel er behandlet fra før. Det er lite hensiktsmessig å validere en forespørsel som likevel ikke skal behandles. Valideringen skjer i en klasse som heter TransactionValidator, som igjen benytter seg av klassen AmountValidator. Alle posteringer tilhørende en transaksjon valideres, og krav stilles: S i d e 22 53

23 # Krav Kommentar Exception 1 Konto må eksistere i modulen, og den må være aktiv 2 Beløpet i transaksjonen må stemme overens med beløpene i posteringene. 3 Summen av alle posteringsbeløp må være 0 4 En transaksjon må inneholde posteringer Dersom en transaksjon forsøker å benytte en ugyldig konto, vil det kastes exception. Dersom en transaksjon inneholder en sum som ikke stemmer overens med det som bes postert, så er det feil og det kastes exception. En transaksjon består av et beløp som skal posteres mot debet (pluss) og kredit(minus) i regnskapet. Dersom disse ikke går i balanse, så er det feil og exception kastes. En transaksjon som ikke inneholder noen posteringer har ingen hensikt og det kastes exception InvalidAccountException InvalidTransactionBalance Exception(sumPostings, sumamount) InvalidPostingBalanceExce ption(sumpostings) EmptyPostingDataException Dersom en transaksjon stoppes, så kastes det en fielmelding (exception) som modulen behandler. Denne vil medføre at det genereres en kvittering til klienten, med informasjon om at transaksjonen ikke kunne gjennomføres. Grunnen til at transaksjonen er stoppet vil fremgå av kvitteringen. S i d e 23 53

24 Figur 14- [TransactionValidator] LAGRING AV TRANSAKSJON Selve lagringen av en transaksjon håndteres i en egen klasse, TransactionHandler. Lagringen er det siste steget i prosessen en transaksjon gjennomgår. TransactionHandler benytter klassene TransactionCreator og PostingCreator til å opprette transaksjon med tilhørende posteringer, ut ifra data som mottas. Forløpet i TransactionHandler kan oppsummeres i 6 følgende steg: 1. TransactionData og clientid ankommer TransactionHandler 2. Et Transaction objekt opprettes ut ifra mottatt data 3. En liste med Posting objekter opprettes med tilhørende Reference objekt 4. Posteringene kobles til transaksjonen 5. Transaksjonen blir forsøkt satt inn i databasen 6. Guid en til transaksjonen returneres S i d e 24 53

25 Figur 15 - [Oppbygging av en Transaction] Dersom en feil inntreffer under utførelsen av stegene avbrytes hendelsesforløpet. En feilmelding kastes til RequestHandler, som sørger for at det blir sendt en kvittering til klienten med informasjon om feilen. Steg 1: TransactionData objekt og klientens id mottas fra kallende rutine. TransactionData tilsvarer en enkelt transaksjon. Steg 2: Transaction objektet lages ved å kalle på klassen TransactionCreator. Denne oppretter objekt med bakgrunn i innsendt transaksjonsdata og klientid. Steg 3: En liste med Posting objekt opprettes ved å kalle på klassen PostingCreator. En liste med PostingData og en transaksjonsid sendes inn til klassen. For hver enkelt PostingData i listen sjekkes følgende: Et Posting objekt opprettes med bakgrunn i PostingData og transaksjonsid. Dersom posteringen inneholder en parenttransaction så betyr det at denne posteringen referer til en tidligere transaksjon. o ParentTransaction blir verifisert ved at strengen omgjøres til en Guid (parentguid). Dersom dette ikke lar seg gjøre kastes det en feilmelding. S i d e 25 53

26 o o Reference objektet knyttet til parentguid hentes fra databasen. Finnes ikke dette kastes det en feilmelding av typen PostingParentNotFoundException med meldingen «Cannot find Posting Parent». Reference objektet knyttes til posteringen. Dersom posteringen ikke har en parenttransaction betyr det at den selv blir en parent. Det betyr videre at det ikke eksisterer et Reference objekt tilhørende denne posteringen fra før, og et nytt Reference objekt opprettes og knyttes til posteringen. Steg 4: Listen med posteringer kobles til transaksjonen. Steg 5: For å fullføre operasjonen må transaksjonen settes inn i databasen, dette gjøres via TryInsert metoden i TransactionRepository. Dersom dette ikke går blir en feilmelding kastet og behandlet av modulen, som sender en kvittering med feilinformasjon til klienten. Steg 6: Dersom innsettingen er vellykket returnerer metoden Guid en til transaksjonen den nettopp har satt inn i databasen. S i d e 26 53

27 Figur 16 - [Lagring av en Transaction] OPPDATERE REQUEST MED GUID Etter at transaksjonen er vellykket lagret gjenstår det kun å oppdatere RequestContext databasen med transaksjonens Guid, slik at transaksjonen ikke blir behandlet på nytt dersom forespørsel sendes inn en gang til. Dette gjøres ved at TransactionRequestHandler kalles på nytt, og via metoden UpdateCompletedTransactionRequest blir transaksjonen oppdatert med Guid UTSENDELSE AV KVITTERING Det siste som gjøres etter at en transaksjon er vellykket lagret, er å sende kvittering til klienten. ReceiptSender klassen benyttes til dette, den genererer en kvittering som blir sendt til klientens kvitteringsmottaker. S i d e 27 53

28 Klient vil altså motta en kvittering uavhengig av om transaksjonen er vellykket eller ikke. Kvitteringen vil inneholde en Guid dersom vellykket, eventuelt en tom Guid og feilmelding dersom en feil oppstår underveis. 3.7 KVITTERINGER En kvittering sendes klienten som følge av tre mulige årsaker: En transaksjon er behandlet fra før En transaksjon er vellykket postert En feil har oppstått under behandlingen av en transaksjon Klienten vil motta like mange kvitteringer som antallet transaksjoner som er sendt inn, dette uavhengig i utfallet under behandlingen. Figur 18 - [Kvittering - flyt] S i d e 28 53

29 Kvitteringen inneholder fire element som vist i Figur 18. Figur 18 - [Kvitteringens innhold] Klient kan ved hjelp av disse kvitteringene oppdage potensielle problemer, eksempelvis manglende posteringer, ubalanse i transaksjon eller posteringer, ugyldige kontoer eller feil parentid. Modulen sender ut kvitteringer til klientes kvitteringsmottaker, det er imidlertid opp til klienten å håndtere mottaket av kvitteringene og behandle eventuelle feilmeldinger. Modulen tar altså ikke noe ansvar for at disse blir behandlet RECEIPTSENDER For at en kvittering skal kunne sendes må den klassen som tar seg av leveransen først ha en mottaker. Denne mottakeren er naturligvis hos klienten, og klienten må implementere denne for å kunne ta i bruk modulen. Sending av kvittering skjer i metoden SendReceipt i klassen ReceiptSender. TransactionReceipt receipt = new TransactionReceipt { RequestChecksum = _requestchecksum, Success = success, TransactionId = transactionid, ErrorMessage = errormessage }; receiver.receivetransactionreceipt(receipt); Her opprettes først en kvittering, før kvitteringen sendes med kallet receiver.recievetransactionreceipt. En receiver er direkte oversatt en mottaker, og dette er altså klientens mottaker for kvitteringer. S i d e 29 53

30 3.7.2 IMESSAGERECEIVER Klassen IMessageReceiver er et interface brukeren av modulen må implementere i sin klient. Klassen består kun av en metode, ReceiveTransactionReceipt, som tar imot en kvittering. Denne metoden kalles fra flere steder i modulen og sett fra dens perspektiv er dette kun en brevsprekk i en postkasse. Modulen er kun interessert i å sende kvittering avgårde, og overlater videre håndteringen av kvitteringen til klienten. Figur 19 - [Kvitteringsmottaker] S i d e 30 53

31 3.8 HENTE UT DATA Modulen har implementert diverse klasser for å hente ut data, dette skjer via egne leseklasser. Klassene inneholder kun metoder for uthenting av eksisterende data, det er ikke mulig å skrive til databasen via disse. Alle klassene benytter tilhørende Repository for å aksessere databasen. Modulen inneholder fire reader-klasser: TransactionReader PostingReader ReferenceReader AccountReader Figur 20 [Oversikt over reader klassene] UTTAK AV DATA TIL REGNSKAPSSYSTEM I dagens inkassosystem, K90, overføres posteringene til et eksternt regnskapssystem. Det skjer i nattkjøringen, hvor alle aktuelle posteringer fra forrige dag eksporteres. Tilsvarende funksjonalitet var naturligvis et krav for den nye løsningen, og det er løst i modulen ved å tilby uthenting av de aktuelle posteringene. Logikken er implementert i en egen klasse, ExtractDataToAccountingSystem. Aktuelle posteringer skrives til en strøm (stream) som klienten sender inn ved kall til klassen. S i d e 31 53

32 Aktuelle posteringer overføres til et regnskapssystem via et AccountingRequest objekt, bestående av antall posteringer og selve posteringene. Hver postering er gjengitt i et AccountingData objekt som inneholder: Transaksjonsdato Regnskapsår Regnskapsperiode Kontonummer ParentTransaction (Guid) Beløp Klassen har følgende metoder og funksjonalitet: Returverdi Metodenavn Parametere Funksjonalitet AccountingReq est ConvertToAccounting Request() (List<Posting> postings) En liste med posteringer konverteres til en liste med AccountingData. Disse legges så til et AccountingRequest objekt som returneres List<Posting> List<Posting> GetAllNonWritten() GetAllWritten() Returnerer en liste med alle posteringer for alle kontoene som har sin TransferToAccountingSystem satt true. Henter kun de posteringer som ikke er overført til regnskapssystemet fra før (posting.transferedtoaccounting System = null) (DateTime date) Returnerer en liste med alle posteringer som ble overført til regnskapssystemet på oppgitt dato bool WriteAllNonWritten( ) (Stream stream, bool update = true) Henter alle ubehandlede posteringer og serialiserer disse til en stream. Dersom update er true settes alle posteringene som S i d e 32 53

33 behandlet. bool WriteAllWritten() (Stream stream, DateTime date) 1.Kaller GetAllNonWritten() sender listen med ubehandlede posteringer til ConvertToAccounting Request() 2. Alle posteringene returneres som et AccountingReqest-objekt 3. AccountingReqest sendes til WriteToStream() med streamen metoden mottok 5. WriteToStream() sjekker om objektet er tomt og om det er mulig å skrive til den mottatte streamen 6. En XmlSerializer av typen AccountingReqest opprettes og serialiserer AccountingReqest objektet til streamen 7. Dersom update er true settes TransferedToAccountingSystem lik dagens dato for alle posteringer som er sendt til streamen 7. Bool returneres i henhold til resultat Henter alle posteringer som ble behandlet på den oppgitt datoen og serialiserer disse til streamen bool WriteToStream() (Stream stream, AccountingReque st accountingreque st) bool MarkPostingsAsUpdat ed() List<Posting> postings) 1. Mottar en liste fra GetAllWritten(date) over alle posteringer som ble overført den dagen date tilsier 2. Sender de behandlede posteringen til ConvertToAccounting Request() 3. Sender listen med AccountingRequest objekter videre til WriteToStream() 4. Returnerer samme returvedi som WriteToStream() Tar imot en stream og en AccountingRequest, sjekker at objektet ikke er tomt og at streamen er skrivbar, serialiserer AccountingRequesten til streamen og returnerer bool basert på utfall Tar imot en liste med posteringer (som nettopp har blitt overført til S i d e 33 53

34 regnskapssystemet) og markerer alle disse som overført ved å sette TransferedToAccountingSystem lik dagens dato Funksjonaliteten tas i bruk ved at regnskapssystemet tilbyr en datastrøm posteringene kan mottas på. Figur 21 - [Uthenting av regnskapsdata] 3.9 FEILHÅNDTERING Dersom modulen ble levert uten feilhåndtering ville den minste lille feil ført til at hendelsesforløpet hadde stoppet, og det på en måte som ikke hadde gitt hint om hva det var som hadde gått feil. S i d e 34 53

35 For at run-time errors ikke skal inntreffe har vi definert og fulgt et sett med prinsipper som er implementert i koden til modulen. Disse prinsippene identifiserer potensielle farer ved visse handlinger/bruk av kodemønstre, beskriver graden av fare dette utgjør og løsning på faren. # Fare Faregrad Løsning 1 Databasekall kaster exception 2 Innsendt forespørsel inneholder feil Alvorlig Alvorlig Håndter alle databasekall i try-catch blokk, håndter exceptions på en forsvarlig måte Valider hver forespørsel helt ned på posteringsnivå før forespørselen bokføres EXCEPTIONS For nøyaktig identifiering av potensielle feil har vi implementert våre egne exceptions. Hensikten med dette er å innsnevre identifiseringen av et inntruffet problem. Samtlige exceptions kalles på et punkt under validering av forespørsler, dersom gitt scenario inntreffer. Følgende unntak har fått sine egne exceptions: Exception Bruksområde Message EmptyPostingData Kastes hvis en transaksjon ikke inneholder noen posteringer «Transaction has no Postings» InvalidAccount Kastes hvis en postering «Invalid Account: {int inneholder en konto som ikke accountno}» eksisterer i modulen InvalidPostingBalance Kastes hvis et sett med «Postings are not in InvalidTransactionBalance posteringer ikke er i balanse Kastes hvis posteringene ikke stemmer med transaksjonens beløp InvalidRequest Kastes hvis et TransactionRequest ikke er gyldig formatert PostingParentNotFound Kastes hvis en oppgitt parentid ikke finnes i databasen TransactionHandledBefore Kastes hvis en transaksjon som er ferdig behandlet i systemet tidligere blir sendt inn på nytt balanse{double balance}» «Invalid Transaction balance: [Sum Transaction: {double transactionamount}] [Sum Postings: {double postingsamount}]» «Invalid request: {string requestchecksum}» «Cannot find Posting Parent: {Guid parentguid}» «Transaction handled before» S i d e 35 53

36 Alle unntakene arver standard exception, og hvert exception har unik implementasjon SPORBARHET Et viktig krav til modulen er at transaksjoner og posteringer er sporbare i ettertid, det vil si at man skal lett finne tilbake til den opprinnelige kilden til posteringen. For å løse dette innførte vi Guid i modulen siden denne er garantert unik, og i vår kontekst er det parenttransactionid (Guid) som garanterer sporbarhet. Alle posteringer blir stemplet med parenttransactionid, og på den måten er det enkelt å finne alle posteringer knyttet til en gitt betaling eller annen form for transaksjon. Ved å sortere alle posteringer som har samme parenttransactionid vil man kunne se historikken til en gitt betaling fra start til slutt. Figur 22 - [Sporbarhet] S i d e 36 53

37 3.11 ASYNC/SYNC HÅNDTERING Modulen er utviklet med to mulig løp, et synkront og et asynkront 2. Begge har nøyaktig samme funksjonalitet, men den asynkrone vil kjøre flere tråder samtidig og derfor behandle forespørsler raskere. Eksempelvis inneholder RequestHandler to metoder som i prinsippet utfører de samme handlingene, dette er forklart litt nærmere under. Metoden CreateTransactions håndterer hver transaksjon sekvensielt. Dette innebærer at listen med transaksjoner itereres igjennom fra start til slutt og håndteres en av gangen. Klienten vil derfor motta kvitteringer på behandlet transaksjon i samme rekkefølge som de er arrangert i innsendt forespørsel. En transaksjon fullføres før modulen tar tak i en ny. CreateTransactionsAsync behandler transaksjonene i en forespørsel asynkront. Asynkron håndtering innebærer (ved korrekt bruk) at hver transaksjon tildeles sin egen tråd i operativsystemet. På denne måten kan flere transaksjoner (tråder) håndteres tilsvarende samtidig av CPU en. Operativsystemet behøver altså ikke vente på at en transaksjon er ferdig behandlet før en ny kan tas tak i. Synkron Transactions håndtering eks. Asynkron Transaction håndtering eks. foreach (var trans in request.transactions) { try { TransactionValidator.VerifyPostings(); TransactionHandler.CreateTransaction(); TransactionRequestHandlerUpdateRequestGuid(); ReceiptSender.SendReceipt(); } catch (Exception e) { ReceiptSender.SendReceipt(); } List<Task> tasks = new List<Task>(); foreach (var trans in request.transactions) { tasks.add(task.run(() => CreateTask(trans, request.requestchecksum))); } Task.WaitAll(tasks.ToArray()); Async Task CreateTask(TransactionData trans, string requestchecksum) { //Do same as in sync method } 2 S i d e 37 53

38 Hensikten med implementasjon av både sync og async metoder er å kunne tilby klienten den løsningen som passer best. Klienten kan nå selv fritt benytte seg av den funksjonaliteten som er mest hensiktsmessig. For at modulen skal være asynkron/synkron gjennom hele hendelsesforløpet er det implementert asynkrone og synkrone metoder med samme funksjonalitet flere steder i modulen. 4 OPPBYGGING Dette kapittelet beskriver Arena Kundereskontros interne oppbygging. Kapittelet vil beskrive klasser, modeller og namespaces, sammenhengen mellom disse, prosjekter og deres dependencies og dataflyten ved sentrale prosesser i modulen. Kapitelets formål er å gi leseren en tilstrekkelig innføring i modulens struktur og oppbygning. 4.1 PROSJEKTSTRUKTUR Løsningen består av fire prosjekter: ArenaKundereskontro ArenaKundereskontro.Tests Test WebAPI Her inneholder det første prosjektet modulen, det andre enhetstester og testmetoder til modulen, det tredje et testprogram gruppen benyttet under utviklingen av produktet, og det fjerde et Web API. ArenaKundereskontro er helt selvstendig og er uavhengig av de andre prosjektene. De øvrige benytter seg alle av klassebiblioteket, og er derfor avhengige av ArenaKundereskontro. Figur 23 - [Prosjektstruktur] S i d e 38 53

39 4.2 ORGANISERING AV KLASSER - NAMESPACES ArenaKundereskontro består av åtte ulike namespaces. Formålet med innføringen av disse var å kategorisere funksjonaliteten til modulen i ulike bruksområder. Foruten det faktum at bruk av namespaces anses til å være god generell kodestandard bidrar det dessuten i å holde prosjektet ryddig og strukturert. Dersom navngivningen til disse namespacene er logiske vil en utestående deltaker kunne sette seg inn i et prosjekts ulike egenskaper og på den måten enklere danne seg et bilde av hvordan prosjektet fungerer. Vi har bruk mye tid på å gjøre navngivningen så logisk som mulig, og mener navnene står i samsvar med det vi prøver å formidle. En komplett oversikt over alle namespaces og tilhørende klasser er gjengitt i tabellen nedenfor. Klassetype Færgekode Datamodell Grønn Databaseaksessor Sort Context Sort Interface Lyseblå Databehandler Blå Exceptions Rød Namespace Klasser Innehold Accounts Account AccountCsv AccountReader AccountWriter AccountRepository Clients Client ClientManager ClientRepository IArenaKundereskontroClient Context AKContext RequestContext Alt som omhandler en «Konto» i modulen. Inkluderer domenemodellen Account, CSVrepresentasjon av en konto og aksessorer for å skrive og lese en konto. Alt som omhandler en «Klient» i modulen. Inkluderer domenemodellen Client, aksessor for å skrive og lese, samt implementasjonen en bruker av klassebiblioteket må implementere for å identifisere seg. De to kontekstene datastrukturen i modulen. S i d e 39 53

40 Exceptions EmptyPostingDataException InvalidAccountException InvalidPostingBalanceException InvalidRequestException InvalidTransactionBalanceException PostingParentNotFoundException TransactionHandledBeforeException Alle egendefinerte Exceptions som indikerer feilsituasjoner i henhold til innlesing av forespørsler i systemet. Export ExtractDataToAccountingSystem Funksjonalitetet for å hente ut data til regnskapssystem. Requests Request RequestTransaction TransactionRequestCreator TransactionRequestHandler RequestRepository RequestHandler Transactions Transaction Posting Reference TransactionCreator PostingCreator TransactionHandler TransactionValidator AmountValidator TransactionReader PostingReader ReferenceReader TransactionRepository PostingRepository RefenceRepository Transmission AccountingData TransactionData PostingData AccountingRequest TransactionRequest TransactionReceipt IMessageReceiver ReceiptSender Alt som omhandler en «Request» i modulen. Innkluderer de to modellen som lagres i klientens sin database, Request og RequestTransaction, samt klasser som utfører logikk på disse. Alt som omhandler en «Transaksjon» i modulen. Innkluderer modellene knyttet til en transaksjon, klasser for lesing og skriving, samt logikk for validering i henhold til regnskapsprinsipper. Alt som skal sendes mellom klient og modulen. Her ligger XMLrepresentasjonene som modulen støtter. Disse klassene vil fungere som «beholdere» og ansvare over at «flytte» data. S i d e 40 53

41 Figur 24 - [Klasseoversikt] 4.3 BENYTTEDE BIBLIOTEKER & RAMMEVERK Modulen er et produkt fullstendig utviklet av oss i gruppen. Dette innebærer at alt fra start til slutt, systemarkitektur og kode, er et resultat av gruppens arbeid. All kode er med andre ord egenprodusert. Vi har på tross av dette naturligvis benyttet oss av eksisterende biblioteker og rammeverk MICROSOFT.NET FRAMEWORK Det mest sentrale rammeverket benyttet i oppgaven er.net Framework 3. Dette rammeverket er integrert i utviklermiljøet vi har tatt i bruk (Visual Studio) og er utviklet av Microsoft. Dette inneholder blant annet ASP.NET, Entity Framework, LINQ og Framework Class Library, som alle benyttes i stor skala. 3 S i d e 41 53

42 4.3.2 ENTITY FRAMEWORK Entity Framework 4 er et ORM (Object-relation mapper) som benyttes i produktet. Hensikten med dette er å konvertere databasetabeller til objekter for at siden å operere med disse objektene i stedet for at implementere egen dataaksesseringskode LINQ LINQ (Language Intergrated Query) benyttes for utføre «spørringsuttrykk», som ligner på SQL, for å ekstrahere data fra forskjellige datastrukturer som arrays og lister. Det brukes også sammen med Entity Framework i repositoriene for å filtre uthentingen av data fra konteksten MOQ MOQ 5 er et «mocking-rammeverk» som benyttes for enhetstesting av klassene i modulen. Mocking kan beskrives som at simulere dataobjekter, hvilket er nødvendig når testing av klasser som er avhengig av data skal utføres. Data som ellers må ligge i en database er med MOQ mulig å simulere. Dette er brukt i testprosjektet ArenaKundereskontro.Test og nevnt i [Testrapporten] FILEHELPERS FileHelpers 6 er et.net bibliotek som gjør det mulig å importere og eksportere data fra bland annet CSV filer, og parse/oversette disse til et objekt. Dette er benyttet for å importere en kontoplan i modulen S i d e 42 53

43 4.4 MODELLER DOMENEMODELLER Lagring av data skjer via modeller. Vi har benyttet «Code First», et mye brukt prinsipp i Entity Framework. Dette prinsippet går ut på å definere objekter i gjennom kode, deretter koble disse objektene til en kontekst, for deretter å kunne foreta lesing/skriving mot objektene via konsteksten. Modulen har følgende syv domenemodeller, hver av fem eksisterer i AKContext og to i RequestContext: Klasse Representerer Nytte Transaction AKContext Posting AKContext Client AKContext Reference AKContext Account AKContext RequestTransaction RequestContext Request RequestContext Representerer en bokført transaksjon med tilhørende posteringer Representerer en bokført postering med beløp og konto Representerer en klient som benytter seg av systemet Representerer en referanse knyttet til en transaksjon Representerer en konto Representerer en Transaksjons-forespørsel Representerer et sett med RequestTransactionobjekter Alle transaksjoner lagres som et Transaction-objekt i databasen Hver transaksjon har to/flere posteringer lagret som egne posterings-objekter Gjør det mulig å finne ut hvem som har opprettet en transaksjon i modulen. Som regel vil alle klienter ha en referanse i sitt system knyttet til en transaksjon (sak). Denne refereansen knyttes til en foreldertransaksjon for å gjøre en transaksjon sporbar. Alle gyldige posterings-kontoer skal være lagres som selvstendige Account objekt Lagres i request-tabellen, hvor henvendelser lagres med id og guid. Benyttes for å identifisere og behandle en fullstendig forespørsel. S i d e 43 53

44 Figur 25 - [Domenemodeller i AKContext] Figur 26 - [Domenemodeller i RequestContext] XML MODELLER Modulen benytter i tillegg til domenemodellene også XML-objekter. Et XML-objekt er en klasse som innholder XML-attributter for å definere hvordan klassen ser ut i som XML. Disse taggene gjør det mulig å konvertere et objekt til og fra XML med klassene XmlSerializer og XmlDeserializer i.net. For å konvertere til et objekt er XMLdatan nødt til å være utformet som definert i objektet. Klasse Representerer Nytte TransactionRequest Representerer en forespørsel sendt fra klient med transaksjoner og tilhørende posteringer Xml-filen som sendes til modulen konverteres til et TransactionRequest objekt før det behandles videre TransactionData Representerer en I prosessen fra en forespørsel S i d e 44 53

45 PostingData AccountingData AccountingRequest TransactionReceipt Transaksjonsforespørsel sett ifra xml-filens definisjon på en transaksjon Representerer en Posteringsforespørsel sett ifra xml-filens definisjon på en gitt postering Representerer en postering som overføres til et eksternt regnskapssystem Representerer et sett med AccountingData Representerer en transaksjonskvittering ankommer til den posteres behandles dataene i transaksjonen som et TransactionData-objekt Inneholder dataen til en individuell postering tilhørende et TransactionData objekt Innholder informasjon om posteringen, i tilegg til nødvendig data fra dens transaksjon. Eksisterer i en AccountRequest. Holder oversikt over hele sett med posteringer (AccountingData-objekter) som er overført til regnskapssystem Sendes som dokumentasjon på en behandlet transaksjon. Figur 27 - [XML modeller] S i d e 45 53

46 4.5 DATALAGRING/DATAAKSESSERING Håndtering av dataflyten til og fra databasen er en viktig del av løsningen. Flyten må også implementeres på et sett som opprettholder god programmerings-standard i henhold til ryddig og strukturert kode. Bruk av repositories oppfyller alle kravene vi hadde til trygg data-aksessering. Et repository inneholder skreddersydde metoder for et spesifikt objekt, og kan inneholde alle metoder et system trenger for å legge til/aksessere eksisterende/modifisere eksisterende objekter. Repositoriene fungerer som mellom-stadier imellom «databasen (konteksten) og «brukeren (systemet via repository-metodene). Vi har implementert repositories for alle domenemodeller, som gjengitt i følgende tabell: Repository AccountRepository ClientRepository Aksess-klasser AccountReader AccountWriter ClientManager TransactionRepository TransactionReader PostingRepository RequestRepository ReferenceRepository PostingsReader TransactionRequestHandler ReferenceReader Aksess-klasser er implementert for å kun gi enten skrive-tilgang eller lese-tingang. Dette er hensiktsmessig i tilfeller hvor en gitt klasse har behov for å benytte seg av en del av funksjonaliteten i et repository, men ikke alt (for eksempel kun lesefunksjonalitet). Disse klassene er resultatet av programmering i henhold til prinsippet on minste privilegium, altså at en bruker kun skal gis tilgang til nødvendig funksjonalitet. 4.6 SIKKERHET Aksess til kontekst skjer alltid via de forskjellige repository-klassene. Gjennom å forhindre brukere av klassebibliotek direkt aksessering til kontekst er det ikke mulig å slette eksisterende data. I og med at det ikke skal være mulig å fjerne posteringer/transaksjoner (etter oppdragsgivers krav) inneholder ikke noen av S i d e 46 53

47 repository-klassene funksjonalitet for å slette data. Produktet er derfor sikkret mot at data ikke kan bli slettet. Detsamme gjelder innsetting av data i modulen. For å lagre noe til databasen er man nødt til å bruke en klasse som i forkant vil prosessere å validere uppgiftene før disse blir lagret. Det forsikkrer at det er kun reell data som blir lagret i databasen. Det er også tatt et bevisst valg om å sette restriksjoner av hva en bruker har adgang til og ikke med hjelp av access modifiers ACCESS MODIFIERS «Access Modifiers» er nøkkelord som brukes i objektorienterte språk for å bestemme aksessibilitet av klasser, metoder og attributter. C# har følgende nøkkelord som klassebiblioteket benytter: Attributt Private Internal Public Kan aksessers av Klassen Kun klassebiblioteket Alle De klasser som kun skal aksesseres av Arena Kundereskontro har fått nøkkelordet internal. Dette er brukt på klasser der tanken er at de ikke skal brukes utenfør kjernen, deriblandt repositories. Metoder som utgjør en intern jobb i en klasse er satt til private, og er kun en jobb som skal utføres av klassen selv. Alt som skal være mulig å aksessere av de som implementerer klassebiblioteket er satt til public. 4.7 PROGRAMMERINGS STANDARD Programmerings standard beskriver retningslinjer og bevisste valg vi har fulgt under utviklingen av produktet. Disse standardene er direkte resultat av retningslinjer mottatt av arbeidsgiver, og er definert i kapittel 7 [Retningslinjer]. S i d e 47 53