D Softwarearkitektur

Transkript

1 <Kundenavn> <Projektnavn> Version: 1.0 Status: Endelig Godkender: <Fjernet>. Alle rettigheder forbeholdes. Elektronisk, mekanisk, fotografisk eller anden gengivelse, oversættelse eller kopiering af dette dokument eller dele deraf er, uanset formål, ikke tilladt uden forudgående skriftlig tilladelse fra Netcompany A/S.

2 Dokumenthistorik Version Dato Navn Status Bemærkninger <Fjernet> Udkast <Fjernet> Udkast <Fjernet> Udkast <Fjernet> Udkast Første udkast til disposition Use-case model beskrevet Første udkast til design model Use-case model revideret <Fjernet> Udkast Design model revideret <Fjernet> Udkast Sikkerheds-perspektiv tilføjet <Fjernet> Udkast Internt review <Fjernet> Endelig Afleveret til Kundennavn. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 2 af 53

3 Indholdsfortegnelse 1 INTRODUKTION Omfang Definitioner og forkortelser Referencer Læsevejledning 6 2 ARKITEKTURMÆSSIGE MÅL OG RAMMER Teknisk platform Brugervenlighed og design Statistik Migrering af data Sikkerhed Kapacitet og performance Tilgængelighed Skalerbarhed 9 3 USE-CASE PERSPEKTIV Use cases for e-handelsløsning Brugerhåndtering Use cases for CMS-platform 16 4 LOGISK PERSPEKTIV Overblik E-handelsløsningen Frontend Backend Integration Data Access Common CMS-Platform Frontend Backend Database Integration 44 5 DATA-PERSPEKTIV 46 6 IMPLEMENTERINGS-PERSPEKTIV 47 7 DEPLOYERINGS-PERSPEKTIV 48 8 SIKKERHEDS-PERSPEKTIV Sikkerhedskrav Autentificering Autorisering Sikker kommunikation STRIDE-modellen Spoofing Tampering 51 Fil:.doc Version 1.0 Udskrevet: :32:00 Side 3 af 53

4 8.2.3 Repudiation Information disclosure Denial of service Elevation of privilege 53 Fil:.doc Version 1.0 Udskrevet: :32:00 Side 4 af 53

5 1 Introduktion Formålet med dette dokument er at give et overblik over softwarearkitekturen for <Kundennavn>s nye e-handelsløsning og CMS-platform. Softwarearkitekturen beskrives ved at inddrage forskellige perspektiver, som belyser systemet fra forskellige synspunkter og henvender sig til forskellige interessenter. Logisk perspektiv Data-perspektiv Sikkerhedsperspektiv Use-case perspektiv Implementeringsperspektiv Deployeringsperspektiv Arkitekturmæssig repræsentation Tilsammen giver perspektiverne et komplet billede af softwarearkitekturen. Use-case perspektiv Repræsenterer use-case modellen og beskriver sammen med D Brugergrænsefladedesign systemet fra et brugersynspunkt. Perspektivet er relevant for alle systemets interessenter. Logisk perspektiv Repræsenterer design modellen og beskriver systemets væsentligste klasser og deres organisering i delsystemer, komponenter, pakker, og lag. Det logiske perspektiv indeholder også den logiske datamodel. Perspektivet er relevant for designere og udviklere. Data-perspektiv Repræsenterer data modellen og beskriver den fysiske repræsentation af data i systemet. Perspektivet er relevant for udviklere og databaseadministratorer. Implementerings-perspektiv Repræsenterer implementerings-modellen og beskriver de logiske delsystemer med Fil:.doc Version 1.0 Udskrevet: :32:00 Side 5 af 53

6 henblik på at afklare deres konstruktionsmæssige afhængigheder. Perspektivet er relevant for udviklere. Deployerings-perspektiv Repræsenterer deployerings-modellen og beskriver konfigurationen af det fysiske afviklingsmiljø. Perspektivet er relevant for udviklere og driftspersonale. Sikkerheds-perspektiv Beskriver systemets sikkerhedsmæssige aspekter, herunder autentificering og autorisering. 1.1 Omfang Dokumentet dækker softwarearkitekturen for e-handelsløsningen og CMS-platformen. 1.2 Definitioner og forkortelser Definition Systemet Kunden Leverandøren Beskrivelse Internetplatformen bestående af E-handelsløsningen og CMS-platformen Kundennavn Netcompany Forkortelse Beskrivelse AD Microsoft Active Directory BizTalk Microsoft BizTalk Server IIS Microsoft Internet Information Server 1.3 Referencer 1. Kunden: Screen Design Guidelines, Kontrapunkt, 12. jan Kravspecifikation for ny e-handelsløsning og CMS-platform, Devoteam Consulting, 9. sep Læsevejledning I afsnit 2 beskrives de arkitekturmæssige mål og rammer for systemet. I afsnit 3 beskrives use-case perspektivet, som belyser systemet fra et brugersynspunkt. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 6 af 53

7 I afsnit 4 beskrives det logiske perspektiv, som belyser systemet fra et design og udviklingssynspunkt. I afsnit 5 beskrives data-perspektivet, som belyser den fysiske persistering af data. I afsnit 6 beskrives implementerings-perspektivet, som belyser systemet fra et konstruktionssynspunkt. I afsnit 7 beskrives deployerings-perspektivet, som belyser systemet fra et driftssynspunkt. I afsnit 8 beskrives sikkerheds-perspektivet, som beskriver hvordan systemet håndterer sikkerhedskravene og belyser sikkerheden ud fra STRIDE-modellen. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 7 af 53

