Ladok3 Refaktorering - Ladok3

Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 1 (35)
Ladok3
Refaktorering av befintligt Ladok
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Björn Edlund, Mikael Berglund
Rapport
Version 1.0
2011-12-02
Sida: 2 (35)
Innehåll
1
Introduktion ...................................................................................................................... 4
1.1 Syfte .......................................................................................................................... 4
1.2 Introduktion till refaktorering ................................................................................... 4
1.3 Introduktion till dokumentet ..................................................................................... 5
1.4 Grundläggande antaganden ...................................................................................... 5
1.5 Öppna frågor ............................................................................................................. 6
1.6 Referenser ................................................................................................................. 6
1.7 Förkortningar ............................................................................................................ 6
2
Sammanfattning ................................................................................................................ 7
2.1 För- och nackdelar .................................................................................................... 7
3
Översikt av dagens Ladok ................................................................................................ 8
4
Refaktorering .................................................................................................................. 11
4.1 Målarkitektur .......................................................................................................... 11
4.2 Modularisering........................................................................................................ 17
4.3 Metodik................................................................................................................... 19
4.4 SOA och kärnladok................................................................................................. 20
4.5 Framtiden för Ladoks produkter ............................................................................. 21
4.6 Refaktorering av databas ........................................................................................ 22
5
Ladok3 krav .................................................................................................................... 24
5.1 Funktionella krav .................................................................................................... 24
5.2 Icke funktionella krav ............................................................................................. 30
5.3 Slutsatser ................................................................................................................. 31
6
Arbetsplan ....................................................................................................................... 32
7
Analys av effektmål......................................................................................................... 34
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 3 (35)
Utgåvehistorik för dokumentet
Utgåva
Datum
Kommentar
1.0
2011-08-08 Första publicerade version
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
1
Introduktion
1.1
Syfte
Version 1.0
2011-12-02
Sida: 4 (35)
Syftet med detta dokument är att utreda det lösningsförslag för Ladok3 som innebär att
bygga vidare på det existerande Ladoksystemet för att realisera de krav som finns för
Ladok3.
Det primära syftet med denna rapport är att kunna fungera som underlag för att välja
lösningsförslag för Ladok3.
1.2
Introduktion till refaktorering
Ordet refaktorering 1 avser normalt att ett system renoveras utan att funktionaliteten
förändras. Genom att systematiskt förändra Ladok ur ett tekniskt och funktionellt
perspektiv kan Ladok3 realiseras.
Den första stora fördelen med refaktorering jämfört med ett nybygge är att risken blir
mycket mindre. Systemet kan förändras gradvis och alltid vara operativt. Det är dock
viktigt att målmedvetna och kraftfulla åtgärder vidtas för att skapa ett system som kan
leva många år till. Kända svagheter med dagens arkitektur bör adresseras under
utvecklingstiden.
Den andra stora fördelen är att en refaktorering kommer kontinuerligt att leverera
affärsnytta samtidigt som tekniska förbättringar genomförs. Jämfört med en introduktion
av ett helt nytt system där affärsnyttan kan ta tid att få på plats, speciellt med tanke på att
ett så omfattande system som Ladok måste byggas upp från grunden innan nya funktioner
tas i drift. Ladok3 som projekt kan också avbrytas utan att någon investering går förlorad.
Den tredje stora fördelen med en refaktorering är att Ladok har en existerande komplett
kravbild som täcker in alla detaljer som är nödvändiga för ett användbart system.
Gissningsvis kräver ett nybyggnadsspår åtskilliga timmar av kravarbete för att detaljera
de framtagna kraven till det som krävs för ett färdigt system.
En refaktorering skulle givetvis också innebära en del risker. En risk skulle vara att de
nödvändiga förbättringarna inte skulle genomföras i någon större omfattning. Detta är
något som lätt kan bli fallet eftersom refaktoreringsarbete ofta prioriteras ned till förmån
för funktionella förändringar.
En liknande process används i förvaltningen av Norges motsvarighet till Ladok, Felles
Studentsystem (FS).
1
Ordet finns inte i SAOL men används frekvent i systemutvecklingssammanhang. När det gäller
huruvida man ska använda order refaktorering eller refaktorisering så används båda
varianterna. Detta dokument har valt den förstnämnda varianten.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 5 (35)
Det kan vara värt att notera att refaktorering och förändring av funktionalitet kommer att
hanteras parallellt ur ett utvecklingsperspektiv, men det är hanterbart om vägen stakats ut
på ett bra sätt.
1.3
Introduktion till dokumentet
Detta dokument är uppdelat i följande delar:
1. Kapitlet Översikt av dagens Ladok ger en kort översikt av dagens Ladok.
2. Kapitlet Refaktorering beskriver nödvändiga renoveringar av systemet för att
skapa en bra grund att bygga vidare på.
3. Kapitlet Ladok3 krav analyserar den funktionalitet som Ladok3 kräver av ett
framtida system och hur den skulle kunna föras in i Ladok.
4. Kapitlet Arbetsplan beskriver hur arbetet skall läggas upp.
5. Kapitlet Analys av effektmål utvärderar lösningen mot effektmålen.
6. Kapitlet Avslutande diskussion innehåller en del avslutande reflektioner om
refaktoreringsspåret.
1.4
Grundläggande antaganden
För att begränsa omfattningen av denna rapport har vissa antaganden gjorts, dessa
beskrivs nedan.
Nouveau-klienten byts ut mot en Java-baserad lösning som bygger vidare på Ladok
på Webb, men med ett komplett användargränssnitt. För ett system som Ladok är
det viktigt att använda allmänt använda tekniker som ligger i ”mittfåran”. Allmänt
använda tekniker gör också att uppdateringar/förbättringar kommer fram snabbt.
Detta ligger i linje med effektmålet ”Ladok3 ska byggas med teknik som bedöms ha
mycket lång återstående livslängd och som ger låga risker för inlåsning”.
Refaktoreringen skall utföras på ett iterativt sätt. Med detta menas att förändringen
av Ladok skall ske gradvis. Ladok skall alltid vara operativt, dvs. det får inte blir
frågan om ett ”big-bang” utvecklingssteg som lämnar Ladok ur funktion långa
perioder. Detta är centralt eftersom det är den kanske största fördelen med
refaktorering jämfört med ett nybygge. Riskerna med projektet kan hållas på en
lägre nivå
Behålla en databas per högskola. Att förändra dagens Ladok till att ha en gemensam
databas för alla högskolor skulle förmodligen vara mycket arbetsamt. Ett stort
problem skulle vara att migrera data från existerande lokala installationer till det
nya nationella systemet. Detta är förstås ett stort problem som även ett nybygge
skulle behöva hantera, men en av huvudpoängerna med en refaktorering är just att
minska riskerna genom att gå försiktigt fram och därför antas systemet även
fortsättningsvis vara lokalt för denna lösning. Dock är det realistiskt och
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 6 (35)
förmodligen en bra idé att kombinera dessa lokala databaser med en gemensam för
visst data. Detta diskuteras mer i detalj i kapitel Icke funktionella krav.
1.5
Öppna frågor
1.6
Referenser
Referens
1.
2.
3.
4.
5.
6.
7.
8.
Beteckning
Ladok3 Tjänstebaserad arkitektur, SOA_01.pdf
Övergripande kravspecifikation Process 8 v0.5.docx
Projektdirektiv Ladok3 – Lösningsdelprojekt
Ladok 3 Arkitektur
Förstudie Trafla förbättringar
Krav-dokument T-0001-C Icke funktionella krav
Förslag funktionalitet L3_Strategiska_frågor
PM Uppföljning av effektmål
1.6.1 Övrig referenslitteratur
Referens
I.
II.
1.7
Beteckning
Patterns of Enterprise Application Architecture, Martin Fowler. 9780321127426.
Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric
Evans. 978-0321125217.
Förkortningar
Förkortning
DAO
DDD
VO
Beskrivning
Data Access Object
Domain Driven Design
Value Object, Värdeobjekt
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
2
Version 1.0
2011-12-02
Sida: 7 (35)
Sammanfattning
En refaktorering är möjlig av dagens Ladok för att möta de verksamhets- och
affärsmässiga krav som Ladok3 har, förutsatt att Ladok förblir en lokal installation. En
refaktorering är fördelaktig när det gäller att minska risken med projektet samt att på
enklaste möjliga sätt lösa problemet med att migrera data och kringliggande system. De
förändringar som föreslås för Ladok3 kan också göras inom ramen för dagens
förvaltning, vilket ger förutsättningar för en stabil övergång.
2.1
För- och nackdelar
Fördelar
•
•
•
•
•
Risken med att projektet skulle totalhaverera är i stort sett obefintlig eftersom
systemet skulle förändras gradvis och alltid vara operativt.
En refaktorering skulle kontinuerligt komma att leverera affärsnytta samtidigt
som tekniska förbättringar genomförs. Jämfört med en introduktion av ett helt
nytt system där affärsnyttan kan ta tid att få på plats, speciellt med tanke på att ett
så omfattande system som Ladok måste byggas upp från grunden innan nya
funktioner tas i drift.
Ladok har en existerande komplett kravbild som täcker in alla detaljer som är
nödvändiga för ett användbart system. Gissningsvis kräver ett nybyggnadsspår
åtskilliga timmar av kravarbete för att detaljera de framtagna kraven till det som
krävs för ett färdigt system.
En fördel av mindre slag som kan vara väldigt viktig för vissa högskolor är att de
LPW tjänster där högskolan implementerat egna användargränssnitt kommer att
kunna behållas.
Skillnaderna mellan dagens Ladok och Ladok3 är förhållandevis små ur ett
affärsmässigt perspektiv vilket gör en refaktorering till ett mindre åtagande
jämfört med att bygga ett helt nytt system.
Nackdelar
•
•
Tekniska förbättringar åsidosätts till förmån för funktionella förändringar, vilket
gör att man kanske aldrig når målet.
Ett nationellt system är svårt att uppnå via refaktorering.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
3
Version 1.0
2011-12-02
Sida: 8 (35)
Översikt av dagens Ladok
Syftet med detta dokument är inte att ge en detaljerad beskrivning hur dagens
Ladoksystem är uppbyggt. De flesta tänkta läsare är förmodligen redan insatta i Ladok,
om inte finns det ett flertal andra dokument som beskriver Ladok i detalj. För att skapa en
kontext för arbetet inleds dokumentet med en kort beskrivning av Ladoksystemets olika
delar.
Delarna i dagens Ladok visas i figuren nedan:
Figur 1: Översikt dagens Ladok
Systemdelarna i figuren beskrivs nedan.
3.1.1 Ladokdatabasen
Den mest centrala delen i Ladok. I princip samtliga produkter använder Ladokdatabasen.
3.1.2 Nouveau
Används som gränssnitt för experanvändare. Nouveau är implementerad i 4GL-språket
Uniface. Varje användare har en egen installation av Nouveau på sin arbetsstation.
Majoriteten av Ladoks funktionalitet, både avseende gränssnitt och affärslogik, ligger här.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 9 (35)
3.1.3 LPW
Ladok På Web exponerar delar av Ladoksystemet som SOAP tjänster. Främst används
LPW för att skapa studentjänster, men vissa tjänster finns även för lärare och
administratörer. Affärslogiken för LPW exekverar på en JBoss applikationsserver. SOAP
lagret exekverar i en Tomcat Servlet container och kommunicerar med
applikationsservern via Java RMI. Ladok levererar även färdiga användargränssnitt för
dessa tjänster, så kallade portlets som exekverar i en webbportal.
3.1.4 Java Batch
Syftet med batcharna är att utföra större jobb i Ladok som t ex import av urvalsresultat
från NyA och export av statistiskt underlag till SCB. Funktioner finns för registervård
och administrativa sysslor som personnummerbyte. Beställningarna sker i Nouveau
genom skrivande till databasen som sedan batchramverket läser och startar batchen. Vid
avslutad körning meddelas resultatet vanligtvis per e-post.
3.1.5 LadokPing
Dagens Ladok har en lokal installation för varje högskola. Ibland har man behov att
sammanställa information från flera högskolor. Syftet med LadokPing är just att fråga
efter information från flera högskolor och sammanställa den informationen. Förfrågan
hanteras först av LPW som i sin tur kommunicerar med LadokPing som via RMI hämtar
information från andra högskolor, dvs Ping-installationen på en viss högskola skickar
meddelanden till Ping-installationer på andra högskolor för att sammanställa information.
3.1.6 Ladok Connector
Syftet med Ladok Connector är att kunna skicka meddelanden till olika intressenter om
förändringar i Ladok. Data förs över från Ladokdatabasen till en Ladok Connector
databas med hjälp av databas-triggrar. Meddelanden skickas via JMS (Java Messaging
Service) till en JMS server. T ex kan man tänka sig ett passerkortssystem som lyssnar på
meddelanden om registrerade studenter. Det har förekommit diskussioner om att byta ut
det RDF-baserade meddelandeformatet mot något enklare. Enligt den SOA-baserade
modell som Ladok3 skall använda sig av finns det ett behov av denna funktionalitet.
3.1.7 Trafla
Trafla står för Transaktionsloggning för Ladok och används för att spåra förändringar i
Ladok. Genom loggning skall det vara möjligt att följa vilken information som tillförts
eller ändrats i databasen. Det ska vara möjligt att se när det gjorts, vem som gjort det och
vad ändringen består i. Loggdatat lagras i en separat databas som brukar benämnas
Trafladatabasen. Det finns en klientdel som läser från Ladokdatabasen och för över data
till en serverdel som lagrar informationen i en separat trafladatabas. En förstudie [5] har
genomförts för att öka användandet av Trafla. Följande förbättringar diskuterades i
förstudien:
•
Ett webbaserat användargränssnitt för att kunna söka i Trafla samt studera larmlistor.
•
Förbättrad sökfunktionalitet.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Björn Edlund, Mikael Berglund
Rapport
Version 1.0
2011-12-02
Sida: 10 (35)
Införande av en regelmotor som granskar informationen som läggs in. Ett exempel på en regel
skulle kunna vara att ett betyg ändras i efterhand. Prenumeranter skulle bli informerade via mail
om en regel uppfylls.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Björn Edlund, Mikael Berglund
4
Refaktorering
4.1
Målarkitektur
Rapport
Version 1.0
2011-12-02
Sida: 11 (35)
I Ladok så finns det stora mängder affärslogik skriven i 4GL språket Uniface.
Antagandet är, av redan nämnda skäl, att funktionalitet skriven i Uniface ska bytas ut mot
Javakod. Idag är mängden gemensam kod mellan Ladoks produkter begränsad. Det finns
arkitekturella anledningar till detta som dokumentet kommer att gå in på mer senare. Ett
krav som detta dokument ställer på ett framtida Ladok är att gemensam kod måste finns i
större omfattning än idag. Detta blir givetvis än mer viktigt när den stora mängden
affärslogik som finns i Uniface ska transformeras till Java. Att skapa en sådan arkitektur
från en befintlig är en utmaning.
Domän-driven design (DDD) är en metodik/arkitektur som effektivt undviker funktionell
duplicering. Detta beror på DDD lägger fokus på att funktionalitet skall implementeras i
domänentiteter. En domänentitet är ett begrepp som finns inom en domän, i
studiedokumentationsdomänen är kurs ett exempel. DDD förespråkar att använda en så
kallad domänmodell. Definitionen av vad en domänmodell är kan variera, men i detta
dokument avses följande:
Domänmodell: En objektorienterad modell som visar relationerna mellan
domänentiteteter. En domänentitet motsvarar ett begrepp som har en mening ur
verksamhetsperspektiv. Det primära syftet med en domänmodell är att visa det centrala
begreppen inom en domän och fungera som stöd för att kunna specificera vad systemet
gör.Ibland brukar en sådan modell benämnas informationmodell .
Normalt används begreppet domänmodell i detta dokument, men i samband med Ladok3
krav används oftast benämningen informationsmodell eftersom det begreppet används i
verksamhetsprojektet. Definitionen ovan innebär att rena implementationsklasser inte hör
hemma i domänmodellen. Av definitionen att döma har domänmodellen inget med
implementationen att göra, men ändå kommer dokumentet på många ställen prata om att
föra in en ett domänmodellstänk i koden, vad menas med detta? Jo, detta ska ses som att
klassmodellen i implementationen är baserad på en objektorienterad domänmodell. De
klasser som man hittar i domänmodellen hittar man normalt också i Javakoden, men
utöver detta finns dessutom ett större antal rena implementationsklasser (dvs utan
verksamhetsanknytning) som inte har någon relevans i domänmodellen. Mycket av det
som beskrivs i DDD är egentligen inget nytt, utan i enlighet med klassisk
objektorienterad analys och design, men det har fått en renässans genom DDD. De
klasser som finns i domänmodellen benämns domänentiteter.
Exempel på domänentiteter i studiedokumentationsdomänen är kurs, examen och student.
Tanken är att domänentiteter skall innehålla funktionalitet. Eftersom dessa entiteter är de
gemensamma begrepp som hanteras av funktionerna som finns i Ladok är det logiskt att
detta angreppssätt effektivt reducerar funktionell duplicering. Strategin med
refaktoreringen är att först beskriva en tänkt DDD inspirerad målarkitektur och sedan
kolla på hur Ladok kan förändras i den riktningen. Det är också viktigt att poängtera att
syftet har inte varit att använda sig av samtliga koncept som finns i DDD. Figuren nedan
visar denna målarkitektur:
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 12 (35)
Figur 1: Målarkitektur
Målarkitekturen beskrivs nedan.
DDD förespråkar normalt tre lager, målarkitekturen följder den uppdelningen. Dessa
lager beskrivs nedan.
4.1.1.1 Domain layer
Innehåller all domänrelaterad kod. Detta är det som anses vara hjärtat i systemet, vilket är
naturligtmed tanke på det är domänfunktionaliteteten som är orsaken till att ett system
byggs. Funktionaliteten i detta lager har störst värde och måste hanteras med högsta
prioritet. Vad som är domän och inte är upp till varje system att definiera. I Ladoks fall är
den centrala domänen studiedokumentation. Domänlagret använder infrastrukturlagret
som implementerar tekniska tjänster av mer domänneutral karaktär.
En central princip i DDD är att domänlagret ska isoleras från vissa typer av
infrastrukturberoenden. Det innebär att domänlagret skall välja infrastrukturberoenden
med omsorg.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Björn Edlund, Mikael Berglund
Rapport
Version 1.0
2011-12-02
Sida: 13 (35)
Ett genomgående tema i utvecklingen av affärssystem är att domänfunktionalitetetn
normalt är mer långlivad än de olika ramverk som är populära för tillfället. Lyckas man
minimera beroenden mot ramverk i domänlagret underlättar det förstås mycket om man
vill byta ramverk. En annat positiv konsekvens är att domänlagret blir renare och därför
enklare beroende på att funktioner som dessa ramverk normalt hanterar, t ex transaktioner
och säkerhet, inte kommer att hanteras i domänlagret. En strävan är att domänlagret bara
ska innehålla så kallade POJOs (Plain Old Java Objects).
4.1.1.2 Infrastructure layer
I ett system finns det en hel del funktionalitet som kan betraktas som stödfunktionalitet
till övrig kod. Det är funktionalitet som har ingen eller svag koppling till någon domän.
Den typen av koden vill man inte ha i domänlagret. Den stora mängen sådan
funktionalitet ligger normalt i system och tredjepartsbibliotek, dock brukar det i stora
system med tiden bli en del egenproducerad kod också. Exempel på funktionalitet:
• Loggning
• Autentisering
• Cache-mekanismer
Ofta är det frågan om ”wrappers” mot tredjepartsbibliotek, t ex man kanske använder ett
extern loggbibliotek men skriver en tunn wrapper som hakar på strängen ”Ladok” på alla
loggutskrifter. Typiskt för funktionaliteteten i detta lager är att det inte krävs någon
domänkunskap för att kunna implementera den.
4.1.1.3 Application layer
Som tidigare nämnts är en central princip i DDD att isolera domänlagret från uppgifter
som inte har med domänen att göra. Kompletta användningsfall består normalt av
domänfunktionalitet plus en del annat som inte har något med domänen att göra.
Applikationslagret har till uppgift att ”sy ihop” färdiga användningsfall och ta hand om
funktionalitet som domänlagret inte bör ha. Exempel på funktionalitet som bär ligga i
applikationslagret är:
• Definiera och exportera SOAP eller REST gränssnitt. Dessa kräver mer
grovkorniga gränssnitt och är något domänlagret inte skall hantera.
• Autenticering. Koordineras av applikationslagret som normalt använder någon
funktion i infrastrukturlagret för själva autenticeringen.
• Transaktionshantering. Koordineras av applikationslagret. Använder dock
normalt funktionalitet i infrastrukturlagret för lågnivå aspekter av
transaktionshanteringen (tänk att applikationslagret bestämmer när en transaktion
skall skapas och committas men att den anropar någon modul i infrastrukturlagret
för att göra detta).
4.1.1.4 Persistance layer
Databasåtkomst skall döljas bakom ett databasinterface. Detta kallas DAO, Database
Access Object. Majoriteten dessa definieras i domänlagret, men det finns inget principellt
som hindrar att även infrastruktur och applikationslagret har behov av persistens.
Implementationen av DAO interface vill man ha tydligt separerade. Detta beroende på
att:
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 14 (35)
•
Samlar all SQL-relaterad kod på ett ställe. Förenklar om t ex DBA vill gå igenom
alla SQL-satser.
•
Förenklar om man vill skapa nya implementationer av DAO interfacen. Om man
t ex vill gå från en ren JDBC implementation till iBATIS är det bara att skapa ett
nytt persistenslager.
DAO interfacen ligger sålunda i det lager som har behovet medan implementationen av
DAO interfacen skall ligga i persistenslagret.
4.1.2 Jämförelse av dagens Ladok mot målarkitektur
Syftet med detta kapitel är en diskussion om hur dagens Ladok ser ut jämfört med den
målarkitektur som målats upp. Den diskussionen är nödvändig för att senare i dokumentet
kunna komma fram till en väg framåt.
Ladok består av ett antal produkter. Den gemensamma koden mellan dessa är begränsad.
Någon egentlig domänmodell existerar varken i krav eller i utvecklingsledet.
Ladokprodukterna är generellt implementerad enligt det design mönster som brukar
benämnas transaktionsskript (se transaction script i [I]). Det mönstret är också det som
historiskt huvudsakligen använts i stora affärssystem innan DDD slog igenom på bred
front. Först en kort beskrivning av vad transaktionsskriptmönstret innebär.
Figur 2: Transaktionsskriptarkitektur
Figuren visar ett antal funktioner vars gemensamma funktionalitet består i huvudsak av
DAO-klasser och tillhörande värdeobjekt (VO) som mappar mot de tabeller som finns i
databasen. Värdeobjekten kan t ex vara ett KursVO och saknar funktionalitet förutom
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Björn Edlund, Mikael Berglund
Rapport
Version 1.0
2011-12-02
Sida: 15 (35)
getters/setters av datat. Bilden ovan visar en extrem transaction script arkitektur. Tittar
man på Ladok Java produkterna så följs det mönstret i huvudsak, men det finns mer kod
än bara DAOs/VOs som är gemensam mellan funktioner inom framförallt en produkt.
Majoriteten av den gemensamma koden (borsett från DAOs/VOs) kan anses tillhöra
infrastrukturlagret i målarkitekturen. När det gäller generell domänrelaterad funktionalitet
som skulle tillhöra domain/common i referensarkitekturen så är det relativt begränsat.
Detta gäller inom en produkt men ännu mer mellan produkter. Det finns dock en del
funktionalitet relaterad till studieavgifter som delas mellan LPW och JavaBatch. Det
intressanta med detta är kanske inte den ganska begränsade mängd funktionalitet som
delas, utan snarare att infrastrukturen när det gäller CM och metodik för att kunna hantera
gemensam kod redan är på plats. Den gemensamma ytan är också uppdelad i ett
infrastruktur- och domänlager enligt den målarkitektur som tidigare beskrivits. Denna
gemensamma yta skulle vara platsen där en eventuell framtida domänmodell skulle ligga.
Det ska också sägas att den transaktionsskriptarkitektur som finns i Ladok är generellt
gjort på ett konsekvent sätt, så när det gäller hantverket uppfylls förväntningarna.
I en domänmodellsarkitektur har VOarna bytts ut mot en fullödig objektorienterad modell
med domänentiteter som har både relationer till andra objekt samt funktionalitet.
När det gäller domänmodell kontra transaktionsskript blir det lätt så att man får intrycket
att domänmodell löser alla problem. En domänmodell har högre potential, men den är
också en mer komplicerad arkitektur än transaktionsskript. Den stora fördelen med en
domänmodellsarkitektur är som tidigare beskrivits att förutsättningarna för att minimera
funktionell duplicering kraftigt förbättras. Dock ska man medveten om att det finns fällor
med en domänmodellsarkitektur. En sak som lätt kan hända är att man lägger
funktionalitet i entiteter som inte hör hemma där. Med en sådan utveckling kan man lätt
skapa en oreda som blir något mycket sämre än som någonsin skulle kunna skapas med
en transaktionsskriptarkitektur. Ett annat problem med domänmodeller som är viktigt att
känna till är det antimönster som brukar benämnas anemic domain model (”blodfattig”
domänmodell). Där baserar man sin design på en domänmodell och tittar man i koden så
finns domänentiteter och även relationer mellan dessa. Tittar man på koden i
domänentiteterna så hittar man dock ingen annan funktionalitet förutom getters/setters för
data den har. Med en sådan arkitektur har inte mycket förbättrats jämfört med en
transaktionskriptarkitektur, grundproblemet med funktionell duplicering finns kvar. Det
kan vara värt att notera att medan anemic domain model normalt benämns vara ett
antimönster, så är inte fallet detta med transaktionsskript som mera betraktas som ett lite
gammalt arkitekturmönster med vissa brister.
Ett medvetet arbete bör göras för att förändra Ladok mot en domänmodellsarkitektur.
Detta mönster har högre potential jämfört med transaktionsskript, men ställer också högre
krav.
Om man tittar på de klasser som ligger i VO paketet i figuren ovan så mappar de klasser
som finns där ganska väl (KursVO, ExamenVO etc.) mot de domänentiteteter som skulle
finnas i en domänmodell. Det går inte att endast tillföra funktionalitet till dessa för att
skapa en domänmodell. En central aspekt av en objektorienterad modell är relationerna
mellan objekt. Tittar man på värdeobjekten så hanterar de relationer enligt den princip
som en relationsdatamodell gör, nämligen en relation från ett värdeobjekt till ett annat
hanteras via en nyckel. I en klassdesign baserad på en domänmodell hanteras en relation
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 16 (35)
genom att medlemsvariabel har en referens till det refererade objektet. Det hela hade varit
enkelt om hela objektgrafen kunde hållas i minnet, men det är förstås helt orealistiskt.
Delar av objektgrafen måste läsas upp i minnet från databasen. Detta är en problematik
som ägnas mycket uppmärksamhet i DDD. Kortfattat kan sägas att lösningen går ut på att
att dela upp objektgrafen i så kallade ”units of work”, Det innebär att man identifierar ett
antal objekt som anses höra ihop och därför läses upp respektive sparas ned till databasen
som en enhet. Hanteringen av detta förenklas mycket genom användandet av ett OR
ramverk som Hibernate.
Ladok består av ett antal produkter som kan ses som grupperingar som byggs ihop till
något som deployas. Hur kommer då dessa produkter relateras till målarkitekturen?
Bilden nedan visar hur det är tänkt.
Figure 3: Målarkitektur och produkter
Den övre delen av bilden visar tre Ladokprodukter. Dessa är tre olika system. I denna bild
följer de DDD arkitekturen även internt. Detta kan ses som ett långsiktigt mål. Det
centrala i bilden är dock Java Common, som är den systemdel vilken innehåller
gemensam kod. Den har inget applikations eller presentationslager (observera att
generella UI komponenter hör till infrastrukturlagret) eftersom inga fullständiga
produkter/applikationer implementeras där. I Java Common finns ett domänlager och
infrastrukturlager som används av de olika produkterna. Det finns även ett persistenslager
som implementerar Java Commons DAO gränssnitt, men de används inte direkt av
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 17 (35)
produkterna. Just kvaliteten och omfattningen på Java Commons domänlager är helt
avgörande för att arkitekturen skall bli bra. Där kommer huvuddelen av domänmodellen
att befinnasig.
4.2
Modularisering
Den lagrade arkitektur som förslagits i dokumentet behöver kompletteras med ett
modultänk inom respektive lager. Syftet är att gruppera likartad funktionalitet och skapa
tydliga gränssnitt mellan modulerna. Principen gäller för alla lager men är allra viktigaste
för det gemensamma domänlagret. Detta illustreras nedan:
Figure 4: Modularisering
En modul innehåller klasser inom ett område, examenshantering skulle kunna vara ett
exempel på en modul. En modul i domänlagret kan typiskt innehålla ett antal
domänentitetsklasser plus några domänservicar inom området. Bilden visar också hur
databasen modulariserats. Det sistnämnda är förmodligen väldigt viktigt när det gäller
refaktoreringen av databasen. Tittar man lite mer noggrant på databasen så är det ganska
enkelt att hitta olika grupperingar, men detta finns inte beskrivet i dokumentform. Det
rimliga är att en kodmodul i det gemensamma domänlagret mappar mot en del av
databasen, nämligen en databasmodul. Det innebär att den förvaltargrupp
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 18 (35)
(verksamhetsexperter och utvecklare) som är ansvarig för examensmodulen också har ett
ansvar för hur motsvarande modul i databasen ser ut. Detta är ett annorlunda tänk jämfört
med idag där det finns en DBA som kan ses som ansvarig för hela databasmodellen.
DBA kommer givetvis även fortsättningsvis ha en viktig roll, men modelleringsfrågor
måste på ett annat sätt än idag vara ett gemensamt ansvar mellan verksamhetsexperter,
utvecklare och DBA. Det är väldigt centralt för att generell funktionalitet knuten till en
entitet överhuvudtaget ska upptäckas.
Tittar man på databasen idag ser man ganska enkelt olika grupperingar som skulle kunna
ses som en modul. Detta kan förstås göras på olika sätt, men ett sätt visas nedan. Detta
ska bara dock ses som ett exempel för att ge en känsla hur det skulle kunna se ut. Detta
måste också synkroniseras med de objektgrupper som verksamhetsprojektet tagit fram i
informationsmodellen.
Figur 5: Modulindelning
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Björn Edlund, Mikael Berglund
4.3
Rapport
Version 1.0
2011-12-02
Sida: 19 (35)
Metodik
När man pratar om en domänmodell och dagens Ladok är det nödvändigt att titta lite
närmare på den metodik som används idag. Detta påverkar i högsta grad hur arbetet med
en domänmodell skulle fungera. Det normala sättet en kravspecifikation för Ladok skrivs
på är att basera kraven i stor omfattning på relationsdatamodellen (dvs Ladokdatabasen).
Kraven är ofta detaljerade där kravspecifikatören anger tabeller och kolumner. En styrka
med medoden är att kravspecifikatörer utan insyn i koden kan specificera krav som sedan
utvecklare med mindre verksamhetskunskap utan problem kan implementera. Det finns
en stor kraft i att ha en modell som kravspecifikatörer, utvecklare och testare gemensamt
kan förstå.
Den modellen kan antingen vara en relationsdatamodell eller en objekorienterad
domänmodell. Skillnader mellan en relationsdatamodell och en objektorienterad modell
är ett klassiskt problem i mjukvaruutveckling vilket alla resurser som lagts ned i
begreppet ORM, object relational mapping, vittnar om. Att utförligt beskriva skillnader
mellan modellerna är utanför detta dokument, men ett exempel är t ex att
relationsdatamodellen inte har någon arvsrelation. Skillnaden hur associationer hanteras
har redan berörts.
Bygger man ett nytt system där man vill jobba med en domänmodell är det rimligen en
självklarhet att den primära modellen är just domänmodellen. Domänmodellen skulle då
vara den rådande i alla led (krav, utveckling och test). Den skulle givetvis i slutändan att
mappas till en relationsdatamodell, men det är mer något av en nödvändig biprodukt (ofta
genom att använda ett ORM ramverk som t ex Hibernate). När det gäller
refaktoreringsspåret är hanteringen inte lika självklar och en nyckelfråga. Det finns några
olika varianter.
1. Fortsätt att låta SQL modellen vara en allmänt rådande när det gäller krav och test.
Ett aktivt arbete för att bygga upp en domänmodell i utvecklarledet skulle införas för
att få entiteter att lägga funktionalitet i. Denna domänmodell skulle då byggas från
SQL modellen. Så det blir lite omvänt mot det arbetssätt som man egentligen skulle
vilja, men det får man leva med i när det gäller refaktorering. Det är dock inte frågan
om att skapa en fullständig domänmodell, utan en analys en dagens funktionalitet
skulle göras för att identifiera områden där det finns en omfattande funktionell
duplicering.
2. Skapa en fullständig domänmodell utifrån den existerande SQL modellen som sedan
kravsamordnare och kravspecifikatörer måste använda. Liknar alternativ 1 i den
meningen att en domänmodell skapas utifrån en existerande SQL modell. Kravet på
direkt skapa en fullständig domänmodell blir dock mycket större om det är tänkt att
krav/test också ska kommunicera via den modellen. Efter att ha skapat
domänmodellen skulle man då ha en domänmodell tom på funktionalitet (anemic
domain model), men tanken är att den med tiden skulle fyllas på med funktionaliet.
Det är dock svårt att se att detta skulle vara en bra väg. Först och främst skulle man
behöva lägga en massa tid på att skapa en fullständig domänmodell som efter den
skapats fortfarande inte skulle innehålla någon funktionalitet. Sedan skulle
övergången från relationsdatamodell till domänmodell skapa ett paradigmskifte i
kravledet. Vid ett nybygge är det ett paradigmskifte som skulle kännas rimligt men
det känns fel om refaktoreringsspåret väljs.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 20 (35)
Antagandet är att alternativ 1 väljs. I ett längre perspektiv kan detta säkert ändras.
4.4
SOA och kärnladok
Effektmålen [8] fokuserar mycket på tjänsteorienterad arkitektur. Detta avhandlas i detta
kapitel.
SOA (Service Oriented Architecture, tjänsteorienterad arkitektur) är en högnivå
arkitektur som definierar hur olika system kommunicerar med varandra. Rapporten [1]
ger en bra allmän beskrivning om SOA och Ladok. SOA definierar standardiserade
kommunikationsmekanismer som möjliggör kommunikation mellan olika system.
Definitionen vad SOA egentligen innebär varierar, men ofta lyfts just det här med lös
koppling fram och att användandet av web services som REST eller SOAP endast skall
ses som ett sätt att implementera SOA. När begreppet SOA används i detta dokument
avses dock att komponenter kommunicerar via REST/SOAP över HTTP. Ofta nämns
som sagt lös koppling (loose coupling) som argument för SOA. Definitionen av lös
koppling kan också variera, men ofta beskrivs det som att separera gränssnitt från
implementation. Detta är dock en central ide också med objektorienterad programmering,
så vad är då fördelarna med komponenter kommunicerar via REST/SOAP jämfört med
vanliga Java gränssnitt? För att svara på detta så måste man titta på ett mer konkret
exempel. Anta att vi har två mjukvarukomponenter enligt bilden nedan.
Figure 6: Kommunikation mellan två mjukvarukomponenter
Kommunikationen mellan dessa kan ske på ett antal olika sätt.
1.
Lokala anrop. Detta kräver att bägge komponenterna är implementerade i samma språk och att
de är driftsatta på samma server. Fördelarna är enkelhet i programmeringen och prestanda.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 21 (35)
2.
Fjärranrop via Java RMI. Kräver att komponenterna är implementerade i Java, skillnaden mot
1) är dock att komponenterna kan driftsättas på olika servrar.
3.
Fjärranrop via REST/SOAP. Hanterar flexibel driftsättning som för 2), men klarar dessutom
att komponenterna implementerats i olika språk. Nackdelen mot 2) är mer komplicerad
programmering och sämre prestanda (det finns ett exempel för LPW där gränssnittet för
uppföljningstjänsterna har ändrats från SOAP till RMI av prestandaskäl).
Oavsett vilket alternativ man väljer så kan modulariseringen mellan komponenterna vara
bra eller dålig, detta beror mer på den allmänna komponentdesignen. Ett sätt att hamna i
problem är att schablonmässigt alltid välja alternativ 3 ovan. Tittar man på t ex
LadokPing så används SOAP mellan presentationslagret och affärslogiken. Där vill man
förstås kunna driftsätta dessa på olika servrar, däremot har det aldrig funnits något behov
att implementera lagren i olika språk. Med tanke på att bägge lagren är implementerade i
Java hade förmodligen RMI varit ett bättre val. Den dag man sedan får behov av olika
programmeringsspråk är det inget större jobb att skapa en SOAP servicefasad. När det
gäller SOA och målarkitekturen så ligger exponerandet av REST/SOAP i
applikationslagret. Det innebär att domänlagret inte har något att göra med
kommunikationsmekanismer.
Det är rimligt att se framtida Ladok bestående av en kärna med funktionalitet som
levereras ut till driftcentralerna. Därutöver kan det finnas annan funktionalitet som ligger
utanför kärnan. Denna typ av funktionalitet kan t.ex. vara:
•
Högskolespecifik funktionalitet.
•
Funktionalitet som har mycket svaga kopplingar mot studiedokumentation men
ändå behöver information från Ladok, t ex ett passerkortsystem.
Ladok kan därför behöva exponera gränssnitt som andra system kan använda. När det
gäller funktionalitet som ligger utanför kärnan är det mycket troligt att dessa inte har
synkade leveranser med kärnan och dessutom är det svårt att veta vilket programspråk
som används. Därför är det motiverat att exponera sådana gränssnitt via SOA, dvs. som
REST eller SOAP. Däremot kan RMI ibland vara ett bra alternativ för kommunikation
mellan presentationslager och affärslogik i de fall där vi har kontroll över bägge lagren.
Nyckeln är att kommunikationsmekanismer måste avgöras från fall till fall, det finns
ingen schablonlösning. När det gäller kommunikation mot externa system som till
exempel NyA och CSN måste det finnas en långsiktig strävan att använda sig av web
service baserade protokoll istället för de filöverföringar som görs idag.
4.5
Framtiden för Ladoks produkter
Begreppet produkt är egentligen ganska vagt, men det används normalt för att beteckna
en mängd kod som byggs ihop. Uppdelningen har varit viktig eftersom den gemensamma
koden mellan produkterna varit liten. Men den nya målarkitekturen som fokuserar på
gemensam kod mellan dessa är inte uppdelningen inte längre lika central. Nedan följer en
lista på dagens produkter och huruvida de initialt kommer att finnas kvar eller inte.
•
Nouveau: Ersätts med Javabaserade webbtjänster.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
•
•
•
•
•
4.6
Version 1.0
2011-12-02
Sida: 22 (35)
JavaBatch: Finns kvar.
Kommentar: dock bör protokoll mot externa system (idag t ex CSN och SCB) i
framtiden styras mot att de läser information från Ladok via tjänstebaserade
protokoll istället för de filöverföringar som görs idag. Utformandet av dessa
protokoll ligger dock inte helt inom Ladoks kontroll.
LPW: Finns kvar.
LadokPing: Finns kvar.
Kommentar: kan eventuellt förenklas om alla databaser ligger hos samma
driftcentral inom samma “kluster”.
Ladok Connector: finns kvar, kommer dock förmodligen att förenklas.
Trafla: Finns kvar.
Refaktorering av databas
En central del av dagens Ladok är databasen. Den har varit i produktion sedan 80-talet
och vissa tekniska förbättringar kan göras. Dessa beskrivs nedan:
4.6.1 Dela upp databasen i flera databaser
Dagens Ladokdatabas består av 337 tabeller. Tittar man lite noggrannare på tabellerna så
består dessa av olika grupper:
1. Generella domänrelaterade tabeller, dvs. relaterade till studiedokumentation.
2. Produktspecifika tabeller. Det finns tabeller som är specifika för t ex LPW, Ping och
Javabatch.
3. Tekniska tabeller som inte är relaterade till studiedokumentation. Ett exempel är
ANV… tabeller som innehåller information om användare av systemet.
Det vore rimligt att separera dessa i olika databaser. Det primära syftet skulle vara att få
1) ovan mer överblickbar, dvs. att ha en databas som renodlat bara har domänrelaterade
tabeller.
4.6.2 Modularisering
Modularisering av både mjukvara och databas har redan berörts. Att ha en tydligt
dokumenterad modularisering är mycket viktig för förståelsen. En analys av dagens
databas visar på olika moduler, men de är dock inte dokumenterade på något bra sätt.
Detta är ett område där man med ganska små medel skulle kunna underlätta förståelsen
av databasen.
Kapitlet Modularisering berör också hur ansvaret över databasen skulle förändras.
4.6.3 Normalisering
Enligt dokumentationen skall databasen vara normaliserad till 3:e normalformen (3NF).
Det förekommer dock idag konstruktioner i databasen som gör att detta inte uppfylls.
Titta till exempel på tabellen LANTKURS som har kolumnerna villkor, villkor1 och
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Björn Edlund, Mikael Berglund
Rapport
Version 1.0
2011-12-02
Sida: 23 (35)
villkor2. Denna konstruktion fungerar inte om man behöver 4 villkor och detta problem
har faktiskt redan uppstått. Konstruktionen ovan uppfyller inte 1NF definitionen.
Normaliseringen av databasen bör ses igenom och åtgärdas.
4.6.4 Restriktioner (constraints)
Restriktioner är en mekanism som möjliggör att på databasnivå definiera regler för hur
datat lagras. Ett exempel är att en registrering endast kan skapas om den angivna kursen
redan finns. Dagens databas utnyttjar inte denna möjlighet fullt ut, utan det är helt upp till
mjukvaran att se till att data läggs in på ett korrekt sätt. I de fall där data skrivs in direkt
via SQL av användare är risken förstås ännu större att korrupt data läggs in. Idag finns det
en hel del kod som utför valideringar av data som inte skulle behövas om databasen redan
gjort detta. Det vore därför klokt att föra in fler restriktioner i databasen.
4.6.5 Specificerade typer
Det finns många exempel på typer i databasen som skulle kunna vara mer specificerade.
Det kan t ex, använda sig av typen DATE istället för STRING för datum eller att använda
BOOL istället för en sträng med J/N värden. Detta skulle minska risken för korrupt data,
förbättrad prestanda samt minskat användande av lagringsutrymme.
4.6.6 Blank underscore
Idag används något som kallas blank underscore i databasen. Detta beroende på att värdet
” _” används för att representera tomma värden. Denna lite udda konstruktion infördes en
gång i tiden beroende på att Uniface inte kunde hantera tomma nycklar.
4.6.7 Namngivning
Idag lämnar namngivning på tabeller och kolumner en del övrigt att önska beroende på en
gammal COBOL relaterad begränsning av namnlängd. COBOL finns inte kvar i systemet
och det vore rimligt att använda sig mer informativa namn, t ex
EXAMENSBENÄMNING istället för EXAMBEN.
4.6.8 Summering
Vid en första anblick så framstår Ladokdatabasen med sina 337 tabeller som komplex att
överblicka. Tittar man dock lite närmare så inser man att det är ganska lätt att identifiera
olika grupper av tabeller som skulle kunna betraktas som moduler. Genom att tydliggöra
en sådan modularisering och kombinera ansvar för en databasmodul tillsammans med
tillhörande kod skulle ansvaret för databasen inte längre ligga helt på DBA. Med ett
sådant arbetssätt skulle man förmodligen ganska snabbt och med relativt små medel
kunna städa upp databasen och införa de förbättringar som beskrivits i detta kapitel.
Verktyg finns för att löpande införa databasförändringar i befintliga Ladok.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
5
Version 1.0
2011-12-02
Sida: 24 (35)
Ladok3 krav
Detta kapitel går igenom hur kraven på Ladok3 relaterar till dagens Ladok.
5.1
Funktionella krav
Med funktionella krav avses verksamhetsrelaterade krav. Dessa specificeras i huvudsak
genom:
1. En informationsmodell. Ur detta dokuments perspektiv är detta samma sak som en
domänmodell. Notationen som valts är en notation framtagen av företaget IRM. När
det gäller informationsmodellering kan man grovt använda sig av ER (Entity
Relationsship) notation eller UML. ER notationen har sin bakgrund i
databasmodellering medan UML har sina rötter i mjukvarumodellering. IRM har som
sagt sin egen notation, den har dock mer likheter med ER än UML. I praktiken
behöver detta inte spela så stor roll, även IRM notationen stödjer till exempel
arvsrelationen.
2. Processdokument som med text beskriver systemets funktionalitet. De använder de
begrepp som informationsmodellen specificerat för att kunna beskriva
funktionaliteten på ett tydligt sätt.
Informationsmodell och processer diskuteras nedan.
5.1.1 Informationsmodell
När man studerar dagens Ladok och jämför med kraven är det viktigaste att studera hur
den nya informationsmodellen ser ut jämfört med dagens. Dagens Ladok har inte
informationsmodellen explicit beskriven i ett dokument utan man får jämföra med
databasmodellen. Informationsmodellen definierar ett systems begrepp och hur de
relaterar till varandra. Om den nya informationsmodellen är inkompatibel med dagens
Ladok innebär det att refaktoreringsalternativet kan bli alltför omfattande att genomföra.
Detta är mer centralt än att det finns processer som inte stämmer helt överens med dagens
Ladok.
Först några allmänna reflektioner:
•
Detaljnivån är i skrivande stund ganska låg i Ladok3s informationsmodell och kommer
förmodligen att detaljeras ytterligare när man börjar väva in mer funktionalitet. Det
existerande Ladoks informationsmodell är en fullständig modell med stöd för alla
specialfall, detta innebär att Ladoks informationsmodell är mer omfattande när det
gäller detaljer.
•
Ladok3s informationmodell spänner över stora områden, t ex antagning som hanteras
av NyA samt vissa områden som inte behöver systemstöd. Fokus när Ladok3 och
Ladok jämförts har varit de delar av informationsmodellen som behövs för de
prioriterade processerna som listas senare i kapitlet.
•
Ladok3s informationsmodell är inte en datamodell. Mellan dessa har man en mappning
som måste göras. En entitet i informationsmodellen kan till exempel brytas ned i flera
entiteter i datamodellen. Sen kan man också välja om en entitet i informationsmodellen
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 25 (35)
blir en kolumn eller en egen tabell.
De två ovanstående punkterna gör att jämförelsen måste göras på ganska hög nivå. Man får
se mer på om olika områden finns i modellerna. Slutsatsen blir att modellerna är
förhållandevis lika. Mycket av informationen är detsamma. Ett antal lite större skillnader är:
•
Vissa entiteter, som t ex Kurs, är knutna till en lärosätesentitet. Detta behövs för att
kunna hantera en gemensam databas. Detta finns inte i Ladok och eftersom
grundansatsen är att refaktoreringsspåret inte ska stödja en gemensam databas är det
inget att ta hänsyn till. Det skall också poängteras att det inte skulle vara en stor
förändring av Ladok rent schemamässigt att införa detta. Anledningen till att lokala
databaser behålls för refaktoreringsspåret beror mer på att komplexiteten att migrera
många existerande databaser till en.
•
Individuell studieplan finns inte i Ladok. Ett antal nya tabeller skulle behövas för detta.
•
En kurs består av moduler som i sin tur består av komponenter i Ladok3. Så är inte
fallet i Ladok där modul och komponentbegreppet saknas.
•
I Ladok3 modellen är en registrering knuten till ett utbildningstillfälle, så är inte fallet i
dagens Ladok där en registrering är knuten till en kurs.
•
Ett av målen med Ladok3 är en enhetlig hantering av olika utbildningsnivåer, detta är
inte riktigt fallet idag.
Dessa är de lite större förändringarna, givetvis finns det även andra förändringar av lite
mindre art som tas upp när processerna diskuteras nedan.
5.1.2 Processer
När det gäller processerna så finns det ett kapitel i processbeskrivningarna som beskriver
skillnaderna mot dagens system. Den totala mängden processer är omfattande, men [7]
innehåller en prioritering av processerna och indikationer på om de ska in som
systemstöd i Ladok 3. Nedan diskuteras de prioriterade processerna. Kapitlet i
processerna som beskriver skillnader mot dagens system har klippts in. Kommentar om
dessa ändringar samt estimat är inlagd under varje förändring. Estimatet måste förstås
anses som mycket grovt i detta läge. Skalan låg, medel och hög har använts. Ett
efterföljande + eller – har använts för att kunna ge lite ytterligare information om arbetets
omfattning.
Huvudprocess 8: Hantera studiedeltagande
Förändringar gentemot dagens system (texten inklippt från processerna i kursiv stil):
All registrering föregås av att det finns en antagning/motsvarande till aktuellt
utbildningstillfälle.
Kommentar: Är detta påstående korrekt, syftar man kanske på lokal efterantagning? Vad
händer med lokal efterantagning (SA02, S03)?
Estimat: oklart.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 26 (35)
All registrering skall i princip ske som självregistrering genom webblösningar, i vissa fall
efter kontakt med administratör. Självbetjäning även vid anmälan av avbrott och
studieuppehåll samt grupplacering.
Kommentar: Uppdaterade/nya LPW tjänster krävs för att kunna hantera anmälan av
avbrott och studieuppehåll. Inga förändringar av datamodell nödvändig.
Estimat: medel.
Ansökan om byte av program eller ämne på forskarnivå – självbetjäning.
Kommentar: Ny LPW tjänst.
Estimat: medel.
Enhetlig hantering i största möjliga mån av studenter på alla nivåer.
Kommentar: Lite större förändring som påverkar datamodellen. Till exempel finns idag
flera tabeller som hanterar registreringar. Viktig aspekt av refaktoreringen att se över
detta.
Estimat: medel+.
Individuell studieplan kan upprättas även för studenter inom grund- och avancerad
utbildning, såväl för programstudenter som för studenter på fristående kurser, i det förra
fallet med matchning mot utbildningsplan och i det senare fallet med matchning mot
examenskraven.
Systemstöd för hantering av individuella studieplaner. Uppgifter i individuella
studieplaner utgör underlag för registrering av doktorander.
Kommentar: Stöd för individuell studieplan finns inte alls i dagens Ladok. Kräver
förändringar i datamodell och kod.
Estimat: hög.
Större möjlighet att dokumentera individuella avvikelser såsom byte av kurstillfälle
(kurstakt, undervisningsform, kursort) samtidigt som historiken bevaras.
Kommentar: En utökning av dagens informationsmodell krävs för att kunna lagra
historik.
Estimat: låg.
Bättre kontroll översikt av var inom programmet en student befinner sig efter ett
studieuppehåll eller utlandsstudier. Studieuppehåll även på forskarnivå dokumenteras.
Kommentar: Logghistorik skulle kunna läggas till.
Estimat: medel.
Termin ersätts eller kompletteras i indatasammanhang med (studie)period.
Kommentar: Idag används terminbegreppet på många ställen i databasen där det skulle
vara bättre att kunna använda en mer detaljerad angivelse som period. T ex skulle man
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 27 (35)
kunna tänka sig att det skulle finnas 10 perioder på ett år. Skulle påverka datamodellen på
en rad ställen.
Estimat: hög.
Skilja mellan faktiska förändringar i en students studier och organisatoriska eller andra
”tekniska” förändringar, t.ex. i fråga om byte av ämne på forskarnivå.”Avbrott” skall
bara avse faktiska avbrott. Tidigt avbrott skall ev. betraktas som återbud. Orsakstyp för
avbrott dokumenteras och kan därmed följas upp.
Kommentar: Mindre förändringar. Relaterat till att dokumentera avvikelser.
Estimat: låg.
Olika typer av omregistrering införs, bl. a. för deltagande i undervisning, för självstudier
m.m. Studenten kan själv avgöra poängomfattning och tidsperiod för omregistrering men
bara för ej avklarad del av kurs. Omregistrering på annan studietakt och -form samt
annan ort (campus) blir möjlig.
Kommentar: Idag finns bara en typ av omregistrering.
Estimat: medel.
Bättre historik ger en mer korrekt bild av studentens utbildningsväg, t.ex. skall man
kunna se om en nyantagning avser byte från annan utbildning.
Kommentar: Relaterat till bättre kontroll på avbrottsorsaker. Man skulle t ex kunna tänka
sig att denna orsak skulle behöva sättas vid nyregistrering om existerande registrering
redan finns. Den enda som vet om det verkligen är ett byte är studenten (det kan också
vara frågan om parallelläsning).
Estimat: medel.
Markörer (”flaggor”) för studentens påbörjade terminer/kurser inom programmet/ämnet
införs. En enkel räknare ersätter begreppet kull/programtermin.
Kommentar: Mindre ändring.
Estimat: låg.
En räknare för varje påbörjad termin eller kurs samt en räknare för uppnådda poäng
inom programmet/ämnet på forskarnivå (delat med 30 hp).
Kommentar: Mindre ändring.
Estimat: låg.
Möjligt att ha en gemensam räknare för flera program/ämnen om så önskas.
Kommentar: Mindre ändring.
Estimat: låg
Antagning till senare del av program hanteras i NyA.
Kommentar: Helt OK bara någon gör ”jobbet”.
Estimat: låg
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Version 1.0
Rapport
Björn Edlund, Mikael Berglund
2011-12-02
Sida: 28 (35)
Huvudprocess 10: Betygssätta och offentliggöra resultat
Förändringar gentemot dagens system (texten inklippt från processerna i kursiv stil):
Komponentnivå ska kunna visas på underlag för grundnivå/avancerad nivå.
Kommentar: Idag har vi prov, praktik och labbar som delmoment. Att införa generell
hantering av komponenter skulle innebära en del jobb. Påverkar både datamodell och
kod.
Estimat: hög.
Gemensam hantering oavsett nivå men olika slags underlag för forskarnivå jämfört med
övriga nivåer.
Kommentar: Ett lite större arbete för att få dagens Ladok att uppfylla detta.
Estimat: hög.
Lärare ska själv kunna skapa underlagen.
Kommentar: Realiseras genom nya/förändrade LPW tjänster.
Estimat: medel.
Den individuella studieplanen kan utgöra ett underlag vid rapportering av kurser på
forskarnivå.
Kommentar: Individuell studieplan existerar inte i dagens Ladok.
Estimat: hög.
All hantering sker digitalt:
All ansökan om tillgodoräknande sker elektroniskt. Inskanning av det åberopade
underlaget. Meddelande om ansökan kommer elektroniskt.
Kommentar: Om juridiskt möjligt. Tjänst där student får skicka in inskannade dokument
så administratör slipper detta. Inga större problem att realisera även om det är en
omfattande förändring.
Estimat: medel.
Ärendehantering med signering och kontrasignering används. Meddelande skickas om
inte ärende bearbetats. Automatisk påminnelse ”nästa instans” om ej bearbetning sker
inom viss tidsram. Går vidare till högre instans om ej bearbetats trots påminnelse.
Kommentar: Ett lite större jobb att införa en ärendehantering enligt detta.
Estimat: hög.
Bättre dokumentation av betygsättare/historik.
Kommentar: Idag problem med om betygsättare slutat.
Estimat: medel.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Version 1.0
Rapport
Björn Edlund, Mikael Berglund
2011-12-02
Sida: 29 (35)
Betyg på hel kurs föreslås automatiskt om alla villkor är uppfyllda.
Kommentar:
Estimat: låg.
Möjlighet att automatiskt koppla skrivning och poäng till betyg.
Kommentar: Inget problem med datamodellen, utan handlar endast om kod.
Estimat: låg.
Möjlighet att delge resultat kring betyg, resultat, tillgodoräknande m.m. för samtliga
nivåer på ett mer automatiserat sätt genom e-post, sms m.m.
Kommentar: Finns delvis idag. Behöver utökas.
Estimat: medel.
Möjligt för lärosätet att själv styra vilken information från Ladok som ska gå att delge
studenten direkt när det är dokumenterat och arkiverat.
Kommentar: Inget större problem att föra in.
Estimat: låg.
Huvudprocess 13: Utfärda examen
Förändringar gentemot dagens system (texten inklippt från processerna i kursiv stil):
Automatisk kontroll av uppfyllda examensvillkor finns inte alls idag.
För att den kontrollen ska kunna göras så måste individuella studieplaner finnas
upplagda för varje student. För studenter som följer en utbildningsplan ser de
individuella studieplanerna likadana ut för alla studenter.
Studenten kan också själv kontrollera sin progression gentemot uppsatta villkor.
Kommentar: Kräver individuell studieplan som inte finns idag.
Estimat: hög.
När kraven för examen förefaller vara uppfyllda så skickas en elektroniskt meddelande
till studenten. Den funktionen finns inte alls idag.
Kommentar: Skulle också kanske vara bra om meddelande skickas om nästan uppfylld
examen och vad som saknas.
Estimat: låg (om föregående punkt redan implementerats).
Alla ansökningar för både kursbevis och examensbevis görs elektroniskt via webben och
studenten får ett elektroniskt meddelade om att ansökan är mottagen av lärosätet.
Kommentar:
Estimat: medel.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 30 (35)
I och med att man har en elektronisk autentiseringslösning, till exempel med elegitimation så höjs rättsäkerheten. Man vet att det är rätt person som ansökt.
Alla ärenden hanteras med hjälp av ärendehantering och när ansökan inkommer så får
administratören/examenshandläggaren ett elektroniskt meddelande.
Till skillnad från idag görs kontroll och bedömning av huruvida examenskrav och andra
krav är uppfyllda elektroniskt.
Genom övervägande elektronisk hantering blir pappershanteringen vid kompletteringar
mindre och inhämtning av saknade uppgifter blir mer effektiv.
Både kursbevis och examensbevis (som har ett unikt identifikationsnummer) signeras
elektroniskt av bemyndigade personer.
Underlaget kan lätt användas i moduler som lärosätet kan anpassa utifrån egna beslut
om grafisk utformning.
Både kursbevisen och examensbevisen arkiveras elektroniskt och överföring av uppgifter
till legitimationsutfärdande myndigheter sker elektroniskt.
Huvudprocess 27: Hantera gemensam information
Processen hanterar gemensam information beskriver hur man kan jobba med information
som är av intresse att ha definierad på samma sätt och som man vill förvalta gemensamt.
Exempel på denna gemensamma information kan vara examenstyper, handledartyper,
kurstakt, kurstid, undervisningsform, utbildningsnivå, utbildningsområde, försörjningsart,
urvalsgrupper, betygsskalor, finansieringsformer, orter, länder, svenska lärosäten och
utländska universitet.
Ett förslag som nämnts tidigare i detta dokument är att förutom de lokala databaserna
även introducera en gemensam databas där gemensam information kan lagras.
5.2
Icke funktionella krav
[6] innehåller en stor mängd icke funktionella krav. Dessa är dock under
gallring/bearbetning och för tillfället finns ingen mer fullständig analys i detta dokument.
Ett av kraven är dock av särskilt stort intresse, nämligen DES-01-02 rörande kravet om
nationell installation. Den stora begränsningen för refaktoreringsspåret är som tidigare
påpekats lokala databaser för respektive högskola. Detta är dock inte samma sak som
kravet på nationellt installation. Tittar man på Ladok så finns det idag tre driftcentraler,
men det skulle lika gärna kunna vara ett driftställe. Tittar man på exempelvis Javabatcharna så fungerar det så att det går utmärkt att köra batcharna för samtliga högskolor
på en server (om man inte av lastskäl behöver flera) och en uppsättning JAR filer och
script. För respektive högskola finns sedan en konfigurationsfil och det startas en process
för varje högskola. Huruvida denna hantering (antaget att man har en driftcentral som inte
är tekniskt relaterat) anses uppfylla kravet när det gäller nationell installation är något att
fundera över.
Även om majoriteten av data även fortsättningsvis antas ligga i en lokal databas så är det
förmodligen en bra idé att kombinera detta med en gemensam databas för visst data. Om
man börjar med att se till att möjligheten finns och lägger dit data av ”mycket” gemensam
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Björn Edlund, Mikael Berglund
Rapport
Version 1.0
2011-12-02
Sida: 31 (35)
karaktär som till exempel landskoder så kan denna databas utökas med tiden. Om
antagandet är att alla högskolor driftas av samma driftcentral kommer alla servrar ligga
inom samma brandvägg, så åtkomsten av den gemensamma databasen borde inte skapa
några problem.
5.3
Slutsatser
Som tidigare nämnts är det svårt att jämföra Ladok3s övergripande krav med det
existerande Ladoks detaljerade funktionalitet. Slutsatsen är dock att skillnaderna är små.
En större sak är förstås modelleringen i Ladok3 modellen som tillåter flera lärosäten i
samma databas, men eftersom ett grundantagande beträffande refaktoreringen är att
lokala databaser skall behållas är detta inte ett problem. Bortsett från problematiken med
en eller flera databaser så är med största sannolikhet kraven från Ladok3 hanterbara.
Strategin för detta har redan beskrivits och är i detta läge en viktigare fråga när man
bestämmer sig för om refaktorering är ett bra val eller inte.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Björn Edlund, Mikael Berglund
6
Rapport
Version 1.0
2011-12-02
Sida: 32 (35)
Arbetsplan
Dokumentet har beskrivit en målarkitektur och diskuterat hur dagens Ladok ser ut i
jämförelse. Nedan följer en plan hur det fortsatta arbetet skulle kunna se ut om detta
alternativ skulle väljas. Det ska poängteras att detta arbete inte är något som görs inom
ramen för detta dokument, utan först den dagen när refaktoreringsspåret valts som
alternativ att gå vidare med.
•
Börja arbetet med att skriva en SAD (Software Architecture Document) som utifrån
detta dokument bryter ned det som ska göras på en lägre nivå. Dokumentet skall även
ge svar på den slutliga modulindelningen.
•
Behåll relationsdatamodellen för kravspecifikation. Genomför ett arbete för att skapa
en domänmodellarkitektur inom områden där det finns funktionell duplicering.
•
Genomför en detaljerad analys av den domänlogik som finns implementerad idag.
Försök att identifiera funktionalitet som är duplicerad mellan olika funktioner. Skapa
en domänmodellbaserad klassmodell inom de områden där det skulle ge mest nytta.
Gemensam kod kan också givetvis skapas som domänservicar. Detta är viktigt att
genomföra innan transformeringen av Unifacefunktionalitet sätter igång. Denna
analys ligger inom ramen för SAD arbetet.
•
Bygg vidare på den Common-modul som finns i dagens Ladok och implementera
domänmodellen där.
•
Börja ett arbete där Uniface funktionerna iterativt byts ut. Det innebär att
Javabaserade funktioner kommer att samexistera med deras motsvarigheter i
Nouveau. Detta kommer att leda till att handläggare kommer att behöva jobba med
två typer av klienter. Inte helt idealt, men en konsekvens man får acceptera med en
iterativ refaktoreringsprocess. Ett exempel är att börja med att byta ut alla
katalogfunktioner. Bilden nedan visar hur Uniface kod gradvis byts ut mot Java kod.
Java koden är benämnd LPW eftersom Uniface-delarna kommer att bytas ut mot
webbaserade användargränssnitt..
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 33 (35)
Figure 7: Utfasning av Uniface
•
När det gäller den existerande funktionaliteten finns det ingen anledning att
refaktorera befintlig kod som fungerar bra och har låg förvaltningskostnad.
•
Genomför ett refaktoreringsarbete av databasen. Detta dokument ger en grund vad
som ska göras, arkitekturdokumentet får bryta ned detta ytterligare.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
7
Version 1.0
2011-12-02
Sida: 34 (35)
Analys av effektmål
[8] beskriver projektets effektmål. Den typen av mål är viktiga indikationer för ett
projekt, men många mål är till sin natur svåra att utvärdera på ett exakt sätt. Några av
effektmålen har särskilt stark koppling mot lösningsarkitekturen. Dessa diskuteras i detta
kapitel.
Effektmål 6 – Flexibilitet
Högskolorna får ett hållbart och flexibelt systemstöd, med en struktur som är generellt
användbar med avseende på t ex utbildningsnivåer, valutor, periodbegrepp och
ursprungsländer, och som byggs i en långsiktigt hållbar teknik med lång återstående
livslängd vilket gör att investeringen kan nyttjas under längre tid än den ekonomiska
avskrivningstiden
Flexibilitetsmålet är det högst prioriterade effektmålet. Den kraftfullaste åtgärden som
tagits för att uppfylla detta är att skapa en skiktad arkitektur som isolerar domänlogik
från:
1.
Tekniska ramverk som till exempel Spring och EJB. Syftet med olika ramverk kan förstås
variera men oftast ger de stöd för transaktioner, säkerhet och att kunna verka i en distribuerad
miljö. Livslängden för vilka ramverk som är i ropet brukar vara ganska korta, för tillfället är
det Spring, om några år är det förmodligen något nytt som är i fokus. Det är därför av största
vikt att undvika beroenden från domänlagret mot dessa ramverk. Den lagrade arkitektur som
beskrivits i dokumentet hanterar beroenden mot dessa ramverk i applikationslagret och
infrastrukturlagret, beroenden från domänlagret är förbjudna.
2.
Exponerandet av tjänstegränssnitt mot omvärlden. Den domänlogik som ett system har kan
behöva exponeras på olika sätt, det kan till exempel vara via RMI, SOAP eller REST. På
samma sätt som för tekniska ramverk är behoven/kraven rörande detta något som är ganska
föränderligt. Denna aspekt vill man därför också separera från domänlogiken. I
målarkitekturen hör exponerandet av tjänstegränssnitt till applikationslagret.
Figuren nedan illustrerar strategin.
Ladok3 Arkitektur - Refaktorering
Ladok3-projektet
Rapport
Björn Edlund, Mikael Berglund
Version 1.0
2011-12-02
Sida: 35 (35)
Figure 8: Separation av domänlogik
Att följa den arkitekturen är det centrala när det gäller flexibilitet eftersom det gör att
förändringar kan föras in utan att det påverkar kärnan i systemet.
Effektmål 1 - Förbättrad kommunikation
Högskolorna får en gemensam plattform som snabbt och allsidigt kommunicerar med
alla omgivande informationssystem av intresse och vid behov kan dela data med dessa,
samt med andra högskolor, både nationellt och internationellt.
- Alla integrationer mot kringsystem kan använda standardgränssnitt för kommunikation med
Ladok. Inga system ska behöva hämta eller skriva in information direkt mot databasen via SQL.
- Överföring till andra system där behov finns av kontinuerlig uppdatering, ska inte hanteras via
batchöverföringar.
Idag finns det exempel på kringsystem som använder databasen direkt via SQL. Detta
skulle kunna ersättas genom att exponera fler REST/SOAP tjänster. Det finns kritik mot
att de exponerade tjänsterna har ändrats för mycket, vilket gjort att kringsystemen varit
tvungna att uppdateras. Det har därför varit ”stabilare” att direkt bero av datamodellen.
Detta är relaterat till hur tjänstegränssnitten är utformade och bör ses över.