Modellering 1. Modellering

Tore Berg Hansen 25.8.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget SO328D Programutviklingsmetoder 1. Resymé: I dette notatet skal vi se på hva som genererelt ligger i begrepet modellering. Vi skal se at i systemutvikling bruker to typer modeller prosessmodeller og produktmodeller. Den første gruppen modeller er oppskrifter vi kan følge. Den andre typen modeller briuker vi for å beskrive forskjellige sider ved systemer og produketer. Vi viser eksempler på v begge typer modeller og ser spesieolt på modellering av objektorienterte systemer og introdusere modelleringsspråket Unified Modelling Language (UML). Innhold 1.1. HVA ER EN MODELL... 2 1.2. HVORFOR MODELLERE... 2 1.3. PROSESSMODELLER... 3 1.3.1. Utviklingsprosjektets aktiviteter... 4 1.3.2. Iterativ og inkrementell utvikling... 6 1.4. EKSEMPLER PÅ ITERATIVE OG INKREMENTELLE UTVIKLINGSPROSESSER... 6 1.4.1. UP... 6 1.4.2. Ekstrem Programmering... 10 1.5. UML... 11 1.5.1. Litt historie... 11 1.6. BYGGEKLOSSENE I UML... 11 1.6.1. Strukturelle ting... 13 1.6.2. Oppførselsting... 13 1.6.3. Grupperingsting... 14 1.6.4. Merknadsting... 14 1.6.5. Forhold... 15 1.7. ET EKSEMPEL... 16 1.7.1. Use case modell... 16 1.7.2. Domenemodellen... 21 1.7.3. Analysemodellen... 23 1.7.4. Designmodellen... 25 1.8. SLUTTKOMMENTAR TIL DENNE LEKSJONEN.... 27 1.9. REFERANSER... 28

1.1. Hva er en modell Modell har flere betydninger. I en ordbok leser vi følgende: 1. Representasjon av noe. Vanligvis mindre enn originalen. F.eks modelljernbane. 2. Noe som lages for å brukes til kopiering i et annet materiale. F.eks voksmodell av noe som skal støpes. 3. Bestemt type eller design av et produkt. F.eks bilmodell. 4. Forenklet beskrivelse av et system brukt ved forklaring. F.eks en økonomisk modell. 5. Noe som man kan arbeide etter. F.eks en oppskrift. 6. Person eller ting som anses som eksepsjonelle og som det er verdt å etterligne. 7. Person som poserer. F.eks mannekeng eller akt. 8. Utgaver av klær fra motedesignere. Innenfor vårt fag, systemutvikling, er det 4 og 5 som er aktuelle. Vi har behov for å beskrive forskjellige sider og egenskaper ved programvaresystemer og vi følger utviklingsmodeller når vi utvikler systemene. Også 6 er aktuell i forbindelse med begrepet mønstre (engelsk patterns) som er løsninger som har vist seg å fungere godt i systemer som er utviklet tidligere. Jeg gjorde en gang et søk på Internett i et forsøk på finne noe relevant stoff om modeller og modellering. Jeg fant ikke det jeg håpet å finne. Men en av de tingene jeg fant var dette. Her er det flere typer modeller. Hvilke? 1.2. Hvorfor modellere Innefor 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 side 2 av 29

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 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 en prosess og kan organiseres etter forskjellige modeller. Dette skal vi komme tilbake til. 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. I [4] settes det opp fire grunnprinsipper for modellering: - Vær nøye med hvilke modeller du velger fordi valg av modell har grunnleggende betydning for hvordan man angriper et problem og for hvilken løsning som lages. - Forskjellige modeller gir ulikt detaljeringsnivå. Noen ganger har man behov for å vise et oversiktsbilde, andre ganger er det detaljene man vil konsentrere seg om. En bruker er interessert i å se hvordan systemet vil se ut utenfra, mens en utvikler kan vikle seg inn i detaljer rundt realiseringen av systemet. - De beste modeller er knyttet til virkeligheten. Det gjelder også for programvare. Objektorientert modellering gjør det lettere å oppnå dette. - Det er ikke nok med en enkelt modell. Store systemer vises best gjennom et lite sett med nesten uavhengige modeller. Gjennom utviklingsprosessen lager vi forskjellige modeller. Modeller er sentrale produkter gjennom hele utviklingsprosessen. 1.3. Prosessmodeller Dagens mennesker er helt avhengige av godt fungerende programvare. Vi støter nesten daglig på systemer som enten er rene programvaresystemer eller systemer hvor programvare er en svært kritisk del av systemet. Avhengig av hvilket arbeid vi har, bruker vi mange hjelpemidler og verktøy for å gjøre en effektiv jobb. Mange av disse hjelpemidlene og verktøyene er programvaresystemer. I hjemmet har vi en rekke apparater. Noen av disse apparatene trenger vi i husholdningen (kjøleskap, mikrobølgeovner, komfyrer). Andre apparater brukes til underholdning (tv, radio, video). De fleste av oss kan heller ikke unnvære telefon/mobiltelefon og bil. Og med Internett handler vi, betaler regninger og finner informasjon om snart nesten det meste. Sikker transport enten det skjer med fly, buss eller båt er avhengig av programvaresystemer. Det dette betyr er at programvaresystemer blir både større og mer komplekse. Det gjør igjen at de som skal utvikle disse programvaresystemene stilles overfor store utfordringer. side 3 av 29

