1. Objektorientert systemutvikling

Transkript

1 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Objektorientert systemutvikling Tore Berg Hansen Lærestoffet er utviklet for faget LO314D Prosjektrettet systemarbeid 1. Objektorientert systemutvikling Resymé: I denne leksjonen skal vi se på hvordan man kan arbeide når man skal utvikler systemer objektorientert. Innhold 1.1. INNLEDNING KLASSER OG OBJEKTER OBJEKTORIENTERT ANALYSE MODELLER OG ARTEFAKTER I ANALYSEN UNIFIED MODELLING LANGUAGE (UML) Innledning Litt historie Byggeklossene i UML Strukturelle ting Oppførselsting Grupperingsting Merknadsting Forhold BRUKSMØNSTER Bruksmønsterdiagrammet PROBLEMDOMENEMODELLEN SYSTEM SEKVENSDIAGRAM KONTRAKTER ORDBOK OBJEKTORIENTERT DESIGN ET EKSEMPEL REFERANSER... 33

2 Objektorientert systemutvikling side 2 av Innledning Når man studerer litteraturen om systemutvikling støter man bort i ordet paradigme. Ordet kommer fra gresk og kan bety forbilde, mønster eller felles grunnsyn blant utøverne av en vitenskap. I systemutviklingens korte historie har det vært flere paradigmer. Det betyr altså at synet på hva som er den beste måten å utvikle systemer på, har endret seg med jamne mellomrom. På 1970-tallet kom det strukturerte paradigme med strukturert analyse og design og dataflytskjemaene. Dette paradigmet er behandlet i tidligere leksjoner. Nå er det det objektorienterte paradigme som er mest populært. I denne leksjonen skal se litt på hva det vil si å utvikle objektorientert. Det objektorienterte paradigmet er fremdeles under utvikling. Det har vært, og er ulike oppfatninger både når det gjelder betydningen av begreper og bruk av konkrete fremgangsmåter (metodikken). Vi skal ta for oss én slik fremgangsmåte med tilhørende modeller, og vi skal se på et visualiseringsspråk som kan brukes for å vise disse modellene. Men det første vi skal gjøre er å avklare noen sentrale begreper Klasser og objekter I objektorientering er klasser og objekter det sentrale begrepet. Objekter er flere ting. Det kan være noe konkret fra den virkelige verden, eller det kan være en variabel i et objektorientert programmeringsspråk. I det siste tilfellet bruker men gjerne begrepet instansvariabel. Det kan være hensiktsmessig å klassifisere ting. Ting som naturlig hører sammen fordi de har de samme egenskaper kan man si tilhører den samme klassen. En bestemt ørn som vi observerer på himmelen er et objekt fra den virkelige verden. Vi kan kalle han Ørnulf. Ørnulf har mange egenskaper felles med andre ørner. Den kan fly og den kan fange bytte, den har et vingespenn osv. Dette karakteriserer altså alle ørner og er en måte å klassifisere ørner på. Vi har laget oss en klasse Ørn. Men disse egenskapene har ørner felles med svært mange fugler. Det kan derfor være hensiktsmessig å klassifisere på en slik måte at vi samler egenskaper og adferd som er felles i en klasse som vi kan kalle Fugl. Men en fugl er igjen et dyr. Det som er felles for alle dyr kan vi samle i en klasse Dyr. Det vi her gjør er å generalisere. På den måten kan vi bygge opp et hierarki av klasser hvor vi samler de mest generelle egenskapene øverst. Dette er helt vanlig å gjøre på mange områder i forskjellige vitenskaper. Prinsippet er ført over i objektorientert systemutvikling. Her er et av poengene å bruke de samme begreper (objektbegrepet) også i analyse, design og programmering. På den måten mener man å redusere gapet mellom problembeskrivelse og realisering i et objektorientert språk ved at man hele tiden arbeider med de samme begreper. Men det er en stor forskjell, og som ofte har ført til misforståelser om hva som menes med objekter og klasser i forskjellige sammenhenger. Et objekt i den virkelige verden er én ting, et objekt i et program er en annen ting. En klasse i den virkelige verden er et konsept, mens en klasse i et objektorientert programmeringsspråk er en abstrakt datatype med arv. En abstakt datatype innkapsler data og operasjoner som kan utføres på disse dataene. Operasjon heter metode i Java eller funksjon i C++, som er to av de mest brukte objektorienterte programmeringsspråk. På samme måte som en heltallsvariabel er en instans av datatypen integer, så er et objekt i et program en instans av en klasse. Man sier at man instansierer klassen. Det som skjer er at det avsettes plass til data og operasjoner i minnet til datamaskinen som programmet skal kjøre på.

3 Objektorientert systemutvikling side 3 av 35 Klasser i et objektorientert språk henter gjerne sine navn fra konsepter i den virkelige verden. Vi skal se mer på klassebegrepet, hvordan man finner konsepter i den virkelige verden og overgangen til klasser og objekter som skal programmeres, i senere kapitler Objektorientert analyse I Norsk ordbok (Guttu, 1998) kan man finne denne definisjonen: 1. Undersøkelse som består i at noe sammensatt oppløses i enkelte bestanddeler. 2. Utredning med grunnlag i slik undersøkelse. Eller sagt på en annen måte så er analyse et studium av noe gjennom å undersøke dets deler og sammenhengene mellom dem. Det kan også være resultatet av dette studiet. Innen systemutvikling har analyse tradisjonelt vært forbundet med den første fasen i fossefallsmodellen. Der kalles denne fasen Requirements analysis and definition (Dvs. analyse og definisjon av krav). I neste fase foretar man så design. I praksis følges aldri fossefallsmodellen. Man legger opp til å utvikle iterativt og inkrementelt. Det vil si at man i stedet for å følge sekvens av faser med tette skott imellom, gjentar aktiviteter (itererer) og leverer produktet i deler (inkrementer). Resultatene fra aktivitetene er modeller, dokumenter og produkter (med en fellesbetegnelse kalt artefakter). I objektorientert systemutvikling blir ikke analysen knyttet til en bestemt fase. Men det er noe som gjøres i hele prosjektet. Skillet mellom analyse og design blir også mer flytende. Figuren som følger er hentet fra første utgave av en bok skrevet av Craig Larman (Larman, 2002). Her ser forfatteren overgangen fra analyse til design som gradvis. Hovedvekten i analysen ligger likevel på å finne ut hva man skal lage, mens det i design dreier det seg om hvordan man skal få laget ting på "best mulig måte". Hva som er "best mulig måte" skal vi komme tilbake til. Mer analyseorientert Mer designorientert hva krav undersøkelse av domenet hvordan logisk løsning