8 2 Arkitekturmæssige mål og rammer Dette afsnit beskriver ikke-funktionelle krav af væsentlig betydning for arkitekturen, herunder krav til den tekniske platform, til brugergrænsefladen, statistik, migrering af data, sikkerhed, kapacitet og performance, samt skalerbarhed. 2.1 Teknisk platform Systemets specialudviklede software udvikles på.net 2.0 platformen og afvikles på en Microsoft Internet Information Server i samspil med Microsoft Commerce Server 2007, Sitecore og Microsoft BizTalk Server Den tekniske platform er nærmere beskrevet i D0120 Teknisk infrastruktur oversigt. Løsningens standard-programmel og værktøjer sikrer at systemet overholder godkendte grænseflade-standarder, herunder W3C for HTML og Webservices. 2.2 Brugervenlighed og design Følgende krav til systemets brugergrænseflade er af betydning for arkitekturen: 1. Web-brugergrænsefladen skal følge design retningslinier for Apoteket.dk og skal genbruge den eksisterende navigationsramme. 2. Web-brugergrænsefladen skal understøtte Internet Explorer 6 og opefter, Firefox 1.5 og opefter, Safari 2.0 og opefter. 3. Web-brugergrænsefladen for dele af CMS-platformen og hele e-handelsløsningen skal kunne vises i en frame på sundhed.dk. E-handelsløsningen skal her begrænse sortimentet til apoteksforbeholdte varer. 4. Udformning af recepter skal samordnes med udformningen af recepter på Sundhed.dk. Systemets brugergrænseflade er beskrevet i D Brugergrænseflade-design. 2.3 Statistik Systemet skal kunne indsamle en række statistiske oplysninger om brugernes anvendelse af internet platformen. Statistiske rapporter genereres ved brug af standardværktøjer i Microsoft Reporting Services og Microsoft Commerce Server Rapporterne er specificeret i D Brugergrænseflade-design. 2.4 Migrering af data Den nye løsning erstatter en eksisterende, og overgangen skal ske med størst mulig kontinuitet. Håndteringen af dette aspekt er beskrevet i D Konverteringsdesign. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 8 af 53

9 2.5 Sikkerhed Systemets håndtering af sikkerhed beskrives i sikkerhedsperspektivet, afsnit Kapacitet og performance Systemet skal kunne håndtere en gennemsnitlig belastning på besøgende og sidevisninger per uge efter en performance model, som vil blive aftalt med Kunden. Systemet skal endvidere kunne håndtere en datamængde svarende til sortimenter for 160 apoteker. Løsningen designes og deployeres således at batch-kørsler kan afvikles uden væsentlig performance-degradering på websitet. 2.7 Tilgængelighed For at minimere systemets nedetid bliver produktionsmiljøet opsat med fail-over på samtlige kritiske servere (webservere, databaseserver og biztalk server). Synkrone afhængigheder til apotekssystemer (receptopslag) vil dog gøre at man periodevist kan være afskåret fra at handle på recept hos et specifikt apotek, hvis der ikke er adgang til dets apotekssystem. 2.8 Skalerbarhed Systemet skal kunne skaleres til at understøtte flere brugere og større mængde information. Skalerbarhed sikres dels gennem standard-produkter som IIS, Biztalk og SQL Server, og dels gennem overholdelse af best-practices og retningslinier for programmering. Der vil være mulighed for vertikal skalering ved at placere kraftigere hardware (f.eks. flere CPU er) i den leverede hardwarekonfiguration. Der vil være mulighed for horisontal skalering, gennem tilføjelse af yderligere tilstandsløse web servere og/eller flere BizTalk servere. På databaseserveren er der fra start foretaget en logisk partitionering af data. Disse partitioner kan distribueres på yderligere database servere. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 9 af 53

10 3 Use-case perspektiv Dette afsnit giver et overblik over systemet fra et brugersynspunkt ved at beskrive aktører og væsentlige use-cases. Alle use cases tager udgangspunkt i kravspecifikationen og indarbejder eventuelle afklaringer og ændringer som er aftalt undervejs i afklarings- og designfasen. Enkelte use-cases erstattes af andre (B.5-7) og enkelte nye use-cases er introduceret (B.12-14, C.4-5). Use case modellen er detailspecificeret med sideskitser i D0160 Brugergrænseflade-design, og sammen giver de et komplet billede af systemet set fra brugerens synspunkt. System E-handelsløsning Brugerhåndtering TDC Nøglecenter Varekøb Kunde Leverandør af vareinfo Abonnement CMS-platform Apotekssystem Receptserver Tilgængelige funktioner Internetbruger Brevkasse Redaktionsmiljø Redaktør Figur 1: Samlet overblik Væsentligste aktører Aktør Beskrivelse Fil:.doc Version 1.0 Udskrevet: :32:00 Side 10 af 53

11 Aktør Apotekssystem Internetbruger Kunde Leverandør af vareinfo Beskrivelse Dækker over apotekssystemerne som en helhed. En person som tilgår CMS-platformen med en webbrowser. En person som tilgår e-handelsløsningen med en webbrowser. Dækker over alle leverandører af vareinformation, herunder beskrivelser, billeder priser for apoteksforbeholdte varer. Leverandører er: Medicinpriser.dk (LMS Takst), Interaktionsdatabasen, Nomeco grossistkatalog, Apotekssystemet (specialvarer), Medicinhåndbogen. Receptserver TDC nøgleservice Lægemiddelstyrelsens receptserver (Medicinprofilen), som samler elektroniske recepter. TDC s service til validering af OCES personcertifikater. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 11 af 53

12 3.1 Use cases for e-handelsløsning Dette afsnit beskriver use cases for e-handelsløsningen, og inddeles i områderne Brugerhåndtering, Varekøb og Abonnement. E-handelsløsning Brugerhåndtering TDC Nøglecenter Varekøb Kunde Leverandør af vareinfo Abonnement Apotekssystem Figur 2: Overordnet use case model for e-handelsløsning Brugerhåndtering I dette af afsnit beskrives hvordan systemet håndterer brugere, herunder oprettelse, autentificering, vedligeholdelse af kundedata og sletning. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 12 af 53