Utviklerne trenger støtte av metoder, verktøy og god praksis for å kunne håndtere den økende størrelse og kompleksitet. Dette er grunnleggende nødvendig fordi vi erfarer at svært mange utviklingsprosjekter er problematiske. Alt for ofte overskrides tids og kostnadsrammer. Brukerne får ikke det de har forventet. Noe av årsaken til problemet er mangel på en definert utviklingsprosess. Man må strukturere arbeidet. Dvs at man må arbeide etter en prosessmodell. Med utgangspunkt i prosessmodellen skreddersys en prosess for det aktuelle utviklingsprosjektet. En definert prosess skal gi grunnlag for - å finne frem til det arbeid som må gjøres og dele det opp - å følge opp fremdrift - planlegging av ressurser - estimering av tid og kostnader - å finne betingelsene for at en aktivitet kan starte - å spesifisere produkter fra hver aktivitet - å spesifisere teknikker som skal brukes i hver aktivitet - å samle erfaring En prosessmodell er likevel bare et element i et vellykket utviklingsprosjekt. Vi skal derfor før vi diskuterer noen aktuelle prosessmodeller, kort se hvilke elementer som må være på plass for at et utviklingsprosjekt skal bli vellykket. 1.3.1. Utviklingsprosjektets aktiviteter Vi kan dele et utviklingsprosjekt inn i tre hovedgrupper av aktiviteter: - Prosjektstyring Planlegging Organisering Bemanning Ledelse Kontroll - Programvare system engineering Problemdefinisjon Analyse av løsninger Prosessplanlegging Prosesskontroll Evaluering av ferdig produkt - Programvare engineering Design av programvaren Koding Enhetstest Integrasjon av enheter Aktivitetene under prosjektstyring utfører vi i alle typer prosjekter. Det å få på plass og kontrollere en prosess hører inn under systemaktivitetene. Det er aktiviteter som vi utfører enten vi skal utvikle utelukkende programvare eller programvaren er en del av et større side 4 av 29

system med både programvare og maskinvare. Den siste gruppen av aktiviteter er kun knyttet til programvare. Det er beskrevet en rekke prosessmodeller. Det første forsøk på å lage etablere en prosess for utvikling av programvare resulterte i den velkjente fossefallsmodellen. Forandrings analyse Analyse Utforming Realisering Implementering Forvaltning og drift Avvikling Figur 1 Fossefallsmodellen Den finnes i forskjellige varianter. Man kan finne forskjellig antall faser og navn på faser. Men hovedprinsippet er at man gjør seg ferdig med en fase før neste begynner. Erfaringer fra et utall prosjekter viser at dette sjelden er mulig i praksis. Det skjer stadig at krav endrer seg under veis. Det tar for lang tid før brukere får et produkt å forholde seg til. Flere undersøkelser har også vist at en av de aller viktigste årsaker til fiasko er manglende forståelse av kravene til systemet som utvikles. Svakhetene med vannfallsmodellen har gitt opphav til andre modeller. Vi skal i andre sammenhenger diskutere nærmere fordeler og ulemper med forskjellige modeller. I dette notatet skal vi kort se på noen av de modeller som er mest omtalt for tiden. Basert på erfaringer om hva som virker og ikke virker, er det etter hvert blitt utbredt enighet om en del beste praksiser. Disse beste praksiser er: - iterativ og inkrementell utvikling - tidlig kontroll med risikofaktorer - kontinuerlig involvering av brukere og andre interessenter - tidlig etablering av en arkitektur for programvaresystemet - kontinuerlig verifikasjon av kvalitet - use case som tråd i utviklingsprosessen - visuell modellering av programvare - opptatthet av krav - praktiseringa av endringskontroll og konfigurasjonsstyring side 5 av 29

Det viktigste er den første praksisen, iterativ og inkrementell utvikling, fordi den legger på en måte grunnlaget for de andre. Vi skal i de etterfølgende kapitler se på noen prosessmodeller basert på disse praksisene. 1.3.2. Iterativ og inkrementell utvikling En iterativ og inkrementell utviklingsprosess består av en rekke iterasjoner som til slutt ender opp med det endelige system. Denne overordnete filosofien kan gi opphav til prosesser med forskjellig antall faser. Likedan kan graden av formalisme variere. Men et hovedpoeng er at ettersom kravene ikke er fullstendig kjente på forhånd, må denne kunnskap fremskaffes under veis. Man leverer systemet i inkrementer. Hvert inkrement realiserer deler av systemets funksjonalitet, samtidig som man fremskaffer mer kunnskap om systemet og risikoene man står overfor. Et inkrement er i seg selv er miniprosjekt som leverer et kjørbart system. Brukerne får presentert håndfaste resultater tidlig og i en jevn strøm og kan gi stadig tilbakemelding om systemet tilfredsstiller forventningene. Det endelige systemet bygges dermed i inkrementer ved at det legges til ny funksjonalitet etter hvert. Hvert inkrement vil inneholde innsamling av krav, analyse, design, implementasjon og test. Filosofien har en parallell i Shewhart/Deming syklusen for kontinuerlig forbedring som er sentral innenfor total kvalitets tenkningen. Denne syklusen har fire faser: 1. Planlegg hva som skal gjøres. 2. Gjør det. 3. Sjekk resultatet. 4. Handle og start en ny syklus 1.4. Eksempler på iterative og inkrementelle utviklingsprosesser 1.4.1. UP Historien For å få det hele i et perspektiv skal vi se kort på historien. Mange sett av metodikker og tilhørende notasjoner er lansert i forbindelse med den objektorienterte bølge som har slått over oss. Tre av de mange pionerer innen feltet er James Rumbaugh, Grady Booch og Ivar Jacobson. De har bidratt med hver sine metoder. Rumbaugh med OMT (Object Modelling Technique) [18], Booch [19] med sine spesielle klasse og objektdiagrammer og verktøyet Rational og Jacobson [17] med Use Case og metoden/verktøyet Objectory. Disse slo seg for noen år tilbake sammen. Et av resultatene er UML (Unified Modeling Language) som er et notasjonsspråk, dvs det redskapet man trenger når man skal visualisere forskjellige sider av et objektorientert system. UML forener OMT, Booch og Objectory. Det ser ut som de har vunnet notasjonskrigen og at UML har blitt det allment aksepterte notasjonsspråket. Det er nå en standard i regi av organisasjonen OMG (Object Management Group). UML er nå i versjon 1.3 utvidet med ideer fra andre av de mest kjente aktørene rundt objektorientering som Meyer, Wirfs_Brock, Shlear-Mellor, Gamma og andre. Revisjon 1.4 er i betaversjon og det arbeides med versjon 2.0. Et annet resultat av samarbeidet mellom de tre (amigos) er verktøyet Rational Rose som også ser ut til å vinne stor utbredelse i det objektorienterte miljø. Et verktøy kan ikke stå alene. Det må være en støtte for det arbeidet som gjøres i utviklingsprosessen. Samarbeidet mellom de side 6 av 29

