UML Modellering Grunnregler og retningslinjer UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Vi går litt dypere inn i materien! Vi har sett på hvordan vi strukturer objektkatalogen i UML Pakker Objekttyper Egenskaper Datatyper Kodelister Hvordan modellerer vi videre Informasjonsmodellen (Application Schema) Identifisere objekttyper Se på forholdene objekttypene imellom Grunnleggende mekaniser og løsninger UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Informasjonsmodellen! (application schema) Beskrive fagområdet Gi en korrekt beskrivelse av objekter, egenskaper og forhold innenfor hvert fagområde (vegnett,bane++) Mennesklig forståelse Grunnlag for implementasjon, dataforvaltning og utveksling Datamaskinen må kunne lese modellen og dermed bruke rutiner for å oversette modellen til andre formater Konseptuelle språk (igjen) utvetydig og konsistent representasjon av modeller gir grunnlag for applikasjoner (FKB,AREALIS, ++) UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Informasjonsmodellen er implementasjonsuavhengig! UML beskriver en modell uavhengig av system Modellene kan oversettes til ulike systemer Vi beskriver retningslinjer for å lage en slik modell Vi følger samtidig internasjonale føringer ved bruke en akseptert objektmodell (UML) er konforme med ISO19100 serien Følger systemleverandørerer standarden kan alle snakke sammen UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Hvordan lager vi informasjonsmodellen? Identifiser objekttypene som tilhører den ønskede verden Objekttypene modelleres som UML klasser Identifiser egenskapene som tilhører objekttypen egenskapene modelleres som UML attributter Bestem hva slags datatype egenskapene skal ha Kan være basal, brukerdefinert eller kodeliste Egenskapsnavn skrives med liten forbokstav Identifiser forhold mellom objekttypene! Hvordan identifisere og beskrive forhold? UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Identifisere forhold Finnes det en objekttype som har klar sammenheng med en annen? Typisk eksempel er en flate og dens avgrensning Finnes det en stor ting som består av flere mindre ting? For eksempel et flateområde som består av flere delområder Finnes det objekttyper som kan klassifiseres som en art av en annen? Er en objekttype en spesialisering av en annen? UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Forhold mellom objekttyper For å modellere forhold mellom objekttyper bruker vi to mekanismer Assosiasjon (Association) Sammenheng mellom objekttyper Generalisering (Generalization) Forelder og barn klassifisering UML definere også andre typer forhold Avhengigheter Brukes mest for pakker (har vi sett på tidligere) Realisering Programmeringsspesifikt (en klasse realiserer et interface) UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Assosiasjon Det mest generelle forholdet vi bruker En assosiasjon angir semantisk sammenheng mellom to objekttyper. Jeg liker å tenke på assosisjoner som veier/lenker til andre objekttyper jeg kan se, snakke med og hente informasjon fra :) En assosiasjon betegnes med heltrukken linje mellom objekttypene Assosiasjonen tilegges også rollenavn og multiplisitet UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Roller og multiplisitet Rollenavn beskriver en objekttypes forhold til en annen GangSykkelvegAvgrensning spiller rollen som avgrensning for GangSykkelVeg GangSykkelveg spiller rollen som veg for GangSykkelVegAvgrensning Multiplisitet beskriver hvor mange instanser som er lovlige En GangSykkelveg har 1 eller to avgrensninger En GangSykkelvegAvgrensning avgrenser bare en GangSykkelveg UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Rollenavn Rollenavn skrives med liten forbokstav og store bokstaver på etterfølgende delord Rollenavnet skal helst være substantiv Skal angi rollen en objekttype spiller for en annen Mange er litt slepphendte med å angi rollenavn på begge ender av assosiasjonen Regelen er at man i hvert fall skal ha rollenavn på den ”viktigste” enden Ofte vil den andre være invers Dermed også vanskelig å finne et fornuftig rollenavn UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Kardinalitet/multiplisitet Hvor mange instanser kan lovlig assosieres med en annen? ? Forklaring Eksempel 1 1 og kun 1 instans Husk! En objekttype angir ett sett instanser. 0 eller flere 0..* 0 eller 1 0..1 1 eller flere 1..* Ett spesifisert antall instanser 1,3,7 UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Pil eller ikke pil på assosiasjoner Hva betyr disse pilene på assosiasjonene mellom objekttyper. I UML snakker man om navigering mellom objekter Noen ganger ønsker man kun å navigere en vei! Gitt en bruker, må systemet kunne finne brukerens passord Finner man et passord bør systemet sørge for at man ikke kan finne passordets eier Vi bruker ikke piler på assosiasjonene såfremt det ikke er noe spesielt, jamfør eksempelet over UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Typer assosiasjoner En assosiasjon mellom objekttyper kan tillegges ytterligere semantikk Vi har to typer: Aggregering åpen diamant på den ene enden av assosiasjonen beskriver en ting og dens deler (beskrivende) Komposison eller sterk aggregering fylt diamant på den ene enden av assosiasjonen delene er strengt assosiert med helheten (utøvende) UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Aggregering En aggregering er kun et konseptuelt begrep. Assosiasjonen beskriver forholder mellom det hele og deler av helheten. Skiller hvem av objektypene som organisasjonsmessig er overordnet. En aggregering beskrives ved en åpen diamant på assosiasjonsenden som er helheten. Eksempelet viser at en gang og sykkelveg har en eller to avgrensningslinjer, veien er helheten og avgrensningen er delen. UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Komposisjon - sterk aggregering En komposisjon angir at objekter av objekttypen på "diamant-siden" har, eller eier objekter av objekttypen på "strek-siden" som komponenter De eide objektenes oppretting og eksistens følger eier-objektets eksistens Komposisjon i eksemplet betyr at KpSamferdsel-Linje ikke kan eksistere uten et KpOmråde UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Eksempel på aggregeringer Eksempel fra SOSI-Plan -KpOmråde har et restriksjonsområde -KpRestriksjonsområde kan ikke eksistere uten KpOmråde -KpRestriksjonOmråde består også av en avgrensning Denne kan være en avgrensning til en annen objekttype! Hva fins på andre siden av avgrensningen? UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Generalisering Generalisering beskriver et forhold mellom det generelle (supertype) og det spesielle(subtype) En objekttype (den generelle) kan finnes i en mer spesifikk versjon (spesialiseringen) Et kjøretøy er enten en bil eller et tog. Generalisering representeres ved en rettet linje med en stor åpen pil rettet mot supertypen Ingen multiplisitet eller rollenavn! UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Mer om Generalisering En spesialisert objekttype arver egenskaper, operasjoner og assosiasjoner av den generelle En supertype kan være abstrakt, dvs. at den aldri instansieres som seg selv, men som en av subtypene Abstrakte supertyper skal angis med klassenavn i kursiv. Kjøretøy er abstrakt (kursiv). Vil aldri finnes et kjøretøy objekt, bare en bil eller et tog! UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Modellelementer i informasjonsmodellen! UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Deler av UML vi bruker Objekttyper Egenskaper Forhold Oppførsel Note multiplisitet på egenskaper enumeration (møtedag) kodeliste (produsent) datatype (adresse) basal datatyper (real,heltall) Forhold assosiasjon (rollenavn,multiplisitet) aggregering komposisjon generalisering Oppførsel Note UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Gjenbruk av modell-elementer Samme objekt dukker ofte opp i flere datasett Unødvendig å modellere objektet en gang til Objekttypene modelleres ett sted og benyttes på tvers av fagområder TekniskeAnleggSomDelAvKystkonturen KaiKant MoloKant Bølgebryter PirKant SlippKant SpuntveggKant Strømbryter Sluse UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Gjenbruk av andre elementer Samme gruppeelement kan brukes av flere fagområder Unødvendig å modellere elementet igjen Her er datatypen Høyde modellert i pakken SOSIDel1-2 og brukes av NavigasjonsLys i SOSI KystogSjø Høyde + høyde : String + enhet : string + Referansenivå : Referansenivå (from SOSIDel1-2) <<Datatype>> UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Andre former for gjenbruk Modelleres inn som verdien for en egenskap til en objekttype Eiendomsgrense kan følge en verdi definert i kodelisten. Dvs. at eiendoms- grense kan følge havkontur,innsjøkant, bygning, vegkant osv. Metoden er i overens- stemmelse med dagens forvaltningsløsning UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Generelle ting Vi har sett på Herfra ser vi på diverse emner Hvordan bygge opp informasjonsmodellen Mekanismene og notasjonene i UML vi trenger Herfra ser vi på diverse emner Generelle problemstillinger Detaljer og avanserte ting Litt opptil dere hvordan vi går videre Temaer vi skal/kan ta opp Geometrimodellen i SOSI Stereotyper Operasjoner Synbarhet kodelister og verdidomener Utvidelsesmekanismer i UML modellere avgrensninger UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