13 Brugerhåndtering Opret bruger (A.1) TDC Nøglecenter Log in/ud Kunde Rediger bruger (A.2) Slet bruger (A.3) Administrator Figur 3: Use-case model for brugerhåndtering Opret bruger (A.1) Use Case A.1 Opret bruger ID A.1 Pakke Brugerhåndtering Version 1.0 Formål: Aktører: Systemer: Beskrivelse: Startbetingelser: Slutbetingelser: At oprette ny bruger Kunde e-handelsløsning, TDC nøglecenter Kunden ønsker at bestille en receptpligtig vare online og har behov for at oprette sig som bruger på e-handelsløsningen Kunden har en gyldig digital signatur. Kunden er oprettet som bruger på systemet og har registreret sine profiloplysninger og stamdata. Normalt flow: Fil:.doc Version 1.0 Udskrevet: :32:00 Side 13 af 53

14 Use Case A.1 Opret bruger ID A.1 Pakke Brugerhåndtering Version 1.0 Trin Aktør System 1 Kunden vælger at oprette sig som bruger med sin digitale signatur Hvis kunden ikke har en digital signatur, henvises han til TDCs website for den offentlige digitale signatur. 2 Kundens browser prompter for valg af digital signatur og herefter for password. Systemet forespørger kundens browser om digital signatur. Systemet modtager kundens personcertifikat og registrerer certifikatets unikke identifikation (PID). Herefter bedes kunden om at indtaste sit CPR-nummer. 3 Kunden indtaster CPR-nummer. Systemet kalder TDC s nøgleservice og validerer at det registrerede certifikat er udstedt til personen med det indtastede CPR-nummer. Systemet viser en formular til indtastning af personlige oplysninger, herunder navn, hjemmeadresse, , telefon, mobiltelefon, samt præferencer for format og SMS-notifikation. 3 Kunden indtaster sine personlige oplysninger. 4 Kunden indtaster sine e- handelsoplysninger. 5 Kunden indtaster sine interesseområder. 6 Kunden læser og accepterer samtykkeerklæringen. Systemet viser en formular til indtastning af e-handelsoplysninger, herunder foretrukket apotek (ved hjælp af Use case B.1 Søg apotek), foretrukket leveringsmetode, leveringsadresse (hvis forskellig fra hjemmeadresse), medlemskab af Sygesikring Danmark. Systemet viser en formular til indtastning præference for deltagelse i brugerundersøgelser, samt liste af interesseområder, grupperet efter kategori, som kan afkrydses. Systemet viser en samtykkeerklæring og et afkrydsningsfelt for accept. Systemet opretter kunden som bruger med de indtastede oplysninger. Undtagelser: Noter Fil:.doc Version 1.0 Udskrevet: :32:00 Side 14 af 53

15 Rediger bruger (A.2) Use Case A.2 Rediger bruger ID A.2 Pakke Brugerhåndtering Version 1.0 Formål: Aktører: Systemer: Beskrivelse: Startbetingelser: Slutbetingelser: At redigere profiloplysninger og stamdata for en kunde. Kunde e-handelsløsning Kunden ønsker at ændre sine profiloplysninger eller stamdata. Kunde er oprettet som bruger og er logget ind. Kundens profiloplysninger og stamdata er rettet. Normalt flow: Trin Aktør System 1 Systemet viser en formular til indtastning af personlige oplysninger, herunder navn, hjemmeadresse, , telefon, mobiltelefon, samt præferencer for format og SMS-notifikation. 2 Kunden indtaster sine personlige oplysninger. 3 Kunden indtaster sine e- handelsoplysninger. 4 Kunden indtaster sine interesseområder. Systemet viser en formular til indtastning af e-handelsoplysninger, herunder foretrukket apotek (ved hjælp af Use case B.1 Søg apotek), foretrukket leveringsmetode, leveringsadresse (hvis forskellig fra hjemmeadresse), medlemskab af Sygesikring Danmark. Systemet viser en formular til indtastning præference for deltagelse i brugerundersøgelser, samt liste af interesseområder, grupperet efter kategori, som kan afkrydses. Systemet opretter kunden som bruger med de indtastede oplysninger. Undtagelser: Noter Slet bruger (A.3) Use Case A.3 Slet bruger ID A.3 Pakke Brugerhåndtering Version 1.0 Formål: At slette bruger Fil:.doc Version 1.0 Udskrevet: :32:00 Side 15 af 53

16 Use Case A.3 Slet bruger ID A.3 Pakke Brugerhåndtering Version 1.0 Aktører: Systemer: Beskrivelse: Startbetingelser: Slutbetingelser: Administrator eller Kunde E-handelsløsning Kunden, eller Administrator på vegne af kunden, ønsker at slette sin brugerprofil. Kunde er logget på e-handelsløsningen eller Administrator er logget på Commerce Server 2007 administrationsmodulet. Kundens brugerprofil er slettet. Normalt flow: Trin Aktør System 1 Administrator fremfinder Kunde via søgedialog i Commerce Server 2007 administratormodul og vælger Delete. Systemet viser en advarsel der forklarer konsekvensen af sletning, og beder om bekræftelse. eller Kunden vælger Nedlæg brugerprofil via Min side. 2 Kunde eller Administrator insisterer. Eventuelle abonnementer knyttet til kunden slettes fra systemet. Eventuelle ordrer knyttet til kunden (åbne eller lukkede) slettes ikke. Undtagelser: Noter Systemet sender en til kunden med bekræftelse. Kundens brugerprofil slettes. < En større række use cases er fjernet > 3.2 Use cases for CMS-platform Use cases for CMS-platformen er uændrede i forhold til kravspecifikationen. Der henvises til D0160 Brugergrænseflade-design for detaildesign og yderligere specifikation. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 16 af 53

