Page History

Sekvensdiagrammer

Sekvensdiagrammer (sequence diagrams) har som mål å vise hvordan flere objekter sam- arbeider for å løse en bestemt oppgave. En ”oppgave” i denne sammenhengen vil typisk tilsvare ett brukstilfelle. I figur 4 er det vist to enkle sekvenser i det samme diagrammet. Her får vi illustrert både hvordan man viser metodekall mot eksisterende objekter, ny- skaping av objekter og sletting av objekter. De sentrale konseptene i sekvensdiagrammet vil bli forklart i de følgende delkapitler.

                      Figur 4: Two sequences in the same diagram A.9.1.

Objekter

Objekter vises ved navngitte rektangler som i utgangspunktet plasseres øverst i diagram- metdiagrammet. At det står ”en Bok”, ”en Reservasjon” etc., signaliserer nettopp at det her ikke dreier seg klasser, men om enkeltobjekter av klassene. Hvis man vil kan man også ha med aktører på linje med objektene for å vise hvordan handlingssekvensene initieres ved eksterne kommandoer fra brukeren. Aktørene er vist ved samme notasjon og har samme betydning som før, og vi vil ikke diskutere dem nærmere her, mange bruker dem heller ikke i sekvensdiagrammene. Den observante leser vil ha merket seg at vindusobjektet (det lengst til venstre) ikke er inkludert i klassediagrammet vårt i figur 183. Dette objektet er av en klasse som er del av brukergrensesnittet. Det er ikke noe i veien for å ha med slike objekter i klassediagrammene (tvert imot, de bør modelleres på et eller annet tidspunkt i utviklingen), men vi droppet for enkelthets skyld alle tanker på dette i figur 17 2 for å konsentrere oss om den konseptuelle siden ved biblioteksdomenet.

Hvert objekt vil være utstyrt med en livslinje, nemlig den stiplede linjen som går

44

går loddrett nedover fra hvert objekt. Disse indikerer objektets levetid, og står som et til- knytningspunkt for meldinger. I noen varianter av sekvensdiagrammer bruker man en mer detaljert notasjon hvor det er uthevede partier på livslinjen i de perioder det til- hørende objektet er aktivt, men dette er droppet her. Når det gjelder rekkefølgen på hendelser skal livslinjene leses ovenfra og ned. Et kryss på livslinjen betyr at objektet opphører å eksistere.

Meldinger

Meldinger vises ved piler mellom livslinjene, annotert med meldingens navn. En * foran meldingsnavnet betyr at meldingen kan bli repetert mange ganger. I noen tilfeller kan en melding gå rett til en objektboks i stedet for til dets livslinje, dette brukes når dette objektet blir opprettet (med new).

I figur 19 4 ser vi først at låneren gir en kommando om å reservere en bok (f.eks. ved å fylle inn opplysninger om forfatter og tittel og klikke på en ”Reserver”-knapp på skjer- men). Dette fører til at vindu-objektet sender en reserver()-forespørsel til det aktuelle bok-objektet. Her ser vi for enkelhets skyld bort fra komplikasjoner som kunne føre til at reservasjonen ble avvist. Det fortsetter dermed betingelsesløst med at bok-objektet utfører en new-operasjon som oppretter et reservasjonsobjekt.

I den neste sekvensen, som er satt sammen med den første så vi skal slippe å tegne så mange bokser, bestemmer en låner seg for å slette alle sine reservasjoner. Dette vil føre til en repetert (*) delete-operasjon mot diverse reservasjonsobjekter, og disse opphører å eksistere som følge av handlingen. A.9.3.

Betingelser

For mer presis modellering kan man både angi parametere og dessuten utstyre meldin- gene meldingene med betingelser, angitt i [ ]-parenteser. Hvis en betingelse er angitt, betyr dette at meldingen kun vil bli sendt dersom betingelsen er tilfredsstilt. Et eksempel med bruk av betingelser er vist i figur 205.