tre har resultert i en prosessmodell som har fått betegnelsen Unified Process (opprinnelig kalt Objectory Process). Den overordnede filosofi for denne prosessen er inkrementell og iterativ utvikling. Det er utgitt en bok som Jacobson [20] er hovedforfatter for, hvor prosessen beskrives. De som kun trenger en oversikt over prosessen kan lese i bl.a [12] og [21]. Prosessen omtales ofte som Rational Unified Process (RUP) fordi firmaet Rational støtter prosessen med verktøy. Prosessen The Unified Process (UP) er en livsløpsmodell som skal være godt egnet for bruk sammen med UML. UML er imidlertid ikke avhengig av noen spesiell prosess. Heller ikke er UP avhengig av noe spesielt notasjonsspråk. Imidlertid har UP og UML utviklet seg sammen og involvert noen av de samme personer. Målet med denne prosessen, som med alle andre livsløpsprosesser, er å sørge for produksjon av programvare av høy kvalitet som tilfredsstiller brukerkravene innenfor forutsigbare tids og budsjettrammer. Prosessen skal kunne skreddersys til å passe mange forskjellige prosjekter og organisasjoner. Prosessen legger vekt på at det skal produseres og vedlikeholdes modeller i stedet for dokumenter. Den er arkitektursentrert. Med det menes at det tidlig i prosessen må lages en grunnleggende arkitektur. Denne arkitekturen skal være robust for å kunne videreutvikles i iterasjon etter iterasjon. Prosessen er Use Case drevet (Jacobsons bidrag [17]) og produserer objektmodeller under veis. Det legges vekt på at prosessen skal bidra til å redusere risiko og fremme kvalitet på sluttproduktet. Risikovurdering og kvalitetsvurdering er bygget inn i prosessen. Oppstart Detaljering Overlevering Konstruksjon Figur 2 Fasene i UP 1 3... 2 De fire fasene utgjør til sammen en livssyklus for programvaren. Hver fase ender i en milepæl. Man itererer seg gjennom hver fase. Dette utgjør tidsdimensjonen i modellen. Dette gjøres i de forskjellige fasene: - Oppstart (inception på engelsk). Her skal man legge grunnlaget for prosjektet. Det vil si å finne frem til suksesskriterier, vurdere risikoer, estimere ressursbehov og utforme en tidsplan med faser og milepæler. Prototyper er nyttige i denne fasen. - Detaljering (elaboration på engelsk). Problemdomenet analyseres. Man skal ha på plass en arkitektur, detaljere prosjektplaner og søke eliminere de største risikoelementene. Hovedkravene til systemet skal beskrives. - Konstruksjon (construction på engelsk). Her fremstilles systemet gjennom en rekke iterasjoner og inkrementer. Man finner flere krav og akseptansekriterier. Design detaljeres og systemet inplementeres og testes. side 7 av 29

- Overlevering (transition). Systemet leveres til brukerne. Dette vil typisk være en betaversjon av systemet.ved at systemet tas i bruk kan nye krav og problemer dukke opp som gjør at livsløpet må startes på nytt. Slutten av hver fase ender i en milepæl. Hver fase i prosessen kan deles i flere iterasjoner. En iterasjon er et fullstendig utviklingsløp som skal resultere i et frislipp (release) som enten er internt eller eksternt. Hvert slikt frislipp er en kjørbar del av systemet som er under utvikling. Det endelige systemet blir gradvis komplettert etter hver iterasjon. Dvs hver iterasjon bringer frem et nytt inkrement av systemet. Iterasjonene i hver fase har forskjellig fokus. I den første fasen vektlegges å få frem kravene, deretter vektlegges analyse og design. Under konstruksjon er det implementasjon som vektlegges. Man kan si at prosessen har to dimensjoner som vist i Figur 3. Faser (tidsdimensjonen) Disipliner (aktivitetsdimensjonen) Oppstart Detaljering Konstruksjon Overføring Virksomhetsmodellering Krav Analyse og design Implementasjon Test Deployment Konfig & endringsstyring Prosjektstyring Omgivelser Innledende iterasjoner Iter #1 Iter Iter #n Iter #1 Iter Iter #m Iter #1 Iter Figur 3 De to dimensjoner i UP Disiplinene (tidligere kalt workflows) representerer aktiviteter som må utføres. Hver disiplin har i tillegg et sett artefakter. Et poeng er at hver iterasjon inneholder nesten alle aktiviteter, men med forskjellig omfang og at man arbeider med de samme artefakter. Det vil si at artefaktene til å begynne med stadig endres, men etter hvert vil de konvergere mot en stabil tilstand. F.eks så vil kravene være flytende i oppstartsfasen og i begynnelsen av bearbeidingsfasen. Hovedpoenget er at man gjennom iterasjoner med tilbakemelding fra brukere kommer frem til sikrere og sikrere krav. Også i de senere faser kan det bli endringer, men etter hvert færre og færre. Et hovedmål med detaljeringsfasen er å få på plass en arkitektur for programvaresystemet. Arkitekturen er det fundament og ramme som skal gi grunnlaget for et kvalitetssystem. Vi kommer tilbake til temaet arkitektur i en senere leksjon. side 8 av 29

