Universitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte

Transkript

1 Universitetet i Oslo Institutt for informatikk Eskild Busch UML hefte 6. desember 2000

2

3 Innhold Dette heftet tar for seg deler av UML som er sentralt i kurset IN29. Use case-, sekvens-, tilstand- og klassediagrammer, samt noe av deres indre funksjonalitet, vil bli behandlet i dette heftet. Eksemplene her er kun ment å vise ulike modelleringsfunksjonaliteter i de respektive diagrammer i UML, og ikke ment å være en korekt modellering av et system. PÅ figurene i dette heftet har jeg satt på lapper med nummer, disse numre er beskrevet under tilhørende diagram. iii

4 Innhold Use case 2 Sekvensdiagram 3 3 Tilstandsdiagram 5 4 Klassediagram 7 Figurer Eksempelpåusecasediagramm Eksempelpåsekvensdiagramm Eksempelpåtilstandsdiagramm Eksempelpåklassediagramm iv

5 Use case Et use case (ellipse) presenterer en del av funksjonaliteten til et system. Det kan være funksjonaliteten til et system, subsystem eller for en klasse slik den opptrer for en bruker utenfor systemet. Diagrammet viser er en overordnet funksjonalitet ved systemet, dvs generelle hendelser i systemet. I figur er New Customer et use case som inneholder en generalisering av flere hendelser som kommer til å skje i det ferdige systemet. Aktøren Clerc starter denne hendelsen. En aktør (strekmann) trenger nødvendigvis ikke å være en bruker, men kan være et system i seg selv. Aktøren kan ikke være det systemet som skal modelleres. Det er viktig å ikke tenke objekter og programmering, men i stedet uttrykke alle de generelle bruksmønstre (use case) som vil skje med systemet. Det vil si at man skal lage en generell hendelse som kan involvere flere objekter i det ferdige systemet. Man bruker så et eller fleresekvensdiagram for å vise hendelsesforløpet til et slikt use case, der man viser flyten av data/meldinger/kontroll mellom objekter. Videre følger en forklaring til de nummererte firkantene i figur.. Se figur. En pil med fylt pilhode uttrykker at kommunikasjon kun kan gå en vei. Dette brukes typisk når aktøren skal sette i gang en hendelse, og ikke trenger tilbakemelding fra systemet. 2. Se figur. Use case Balance er en spesialisering av use case Check acount. Dette er en vanlig arving, der Check acount er foreldre use case og Balance barnet. Balance inneholder oppførselen til Check acount, samt muligheten for egne spesielle hendelser, altså en spesialisering. 3. Se figur. I use case New Customer skal det i tillegg til å registrere en ny kunde, også forekomme opprettelse av en ny konto. Dvs. denne type pil med label:include, sier at Create Acount skal være en del av det å opprette New Customer. 4. Se figur. En strek mellom en aktør og et use case betyr at dette er en assosiasjon. Denne assosiasjonen utrykker at en aktør er en deltager i dette use case, f.eks instanser av aktøren og instanser av use case kan kommunisere med hverandre. 5. Se figur. I use case Redraw Card, tillegges use case Check Acount spesielle egenskaper. En User skal sjekke kontoen sin. Dersom det av en

6 grunn er satt en inndragning av dette kortet fra banken, skal use case (Redraw Card) skje som en hendelse i systemet. Med andre ord kan man tillegge et use case spesielle hendelser dersom det oppstår et behov for det. I tillegg kan man bruke dette use case i forbindelse med andre use case i systemet. Dersom man vil spesifisere hva som skal trigge dette use case, så kan man angi dette som en label ved siden av pilen. Figur Eksempel på use case diagramm. User Clerc Balance. Amount 4 5 Check acount Balance New Customer extend include Redraw Card Om feil kode 3 ganger Create Acount 2 3 2

