Facit Tentamen 16/2 Informationsinfrastruktur Teoridel (30 p) 1) Svar (1) I det fall som det inte redan finns en installerad bas av användare gäller det att snabbt samla en första avgränsad användargrupp som har nytta av den nya delen av informationsinfrastrukturen, och att se till att den nya informationsinfrastrukturen är så enkel som möjlig. Det gäller också att de nya IT-komponenterna inte är för dyra att använda. Att implementera IT-komponenter som stödjer 1:M interaktion är att föredra framför M:M. Exempel: Vänd er till transportföretag, t.ex. SJ, Green Cargo. Försök att få dem att använda er gateway till att knyta samman fordonspassagerna med deras interna system. Utveckla inte mer funktionalitet i detta läge. (2) Den andra delprincipen bygger på att välja en understödjande infrastruktur (identitetshantering (t.ex. personnummer/samordningsnummer) och datatransportinfrastruktur (t.ex. SHS och webservices)) till den nya delen av e- infrastrukturen som den potentiella användargruppen redan använder. Om den nya applikationsinfrastrukturen designas så att den behöver en helt ny understödjande infrastruktur så kommer det att skapa barriärer i samband med utvecklingen. Utnyttja befintliga applikationsinfrastrukturer och standarder och utnyttja deras spridning. Exempel: Er gateway är baserad på web-services (SOAP) som är en erkänd och mycket spridd standard för datatransport och kryptering av data mellan system-tillsystem tjänster. Att utnyttja befintliga standarder för och identifierare som EVN och GIAI, utgör ett annat exempel på det. Ni utnyttjade också befintlig applikationsinfrastruktur genom att knyta samman EPCIS-meddelanden med en tjänst som levererade masterdata. (3) Den tredje delprincipen kan beskrivas som användare framför avancerad funktionalitet vilket bygger på tanken att när den första gruppen av användare har börjat använda informationsinfrastrukturen så gäller det att övertala även andra användare att ansluta sig. Den nya informationsinfrastrukturen är värdefull om den har många användare inte p.g.a. att den har avancerad funktionalitet. Det betyder att nya funktionalitet ska läggas till om det bara är absolut nödvändigt. Att inse vilken funktionalitet som verkligen behövs upptäcks också först när användarna börjar använda den nya IT-komponenten. Det är också viktigt att ta hand om användarnas idéer och behov genom att skapa gemensamma communities. Exempel: Utveckla inte mer funktionalitet i er gateway innan ni är säkra på att det verkligen behövs. Satsa istället resurser på marknadsföring och implementering av er gateway. Skapa en user community för att sprida information och få feed-back från befintliga användare.
2) Svar a) Skillnaden mellan en identifierare och en definite description är att man med identifieraren kan referera utan att beskriva, vilket man gör med en definite description. b) Problemet med att använda en definite description är att den blir instabil och lång. Ett annat problem är att risken ökar för att den inte räcker till för att referera till alla de objekt som det är tänkt att den ska referera till. 3) Svar a) Innebär system-till-system tjänster som skall kunna kombineras med varandra. SOA betyder också lösa kopplingar mellan olika applikationer och stödjande infrastruktur genom att: bindningen sker i samband med runtime informationsutbytet sker med hjälp av meddelanden det innebär bland annat att det blir möjligt att utbyta tjänster via det publika Internet (Web services) OBS! Web Services är en variant as SOA b) SOAP som är en internetstandard som erbjuder möjligheter att skicka XML-dokument mellan olika system och därmed erbjuder det all den information som är nödvändig för att systemen skall förstå hur XML-dokumenten skall tolkas. SHS (Spridnings- och Hämtningssystem) är ett koncept för standardiserat, säkert och pålitligt utbyte av information mellan offentliga organisationer i Sverige. REST/HTTP, som står för Representational State Transfer, är som bekant en arkitekturstil som beskriver hur du bygger tjänster som exponeras via URI:er, där du arbetar med HTTP-protokollets GET, PUT, POST och DELETE-verb för att hämta, skapa, uppdatera och radera data c) Asynkron kommunikation (strax-kommunikation) innebär att det program som frågar inte upprätthåller kontakt och väntar på det program som ska svara. Detta är användbart när man inte behöver ett omedelbart svar, utan det svarande programmet kan beta av en kö av anrop som levereras när de är klara. Detta kan ta minuter, timmar eller dagar. Synkron kommunikation (nu-kommunikation) innebär att det program som frågar upprätthåller kontakt och väntar på det program som ska svara. Detta är användbart när man behöver ett omedelbart svar, och man kräver sekundsnabba svar. 4) Svar a) Legala förutsättningar (Legal pre-conditions)
Detta är legala förutsättningar som reglerar hur data får lämnas ut och utbytas. Organisatoriska förutsättningar (Organizational pre-conditions) Detta är organisatoriska förutsättningar som behövs för att bedriva utveckling i nätverk. Ekonomiska förutsättningar (Economic pre-conditions) Detta är ekonomiska modeller som tar hänsyn till nätverkseffekter och inte motverkar vidareutveckling genom en snäv intra-organisatorisk kalkylmodell. Existerande e-infrastruktur (E-infrastructure pre-conditions) Detta är förutsättningar som ställs upp av den existerande e-infrastrukturen och kan delas in i tekniska, kontraktsmässiga och informations aspekter. De tekniska förutsättningarna handlar om hur e-infrastrukturen stödjer utvecklingen rent tekniskt och hur tillgänglig applikationsinfrastrukturen är. De kontraktsmässiga handlar t.ex. om vilka rättigheter man har att använda och integrera med andra IT-komponenter. Den informationsmässiga aspekten handlar t.ex. om tillgången på metadata. b) Det är viktigt att känna till dessa förutsättningar p.g.a. att de påverkar möjligheterna att utveckla nya komponenter. Om dessa förutsättningar motverkar eller befrämjar utvecklingen påverkar detta möjligheten att utveckla e-infrastrukturen. Man måste ha kompetens inom dessa olika områden för att kunna utveckla e-infrastrukturen. 5) Svar Det traditionella perspektivet bygger på följande förutsättningar och antaganden: IS är väl avgränsat och man tar inte hänsyn till den installerade basen av redan befintliga databaser och IS Det finns ett begränsat antal (kända) användare inom en organisation som utvecklaren (designern) kan interagera med för att fånga kraven på IS Interaktion med andra IS fokuseras inte Den som utvecklar IS (designern) har full kontroll över designprocessen (IS) betraktas som ett användarverktyg som ska lösa ett problem för en specifik organisation Problemet med ett sådant perspektiv på IT-utveckling är: att man inte tar hänsyn till den installerade basen. att man förbiser att den som utvecklar en IT-komponent har full inte kontroll över designprocessen och att det kan finnas flera designers att interaktionen mellan olika heterogena IT-komponenter inte fokuseras
Programmerings- och modelleringsdel (25 p) a) XElement HämtaBeslutFörLåneansökningar() { var lånedoc = HämtaLåneansökningar(); var svar = new XElement("SvarBeslutsunderlagFörLån", new XElement("Tid", DateTime.Now.ToString("dd/MM/yyyy HH:mm")), new XElement("Långivare", (string)lånedoc.element("långivare")), new XElement("Låneärenden", // Loopa igenom alla ansökningar from lånansökan in lånedoc.descendants("lånansökan") let pnr = (string)lånansökan.element("låntagare").element("personnummer") let lånsumma = (int)lånansökan.element("lån").element("belopp") // Gör en kreditupplysning av låntagaren let kreditupplysning = HämtaKreditUpplysning(pnr) let inkomst = (int)kreditupplysning.element("taxeringsuppgifter").element("sammanräknadinkomst") let betalningsanmärkning = (string)kreditupplysning.element("betalningsanmärkningar").element("betalningsanmärkningar") let harbetalningsanmärkningar = betalningsanmärkning == "Ja" let skulderkronofogden = (int)kreditupplysning.element("kronofogdeuppgifter").element("summaskuldsaldo") // Besluta om lånet ska beviljas eller ej let beslut = (skulderkronofogden <= 0 &&!harbetalningsanmärkningar && lånsumma <= inkomst)? "Bevilja" : "Bevilja ej" // Skapa XML select new XElement("Låneärende", new XElement("Id", Guid.NewGuid()), // Id för ärende new XElement("Lånansökan", new XElement("Id", (int)lånansökan.element("id")), new XElement("Personnummer", pnr)), new XElement("BeslutFörLåneansökan", new XElement("Beslut", beslut), new XElement("Beslutsunderlag", new XElement("Betalningsanmärkning", betalningsanmärkning), new XElement("SkuldKronofogden", skulderkronofogden), new XElement("MånadslönerLånetAvser", lånsumma / (inkomst / 12))))))); } return svar;
Exempel XML: <SvarBeslutsunderlagFörLån> <Tid>01-03-2012 14:10</Tid> <Långivare>Swedbank</Långivare> <Låneärenden> <Låneärende> <Id>a0dea952-fc23-4ca1-b8b1-ad4d168d843d</Id> <Lånansökan> <Id>1</Id> <Personnummer>860404-9999</Personnummer> </Lånansökan> <BeslutFörLåneansökan> <Beslut>Bevilja</Beslut> <Beslutsunderlag> <Betalningsanmärkning>Nej</Betalningsanmärkning> <SkuldKronofogden>0</SkuldKronofogden> <MånadslönerLånetAvser>8</MånadslönerLånetAvser> </Beslutsunderlag> </BeslutFörLåneansökan> </Låneärende> <Låneärende> <Id>77c59ee9-b079-442f-b3ae-d23be0a443b1</Id> <Lånansökan> <Id>2</Id> <Personnummer>860404-8888</Personnummer> </Lånansökan> <BeslutFörLåneansökan> <Beslut>Bevilja ej</beslut> <Beslutsunderlag> <Betalningsanmärkning>Ja</Betalningsanmärkning> <SkuldKronofogden>22555</SkuldKronofogden> <MånadslönerLånetAvser>3</MånadslönerLånetAvser> </Beslutsunderlag> </BeslutFörLåneansökan> </Låneärende> </Låneärenden> </SvarBeslutsunderlagFörLån>
c) Det finns tre tydligt identifierade objekt i meddelandet: Långivare (namn på bank), Låneansökan (identitet på låneansökan), och Låntagare (personnummer). Det finns även ett till tydligt objekt Låneärende som utgör den huvudsakliga strukturen i meddelandet. Man kan också betrakta beslutet som ett eget objekt men man kan även se det som ett attribut till ärendet.