4 Objektorientert systemutvikling side 4 av 35 Vi vil i denne leksjonen definere analyse som de aktiviteter og resulterende artefakter som er knyttet til det med å finne frem til og dokumentere kravene til systemet som skal lages. Det er vår definisjon og er ikke nødvendigvis den samme som andre legger i begrepet. Derfor er det nødvendig med en slik begrepsavklaring. F.eks så har Jacobson (Jacobson m.fl., 1999), en av hovedmennene bak Unified Process (UP), i sin beskrivelse av UP en disiplin han kaller analyse. Han skriver: In analysis we analyze the requirements as described in requirements capture by refining and structuring them. Hovedresultatet er hva han kaller en analysemodell. Denne modellen er en klassemodell og skal brukes av utviklere til å klarlegge hvordan systemet skal utformes. Andre vil oppfatte dette som en tidlig design. Mange som praktiserer UP hopper over denne modellen. I dette kurset gjør vi det. Booch, en av objektorienteringens guruer og medarbeider av Jacobson, har denne definisjon (Booch, 1994) av analyse: Objektorientert analyse er en metode for analyse som undersøker kravene i form av klasser og objekter som man finner i vokabularet til problemdomenet. Og Rumbaugh, også en kjent guru, skriver i sin klassiske bok (Rumbaugh m.fl. 1991) at i analysen så bygger analytikeren modeller av den virkelige verden for å vise dens viktige egenskaper. Analytikeren må arbeide sammen med brukeren for å forstå problemet fordi utsagn om problemet sjeldent er komplette eller korrekte. Analysemodellen er en konsis, presis abstraksjon av hva det ønskede systemet skal gjøre, ikke hvordan det skal gjøre det. Objektene i modellen skal være konsepter fra applikasjonsdomenet og ikke programvarekonsepter. Forvirret? Det er etter vårt syn ikke så viktig hva aktivitetene betegnes som. Det som er viktig er at man legger innsats i å finne og dokumentere krav, både funksjonelle og ikkefunksjonelle. Dette krever igjen en grundig forståelse av problemområdet, brukerne og den terminologi som brukes. Derfor skal vi både se på modellering av kravene til systemet, så vel som på modeller for å belyse og forstå det problemområdet systemet skal brukes i. Arbeidet med dette har størst vekt tidlig i utviklingsprosjektet. Og vi understreker at aktivitetene ikke er knyttet til en bestemt fase, som i fossefallsmodellen, men pågår hele tiden.

5 Objektorientert systemutvikling side 5 av Modeller og artefakter i analysen I det vi betegner som analysen er følgende modeller og artefakter de sentrale: Bruksmønster (Engelsk use case, beskriver funksjonelle krav) Ikke-funksjonelle krav Problemdomenemodell (også kalt konseptuel modell) System sekvensdiagrammer Kontrakter Ordbok I tillegg kommer planer, eventuelle prototyper, visjoner og forretningsmuligheter. Disse vil ikke vektlegges i dette kurset ettersom vi her legger hovedvekten på objektorientert analyse og design. Vi skal etter hvert se nærmere på disse modellene. Men før vi gjør det må vi introdusere et visuelt modelleringsspråk som kan brukes til å vise flere av disse modellene i form av diagrammer. Det modelleringsspråket som har størst utbredelse for tiden er Unified Modelling Language (UML) Unified Modelling Language (UML) Innledning Vi har i tidligere leksjoner sett på behovet for og nytten av å modellere. Vi tar et lite sammendrag. Innenfor mange fagområder er det vanlig å lage modeller. Hensiktene kan være flere. Å få prøvet ut ting under kontrollerte betingelser i mindre skala før man setter i gang produksjon. Eksempler er utprøving i vindtunneler av fly og biler. Man sparer penger fordi modellene er billigere å lage enn det endelige produktet. Å ha noe fast å kommunisere rundt for forskjellige interessenter i et prosjekt. I et systemutviklingsprosjekt er det brukere, analytikere, designere, testere, programmerere og eksperter innen forskjellige fagområder. Forskjellige modeller kan brukes til å belyse forskjellige egenskaper ved det tenkte systemet. Det er lettere å føre diskusjoner mellom forskjellige interessenter om egenskapene til et programvareprodukt som er modellert, enn et som bare eksisterer i form av programkode. Når større byområder planlegges lager byplanleggerne modeller som viser hvordan området vil ta seg ut. Slike modeller gir et grunnlag for å fatte beslutninger. Modellene gir bedre forståelse for eventuelle problemer. Å ha et utgangspunkt for en realisering. Snekkere arbeider vanligvis ut fra arbeidstegninger når de setter opp hus. De samme tegningene kan også brukes i en diskusjon mellom arkitekten og de som skal bebo huset. Når barn bygger hytter i trær, trengs ingen arbeidstegning. Men skal det settes opp et bolighus er det helt nødvendig for å komme frem til ønsket