7 2 Sekvensdiagram Et sekvensdiagram viser mønsteret av interaksjon mellom ulike objekter, samt tid og kontroll aspekter ved et system. Man bruker det til å modellere komplekse løsninger i domenet der man utvikler systemet, og tar gjerne utgangspunkt i use case diagrammer. Dersom man har modellert use case for et system, så bør man lage et eller flere sekvensdiagram for hvert av de. Sekvensdiagrammet er en todimmensjonal fremvisning, der man har tiden vertikalt og interaksjonen mellom objekter horisontalt. Hver sekvens kan bare ha en som starter hendelsen, men man kan ha flere sekvenser i et diagram. Dvs. man kan ha aktør objekt objekt aktør. Videre følger en forklaring til de nummererte firkantene i figur 2.. Se figur 2. Dette er et eksempel på 4 funksjonaliteter. Den tykke pilspissen indikerer dette et metodekall eller en flyt av kontroll. Metodekallet på log_on skal ha en returverdi, Boolean. Denne returverdien trenger ikke å angis som en pil (se punkt 7), da den er angitt som Metode_Kall:Returverdi. Objektet System er et objekt som eier en egen prosess, og kan starte egne aktiviteter. Kallet på log_on(), skal ligge som en metode i en klasse som heter System, dvs. når man skriver en label på en pil av denne typen, skal denne ligge i klassen pilspissen peker på, som en metode. 2. Se figur 2. Disse to objektene er vanlige objekter, som er en instans av en klasse. Disse har ikke mulighet til å eie sine egne prosesser. Dvs at objektene er vanlige objekter i det kommende programmet, og har kun en tilstand. 3. Se figur 2. Setter en tidsbestemmelse på hendelsen. I dette tilfellet skal man ha sjekket om kontonummeret er ledig på en tid som er mindre en 5 sekunder. 4. Se figur 2. X : Terminerer et objekt som ikke trengs lenger. Dvs. etter å ha sjekket om kontonummeret er ledig, kan man frigjøre dette objektet. Det er ingen hensikt å la det eksistere lenger. 5. Se figur 2. En åpen pil betyr at det sendes et asynkront signal, i dette tilfellet har systemet utført det brukeren ber om. Og angir at den er klar for en ny oppgave. Denne typen pil forventer et svar fra bruker. 3

8 6. Se figur 2. Rektangelet viser hvor lenge objektet er aktivt. Der pilen kommer inn til objektet blir det aktivert (aktivert er her ment som at man bruker objektet), og lengden på rektangelet viser hvor lenge det er aktivt. Mange forbinder dette med tidsforløpet til et objekt, noe jeg syntes er feil. Grunne til dette er at et objekt kan leve lenge i et system uten å være aktivit. 7. Se figur 2. Denne typen pil er en annen måte å angi returverdi på. Dvs. man kan angi returverdier på denne måten eller som vist i.. I eksempelet returnerer jeg hele objektet Customer. 8. Se figur 2. Denne typen pil indikerer en asynkron kommunikasjon mellom objekter. I dette eksemplet har jeg satt den til å gi en melding til Clerc når han har forsøkt å opprette en Acount 5 ganger. Da skal man avbryte og returnere til Clerc med meldingen something is wrong. Denne type pil forventer ikke svar fra bruker. 4

9 Figur 2 Eksempel på sekvensdiagramm. Clerk 2 :System :Customer log_on():boolean create_new_user() create_acount():acount If Boolean=false 5 times: something is wrong Customer controll() :Acount 6 chek_nr Boolean 4 :Is_Acount_Free < 5 sek 3 3 Tilstandsdiagram Tilstandsdiagram brukes for å vise dynamiske hendelser for en klasse, et use case, en aktør, et subsystem, en operasjon eller en metode. Det man ønsker å vise frem med et slikt diagram, er livssyklusen for det aktuelle tilfellet. På figur 3 ser dere at dette er noe som skjer i tid. Man har en starthendelse som går inn i en tilstand, i dette eksemplet en sammensatt tilstand. En ansatt kan ha flere funksjoner i denne tilstanden, men av plasshensyn er disse utelatt. Videre har man tilstander utenfor den sammensatte tilstanden. Disse kan også observeres og gå over tid. I tilstandsdiagrammer skal man bruke fortid i den beskrivende label på pilene. En god regel er å bruke ordet ble inne i setningen. Pilen som brukes i denne type diagram, viser hendelsen som tar plass i diagramm- 5

10 et. Videre følger en forklaring til de nummererte firkantene i figur 3.. Se figur 3. Starttilstanden er den første tilstanden av oppførsel til et objekt eller lignende, etter at det er opprettet. Eksempelet jeg bruker her, har jeg flere slike starthendelser. Den første som ligger utenfor supertilstanden, viser hendelsen når en ansatt blir logget på. Videre er det to nye starttilstander inne i supertilstanden. Grunne til dette er at en ansatt kan velge ulike handlinger i denne supertilstanden. 2. Se figur 3. Seleksjon: man går fra en tilstand til en ny. Dvs. ved hjelp av seleksjon kan man velge å gå over til en annen tilstand. 3. Se figur 3. Disse er med for å vise sekvensielle tilstander. Som navnet sier, så er dette et sekvensielt skifte av tilstander. 4. Se figur 3. Iterasjon: noe som kan skje flere ganger på samme tilstand. (kunde ble registrert, kunde ble slettet). Denne hendelsen kan skje utallige ganger innen en klasse etter at den er blitt initiert, og ikke er avsluttet. I dette eksemplet kan en Clerc gjøre disse operasjonene flere ganger på forskjellige kunder. 5. Se figur 3. Denne kalles en supertilstand. Dens funksjon er å generalisere deler av et diagram. På utsiden av diagrammet kan man behandle denne tilstanden som en enkelt tilstand. 6