17 4 Logisk perspektiv Denne sektion beskriver de dele af designmodellen, som er væsentlige for arkitekturen, herunder systemets nedbrydning i delsystemer. For hvert delsystem beskrives arkitekturmæssigt væsentlige komponenter, lag og klasser, og deres ansvar beskrives sammen med en indikation af de væsentligste relationer, operationer og attributter. 4.1 Overblik Det følgende diagram viser systemets væsentligste bestanddele (se også D0120 Teknisk infrastruktur oversigt). Klienter Browser Webservice Klient Forfatterværktøj Apoteket.dk Internet Information Server e-handelsløsning CMS-platform MS Commerce Server Sitecore Ankiro SQL Server BizTalk Server Active Directory Eksterne systemer TDC OCES Apotekssystemer Medicinpriser.dk Mobitech SMS Gateway Interaktionsdatabase Medicinhåndbogen DIBS Nomeco Figur 4: Overblik Fil:.doc Version 1.0 Udskrevet: :32:00 Side 17 af 53

18 Softwarekomponenterne for e-handelsløsningen og CMS-platformen er specialudviklet. Alle andre løsningskomponenter er standard-software. I det følgende beskrives designmodellen for de to komponenter. 4.2 E-handelsløsningen E-handelsløsningskomponenten implementeres som en web-applikation og afvikles på IIS. E-handelsløsningens klasser er organiseret i pakker og lag, som hver har et specifikt ansvarsområde. Lagene og deres afhængigheder er vist i nedenstående diagram. «layer» Frontend «uses» «layer» Backend «layer» Common «uses» «uses» «layer» Integration «layer» Data Access Figur 5: E-handelsløsningens lagdeling Lag Frontend Frontend laget har ansvaret for rendering og styring af webbrugergrænsefladen og indeholder kontroller og hjælpeklasser til formålet. Desuden har frontend laget ansvar for webservices, som udstilles til interne og eksterne klienter. Backend Backend laget har ansvaret for forretningslogikken og indeholder domæne-entiteterne. Integration Integrationslaget har ansvaret for integrationer til Microsoft Commerce Server 2007, eksterne systemer (CMS, Apotekssystemer, Interaktionsdatabasen, DIBS, TDC OCES, SMS Gateway). Fil:.doc Version 1.0 Udskrevet: :32:00 Side 18 af 53

19 Lag Data Access Common Har ansvaret for persistering af data og indeholder Connection, Command, og DataAdapter klasser. DataAdapter klasser genereres for hver entitet og leverer type-specifikke DataSet klasser. et for mapningen af DataSet til domænet ligger hos domæne-entiteterne i Backend laget. Common-laget har ansvaret for generisk understøttende funktionalitet, herunder logging, caching og formatering. Indholdet af hvert lag er specificeret nedenfor. Frontend Common UI Service Cache Backend Log Apotek Indkøbskurv Abonnement Kunde Utility Recept Ordre Varekatalog Lægemiddel Integration Data Access Apotekssystem CMS TDC DB SMSGateway DIBS Commerce Server Figur 6: E-handelsløsningens lag og pakker I det følgende gennemgås indholdet af de væsentligste pakker. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 19 af 53

20 Notation r med stereotypen <<entity>> er persistente, og udgør tilsammen den logiske datamodel. Mapningen af entiteter til den fysiske datamodel er givet i afsnit 5 - Dataperspektiv. r med stereotypen <<enumeration>> er konstanter og fastlagt på designtidspunktet. r med stereotypen <<utility>> indeholder forretningslogik. Alle andre klasser er transiente Frontend Frontend laget har ansvaret for rendering og styring af web-brugergrænsefladen, og indeholder kontroller og hjælpeklasser til formålet. Desuden har frontend laget ansvar for webservices, som udstilles til interne og eksterne klienter. Pakker Pakke UI Service Har ansvaret for sider, sideskabeloner, kontroller, og understøttende funktionalitet til rendering af web-brugergrænsefladen. Har ansvaret for webservices, som udstilles til interne og eksterne klienter Backend Backend laget har ansvaret for forretningslogikken og indeholder domæne-entiteterne, som udgør den logiske datamodel, samt manager klasser som indeholder forretningslogikken. Backend laget er inddelt i følgende områder: Pakker Pakke Abonnement Apotek Indkøbskurv Kunde Lægemiddel Ordre Har ansvaret for klasser til håndtering af medicinabonnementer. Har ansvaret for klasser til håndtering af apoteksoplysninger fra medlemsnettet. Har ansvaret for håndtering af indkøbskurve. Har ansvaret for håndtering af kundedata, herunder stamdata og profiloplysninger. Har ansvaret for håndtering af lægemidler i varekataloget, herunder lægemiddelsubstitutioner og interaktioner. Har ansvaret for håndtering af ordre. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 20 af 53