6 Objektorientert systemutvikling side 6 av 35 utforming. Modeller gir med andre ord bedre design. Modellene bidrar til å belyse kravene til det ønskede system. Å håndtere kompleksitet. Gjennom modeller kan man abstrahere bort detaljer og betrakte problemer på et nivå hvor det er mulig å holde oversikten. Vi har også behov for modeller som beskriver hvordan vi kan organisere arbeidet for å oppnå gode resultater. Slike modeller kan vi gjerne si er oppskrifter som skal følges og vi kaller dem prosessmodeller. Et prosjekt er en type prosess. En prosjektmodell forteller hvilke aktiviteter som skal utføres, hvordan aktivitetene kan grupperes og deles inn i faser og rekkefølgen av fasene. Et systemutviklingsprosjekt er en prosess og kan organiseres etter forskjellige modeller. Vi oppsummerer: Vi lager modeller slik at vi bedre kan forstå de systemene vi vil utvikle og vi følger modeller for å kunne håndtere arbeidsoppgaver på en hensiktsmessig måte. Gjennom utviklingsprosessen lager vi forskjellige modeller. Modeller er sentrale produkter gjennom hele utviklingsprosessen. UML (Booch m.fl., 1998) er et modelleringsspråk The Unified Modelling Language. Eller litt mer pragmatisk sagt det er det settet med byggeklosser som gir oss muligheten for å modellere alle viktige sider ved et programvaresystem. Det er et modelleringsspråk fordi det gir oss et vokabular i form av symboler og et sett med regler for hvordan disse symbolene kan brukes for å vise konsepter og den fysiske representasjon av systemet. Vi bruker UML til fire ting. Vi bruker det til å visualisere, spesifisere, konstruere og dokumentere programvaresystemer. UML er et utgangspunkt for å realisere systemer fordi modellene direkte kan avbildes i programmeringsspråk som Java og C++. Under utvikling av programvare fremstilles en rekke produkter (også kalt artefakter) både dokumenter og eksekverbar kode: - Krav - Arkitektur - Kildekode - Prosjektplaner - Tester - Prototyper - Frislipp UML bidrar til å gjøre disse produkter mer forståelige Litt historie Objektorientering er relativt ungt. Mange personer har bidratt med metoder og tilhørende modeller. Blant disse mange er de som er blitt kjent som de tre amigos, nemlig Grady Booch, James Rumbaugh og Ivar Jacobson. UML er resultatet av at disse tre har samordnet (unified) sine metoder og notasjoner i et felles språk. Grady Booch var sterk på design og er kjent for å ha utviklet et rikt modelleringsspråk. James Rumbaugh står bak OMT (Object Modeling

7 Objektorientert systemutvikling side 7 av 35 Technique) som var sterk på analyse. Ivar Jacobson er kanskje mest kjent for sine Use Case og OOSE som legger sterk vekt på å modellere oppførsel (funksjonalitet) Byggeklossene i UML Generelt kan man si at et språk består av et sett med symboler som utgjør ordforrådet og regler for hvordan disse symbolene skal settes sammen og tolkes for å gi mening. Slik er det med naturlige språk, og man gjør de samme betraktninger når det gjelder formelle språk. Eksempler på formelle språk er programmeringsspråk. Og altså språk brukt til visuell modellering. Språk analyseres gjerne på tre nivåer: 1. Det leksikalske nivå hvor man ser på ordene som språket består av og hva som er lovlige ord. 2. Det syntaktiske nivå hvor man ser på reglene for hvordan ord kan settes sammen til setninger. 3. Det semantiske nivå hvor man ser på hvilken mening setninger har. Av og til legger man inn ett ekstra nivå mellom det syntaktiske og det semantiske nivå hvor man er interessert i å se på hva som er tillatte setninger i gitte sammenhenger. Dette nivået kalles gjerne det kontekstuelle nivå. I sin brukermanual (Booch m.fl., 1998) lanserer de tre amigos tre typer byggeklosser som utgjør ordforrådet i UML. Disse er: - Ting (Things) - Forhold (Relationships) - Diagrammer (Diagrams) Ting består igjen av: - Strukturelle ting - Oppførselsting - Grupperingsting - Merknadsting Av forhold er det fire typer: - Avhengighet - Assosiasjon - Generalisering - Realisering Det er ni fundamentale diagrammer: - Klassediagram - Objektdiagram - Bruksmønsterdiagram

8 Objektorientert systemutvikling side 8 av 35 - Sekvensdiagram - Samarbeidsdiagram - Tilstandsdiagram - Aktivitetsdiagram - Komponentdiagram - Deploymentdiagram Ting og forhold dreier seg om hvilke symboler som brukes i UML. Samtidig uttrykker de sammenhengene (konseptene) som vi vil få frem i modellene. Diagrammene er grafisk visualisering av de forskjellige konsepter. Vi skal i det etterfølgende se litt nærmere på disse begrepene Strukturelle ting UML er altså et modelleringsspråk. De strukturelle tingene er substantivene i språket. De utgjør de statiske delene i modellene og kan være både konseptuelle, dvs logiske, og fysiske ting. De strukturelle tingene er klasser, grensesnitt, samarbeidsforhold, bruksmønster, aktive klasser, komponenter og noder. Alle disse er representert med grafiske symboler i UML. Objektorientert systemutvikling dreier seg om klasser og objekter. Klasser og instanser av klasser (objekter) og deres samarbeidsmønstre utgjør den statiske strukturen i programvaresystemet. Derfor vil man alltid lage klassediagrammer for systemet. Et grensesnitt beskriver en ekstern tjeneste som en klasse eller en samling klasser skal tilby. Grensesnitt er spesielt relevant i moderne distribuerte systemer. Disse bygges opp av distribuerte komponenter som kan være på et hvilket som helst sted i et nettverk. Komponentene gjør seg tilgjengelig gjennom et definert grensesnitt som publiseres i nettet ved hjelp av en broker som f.eks CORBA. Et samarbeidsforhold er en samling klasser, grensesnitt og andre elementer som arbeider sammen. De tilbyr funksjonalitet som er større enn summen av funksjonaliteten til enkeltelementene. Bruksmønster er et sentralt begrep hentet fra Jacobsons (Jacobson m.fl., 1992) utviklingsmetode og tatt med i UML. Kort kan vi si at et bruksmønster er et samspill mellom en ekstern bruker og det programvaresystemet som skal utvikles. I denne sammenheng kalles brukeren en aktør. En aktør behøver ikke være et menneske, men kan også være andre systemer som skal samspille med programvaresystemet. En aktør representerer en rolle som spilles i forhold til systemet. Gjennom et bruksmønmster ser vi programvaresystemet utenfra. Gjennom et bruksmønster blir en aktør tilbudt noe av nytte fra systemet. Settet med alle bruksmønstre er den totale funksjonalitet som systemet tilbyr sine brukere. Aktive klasser har instanser som eier en eller flere prosesser eller eksekverbare tråder. Det betyr at de kan kontrollere utførelsen av et program eller deler av et program. De kan også være samtidige. En komponent er en fysisk del av et programvaresystem. En komponent kan være en eksekverbar del av systemet. En komponent representerer typisk den fysiske pakkingen av elementer som ellers er logisk relaterte.

9 Objektorientert systemutvikling side 9 av 35 En node er en maskinressurs. Et program eller deler av et program eksekverer på noder. Dvs. at en node vil huse en eller flere komponenter Oppførselsting Oppførsel uttrykker dynamikken i tid og rom i et programvaresystem. Prinsippielt er det to typer oppførsel. Man bruker begrepet interaksjon når flere objekter samarbeider gjennom utveksling av meldinger seg imellom for å oppnå et resultat. For at meldinger skal kunne sendes fra et objekt til et annet må det være en lenke (forbindelse) mellom objektene. Objekter vil i løpet av sin levetid kunne være i forskjellige tilstander. Dette kan modelleres som tilstandsmaskiner Grupperingsting I større systemer vil det alltid være behov for å kunne gruppere deler av systemet for å få bedre oversikt. Den primære grupperingstingen er pakke. En pakke samler flere strukturelle og oppførselsting som er tett koblet. En pakke kan igjen bestå av flere pakker Merknadsting Dette er forklaringer. Det er gjerne tekstlige forklaringer og anmerkninger som kan være nødvendige for å øke forståelsen av en modell eller spesielle deler av en modell. Nedenfor er en oversikt over de symboler som brukes. Strukturelle ting i UML Tilhørende symbol i UML klasse grensesnitt (interface) samarbeid bruksmønster