11 Figur 3 Eksempel på tilstandsdiagramm Ansatt ble logget på Er logget på Kunde aktiv kunde sjekkes kundeforhold ble aktivisert kunde ble aktiv konto åpnet kunde ble registrert kunde registrert konto ble laget kunde ble registrert(dato) kunde ble slettet(dato) Ansatt ble logget av 3 T T2 T3 T4 4 Klassediagram Klassediagram viser den statiske strukturen for en modell, spesielt de ting som eksisterer (slike som klasser og typer), deres interne struktur, og relasjoner til andre klasser/typer. Typer er en annen form for objekter enn de som kommer fra klasser, de kommer fra objekttyper. Ved hjelp av et klassediagram kan man vise hvordan de ulike klasser/typer er relatert til hverandre. Et klassediagram er en graf av klassifiseringselementer knyttet sammen ved deres statiske relasjon. Merk at et klasse diagram også kan inneholde interfaces, pakker, relasjoner og instanser (slik som objekter eller linker). For hver type objekt eller klasse har man karakteristika (attributter) og prosesser det kan utføre (metoder). Videre følger en forklaring til de nummererte firkantene i figur 4.. Se figur 4. 7

12 Dette er et symbol som representerer en klasse/objekt, som heter klasse. Klassen er den beskrivende delen for et objekt, disse objekter har lik struktur, oppførsel og relasjon. Modellen er opptatt av å beskrive intensjonen for dette objektet, dvs. regelen som definerer den. Øverste del av den er satt av for å angi navnet på klassen/objektet. Midtre del brukes for attributter, og nederste del er for metoder. 2. Se figur 4. Denne typen symbol er en generalisering. Det er en form for relasjon som brukes mellom et generelt element (foreldre (Person)) og et mer spesifikt element (barnet (Clerc og Customer)). Barnet er fullstendig konsist med det første elementet (foreldre) og i tillegg til å ha ekstra informasjon (metoder og/eller attributter). Denne typen relasjon kan brukes på klasser, pakker, use cases, etc. 3. Se figur 4. Denne typen symbol er en aggregering Det er en form for relasjon der man må spørre seg selv: Er et eller flere av den ene klassens objekter en del av et eller flere objekter av den andres klasse? I eksempelet kan man si det slik: Et System skal ha en eller flere ATM, ogenatm skal være knyttet til et System objekt. Det jeg tenkte når jeg modellerte dette, var at for å ha et System så må man ha en ATM. AltsåerATM en del av det å ha et System. Dvs. her er helheten System klassen/objektet og delen er klasse/objekt ATM. Det som også er viktig å merke seg her, er at en del kan tilhøre mer enn en aggregering, og den kan eksistere uavhengig av helheten. 4. Se figur 4. Denne typen symbol er en komposisjon. Det er en form for relasjon som er lik aggregering, men som er mye strengere. Med komposisjon kan et delobjekt (Acount) kun tilhøre et helhetsobjekt (Customer), og delobjektene er forventet å leve og dø med helhetsobjektet. I eksempelet inngår Acount som et delobjekt av helhetsobjektet Customer. Når Customer objektet blir opprettet, skal man også opprette et Acount objekt som skal eksistere like lenge som Customer eksisterer. Acount kan ikke være i en aggregering eller komposisjon med andre objekter. 5. Se figur 4. Dette er en måte å gruppere klasser inn i et høyere nivå. Pakker/Klynger (Jeg kommer til å bruke ordet pakker her) kan danne sitt eget subsystem. Med dette menes en gruppe klasser som hører sammenogsomkanmodelleresforsegselv.ieksempelettilhører klassene System og ATM (minibank) naturlig sammen i en egen 8

13 pakke, mens de resterende er klasser som kan være frittstående. Et eksempel til gjelder programmeringsspråket Java. Her er alle pakkene man innhenter gjennom import setningen, pakker. Import java.io.* sier at man skal hente inn pakken java.io, som er en del av hele API til Java, altså et eget subsystem. 6. Se figur 4. Dette symbolet er en assosiasjon. Den beskriver relasjoner mellom instanser av klasser (begge ender kan være knyttet til samme instans, men der de to endene er forskjellige). Man kan ha ulike forhold mellom objektene, en til en, en til mange, mange til en, etc. etc. I eksemplet kan man lese asossiasjonen slik: en Clerc kan ha null til et System, ogetsystem kan ha null til mange Clerc. Dvs.når man er Clerc i dette systemet, skal man være tilknyttet et System objekt, samt at et System objekt kan ha ingen eller mange Clerc objekter. Banksystemet kan eksistere uten å ha noen Clerc. 9

14 Figur 4 Eksempel på klasse diagramm. 5 6 Bank System * log_on():boolean Clerc System System has ATM..* ATM is in a System ATM 3 pay_out_money Person name:string = new String(this) 2 Clerc emplyeeid:int..* Customer customernumber:int create_new_user():customer 4 0..*..* IS_Acount_Free Acount check_nr():booean create_acount():acount_id 0