Samverkande GIS med ISO 19100

Transkript

1 Samverkande GIS med ISO En handbok om tekniskt ramverk för geografisk information

2 Utarbetad av SIS, Swedish Standards Institute Tekniska kommittén Ramverk för geografisk information (SIS/TK 323) Utgiven av Stanli - SIS projektområde för geografisk information Utgåva 1 September 2004 (01-01) 2

3 Innehåll 1 Samverkande GIS Data med innebörd Tekniska lösningar för samverkan Lösningsoberoende specifikationer Specifikationer för tekniska lösningar Vad är Tekniskt ramverk för geografisk information? Det tekniska ramverket är plattformen Gränssnittsspecifikationer för geografisk information ISO 19100, standardscheman och applikationsscheman Vem är tekniska ramverket till för? Vad ingår i det tekniska ramverket? Ramverkets utveckling En utvecklingsprocess för gränssnittsspecifikationer Standardiseringsprocessen och utvecklingsprocessen Förutsättningar Specifikationens syfte och omfattning Testfall Termer och begrepp Informationsbehov uttryckt som objekttyper Applikationsscheman Modeller för olika lösningar Kvalitetssäkring, test och verifiering Överensstämmelsekrav Kvalitetssäkring vid specifikationsarbetet Beskrivning av kvalitetssäkringsrutiner Exempel på checklistor Att konstruera ett applikationsschema UML och regler Modelleringsverktyg Applikationsscheman är paket Att utnyttja standardscheman Användning av andra applikationsscheman i ett applikationsschema Modellering av objekttyper Namnregler Modellering av specialisering Modellering av samband Modellering av attributtyper Datatyper från standardscheman Typoberoende representation Rumsliga egenskaper i applikationsscheman Geometri och topologi Implicit topologi Explicit topologi Rumsliga objekt och geografiska företeelser Rumsliga attribut Geometriska primitiver Geometriska sammansättningar Topologiska primitiver Topologiska komplex Rumsliga samband mellan objekt Objekt som delar geometri Flera alternativa representationer

4 6.13 Separerade topologier Lägesredovisning med geografiska identifierare Tidsaspekter i applikationsscheman Temporalt referenssystem Tidsattribut Enkla tidssamband Objektsföljd Metadata Metadata om datamängder Metadata i applikationsscheman Kvalitetsdata i applikationsscheman Anpassning av standardscheman efter egna behov Utökning av standardschema Inskränkning av standardschema Profiler XML-kodning av data Modellfiler, XML-scheman och data XML-dokumentets struktur Kodning av självständiga objekt Sammansättningar och associationer Arvsmekanism Konverteringsregler Överföring av förändringar i datamängder Genereringsexempel Datakvalitet Bakgrund Kvalitetsbegreppet Kvalitetsegenskaper Kvalitetstyper Beskrivning av koordinatsystem Referensnät och referenssystem Standarden ISO Modell för att beskriva ett referenssystem Koordinatoperationer Terminologi och definitioner Symboler och förkortningar Exempel på koordinatsystem Lokalisering med geografiska identifierare Indirekt lägesangivelse Standarden ISO Ingående delar för att beskriva ett indirekt referenssystem Beskrivning av indirekta referenssystem Standardschema för geometri Översikt Positionsangivelse - DirectPosition GM_Object GM_Primitive Geometri med riktning GM_Point GM_Curve, etc GM_Surface, etc GM_Solid, etc GM_Complex GM_Composite, etc GM_Aggregate, etc Standardschema för topologi

5 15.1 Översikt TP_Object TP_Primitive TP_DirectedTopo TP_Node och TP_DirectedNode TP_Edge och TP_DirectedEdge TP_Face och TP_DirectedFace TP_Solid och TP_DirectedSolid TP_Complex Härledda topologiska relationer Standardschema för tidsaspekter Översikt Temporala basklasser Temporala geometriska objekt Temporala topologiska objekt Temporala referenssystem Kalender och klockor Temporal position Exempel - Temporal positionering i SS Kvalitetsrapportering - förklaringar Scope Conformance Normative references Terms and definitions Principles for describing the quality of geographic data Identifying the quality of geographic information Reporting quality information Kvalitetsrapportering - anvisningar Allmänt Övergripande kvalitetsuppgifter Hänvisningar Termer och definitioner

6 Förord Stanli är det projektområde inom SIS som utarbetar stadnarder för geografisk information. Genom Stanlis försorg utkom 1998 handboken Tekniskt ramverk för geografisk information (STG Hb 171, Utgåva 1). Handboken innehöll dels ett antal standarder för modellering och överföring av rumsliga data, dels beskrivningar av hur standarderna skulle användas. Detta gjorde att den blev tämligen omfångsrik - över 900 sidor. De standarder som ingick var dels s.k. europeiska förstandarder för geografisk information, dels ISO-standarder för modellspråk och dataöverföring (Express). Sedan 1994 har inom ISO pågått ett projekt för heltäckande standardisering av geografisk information och idag finns ett flertal fastställda standarder i den s.k. ISO serien. Stanli beslutade 2001 att det tekniska ramverket skulle anpassas till dessa ISO-standarder och under 2002 påbörjades arbetet. Den föreliggande handboken Samverkande GIS med ISO är resultatet av detta arbete. En praktisk skillnad mot tidigare är att själva standarderna inte är inkluderade utan att handboken istället inriktar sig på förklaringar och anvisningar till standarderna. Handboken utgör därigenom en del av det tekniska ramverket. Den tekniska kommittén Ramverk för geografisk information (SIS/TK 323) som ansvarar för handboken har givit specialister i uppdrag att ta fram manus för olika delar av handboken. De som medverkat är: Ralf Lindgren, Sjöfartsverket Mikael Lilje, Lantmäteriet Gunhild Lönnberg, Lantmäteriet Robert Noack, Eurostep Sten Sandström, SGU Erik Stenborg, Banverket Väino Tarandi, Eurostep Hakon Wikström, Metria GIS-Centrum Lars Wikström, Triona Rolf Wohed, Syntell Dessutom har personer i den tekniska kommittén varit engagerade vid genomgångar och granskningar. Anders Skog på Stanlisekretariatet har sammanställt och anpassat materialet. Terminologicentrum (TNC) har medverkat vid terminologi- och språkgranskning av valda delar. Under arbetets gång har det framkommit ytterligare önskemål om vad en handbok bör ta upp. En plan för kommande revideringar finns under Användarstöd på där även frågor och påpekanden om innehållet i handboken kan lämnas. Stockholm i september 2004 Torbjörn Cederholm Projektledare för Stanli Swedish Standards Institute 6

7 1 Samverkande GIS Strukturerad, väldefinierad och lättillgänglig information har blivit en av dagens viktigaste infrastrukturfrågor. På denna information ska alla de tjänster byggas som i sin tur ska möjliggöra samverkan av helt nytt slag mellan organisationer, företag och samhällsmedborgare. Den geografiska informationen - all den information som direkt eller indirekt är knuten till någon plats på jorden - kommer att spela en oerhört viktig roll i detta scenario. Skogsnäring, energiproduktion, transportsystem, tekniska anläggningar, jordbruk, räddningstjänst, marknadsföring. Det finns inte många områden som inte på något sätt har en geografisk koppling. Det betyder kanske inte att begreppet GIS - geografiska informationssystem - borde omfatta alla de system som hanterar sådan information. Klart är dock att behoven att låta systemen samverka ökar i samhället. 1.1 Data med innebörd När olika informationssystem inte kan prata med varandra kan de inte samverka. Informationsutbytet blir krångligt, dyrt och osäkert. För samverkande GIS som för annan digital samverkan är kommunikationsproblemen dock inte enbart tekniska utan det handlar också om innebörden av data. Det betyder att specifikationer för samverkan måste innehålla både de tekniska formaten och erforderlig hjälp att bygga och tolka data. Den här handboken handlar om hur man utformar sådana dataspecifikationer. Vi kallar dem för gränssnittsspecifikationer. De kan användas för samverkan inom och mellan organisationer men de skulle även kunna ligga till grund för utformandet av databaser och programsystem. Gränssnittsspecifikationer för geografisk information kan bli till standarder och en hel del arbete som pågår i Sverige, Europa och internationellt syftar också till detta. Standardisering ökar möjligheterna att integrera data från olika källor och gör det enklare att hitta dataleverantörer. Oavsett om det är en global standard eller en överenskommelse mellan två organisationer som är målet är det en stor fördel om gränssnittsspecifikationer bygger på standarder. Det förbättrar förutsättningarna för spridning och sänker kostnaderna för utveckling av GIS. Den här handboken bygger på sådana globala standarder. I anslutning till att en gränssnittsspecifikation tas fram kan även andra viktiga specifikationer tas fram, t.ex. terminologi, regelverk, checklistor och principer inom ett visst tillämpningsområde. 1.2 Tekniska lösningar för samverkan För att få en digital samverkan att fungera måste det finnas en överenskommelse mellan dem som ska samverka. Man måste vara överens om såväl principiell lösning och teknisk kommunikationsmetod som datasyntax och semantik. Vädercentralen Trafikverket Plogbolaget Figur 1 - Informationssamverkan Informationssamverkan mellan verksamheter kan innebära mycket olika behov, till exempel: De parter som är inblandade måste alltid ha tillgång till samma information. 7

8 En part måste kunna initiera en aktivitet hos en annan part. En part måste kunna efterfråga information från en annan part. Därtill finns det många principiella lösningar, till exempel: Man kan skicka filer eller meddelanden till varandra. Man kan ha en gemensamt åtkomlig databas. Man kan erbjuda varandra programgränssnitt som kan utnyttjas över nätet. Vädercentralen Skicka filer Trafikverket Plogbolaget Vädercentralen Databas Trafikverket Plogbolaget Fråga/svar Plogbolaget Trafikverket Vädercentralen Figur 2 - Behoven styr valet av principiell och teknisk lösning. Varje sådan principiell lösning kan i sin tur åstadkommas med olika teknik. Filöverföring kan t.ex. lösas med någon typ av XML-kodning, med filer med fasta fältlängder eller med EDI-liknande syntax. Åtkomsten av databaser kan göras med SQL eller realiseras i något programmeringsspråk. Fråga-svars-tjänster kan implementeras enligt Web Services-konceptet eller med tekniker som Corba. Filöverföring med XML enligt... Lösningsoberoende gränssnittsbeskrivning informationsbeskrivning Filöverföring med STEP enligt... Databas med SQL-gränssnitt enligt Web Services med gränssnitt enligt Figur 3 - Den lösningsoberoende specifikationen kan ligga som underlag för olika lösningar. Det som är gemensamt för all dessa lösningar för digital samverkan är att de inblandade parterna måste vara överens. För olika principiella och tekniska lösningar finns olika saker att komma överens om, men för alla lösningar krävs att parterna har samma uppfattning om den information som samverkan kretsar kring. Denna information går att beskriva oberoende av vilken principiell och teknisk lösning man väljer och kan därigenom utnyttjas för flera lösningar, samtidigt eller över tiden. Det betyder att samma modell kan ligga till grund för databaslösningar som för filöverföring men också för lösningar som inte ens är kända idag. 8

9 Trafikverket Vädercentralen Plogbolaget STANDARD Gemensam informationsbeskrivning Figur 4 - En standard kan beskriva informationsinnehållet oberoende av vilken lösning som väljs. 1.3 Lösningsoberoende specifikationer En lösningsoberoende gränssnittsspecifikation innehåller modeller som på ett formellt sätt beskriver: vilka datauppgifter som är intressanta i sammanhanget hur dessa datauppgifter är strukturerade vilka värden datauppgifterna kan ha Detta räcker dock inte; det måste även finnas en beskrivning som ger en begreppsmässig förståelse för vad uppgifterna avser. Denna del av specifikationen tar upp de verksamhetsbegrepp som är viktiga för samverkan samt sådana verksamhetsbegrepp som behövs för att förklara dessa. 1.4 Specifikationer för tekniska lösningar För att utnyttja en lösningsoberoende specifikation för en viss teknisk lösning krävs att man kan ta fram en specifikation som tar hänsyn till den tekniska lösningens särart. Om det finns väldefinierade regler kan den till och med skapas automatiskt förutsatt att den lösningsoberoende specifikationen är maskintolkbar. Sådana maskintolkbara format kan utnyttjas för utbyte av modeller mellan olika modelleringsverktyg men också som grund för en automatisk generering av olika delar som behövs för en viss lösning, t.ex. XML-scheman eller SQL-kod. Ambitionen hos denna handbok är att visa hur en lösningsoberoende gränssnittsspecifikation tas fram och dokumenteras samt att visa hur denna kan användas för att ta fram en beskrivning för en viss principiell och teknisk lösning, nämligen satsvis dataöverföring med XML. Detta hindrar naturligtvis inte att handboken och tekniskt ramverk kan utnyttjas även för andra principiella och tekniska lösningar. 9

10 2 Vad är Tekniskt ramverk för geografisk information? 2.1 Det tekniska ramverket är plattformen Det första steget mot en geografisk informationsinfrastruktur är att skapa en plattform som alla aktörer kan referera till, oavsett om man är lantmätare, geolog, samhällsvetare, arkitekt, statistiker eller vilken annan berörd yrkesgrupp som helst. Denna plattform - som vi kallar det tekniska ramverket för geografisk information - bygger på generell IT-standard som UML och XML och på internationella standarder för geografisk information. Denna handbok - Samverkande GIS med ISO är en vägledning i att utnyttja det tekniska ramverket. Handboken inriktar sig på metodik och formell beskrivningsteknik. De beskrivningar som görs kan mycket väl komma att leva längre än den teknik som används vid datahanteringen. Gränssnittsspecifikationer gör därför skillnad på det som är oberoende av och det som är direkt avsett för en viss teknisk lösning för att få ITsystem att samverka. De specifika tekniska lösningar som behandlas i handboken begränsar sig för närvarande till filöverföring med XML. 2.2 Gränssnittsspecifikationer för geografisk information Det primära syftet med den här handboken är att visa hur specifikationer byggs upp för att stödja överföring, utbyte eller lagring av geografisk information i ett visst sammanhang eller för ett visst område ett visst tillämpningsområde. Tekniskt ramverk för geografisk information ISO Internationell standard för geografisk information Standarder för olika tillämpningsområden Vägtrafik Försörjningssystem Naturresurser Fastigheter Sjöar och vattendrag Järnvägar Fornlämningar Kraftledningar Figur 5 - Med ett gemensamt ramverk ökar möjligheterna att ta fram samverkande standarder Ramverket erbjuder metoder, regler och resurser för att både beskriva och överföra geografiska data. Ramverket blir på det viset styrande vid utarbetande av en gränssnittsspecifikation som till exempel ingår i en tillämpningsstandard. Genom denna specifikation och med ramverkets regler blir även dataöverföringen mellan olika system väldefinierad. Ramverket erbjuder även metodik och resurser för beskrivning av geografiska data, s.k. metadata. Det gäller framför allt aspekter som ha med datakvalitet att göra. 2.3 ISO 19100, standardscheman och applikationsscheman En gränssnittsspecifikation, t.ex. en tillämpningsstandard, innehåller applikationsscheman. Det är formella modeller som beskriver data hos företeelser som återfinns i ett visst sammanhang i den verkliga världen. Det kan vara fysiska företeelser som busshållplatser och vägkorsningar, men det kan också vara mer abstrakta företeelser som arrendeavtal eller hastighetsbegränsningar. En skillnad mot traditionella modeller för geografiska data är att ISO skiljer noga på företeelser och deras rumsliga egenskaper. Man talar inte om punktformiga och linjeformiga företeelser utan försöker se de rumsliga egenskaperna på samma sätt som andra egenskaper som t.ex. färg och namn. Ramverksstandarderna som det tekniska ramverket baseras på är standarderna i ISO serien samt ett par svenska standarder. Innehållet i dessa standarder berör regler och principer för applikationsscheman och datakodning samt modeller för geometri, topologi och tidsaspekter. Dessutom finns både regler och modeller för datakvalitet och annan metadata. Vissa av ramverksstandarderna innehåller formella databeskrivningar, s.k. standardscheman. Mycket av det som beskrivs i handboken och i tekniskt ramverk skulle kunna användas inom vilket område som helst. De modeller och standardscheman för topologi och geometri som definieras i standarderna visar dock på att det är just geografisk information det handlar om. Den information som behövs för att beskriva t.ex. ett gatunät är mycket komplex och beskrivningen skulle kunna göras på många 10