10 Objektorientert systemutvikling side 10 av 35 Strukturelle ting i UML Tilhørende symbol i UML aktiv klasse komponent node oppførsel melding gruppering tilstand merknad Forhold Jeg har tillatt meg å oversette det engelske relationship med forhold. Dette har jeg gjort for å skille det fra begrepet relasjon (eng relation) som er et matematisk begrep. En annen ting er at et forhold kan være en relasjon i matematisk forstand. I UML kan man modellere fire typer av forhold: - Avhengighet - Assosiasjon - Generalisering - Realisering Et avhengighetsforhold har vi når en klasse bruker en annen klasse. Vanligvis kommer det til uttrykk ved at en klasse er parameter i en operasjon til en annen klasse.

11 Objektorientert systemutvikling side 11 av 35 En assosiasjon er et forhold hvor det eksisterer en forbindelse mellom objekter. Dette kan sammenlignes med E-R modeller for relasjonsdatabaser. Forskjellen ligger i at en entitet i en E-R modell bare innkapsler data, mens objekter innkapsler både data og oppførsel. Generalisering er det samme som arv. Et generaliseringsforhold kommer til uttrykk gjennom et spesialiserings/generaliserings-hierarki. De spesialiserte elementer er subtyper av generelle typer som blir en supertype. Realisering har vi når en klasse oppfyller en kontrakt, f.eks spesifisert i et grensesnitt (interface). Ting og forhold utgjør det leksikalske nivå i UML fordi det dreier seg om symbolene som brukes for å bygge opp modellene. På det syntaktiske, kontekstuelle og semantiske nivå befinner modellene seg. Her dreier det seg om hva som er vel formulerte modeller. Dvs regler for å kombinere modeller og hvordan modellene skal tolkes Bruksmønster Bruksmønster står sentralt i objektorientert systemutvikling selv om det ikke er noe spesielt objektorientert med begrepet. Ivar Jacobson er trolig den som introduserte bruk av bruksmønster i objektorientert systemutvikling. Det gjorde han i sin banebrytende bok om objektorientert systemutvikling (Jacobson m.fl., 1992). Andre teoretikere og praktikere, delvis i samarbeid med Jacobsen, har videreutviklet og systemematisert bruk av bruksmønstre. I den kjente utviklingsprosessen Unified Process, er bruksmønstre det som driver utviklingsprosessen. Jacobsen brukte beuksmønstre i tillegg til tradisjonelle spesifikasjonsmetoder for bedre å forstå kravene til systemet som skal utvikles. I UP er samlingen av bruksmønster de funksjonelle kravene til systemet. Ikke-funksjonelle krav som naturlig kan knyttes til et bruksmønster spesifiseres sammen med bruksmønster en. Hvis det ikke er naturlig spresifiseres de i et eget dokument. I UP kalles dette dokumentet Suplementary Specification. Et bruksmønster er en beskrivelse av et ganske omfattende og komplett samspill mellom brukere (aktører) av systemet og systemet. Bruksmønstre er historier (på engelsk stories). Gjennom å fortelle historier om hvordan systemet skal samspille med brukerne får man en bedre forståelse av hva som kreves av systemet. Historien kan være knapp, den kan bestå av noen få setninger eller være omfattende med mange alternativer. Tradisjonelt har kravspesifikasjoner inneholdt lister med detaljerte krav på formen: Systemet skal. Gjennom å fortelle historier i form av bruksmønstre ser man ikke på enkeltegenskaper, men på samspill. Det øker forståelsen og bedrer kommunikasjonen mellom brukere og utviklere fordi det klarere kommer frem hvilken verdi systemet skal gi brukeren. Samspillet beskrives altså i form av en historie som detaljerer flyten av hendelser mellom brukere og systemet. Hos enkelte forfattere finner man begrepet scenario brukt om den detaljerte flyten av hendelser. Noen bruker dette begrepet om instanser av bruksmønstre. Med det mener de at i en konkret situasjon har et buksmønster et helt bestemt forløp og et konkret

12 Objektorientert systemutvikling side 12 av 35 sett med data. Man trekker parallellen til klasser og objekter (instanser). Man kan si at en klasse er en beskrivelse av hva objekter kan gjøre, mens man kan ha mange objekter som gjør de samme tingene, men med forskjellige data (verdier på attributtene). I enkelte bøker kan man finne at det skilles mellom hva man kaller essensielle bruksmønstre og reelle bruksmønster. Et essensielt bruksmønster er et hendelsesforløp som utrykkes på en ideell form. Det vil si at den er mer eller mindre fri for implementasjonsdetaljer. Spesielt gjelder det detaljer knyttet til brukergrensesnittet. Reelle (eller konkrete) bruksmønster er hendelsesforløp beskrevet i detaljerte implementasjonstermer. Hvis det inngår brukergrensesnitt vises disse med detaljert plassering av kontroller og felter. Her er to eksempler fra samspillet med en minibankterminal. Essensiell: Kunden identifiserer seg. Kunden presenteres for forskjellige valgmuligheter osv Reell: Kunden setter inn sitt kort. Systemet ber om PIN kode. Kunden taster inn koden. Systemet viser en meny med valgmuligheter osv Det er med andre ord også her mulighet for begrepsforvirring. Scenario er for mange det samme som reelt bruksmønster. Larman bruker begrepet scenario om historien som fortelles. Det vil si at et scenario kan være både essensielt og reelt (konkret). Men det vi skal legge vekt på er at bruksmønstermodellering er historiefortelling. Det er ikke å tegne diagrammer. Diagrammer er nyttige for visualisering og kommunikasjon. Men historien som detaljerer flyten av hendelser er det essensielle. Mens historiene i Jacobsons bruksmønster var ustrukturerte legges det nå vekt på at bruksmønster skal fortelles i strukturert format. Det er flere måter å gjøre dette på. I (Larman, 2002) finner man den mest omfattende måten. I (Quantrani, 2000) finner vi et noe enklere oppsett. Det har denne formen:

13 Objektorientert systemutvikling side 13 av 35 X. Hendelsesforløpet for bruksmønster <navn> X.1 PREBETINGELSE X.2 Hovedløp X.3 Sideløp (hvis det finnes) X.4 Alternative løp X er et tall som identifiserer et scenario. Vi bruker et eksemplet fra et program som skal beregne areal og omkrets for geometriske figurene for å vise hvordan historien i et bruksmønster kan skrives etter denne malen. Bruksmønsteret har vi kalt BeregningAvArealOgOmkrets og aktøren Figurberegner. 1. Hendelsesforløpet for bruksmønster BeregningAvArealOgOmkrets 1.1. Prebetingelse. Ingen (dvs at det ikke er noen annen bruksmønster som må være utført før denne kan starte) Hovedløp. Dette bruksmønster starter med at det kommer opp et skjermbilde som viser en sirkel, et rektangel og et triangel. FigurBeregner har nå mulighet for å få utført beregning av areal og omkrets for slike figurer. FigurBeregner klikker på en av figurene. Hvis figuren er en sirkel, utføres S-1: BeregnSirkel. Hvis figuren er et rektangel, utføres S-2: BeregnRektangel. Hvis figuren er et triangel, utføres S-3: BeregnTriangel. FigurBeregner kan også klikke på ikonet for å avslutte. Da avsluttes bruksmønster en Sideløp S-1: BeregnSirkel. Programmet viser en dialog med et felt for innsetting av radius. FigurBeregner setter inn en radius og klikker på en knapp merket Beregn (A-1). S-4 utføres. S-2: BeregnRektangel. Programmet viser en dialog med et felt for innsetting av høyde og bredde. FigurBeregner setter inn høyde og bredde og klikker på en knapp merket Beregn (A-1). S-4 utføres. S-3: BeregnTriangel. Programmet viser en dialog med et felt for innsetting av triangelets tre sider. FigurBeregner setter inn de tre sider og klikker på en knapp merket Beregn (A-1). S-4 utføres. S-4: VisResultat. Programmet beregner areal og omkrets. En dialog som viser resultatet spretter frem. FigurBeregner klikker på en knapp merket OK og programmet viser skjermbildet med figurene igjen. FigurBeregner kan nå få utført nye beregninger eller avslutte programmet Alternative løp. A-1: Ugyldig verdi. Denne bruksmønster starter når en ugyldig verdi for et datafelt er satt inn. En dialog spretter frem med forklaring av problemet og FigurBeregner får mulighet til å sette inn en ny verdi. Den enkelte står fritt til å velge den formen som man mener er best. Det er en smakssak.

14 Objektorientert systemutvikling side 14 av 35 En bruksmønster kan være mer eller mindre detaljert avhengig av hvor langt man er kommet med det: Høynivå (brief) En kortfattet beskrivelse av hendelsesforløpet. Bruksmønster identifiseres med navn og historien består av noen få linjer. Kausal (causal) En fri tekst historie som kan bestå av flere avsnitt som dekker flere scenarier. Fullstendig (fully dressed) Den mest omfattende og strukturerte form. Hvordan finne bruksmønster Etter hvert som bruksmønster har økt i popularitet, har også metodene for å finne dem endret seg. Toneangivende eksperter på skriving av bruksmønstre som Cockburn (Cockburn, 2001), legger han vekt på å identifisere mål hver enkelt aktør har med systemet, dvs hva aktøren ønsker å oppnå av verdi fra systemet. Definer så bruksmønster for hvert av målene. Dette er et skifte fra tidligere oppfatninger om at man oppdager bruksmønster mer eller mindre direkte, til å fokusere på måloppnåelse og deretter finne bruksmønster som viser hvordan målene oppnås i samspill med systemet. Det å finne og definere bruksmønster er ingen enkel oppgave. Vi tror derfor at man godt kan kjenne til og bruke flere måter. Selve arbeidet kan gjøres i idédugnader. I (Larman, 2002) finner man også retningslinjer for hva som er et bruksmønster. Nybegynnere har en tendens til å la enkelttrinn bli bruksmønster. Spesielt gjelder det folk som er vant til å tenke informasjonsflyt. Men bruksmønster er ikke flyt av informasjon. Det er historier som forteller samspillet mellom bruker og system. Legg disse fortellingene på et relativt høyt nivå. Som Larman skriver: I forbindelse med analyse av krav til datamaskinapplikasjoner, legger man bruksmønster på nivået for elementære forretningsprosesser. En elementær forretningsprosess er definert som: En oppgave som utføres av en person på ett sted til en gitt tid, som svar på en hendelse i virksomheten. Oppgaven skal resultere i noe som har målbar verdi for virksomheten. Data skal deretter være i en konsistent tilstand. Mer konkret foreslår Larman denne fremgangsmåten: 1. Fastsett grensene for systemet.

15 Objektorientert systemutvikling side 15 av Identifiser primære aktører. Der er de som har mål de ønsker å nå gjennom de tjenester systemet må tilby. 3. For hver primæraktør identifiseres målene. Legg målene på et nivå som svarer til definisjonene for en elementær forretningsprosess. 4. Definer bruksmønster som tilfredsstiller disse målene. Gi bruksmønster ene navn som samsvarer med målene. Larman skiller altså mellom flere typer av aktører. Disse er: Primære aktører. Det er de som når mål gjennom bruk av systemet. Støtteaktører. Det er slike som tilbyr tjenester til systemet. Utenforstående aktør. Det er slike som har interesse av systemet uten å være direkte involvert i samspillet med systemet. Aktører kan være både mennesker og andre systemer. Primære aktører er gjerne mennesker, mens støtteaktører oftest er andre systemer. Utenforstående aktører kan være etater eller institusjoner. Gjennom å finne slike sikrer man at alle krav til systemet blir identifisert og tatt vare på. Etter at bruksmønster er identifisert skal de rangeres. Det innebærer å finne ut hvilke bruksmønster som skal realiseres i hvilke iterasjoner i utviklingsprosessen. Her er noen kriterier for rangering av bruksmønster. Det vil si hvilke man skal ta sikte på å realisere i de tidlige inkrement: bruksmønster som har vesentlig innvirkning på utformingen av systemarkitekturen bruksmønster som gir mye informasjon og innsikt uten for store anstrengelser bruksmønster som det knytter seg risiko til eller som er tidskritiske eller har kompleks funksjonalitet bruksmønster som krever ny og risikabel teknologi bruksmønster som fører til økte inntekter eller reduserte kostnader Og glem ikke oppstarts bruksmønster en. Alle systemer har en slik. Den må gjennomløpes før andre bruksmønster kan utføres Bruksmønsterdiagrammet Som understreket tidligere er hovedoppgaven med bruksmønster modellering å fortelle historier. Men i visse sammenhenger kan bilder si mer enn ord. UML, som vi skal se nærmere på, gir oss bruksmønsterdiagrammer som et egnet redskap for det formålet. Det er vanlig for nybegynnere å se på bruksmønsterdiagrammet som et av målene i analysen. Men som poengtert foran så er hovedoppgaven å skrive fortellinger. På den annen side så vil et diagram på en kortfattet måte kommunisere hvilke aktører og bruksmønster som er funnet.