45

Image Added

                   Figur 5

Kompendium for Fellesprosjektet TDT4140

Figur 20: Sequence diagram with conditions

I figur 20 5 gir en låner inn et ønske om å forlenge lånet av et eksemplar, dvs. å få utsatt innleveringsfristen. La oss anta at bibliotekets policy på dette er at man standard får 4 ukers utsettelse, såfremt boken ikke er reservert av noen andre. Vinduet sender en for- leng_lån( )-melding til det aktuelle eksemplar-objektet. Eksemplar-objektet må så sende en reservert?( )-melding til det tilhørende bok-objektet, denne vil mest hensiktsmessig returnere true eller false. Nå kommer bruken av betingelser inn i bildet. Hvis boken var reservert, må forlengelsen avvises. Ellers er det i orden å forlenge lånet. Eksemplar- objektet sender da meldingen utvid_frist(4 uker) til seg selv (dvs. kaller en metode i samme objekt), dette kalles selv-delegering (self-delegation). For de øvrige metodekallene har vi ikke inkludert parametere, enten fordi de ikke trengs, eller fordi de antas å være innlysende. Her har vi også valgt å vise hvordan resultater returneres, noe som ofte ikke gjøres i enkle sekvensdiagrammer (kanskje også fordi det ikke returneres noe, eller fordi det anses for innlysende hva som returneres). Hvis boken var reservert, gis melding til- bake i vinduet om at forlengelsen er avvist, samt at låneren påminnes om den gjeldende fristen for innlevering. Ellers gikk forlengelsen i orden, og det vises informasjon om den nye fristen.

Hvis det blir mye betingelser i sekvensdiagrammer, blir de fort uoversiktlige. De fleste eksperter anbefaler heller at man prøver å holde sekvensdiagrammene enkle og bruker aktivitetsdiagrammer der det er behov for å vise flere alternative handlingsmåter. Akti- vitetsdiagrammer blir diskutert på slutten av neste seksjon.

46

Kompendium for Fellesprosjektet TDT4140

Tilstandsdiagrammer

Med tilstandsdiagrammer (state diagrams, evt. state transition diagrams, STD) er man på vei mot en mer presis, formell modellering av systemet, noe à la tilstandsautomater, som vil være kjent fra fag som Diskret matematikk. Mens sekvensdiagrammer egner seg for å vise meldingsutveksling og samarbeid mellom flere objekter, er et tilstandsdiagram best egnet til å vise oppførselen internt i et objekt, i form av alle mulige tilstander dette objektet kan ha, og hvilke overganger som er mulige mellom disse. Figur 21 6 viser et tilstandsdiagram for eksemplar-objekter. Konseptene vil bli forklart i de påfølgende delkapitlene.

Image Added

Figur 21                          Figur 6: Tilstandsdiagram for eksemplar-objekt A.10.1.

Tilstander

Tilstander (eng. states) vises som firkanter med avrundede hjørner, og med navn som forklarer hva slags tilstand det er, dette vil typisk være adjektiver. Om man vil, kan man i stedet for selve tilstanden angi hvilken aktivitet som foregår mens objektet er i tilstanden, eller eventuelt angi både tilstand og aktivitet. Dette har vi gjort for tilstan- den øverst til venstre, ”Uklar”. Et eksemplar vil befinne seg i denne tilstanden enten med det samme det er anskaffet, da man må initiere det (sette på strekkode og magnetstri- pe for tyverisikring), eller hvis slitasje gjør det nødvendig med vedlikehold. Således er aktiviteten her ”Initiering eller vedlikehold. Forøvrig har vi holdt oss til å kun navngi tilstander. ”Tilgjengelig”, ”Utlånt” og ”Savnet” burde være selvforklarende. ”Avlagt” inne- bærer at eksemplaret befinner seg i biblioteket, men er reservert av noen. Som vi husker fra klassediagrammet, gjaldt reservasjoner egentlig bøker, ikke eksemplarer, men den som har reservert, vil jo i så fall ønske det første eksemplaret biblioteket får kloa i, dette blir altså avlagt (f.eks. lagret ved disken, hvor låneren kan hente det).