11 olika sätt. Syftet med att införa standarder för hur man beskriver en polygonlinje eller ett nätverk är att ge de nödvändiga och tillräckliga uttrycksmedel som behövs och därigenom styra upp hur information om t.ex. ett gatunät faktiskt beskrivs. Tekniskt ramverk för geografisk information ISO Standardscheman Metadata Kvalitet Geometri Topologi Tid Applikationsscheman för olika tillämpningsområden ISO Regler för applikationsscheman - när ska standardscheman användas? - hur får standard-scheman användas? - konstruktionsregler - dokumentationsregler Fastigheter Vägtrafik Järnvägar Försörjningssystem Fornlämningar Naturresurser Kraftledningar Sjöar och vattendrag Figur 6 - I ISO finns regler för hur applikationsscheman ska konstrueras 2.4 Vem är tekniska ramverket till för? Tekniskt ramverk och denna handbok vänder sig primärt till dem som är med och utvecklar gränssnittsspecifikationer för geografisk information. Hit hör framförallt de som med sina kunskaper om den egna verksamheten bidrar till att specifikationen behandlar rätt saker. De som arbetar i nuvarande och kommande standardiseringsprojekt inom Stanli är en självklar målgrupp men naturligtvis kan ramverket tillämpas även om målet inte är en formell standard. Många delar i ramverket är mycket komplicerade och kan kräva djupa kunskaper i såväl modellering som i geodesi och grafteori. Handboken har inte ambitionen att göra dessa delar tillgängliga för vem som helst. Däremot kan den sätta in dem i ett sammanhang så att olika individer kan bidra med sin kunskap på rätt ställe i utvecklingsprocessen. Även de som implementerar specifikationerna och tar fram olika tekniska lösningar har stor nytta av det tekniska ramverket. Hit hör t.ex. systemutvecklare, systemintegratörer, programvarutillverkare och systemleverantörer. 2.5 Vad ingår i det tekniska ramverket? Det tekniska ramverket innehåller Denna handbok: Samverkande GIS med ISO Ramverksstandarder: ISO serien Ramverksstandarder: Svenska standarder Dokumentmallar: Nedladdningsbara mallar för olika beskrivningar Standardschemafiler: Nedladdningsbara modellfiler Exempelmaterial: Nedladdningsbart material som refereras i handboken Nedladdningsbara filer finns på Stanlis webbsidor för användarstöd ( 11

12 De ramverksstandarder som refereras och behandlas i denna handbok framgår av nedanstående tabell. Av dessa är de flesta färdiga. Samtliga kommer att bli formellt fastställda under Nummer Engelsk titel Svensk titel Beskrivning ISO Conceptual schema language Modellbeskrivningsspråk Krav på beskrivningsspråk för standardscheman och applikationsscheman. Används som anvisning för klassdiagram i UML. ISO Spatial schema Modell för att beskriva rumsliga aspekter Standardschema för representation av geometri och topologi ISO Temporal schema Modell för att beskriva tidsaspekter Standardschema för representation av tidsaspekter ISO Rules for application Regler för tillämpnings- Regler för hur man ska göra ett ISO schema Spatial referencing by coordinates modell Modell för att beskriva rumsliga koordinatbaserade referenssystem applikationsschema Standardschema för att beskriva koordinatbaserade referenssystem ISO Spatial referencing by geografic identifiers Modell för att beskriva icke koordinatbaserade referenssystem Standardschema för att beskriva icke koordinatbaserade referenssystem, t.ex. indelningar och geografiska namnkataloger ISO Quality principles Kvalitetsprinciper Principer för kvalitetsrapportering ISO Quality evaluation principles Metoder för utvärdering Metoder för utvärdering av kvalitet av kvalitet ISO Metadata Metadata Standardschema för representation av metadata och kvalitet ISO Encoding Kodningsregler för överföring av data Kodningsregler för dataöverföring, särskilt för generering av XML- SS SS Generic representation of geographic features Representation of changes in datasets Generisk representation av geografiska företeelser Representation av förändringar i datamängder scheman från applikationsscheman Behandlar en katalogbaserat angreppssätt för att representera och överföra data om geografiska företeelser. Beskriver transaktioner för att ta bort, lägga till eller uppdatera data i datamängder Ramverkets utveckling Det tekniska ramverket kommer att utvecklas. Detta kommer bland annat att ske genom att nya ramverksstandarder, både globala och nationella, kommer till. Handboken, mallar, standardscheman och exempelfiler kommer också att förändras. På Stanlis webbplats ( ska man kunna följa utvecklingen. 12

13 3 En utvecklingsprocess för gränssnittsspecifikationer Denna handbok ska tillsammans med övriga delar i det tekniska ramverket ge stöd vid utvecklingen av specifikationer för geografisk information inom olika tillämpningsområden. Dessa specifikationer kan användas i standarder men de kan också fungera i andra sammanhang. I ISO 19100, som ramverket bygger på, sägs inget om hur ett sådant utvecklingsarbete ska bedrivas. En rekommendation av hur utvecklingsprocessen ska gå till är dock viktig av flera anledningar. Dels kan den göra det enklare att komma igång, dels kan den höja kvaliteten på resultatet. Avgränsning av tillämpningsområdet och specificering av arbetets resultat Målmodell med användningsfall och tillämpningsområde samt specifikation av innehåll i olika arbetsresultat Analys och definition av termer och begrepp Begreppsmodell med termer, definitioner och illustrationer Terminologi för tillämpningsområdet Regler och modeller från ISO Analys av informationsbehov Konstruktion av datastruktur genom tillämpning av standardmodeller Generering av teknisk lösning Beskrivning av objekttyper som man ska kunna hantera data om, med definitioner, egenskaper, värdedomäner och samband Applikationsschema som UMLpaket med klasser, attribut, datatyper och relationer Utökningsregler för utökning av struktur och specifikation av värdedomäner Överföringsformat i form av XML-schema Figur 7 - Utvecklingsprocessen består av ett antal olika aktiviteter som ger vissa resultat. 3.1 Standardiseringsprocessen och utvecklingsprocessen Standardiseringsarbete är utvecklingsarbete. På samma sätt som i annat utvecklingsarbete krävs projektledning och koordinering mellan olika aktiviteter. I ett formaliserat standardiseringsprojekt sköts sådant arbete av en teknisk kommitté samtidigt som ett antal arbetsgrupper utvecklar standarden. I ett mera informellt specifikationsarbete, t.ex. i ett företag, sköts det istället av någon typ av projektledning. Det ligger utanför det tekniska ramverkets intresse att beskriva en sådan modell och samspelet mellan arbetsgrupperna och kommittén. Det som beskrivs här är aktiviteterna i utvecklingsprocessen, vilka resultat de ger och hur de hänger ihop. Beskrivningen av en utvecklingsprocess specificerar en förutbestämd arbetsgång, den input som behövs och de resultat som skapas under arbetet. Den kan också gå in på vilka arbetsmetoder och samarbetsformer man bör använda. Syftet är att säkra kvaliteten på resultatet och i praktiken innebär detta att se till att vissa dokument med visst innehåll produceras och granskas. Den utvecklingsprocess som beskrivs här i handboken tar upp de delar som behandlar utvecklingen av innehållet i en gränssnittsspecifikation. Men även delar som handlar om att avgränsa tillämpningsområdet och att beskriva mål och krav behandlas. Däremot beskrivs inte i detalj hur arbete kan bedrivas parallellt eller genom att upprepa delar av processen, s.k. iterativ utveckling. Resultatet av utvecklingsaktiviteterna är de dokument och datafiler som ska ingå i specifikationen. Vilka de är beror på de krav som ställts i början av utvecklingsprocessen. Det kan handla om att reda ut termer och begrepp eller att utveckla ett komplett överföringsformat för datautbyte. 13

14 Standardiseringsprocessen: uppstart, avgränsning, målformulering, remisshantering, fastställelse, förvaltning... Input Mellanresultat Utvecklingsresultat Återkoppling Standard Utvecklingsprocessen Regler och modeller enligt tekniskt ramverk för geografisk information Figur 8 - Utvecklingsprocessen är en del av standardiseringsprocessen Om avsikten med specifikationen är att möjliggöra informationsutbyte måste de resultat som uppstår i processen vara tillräckliga för att få till stånd en fungerande dataöverföring. Men det handlar inte enbart om att så enkelt och snabbt som möjligt kunna bygga den programvara som krävs utan det handlar också om att effektivt och säkert kunna hantera förändringar i behov och tekniska förutsättningar. 3.2 Förutsättningar Förutsättningarna för ett specifikationsarbete kan vara mycket olika. Data finns redan i en databas. Specifikationen ska beskriva data så att det kan överföras och andra kan utnyttja det. Det finns en väl utvecklad begreppsapparat som de tilltänkta användarna alla utnyttjar. Specifikationen kan hänvisa till den när innebörden i data ska beskrivas. Man vet bara att vissa problem ska kunna lösas och måste börja med att avgränsa omfattningen. Värdemängder för vissa datauppgifter är given och ska användas i specifikationen. Förutsättningarna avgör vilka aktiviteter som måste genomföras. 3.3 Specifikationens syfte och omfattning En specifikation har något syfte. Syftet måste klargöras och beskrivas av framför allt två skäl. För det första måste de som utformar specifikationen ha en gemensam och dokumenterad uppfattning om syftet. Genom att pröva resultatet mot det syfte man hade kan man kvalitetskontrollera arbetet. För det andra måste användare av specifikationen kunna bedöma om den är relevant för deras behov. Därför bör syftet på något sätt finnas dokumenterat i specifikationen. När man känner till syftet med specifikationen bör man även kunna beskriva vad den omfattar. Omfattningen kan uttrycka såväl tillämpningsområdets avgränsning som specifikationens innehåll. Avgränsning av tillämpningsområdet och specificering av arbetets resultat Målmodell med användningsfall och tillämpningsområde samt specifikation av innehåll i olika arbetsresultat Figur 9 - Målmodell 14

15 3.3.1 Målanalys Syfte med och omfattning av en tillämpningsstandard (eller annan gränssnittsspecifikation) bestäms genom målanalys. En målanalys är ett grupparbete där olika intressenter finns representerade. Först inventerar man vilka problem i verksamheten som man hoppas att specifikationen ska kunna lösa. Problemen samlas ihop i olika problemområden för att man ska få en överblick. Därefter inventerar man, utgående från problemområdena, vilka mål man har i anknytning till den tänkta specifikationen. Genom att gruppera målen kan man identifiera vad som är huvudsakliga mål och vilka mål som bidrar till att dessa kan nås. Utifrån denna så kallade målmodell bör därefter syfte och omfattning kunna uttryckas. Specifikationens sammanhang eller samband med andra specifikationer och standarder bör också beskrivas. Vissa processer i en verksamhet kan beröra fler än en specifikation och därmed är det viktigt att dessa är väl harmoniserade så att de effektivt stöttar verksamhetens begrepps- och informationshantering Tillämpningsområdets avgränsning Avgränsningen av tillämpningsområdet syftar till att ge en kravlista. Denna kravlista kan användas för kommunikation med dem som ska ta fram specifikationen. Man har också möjlighet att dela upp arbetet i flera omgångar där tillämpningsområdet utökas för varje omgång eller att prioritera mellan olika delar av tillämpningsområdet. Som i allt utvecklingsarbete kan kraven användas för att pröva att resultatet är det förväntade. Viktiga aspekter för tillämpningsområdets avgränsning är vilka företeelser som specifikationen ska (och inte ska) hantera vilka verksamhetsprocesser och informationsflöden som specifikationen ska (och inte ska) hantera vilken detaljeringsgrad och dimension rumsliga beskrivningar ska ha vilka förändrings- och tidsaspekter som ska hanteras Gränssnittsspecifikationens innehåll En specifikation kan innehålla många olika beskrivningar. En innehållsförteckning kan, på samma sätt som en avgränsning av tillämpningsområdet, användas för kommunikation med dem som ska ta fram specifikationen. Förutom att ge möjlighet att dela upp arbetet i flera iterationer eller prioritera mellan olika delar ger den också möjlighet att fördela arbetet, både i tiden och mellan olika individer eller grupper. Viktiga aspekter för innehåll är huruvida definitioner av begrepp och termer ska ingå huruvida datastruktur i form av applikationsscheman ska specificeras huruvida modeller för datakvalitet och annan metadata ska specificeras vilka olika tekniska lösningar som ska specificeras huruvida samverkansprocesser ska specificeras huruvida principer för utökning och framtida förändring av specifikationen ska beskrivas vilka principer, regler och rekommendationer som ska specificeras vilka separata specifikationer som borde tas fram för att därigenom utgöra en gemensam resurs för flera specifikationer vilka kopplingar till praxis, kataloger och andra standarder som ska utnyttjas vilken dokumentationsform specifikationen ska ha, t.ex. uppdelning i flera delar vilka datafiler som specifikationen ska inkludera, t.ex. ordlistor, modeller, scheman Samverkansbeskrivningar Alla medel är tillåtna för att klargöra och illustrera syftet med en tillämpningsstandard. Att beskriva samverkan eller användning på en hög nivå är ett sätt. Då framgår dels sådana saker som vilka aktörer som är inblandade, vem som tar initiativ och vem som producerar och konsumerar data. Dessutom framgår vad man samverkar om, vilket ger en avgränsning av tillämpningsområdet. 15

16 Formella metoder kan hämtas från litteratur i modellering och systemutveckling, t.ex. användningsfall enligt UML eller en process- och funktionsbeskrivning enligt FIPS IDEF0-standarden FIPS IDEF0 I IDEF0-standarden kan också specifikationens avgränsning åskådliggöras. En specifikation omfattar nämligen den information som behövs i verksamhetsprocesserna. Särskilt är det den information som flödar mellan processerna som behöver standardiseras Användningsfall enligt UML Begreppet användningsfall blir allt vanligare inom objektorienterade tekniker och kan definieras som en sekvens av transaktioner i systemet som ger en användare ett mätbart resultat av bestående värde. En illustration av hur samverkan mellan processer, användningsfall och aktörer kan beskrivas finns i figuren nedan. Planteringsplanering Bonde Köp eller arrende av mark Arrondering av fruktodlingsenheter Plantering Plantor Skötsel Fruktbärande plantor Skörd Frukt Fruktförsäljning Avveckling av växter och fält Skördeprognos Skördeplanering Skörda Länsstyrelserapportering Grossist Bonde Skörderedovisning Länsstyrelse Processbeskrivning och omfattning Användningsfall Aktör Verksamhetsprocess Figur 10 - Syfte och omfattning kan beskrivas i form av processer, användningsfall och aktörer Till fördelarna med användningsfall kan nämnas att de fokuserar på användare, bidrar till bra användarförankring, bra och successiv nedbrytning av komplexa system samt utgör ett naturligt underlag för test. Exempel på användningsfall på hög nivå kan vara: skördeprognos, skörd, länsstyrelserapportering. Användningsfall bör på den här nivån beskriva de centrala uppgifterna i processerna och de viktigaste användarna, allt i avsikt att tydliggöra standardens omfattning. Användningsfallsmodellering kan användas för att, utgående från funktionsbeskrivningar och användningsfall, identifiera begreppen och konstruera begreppsmodellen. Denna metodik finns beskriven i boken Object- Oriented Software Engineering -- A Use Case Driven Approach av Ivar Jacobson. Fördelen med en sådan metodik är bl.a. att den dokumenterar den tänkta standardens användning i användares språk och termer. Principen illustreras i figuren nedan. Användare 1 Består av Objekttyp 1 Känner till Ärver från Objekttyp 2 Användningsfall 1 Användningsfall 2 Objekttyp 3 16

17 Figur 11 - Ur användningsfall kan begreppen identifieras Det finns flera verktyg på marknaden som hanterar användningsfall och därur härledda modeller med spårbarhet till användningsfallen. 3.4 Testfall Olika typer av tester kan göras kopplat till en specifikation: 1. Granskning av huruvida innehållet uppfyller ställda krav och följer ramverkets regler. 2. Granskning och praktiska prov för att se att standarden innehåller komplett information för det tänkta användningsområdet. Här kan de användningsfall som tidigare nämnts utgöra specifikation. 3. Test huruvida en lösning som bygger på standarden, t.ex. en dataöverföring, fungerar korrekt. Testfall för typerna 2 och 3 ska beskrivas. Inga testfall behöver ingå i standarden men typ 3 skulle kunna göra det. Läs mer om tester och överensstämmelsevalidering på sidan Termer och begrepp Ett tillämpningsområde kan vara tämligen komplext och beröra ett stort antal olika företeelser som man måste kunna referera till utan att missförstånd uppstår. Det gäller både för dem som tar fram en specifikation och för dem som ska samverka med hjälp av specifikationen. Begrepp är vårt sätt att inordna världen genom att se likheter: Alla hus är lite olika men vi ser ändå att de har kännetecken som gör dem till just hus. Kanske är det att de alla har väggar, tak och fönster, eller att man kan bo i dem. Vi skapar själva våra begrepp och däri ligger också ett problem; det är inte säkert att vi menar samma sak bara för att vi använder samma term. De som tar fram en gränssnittsspecifikation för ett visst tillämpningsområde måste vara överens om definitionerna av de begrepp som används inom området. De måste också vara överens om vilka termer som ska användas. Resultatet av detta arbete blir en begreppsmodell där begrepp för företeelser inom området, företeelsernas egenskaper och relationerna mellan företeelserna finns med Begreppsanalys Att ta fram ett tillämpningsområdes begrepp kallas begreppsanalys. Det handlar inte endast om att identifiera och definiera begrepp, ofta handlar det om att göra en modell av verkligheten. Ibland finns inga självklara sätt att betrakta verkligheten. Just när det gäller geografiska företeelser är det påtagligt hur svårt det kan vara att välja ett betraktelsesätt. Naturen ser ju ut som den gör och det finns ingen ritning som säger hur vi ska betrakta den. Tillverkade företeelser är på det viset enklare att hantera. Det sätt man väljer att betrakta verkligheten på ligger till grund för de begrepp man behöver och där måste också begreppsanalysen börja. Analys och definition av termer och begrepp Begreppsmodell med termer, definitioner och illustrationer Terminologi för tillämpningsområdet Figur 12 - Begreppsanalys ger gemensamma begrepp och termer Begreppsmodell Begreppen kan ibland redovisas endast som en lista med termer och definitioner men genom att ett begrepp egentligen definieras av sina samband med andra begrepp är en grafisk form - en begreppsmodell - ofta att föredra. 17

18 Busslinje trafiklinje trafikerad av buss Spårvagnslinje trafiklinje trafikerad av spårvagn Trafiklinje regelbundet av färdmedel trafikerad rutt med definierad sekvens av hållplatser Tidtabell plan för avgångar för trafiklinje Beskriver trafiken för 1:1 Listar 1:M Stannar vid 1:M (Användbar för 0:M) Avgång i tidtabell planlagd händelse specificerad som den avgångstid när färdmedel lämnar viss en hållplats Gäller från 1:1 Planlagd vid 1:1 Hållplats geografisk plats där en eller flera trafiklinjer stannar Avgångstid tidpunkten när färdmedel avgår Figur 13 - Ett exempel på en begreppsmodell I praktiken måste man också tala om vilken term som ska användas för begreppet. I vissa fall finns redan utarbetade ordlistor med definitioner att tillgå. Terminologicentrum, TNC, hanterar termsamlingar för olika fackområden och andra organ kan ansvara för kataloger med beskrivna företeelser eller egenskaper. Ofta händer det dock att en begreppsdefinition inte är tillräckligt exakt eller inte riktigt stämmer. Då måste man omarbeta definitionen. Begreppsmodellen kan också vara ett bra verktyg när man systematiskt vill plocka fram och beskriva ett tillämpningsområdes alla begrepp. Det är dock viktigt att komma ihåg att den främst är ett sätt att dokumentera begreppen och att alla medel är tillåtna. För att förklara geografiska företeelser för andra verksamhetskunniga är kartor, skisser och exempel från verkligheten naturliga utgångspunkter. Begreppsmodellen ska fungera för människor som verkar i den miljö där den tänkta standarden ska användas. Analysen måste därför göras av personer som är väl förtrogna med de olika verksamheter som ska samverka. De analystekniker och beskrivningsformer som då används måste därför framförallt vara avsedda för en gruppsituation. Stanlinotationen [SN] har med sin enkelhet visat sig väl lämpad för detta och är därför den teknik som ramverket rekommenderar för begreppsmodeller. För begreppsmodeller utnyttjas vanligtvis en delmängd av notationens möjligheter. Med systematisk begreppsanalys förfinas modellen för att till slut innehålla alla de verksamhetsbegrepp som behövs inom området och kanske även en del begrepp från omgivningen. Det kan också vara nödvändigt att studera begrepp som andra använder. Det kanske redan finns begreppsmodeller för många av de begrepp man behöver. Man bör aktivt söka efter sådana modeller och därefter noggrant överväga att utnyttja dem eller åtminstone beskriva hur deras begrepp förhåller sig till de egna. Begreppsmodellen kommer att vara inblandad på många sätt i utvecklandet och användandet av en tillämpningsstandard eller annan gränssnittsspecifikation: Som analysverktyg och gemensamt språk vid avgränsning av tillämpningsområde Som gemensamt språk vid målformulering Som gemensamt språk vid beskrivning av användningsfall Som beskrivningsverktyg vid definition av verksamhetsbegreppen Som språk vid formulerandet av regler och principer Som utgångspunkt för identifiering och gruppering av företeelser Som definition när data ska tolkas vid implementation av standarden, t.ex. vid datamappning Som underlag för ordlistor för tillämpningsområdet Som tidigare nämnts görs begreppsmodellen med en viss grafisk notation - Stanlinotation. För begreppsmodeller utnyttjas vanligtvis bara en delmängd av notationens möjligheter. 18

19 Busslinje trafiklinje trafikerad av buss Spårvagnslinje trafiklinje trafikerad av spårvagn Definition av begreppet Termen som används för begreppet Trafiklinje regelbundet av färdmedel trafikerad rutt med definierad sekvens av hållplatser Tidtabell plan för avgångar för trafiklinje 1:M betyder att det måste finnas en men kan finnas flera Hållplatser som en Trafiklinje stannar vid Beskriver trafiken för 1:1 Listar 1:M Stannar vid 1:M (Användbar för 0:M) Avgång i tidtabell planlagd händelse specificerad som den avgångstid när färdmedel lämnar viss en hållplats Inverssambandet inom parentes betyder att en Hållplats är användbar för ingen, en eller flera Trafiklinjer Gäller från 1:1 Planlagd vid 1:1 Hållplats geografisk plats där en eller flera trafiklinjer stannar Avgångstid tidpunkten när färdmedel avgår Betyder att både Busslinje och Spårvagnslinje är en sorts Trafiklinje I pilens riktning läser man sambandet en Tidtabell listar en till många Avgångar 1:1 betyder att det måste finnas precis en Avgångstid för varje Avgång Figur 14 - Stanlinotationens olika uttryckssätt i en begreppsmodell Begreppsdefinition Definitionen av begreppen bör göras separerat från den grafiska modellen. Detta görs som en termförteckning. För varje term som hämtas ur modellen görs en definition. De karaktäriserande relationer som framgår av den grafiska modellen bör beskrivas i definitionen. Det går även att lägga till andra noteringar, referenser och illustrationer. Ett exempel: avgång i tidtabell planlagd händelse specificerad som den avgångstid när färdmedel lämnar en viss hållplats tidtabell plan för avgångar för en trafiklinje trafiklinje regelbundet av färdmedel trafikerad rutt med definierad sekvens av hållplatser hållplats geografisk plats där en eller flera trafiklinjer stannar Anm: En hållplats kan delas av flera trafiklinjer. Därigenom kan den användas för byte mellan dessa Ytterligare begrepp Förutom de termer och begrepp man redovisar i begreppsmodellen kan ytterligare termer för modellens begrepp eller närliggande begrepp komma upp under arbetet. Det gäller t.ex. när man börjar analysera informationsbehovet. Då kan det krävas att de begrepp som används för företeelsers egenskaper och de värden som behövs för att uttrycka dessa egenskaper. Dessa kan specificeras i begreppsmodellen. I exemplet ovan kan man t.ex. behöva tala om att en tidtabell är giltig på vardagar, lördagar respektive sön- och helgdagar. Man kan då behöva införa och definiera begreppet "veckodagstyp" och därtill definiera vad som menas med "lördag", etcetera. 19

20 3.5.5 Modelleringsgrupp för begrepp Ramverket har inte ambitionen att beskriva hur begreppsanalysen går till men arbetet bör utföras som ett grupparbete med en modelleringsledare. Gruppen bör bestå av verksamhetskunniga och åtminstone modelleringsledaren ska behärska dokumentationsmetoden och känna till hur bra definitioner skrivs. 3.6 Informationsbehov uttryckt som objekttyper Applikationsschemat är som tidigare nämnts den beskrivningsform som man enligt ISO standarderna ska använda för att uttrycka datastrukturen. I fall då strukturen är väl känd från början, t.ex. om man har en databas som man vill överföra, kan man göra applikationsschemat utifrån sina kunskaper om detta. I andra fall är det inte lika enkelt utan man måste först analysera sitt informationsbehov: objekttyper - vilka företeelser man vill kunna lagra, hämta eller överföra data om attributtyper - vilka egenskaper hos varje företeelse man vill kunna lagra, hämta eller överföra data om sambandstyper - vilka av en företeelses samband med andra företeelser man vill kunna lagra, hämta eller överföra data om Beskrivningen av objekttyperna är verksamhetens sätt att uttrycka informationsbehovet. Den ska kunna göras utan kännedom om de regler och komponenter som ISO föreskriver. Även geometri och topologi ska betraktas som egenskaper och ska därför anges som en objekttyps attributtyper. En väg kan till exempel ha en egenskap som beskriver den linje i ett referenssystem som den kan representeras av. När man anger en sådan attributtyp räcker det med att säga hur den rumsliga informationen om en företeelse ska representeras, t.ex. av en "geometrisk linje längs vägens mittlinje". Det är också viktigt att specificera vilka topologiska förhållanden som man ska kunna ta reda på, t.ex. vilka tomter som gränsar till varandra. Analys av informationsbehov Beskrivning av objekttyper som man ska kunna hantera data om, med definitioner, egenskaper, värdedomäner och samband Figur 15 Informationsanalysen ger de objekttyper som behövs Kravspecifikation Analysen av informationsbehovet syftar i första hand till att fungera som kravspecifikation vid konstruktionen av applikationsschemat. Resultatet av analysen behöver egentligen inte ingå i specifikationen men kan i praktiken ge en mera överskådlig och lättillgänglig bild av den information som applikationsschemat representerar. Även om den slutliga dokumentationen inte innehåller en separat beskrivning av objekttyperna bör dessa dokumenteras. Beskrivningen är utgångspunkten för applikationsschemat och kan användas både när detta konstrueras, testas och revideras Företeelser och egenskaper Om man tidigare har gjort en komplett begreppsmodell bör man ha täckt in alla intressanta företeelser och alla samband. Det är dock inte säkert att alla begrepp i modellen representerar företeelser som är intressanta. En del begrepp kan avspegla egenskaper (och inte företeelser) och andra kan vara intressanta endast för att förklara andra begrepp. För sambanden mellan begreppen gäller att kanske båda, bara ena eller ingen av riktningarna är intressant. Egenskaperna hos företeelserna är inte alltid lika enkla att hitta i begreppsmodellen om man inte medvetet har beskrivit dem i samband med begreppsanalysen Topologi och geometri För geografisk information kommer en informationsanalys ofta att handla om hur man ska använda topologi och geometri för att beskriva företeelser. I exemplet med linjetrafiken är det viktigt att veta hur de olika hållplatserna ligger i förhållande till varandra (topologi), det kanske är viktigt att veta var de ligger (geometriskt 20

21 läge), men det kanske inte är intressant att veta vilken väg man åker mellan hållplatserna. Dessa verksamhetsbehov ska visa sig i beskrivningen av objekttyperna Regler och detaljeringsgrad Andra aspekter är generaliseringsregler och detaljeringsgrad. I exemplet skulle det kunna handla om vilka regler som ska användas för att välja den geometriska punkt som representerar en hållplats. Det skulle kunna vara t.ex. mittpunkten eller någon annan väldefinierad punkt. Eftersom rumsliga förhållanden ses som egenskaper hos företeelser kan motsvarande objekttyp mycket väl innehålla flera rumsliga attributtyper. I exemplet skulle dessa kunna representera olika detaljeringsgrad så att en hållplats kan representeras både som en punkt och som en yta. Hållplatspunkt Hållplatsyta Figur 16 En hållplats kan representeras av både en punkt och en yta Dokumentation Informationsbehovet dokumenteras som en förteckning av objekttyper. För varje objekttyp anges dess definition och vilken information som ska finnas. Det kan göras med fri text men det är viktigt att ta upp aspekter som när informationen refererar till andra objekttyper, när det kan finnas flera förekomster av ett värde och om det finns några särskilda villkor. Ett exempel på hur en del av en objekttypsförteckning kan se ut ges nedan. Referenser till andra objekttyper har gjorts med kursiv stil. Uppräkningsbara värdedomäner har gjorts där sådana behövs. avgång i tidtabell planlagd händelse specificerad som den avgångstid när färdmedel lämnar ett visst stopp det stopp från vilket avgången gäller avgångstid uttryckt som klockslag tidtabell plan för avgångar för en trafiklinje första och sista datum då tidtabellen gäller typ av dag då tidtabellen gäller: vardag; lördag eller dag före helgdag; söndag eller helgdag lista över avgångar trafiklinje regelbundet av färdmedel trafikerad rutt med definierad sekvens av stopp ordnad sekvens av stopp lista över tidtabeller för trafiklinjen slag av trafik: buss; spårväg (frivillig) namn på trafikbolag identitet som används av trafikbolaget stopp plats längs trafiklinje där på och avstigning kan göras den trafiklinje som trafikerar stoppet den hållplats där stoppet görs hållplats geografisk plats för stopp för en eller flera trafiklinjer de stopp som hållplatsen utnyttjas för läget för hållplatsen i form av en representativ punkt utförande: stolpe; kur (frivillig) 21

22 Informationsbehovet kan även uttryckas med Stanlinotation [SN] eller UML. Detta ger en bättre överblick än enbart objekttypsförteckningen. Trafiklinje trafikslag trafikbolag identitet stannar v id 1: M (används av 1:1) Stopp beläget vid 1:1 (används som 1:M) Hållplats lägespunkt utförande Tidtabell giltighetsperiod veckodagstyp beskriv s av 1: M listar 1:M från 1:1 Avgång avgångstid Figur 17 Objekttyper i Stanlinotation Trafiklinje +trafikslag +trafikbolag +identitet används av st annar vid 1..* Stopp från används av 1..* belä get vid Hållplats +lägespunkt +utförande beskrivs av 1..* Tidtabell Avgång +gilt ighet speriod +veckodagstyp listar 1..* +avgångstid Figur 18 Objekttyper i UML Skillnaden mellan att använda den ena eller andra notationen är inte så stor utan handlar mera om vilka verktyg man har tillgång till Modelleringsgrupp Informationsbehovsanalysen bör göras av verksamhetskunniga personer och tanken är att man inte ska behöva vara insatt i reglerna för hur man gör ett applikationsschema. Man ska t.ex. inte behöva känna till hur geometri och topologi uttrycks enligt ISO Faran med att utgå från t.ex. standardschemat för rumslig representation [19107] är att man då lätt kan underlåta att specificera vilka faktiska informationsbehov man har. Om objekttyperna förmår uttrycka informationsbehovet fullständigt kan applikationsschemat tas fram av experter på ISO De definitioner som använts för objekttyperna kan vanligtvis direkt överföras som definitioner i applikationsschemat Kataloger Det finns kataloger över både objekttyper och värdedomäner. Feature and Attribute Coding Catalogue (FACC) från Digital Geographic Information Working Group (DGIWG) är ett exempel på en sådan katalog. När man ska definiera en objekttyp eller en värdedomän är det självklart en hjälp att utgå från en färdig definition. Det som är viktigt är dock att granska att den definition av en objekttyp som ges i katalogen är i överensstämmelse med den som gjordes under begreppsanalysen. 22

23 Samma sak gäller värdedomäner. En värdedomän i katalogen består av en lista med definierade värden och koder. Förutom att granska definitionerna bör man dokumentera det urval av värden som gäller för den aktuella attributtypen Metodik Det finns ingen entydig väg att analysera informationsbehovet men nedanstående metod ger en fingervisning om hur man kan gå till väga: 1. Gå igenom begreppsmodellens begrepp och identifiera de företeelser man vill hantera data om. Dessa blir objekttyper. Notera att de ska kunna ses som företeelser, inte vara egenskapen hos någon företeelse. 2. Gå därefter igenom sambanden mellan de begrepp som givit objekttyperna. I vissa fall ska sambandet vara enkelriktat eller inte alls finnas med mellan objekttyperna. 3. Gå igenom objekttyperna och identifiera de egenskaper som det ska gå att ha data om. Dessa blir attributtyper. Vissa av begreppen i begreppsmodellen kan motsva sådana egenskaper, men de finns oftast inte alls med. Attributtyper kan anges utan att man talar om en viss värdedomän eller datatyp. Ett undantag är när en attributtyp kan anta ett av flera värden i en uppräkningsbar värdedomän. Då kan man ange värdedomänen genom att lista möjliga värden eller ange en referens till en standardiserad katalog. 3.7 Applikationsscheman Beskrivningen av objekttyperna avspeglar våra krav på information: vad vi vill kunna lagra som och läsa ut ur data. Applikationsschemat är den formella beskrivning som ISO föreskriver. Det ska kunna användas både för att visa hur data ska struktureras och representeras och för att tolka och förstå data. Det ska dessutom kunna användas för att generera överföringsformat. Applikationsschemat konstrueras utifrån de verksamhetsbehov som finns uttryckta i objekttyperna. Med konstruktion menas att det är en ganska väldefinierad process. Hur applikationsscheman konstrueras beskrivs utförligare i kapitel 5 på sidan ISO I applikationsschemat ingår även kopplingar till ISO standardernas standardscheman för representation av rums- och tidsaspekter samt metadata. Eftersom reglerna föreskriver att dessa standardscheman ska användas krävs kunnande och erfarenhet för att översätta kraven till ett applikationsschema. ISO anger ett antal regler för hur ett applikationsschema ska konstrueras. Handboken har ambitionen att göra dessa regler mer lättbegripliga. Standardscheman: Geometri Topologi Tidsaspekter Metadata Kvalitet Regler för applikationsscheman Konstruktion av datastruktur genom tillämpning av standardscheman Applikationsschema som UMLpaket med klasser, attribut, datatyper och relationer Utökningsregler för utökning av struktur och specifikation av värdedomäner Figur 19 Applikationsschemat konstrueras enligt regler och föreskrivna standardscheman Applikationsscheman görs med UML:s klassdiagram enligt principer som beskrivs i [19103] och [19109]. För att göra applikationsscheman krävs inte bara goda kunskaper i UML-modellering utan även kunskap om dessa principer och de föreskrivna standardschemana. 23

24 3.7.2 Utökningsregler I många fall innehåller inte applikationsschemat alla detaljer utan är tänkt att behöva anpassas och utökas. Då bör även detta beskrivas. Anpassningar kan vara att värdedomäner ska kunna definieras i efterhand. Om ett applikationsschema beskriver träden i en park vill man kanske ha möjlighet att ange olika arter. Men listan med arter kommer troligtvis att förändras med tiden och det bör finnas regler för hur det görs. En annan anpassning kan vara en ren utbyggnad, eller specialisering, av applikationsschemat. Antag att applikationsschemat är gjort så att det beskriver parker men inte säger något om vilka företeelser, t.ex. träd, som kan finnas i parken. Då måste man ha något sätt att modellera in olika företeelser och de datauppgifter man ska kunna ha om dem. 3.8 Modeller för olika lösningar Krav på vilken teknisk lösning som gränssnittsspecifikationen ska specificera har eventuellt ställts i målmodellen. En beskrivning ska i så fall tas fram för att mer direkt stödja den tekniska interoperabiliteten hos de system som ska utnyttja gränssnittsspecifikationen för samverkan. Resultatet, t.ex. ett XML-schema för dataöverföring, ska då ingå i gränssnittsspecifikationen. Ett av syftena med applikationsschemat är att kunna användas för att generera till exempel syntaxen för ett överföringsformat, klasspecifikationerna i ett program eller tabellerna för en databas. Namn i applikationsschemat kan då användas för att bilda namn på typer, tabeller, fält, element, attribut, etc. Generering av teknisk lösning Överföringsformat i form av XML-schema Figur 20 Ett XML-schema ska kunna genereras från applikationsschemat På sidan 61 beskrivs utförligt hur det går till för att göra en kodningsspecifikation i form av ett s.k. XMLschema. 24

25 4 Kvalitetssäkring, test och verifiering Detta kapitel beskriver hur man ska kunna avgöra att en gränssnittsspecifikation, t.ex. en tillämpningsstandard, uppfyller de krav som det tekniska ramverket ställer på den, samt hur man ska kunna avgöra om ett system som bygger på specifikationen också uppfyller denna. 4.1 Överensstämmelsekrav ISO (Conformance and testing) Metoder för bestämning av överensstämmelse Tekniskt ramverk för geografisk information Regler och anvisningar i denna handbok Svensk standard ISO 191xx Innehåller kapitel om hur man avgör överensstämmelse - Conformance - Abstract Test Suite Överensstämmer med En tillämpningsstandard (eller annan gränssnittsspecifikation) Ett system byggt på en tillämpningsstandard (eller annan gränssnittsspecifikation) Figur 21 - Överensstämmelse på olika nivåer Överensstämmelsekrav i ISO standarder ISO (Conformance and testing) beskriver metoder för bestämning av överensstämmelse. Standarden innehåller de krav som ställs på andra standarder vad gäller test av överensstämmelse: Varje ISO standard ska ha ett kapitel benämnt "Conformance". Detta hänvisar till en "Abstract test suite" (ATS) som vanligtvis är en checklista som man ska gå igenom för att avgöra om en produkt, t.ex. en tillämpningsstandard, uppfyller kraven i just denna ISO-standard. Ibland finns det olika "Conformance classes" beskrivna. En "Conformance class" avser en viss aspekt eller delmängd av standarden. Till varje sådan hör en ATS Överensstämmelse med tekniskt ramverk När man tar fram en gränssnittsspecifikation som man påstår stöder ISO menar man alltså att berörda standarders ATS är genomgångna med positivt resultat. För övriga delar i ramverket ska motsvarande krav återfinnas i handboken. För att åstadkomma att överensstämmelse råder måste man under specifikationsarbetets gång utföra vissa kvalitetssäkrande aktiviteter. Dessa beskrivs nedan. 25

26 4.1.3 Överensstämmelse med en gränssnittsspecifikation Det kan vara svårt att avgöra om en tillämpning eller ett system som bygger på en gränssnittsspecifikation överensstämmer med standarden. Ett typiskt sådant system innehåller mappning till och från interna data och generering och tolkning av XML-data. Överensstämmelse kommer att kunna valideras i vissa fall: Om gränssnittsspecifikationen innehåller ett XML-schema kommer bristande överensstämmelse med XML-data automatiskt att kunna detekteras. Om det i applikationsschemat finns restriktioner uttryckta i OCL-kod eller på annat sätt, kommer sådana datafel att kunna detekteras om dessa restriktioner är implementerade som programkod. Om semantiken hos interna data är väl beskriven kommer man vid mappningen att kunna verifiera att betydelsen av olika datauppgifter överensstämmer. Vid behov måste transformeringar och kodkonverteringar göras. 4.2 Kvalitetssäkring vid specifikationsarbetet Enligt SS-ISO 8402 definieras kvalitetssäkring som alla planerade och systematiska åtgärder nödvändiga för att ge tillräcklig tilltro till att en produkt kommer att uppfylla givna krav på kvalitet. Att ta fram en gränssnittsspecifikation för ett visst verksamhetsområde är ett omfattande arbete både när det gäller tid och personresurser. Specifikationen får inte vara för vag eller tvetydig. Modellerna som tas fram måste vara syntaktiskt korrekta enligt det beskrivningsspråk man har valt och modellernas riktighet ska vara verifierad genom funktionstester. Modellerna får inte kollidera med de standardiserade delmodeller som de ska integreras med eller använda det tekniska ramverket på ett felaktigt sätt. Också mellan applikationsscheman från olika verksamhetsområden finns risker för kollisioner och överlappning. Sammantaget innebär detta att en arbetsmetodik måste användas som underlättar att korrekta och funktionsdugliga applikationsscheman tas fram. Arbetsmetodiken innebär kontroller som genomförs kontinuerligt under arbetets gång. Det ska ingå i planeringsarbetet för att ta fram ett applikationsschema att fastlägga vilka kontroller som ska göras och vid vilka tidpunkter dessa ska utföras samt vem som ska utföra kontrollerna. Kontrollerna ska vara systematiskt utförda och väl dokumenterade. Handboken har ambitionen att fastlägga en miniminivå för kvalitetssäkring samt att tillhandahålla ett underlag till checklistor som kan användas vid kontroller. Beskrivningen och checklistorna kommer dock inte att vara fullständiga. Komplettering kommer att ske alltefter kvalitetssäkringsrutinerna testas i praktiskt arbete. 4.3 Beskrivning av kvalitetssäkringsrutiner Ansvar och roller Specifikationsarbetet förutsätts underkastat någon typ av projektledning. För standardiseringsprojekt är detta en teknisk kommitté. Nya aktiviteter startas efter beslut av projektledningen som sedan fortlöpande följer upp arbetet i aktiviteten. För varje aktivitet ska en kvalitetssäkringsansvarig utses. Den kvalitetssäkringsansvarige deltar inte i det egentliga arbetet utan har till uppgift att se till att de rutiner som finns för kvalitetssäkring följs på ett korrekt sätt att delta i genomförandet av kontrollerna att vid behov tillsammans med aktivitetsansvarig föreslå korrigerande åtgärder att dokumentera genomförda kontroller samt att avrapportera till projektledningen Metoder Kvalitetssäkring ska innebära att en aktivitets resultat ska granskas med avseende på om uppsatta kvalitetsmål uppnås. Granskningen ska vara oberoende och formell. Detta kan man uppnå genom att en särskilt ansvarig för kvalitetssäkring utses och att utomstående och oberoende personer används vid granskningen. Alla avvikelse från uppsatta mål samt vilka korrigerande åtgärder som ska vidtas ska dokumenteras. Granskningen kan utföras med ett antal olika metoder. Vanliga metoder är: 26

27 remiss, till expertgrupp eller till bredare grupp av intressenter granskningsmöte med referenspersoner, olika sammansättning beroende på vad syftet med granskningen är tester, prototyper, för att testa funktionsduglighet pilotförsök för att testa användbarhet. Olika metoder lämpar sig för olika typer av granskning och vid olika tillfällen i arbetsprocessen. Se exempel nedan Lämpliga rutiner för kvalitetssäkring Lämpliga tidpunkter för kvalitetssäkring är vid naturliga avstämningspunkter i arbetet. Dessa beskrivs i kapitlet En utvecklingsprocess för gränssnittsspecifikationer på sidan 13. Efter etappen målanalys behöver följande granskningar göras: mot tekniskt ramverk, görs som seminarium och eventuell remiss till intressenter terminologigranskning avstämning mot projektledningen genom granskningsmöte Efter etappen begreppsmodellering behöver följande granskningar göras: mot det tekniska ramverket mot begreppsmodeller för andra verksamhetsområden terminologigranskning teknisk granskning av modellen, granskningsmöte med modelleringsexperter logisk granskning av modellen, granskningsmöte med modelleringsexperter och verksamhetskunniga avstämning mot projektledningen bredare remiss bland intressenter. Efter etappen informationsbehovsanalys behöver följande granskningar göras: mot det tekniska ramverket mot begreppsmodellen teknisk granskning av modellen, granskningsmöte med modelleringsexperter logisk granskning av modellen, granskningsmöte med modelleringsexperter och verksamhetskunniga avstämning mot projektledningen bredare remiss bland intressenter. Efter etappen applikationsschemautveckling behöver följande granskningar göras: mot det tekniska ramverket mot informationsmodellen mot applikationsscheman för andra verksamhetsområden teknisk granskning inklusive funktionstest, granskningsmöte med modelleringsexperter logisk granskning, granskningsmöte med modelleringsexperter och verksamhetskunniga bredare remiss bland intressenter granskning av utformning, remiss till sekretariatet. Vissa av ovanstående moment kan vid behov lämpligen föras ihop till en granskning som då omfattar fler syften; till exempel kan teknisk och innehållsmässig granskning utföras i samma moment. 27

28 4.4 Exempel på checklistor Terminologikontroll Alla termer väsentliga för förståelsen av dokumentet ska förekomma i definitionsavsnittet. Samma term ska användas för ett bestämt begrepp genomgående i hela dokumentet. En term får inte stå för flera olika begrepp inom dokumentet. En term ska skrivas på samma sätt i hela dokumentet. Termen ska alltid skrivas på det sätt som den står i definitionsavsnittet; vill man använda en kortform eller förkortning så ska denna vara angiven som huvudterm för begreppet i definitonsavsnittet. Alla termer som förekommer i definitionsavsnittet ska också återfinnas i texten i dokumentet. En term ska ha samma betydelse i hela gruppen av samhörande standarder. Definitionsavsnittet ska skrivas i enlighet med SS-ISO Kontroll mot det tekniska ramverket Det tekniska ramverket skall användas. Används det tekniska ramverket i tillämpliga delar? Syfte och omfattning Är syfte och omfattning beskrivet enligt det tekniska ramverket? Begreppsmodell Överensstämmer begreppsmodellens avgränsning med syfte och omfattning? Används begreppsmodellens grafiska språk på ett korrekt sätt? Är förteckningen över begreppens termer och definitioner korrekt utformad? Överensstämmer innehållet i denna förteckning med den grafiska redovisningen? Applikationsschema Överensstämmer applikationsschemats avgränsning med syfte och omfattning? Överensstämmer applikationsschemats innehåll med informationsmodellen? Är UML-diagrammen korrekt utformade? Checklista för kontroll av modeller Följande aspekter skall utvärderas av en neutral granskningsgrupp. Checklistan baseras på kapitel 5 - Modelleringsprinciper - ur Schencks och Wilsons bok. Listan är tillämpbar på applikationsschemat. Läsbarhet - är modellen utformad för att läsas av människor? Syfte - är de definierade syftena och antagandena för de olika modellerna i överensstämmelse med syftet för helheten? Nym -principen - har principen med ett namn, en betydelse, en definition följts? Se upp för synonymer och homonymer! Sammanhangsoberoende - är alla objekttyper definierade så oberoende av det aktuella sammanhanget som möjligt? Om objekttypen är intressant i fler än ett sammanhang skall den inte ha några restriktioner som beror av sammanhanget. 28

29 Implementationsoberoende - är modelldeklarationen inriktad på vad och inte på hur, d.v.s. inrikta inte modellen på effektivitet vid dataöverföring eller implementering. Invarians - betydelsen av en objekttyp skall inte bero på dess attributvärden. Restriktioner - är attributtypernas och sambandstypernas värdedomäner ändamålsenligt begränsade? Detta kan åstadkommas med hjälp av modellens struktur, lokala och globala regler eller genom funktioner. Verklighet - överensstämmer de deklarerade objekttyperna med verkligheten? Redundans - finns det redundans som kan leda till möjlig tvetydighet på förekomstnivå? Begrepp - är det de underliggande begreppen som har uttryckts? Representationen och syntaxen skall inte modelleras utan det finns säkert ett bakomliggande begrepp. Attributtyper som är frivilliga kan tyda på att det är en olämpligt utformad objekttyp. Specialiseringar - placera attributtyper som behövs för subtyper så högt i hierarkin som möjligt. Använd inte specialiseringar i stället för aggregering. Kom ihåg att en objektförekomst av en subtyp också är en objektförekomst av supertypen. Enkla datatyper - har attributtyperna korrekta värdedomäner? 29

30 5 Att konstruera ett applikationsschema I ISO finns ett centralt begrepp - application schema - som här kallas applikationsschema. Ett applikationsschema beskriver på ett formellt sätt vilka uppgifter som ska kunna finnas om vissa geografiska företeelser. I applikationsschemat visas den logiska strukturen hos data men inte hur det fysiskt är kodat i t. ex. ett XML-dokument. Ett applikationsschema ska vara tillräckligt innehållsrikt för att man ska kunna generera t.ex. ett XMLschema. Det ska även vara tillräckligt innehållsrikt för att kunna användas vid informationsöverföring. Det betyder att det ska innehålla, eller referera, de begreppsmässiga definitioner som behövs för att entydigt tolka data som någon annan har sänt. 5.1 UML och regler För att ett applikationsschema ska bli en otvetydig och motsägelsefri beskrivning används ett formaliserat modelleringsspråk - UML. Dessutom finns vissa tillämpningsanvisningar i [19103], ISO/TS Conceptual Schema Language. Det behövs vissa grundläggande kunskaper i UML för att man ska kunna följa reglerna i kapitlet och för att man överhuvudtaget ska kunna få ut något av de UML-modeller som finns i ISO serien. I [19103] finns kortfattade förklaringar till termer och symboler som används men det är därmed inte sagt att denna kunskap är tillräcklig. Det här kapitlet handlar om de regler som man måste följa när man gör ett applikationsschema. Reglerna finns dels för att andra lättare ska kunna förstå och utnyttja schemat, dels för att det senare ska kunna användas till att generera XML-scheman eller andra typer av lösningsberoende format. Ibland tillåter reglerna att man gör på flera sätt och då diskuteras när det ena eller andra sättet är lämpligt. 5.2 Modelleringsverktyg Ett applikationsschema måste tas fram med ett modelleringsverktyg för UML. Verktyget måste ha möjlighet att: Importera modeller i XMI-format, ett öppet format för bl.a. UML-modeller. Detta är nödvändigt för att man ska kunna använda de modeller som hör till ISO standarderna. Spara modellerna i XMI-format. Dessa filer ska kunna användas dels när man vill flytta modellerna till ett annat verktyg, dels när man ska generera kod, t.ex. för att göra XML-scheman. Spara text och bilder från verktyget i öppna digitala format så att dessa kan ingå i publikationen för tillämpningsstandard eller motsvarande dokumentationen. 5.3 Applikationsscheman är paket En gränssnittsspecifikation kan innehålla ett eller flera applikationsscheman. Uppdelningen i flera scheman görs utifrån vad som verkar praktiskt. Varje applikationsschema modelleras som en uppsättning s.k. paket som i sin tur består av ett klassdiagram och referenser till andra paket, som även de kan vara applikationsscheman. Om definitioner dokumenteras i en yttre katalog ska en referens till katalogen anges. Om verktyget tillåter görs detta med en UML-not (note) kopplad till berörda paket eller klasser. 30

31 <<Application Schema>> Fornlämningar Applikationsschemapaket som... innehåller ett applikationsschema i form av ett klassdiagram och utnyttjar klasser i andra paket Paket med geometriklasser Lämning +id:integer +position:gm_point Gravfält Runsten +inskrift:characterstring Grav Figur 22 - Applikationsschemapaket Ett applikationsschemapaket ska ha: Ett formellt, beskrivande namn. En versionsbeteckning som ska återfinnas i paketets dokumentation. För varje applikationsschema definieras även ett prefix bestående av två versaler. Prefixet används för att namnge klasser i applikationsschemats paket. Det kan också vara klokt att undvika å, ä och ö i namn och identifierare eftersom vissa verktyg kan ge problem med dessa. Om applikationsschemat ska spridas internationellt bör man använda engelska. Detta gäller för övrigt alla namn och andra identifierare i ett applikationsschema. 5.4 Att utnyttja standardscheman När ett applikationsschema tas fram bryts ofta arbetet ner i flera oberoende delar som kan sammanfogas via ett centralt applikationsschema. Varje sådan del är ett paket. Standardschemana i ISO är andra paket. Den fullständiga definitionen av den logiska datastrukturen för en viss tillämpning består av applikationsschemana integrerade med de standardscheman som direkt eller indirekt åberopas. Figur 23 visar ett exempel på ett applikationsschema som använder element ur scheman som definieras i andra av seriens standarder. Beroendena i figuren betyder att applikationsschemapaketet använder strukturer och definitioner från övriga paket. 31

32 Applikationsschemapaket har klasser som motsvarar företeelser och egenskaper <<Application Schema>> namn på applikationsschema Standard-paket med klasser för olika typer av egenskaper hos företeelser. DQ_xx använder klasser från... I noten anges vilka klasser som används Geometri ISO Tid ISO Kvalitet ISO Figur 23 - Exempel på paketdiagram En gränssnittsspecifikation ska innehålla ett eller flera paketdiagram som med beroendepilar visar hur applikationsschemana använder definitioner ur standardscheman eller andra paket. Visa gärna med UML-noter vilka klasser eller datatyper ur respektive modell som används. 5.5 Användning av andra applikationsscheman i ett applikationsschema En tillämpningsstandard består ofta av flera applikationsscheman där ett av dem utgör det centrala schemat. Vart och ett av applikationsschemana kan åberopa standardscheman. Denna organisation av scheman kan användas för att undvika byggandet av stora och komplexa modeller. Figur 24 visar ett exempel som åskådliggör att en tillämpning som innehåller vägar, floder och broar kan beskrivas genom följande tre UML-paket: ett centralt applikationsschema som beskriver broarna ett använt applikationsschema som definierar vägar ett använt applikationsschema som definierar floder. Vart och ett av applikationsschemana använder geometriska primitiver definierade i standardschemat som ingår i standarden ISO Rumslig modell. 32

33 <<ApplicationSchema>> Broar I noten anges vilka klasser som används Flod Väg <<ApplicationSchema>> Floder GM_Point GM_Curve <<ApplicationSchema>> Vägar GM_Curve Geometri ISO GM_Curve Figur 24 - Ett applikationsschema som baseras på andra applikationsscheman 5.6 Modellering av objekttyper När man skapar ett klassdiagram för ett applikationsschema utgår man från de objekttyper som man identifierat under informationsbehovsanalysen. I princip modelleras varje objekttyp som en klass i applikationsschemats klassdiagram. 5.7 Namnregler När applikationsschemat skapas utgår man från resultatet från informationsbehovsanalysen. Namnen väljs enligt nedanstående tabell där AZ avser det prefix som valts för applikationsschemat. Modellelement UML-representation Stereotyp Namnregel för UML-representation Objekttyp (med ursprung i en företeelse) Attributtyp (med ursprung i en egenskap) Klass ingen AZ_Namn, där Namn skrivs med inledande versal. Namn ska associera till företeelsen och bör vara samma som namnet på objekttypen om inte översättning till engelska görs. Attribut -- attributnamn, skrivet med inledande gemen. Sambandstyp Relation -- rollnamn, skrivet med inledande gemen. Egendefinierad datatyp Uppräkningsbar värdedomän Utvidgbar värdedomän Typer för rumsoch tidsaspekter Klass <<DataType>> AZ_Namn Klass <<Enumeration>> AZ_Namn Klass <<CodeList>> AZ_Namn Klass <<Type>> AZ_Namn 33

34 5.8 Modellering av specialisering En specialisering av en objekttyp modelleras som arv med pilen riktad från subtypen mot supertypen. Specialiseringar blir arv mellan klasserna. I exemplen nedan är objekttyperna representerade i Stanlinotation. Busslinje (BusLine) Trafiklinje (TrafficLine) XX_TrafficLine +type:xx_traffictype +... Spårvagnslinje (TramLine) +... XX_BusLine +... XX_TramLine Figur 25 - Specialisering utfört som arv Olika typer av specialiseringar av objekttyper i informationsmodellen utförs på olika sätt i applikationsschemat. Nedanstående exempel visar s.k. uttömmande specialisering. Mark ska antingen vara Allmän mark eller Privatmark. Den klass som supertypen Mark ger upphov till ska då göras abstrakt, d.v.s. några objekt som är av klassen XX_Land kommer aldrig att kunna skapas utan den tjänar endast som en klass att ärva från. Allmän mark Uttömmande XX_CommonLand Abstrakt Mark XX_Land Privat mark XX_PrivateLand Figur 26 - Uttömmande specialisering ger en abstrakt klass Vid multipel specialisering, då två eller flera specialiseringar samtidigt kan gälla, kan man utnyttja UMLrestriktionen {overlapping} för berörda arvspilar. Andra regler uttrycks i text eller i UML:s regelspråk OCL, och anges i noter knutna till det UML-element som regeln avser. 5.9 Modellering av samband Sambandstyper mellan objekttyper modelleras som olika associationer mellan klasserna. Man måste tillföra kunskap som inte alltid framgår av sambandstyperna: hur objekttyperna "känner till", "bestämmer över" och "består av" varandra. Man får också välja bort sambandstyper som finns mellan objekttyper om samma information kan fås på ett annat sätt. 34

35 Delar hållplats med 0:M Informationsbehovet är att kunna tala om vilka Trafiklinjer som delar Hållplats och vilka Hållplatser som en viss Trafiklinje stannar vid. Trafiklinje (TrafficLine) Stannar vid 1:M Hållplats (Stop) Om det finns data om vilka Trafiklinjer som stannar vid en viss Hållplats kan vi välja att detta räcker för att få fram informationen. XX_TrafficLine line * XX_Stop Figur 27 - Associationer väljs efter den logiska datastruktur man vill ha En sambandstyp som innebär helheten består av självständiga delar modelleras som aggregering (tom diamant). Det betyder att delarna fortsätter existera oberoende av om helheten existerar. XX_BusLine XX_BusStop Informationen om de hållplatser som en busslinje utnyttjar försvinner inte om informationen om linjen tas bort. De kan ju t.ex. utnyttjas av någon annan linje. Figur 28 - Exempel på aggregering En sambandstyp som innebär består av och där delarna upphör att existera samtidigt med helheten modelleras som komposition (fylld diamant). XX_Building XX_Room Om informationen om en byggnad tas bort tas också informationen om dess rum bort. Figur 29 - Exempel på komposition En klass som en annan klass måste "känna till" tilldelas ett rollnamn på associationen mellan dem. Rollnamnen inleds med liten bokstav. Rollnamnet ska vara unikt för den klass som finns i andra änden av associationen. Rollnamnet får inverkan på kodningen av data; om XML används blir rollnamnet en XML-tagg. 35

36 Måste vara olika KlassA KlassB KlassC KlassD rolla rollb rollb rollc rollz Får vara lika Den roll som KlassA spelar för KlassB Pilen visar att KlassC inte behöver känna till KlassD. Därför behövs ingen roll. Figur 30 - Rollnamn Ett verb kan i klassdiagrammet ge namn på associationen och ges en läsriktning, från ena klassen till den andra. Detta ger en tydligare dokumentation men får ingen inverkan på kodningen av data. XX_BusLine line Stops at > stop XX_BusStop Verb och läsriktning Figur 31 - Namn på associationen ger bättre dokumentation 5.10 Modellering av attributtyper En attributtyp hos en objekttyp ska i applikationsschemat modelleras med en attributdefinition för klassen. En attributdefinition består av attributnamn och datatyp. Datatypen kan vara av olika slag: En primitiv datatyp, se tabell. En standardiserad datatyp hämtad från standardschemana, t.ex. för topologi eller tidsaspekter. En återanvändbar datatyp hämtad från ett annat paket. En egendefinierad datatyp i aktuellt paket. Datatyp Förklaring Exempel Integer Positivt eller negativt heltal 37; Decimal Exakt decimaltal 2,5; -9999,999 Real Reellt tal, kan vara avrundat 3, ; 2,99E10; -9,81 Vector En uppsättning tal av någon av ovanstående ( ); (12,7 88-4, ) typer CharacterString Text, även med internationella tecken och "räksmörgås" accenter Date Datum enligt ISO Time Tidpunkt enligt ISO :30:59; 18:30:59+01:00 DateTime Datum och tid enligt ISO :03:12 Boolean Boolskt värde true, false Logical true, false, maybe Propability Sannolikhet mellan 0,0 och 1,0 0,34 Tabell 1 Tabell över tillåtna primitiva datatyper 36

37 Egendefinierade datatyper görs som klasser av en av följande stereotyper: Kännetecken för datatypen Värdena går att räkna upp och alla värden är kända. Värdena går att räkna upp men nya värden kan tillkomma senare. Värdena är en strukturell sammansättning av flera värden av andra datatyper. XX_ Building +id:xx_propertyid +owner:xx_owner Egendefinierad datatyp för återanvändning och strukturering. <<DataType>> XX_ PropertyID +reg:xx_authority +area:xx_areacode +uid:integer Stereotyp CodeList Enumeration DataType Egendefinierad datatyp för att kunna lägga till ett attribut (checked) på ett attribut (owner). <<DataType>> XX_ Owner +owner:characterstring +checked:boolean För en klass som motsvarar en objekttyp behöver ingen stereotyp anges <<Enumeration>> XX_ AreaCode <<CodeList>> XX_ Authority Fler värden får inte läggas till i listan utan att applikationsschemat ändras +Götaland=1 +Svealand=2 +Norrland=3 Listan behöver inte vara komplett. +LMV +VV +SCB Figur 32 - Illustration av klasser för egendefinierade datatyper En datatyp för en attributtyp som i sig har egenskaper behövs t.ex. om man vill ange ett mått och samtidigt ange vilken enhet och vilken noggrannhet måttet har eller om man vill ange status på ett värde. Då ska ska en klass skapas med ett första attribut som har samma namn som klassen. Övriga attribut motsvarar detta första attributs egenskaper. I figuren exemplifieras detta av klassen XX_Owner som kan ha status kontrollerad eller inte kontrollerad (checked). I ISO finns också tre s.k. collection types: Typ Förklaring Exempel Kommentar till exemplet Set Bag Sequence Ett antal värden av samma typ. Ordningen har ingen betydelse. Duplikat får inte förekomma. Ett antal värden av samma typ. Ordningen har ingen betydelse. Duplikat får förekomma. En följd av värden av samma typ. Ordningen har betydelse. Duplikat får förekomma. Set<Colour> Bag<Decimal> Anger vilka färger som finns i en flagga. Anger ett antal ph-mätvärden, t.ex. ph-värdet i en sjö. Sequence<Stop> Anger vilka hållplatser som ligger utefter en busslinje och i vilken ordning de ligger. För s.k. rumsliga attribut kan istället en association till ett rumsligt objekt användas. Se även kapitel 6. 37

38 5.11 Datatyper från standardscheman En genomgående regel för konstruktion av applikationsscheman är att man alltid ska utnyttja klasser från de standardscheman som finns. Det finns regler för hur man ska göra detta för olika slags attributtyper: För geometri, använd alltid standardschemat i [19107]. För topologi, använd standardschemat i [19107], använd associationer mellan de klasser som representerar företeelserna eller beräkna topologin utifrån geometrin. Se även sidan 47. För tidsaspekter, använd standardschemat i [19108] om ett referenssystem krävs. I andra fall kan de primitiva datatyperna Date, Time och DateTime användas. För lägesredovisning med geografiska identifierare, använd SI_LocationInstance från [19112]. Se även sidan 52. För kvalitet och andra metadatauppgifter får klasser från standardschemat i [19115] användas. Se även sidan 58. Figur 33 visar ett exempel på ett applikationsschema hämtat från [19109]. Det är konstruerat med datatyper från andra standardscheman, primitiva datatyper eller egendefinierade datatyper. PropertyParcel + identification : PropertyID + name : CharacterString + area : TP_Face +contains 0..* Building + code : Integer + centerpoint : Position + shape (0..1) : GM_Curve + address : SI_LocationInstance + type : BuildingType=Private + owner : CI_ResponsibleParty Position + position : GM_Point + horizontalaccuracy : DQ_AbsoluteExternalPositionalAccuracy + verticalaccuracy : DQ_RelativeInternalPositionalAccuracy +financed 0..* <<Enumeration>> BuildingType + Private + Public <<Data Type>> PropertyID + municipalityno : Integer + number : Integer Loan + amount : Real + classification : MD_LegalConstraint + period : TM_Period Figur 33 - Exempel på ett applikationsschema 5.12 Typoberoende representation Den metod som ISO föreskriver innebär att olika typer av företeelser som hör till något avgränsat tillämpningsområde modelleras explicit för detta tillämpningsområde. Exempel på sådana företeelser är tunnel, bro, skyddsområde, servitut. Det betyder att företeelser med likartade egenskaper klassificeras som objekttyper vilka namnges, tilldelas attributtyper och relateras till varandra genom sambandstyper. Från objekttyperna skapas ett applikationsschema för tillämpningsområdet. Vid informationsöverföring, t.ex. i form av XML-dokument, bildas dataförekomster av de objekttyper som definierats. Mottagaren kan identifiera de 38

39 olika objekttyperna i XML-dokumentet. Med hjälp av applikationsschemat och dess definitioner kan ett tillämpningsprogram konstrueras. Detta kan då tolka innehållet i dokumentet. Ett problem med applikationsscheman är att de riskerar att relativt snart bli inaktuella. När behov av någon ny objekttyp uppstår eller av att någon befintlig objekttyp behöver förändras med t.ex. ett nytt attribut måste det standardiserade applikationsschemat omarbetas och ges ut i ny version. Beroende av systemdesign kan modifieringen av befintliga programvaror bli relativt omfattande. För att undvika detta problem kan en typoberoende objektmodell användas När applikationsschemat utvecklas behöver man inte känna till alla de objekttyper som kan komma att behöva hanteras av ett tillämpningsprogram. Den svenska standarden "Generisk representation av geografiska företeelser" [06] visar hur detta kan göras. Den typoberoende objektmodellen kan således inte specificera data längre än att säga att en datamängd innehåller objekt. Vi kan säga att datamängden innehåller en typoberoende representation. På datanivå kan vi inte åtskilja objekten med avseende på objekttyp. För att kunna göra det och därigenom kunna tolka informationen behövs en katalog över alla objekttyper som ska kunna hanteras. Utifrån en sådan katalog skulle ett mottagande och tolkande tillämpningsprogram kunna konstrueras. Genom att göra katalogen maskinläsbar skulle programmet till och med kunna förändra sitt beteende när katalogens innehåll uppdateras. Modellen för en sådan katalog beskrivs i [06]. Objekttypskatalogen kan även använda sig av namn, koder och definitioner ur någon extern klassificeringskälla. Exempel på sådana är FACC (Feature and Attribute Coding Catalogue från DGIWG) och KF85 (Kartdatabanken, Svenska kommunförbundet). Den typoberoende objektmodellen kan användas självständigt för att representera geografiska företeelser, men kan också användas tillsammans med ett applikationsschema. Genom användningen av en typoberoende objektmodell och objekttypskataloger ges möjlighet att enklare lägga till och förändra objekttypers definition. När användningen ställer krav på en specifik och över tiden stabil objektrepresentation bör ett specifikt applikationsschema definieras. När frekventa förändringar i objekttypsbeståndet kan förväntas och tillåtas kan en typoberoende representation användas. Datautbytet kan då göras mindre känsligt för förändringar. Tillämpningar som baseras på den typoberoende objektmodellen blir till stora delar datadrivna. Enklare tilllämpningar som enbart syftar till att presentera data behöver inte byggas om allteftersom nya objekttyper dyker upp. Alla objekttyper hanteras på samma sätt och vid påträffandet av en ny objekttyp görs vid behov en uppslagning i objekttypskatalogen för att erhålla specifika uppgifter om den nya objekttypen. Det finns heller ingenting som förhindrar att tillämpningar som bygger på en typberoende objektmodell kan leverera sina data enligt den typoberoende modellen eller vice versa. När en del av en tillämpning utvecklas och en typoberoende objektmodell ligger till grund för utvecklingen kan den inte vid utvecklingstillfället anpassas för att hantera specifika objekttyper. Det är först när tillämpningen körs och förses med data som den vet vilka objekttyper som ska hanteras. Förfarandet kallas för sen bindning (jämför eng. late binding). Om däremot det traditionella applikationsschemat, som måste innehålla varje tillåten objekttyp, ligger till grund för utvecklingen av tillämpningen kan man vid utvecklingstillfället bygga tillämpningen för att hantera just dessa objekttyper. Det kallas för tidig bindning (jämför eng. early binding). Fördelen med sen bindning är som påpekats ovan större flexibilitet och minskad känslighet för förändringar. Ett pris man kan få betala för denna flexibilitet är risken för långsammare tillämpningar. En annan nackdel kan uppstå om katalogmodellen ger stora begränsningar i uttrycksmöjligheter jämfört med förekommande modelleringsspråk (t.ex. uttrycksmöjligheterna i UML och ISO/TS eller EXPRESS). Slutligen måste vid varje användning av denna standard bestämmas vilken roll och status objekttypskatalogen har. Är den en formell standard eller kan den underhållas t.ex. av en ansvarig förvaltare? Är katalogen att betrakta som en standard så kvarstår en del av problematiken, nämligen förfarandet med revidering av standard. 39

40 6 Rumsliga egenskaper i applikationsscheman Att kunna beskriva olika företeelsers position, form och inbördes relationer är givetvis en av de viktigaste egenskaperna hos en standard för geografisk information. Informationen om en väg ska kunna inbegripa vägens sträckning men det ska också gå att ta reda på vilka vägbroar den utnyttjar och vilka andra vägar den korsar eller ansluter till. I standarden ISO [19107] beskrivs hur man i ett geometriskt referenssystem kan bygga upp geometriska konstruktioner och beskriva informationen om dessa. Standarden visar även hur man kan beskriva topologier, till exempel att två vägar korsar varandra. Vägar och vägbroar kan därefter få representeras av detaljer i de geometriska och topologiska konstruktionerna. Standarden innehåller två UML-paket, ett för geometri och ett för topologi. Paketen innehåller klasser som kan användas som när företeelsers rumsliga egenskaper beskrivs. Det här kapitlet beskriver dels hur de rumsliga modellerna byggs, dels hur man utnyttjar dem i applikationsscheman. 6.1 Geometri och topologi Företeelsers rumsliga egenskaper beskrivs med geometri. Geometri inkluderar dimension, läge, storlek, form och orientering. Geometrin är beroende av vilket koordinatsystem som används. Topologi behandlar de egenskaper hos geometriska figurer som förblir oförändrade när rummet deformeras elastiskt och kontinuerligt, t.ex. när geografiska data transformeras från ett koordinatsystem till ett annat. Inom geografisk information används topologi för att beskriva konnektiviteten, alltså hur geografiska objekt hänger samman. Beräkningstopologi (computational topology) ger information om konnektiviteten mellan geometriska primitiver som kan härledas ur den underliggande geometrin. Ofta används topologi för att öka hastigheten vid databearbetning av geometri, t.ex. beräkningar av inneslutning, grannskap, begränsning, och nätverksanalyser. Av detta skäl konstrueras ofta kombinationsobjekt som topologiska komplex, nätverk eller grafer, för att optimera algoritmerna för geometriska beräkningar. Dessa data- och bearbetningsstrukturer byter ut algoritmer för geometrisk bearbetning mot kombinationsalgoritmer. 6.2 Implicit topologi Geometridelarna i [19107] hanterar de rumsliga aspekter som främst har med position och form att göra. Topologidelerna hanterar främst de aspekter som har med rumsliga relationer att göra. Man kan med rätta säga att topologiska relationer mellan geografiska företeelser implicit finns inbyggda i företeelsernas geometriska representation. Om två geometriska ytor (t.ex. fastighetsområden) vidrör varandra vid en gemensam gräns så är det ju, under förutsättning att geometrin är korrekt, möjligt att matematiskt tyda ut att områdena gränsar till varandra. 6.3 Explicit topologi I [19107] har man valt att rent modelleringstekniskt separera geometri och topologi som i sig kan ses som två sidor av samma mynt. Det finns flera skäl att göra på det sättet. Ett viktigt skäl för att bryta ut explicit topologi till en egen del är att detta ger möjlighet till representation av topologi utan att någon geometri behöver finnas överhuvudtaget. Ett annat skäl för explicit topologi är att det kan finnas sammanhang där det inte är sådan kvalitet på geometriska data att topologiska relationer kan härledas med tillräcklig säkerhet. För en navigeringsapplikation för t.ex. vägnät är det naturligtvis av största vikt att korsningar avsiktligt finns med och inte förekommer av en slump (på grund av bristfällig geometri). Ett tredje skäl kan vara rena prestandaaspekter. En explicit topologisk relation går att uttyda utan några avancerade matematiska operationer. Samtidigt finns fördelar (t.ex. vad gäller utrymmesbehov) med att inte hantera explicita topologiska samband i geometrimodellen. Detta sätt att modellera geometri och topologi är beprövat och används i många kommersiella GI- och CADverktyg. 40

41 6.4 Rumsliga objekt och geografiska företeelser Traditionellt har det som förekommit på kartor klassats som geografiska företeelser som till sin natur varit linjer, ytor eller punkter. Denna särbehandling av rumslig information har varit primär, vilket ju inte är så konstigt om man behöver informationen för att göra kartor. För vissa av kartans företeelser har ytterligare uppgifter funnits lagrade, t.ex. namnet på en plats, årsnederbörden i ett område eller materialet i en bro. I ISO säger man inte längre att företeelserna är av linjetyp, yttyp, etc. Istället betraktas de rumsliga egenskaperna som vilka egenskaper som helst. Detta synsätt gör att man kan modellera alla företeelser på samma sätt och en företeelse kan ha egenskaper representerade av både en linje och av en yta, vilket ju kan vara intressant för till exempel en väg. Man skiljer med andra ord starkt mellan å ena sidan företeelse-objekt som håller i information om företeelsernas egenskaper och å andra sidan de rent geometriska objekten som punkt, linje och yta. Företeelseobjekten representerar något som finns i verkligheten men de geometriska objekten representerar något som bara finns i ett geografiskt referenssystem. I [19107] finns standardschemat för beskrivning av rumsliga aspekter. Där beskrivs en uppsättning grundläggande geometriska objekt. Med hjälp av dessa ska man kunna göra de rumsliga modeller som behövs för att representera olika företeelsers rumsliga egenskaper. För varje geometriskt objekt finns en representation i form av en UML-klass. 6.5 Rumsliga attribut De geometriska och topologiska egenskaper man vill tillskriva en objekttyp uttrycks som ett eller flera attribut eller associationer hos motsvarande klass. De klasser som dessa refererar till kan i sin tur vara hopkopplingar av rumsliga objekt. Dessa kopplingar beskrivs vanligtvis även med text och bild. Klasser för företeelser Rumslig representation RoadNetwork Geometry GM_Complex (from Spatial) 1..* Road Geometry Contains 1..* GM_CompositeCurve (from Spatial) 1..* RoadElement Geometry Contains 1..* GM_Curve (from Spatial) Street Bridge + widthrestriction : Integer Tunnel + heightrestriction : Integer Figur 34: I applikationsschemat finns associationer mellan företeelseklasser och geometriklasser 41

42 6.6 Geometriska primitiver Med geometriska primitiver menar man de enklaste geometriska objekten. De går inte att bryta ner ytterligare i finare delar utan kan betraktas som geometriska atomer. De klasser för geometriska primitiver som får användas som associationer eller attribut i ett applikationsschema ska hämtas ur nedanstående tabell. Även subklasser som ärver från dessa är tillåtna. Geometrisk primitiv Klass Se sidan Punkt GM_Point 109 Linje GM_Curve 111 Yta GM_Surface 122 Kropp GM_Solid 130 Figur 35 visar ett exempel på ett applikationsschema kallad Parcels (fastigheter) som använder det rumsliga objektet TP_Face ur ISO Klassen Parcel har ett rumsligt attribut area som nyttjar en förekomst av datatypen TP_Face som attributvärde. De två alternativen att representera ett rumsligt attribut i UML visas. Model integration TP_Face <<Application Schema>> Parcels Spatial schema ISO Application schema (alternative 1) Parcel + nameofparcel : CharacterString + area : TP_Face Application schema (alternative 2) Parcel + nameofparcel : CharacterString +area TP_Face (from Spatial) Figur 35 - Rumsliga attribut kan modelleras som attribut (alt. 1) eller association (alt. 2) 42

43 6.7 Geometriska sammansättningar När de rumsliga egenskaperna hos en företeelse inte kan representeras av en enkel punkt, linje, yta eller kropp, talar man om geometriaggregat, komplex och kompositer. I ISO finns klasser för detta. Dessa klasser ska användas som datatyp för företeelsens rumsliga attribut. GM_Aggregate GM_MultiCurve GM_Complex GM_CompositeSurface Ett generellt Ett linje-aggregat har inga geometriaggregat behöver restriktioner om överlappning varken ha restriktioner om överlappning eller dimension Ett geometriskt komplex har restriktioner om överlappning En yt-komposit har restriktioner om överlappning och dimension Figur 36 - Klasser för geometriaggregat, komplex och kompositer kan användas för företeelsers geometriska representation Geometriaggregat Geometriaggregat används när man behöver representera en oordnad samling av andra geometriska objekt. Exempelvis skulle en klass för en fruktträdgård kunna ha ett enda attribut som representerar de punktformiga positionerna för alla dess träd. De klasser för geometriaggregat som får användas som rumsliga attribut i ett applikationsschema ska hämtas ur nedanstående tabell. Även subklasser till dessa är tillåtna. Geometriaggregat av Klass Se sidan Blandade geometriska objekt GM_Aggregate 135 Punkter GM_MultiPoint 136 Linjer GM_MultiCurve 136 Ytor GM_MultiSurface 136 Kroppar GM_MultiSolid 136 Blandade geometriska primitiver GM_MultiPrimitive 136 Tabell 2 Geometriaggregat 43

44 GM_MultiPoint, GM_MultiCurve, GM_MultiSurface eller GM_MultiSolid ska användas när man vill göra en samling av geometriska objekt av samma dimension. GM_MultiCurve ska till exempel användas när man vill göra en samling av linjer. GM_Aggregate är mer generell och ska användas när man vill göra en ostrukturerad samling av olika typer av GM_Object, inklusive andra aggregat. Om man vill lägga särskilda restriktioner på ett geometriaggregat ska man göra en ny klass med GM_Aggregate som basklass. Figur 37 visar ett exempel på en användardefinierad rumsligt aggregat benämnd 3points1curve, vilken är datatyp för en rumslig attributtyp i applikationsschemat. MyFeature + name : Charac terstring + district : CharacterString + registrationvalue : Integer + geometricshape : 3points1c urve <<Type>> GM_Aggregate (from Geometric aggregates) 3points1curve + p1 : GM_Point + p2 : GM_Point + p3 : GM_Point + curve : GM_Curve Figur 37 - Exempel på en egendefinierat geometriaggregat Geometriska komplex Ett geometriskt komplex är en samling av geometriska objekt i ett gemensamt koordinatsystem som inte överlappar sig själva eller andra objekt i samma komplex. Klassen GM_Complex ska användas när man behöver en datatyp som representerar en samling av hopkopplade geometriska primitiver, t.ex. linjer och ytor. Notera att klassen inte kan specificera hur objekten är hopkopplade, endast att objekten hör ihop. Hopkopplingen måste härledas ur objektens koordinater. Subtyper av GM_Complex kan specificeras för att begränsa strukturen inom komplexet. Dessutom kan en geometrisk primitiv inom en förekomst av GM_Complex delas mellan olika objekt. Om en tomtgräns är ett komplex av linjer kan en linje i en viss tomtgräns även vara en linje i en annan tomtgräns. Alla primitiverna av samma dimension inom ett komplex måste vara lägesmässigt separerade utom där de delar en gemensam begränsning. En primitiv inom ett komplex kan skära en annan primitiv av ett steg lägre dimension, men bara där den förstnämnda primitiven innehåller den andra inom sin begränsning. En primitiv inom ett komplex kan skära en annan primitiv av ännu lägre dimension, men bara där den förstnämnda primitiven helt omsluter den andra i sitt inre och det finns ett explicit interiorto-samband mellan dessa primitiver. För tvådimensionella komplex betyder detta att: 1. Linjer får inte korsa varandra och ytor får inte överlappa varandra. 2. Varje linje måste ligga helt inom eller helt utanför en yta. 3. Punkter får ligga inom en yta endast om detta uttryckligen anges. Ett dräneringsnät kan representeras som ett GM_Complex sammansatt av GM_Curves med restriktionen att dessa GM_Curves bildar en sammanhängande graf. Att det är ett GM_Complex innebär att ingen 44

45 GM_Curve får skära någon annan, och restriktionen innebär att varje GM_Curve måste ha minst sin ena begränsning (ändpunkten) sammanfallande med begränsningen för någon annan GM_Curve. Varje fastighetsområde i en fastighetsindelning har en gräns som består av GM_Curves. Varje GM_Curve delas av två fastighetsområdesgränser. Gränsen för varje fastighetsområde är ett GM_Complex, och mängden av alla fastighetsgränser är ett större GM_Complex, se Figur 38. Parcel + nameofparcel : String SpatialConfiguration GM_Complex (from Spatial) 1..* ParcelBoundary Geometry Contains 1..* GM_CompositeCurve (from Spatial) UndefinedBoundary CalculatedBoundary BoundaryWithPoles +islyingon 1..2 BoundaryPole + polenumber : Integer + position : GM_Point Figur 38 - Exempel på ett rumsligt komplex Geometriska kompositer En geometrisk komposit är ett geometrisk komplex av geometriska primitiver som alla är av samma typ. Kompositen får då samma dimension och samma egenskaper som denna geometriska primitiv har. I övrigt gäller, som för alla komplex, att de ingående primitiverna inte får överlappa varandra. De klasser för geometriska kompositer som får användas som rumsliga attribut i ett applikationsschema ska hämtas ur nedanstående tabell. Även egendefinierade subklasser till dessa är tillåtna. Geometrisk komposit av Klass Se sidan Punkter GM_CompositePoint 134 Linjer GM_CompositeCurve 134 Ytor GM_CompositeSurface 134 Kroppar GM_CompositeSolid 134 Tabell 3 Geometrikompositer 45

46 Ett vägnät består av vägar, vilken var och en kan sammansättas av enkla objekt som representerar olika vägelement, se Figur 39. De rumsliga attributvärdena för vägelement kan vara GM_Curve. Varje väg kan representeras av GM_CompositeCurve som består av de GM_Curves som representerar vägelementen för vägen. Vägnätet kan representeras av ett GM_Complex som består av mängden GM_CompositeCurves som representerar vägarna. RoadNetwork Geometry GM_Complex (from Spatial) 1..* Road Geometry Contains 1..* GM_CompositeCurve (from Spatial) 1..* RoadElement Geometry Contains 1..* GM_Curve (from Spatial) Street Bridge + widthrestriction : Integer Tunnel + heightrestriction : Integer Figur 39 - Exempel på geometriska kompositer 6.8 Topologiska primitiver Topologi används för att beskriva geografiska samband mellan objekt. Varje topologiskt objekt kan ha (men måste inte ha) en motsvarande geometrisk realisering. Topologiska primitiver kan associeras till geometriska primitiver av samma dimension. Det geometriska objektet sägs då vara det topologiska objektets geometriska realisering. De klasser för topologiska primitiver som får användas som rumsliga attribut i ett applikationsschema ska hämtas ur nedanstående tabell. Topologisk primitiv Klass Kan associeras till Se sidan Nod TP_Node TP_DirectedNode GM_Point 141 Länk TP_Edge TP_DirectedEdge GM_Curve 143 Område TP_Face TP_DirectedFace GM_Surface 146 Rum TP_Solid TP_DirectedSolid GM_Solid 149 Tabell 4 Topologiska primitiver På samma sätt som för andra attribut är det tillåtet att göra egna datatyper genom subklassning eller genom att skapa klasser med sammansatta attribut. XX_Outline +outline : GM_Surface +accuracy : DQ_AbsoluteExternalPositionalAccuracy Figur 40 - Exempel på sammansatta attribut 46

47 6.9 Topologiska komplex Topologiska komplex beskriver explicit kopplingarna mellan de ingående topologiska primitiverna. Ett skäl till att använda topologiska komplex är att kunna använda metoder för topologisk databearbetning på geometriska komplex. Det kräver att sambandet Realization från TP_Complex till GM_Complex implementeras. Ett annat skäl att använda topologiska komplex är att beskriva konnektivitet mellan företeelser oberoende av deras geometriska representation. Ett geometriskt komplex säger ju inget om hur komplexets olika objekt är hopkopplade. Klassen TP_Complex ska användas när man vill uttrycka en sådan hopkoppling. Det görs med en association till det geometriska komplexets representation, t.ex. en GM_CompositeCurve. Klassen TP_Complex ska också användas som datatyp för att uttrycka hopkoppling av topologiska primitiver oberoende av om det finns en geometrisk representation. Ett kraftledningsnät kan representeras som ett TP_Complex där TP_Node representerar kraftverk, transformatorer, brytare eller andra kopplingspunkter, och där TP_Edge representerar kraftledningarna. Det betyder att den klass som skapas utifrån objekttypen kraftledningsnät ska ha ett attribut av typen TP_Complex Rumsliga samband mellan objekt Topologi mellan företeelser uttrycks ibland bäst utan att använda topologi-klasserna. Istället beskrivs deras inbördes förhållande genom särskilda samband mellan företeelsernas klasser. Vissa rumsliga samband - t.ex. inom, korsar, berör skulle antingen kunna uttryckas på det viset eller med hjälp av topologiklasserna. Andra t.ex. öster om, ovanför kan inte uttryckas med topologiklasserna utan måste alltid beskrivas genom särskilda samband mellan företeelsernas klasser. I ett applikationsschema är det tillåtet att göra på båda sätten. Road +connects +connectedto + geometrydefinedby : GM_Curve 2..n 0..2 Crossing + geometrydefinedby : GM_Point Figur 41 - Exempel på ett topologiskt samband implementerat som en association Figur 42 är ett exempel på hur ett rumsligt samband implementeras genom mekanismerna i den rumsliga modellen. Topologin mellan objekten beskrivs genom de TP_Node och TP_Edge, som ingår i ett TP_Complex som representerar vägnätet. Dessa rumsliga objekt bär implicit det rumsliga sambandet. TP_Edge för Road representerar vägen som förbindelse mellan korsningarna, och TP_Node för Crossing representerar korsningen som knut mellan vägarna. Om TP_Complex för RoadNetwork har en geometrisk realisering så ska den enligt ISO utgöras av GM_Object med samma dimension som TP_Object, d.v.s. av GM_Curve för TP_Edge och av GM_Point för TP_Node. I detta exempel har dessa geometriska primitiver använts som datatyper för attributtyperna location resp. position. Härigenom knyts den geometriska realiseringen till geometrin för objekten. Utan dessa definierade attributtyper skulle inte applikationsschemat ha uttalat något om en eventuell geometrisk realisering och vad denna eventuella geometri beskrev för något. Exemplet innehåller dessutom en geometrisk ytredovisning av vägen och korsningen i form av GM_Surface. Denna geometri kan inte utgöra en geometrisk realisering av topologin eftersom den har annan dimension än TP_Edge och TP_Node. 47

48 RoadNetwork Crossing + topology : TP_Node + position : GM_Point + geometrydescribedby : GM_Surface Road + topology : TP_Edge + location : GM_Curve + geometrydescribedby : GM_Surface Figur 42 - Exempel på rumsliga samband implementerade genom användning av rumsliga attributtyper I föregående exempel anger applikationsschemat inte uttryckligen att det är GM_Curve resp. GM_Point som attribut för attributtyperna location resp. position som utgör den geometriska realiseringen av topologin. För att uttrycka detta bör klassen GM_Complex och dess relationer med TP_Complex, GM_Curve och GM_Point ha inkluderats. Ett förslag till hur detta kan modelleras ges i Figur 43. Figuren inkluderar en liten profil av ISO genom att multipliciteterna mellan TP_Node och GM_Point samt TP_Edge och GM_Curve skärpts. Crossing +geometrydescribedby[1] : GM_Surface Road geometrydescribedby[1] : GM_Surface +proxy TP_DirectedNode +boundary 2 2 +topology 0..* +topology 1 TP_Node +topo RoadNetwork TP_Edge +topology +topology * +element 1..* +element 1 +topology -complex TP_Complex 1 1 +complex Realization Realization 1 +topology 1 +geometry +complex GM_Complex 1 1 +complex +geometry GM_Point +element 1..* GM_Curve * +element +geometry Figur 43 - Exempel på hur geometrisk realisering uttrycks som en egenskap hos topologin 48

49 6.11 Objekt som delar geometri Olika objekt kan fullständigt eller delvis dela samma geometri när de förefaller ha samma geografiska position. För att dela en gemensam geometri måste rumsliga attributtyper dela ett eller flera GM_Objects Fullständig delning Fullständig delning inträffar när två objektf bägge har samma objekt av GM_Object som attributvärde för ett rumsligt attribut. Detta kan deklareras som obligatoriskt, eller förbjudet, genom att deklarera ett villkor i applikationsschemat. Om något sådant villkor inte finns kan geometrin delas på detta sätt när det är lämpligt. Figur 44 visar ett exempel där en transformator uppsatt på en stolpe representeras av samma GM_Point som stolpen. En stolpe däremot behöver inte ha samma representation som en transformator, eftersom inte alla stolpar har transformatorer. Pole + height : Integer Transformer +feature 1 +feature geometry GM_Point (from Spatial) 1 +geometry Figur 44 - Exempel 1 på objekt som delar geometri Delvis delning För att objektförekomster ska kunna dela geometri delvis måste de geometriska objekt som representerar de rumsliga egenskaperna modelleras som element i ett geometriskt komplex. Se avsnitt och för regler och exempel. Figur 45 visar ett exempel där en viss GM_Curve representerar både en bro och en väg. Bridge + type : Integer + name : CharacterString Road + name : CharacterString + numberoflanes : Integer +feature 0..* 0..* +feature depict depict +geometry 1..* GM_Curve (from Spatial) +geometry 1..* Figur 45 - Exempel 2 på objekt som delar geometri 49

50 En annan möjlighet att modellera delad geometri är att använda GM_Composite från ISO En GM_Composite är ett aggregat av GM_Primitives (utom punkt) som uppträder som en primitiv. En GM_CompositeCurve är ett aggregat av GM_Curves som uppträder som en GM_Curve. Det är också möjligt att låta en GM_Composite bestå av andra GM_Composites Flera alternativa representationer Ett geografiskt objekt, t.ex. ett vägnät, kan ha flera rumsliga representationer. Det kan i ett sammanhang vara vettigt att se vägnätets transportgeometri som en samling linjer. I ett annat sammanhang är det vägbanans utbredning som är intressant. Dessa olika representationer kan anges i ett och samma applikationsschema men de olika komplexen måste hållas åtskilda. Exemplet visar ett applikationsschema som använder två oberoende geometriska komplex för att representera samma vägnät. Ett GM_Complex beskriver transportgeometrin och består av GM_Curves för vägarnas mittlinjer. Ett annat GM_Complex beskriver vägarnas ytmässiga utbredning som ett komplex av GM_Surfaces. RoadNetwork routing pavement GM_Complex GM_Complex 1..* 1..* GM_Curve GM_Surface Figur 46 - Exempel på två olika rumsliga representationer 50

51 6.13 Separerade topologier Olika typer av företeelser som i praktiken hänger ihop, t.ex. sjöar och broar, behöver ändå inte dela rumslig representation i applikationsschemat. Är man intresserad av de rumsliga sambanden mellan dem kan dessa finnas genom att de refererar till samma plats i rummet. Broarna och vägarna sägs då representeras av topologiskt oberoende mängder av rumsliga objekt. Betrakta ett tätortsområde med ett underjordiskt spårnät, såsom i Figur 47. Fyrkanterna representerar den verkliga rumsliga utbredningen för stationsområdena och utgör GM_Objects av typen GM_Surface. De kan ingå i ett GM_Complex som avser tätortsområdet. På samma gång kan spårnätets konnektivitet representeras av ett TP_Complex där stationerna representeras av TP_Nodes och nätförbindelserna (inte de verkliga spåren) representeras som TP_Edges. Detta TP_Complex har ingen geometrisk realisering. Vi har således två oberoende rumsliga komplex ett GM_Complex och ett TP_Complex i applikationsschemat. Vi kan bygga på exemplet med att spårens verkliga lägen kan representeras som GM_Curves inom samma GM_Complex, men dessa GM_Curves utgör i så fall inte en geometrisk realisering av de TP_Edges som representerar nätförbindelserna. Rail station as GM_Surface Rail station as TP_Node Station connectivity as TP_Edge RailSystem SpatialRepresentation UrbanArea system GM_Complex 1..* Connectivity representedby Building 1..* Shape TP_Complex GM_Surface RailStation ConnectionPoint TP_Node Complex Complex StationConnectivity 1..* TP_Edge Figur 47 - Exempel på oberoende rumsliga komplex i ett applikationsschema När man inte utnyttjar de speciella klasserna för sammanslagning av rumsliga objekt, t.ex. GM_Complex, är det underförstått att den rumsliga representationen är separerad. 51

52 6.14 Lägesredovisning med geografiska identifierare Geografisk information kan vara knuten till ett geografiskt referenssystem antingen genom att informationen innehåller koordinater eller genom att informationen innehåller en referens till en plats. Referenssystem där koordinater används beskrivs i [19111] och referenssystem med geografiska identifierare beskrivs i [19112]. Mer om detta finns beskrivet på sidorna 78 respektive 102. När man använder lägesredovisning i form av geografiska identifierare anges objektets position genom angivelse av en plats. Ett namn eller en kod anger positionen. En datamängd som är beroende av lägesredovisning genom geografiska identifierare innehåller inte explicita koordinater. I stället har man ett platsregister som innehåller platsen och dess koordinater. Härigenom kan data visas eller bearbetas geografiskt. Flera platsregister kan förekomma i ett rumsligt referenssystem som innehåller skilda koordinatangivelser för platserna. Vilket platsregister som väljs blir beroende av tillämpning. För befolkningsstatistik kan till exempel ett platsregister med centralpunkter för bostadsområden vara tillräckligt, medan det för andra behov kan behövas en fullständig koordinatredovisning av områdenas gränser. En objekttyp som anger läge genom att referera till en plats ska i applikationsschemat modelleras som en klass med ett attribut av typen SI_LocationInstance. Detta illustreras i Figur 48 som visar ett exempel på hur information om en kund refererar till ett försäljningsdistrikt. Distrikten måste i sin tur vara registrerade och samlade i ett register enligt ISO I det registret ska finnas information om distriktens geografiska utbredning, antingen som polygoner eller genom att referera till andra platser. XX_Customer +name:characterstring +district:si_locationinstance Figur 48 - Exempel på lägesredovisning genom geografisk identifierare 52

53 7 Tidsaspekter i applikationsscheman Ett spritt användande av datorer och geografiska informationssystem har lett till ett ökat användande av rumsliga (spatiala) data inom flera områden. Geografisk information är dock inte enbart 1-, 2- eller 3- dimensionella rumsliga objekt, utan många geografiska informationssystem har ett behov av data med tidsmässiga (temporala) egenskaper. Information om olika företeelsers tidsaspekter behövs när man ska uttrycka företeelsernas tidssamband, historia, förändring etc. På samma sätt som man i ISO definierar klasser för rumslig geometri och topologi så definierar ISO [19108] klasser för temporal geometri och topologi. På samma sätt som rumsliga objekt har dimensionalitet kan även tid ses som ett dimensionellt objekt. En given tidpunkt har en position som kan identifieras relativt dess referenssystem. Avstånd mellan två tidpunkter kan också beräknas. I motsats till rumsliga objekt har dock tid endast en dimension, och har en absolut riktning tiden går alltid framåt. Det här kapitlet beskriver hur man utnyttjar ISO 19108:s klasser i applikationsscheman. 7.1 Temporalt referenssystem I standarden [19108] beskrivs hur man i ett s.k. temporalt referenssystem kan bygga upp konstruktioner med endimensionell tids-geometri och tids-topologi och beskriva informationen om dessa. Ett referenssystem är nödvändigt för att möjliggöra utbyte av information mellan olika system. Teoretiskt är tidsaxeln oändlig, både bakåt och framåt, vilket gör det praktiskt svårt att fixera tidpunkter (temporala positioner) utan att använda sig av ett referenssystem. Ett värde i en tidsdomän är en temporal position relativt dess temporala referenssystem. I moderna system används vanligen den Gregorianska kalendern som referenssystem, och den Julianska kalendern som basreferensystem när man behöver gå från ett referenssystem till ett annat. ISO innehåller två UML-paket: för referenssystem och för temporala objekt. 7.2 Tidsattribut ISO innehåller klasser som alltid ska användas när företeelsers tidsmässiga egenskaper beskrivs. Tabellen anger de klasser som ska användas för tidsmässiga egenskaper. Egenskap Klass Se sidan Tidsgeometri - Tidpunkt TM_Instant 157 Tidsgeometri - Tidsperiod TM_Period 157 Tidstopologi - Händelsepunkt TM_Node 157 Tidstopologi - Händelserelation TM_Edge 157 Tidstopologi - Komplex av händelser TM_TopologicalComplex 157 Tabell 5 Klasser för tidsattribut i ett applikationsschema Det är även tillåtet att definiera subklasser till dessa. Jämfört med tidpunkt och tidsperiod, som är tämligen vardagliga begrepp, är tidstopologi svårare att förstå. Man kan säga att tidstopologin tillhandahåller information om hur olika topologiska objekt är kopplade till varandra, deras inbördes relationer. På samma sätt som med rumsliga egenskaper kan tidstopologin härledas ur den temporala geometrin. 53

54 Figur 49 visar ett exempel på ett applikationsschema för en mätningsaktivitet där utrustning som placerats på ett fält registrerar mätvärden med en definierad frekvens. Tidsobjekt används som datatyper för tidsattributen för objekttyperna Station och Measurements. Model integraiton <<Application Schema>> Measurements GM_Point TM_Instant Spatial schema ISO Temporal schema ISO Application schema Station + name : CharacterString + position : GM_Point +haslogof Values + fromtime : TM_Instant + totime : TM_Instant 0..* Measurements + timeofmeasurement : TM_Instant + measuredvalue : Real Figur 49 - Exempel på tidsattribut Figur 50 visar exempel på användning av ett TM_TopologicalComplex som tidsattributtyp. BuildingHistory är en attributtyp för objekttypen Building som är en UML-klass i modellen. Som subtyp till - TM_TopologicalComplex är den en aggregat av TM_TopologicalPrimitives som beskriver händelser och tidpunkter i byggnadshistoriken. Den har dessutom en egen attributtyp episodes som är en uppräkning av de episodtyper som svarar mot en nod eller länk i den linjära grafen. Detta exempel verkar ofullständigt. Episoderna är ju bara typen av händelse; det finns ingen koppling mellan typen av händelse och de TM_Instant eller TM_Period som ingår i TM_Complex. 54

55 Model integration <<ApplicationSchema>> HistoryOfBuildings GM_Surface TM_TopologicalComplex Spatial schema ISO Temporal schema ISO Application schema TM_TopologicalComplex Building + footprint : GM_Surface +history + height : Integer + numberoffloors : Integer 0..1 BuildingHistory + episodes : Sequence<Episode> <<CodeList>> Episode + dateofconstruction + constructionperiod + dateofoccupancy + periodofoccupancy + abandonment + vacantperiod + destruction Figur 50 - Exempel på TM_TopologicalComplex som används som en tidsattributtyp. 7.3 Enkla tidssamband Ett enkelt tidssamband mellan två objekt kan representeras på olika sätt: som ett attribut med värden från TM_RelativePosition, se figur 51 som ett beräknat samband utifrån de tidsdata som finns för de olika objekten. Resultatet av beräkningen blir då av typen TM_RelativePosition som en association mellan de två objekten, som i Figur 52 55

56 <<Enumeration>> TM_RelativePosition (from Temporal Objects) + Before + After + Begins + Ends + During + Equals + Contains + Overlaps + Meets + Overlapped + MetBy + BegunBy + EndedBy Figur 51 TM_RelativePosition Figur 52 är ett exempel på ett enkelt tidssamband som implementeras som en UML-association. Modellen anger att vägar existerar innan bensinstationer. På förekomstnivå associeras de bensinstationer som är byggda senare med den väg de ligger invid. XX_Road +before built +after XX_ServiceStation 1..* 0..* Figur 52 Exempel på ett modellerat enkelt tidssamband 7.4 Objektsföljd Objektsföljd är en serie av förändringar över tiden som omfattar ersättning av ett eller flera objektsförekomster med andra. Det finns tre typer av objektföljd: Objektutbyte, som innebär att en objektförekomst ersätts av en annan. Det skapar en ett-till-ett-relation mellan två objektsförekomster. Objektdelning, som uppstår när en enskild objektförekomst delas upp i två eller flera nya objektsförekomster. Det skapar en ett-till-många-relation mellan objektsförekomster. Objektsammanslagning, som uppstår när två eller flera objektsförekomster sammanfogas till en ny objektförekomst. Det skapar en många-till-ett-relation mellan objektsförekomster. Det är möjligt att kombinera de tre typerna av objektföljd. Det finns både rumsliga och tidsmässiga aspekter förknippade med objektutbyte genom att objektförekomsterna har samma rumsliga läge, vid olika tider och i en särskild ordning. Objektutbytesrelationer kan härledas ur rums- och tidsattribut. Emellertid kräver det att varje objekttyp måste ha ett tidsattribut som anger perioden då företeelsen existerar. Objektföljden kan härledas genom att först identifiera de objektförekomster som delar rumsliga primitiver, och därefter bestämma deras TM_RelativePosition för deras existensperioder. De olika objekten i en objektsföljd behöver inte vara av samma typ. Samband mellan objekt av typen objektföljd kan modelleras i applikationsschemat på två sätt: som associationer mellan klasser som självrefererande UML-association för en basklass Namnsättning, rollnamn och multiplicitet för UML-associationen ska väljas med hänsyn till typen av objektföljd 56

57 8 Metadata Metadata är data som beskriver och dokumenterar data. Metadata för geografiska data ger information om datamängdens identitet och kvalitet, när och i vilket sammanhang data har uppstått, vilket rumsligt referenssystem som har använts, etcetera. En viktig del av metadata utgör kvalitetsinformation om data. Här ingår t.ex. uppgifter om mätnoggrannhet och med vilken säkerhet klassificeringar har gjorts. Till en stor del beskrivs detta i kapitlet om Datakvalitet på sidan 61. Det standardschema för metadata som finns i [19115] kan användas i flera sammanhang: För att beskriva kvalitet och andra metadata hos data som ingår i ett datautbyte eller som är lagrad i en databas. För att konstruera kataloger där man kan söka och återfinna befintliga geografiska. För att referera till olika resurser vid filöverföring, t.ex. vilket applikationsschema som använts och var metadata om data i filen kan återfinnas. För att i ett applikationsschema specificera egenskaper hos geografiska objekt som är av metadatakaraktär. För att beskriva en metadataprofil, d.v.s. vilka tillägg och inskränkningar som gjorts av schemat i [19115]. 8.1 Metadata om datamängder Standardschemat i [19115] är mycket flexibel och bygger på att metadatauppgifter ska kunna anges för data på nivåer med olika omfattning: En svit av flera datamängder, t.ex. allt i en databas En datamängd, t.ex. data insamlat vid ett viss tillfälle En viss objekttyp i datamängden, t.ex. alla sjöar En viss attributtyp hos en objekttyp i datamängden, t.ex. djupet hos alla sjöar Ett visst objekt i datamängden, t.ex. en viss sjö Ett visst attribut för ett visst objekt i datamängden, t.ex. djupet hos en viss sjö Metadata om alla data i databasen Databas Metadata om alla data från ett visst mättillfälle Datamängd från visst område och mättillfälle Metadata om alla sjö-data i datamängden Metadata om uppgiften om Storsjöns djup Uppgifter om en sjö Figur 53 - Metadata kan avse data på olika hierarkisk nivå. Genom att definiera hierarkiska nivåer kan man låta lägre nivåer ärva metadata från högre. Då behöver metadata endast anges på en lägre nivå då den avviker från vad som gäller för en högre nivå. 57

58 8.2 Metadata i applikationsscheman Klasser i ett applikationsschema kan innehålla metadataattribut. Exempelvis kan tillkomstinformation läggas till attributen för en klass som representerar en byggnad så att det i data även kan anges när, hur och av vem inmätningen är gjord. Det är då tillåtet, men inte tvunget, att använda de klasser som finns definierade i standardschemat i [19115]. Det är även tillåtet att använda datatypsklasserna i [19115] för andra attribut än metadataattribut om detta skulle passa. 8.3 Kvalitetsdata i applikationsscheman Datakvaliteten antas normalt vara densamma för en hel datamängd. Ibland förväntas dock kvaliteten hos dataförekomster för en viss typ av företeelser avvika från vad som gäller för datamängden. Sådana kvalitetsdata ska anges som attribut i den klass som representerar objektypen, antingen för hela klassen eller för det attribut som kvaliteten avser. Nedanstående datatyper eller subklasser av dessa ska användas: Quality Element Quality Subelement DQ_Element subtype Positional Accuracy Absolute External Accuracy Relative Internal Accuracy Gridded Data Accuracy Temporal Accuracy Accuracy of a Time Measurement Temporal Consistency Temporal Validity Thematic Accuracy Classification Correctness Nonquanitative Attribute Accuracy Quantitative Attribute Accuracy Logical Consistency Format Consistency Topological Consistency DQ_AbsoluteExternalPositionalAccuracy DQ_RelativeInternalPositionalAccuracy DQ_GriddedDataPositionalAcuracy DQ_AccuracyOfATimeMeasurement DQ_TemporalConsistencyAccuracy DQ_TemporalValidityAccuracy DQ_ThematicClassificationCorrectness DQ_ThematicNonQuantitativeAttributeAccuracy DQ_ThematicQuantitativeAttributeAccuracy DQ_FormatConsistency DQ_TopologicalConsistency XX_LandArea +landname : CharacterString +hasoutline : XX_Outline +featureclassificationquality : DQ_ThematicClassificationCorrectness XX_Outline +outline : GM_Surface +accuracy : DQ_AbsoluteExternalPositionalAccuracy Figur 54 - Exempel på användning av datakvalitetsattribut 58

59 9 Anpassning av standardscheman efter egna behov I stället för att direkt använda klasser så som de definierats i standardscheman är det möjligt att göra justeringar för att bättre passa den aktuella tillämpningen. En justering kan göras på ettdera av två sätt: genom att lägga till attribut och/eller associationer till klasserna i standardschemat genom att inskränka definitionerna i standardschemat i enlighet med överensstämmelseavsnittet i standarden. 9.1 Utökning av standardschema Av många orsaker är det praktiskt eller nödvändigt att utvidga definitionerna i ett standardschema med ytterligare information. För att utöka en klass från ett standardschema skapar man en ny klass som ärver från standardklassen och lägger till de ytterligare attribut eller associationer som behövs. De nya klasserna ska samlas ett separat paket. Figur 55 [19109 figure 12] visar ett applikationsschema som direkt använder en definition (GM_Point) från den standardiserade rumsliga modellen, och en annan definition (SurfaceWithQuality) i ett paket kallat domain spatial package. Detta innehåller justeringar av den rumsliga definitionen (GM_Surface), och samtidigt använder det en definition från kvalitetsmodellen (DQ_AbsoluteExternalPositionalAccuracy). Klassen SurfaceWithQuality har två ytterligare attribut som i denna verksamhet befunnits lämpliga som tilläggsinformation till geometrin som beskriver byggnadens projektion på marken. Model integration <<Application Schema>> Example SurfaceWithQuality GM_Point Domain Spatial Package DQ_AbsoluteExternalPositionalAccuracy Spatial schema ISO GM_Surface Quality schema ISO Application schema Building + nameofbuilding : CharacterString + position : GM_Point + footprint : SurfaceWithQuality Domain Profile Package GM_Surface (from Spatial schema) SurfaceWithQuality + accuracy : DQ_AbsoluteExternalPositionalAccuracy + methodofmesurement : CharacterString Figur 55 - Exempel på tillägg av information till ett standardschema 59

60 9.2 Inskränkning av standardschema För vissa standardscheman, t.ex. det i [19107], är det möjligt att omdefiniera modellen på ett sådant sätt att bara valda delar av modellen används, t.ex. bara vissa definierade klasser och samband. En sådan delmängd kallas en profil. En profil måste tillgodose reglerna i överensstämmelseavsnittet för aktuell standard. För att göra en profil skapar man först ett nytt paket. Kopiera relevanta delar av standardschemat till paketet. Klassnamnet bibehålls och alla obligatoriska attribut och samband måste tas med. Multipliciteten kan skärpas inom det intervall som standardschemat anger. Av en basklass i standardschemat kan vissa subklasser utelämnas. Det är även tillåtet att ersätta en basklass med någon eller några av dess subklasser. En inskränkt profil av den rumsliga modellen [19107] kan t.ex. specificeras att bara använda definitionerna av GM_Object och dess subklasser, men inte operationerna för dessa. 9.3 Profiler Exempel på profil samt applikationsschema. Interior to <<Type>> GM_Object (from Geometry root) Coordinate Reference System +object +CRS 0..n 0..1 Oriented <<DataType>> <<Abstract>> +coordinatereferencesystem 0..n DirectPosition SC_CRS (from Coordinate geometry) directposition + coordinate : Sequence<Number> (from Spatial Referencing by Coordinates) /+ dimension : Integer +containedprimitive 0 +primitive <<Type>> 1 GM_Primitive (from Geometric primitive) +containingprimitive 0 +proxy 0,2 <<Type>> GM_OrientablePrimitive (from Geometric primitive) + orientation : Sign <<Type>> GM_Point (from Geometric primitive) + position : DirectPosition +point 1 <<Type>> GM_OrientableCurve (from Geometric primitive) Segmentation <<Type>> GM_Curve (from Geometric primitive) +curve +segment 1 1 <<Abstract>> GM_CurveSegment (from Coordinate geometry) + interpolation : GM_CurveInterpolation = "linear" + numderivativesatstart[0,1] : Integer + numderivativesatend[0,1] : Integer + numderivativeinterior[0,1] : Integer 0..n <<DataType>> GM_PointRef (from Coordinate geometry) <<Union>> GM_Position +column (from Coordinate geometry) + direct : DirectPosition indirect : GM_PointRef <<DataType>> GM_PointArray j : Integer (from Coordinate geometry) <<Type>> GM_LineString (from Coordinate geometry) + controlpoint : GM_PointArray Figur 56 Exempel på profil Ovanstående diagram visar en tänkbar profil av ISO Spatial Schema som endast tillåter användning av punkter (GM_Point) och linjer (GM_Curve). Denna profil uppfyller alltså konformitetsklasserna A (0- dimensionell geometri, endast datatyper) och A (1-dimensionell geometri, endast datatyper) enligt ISO Ytterligare inskränkningar i förhållande till standarden är : Endast ett linjesegment tillåts per linje (GM_Curve.segment[1] i ställer för [1..n]). Endast linjesegment med rätlinjig interpolation tillåts (GM_LineString). Möjligheten att deklarera att geometriska primitiver finns inuti andra har tagits bort. Detta görs genom att sätta kardinaliteten till 0 (GM_Primitive.containingPrimitive[0] och GM_Primitive.containingPrimitive[0]). Dessa inskränkningar är helt i sin ordning så länge som schemat fortfarande ryms inom standarddefinitionen. T ex är kardinalitet 0 en delmängd av kardinalitet 0..n. För information om de regler och riktlinjer som gäller för framtagandet av profiler hänvisas till ISO Profiles. 60

61 10 XML-kodning av data ISO standarderna förordar modelldriven utveckling. Det innebär att modellen, i detta fall applikationsschemat, ska vara tillräckligt innehållsrik för att t.ex. ett filformat ska kunna specificeras. Detta bör kunna ske automatiskt med en uppsättning regler. ISO (Encoding) visar hur XML-kodningen för ett visst applikationsschema kan specificeras med hjälp av ett XML-schema. Detta kapitel redvisar inte reglerna direkt men illustrerar dem med ett XSLT-skript för översättning av ett applikationsschema uttryckt i XMI till ett XML-schema. För att kunna utveckla och felsöka programvara som genererar och avkodar XML-data är det nödvändigt att förstå hur XML-data förhåller sig till applikationsschemats klassdiagram. Kapitlet tar därför upp ett antal exempel som ska ge denna förståelse Modellfiler, XML-scheman och data Ett applikationsschema och de standardscheman som det utnyttjar är gjort med någon form av UML-verktyg. Internt kan modellerna lagras i verktygets format men för att det ska vara möjligt att flytta modellerna till andra verktyg krävs ett standardiserat format - XMI. UML-verktyg Standardmodell XMI Standardmodell Standardmodell Applikationsschema A XMI XMI XMI A Figur 57 - Ett UML-verktyg bör kunna leverera modeller som XMI-filer Varje delmodell ger upphov till en XMI-fil. Det är dessa modeller som sedan kan ligga till grund för regelstyrd generering av XML-scheman (kallas även XSD-filer). Detta arbete kan göras automatiskt med hjälp av ett transformeringsprogram. Eftersom både XMI-filer och XSD-filer i grunden är XML kan man använda sig av ett s.k. XSLT-skript för transformeringen. XMI XMI XMI XMI A Transform XMI-XSD XML-schema ISO XML-schema A Figur 58 - XMI-filerna kan utnyttjas till att generera XML-scheman Standardschemana är mycket omfattande och det kan därför vara vettigt att bara generera de delar man behöver. XML-schemana specificerar hur XML-data ska vara formaterat. Deras huvudsakliga uppgift är att vara underlag för validering av mottagna XML-data. 61

62 XML-dokument (fil) XML-data XML-schema ISO XML-schema A XML-parsern: - Inläsning och validering av XML-dokument mot XML-scheman. - Lagring av data på ett för applikationen åtkomligt sätt. Applikationen: Figur 59 - XML-scheman utnyttjas vid validering av XML-dokument XML-schemana kan även ligga till grund för koden i applikationen XML-dokumentets struktur I XML-dokumentet är XML-data placerat på följande vis: <?xml version="1.0" encoding="utf-8"?> <GI xmlns:xsi=" xsi:nonamespaceschemalocation="stanli_xmi_example.xsd" timestamp=" t13:37:00" version="1.0"> <dataset> XML-data </dataset> </GI> Figur 60 - Exempel på XML-dokument Strukturen <GI><dataset>XML-data</dataset></GI> ska användas. Notera dock att handboken och tekniska ramverket för tillfället inte föreskriver hur ett XML-dokument ska se ut i detalj Kodning av självständiga objekt XX_House +rooms:integer +size:decimal <XX_House id="i012"> <rooms>6</rooms> <size>125</size> </XX_House> <XX_House id="i013"> <rooms>5</rooms> <size>113</size> </XX_House> Figur 61 - Objekt enligt en UML-klass kodas som XML-element Den grundläggande principen för kodning av data är att de objekt som är självständiga blir XML-element med klassnamnet som märktagg. För att ett element ska kunna refereras från andra element får det en identitet som är unik inom filen. Identiteten ska byggas enlig XML:s principer för identifierare. Det betyder i praktiken att identifieraren måste börja med en bokstav men i övrigt kan innehålla siffror och bokstäver. Vart och ett av objektets egenskaper blir ett XML-element uppmärkt enligt attributens namn. 62

63 XX_House +size:xx_area <<DataType>> XX_Area +area:decimal +unit:characterstring <XX_House id= i001"> <size> <area>23</area> <unit>m2</unit> </size> </XX_House> Figur 62 - Exempel på en sammansatt datatyp Om klassens attribut använder en sammansatt datatyp kommer datatypens attributnamn att användas Sammansättningar och associationer XX_House room 1..* i019 i079 i078 XX_Room +size:decimal <XX_House id= i019"> <room id= i077"> <size>15.6</size> </room> <room id= i078"> <size>9.8</size> </room> <room id= i079"> <size>22.3</size> </room> </XX_House> i077 Figur 63 - Exempel på komposition Vid kompositioner (fylld diamant i UML-diagrammet) räknas inte de ingående objekten som självständiga. De blir sub-element till det ägande objektets element. Såväl det ingående som det ägande objektet får identiteter så att andra objekt kan referera till det. XX_House house 1..* XX_Road <XX_Road id= i01"> <house idref= i07" /> <house idref= i08" /> <house idref= i09" /> </XX_Road> i08 i01 i07 <XX_House id= i07">... <XX_House id= i08">... <XX_House id= i09">... i09 Figur 64 - Exempel på association 63

64 För vanliga associationer mellan självständiga objekt används XML-attributet idref för att peka ut objekten. I exemplet i Figur 64 refererar ett väg-objekt (XX_Road) till ett antal hus-objekt (XX_House). Som märktagg i det refererande elementet (XX_Road) används rollnamnet (house) och det är i det elementet som attributet idref finns. XX_BusLine +lineid:integer stop XX_BusStop +name:characterstring <XX_BusLine id= z001"> <lineid>47</lineid> <stop idref= z007"/> <stop idref= z008"/> </XX_BusLine> z008 Zoo z002 z * City z007 <XX_BusLine id= z002"> <lineid>56</lineid> <stop idref= z007"/> <stop idref= z009"/> </XX_BusLine> <XX_BusStop id= z007"> <name>city</name> </XX_BusStop> <XX_BusStop id= z008"> <name>zoo</name> </XX_BusStop> z009 Airport <XX_BusStop id= z009"> <name>airport</name> </XX_BusStop> Figur 65 - Exempel på svag aggregering Svag aggregering (tom diamant i klassdiagrammet) betraktas på samma sätt som vanliga associationer. Exemplet i Figur 65 visar dessutom att inom ett element (XX_BusLine) kommer elementen för klassens attribut (lineid) först och därefter associationerna. I övrigt styrs detta av den ordning som attribut respektive olika typer av associationer har i XMI-filen Arvsmekanism XX_House +size:xx_area <<DataType>> XX_OutsideArea <<DataType>> XX_Area +area:decimal +unit:characterstring <<DataType>> XX_InsideArea <XX_House id= i01"> <size> <XX_InsideArea> <area>23</area> <unit>m2</unit> </XX_InsideArea> </size> </XX_House> Figur 66 - Exempel på arv mellan datatyper En mottagare av XML-kodade data måste kunna förstå vilken av flera möjliga datatyper som använts. Då räcker det inte att bara använda namnet på attributet som i Figur 62. I Figur 66kan attributet size avse antingen ytan mätt inne i huset eller ytan mätt utanpå huset. En extra nivå i XML-data talar om vilken som faktiskt valts. För associationer som refererar till självständiga objekt behövs inte denna extra nivå eftersom typen framgår av elementets märktagg, se Figur

65 i08 i01 i07 XX_House house 1..* XX_Road <XX_Road id= i01"> <house idref= i07" /> <house idref= i08" /> <house idref= i09" />... i09 The Palace XX_Castle XX_Villa <XX_Villa id= i07">... <XX_Villa id= i08">... <XX_Castle id= i09">... Däremot krävs det vid komposition som i Figur 68. Figur 67 - Exempel på arv och association XX_House XX_Bedroom +beds:integer i019 i079 room 1..* i078 XX_Room +size:decimal XX_Kitchen <XX_House id= i019"> <room id= i077"> <XX_Kitchen> <size>15.6</size> </XX_Kitchen> </room> <room id= i078"> <XX_Bedroom> <size>9.8</size> <beds>1</beds> </XX_Bedroom> </room> <XX_Bedroom> <room id= i079"> <XX_Bedroom> <size>22.3</size> <beds>2</beds> </room> <XX_Bedroom> </XX_House> i077 Kitchen Figur 68 - Exempel på arv och komposition 10.6 Konverteringsregler De konverteringsregler som finns i [19118 A.5] möjliggör vissa alternativa för generering av XML-scheman. De fyra första motsvarar de övergripande alternativen enligt [19118 A.5.7]. Dessa är de regler som ska användas: 1. Namn på klasser, attribut, roller och relationer i applikationsschemats klassdiagram ska utnyttjas i XMLschemat. 2. Som oberoende objekt, alltså objekt som kan överföras fristående, räknas alla objekt av klasser utan stereotypning eller med stereotypen <<Type>> utom de objekt som ingår i en UML-komposition. De objekt som är oberoende ska sedan inkluderas i en speciell Group i XML-schemat, se [19118 A.5.4.2]. 3. XML Schemas inbyggda arvsmekanism ska inte används. Genom att multipelt arv är vanligt förekommande i ISO standardernas modeller används den s.k. copy down-metoden [19100 A ]. 4. Choice Groups, alternativ c) i [19118 A.5.2.9], ska användas. 5. Någon configuration file enligt [19118 A.5.7] ska inte användas. 6. Attribut ska konverteras till XML-element (aldrig till XML-attribut), se [19118 A.5.3.1]. 7. Beräknade egenskaper (derived attributes) ska inte avspeglas i XML-schemat. 65

66 8. XML name space-mekanismen ska inte användas. Enligt [19118 A.5.1] får XML name space användas, det finns dock inga regler för hur. 9. IM_Object ska representeras av en attributgrupp i XML-schemat. En tvetydighet i [19118 A ] anger att objekt antingen ska ärva från IM_Object eller inkluderas dess attributgrupp för identifikation, medan [19118 A.5.5.1] bara specificerar arv. Eftersom de flesta av exemplen i standarden använder attributgruppsmetoden kan man utgå från att den trots allt är tillåten. Eftersom de olika metoderna inte påverkar utseendet på XML-dokumenten spelar det i praktiken ingen roll vilken som används. 10. Vid multipelt arv ska attribut kopieras från superklasserna i klassernas bokstavsordning. [19118 A ] anger ordningen vänster till höger men detta är inte möjligt utan att ta hänsyn till modellens geometri. 11. Det är tillåtet att skapa substitutionsgrupper även för klasser utan subtyper och refererar till dessa grupper istället för direkt till klassen. Det finns inget värde i att ha substitutionsgrupper för en klass som saknar subklasser, men det kan vara enklare att generera allt på samma sätt Överföring av förändringar i datamängder Behovet av en standardiserad modell för representation av förändringar i datamängder ökar i verksamheter som inför GIS. Kraven på mer sofistikerade metoder för datautbyte ökar allteftersom verksamheter och system integreras. Dagens modellbaserade standard för datautbyte, som i stora delar lämnat frågan obesvarad om hur förändring ska hanteras, passar bäst för överföring av fullständiga databaser. Användare av dagens standard får lösa frågan mer eller mindre på egen hand om behovet av förändringshantering uppstår. Förändringshantering vid ett datautbyte innebär att det är endast de förändringar som skett i den levererande databasens datamängd sedan det senast föregående utbytet som överförs till det mottagande systemet. Metoden innebär att det vid någon tidpunkt har skett en fullständigt överföring av en databas från dataleverantör till mottagare. Vid det inledande datautbytet är det stora volymer data som överförs. Stora volymer måste accepteras vid en första överföring, men i det fortlöpande utbytet är det fördelaktigt att endast överföra förändringar, d.v.s. att mindre volymer överförs. För en mottagare som integrerar mottagna data med egen information innebär det också många gånger en fördel att kunna särskilja det som förändrats från det som är oförändrat, och slippa ersätta hela den initialt mottagna datamängden. Förändringshantering ställer krav på det neutrala dataformatet som används för överföring av data mellan applikationer. Varje objekt måste märkas med uppgifter om vilket slags förändring det genomgått i det sändande systemet, d.v.s. huruvida det lagts till, modifierats eller tagits bort. Denna standard har just de egenskaper som krävs för att få med den här typen av information vid överföring av data. Modellen för förändringshantering är avsedd att utnyttjas tillsammans med t.ex. applikationsscheman. Den kan även utnyttjas tillsammans med en typoberoende objektmodell. Förändringshantering ställer vidare stora krav på tillämpningar att logga alla förändringar som sker i databasens innehåll. Tillämpningar måste logga och särskilja förändringar som innebär att ett objekt lagts till, modifierats eller tagits bort. Många av de tillämpningar som brukas idag har inte denna funktionalitet inbyggd. För att klara förändringshantering krävs även att objekt kan identifieras globalt på ett unikt sätt. Det är inte tillräckligt att ett objekt är unikt identifierat i ett system eller i en fil. Objektets identitet måste vara unikt över alla system och filer som kan tänkas lagra eller referera till objektet. Allteftersom fler system integreras är det rimligt att anta att ett givet system kan genomföra transaktioner med flera andra system. Konflikt kan uppstå i systemet om ärenden från två håll innehåller förändringar på ett och samma objekt. Konflikten måste lösas upp och i det läget kommer versionsidentiteter till nytta. Versionsidentiteten kan styra om ett objekt kan läsas in i det mottagande systemet eller ej. Om den ena förändringen har utgått från en tidigare version av det aktuella objektet än den andra förändringen kan systemet enkelt avgöra vilket objekt som ska läsas in och vilket som ska ignoreras. [ ] och [19118 A.5.4.4] beskriver en simpel och ofta otillräcklig uppdateringsmekanism för att hantera vissa av dessa aspekter. En mer utvecklad sådan mekanism har därför tagits fram som en svensk standard SS Representation av förändringar i datamängder [07]. Standarden innehåller bl.a. en UML-modell. I korthet kan mekanism och modell sägas hantera: att nya objekt skapats 66

67 att existerande objekt tagits bort att existerande objekt förändrats med avseende på attributvärden ett förenklat transaktionsbegrepp att transaktioner kan bestå av transaktioner metadata för förändringsärenden versionsidentitet konfliktlösning vid transaktioner via versionsidentiteter Modellen omfattar inte: normativa specifikationer eller mekanismer för unika identifierare procedurella beskrivningar av förändringshantering i tänkta tillämpningar 10.8 Genereringsexempel I detta kapitel beskrivs hur en UML-modell konverteras till ett XML-schema. Exemplet innehåller ett antal filer. Dessa återfinns i ramverkets filsystem under XML-generering. Fil Innehåll stanli_xmi_example.mdl Rational Rose modell stanli_xmi_example.xmi XMI modell UMLX13-11.dtd DTD för XMI (Unisys) xmi2xsd.xslt Konverteringsalgoritm stanli_xmi_example.xsd XML Schema iso_profile.xsd Profil av ISO 19118, 19115, stanli_xmi_example.xml XML exempel data Filernas relation beskrivs i följande figur: DTD ISO Profil Rose modell XMI XSLT XML Schema XML Figur 69 - Färgade rutor är automatiskt framställda. Data i XML format refererar till schemat som i sin tur refererar till ISO profilen. 67

68 UML-modellen Nedan visas ett exempel på ett klassdiagram MyModel som refererar till ett standardschema [19103]. Klassdiagrammet är inte ett applikationsschema. Dess syfte är att illustrera olika genereringsmekanismer. ISO19103 MyModel Figur 70 - Paketdiagrammet refererar det standardschema som innehåller vissa datatyper Samtliga klasser i MyModel har en stereotyp, t.ex. <<Interface>>. Användningen av dessa är definierad i [ ]. De vanligast förekommande är representerade i exemplet; de som inte är med är Entity, Control, Boundary, Exception samt MetaClass. <<Interface>> MyInterface + SayHello() <<Abstract>> MySuperClass + date : MyBasicDateType +others_association MyClass + codelist : MyCodeList +others_aggregate + others_attribute [1..n] : MyOtherClass 1..* 1..n MyOtherClass + enum [0..1] : MyEnum + date : Date <<Type>> MyThirdClass /+ calculated : MyEnum + date : MyDateUnion +others_composite 1..* <<BasicType>> MyBasicDateType <<Union>> MyDateUnion + date : Date + value : MyBasicDateType <<DataType>> Date (from ISO19103) + century : CharacterString + year [0..1] : CharacterString + month [0..1] : CharacterString + day [0..1] : CharacterString MyComplexClass + list : Set<Integer> <<CodeList>> MyCodeList + some + list <<Enumeration>> MyEnum + red + green + blue Figur 71 - MyModel är ett klassdiagram i UML De klasser som finns i exemplet är: Klass Illustrerar MySuperClass Abstrakt klass som realiserar ett gränssnitt. MyClass Enkelt arv och relationer till en annan klass. MyOtherClass Enkelt arv och ett omdeklarerat attribut MyThirdClass Abstrakt klass med ett beräknat och ett omdeklarerat attribut MyComplexClass Multipelt arv. 68

69 Ett antal relationer (med förhållandet 1:N) är definierade mellan MyClass och MyOtherClass (eller MyComplexClass som ärver från sistnämnda):. Relation others_attribute others_association others_aggregate others_composition Illustrerar Attributrelation Association Association (aggregat) Association (komposition) Några olika datyper är definierade: Datatyp Illustrerar MyBasicDataType Egendefinierad primitiv datatyp MyDateUnion Endast ett av attributen kan vara satt MyCodeList En utökningsbar värdelista MyEnum En fast värdelista Date Datatyp för att ange ett datum [19103] CharacterString Datatyp för textsträngar [19103] Integer Primitiv datatyp för heltal [19103] Set<T> Parametrisk datatyp för listor [19103] XML Schemat UML-modellen ovan har konverterats med en XSLT-processor enligt ett XSLT-skript som implementerar algoritmerna definierade i ISO och denna handbok. Programmet läser in modellen i XMI format (UML 1.3, XMI 1.1) och genererar direkt ett XML-schema. Med hjälp av programmet XML Spy har ett diagram skapats från schemat. Detta belyser enbart strukturen i schemat; man kan inte se attribut eller datatyper. 69

70 Figur 72 - Översikt över det genererade XML-schemat Exempel på data Följande data exemplifierar en datainstans enligt XML-schemat: <?xml version="1.0" encoding="iso "?> <GI xmlns:xsi=" xsi:nonamespaceschemalocation="stanli_xmi_example.xsd" timestamp=" t13:37:00" version="1.0"> <dataset> <MyClass id="id01"> <date>tuesday</date> <codelist>bd:sg.01</codelist> <others_attribute> <MyOtherClass id="id01_a"> <enum>blue</enum> <date> </date> </MyOtherClass> </others_attribute> <others_association idref="id02"/> <others_aggregate> <MyOtherClass id="id01_b"> <enum>red</enum> <date> </date> </MyOtherClass> </others_aggregate> <others_composite id="id01_c"> <enum>green</enum> <date> </date> 70