16 Objektorientert systemutvikling side 16 av Problemdomenemodellen Den neste modellen man skal arbeide med i analysen er problemdomenemodellen. Et annet navn som brukes er den konseptuelle modellen. Det er en klassemodell som skal hjelpe oss til bedre å forstå det systemet som skal utvikles. Den består av klasser som representerer konsepter (objekter) og deres sammenhenger i den virkelige verden. Den viser altså konsepter, assosiasjoner mellom konsepter og attributter til konseptene. På den måten får vi også klarlagt terminologien og vokabularet knyttet til problemet. Problemdomenemodellen beskriver ikke design av systemet. Det vil si at den ikke inneholder klasser som er programvare. En annen ting er at under design vil klasser fra den konseptuelle modellen finnes igjen som programvareklasser. Et av poengene med objektorientering og programvare er nettopp at man skal bruke de samme begreper i programmet som i problemets verden. Dermed blir terskelen ved overgang fra problem til program mye lavere enn den er ved andre metoder for utvikling av programvare. Vi skal senere under design se hvordan vi fører den konseptuelle modellen systematisk over i en programvaremodell. Vi skal prøve å beskrive hva som menes med konsept. Et konsept (Brugge og Dutoit, 2000) er en abstraksjon som beskriver et sett med fenomener. Eksempler på konsepter er lærebøker i systemutvikling biler sportsklokker Et konsept defineres som tre ting. Det har et navn som skiller det fra andre konsepter, dets hensikt, dvs. de egenskaper som skiller det fra andre konsepter, og medlemmer, dvs. det settet med ting som inngår i konseptet. F.eks så tilhører Larman sin lærebok konseptet lærebøker i systemutvikling. Vi ser her at et det er en parallell mellom på den ene siden konseptbegrepet som vi bruker når vi skal beskrive problemet, og klassebegrepet som vi bruker i objektorienterte programmer. Derfor er det naturlig å illustrere konseptuelle modeller i form av klassemodeller. Men husk at konsepter beskriver problemets verden, mens klasser tilhører programvaresystemet som utgjør løsningen på problemet. Hvordan finner vi kandidater til konsepter? Det er flere måter: 1. Se etter substantiver i bruksmønster. 2. Snakk med eksperter på problemdomenet og fremtidige brukere av systemet. 3. Bruk en sjekkliste med kategorier av konsepter.

17 Objektorientert systemutvikling side 17 av 35 Her er et eksempel på en slik liste som forteller hva som er typiske konsepter man kan søke etter: Konsept kategori Ting man kan ta og føle på Beskrivelse eller spesifikasjon av ting Steder Transaksjoner Roller til personer Beholdere for ting Ting i en beholder Andre datamaskiner eller systemer Abstrakte substantiver Organisasjoner Hendelser Prosesser (sjeldent) Regler og politikker Kataloger Lagret informasjon Finansielle instrumenter og tjenester Manualer, bøker Eksempel Fly Produktspesifikasjon Flyplass Reservasjon Spiller Lager Enhet, passasjer Verifikasjonssystem for kredittkort Sult Salgsavdeling Salg, møte Produktsalg Kredittpolitikk Produktkatalog Oppskrift, kontrakt Aksje Reparasjonshåndbok Den vanligste feil man gjør når man identifiserer konsepter er at man lar noe være et attributt i stedet for et konsept. Hvis man er i tvil gjør man det til et konsept. Her er et eksempel på et tvilstilfelle: En reise har et bestemmelsessted. Er bestemmelsesstedet et attributt til reisen eller er det et eget konsept? Altså, vi kan ha denne situasjonen:

18 Objektorientert systemutvikling side 18 av 35 Reise Reise Sted bestemmelsessted navn Hva er det riktige? Hvis det dreier seg om noe som ikke er en tekst eller tall, men som har utstrekning og kan hende tyngde, så er det et konsept. Vi går for situasjonen til høyre. I de konseptuelle modeller skal man angi assosiasjoner mellom konseptene. Til hjelp i å finne assosiasjoner kan denne listen brukes: A er en fysisk del av B A er en logisk del av B A er fysisk inneholdt i B A er en beskrivelse av B A er en linje i en transaksjon eller rapport B A er kjent/logget/rapportert i B A er et medlem av B A er en organisatorisk subenhet av B A bruker eller administrerer B A kommuniserer med B A er relatert til en transaksjon i B A er en transaksjon som er relatert til en annen transaksjon i B A er nær beliggende til B A er eid av B I den konseptuelle modellen skal man bare vise attributter, ikke metoder. Et attributt er en logisk dataverdi. De er et uttrykk for hvilken kunnskap et konsept skal ha. For eksempel bør et sted vite sitt navn System sekvensdiagram I et system sekvensdiagram illustrerer man hendelser som skjer mellom aktører og systemet. I dette diagrammet finner man to objekter, aktør og system. Se figuren.

19 Objektorientert systemutvikling side 19 av 35 : Aktør : System meld ing 1 meld ing 2 meld ing 3 Meldingene representerer det vi kaller systemhendelser. En systemhendelse er en ekstern input som genereres av en aktør. Hendelsen utløser en operasjon i systemet, en systemoperasjon. En systemoperasjon er altså en reaksjon fra systemet på en ekstern hendelse. I figuren over er det ikke vist tilhørende tekst fra hendelsesforløpet i bruksmønsteret. Men det hører med i et konkret system sekvensdiagram Kontrakter Kontrakter er et hjelpemiddel ved definisjonen av systemets oppførsel. Under design skal vi sørge for at kontraktene blir oppfylt. Kontrakter er oftest knyttet til systemoperasjoner. En kontrakt settes opp etter dette skjemaet: Kontrakt Navn: signatur for operasjon Ansvar: hva som skal utføres Type: type av operasjon, vanligvis systemoperasjon Kryssreferanse: referanse til andre dokumenter Merknader: spesielle ting å ta hensyn til Unntak: hva som kan forårsake feil Utdata: utdata som ikke er knyttet til brukergrensesnittet Prebetingelser: antakelser om tilstanden til systemet før operasjonen utføres Postbetingelser: tilstanden til systemet etter at operasjonen er utført