UML dekker ikke alt! Eksempler på ting som må beskrives andre steder Verbal beskrivelse av fagområdene Definisjon av begreper Evt. link til autoritativ beskrivelse Noter, eksempler, bruksområder Grafiske beskrivelser og eksempler Figurer som viser virkelige objekter Illustrasjoner Mapping av begrepene Oversettelse til annet språk GML SOSI Dette er implementasjonsspesifikt Spesielt informasjonsmodellen for produktet har sterke forbindelser til begreper og objektkatalogen. En grafisk datamodell vil kunne anskueliggjøre objekttypene og deres innbyrdes forhold. I tillegg vil en tekstlig framstilling kunne presentere ytterligere detaljer i informasjonsmodellen. . Ut ifra de abstrakte datamodellene og beskrivelsene i objektkatalogen, vil dataprodusenter kunne: · Plukke ut ønskede objekttyper og deres ønskede egenskapsinnhold. · Legge til egne egenskaper, på en standardisert måte. · Legge til egne nye objekttyper. på en standardisert måte. · Beskrive hvilke avgrensninger i datainnsamlingen som er gjort. UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Veien videre++ UML er et omfattende språk Det fins mange måter å gjøre ting på Det vi har gått igjennom er å regne for retningslinjer erfaringer vi har gjort oss løsninger vi har kommet opp med Fortsatt noen saker som ikke er avgjort Hensiktsmessig at vi modellerer mest mulig ensartet Sikrer felles forståelse!! UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet

Referanser Retningslinjer for datamodellering i UML Foilene Er et foreløpig arbeidsdokument Vil bli lagt ut på SOSI siden Utkastet er tilgjengelig ved forespørsel Foilene Noe har allerede blitt delt ut Foiler kan utleveres ved forespørsel Blir lagt ut på SOSI siden etterhvert UML-seminar 12. og 13. mars 2003 SOSI-sekretariatet