21 Pakke Recept Varekatalog Har ansvaret for håndtering af elektroniske og fysiske recepter. Har ansvaret for håndtering af varekataloget og apotekernes sortimenter og prislister. «utility» KundeManager +CreateKunde(in Kunde) : Kunde +GetKundeByPID(in OcesPID) : Kunde +GetKunde(in KundeId) : Kunde +UpdateKunde(in Kunde : Kunde) : Kunde +DeleteKunde(in KundeId) +SetKundeInteresseområder(in OmrådeIds) +SetKundeStatus(in KundeId, in Status : KundeStatus) +GetVareFavoritliste(in KundeId) +AddSkjultVare(in Vare : Variant) +RemoveSkjultVare(in Vare : Variant) : bool +CreateIndkøbskurv() : Indkøbskurv +CreateIndkøbskurv(in KundeId) : Indkøbskurv +NotificerKunde(in KundeId, in Besked) +GetAlleInteresseOmråder() : Interesseområde[] +GetTeasers(in KundeId) «utility» AbonnementManager +CreateAbonnement() +GetAbonnement() +UpdateAbonnement(in Abonnement : Abonnement) +DeleteAbonnement(in AbonnementId) «utility»apotekmanager +SearchApotek(in Søgeudtryk) : SøgeResultat<Apotek> +GetApotekByNr(in ApotekNr) : Apotek +GetStamkunder(in ApotekId) : Kunde[] «utility» ReceptManager +GetOrdination(in OrdinationId) : Ordination +GetRecept(in ReceptId) : Recept +GetRecepterByCpr(in Cpr) : Recept[] +CreateFysiskOrdination(in Ordination : FysiskOrdination) : FysiskOrdination «utility» KatalogManager +SearchSortimentVarer(in ApotekId, in Søgeudtryk) : SøgeResultat<VareFamilie> +GetRodKategorier(in ApotekId) : Kategori[] +GetKategori(in KategoriId) : Kategori +GetVareFamilie(in VareFamilieId) : VareFamilie +GetVariant(in Varenummer) : Variant +GetInteraktioner(in drugids : string[]) : Interaktion[] «utility» OrdreManager +CreateOrdre(in Indkøbskurv : Indkøbskurv) : Ordre +GetOrdre(in OrdreId) : Ordre +AnnullerOrdre(in OrdreId) +SetOrdreStatus(in OrdreId, in Status : OrdreStatus) «utility» BatchManager +ValiderReceptAbonnementer() +SendOrdrerFraAbonnementer() +ImporterLMSTakst() +ImporterGrossistKatalog() +ImporterInteraktionsdatabase() Figur 7: Backend lag - Manager klasser r Fil:.doc Version 1.0 Udskrevet: :32:00 Side 21 af 53

22 AbonnementManager ApotekManager BatchManager KatalogManager KundeManager OrdreManager ReceptManager lig for tilgang til medicin-abonnementer. lig for tilgang til apotekstamdata. Har ansvaret for funktionalitet knyttet til batch-kørsler, herunder batch-opdatering af varekatalog, interaktionsdatabase og behandling af abonnementer. lig for tilgang til varekataloget. lig for tilgang til kunder. lig for tilgang til ordrer. lig for tilgang til elektroniske og fysiske recepter Abonnement Fil:.doc Version 1.0 Udskrevet: :32:00 Side 22 af 53

23 Abonnement Kunde::Kunde 1 +Oprettelsesdato +Start +Slut +Frekvens +Status : AbonnementStatus +Betalingsmetode : Betalingsmetode +Leveringsmetode : Leveringsmetode +NæsteUdlevering +NæsteStart +AntalUdleveringerForetaget 1 Apotek::Apotek +OpretOrdre() +TilføjLinje() 1 AbonnementLinje +Antal +Slet() +Opdater() 1 Varekatalog::Variant Recept::Ordination «enumeration» Ordre::Betalingsmetode +Kontant +VisaDankort +BetalingsService «enumeration» Ordre::Leveringsmetode +Afhentning +Post +Bud «enumeration» AbonnementStatus +Aktivt +AfventerGodkendelse +OrdinationUdløbet +Afsluttet Figur 8: Abonnement r Abonnement AbonnementLinje Repræsenterer et medicinabonnement og har ansvar for tilføjelse af abonnementlinjer og oprettelse af ordre. Repræsenterer en vare som abonneres på. Datatyper AbonnementStatus Lister de mulige stati for et abonnement. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 23 af 53

24 Apotek +Filialer 1 Apotek +ApotekNr +Porto +Udbringning : bool +UdbringningBeskrivelse +Vagtapotek : bool +MerchantID Udleveringssteder ApotekStamdata +Navn +Kommune +Telefon +Fax + +HjemmesideURL +KrakKortURL +Adresselinie1 +Adresselinie2 +Postnummer +By 0..1 ApotekUdleveringssted +Dækning Postnummer +Postnummer Apoteksydelse +Betegnelse +Kategori 0..1 Åbningstid +Ugedag +Fra +Til Figur 9: Apotek r Apotek ApotekStamdata Apoteksydelse ApotekUdleveringssted Postnummer Åbningstid Repræsenterer et apotek (inkl. filialer), med stamdata (ApotekStamdata) og udleveringssteder (ApotekUdleveringssted). Repræsenterer stamdata for enten et apotek eller et udleveringssted. Repræsenterer en apoteksydelse, e.g. "Tjek på inhalation" eller "Online rådgivning". Repræsenterer et udleveringssted knyttet til et apotek. Repræsenterer et dansk postnummer. Repæsenterer åbningstiden for en ugedag Indkøbskurv Fil:.doc Version 1.0 Udskrevet: :32:00 Side 24 af 53

25 Indkøbskurv Kunde TilføjVare() +OpretOrdre() +BeregnPris() +Nulstil() +FlytTilApotekRapport() +FlytTilApotek() 1 Apotek::Apotek 1 Indkøbsvare +Antal +Navn +Pris +FjernFraKurv() +Opdater() 1 Varekatalog::Variant Figur 10: Indkøbskurv r Indkøbskurv Indkøbsvare Håndterer en indkøbskurv, flytning mellem apoteker, og oprettelse af ordre. Håndterer en vare anbragt i en indkøbskurv Kunde Fil:.doc Version 1.0 Udskrevet: :32:00 Side 25 af 53

26 +Stamapotek Kunde +OcesPID +Cpr +Status : KundeStatus +SidsteLogin +Leveringsmetode : Leveringsmetode +Betalingsmetode : Betalingsmetode +Samtykkeerklæringsdato +Oprettelsesdato +ModtagHTML bool +GivSMSBesked : bool +TilladBrugerundersøgelser : bool +SetStatus() +AddSkjultFavoritvare() +SetInteresseområder() +GetBeskeder() +GetVareFavoritliste() Interesseområde +Navn +Kategori ForetrukketUdleveringssted SkjulteFavoritvarer 0..1 Abonnement::Abonnement 0..1 Recept::Recept Ordre::Ordre Varekatalog::Vare Apotek::Apotek ApotekUdleveringssted +Udleveringssteder 1 KundeStamdata +Fornavn +Efternavn +Telefon +Mobiltelefon + +MedlemAfDanmark Leveringsadresse 1 +Hjemmeadresse 1 Adresse +Navn +Adresselinje1 +Adresselinje2 +Postnummer +By +Land «enumeration» KundeStatus +Aktiv +Spærret +TilSletning «enumeration» Ordre::Betalingsmetode +Kontant +VisaDankort +Betalingsservice «enumeration» Ordre::Leveringsmetode +Afhentning +Post +Bud Figur 11: Kunde r Adresse Interesseområde Kunde KundeStamdata Håndterer generelle adresseoplysninger til brug for kundestamdata. Repræsenterer et kunde-interesseområde. Interesseområder persisteres og administreres af CMS-platformen. Kunde-klassen har ansvar for oplysninger om registrerede kunder. Kundeoplysninger som er fælles for registrerede og engangs-kunder håndteres af KundeStamdata klassen. Håndterer generelle kundestamdata til brug for registrerede kunder Fil:.doc Version 1.0 Udskrevet: :32:00 Side 26 af 53

27 og ordrer. Datatyper KundeStatus Lister de mulige stati for en kunde Lægemiddel Fil:.doc Version 1.0 Udskrevet: :32:00 Side 27 af 53

28 Varekatalog::VareFamilie LægemiddelFamilie +SpecNummer +AlfabetiskSekvensplads LægemiddelPakning 1.. Varekatalog::Vare +Drugid +ATC +Opbevaring : Opbevaringsbetingelse +Udlevering : Udleveringsbestemmelse +Pakningsstørrelse +PakningsstørrelseEnhed +PakningsstørrelseBeskrivelse +AlfabetSekvensnummer 1 Lægemiddelform +Betegnelse +GetSubstitutioner() +GetInteraktioner() 1 1 «enumeration» KliniskBetydning +Udtalt +Moderat +Ringe +Mulig +Ingen +Uafklaret Interaktion +KliniskBetydning : KliniskBetydning +Rekommandation +TekstBorger 1 Substitutionsgruppe «enumeration» Udleveringsbestemmelse «enumeration» Opbevaringsbetingelse Figur 12: Lægemiddel r Interaktion Repræsenterer en interaktion mellem stoffer i to lægemiddelpakninger. Dannes på basis af LMS Takst (Medicinpriser) og Interaktionsdatabasen, som sammenkædes via LMS30.Substansgruppe=IDBStoffer.Navn LægemiddelFamilie Repræsenterer en lægemiddel produktfamilie (e.g. "Aspirin" eller "Panodil"). Fil:.doc Version 1.0 Udskrevet: :32:00 Side 28 af 53

29 Lægemiddelform LægemiddelPakning Substitutionsgruppe Repræsenterer en lægemiddelform (e.g. "Tabletter", "Inhalator"). Repræsenterer en pakning af et lægemiddel, som identificeret i LMS02. LægemiddelPakning har endvidere ansvar for fremfinding af substitutioner (LMS04, LMS05) og interaktioner (LMS30, idbniveau3er, idbstoffer). Repræsenterer en substitutionsgruppe for lægemiddelpakninger. Datatyper KliniskBetydning Udleveringsbestemmelse Opbevaringsbetingelse Lister de mulige kliniske betydninger af interaktioner. Lister de mulige udleveringsbestemmelser for lægemiddelpakninger. Lister de mulige opbevaringsbestemmelser for en lægemiddelpakninger Ordre Fil:.doc Version 1.0 Udskrevet: :32:00 Side 29 af 53

30 1 +OpdateringAf Ordre Kunde::Kunde KundeStamdata OrdreId +Ordredato +Ordrestatus : Ordrestatus +AfventerKundendsGodkendelse : bool +EOrdrenummer +KundeOrdrenummer +Totallistepris +Fragtpris +Totalpris +KanAfvises : bool +Leveringsmetode : Leveringsmetode +Betalingsmetode : Betalingsmetode +DibsOrdrenummer +DibsTransaktionsId +DibsMerchantId +AutoriseretBeløb +HævetBeløb +KvitteringEkspedient +KvitteringUdleveringsnummer +KvitteringUdleveringstidspunkt +KvitteringSamletKundeandel +KvitteringCTRAnvendtSaldo +KvitteringCTRNyBeregnetSaldo +KvitteringCTRPeriodeUdløb +KvitteringDanmarkTilskudBerettigetDel +KvitteringDanmarkIkkeTilskudBerettigetDel +BeskedFraKunde +BeskedFraApotek +BeskedEHandel Apotek::Apotek Apotek::ApotekUdleveringssted Abonnement::Abonnement +Annuller() : bool +SætStatus() 1 Recept::Recept Ordrelinje +Linjenr : int +Antal : int +Varenavn +Substitution : SubstitutionType +ListeprisPerStk +TotalListepris +KvitteringTilskud +KvitteringKundeandel +KvitteringCTRbeløb +Slet() Recept::Ordination Vare «enumeration» Leveringsmetode +Afhentning +Post +Bud «enumeration» Betalingsmetode +Kontant +VisaDankort +Betalingsservice «enumeration» SubstitutionType +ApoteketSkalSubstituere +KundenHarValgtSubstitution +KundenHarFravalgtSubstitution +EjS «enumeration» Ordrestatus +Ny +UnderBehandling +Ekspederet +KlarTilAfhentning +Afsluttet +AnnulleretAfKunde +AnnulleretAfApotek Figur 13: Ordre r Fil:.doc Version 1.0 Udskrevet: :32:00 Side 30 af 53

31 Ordre Ordrelinje Repræsenterer en e-handelsordre. Repræsenterer en varelinje i en ordre. Datatyper Betalingsmetode Leveringsmetode Ordrestatus Lister de mulige betalingsmetoder for en ordre Lister de mulige leveringsmetoder for en ordre. Lister de mulige ordrestati Recept Har ansvaret for håndtering af elektroniske og fysiske recepter. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 31 af 53

32 Recept +ReceptID +Type : ReceptType 0..1 Kunde::Kunde 1 +ReserveretTil Apotek::Apotek 0..1 FysiskOrdination Ordination +OrdinationsID +Oprettelsesdato +Status : OrdinationStatus +AntalOrdineret +AntalUdleveret +Udleveringsinterval +Udleveringsintervalenhed +Doseringstekst +Doseringsperiode +DoseringsperiodeEnhed +Substitutionsbestemmelse +LokalStatus +HandelIkkeTilladt : bool +AnmodOmFrigivelse() Abonnement::Abonnement 1 Abonnement::AbonnementLinje 0..1 Varekatalog::Vare «enumeration» OrdinationStatus +Åben +Afsluttet +Annulleret +Kladde +Inaktiv +DelvistUdleveret +UnderBehandling +Ugyldig +WebEkspederet +OverførtTilDosiskort «enumeration» ReceptType +Elektronisk +Fysisk Figur 14: Recept r FysiskOrdination Ordination Recept Repræsenterer en ordination på en fysisk recept. Repræsenterer en elektronisk eller fysisk ordination. Elektroniske recepter hentes via Apotekssystemet mens fysiske recepter persisteres lokalt. Repræsenterer en elektronisk eller fysisk recept. Datatyper OrdinationStatus ReceptType Lister de mulige stati for en ordination. Lister de mulige recepttyper. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 32 af 53

33 Varekatalog Har ansvaret for håndtering af varekataloget og apotekernes sortimenter og prislister. VareKategori +Navn +Beskrivelse +KanAbonneres : bool +GetUnderkategorier(in ApotekId) +GetVarefamilier(in ApotekId) +Underkategorier VareFamilie +Navn +BeskrivelseKort +BeskrivelseDetaljeret +Klassifikation : VareKlassifikation +GrossistKategori +GrossistUnderkategori +GetVarianter(in ApotekId) Vare +Varenummer +Betegnelse +Apoteksforbeholdt : bool +Fastpris : decimal +BilledeLilleURL +BilledeStorURL +DetaljeBillede1URL +DetaljeBillede2URL +UdgåetDato +Repræsentant 1 1 SortimentVare +Pris : decimal +Lagerføring : Lagerføring +Restordre : bool 1 Apotek::Apotek +GetPrissammenligning() «enumeration» VareKlassifikation +LægemiddelRecept +LægemiddelHåndkøb +Mærkevare +SpecielVare «enumeration» Lagerføring +Lagerføres +Skaffevare Figur 15: Varekatalog Fil:.doc Version 1.0 Udskrevet: :32:00 Side 33 af 53

34 r VareKategori VareFamilie Repræsenterer en kategori i varekataloget. Repræsenterer en varefamilie i varekataloget. En varefamilie er en gruppering af ensartede varer under et varemærke (f.eks. Panodil familien som indeholder varianter med forskellige styrker og lægemiddelformer). Hver varefamilie har mindst én tilknyttet vare. Vare SortimentVare Repræsenterer en vare som kan lagerføres i et apotekssortiment og lægges i indkøbskurven. Repræsenterer en sortiment-vare for et givet apotek, dvs. en vare, som har pris, angivelse af lagerføring og lagerstatus. Datatyper Lagerføring VareKlassifikation Lister de mulige lagerføringstyper. Lister de faste vareklasser (til opfyldelse af lovmæssig adskillelse i præsentationen af indkøbskurv/ordre og til behandling af sortiment) Integration Integrationslaget har ansvaret for integrationer til Microsoft Commerce Server 2007, eksterne systemer (CMS, Apotekssystemer, Interaktionsdatabasen, DIBS, TDC OCES, SMS Gateway). Pakke Apotekssystem CMS Commerce Server DIBS SMSGateway TDC Har ansvaret for at understøtte integration til apotekssystemerne. Har ansvaret for at understøtte integration til CMS-platformen. Indeholder Microsoft Commerce Server 2007 API'et. Har ansvaret for at understøtte integration til DIBS. Har ansvaret for at understøtte integration til Mobitech SMS gateway. Har ansvaret for at understøtte integrationer TDC OCES. Eksterne systemer repræsenteres internt i systemet ved agent klasser, som faciliterer kommunikationen. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 34 af 53

35 «boundary» Apotekssystem::ApotekssystemAgent +HentOrdinationer() +FrigivOrdinationer() +SendOrdre() +GodkendOrdre() +AnnullerOrdre() «boundary» CMS::CMSAgent +GetLægemiddelInfoAnvendelse() +GetLægemiddelInfoKomplet() +SearchApotek() +GetApotek() +GetAlleInteresseområder() +GetBrugerInteresseområder() +SetBrugerInteresseområder() +GetNaturlægemiddel() +GetPillebillede() +GetTeasers() +GetUsermessages() «boundary» TDC::TdcOcesAgent +VerifyCprPid() «boundary» DIBS::DibsAgent +ClearAmount() +CancelTransaction() «boundary» SMSGateway::SMSGatewayAgent +SendMessage() Figur 16: Agent klasser fra Integration pakkerne Data Access Har ansvaret for persistering af data og indeholder Connection, Command og DataAdapterklasser. DataAdapter-klasser genereres systematisk for hver entitet og leverer type-specifikke DataSet klasser. et for mapningen af DataSet til domænet ligger hos domæneentiteterne i Backend laget Common Common-laget har ansvaret for understøttende og generisk funktionalitet, herunder logging og caching. Pakke Cache Log Utility Har ansvaret for at understøtte caching af objekter. Har ansvaret for logging. Har ansvaret for diverse fælles generisk funktionalitet, f.eks. til Fil:.doc Version 1.0 Udskrevet: :32:00 Side 35 af 53

36 Pakke formatering og parsing. 4.3 CMS-Platform CMS-platformen er baseret på Sitecore og er overdnet struktureret som beskrevet i nedenstående figur. Frontend Frontend-laget har ansvaret for at håndtere og vise web-brugergrænsefladen, hvortil Sitecores kontroller og hjælpeklasser blandt andet vil blive brugt. Frontend-laget står også for webservices som udstilles til brug af CommerceServer. Pakke ASP.NET/XSLT Har ansvaret for visning af alt indholdet på hjemmesiden. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 36 af 53

37 Pakke WebServices Har ansvaret for levering af data fra lokale databaser til CommerceServer. Backend Backenden har ansvaret for håndtering af forretningslogik samt editering af lokal sitecoredata. Backenden indeholder også en søgnings pakke der står for alt indexering og søgning i CMS-delen. Pakke Søgning E-Book Rådgivning Redaktionelt indhold Test/quiz/elearning Ekspertpanel Interessegrupper Mailing lists Brugerhåndtering Har ansvaret for søgning i lokale databaser og dermed også indexering af disse. Har ansvaret for redigering og håndtering af data til e-books/brochurer. Har ansvaret for håndtering af onlinerådgivning. Har ansvaret for opdatering/håndtering af redaktionelt indhold. Har ansvaret for opsætning og håndtering af Tests, quizes og e- learning. Har ansvaret for håndtering af spørgsmål og svar til ekspertpanelet. Har ansvaret for håndtering af interessegrupper. Har ansvaret for håndtering af mailing lists, det værende både vedligeholdelse og udsendelse. Har ansvaret for håndtering af brugere, det værende styre lokal data på brugeren som fx roller og interesse grupper. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 37 af 53

38 Database Database laget har ansvaret for databaser, inklusiv gemme og hente data fra/til disse. Pakke SitecoreDB Medicinhåndbogen Naturlægemidler og vitaminer/mineraler Apoteksinfo BrugerDB Indeholder E-Book, Rådgivning, Redaktionelt indhold, Test/quiz/e-learning, Ekspertpanelet, interessegrupper og Mailing lists. Lokal database der indeholder lægemiddeldata fra DLI s medicinhåndbog. Lokal database der indeholder naturlægemiddel- og vitamin- /mineraldata fra medlemsnettets database. Lokal database der indeholder apoteksinformationer fra medlemsnettets database. Har ansvaret for at gemme og hente brugerdata. Integration Integrations laget har ansvaret for at hente data fra eksterne services. Pakke DLI Medlemsnettet CommerceServer Har ansvaret for kommunikation med DLI s web services. Har ansvaret for importering af data eksporteret fra medlemsnettet. Har ansvaret for kommunikation med CommerceServer services Frontend En væsentlig del af arkitekturen i Sitecore består i at en præsentationsside på websitet har abstraktionslag med faste begreber. Dermed sikres ensartet og fleksibel transformation af data fra Sitecore og andre databaser. Der anvendes følgende begreber: Page o Region Block Til sammen danner de tre ovenstående et grid på siden hvor en block er mindste bestanddel. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 38 af 53

39 Element Hver block har en placeholder der bruges til at skyde et eller flere elementer ind Page En page er den logiske samler for en præsentationsside. Konkret er en page en.net WebForm, altså en fil. I Sitecore kaldes dette et layout. En page indeholder en placeholder til regions. Layoutet apo.basepage indeholder alene en Regions placeholder, hvortil de forskellige regioner tilføjes dynamisk i Sitecore: Region En region er den logiske samler for et afsnit af præsentationssiden. Konkret er en region en.net WebUserControl, altså en fil. I Sitecore kaldes dette et sublayout. En region indeholder en række blocks. I projektet indeholder en apo.basepage følgende regions : apo.basepage o o apo.headerregion apo.bodyregion Efter at indsættelse i Regions placeholderen ser siden altså således ud: Fil:.doc Version 1.0 Udskrevet: :32:00 Side 39 af 53

40 I projektet indeholder de to regions følgende blocks : apo.headerregion o LogoBlock o MainNavigationBlock o SearchBlock apo.bodyregion o ContextNavigationBlock o ContentBlock o SpotsBlock Med indsatte blocks ser de to regions således ud: Fil:.doc Version 1.0 Udskrevet: :32:00 Side 40 af 53

41 Block En block er xhtml markup på en region og udgøres af et xhtml div-tag med et id. Inde i dette div-tag er kun en placeholder hvortil elements knyttes i Sitecore. Blocks er dermed mindste bestanddel af det grid som udgør en præsentationsside. Hver block har sin egen placeholder som elements, hvormed man kan få de i projektet udviklede elements til at blive vist de rigtige steder på præsentationssiden. Fil:.doc Version 1.0 Udskrevet: :32:00 Side 41 af 53