20 Objektorientert systemutvikling side 20 av 35 Kontrakter lages for hver bruksmønster. De er et supplement til bruksmønster hvor det ellers er vanskelig å få frem tilstandsendringene i systemet. Postbetingelsene utrykkes i termer knyttet til domenemodellen. Her er noen råd: 1. Finn frem til systemoperasjonene i system sekvensdiagrammet. 2. For hver systemoperasjon som er komplekse, lager man en kontrakt. 3. Start med å fylle ut ansvar som gir hensikten med operasjonen. 4. Skriv deretter postbetingelsene. Ansvar og postbetingelser er viktigst å få fastlagt. Postbetingelsene er en beskrivelse av den tilstand vi vil at systemet skal befinne seg i etter at en operasjon er utført. Gjennom denne beskrivelsen får man klart frem hva man skal ha ut av systemet før man begynner med å finne ut hvordan man skal få det til. Det overlater vi til design. På denne måten tvinges vi i analysen til å fokusere på hva systemet skal tilby uten å bli opphengt i hvordan vi skal utforme systemet. I design skal vi arbeide med å fordele ansvar på objekter slik at kontraktene blir oppfylt. Vi skriver vanligvis kontrakter for systemoperasjoner. Men vi kan også etter behov gjøre det for metoder i klasser. Kontrakter er et hjelpemiddel vi bruker hvis vi finner det hensiktsmessig. Vi skriver ikke kontrakter for alle systemmeldinger Ordbok Vi holder oss til Larman som skriver at en ordbok (glossary) er et enkelt dokument som definerer ord og utrykk. Han sier videre at ordboken etter hvert kan utvides til en dataordbok (data dictionary) Objektorientert design Som vi skrev foran så er grensen mellom objektorientert analyse og design flyttende. Men hovedoppgaven i design er å finne frem til programvareobjekter som kan realiseres i et programmeringsspråk og fortrinnsvis i et objektorientert programmeringsspråk som C++ eller Java. I design detaljerer vi klasser som skal inngå i programmet som skal utvikles. Mange av disse klassene henter vi fra problemdomenemodellen vi lager i analysen. Det er nettopp noe av poenget med objektorientering. Vi arbeider med de samme begreper i programmet som i den virkelige verden. Det gjør det lettere å forstå programmene fordi terskelen fra problem til program blir mindre.

21 Objektorientert systemutvikling side 21 av 35 Men vi legger også til klasser som vi finner opp for å kunne lage en god løsning. Det kan også tenkes at konsepter fra problemområdet ikke vil bli brukt i programmet, eller at de kan bli attributter i klasser. I design arbeider vi altså med å finne frem til programvareklasser. Resultatet er en logisk løsning basert på det objektorienterte paradigme. Oppgaven er å fordele ansvar på samarbeidende objekter. Samarbeidet skjer ved at objektene sender meldinger til hverandre. Ansvaret som skal fordeles er uttrykt i bruksmønstre og systemoperasjoner. Til støtte for arbeidet har vi god praksis nedfelt i såkalte mønstre (engelsk patterns). Interaksjonsdiagrammer er det viktigste arbeidsredskapet i design. Objektene defineres i klasser. Vi detaljerer klassene til et nivå hvorfra vi mer eller mindre rett frem kan skrive koden for klassene i det programmeringsspråket vi skal implementere i. Det finnes modelleringsverktøy (for eksempel Rational Rose) som kan generere kode direkte fra en klassemodell. I design lager vi designmodellen. Den består av interaksjonsdiagrammer og programvare klassediagrammer. Disse er tema i neste leksjon Et eksempel Vi skal ta et konkret eksempel for å vise de hvordan vi går frem når vi modellerer i analysen. Samtidig får vi vist hvordan UML brukes til å visualisere disse modellene. Først probelmbeskrivelsen: Det skal lages et informasjonssystem for busser. Alle nødvendige data tenker vi oss lagt på en sentral database. Systemet er et flerbrukersystem. Brukerne av systemet får opp et skjermbilde som kan se ut omtrent som på figuren nedenfor. Av de funksjonene vi ønsker for et slikt system er:

22 Objektorientert systemutvikling side 22 av 35 Det skal være mulig å klikke på det stedet du ønsker å reise til. Da skal du få spørsmål om hvor du ønsker å reise fra. Du kan enten klikke på stedet eller skrive inn inn adressen på det stedet du befinner deg. Da skal du få opp et skjermbilde som forteller hvilken rute du skal kjøre med nærmeste holdeplass hvor du kan gå på bussen nærmeste holdeplass ved bestemmelsesstedet om du må skifte buss og i tilfelle hvor første avgangstid neste avgangstid varighet av reisen Det er også et menyvalg som er merket Rutetabell. Ved klikk på denne kommer det opp en nedtrekksmeny med to valg et hvor det står Velg linje og et hvor det står Alle linjer. Klikker du på den første blir du bedt om å oppgi en linje. Deretter blir rutetabellen for denne linjen skrevet ut. Velger du den andre får du skrevet ut rutetabellene for alle linjer. Rutetabellene blir skrevet ut til skjerm. Det skal også være mulig å sende rutetabellene til skriver. Så følger analysen: Dette er en skisse til løsning av bussinformasjonssystemet. Jeg kaller det en skisse fordi det på den ene siden ikke er noe fasitsvar og fordi løsningen ikke er fullstendig.

23 Objektorientert systemutvikling side 23 av 35 Oppstart Vi må prøve å få avklart de viktigste kravene til systemet som skal lages. Jeg legger her vekt på de funksjonelle kravene som jeg vil utrykke ved hjelp av bruksmønster. Dessuten vil jeg lage en Domenemodell, system seksvensdiagram, kontrakter og ordbok som støtte til å forstå hva systemet skal gjøre. Aller først må vi forsøke å oppsummere/avklare det som kan trekkes ut av formuleringen av case et. Hvis dette var et virkelig prosjekt, kunne vi ha snakket med aktuelle brukere og en oppdragsgiver. Men i dette tilfellet får vi gjøre egne forutsetninger. Et hjelpemiddel som er brukt er ruteheftet til Trondheim Trafikkselskap (nå Team). Det å studere eksisterende dokumentasjon er en av de ting man kan gjøre i arbeidet med å forstå problemområdet og dets terminologi. Sentrale begreper og sammenhenger som er funnet i ruteheftet er nedfelt i ordboken og domenemodellen. Skjermbildet må betraktes som et eksempel på hvordan brukergrensesnittet kan se ut. Det er ment som en hjelp til å belyse det som egentlig er det primære nemlig funksjonaliteten. Det man kan trekke ut er at systemet skal gjøre det mulig for en som skal reise med buss å få presentert en reiserute med angivelse av nærmeste holdeplass, avgangstider og reisens varighet, å få presentert en tidtabell for en gitt linje eller alle linjer til et trafikkselskap. Det er opp til de som skal designe systemet å utforme et godt brukergrensesnitt for innlesning og presentasjon av data. Bruksmønster Det er generelt flere måter å oppdage bruksmønster på. Jeg velger oppskriften til Larman (Larman, 2002): 1. Avgrensning av systemet. Det som skal utvikles er programvare. I utgangspunktet skal programvaren kunne kjøres fra personlige datamaskiner. Men alle nødvendige opplysninger om linjer, holdeplasser, traséer og avgangstider skal finnes i en sentral database. I første omgang vil vi se bort fra detaljene rundt denne databasen og se den som eksternt til systemet som skal utvikles. På sikt ser vi for oss at programmet også skal kunne kjøres fra mobiltelefon (wap) og PDA. 2. Identifiser aktører. Det er ikke vanskelig her å finne en primær aktør. Det er den som skal reise. Vi kaller aktøren Reisende. Vi ser også umiddelbart en støtteaktør (supporting actor) i databasesystemet med all relevant informasjon. Slik informasjon er den vi finner i et rutehefte. Derfor kaller vi denne aktøren Rutehefte. 3. Primære aktørers hensikt (goal) med systemet. Den primære aktør ønsker å oppnå to ting ved bruk av systemet, å finne en reiserute og få presentert en eller flere tidtabeller. 4. Definer bruksmønster for hvert behov. 3 leder til to bruksmønster, FinnReiserute og FinnTidtabell.