I UP defineres disse disipliner: - Virksomhetsmodellering er aktiviteter for å modellere forretningsprosesser. Målet er å få frem kunnskap om de virksomhetsområder som det skal utvikles programvare for. På den måten bygger man bro mellom systemutviklere og de som skal bruke systemene. Disse aktivitetene vil være forskjellige avhengige av hvilken type virksomhet det dreier seg om. - Krav. Her er målet å komme frem til hva programvaresystemet skal gjøre. Man skal frem til funksjonelle krav uttrykt ved use case og ikke-funksjonelle krav. det utarbeides en visjon for systemet og identifiserer aktører. - Gjennom analyse og design beskriver man hvordan systemet skal realiseres. Man fastlegger en arkitektur, hvilke objekter programvaren skal bestå av, eventuelt database, nettverk og desslike. - Implementasjon omfatter aktiviteter for å realisere systemet. Koding av klasser utføres. Systemet organiseres i delsystemer og komponenter. Enheter testes. - Deployment er aktivitetene for å produsere et frislipp (relesase) og levere programvaren til sluttbruker. Det kan inkludere planlegging og gjennomføring av beta-tester og konvertering av eksisterende programvare og data. - Konfigurasjons og endringsstyring skal sikre at de forskjellige artefakter ikke er i konflikt med hverandre. Man må ha kontroll med oppdateringer, endringer, versjoner, varianter og frislipp av programvaren. Dette er ikke praktisk mulig å få til uten automatiserte verktøy. - Prosjektstyring er gjennomgående aktiviteter hvor man planlegger og følger opp progresjonen i prosjektet. - Omgivelsesdisiplinen er aktiviteter for å få på plass det som trengs for å støtte gjennomføringen av prosjektet. Man skal finner frem og tilrettelegge nødvendig verktøy og tilpasse prosessen til det aktuelle prosjekt. Etter første gjennomløp av de fire hovedfasene har man utviklet første versjon av systemet. Nye generasjoner produseres ved nye løp gjennom hovedfasene. Det er dette som ligger i begrepet evolusjonær utvikling. I løpet av prosessen fremstilles flere modeller. Disse er: - Domenemodell som plasserer systemet i sin kontekst. - Use Case modell som utgjør de funksjonelle kravene. - Modell over ikke-funksjonelle krav. - Analysemodell som gir en implemetasjonsuavhengig arkitektur (her aner vi Jacobson). - Designmodell - Prosessmodell som viser samtidighet og synkroniseringsmekanismer. - Deployment modell som viser topologien for maskinvaren som systemet skal kjøre på. - Komponentmodell viser hvordan systemet fysisk settes sammen. - Testmodell. Det er fremstillingen av disse modellene som står sentralt i senere leksjoner i dette faget. side 9 av 29

Selv om det er UP vi legger vekt på er det i det følgende beskrevet noen andre prosessmodeller. Det gjør vi for at dere skal se at det finnes alternativer. 1.4.2. Ekstrem Programmering Generelt Extreme Programming (XP) er en prosessmodell som har fått en god del oppmerksomhet i den senere tid. Hovedpoenget for de som står bak er at for å utvikle god programvare må man føre ut i det ekstreme det som er nedfelt som de beste praksiser. Han som står bak er Kent Beck. Ideene er forklart i [24]. Her følger en kort presentasjon av prosessen. Hva er ekstremt? Kent Beck skriver følgende om hva som er det ekstreme: - Hvis koderevisjoner er bra, må vi revidere kode hele tiden. To programmere må arbeide sammen hele tiden. (Pair programming) - Hvis testing er bra, skal alle teste hele tiden, også kundene. - Hvis det å designe er bra, må det være noe enhver holder på med hver dag. - Hvis enkelhet er bra, skal systemet være i den enkleste form som støtter ønsket funksjonalitet. - Hvis arkitektur er viktig, skal alle arbeide med å definere og raffinere arkitekturen hele tiden. - Hvis integrasjonstesting er viktig, så skal man integrere og teste mange ganger hver dag. - Hvis korte iterasjoner er bra, gjør man iterasjonene virkelig korte sekunder, minutter og timer, ikke uker, måneder og år. Videre skriver han at XP, i tillegg til en del andre ting, er en morsom måte å utvikle programvare på. Den skiller seg ut fra andre prosesser ved - ved tidllig, konkret og kontinuerlig tilbakemelding fra korte sykluser - inkrementell planlegging som tidlig frembringer en grov overordnet plan som skal utvikles videre gjennom livsløpet - fleksibel implementasjon av funksjonalitet i takt med endrede behov - bruk av automatiske tester skrevet av programmerere og kunder for tidlig å fange opp defekter - muntlig kommunikasjon, tester og kildekode for å kommunisere strukturen for og hensikten med systemet - basering på en evolusjonær design prosess som varer så lenge systemet varer - tett samarbeid mellom programmere med gjennomsnittlige ferdigheter - praksiser som for programmere instinktivt føles riktige i det daglige og som tjener prosjektene på lang sikt. Det som er innovativt med XP er - Alle gjennomprøvde praksiser settes under en paraply. side 10 av 29

- At man sikrer at praksisene følges så nøye som mulig. - At man sikrer at alle som er involvert støtter hverandre på best mulig måte. En god del av dette finner man igjen i UP. Felles er fokusering på å kontrollere risikofaktorer gjennom iterasjon. I UP legger man stor vekt på visuelle modeller for å kommunisere forskjellige sider av systemet. I XP er muntlig kommunikasjon og kildekode det sentrale. 1.5. UML UML [4] 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 både dokumenter og eksekverbar kode: - Krav - Arkitektur - Kildekode - Prosjektplaner - Tester - Prototyper - Frislipp UML bidrar til å gjøre disse produkter mer forståelige. 1.5.1. 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 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). 1.6. 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. side 11 av 29

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 [4] 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 - Use case diagram - Sekvensdiagram - Samarbeidsdiagram - Tilstandsdiagram - Aktivitetsdiagram - Komponentdiagram side 12 av 29

- 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. 1.6.1. 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, use case, 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. Use case er et sentralt begrep hentet fra Jacobsons [4] utviklingsmetode og tatt med i UML. Kort kan vi si at en use case 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 en use case ser vi programvaresystemet utenfra. Gjennom en use case blir en aktør tilbudt noe av nytte fra systemet. Settet med alle use case 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. 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. 1.6.2. 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 side 13 av 29

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. 1.6.3. 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. 1.6.4. 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 use case aktiv klasse komponent side 14 av 29

Strukturelle ting i UML Tilhørende symbol i UML node oppførsel melding gruppering tilstand merknad 1.6.5. 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. 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). side 15 av 29

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. 1.7. Et eksempel Vi skal her se på et eksempel for å vise noen av de mest brukte modeller og tilhørende diagrammer. For at problemet ikke skal overskygge prinsippene lar vi eksemplet være enkelt. Følgende foreløpige krav til et programvaresystem er identifisert: Det skal lages et system som skal brukes til beregning av areal og omkrets for forskjellige geometriske figurer. Vi begrenser oss til todimensjonale figurer. Når programmet starter skal det komme frem et skjermbilde som viser de typer av figurer som programmet kan utføre beregninger for. Ved å klikke på den aktuelle figuren skal det sprette frem en dialog hvor man kan sette inn nødvendige data for beregningene. Etter at brukeren har klikket på en knapp merket Beregn i dialogen skal programmet gjøre beregningene. Når beregningen er utført skal resultatene vises i et vindu på skjermen. I første omgang skal programmet lages for tre figurer; triangel, rektangel og sirkel. Denne spesifikasjonen er mangelfull. Nye krav vil sannsynligvis bli oppdaget etterhvert som vi modellerer systemet. 1.7.1. Use case modell Vi følger Rational Unified Process (RUP). Da er vi nå i oppstartsfasen og skal se nærmere på kravene til systemet. Et naturlig startpunkt kan være use case. side 16 av 29

Oppstart Detaljering Konstruksjon Overføring 1 2 3 Figur 4 Unified Process Jacobson 1 [4] definerer en use case som en rekke av transaksjoner i en dialog med systemet utført av en instans (bruker) av en aktør. En annen definisjon på use case er: Et sett use case instanser. Hver instans er en serie med aksjoner som systemet utfører og som fører til noe som er nyttig for en aktør. En aktør er en representant for hva som samspiller med systemet. Brukeren er den aktuelle personen som bruker systemet. Aktøren representerer en rolle som brukeren kan spille. Man kan si at en aktør er en klasse, mens en bruker er en instans av denne klassen. Alle use case man kan finne for systemet representerer den samlede funksjonalitet for systemet og er det naturlige startpunkt for å finne klasser og objekter som skal tilby denne funksjonaliteten. Med utgangspunkt i use casene lages mange av de andre modellene av systemet. En måte å finne use casene på er å starte med å identifisere aktører og se på hvilken bruk de vil gjøre av systemet. I dette enkle systemet med beregning av areal og omkrets for geometriske figurer er det antagelig bare en aktør, nemlig den som representerer de som er interessert i arealet og omkretsen av geometriske figurer. Hvilket navn skal vi gi denne aktøren? Jeg foreslår FigurBeregner, i mangel av noe bedre. FigurBeregner er en rolle. Forskjellige personer kan gå inn i den rollen avhengig av hvem som bruker systemet. F.eks kan det være en skoleelev, en student eller en arealplanlegger. Det kan for så vidt også være et annet program som har bruk for denne typen beregninger. Hvilken bruk gjør så FigurBeregner seg av systemet? Hvilken funksjonalitet ønskes? I dette tilfellet det vel ganske enkelt å se at det er BeregningAvArealOgOmkrets. Man kunne tenke seg å dele denne i to use case en for beregning av areal og en for beregning av omkrets. Av og til kan det være en smakssak. For store systemer kan man miste oversikten hvis antallet use case blir stort. Det er ikke problemet her. Jeg velger en use case fordi begge beregningene for de fleste figurer kan utføres med basis i de samme dataene. Da har vi identifisert en aktør, FigurBeregner og en use case, BeregningAvArealOgOmkrets. Vi får følgende enkle us case modell som vis i diagrammet i Figur 5... 1 Jacobsen er den som introduserte use case i objektorientert systemutvikling. Derfor er han referert her. I [10], kapittel 6 gis en grundig beskrivelse av use case. Her skjelner forfatteren mellom forskjellige typer av use case. Egentlig er det samme use case, bare på forskjellig detaljeringsnivå, avhengig av hvor langt man er kommet i utviklingsprosessen. side 17 av 29

BeregningAvArealOgOmkrets Figur 5 FigurBeregner Symbolet for aktøren er en stilisert person og symbolet for en use case er en ellipse. Legg merke til at navnene som er gitt symbolene er skrevet under. Det er i samsvar med Jacobson [4]. Begrunnelsen er at man på den måten ikke får problemer med å få plass til teksten inne i symbolet. Man kan dermed holde en fast størrelse på symbolene. Ikke alle bruker den praksisen, men legger teksten inne i symbolene. Det er heller ikke alle som trekker sammen navnene på den kompakte formen som jeg har gjort. (Larman [10] legger teksten inne i symbolet). Det neste man nå kan gjøre er å utbrodere use casen tekstlig. Det vil si at man beskriver med ord trinn for trinn det som skjer mellom aktøren og systemet i den gitte use case. Slik jeg tolker Jacobson kaller han også denne teksten for use case, mens andre metodikere skiller mellom use case som abstraksjon og dens innhold. Innholdet kalles hos dem scenario [6], [7] eller script. Use case blir hos dem en slags klasse, mens scenariet eller scriptet kan oppfattes som en instans av denne klassen. I den senere tid etter hvert som bruk av use case har blitt mer utbredt, er formaliserte oppsett av use case blitt introdusert. Larman [10] viser eksempler på det. Men en ting synes alle å være enige om. Det er at use case, uavhengig av form, er nyttig og viktig når man skal forstå oppførselen til det systemet som skal utvikles. I denne introduksjonen følger vi Jacobson. Han tar utgangspunkt i kravspesifikasjonen i en eller annen form. Her følger teksten til use casen: side 18 av 29

BeregningAvArealOgOmkrets Programmet starter ved at det kommer opp et skjermbilde som viser en sirkel, et triangel og et rektangel. FigurBeregner klikker på en av figurene. En dialog hvor data kan settes inn spretter frem. Hvis det er en sirkel setter FigurBeregner inn radius, hvis det er rektangel setter FigurBeregner inn bredde og høyde og hvis det er et triangel setter FigurBeregner inn lengden av de tre sidene i tiangelet. FigurBeregner trykker på knappen merket Beregn i dialogen. Programmet vil utføre beregningen av areal og omkrets for den valgte figur. Etter at beregningen er ferdig presenterer programmet resultatet i en dialog. Denne dialogen har en knapp merket OK.FigurBeregner klikker OK og programmet viser skjermbildet med de tre figurene igjen. FigurBeregner kan da få utført nye beregninger. Hvis ikke kan FigurBeregner avslutte programmet. I tilknytning til denne use casen kan det også være hensiktsmessig å lage en prototype som viser brukergrensesnittet. side 19 av 29

side 20 av 29

Dette er en prototype. Det endelige brukergrensesnittet behøver ikke se slik ut. Poenget er å komme frem til enighet om det som skal skje i dialog med brukeren. 1.7.2. Domenemodellen Use case modellen viser en side ved det systemet som skal utvikles den eksterne funksjonaliteten. Denne modellen skal hjelpe til med å finne frem til hvilket ansvar som skal legges til objekter i programvaren. Men før man arbeider videre med use casene, kan det være nyttig å modellere den virkelige verden knyttet til det problemet som skal løses. Dermed kommer en annen side ved systemet frem. Denne siden vil vise objekter og sammenhenger som er typiske for problemområdet. Disse objektene vil delvis finnes igjen som programvareobjekter i det endelige programmet. Denne modellen av virkeligheten, kalles gjerne problemdomenemodellen [4], [8]. Et annet nav er den konseptuelle modellen [10]. Den vil vises som et klassediagram. I vårt enkle eksempel er det umiddelbart flere kandidatobjekter som dukker opp: - geometrisk figur - sirkel - triangel - rektangel Disse er beslektede. Et første utkast til domenemodell blir derfor et hierarki med geometrisk figur som superklasse og som besitter alle felles egenskaper for alle typer geometriske figurer. GeomtriskFigur Sirkel Rektangel Triangel Figur 6 Figur 6 viser domenemodellen på sitt høyeste abstraksjonsnivå. Klassene er rektangler med navnene skrevet inni rektanglene. I superklassen er navnet skrevet i kursiv. Det forteller at klassen er abstrakt. Det vil si det ikke vil eksistere noen instanser av denne klassen. De konkrete klassene er Sirkel, Rektangel og Triangel. (Egentlig er det bare de konkrete klassene som tilhører problemdomenet. Abstrakte klasser tilhører programvaren). Disse vil det kunne opprettes instanser av i et program. Trekanten som peker mot klassen på toppen i hierarkiet er en diskriminator som forteller at vi har en generalisering/spesialisering, dvs et arvehierarki. Strengt talt har vi gått litt lenger enn å modellere det rene problemdomenet. Dette fordi vi tenderer i retning av programvareklasser ved introduksjon av abstrakte klasser. Men det falt naturlig. Legg merke til at vi er opptatt av konseptene (den virkelige verden) og ikke operasjoner og attributter som tilhører programvareklasser. I problemdomenemodellen er det ellers vanlig å trekke inn noen attributter som er naturlige for å få frem de som er essensielt med et objekt i den virkelige verden. Legg dessuten merke til at problemdomenemodellen er side 21 av 29

en klassemodell, mens det man snakker om er objekter (også kalt konsepter) i den virkelige verden 2. UML gjør det mulig å lage modeller hvor vi kan legge inn informasjon etter behov. Forskjellige interessenter kan være interessert i forskjellige detaljer i systemet. Brukere er vanligvis opptatt av oversikten, mens designere og testere trenger detaljert informasjon. Vi kan detaljere modellen med attributter og opersjoner for klassene. Da er vi i ferd med å lage en modell med programvareklasser. I den abstrakte klassen legger vi attributter og operasjoner som er felles for alle klassene i hierarkiet. Alle geometriske figurer har et areal og en omkrets. Hvordan disse beregnes vil være forskjellig. Operasjonene har samme navn, men implementasjonen vil være forskjellig i de ulike subklassene 3. Det er dette som kalles polymorfisme. GeomtriskFigur areal beregnareal() beregnomkrets() hentarealet() Sirkel Rektangel Triangel radius høyde bredde sideen sideto beregnareal() beregnomkrets() settradius(radius) hentradius() beregnareal() beregnomkrets() setthøyde(høyde) settbredde(bredde) henthøyde() beregnareal() beregnomkrets() settsider(sideen, sideto, sidetre) Figur 7 Figur 7 viser det samme diagrammet, men nå med flere detaljer. Det er lagt inn de attributter og operasjoner som er mest åpenbare. Etter hvert som man arbeider videre mot realisering av 2 I [10] kapittel 1 finner man en introduksjon til begrepene og i kapittel 9 flere detaljer. 3 En operasjon som ikke har noen implementasjon i den abstrakte klassen kalles i C++ for en ren virtuell funksjon, i Java en abstrakt metode. side 22 av 29

klassen kan man legge inn enda flere detaljer. Det skal vi komme tilbake til. Vi skal senere se på mer systematiske måter å komme frem til operasjoner og attributter på. Klasse navn Sirkel attributt:type = initialverdi radius:float = 1 operasjon(arg liste):retur type beregnareal() beregnomkrets() settradius(radius:float) hentradius():float (a) (b) Figur 8 Figur 8 viser hvordan en detaljert spesifikasjon av attributter og operasjoner kan gjøres. Til venstre vises den generelle oppbygning. Til høyre har vi et konkret eksempel. 1.7.3. Analysemodellen Domenemodellen vil ikke være den modellen som uttrykker designet av programvaresystemet. Det er det designmodellen som skal gjøre. Den vil inneholde de klasser som skal gjøre jobben i programmet. Men før man kommer så langt vil man lage en analysemodell. Dette er en logisk modell som viser hva programmet skal gjøre, mens designmodellen viser konkret hvordan vi vil gjøre det. Analysemodellen er uavhengig av implementasjonsmiljøet. Designmodellen tar hensyn til implementasjonsmiljøet [4]. I objektorientert systemutvikling er grensen mellom analyse og design ganske flytende. Davis [9] skriver om det han kaller what versus how dilemmaet. En persons hvordan er en annen persons hva. Analysemodellen er i stor grad også hvordan fordi det er her man finner klassene og hvordan de skal samspille i programmet. Det betyr at man fastlegger den overordnede arkitekturen og dermed strukturen i programmet. Dette er i høy grad hvordan. På den annen side sier analysemodellen hva programmet skal bestå av ikke hvordan den detaljerte realiseringen skal gjøres. Det overlates til design og implementasjon som til sammen utgjør konstruksjonen av systemet. Da er vi over i konstruksjonsfasen. Tilbake til analysen og analysemodellen. For å utvikle et komplett program er ikke domenemodellen nok. Domenemodellen bygges for at vi skal forstå problemområdet. Det er ikke gitt at noen av klassene i domenemodellen gjenfinnes i det ferdige programmet. Men det er sjeldent. Use case modellen og domenemodellen danner utgangspunktet for analysemodellen. Det vil også være fornuftig å se på eksisterende mønstre for god analyse og design. Vi skal lage et interaktivt program. Et mønster for et slikt program er Model View Controller (MVC) kjent fra SmallTalk. Se Figur 9 side 23 av 29

Model Controller View Figur 9 Modell representerer dataene og kunnskapen i programmet. View er brukergrensesnittet. Controller binder programmet sammen. Jacobson [4] definerer tre typer av objekter grensesnittobjekt, entitetsobjekt og kontrollobjekt. Han hadde egne symboler for disse. I UML kan man bruke stereotyper for å skille mellom typer av klasser eller objekter. Modell er typisk et eller flere entitetsobjekter. View er et eller flere grensesnittobjekter. Controller er et eller flere kontrollobjekter. En gruppering av klasser som logisk hører sammen og som utgjør en større enhet, modelleres som pakker i UML. En pakke har et eget grafisk symbol. MVC modellen kunne derfor også vært vist som i Figur 10. Model Controller View Figur 10 Pilene representerer assosiasjoner mellom klassene (pakkene). Pilene viser retningen på assosiasjonene. F.eks så ser Controller Model, mens Modell ikke har behov for å kjenne til Controller. Vi bruker dette mønsteret i vårt program. Da blir analysemodell som i Figur 11 side 24 av 29

SirkelDialog Beregner View RektDialog TriangDialog GeomFigur RersultatDialog Figur 11 Sirkel Rektangel Triangel 1.7.4. Designmodellen Vi er nå etterhvert over i konstruksjonsfasen. En av de første tingene vi gjør i denne fasen er å designe use casene. Vi skal se på det detaljerte samspill mellom objektene i programmet. Hjelpemidler er interaksjonsdiagrammer. Det er to typer interaksjonsdiagrammer sekvensdiagrammer og samarbeidsdiagrammer. Et sekvensdiagram viser rekkefølgen av hendelser i en use case. Sekvensdiagrammer var sentrale hos Jacobson [4]. Han kaller dem faktisk interaksjonsdiagrammer. Rumbaugh [6] hadde noe lignende som han kalte event trace. Ideene er tatt med i UML under betegnelsen sekvensdiagram. side 25 av 29

Start hovedvindu vises while flereberegninger FigurBeregner klikker på fiur Programmet viser dialog FigurBeregner setter inn data FigurBeregner klikker OK Dialog tar vare på data Beregning utføres start klikkfigur() settdata OK :Beregner :GeomFigur :View :Dialog :Resultat visview() hentdata() settdata() beregnareal() beregnomkrets() hentareal() hentomkrets() visdialog() hentdata() hentdata() Resultat vises i dialog FigurBeregner klikker OK endwhile slutt slutt OK visresultat(resultat) visdialog() visresultat() Figur 12 Figur 12 er et eksempel på et sekvensdiagram. En av hensiktene med diagrammet er at det skal være til hjelp når man skal fordele og finne frem til operasjoner for de forskjellige objekter som inngår i en use case. Diagrammer viser også rekkefølgen av operasjonene. Diagrammet kan også brukes til å vurdere godheten av en løsning. La oss se på oppbygningen av diagrammet. Helt til venstre er use casen formulert i pseudokode. Øverst er tegnet inn de objekter som inngår i use casen inkludert aktøren 4. De er i dette tilfelle anonyme objekter fordi bare klassenavnet er angitt. Dialogobjektet representerer alle de dialoger som brukes for å lese inn data for forskjellige figurer. Det er gjort for å lette oversikten. Det gjør det også lettere senere å utvide programmet med flere typer figurer uten at diagrammet må endres. Det betyr at 4 Vi har brukt et annet symbol for aktøren i dette tilfellet. Det er tillatt i UML. Man kan legge inn egne symboler for å gjøre en modell rikere. side 26 av 29

operasjonene på dette objektet må betraktes som generiske. Det samme er tilfellet med figurobjektet. De stiplede vertikale linjene er såkalte livslinjer for objektene og representerer en tidsdimensjon uten å angi en tidsskala. De horisontale pilene representerer meldinger som et objekt sender til et annet. Teksten over pilene er de operasjoner som utløses som svar på disse meldingene. Et objekt kan sende melding til seg selv. Et samarbeidsdiagram viser den samme informasjon i en annen dimensjon. Figur 13 viser et samarbeidsdiagram for eksemplet vårt. Eksemplet er selvforklarende. Det dreier seg om samspill mellom objekter. Piler viser retningen på meldingsutvekslingen. Teksten over pilene er navn på operasjoner. Tallet foran operasjonen angir rekkefølgen. 16:visDialog 17:visResultat :Resultat 2:visView 9:hentData 15:visResultat :View 7:hentData 4:visDialog 8:hentData :Dialog 5:settData 3:klikkFigur 6:OK 18:OK :Beregner 1:start 19:slutt 10:settData 11:beregnAreal 12:beregnOmkrets 13:hentAreal 14:hentOmkrets :Figur Figur 13 1.8. Sluttkommentar til denne leksjonen. Vi har i denne leksjonen tatt for oss modeller og nytten av å modellere. Det er gjort et raskt sveip innom noen av de mest sentrale modeller som vi lager i objektorientert systemutvikling. UML som modelleringsspråk er introdusert. Men vi har vært litt overfladiske i beskrivelsen av hvordan vi finner frem til klasser og objekter, hvilke faser vi er i, og hvordan objekter skal spille sammen for å realisere et godt programvaresystem. Poenget med dette faget er å introdusere mer systematiske måter å gjøre dette på. Det vil derfor være tema i senere leksjoner. side 27 av 29

1.9. Referanser 4. Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User s Guide, Addison-Wesley 1998, ISBN 0-201-57168-4 5. Ivar Jacobson med flere, Object-Oriented Software Engineering, A Use Case Driven Approach, Addison-Wesley 1992, ISBN 0-201-54435. 6. James Rumbaugh med flere, Object-Oriented Modelling and Design, Prentice Hall 1991, ISBN 0-13-630054-5 7. Paul Allen & Stuart Frost, Component-Based Development for Enterprise Systems, Cambridge University Press 1998, ISBN 0-521-64999-4 8. Martin Fowler, UML Destilled, Applying the Standard Object Modelling Language, Addison-Wesley 1997, ISBN 0-201-32563-2 9. Alan M. Davis, Software Requirements, Analysis & Specification, Prentice Hall 1990, ISBN 0-13-824814-1 10. Craig Larman, Applying UML And Patterns, An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2.utgave, Prentice Hall 2002, ISBN 0-13- 092569-1 11. Berry W. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer, Mai 1998. 12. Terry Quantrani, Visual Modeling with Rational Rose and UML, Addison-Wesley 1998, ISBN 0-201-31016-3. 13. Watts S. Humphrey, Introduction to the Personal Software Process, Addison-Wesley 1997, ISBN 0-201-54409-7. 14. Watts S. Humphrey, A Dicipline for Software Engineering, Addison-Wesley 1995, ISBN 0-201-54610-8. 15. Paul Allen and Stuart Frost, Component-Based Development for Enterprise Systems, Cambridge University Press 1998, ISBN 0-521-64999-4. 16. Putnam P. Texel and Charles B. Williams, Use cases combined with Booch, OMT, UML, Prentice Hall 1997, ISBN 0-13-727405-X. 17. Ivar Jacobson & al., Object-Oriented Software Engineering, A Use Case driven Approach, Addison-Wesley 1992, ISBN 0-201-54435-0. 18. James Rumbaugh & al, Object-Oriented Modeling and Design, Prentice Hall 1991, ISBN 0-13-630054-5 19. Grady Booch, Object-Oriented Analysis and Design, Benjamin/Cummings 1994, ISBN 0-8053-5340-2. 20. Ivar Jacobson, Grady Booch, James Rumbaugh, The Objectory Software Development Process, Addison Wesley 1999, ISBN 0-201-57169-2. 21. Martin Fowler and Kedall Scott, UML Distilled, Addison Wesley 1997, ISBN 0-201- 32563-2. side 28 av 29