47

.

Kompendium for Fellesprosjektet TDT4140

Start og stopp

Start og stopp vises ved svarte rundinger, stopp med en hvit rand rund. Pilen fra Start- rundingen viser hvilken tilstand objektet vil befinne seg i når det oppstår, i dette tilfellet ”Uklart”. Piler som går til Stopp-rundinger viser fra hvilke tilstander objektet kan opphøre å eksistere, i dette tilfellet fra ”Uklar” og ”Savnet”.A.10.3.

Overganger

Overganger (eng. transitions) vises som piler mellom to tilstander, eller mellom en til- stand og start/stopp. Pilens retning forteller hvilken vei overgangen går, og den vil være annotert enten med navn på hendelsen som fører til overgangen og/eller en betingelse for når overgangen vil skje. Betingelser står i [ ]-parenteser, mens navn på hendelser står uten. I vårt eksempel er det altså noen overganger som bare har hendelsesnavn (f.eks. fra ”Tilgjengelig” til ”Savnet”) og noen som bare har betingelser (f.eks. fra ”Tilgjengelig” til ”Uklar”), og noen som har begge deler. Dette er valgfritt, man tar det som best illustrerer handlingsgangen.

Mens objektet tilbringer tid i de forskjellige tilstandene, er overgangene formelt sett ment å være momentane, dvs. ta null tid. Med hendelsen ”innlevering” mener man altså ikke hele handlingsgangen fra låneren kommer fram til disken og sier ”Jeg ønsker å levere inn denne boka” til innleveringen faktisk er blitt registrert og samtalen avsluttes med noen høflighetsfraser. Nei, her representerer hendelsen kun det øyeblikket akkurat da eksemplaret går fra å være utlånt til innlevert fra datasystemets synsvinkel, f.eks. ved at en statusverdi endres i databasen. Overgangen representerer altså kun det momentane skiftet av tilstand, ikke hva man gjør for å oppnå dette skiftet. Eventuelle betingelser innebærer derfor heller ikke at det gjøres noen vurderingen underveis på pilen (siden dette jo ville ta tid) – vurderinger av betingelser må eventuelt ha skjedd mens objektet fortsatt befant seg i fra-tilstanden.

Vårt eksempel kan nå forklares. Eksemplaret starter i den nevnte ”Uklar”-tilstanden. Når det er klargjort, vil det bli ”Tilgjengelig”, med mindre noen allerede har rukket å gjøre en reservasjon. I så fall blir eksemplaret ”Avlagt” (f.eks. lagret ved disken, i påvente av henting) for den som har reservert det. Når denne henter det avlagte eksemplaret, vil det bli ”Utlånt”, det samme skjer med et tilgjengelig eksemplar ved utlån. Her er betingelsen at eksemplaret er ”lånbart” – leksika og andre oppslagsverk vil det normalt være ulovlig å ta ut av biblioteket, men de er likevel tilgjengelige for studier på stedet. Når et utlånt eksemplar leveres tilbake, kan en av tre overganger inntreffe. Hvis eksemplaret er i ustand, sendes det på reparasjon, dvs. det blir ”Uklart” (dessuten må vi tro at låneren får et erstatningskrav, men dette vil ikke være med i vårt tilstandsdiagram, som bare tar for seg det som skjer med eksemplar-objektet). Hvis eksemplaret er i stand, og det ikke foreligger noen reservasjon av boken, vil det igjen bli tilgjengelig. Om det derimot fins en utilfredsstilt reservasjon for boken, vil det bli ”Avlagt”. Om den som har reservert, trekker reservasjonen tilbake, eller ikke henter eksemplaret innen en viss frist, blir det igjen ”Tilgjengelig”, med mindre det fins flere reservasjoner, da blir det ”Avlagt” til den neste i køen. Hvis en låner melder et eksemplar tapt, eller fortsatt ikke leverer etter et

48

et visst antall purringer, blir det ”Savnet”. Det samme kan skje med eksemplarer som ikke var utlånt, hvis man plutselig ikke finner dem på forventet plass biblioteket (kan være stjålet, feilplassert, feilaktig kastet, hvem vet?) Siden savnede eksemplarer kan dukke opp igjen, ønsker man ikke å slette objektet straks det meldes savnet eller tapt, i stedet venter man 3 måneder før man sletter objektet. Sletting kan også skje hvis man bestemmer seg for å kaste eksemplaret etter å ha funnet ut at det ikke lenger er verdt å reparere i tilstanden ”Uklar”.

Hvis tilstandsdiagrammene blir komplekse, kan det lønne seg å dekomponere dem, dvs. at noen tilstander kan ha sub-tilstander inni seg. I vårt første eksempel har vi overhodet ikke modellert komplikasjonene som inntreffer hvis en låner ikke returnerer et eksemplar i tide, annet enn at det til sist kan gå over til ”Savnet”. En mulighet kunne være å skille mellom to tilstander, en kalt ”Utlånt” som før, og en kalt ”Overlånt”, som innebærer at låneren har oversittet fristen. Hvis biblioteket har et fast system for purringer, f.eks. at man først venter til det har gått en uke over fristen, deretter sender ut første purring, så venter i ytterligere to uker før man sender ut andre purring, og deretter venter ytterligere tre uker før man sender siste purring, med beskjed om at låner må betale erstatning hvis man ikke leverer innen en uke. For en presis modellering kunne man her operere med en tilstand for hvert stadium i denne purringsprosessen. ”Overlånt” kan bety at fristen er utgått (men fremdeles med mindre enn en uke, slik at man ikke har purret ennå, hvilket innebærer at låneren kun får forsinkelsesgebyr, ikke purregebyr), deretter har man tilstandene ”Førstegangspurret”, ”Andregangspurret” og ”Sluttpurret”. Selvsagt kunne vi inkludere alle disse tilstandene på samme nivå som de vi allerede har i figur 216, men dette ville bli nokså uoversiktlig. Et bedre alternativ er vist i figur 227, hvor vi som før har en ”Utlånt”-tilstand, bare at denne er dekomponert i fem sub-tilstander (”Normal”, som betyr at man fortsatt er innen fristen, pluss de fire stadiene av overskridelse).

Image Added

Figur 22                                        Figur 7: En dekomponert tilstand

Som vi ser går pilene på venstre side inn til supertilstanden ”Utlånt”, som er navngitt i et lite rektangel i kanten av den store boksen, og ikke til noen av subtilstandene. Da trenger vi et nytt start-symbol inni ”Utlånt”-tilstanden for å vise at man begynner i tilstanden ”Normal” (dvs. vanlig utlån, innen fristen). Alternativt kunne vi her ha kjørt pilene utenfra rett til ”Normal”, dette er en smakssak. Her har vi uansett ikke tjent noe

49

noe i forhold til å modellere uten dekomponering. Fordelen med dekomponering kan derimot ses på høyre side. De tre pilene for ”innlevering” og den ene for ”tapsmelding” går her fra supertilstanden ”Utlånt” og ikke fra subtilstandene. Låneren kan jo på et hvilket som helst stadium i purreprosessen komme til å levere tilbake eksemplaret, eller melde det tapt. At pilene går fra supertilstanden indikerer nettopp dette, at overgangene kan skje uansett hvor man befinner seg inni den dekomponerte tilstanden. Hvis vi skulle ha modellert alle disse tilstandene uten bruk av dekomponering, måtte vi hatt tre innleveringspiler og en tapspil fra hver eneste av disse tilstandene. Dette ville gi et temmelig kaotisk diagram. Nå er det kun pilen til ”Savnet” i tilfelle låneren lar fristen gå ut uten å gi respons, som må gå fra en intern tilstand. Dette gjør ikke noe, for denne overgangen er kun aktuell fra ”Sluttpurret”, så den resulterer bare i en pil likevel.

Når man dekomponerer en tilstand i flere sub-tilstander, er det fortsatt meningen at objektet bare kan befinne seg i én av disse tilstandene om gangen. Men i noen tilfeller kan det også være interessant å operere med parallelle tilstander, hvor altså objektet kan være i flere tilstander på samme tid. Dette brukes når objektet kan gjennomgå flere forskjellige typer tilstandsendringer som er uavhengige av hverandre. Anta for eksempel at en bok kan være "Hyllet"(plassert i bibliotekets hyller, slik at lånere kan finne den selv) eller "Magasinert"(plassert i magasin, slik at det trengs en spesiell forespørsel til personellet for å få tak i den). En bok kan også være Lånbareller "Ulånbar"(det siste vil gjerne være tilfelle for leksika og lignende, evt. også bøker som pga. alder eller sjeldenhet har nådd en betydelig verdi). For det tredje kan en bok være registrert som Populær", "Middelseller "Upopulær", alt etter hvor stor etterspørsel det er etter den (for eksempel basert på oppsamlede data, eller bibliotekspersonellets subjektive oppfatning). La oss her se bort ifra de eksakte kriteriene for at det skal skje endringer fra den ene tilstanden til den andre, men anta at de tre nevnte dimensjonene er uavhengige av hverandre. Dvs., en bok kan være "Hyllet, lånbar og populær", "Hyllet, lånbar og upopulær", "Magasinert, ulånbar og upopulær", etc., etc. Uten bruk av parallelle tilstander ville vi nettopp være nødt til å operere med slike komplekse tilstandsbetegnelser, og i alt ville vi få 12 tilstander (2 x 2 x 3).

For å unngå en kombinatorisk eksplosjon av tilstander når man har uavhengige alter- nativ, er det bedre å bruke parallelle tilstander. I UML er dette gjort ved å dele opp en tilstandsboks med stiplede linjer, hvert avdelt område tilsvarer da en parallell. Dette er vist i Figur 238.

50

Image Added

                                            Figur 8

Kompendium for Fellesprosjektet TDT4140

Figur 23: Tre parallelle tilstander

Aktivitetsdiagrammer kan oppfattes som en variant/utvidelse av tilstandsdiagrammer. Som nevnt i innledningen om tilstandsdiagrammer kunne vi inni en tilstandsboks navngi selve tilstanden og/eller den aktiviteten som foregikk i tilstanden. Aktivitetsdiagrammer vil altså være tilstandsdiagrammer der man kun, eller i hovedsak, opererer med aktivite- ter. I den grad man fortsatt ønsker å inkludere selve tilstandsendringene i diagrammet, vil disse nå være vist som rektangler (med objektnavn, [tilstand]), koblet med stiplede piler til de aktiviteter som forårsaker tilstandsendringene. I tillegg har man en del andre konstruksjoner, f.eks. for å vise valgmuligheter, synkronisering og parallellprosessering.

For valg har man rombesymboler à la hva man vil være kjent med fra algoritmiske flytdiagrammer. I flytdiagrammer har man ofte bare to veier ut fra romben (f.eks. J og N, alt etter om betingelsen er sann eller usann), men i UMLs aktivitetsdiagrammer kan man ha piler ut, hver annotert med betingelsen for at denne skal velges, f.eks. [x<0], [x=0], [x>0]. Synkronisering og splitting vises begge ved en tykk stolpe som piler går inn til og ut fra. Flere piler inn og en ut betyr synkronisering – flere parallelle aktivitetstråder fortsetter i en felles. En pil inn og flere ut betyr splitting – en aktivitetstråd videreføres i flere parallelle aktiviteter. Denne symbolikken er vist i Figur 249.

51