24 Objektorientert systemutvikling side 24 av 35 Diagrammet som følger her viser bruksmønstermodellen. FinnReiserute <<Actor>> Rutehefte Reisende FinnTidtabell Legg merke til at vi bruker to forskjellige symboler for aktører. For primære aktører som normalt vil være mennesker, bruker vi symbolet til venstre. Støtteaktører som ofte er andre systemer fremstiller med klassesymbol med stereotypen <<Avtor>>. For øvrig er det vanlig å plassere primære aktører til venstre og støtteaktører til høyre. Domenemodellen Andre navn for denne modellen er problemdomenemodell eller konseptuell modell. Den lages for å få frem viktige begreper og sammenhenger i problemområdet (domenet). I UML fremstilles modellen som en klassemodell hvor klassene representerer objekter i den virkelige verden. Assosiasjonene viser relasjoner mellom disse objektene. Det er altså ikke programvareklasser vi finner i denne modellen. Men det ligger i objektorienteringens ånd at vi vil finne igjen de samme navnene på klasser i programvaren. Kandidater til klasser i domenemodellen er funnet ved å studere teksten i problembeskrivelsen, ordboken, bruksmønster og ruteheftet. Vi har ikke funnet det nødvendig å bruke en kategoriliste. En sjekk mot kategorilisten viser at de konsepter vi har funnet, er dekket av kategorilisten. Assosiasjonene er også funnet mer ved intuisjon enn med utgangspunkt i en kategoriliste for assosiasjoner. Men også assosiasjonene faller inn under kategoriene i kategorilisten. Noen eksempler: Linje er en logisk del av en reiserute. Holdeplasser er logisk knyttet til linjer. Neste figur viser den domenemodellen vi har kommet frem til.

25 Objektorientert systemutvikling side 25 av 35 for på og avstigning nærmeste 1..* Re iserute inneholder - Varighet - FørsteAvgang : Tidspunkt 0..* 1..* - NesteAvgang : Tidspunkt 1 foregår med beskrives i 1 Reise * * har har 1 Sted Bestemmelsessted 1 1..* Linje - linjeid - Type følger Trase består av Strekning - Navn Avreisested har har * 1..* Avgang - Avgangstid kan ha skjer fra har er i nærheten av * Holdeplass - Navn 1 terminal er oppført i er oppført i 1..* 1..1 Note 0..* 2 Tidtabell 1..1 kan ha Passering - Passeringstid Passeringstid angis i minutter etter avgang fra terminal. Det normale er at en holdeplass har en passeringstid oppført i en tidtabell. Derfor assosiasjonsklasse. Unntak kan forekomme og er angitt i Note. Av denne modellen trekker vi ut disse hovedpunktene: Reiserute har kunnskap om reisens varighet og avgangstidspunkter. En reiserute er assosiert med holdeplasser for på og avstigninger. Reiserute er også assosiert med en eller flere Linje. Reise er beskrevet i en Reiserute og starter på et Sted og slutter på et Sted. En Linje følger en Trasé som igjen består av Strekninger. En Linje har flere Holdeplasser. Linje er også assosiert med tidtabeller. For å få frem at en bestemt tidtabell inneholder avgangstider for en bestemt linje, har vi introdusert konseptet Avgang i assosiasjonen mellom Linje og Tidtabell. Vi kan ikke gjøre Avgang til en assosiasjonsklasse fordi hver instans av Linje og Tidtabell er assosiert med mange avganger. Avgang er assosiert med Holdeplass ved at avganger skjer fra en holdeplass som er terminal. Det får vi frem ved at Holdeplass har rollen terminal i denne sammenheng. I en bestemt tidtabell er de enkelte holdeplasser for en linje oppført en gang med ett passeringstidspunkt. Dette er ikke en egenskap ved en holdeplass eller tidtabell, men knyttet til assosiasjonen mellom en holdeplass og en tidtabell. Derfor har vi introdusert assosiasjonsklassen Passering. Enkelte har lett for å begynne å tenke programvareklasser og hvordan assosiasjoner skal realiseres i koden når de ser domenemodellen. Det skal man ikke. For som Larman skriver Domenemodellen er en visuell ordbok som inneholder ord og konsepter fra problemdomenet og som kan inspirere oss når vi skal navngi ting under design av programvaren. Det bidrar til å redusere et av gapene i forståelse av problem og programvare.

26 Objektorientert systemutvikling side 26 av 35 Fullstendig essensiell bruksmønster Her bruker vi oppsettet i (Larman, 2002) for å vise et alternativ til det vi har presentert tidligere. Bruksmønster UC1: Finn reiserute Primær aktør: Reisende Støtteaktør: Rutehefte. Representerer en database med nødvendig informasjon til å finne reiseruter. Andre interessenter: Trafikkselskaper: Ønsker å bedre servicen til sine reisende Prebetingelse: Ingen spesielle. Postbetingelse: En reiserute er funnet og presentert. Hovedflyt av hendelser: 1. Systemet er klart til å lage reiserute. 2. Reisende legger inn avreisested. 3. Systemet ber om bestemmelsessted. 4. Reisende legger inn bestemmelsessted. 5. Systemet presenterer en reiserute med informasjon om linje som skal brukes, nærmeste holdeplass ved avreisested, nærmeste holdeplass ved bestemmelsessted, første avgangstid, neste avgangstid, reisens varighet og eventuelle overganger og holdeplasser for disse. 6. Systemet er klart for å motta nytt avreisested. Alternativ flyt: *a. Reisende kan når som helst avslutte programmet. 2a, 4a. Ugyldige steder: 1. Systemet gir melding om at sted enten er skrevet feil eller ikke finnes. 2. Reisende korrigerer sted. Spesielle krav: Svartid fra bestemmelsessted er lagt inn til reiserute presenteres skal ikke overstige 2 sekunder i 90% av tiden. Teknologi: a. Systemet skal kunne kjøre på hjemme PC er med Windows 95, Windows NT 4.0 og nyere versjoner som er kommersielt tilgjengelige pr første halvår b. Systemet skal kunne kjøre på datamaskiner som kjører Linux operativsystem. c. Systemet skal kunne kjøre på Apple datamaskiner. Bruksfrekvens: Nærmest kontinuerlig. Uavklarte spørsmål: