Objektorientert analyse og design med UML i kurset programmeringslaboratorium

Trond Løvereide

Som kjent er faget vårt i stadig utvikling og som en konsekvens av dette skjer det også endringer med kursene våre. Og i høst er det bl.a. kurset "programmeringslaboratorium" som har fått en ansiktsløftning. Eller kanskje man skal snakke om et større inngrep som ikke bare er av kosmetisk art.

Avdelingen har ihvertfall sett et økende behov for å ha utviklingsmetodikk og utviklingsverktøy for bruk i større prosjekter med i studiet. Kurset programmeringslab har gjennom årene hatt et variabelt innhold, men med en rød tråd, nemlig utvikling av større systemer. Og i år ble det derfor besluttet å endre kurset til å konsentrere seg om UML, objektorientert analyse/design og objektorientert systemutvikling.

UML og objektorientering

UML står for Unified Modeling Language og er en notasjon, dvs. en samling med symboler og diagrammer som kan brukes til å lage en visuell modell av et system. Det som er nytt med UML i forhold til tidligere slike notasjoner er U’en, nemlig unified. Det betyr at man har blitt enige om en standard for slike modeller. Tidligere har det vært flere slike "standarder" og man kunne oppleve at ulike miljøer bruker to ulike symboler for samme ting, eller at samme symbol hadde ulik mening. En unik mulighet for unødvendige misforståelser, med andre ord. I oktober 1995 ble så versjon 0.8 av UML lansert og i tillegg til notasjonen var også en utviklingsmetode inkludert. Senere så man at det kunne være nyttig å definere UML som en standard for notasjon uten at dette ble knyttet til en utviklingsmetode, og f.o.m. UML 1.0 omfattet standarden kun notasjonen. Den seneste versjonen, UML 1.1 ble presentert for The Object Managenement Group (OMG) i september 97 og akseptert som en standard måneden etter.

Jeg skal ikke gå noe særlig inn på hverken symbolene eller diagrammene i UML her, men vil bare vise et eksempel på et klassediagram hvor man viser hvordan to klasser A og B defineres som subklasser til java.awt.Frame og java.awt.Dialog og implementerer interfacet ActionListener og har en avhengighet til klassen ActionEvent.

Figur 1. Et klassediagram i UML.

Slike og endel andre diagrammer lages for hele systemet og gir oss en visuell modell som er veldig nyttig i systemutviklingen.

En notasjon, et verktøy og en metode

I tillegg til notasjonen UML trenger man også et verktøy for å lage modellene og en utviklingsmetode. Disse tre delene utgjør det som Terry Quantrani [3] kaller "The Triangle for Success". I kurset valgte jeg derfor å legge vekt nettopp på disse tre delene. Notasjonen er UML, verktøyet er Rational Rose og metoden er en forenkling av en metode som kalles "Rational Objectory Process". Ønsket om å ha med alle disse tre delene var også en av kravene jeg prøvde å tilfredstille ved valg av lærebok. Det ble vurdert mange lærebøker, bl.a en "standard bok" som heter "Visual Modeling with Rational Rose". Denne boken retter seg mye mot UML, hvordan lage modeller i Rational Rose og litt om objektorientert analyse og design (OOAD). Bokens styrke er at den er grundig i forhold til Rational Rose, men den har lite om utviklingsmetodikk. Den har også lite om kodegenerering og den benytter C++, mens vi ønsket å bruke JAVA. Neste bok som ble vurdert var UML Toolkit [2], og denne boken var lenge en favoritt. Den benytter Rational Rose, kobler modellene mot eksempler i JAVA og er veldig grundig i beskrivelsen av UML og har med litt om OOAD. Den er litt svak på utviklingsmetodikk, men det er med. Boken vurderes som så god at det kan bli aktuelt å bruke boken til neste år. Boken som ble valgt inneholder derimot alt jeg ønsker.

En grundig innføring i UML, uten at den er koblet mot et spesielt utviklingsverktøy (Rational Rose eller Microsoft Visual Builder blir anbefalt) og den gir en grei innføring i en utviklingsmetode. Det gis også eksempler på generert kode i JAVA, C++, SQL og Visual Basic. Selv om vi benytter Rational Rose og JAVA tror jeg dette valget av lærebok gir modellene en friere stilling, uten noen fast tilknytning til utviklingsverktøy og programmeringsspråk.

Rational Rose

Valget av utviklingsverktøy ble gjort antageligvis etter en litt for kort vurderingsfase, hvor faktisk den eneste utfordreren var MS Visual Builder. Når det viste seg at Visual Builder bare kunne generere kode i Visual Basic var i grunnen valget klart. I ettertid har det vist seg at det finnes andre alternativer vi burde vurdert, bl.a. et freeware program. Den vurderingen vil bli gjort før neste gang kurset gjennomføres.

Imidlertid er Rational Rose ikke et dårlig valg, og programmet kan muligens betraktes som en de facto standard innenfor dette fagområdet. Det Rational Rose kan gjøre for oss er:

Tegne modellene i UML-notasjon
Generere programkode fra modellene
Oppdatere modellen fra programkode

Den første delen er relativt enkel. Modellen deles opp i en rekke diagrammer og man "tegner" modellen slik man vil ha den. I denne prosessen vil man fort oppdage at modellen er veldig viktig for å beskrive krav til systemet, finne klasser, koblinger mellom klasser, metoder i klasser osv.

Når man har en "ferdig" modell genereres skjelettkode til systemet. I denne koden legges inn referanser mellom klasser, kommentarer, headere til metoder, variable vi har gitt og endel andre ting. Men like viktig er det kanskje at systemet også lager en struktur med pakker og komponenter og holder rede på hvilke filer som er avhengige av andre klasser eller pakker og legger inn passende "import"-statement. Hvis man er litt grundig i oppsettet av modellen og har klart for seg hvordan Rational Rose avbilder UML til JAVA kan man faktisk får en samling java-filer som lar seg kompilere direkte, men som selvfølgelig ikke har noen funksjonalitet.

Etter at denne skjelettkoden er laget må vi selv fylle inn kode i metodene, legge inn manglende variabler osv.

Neste trinn i utviklingsprosessen er nå å oppdatere modellen med det nye vi har lagt inn i program-koden. Dette gjøres med en "reverse engineering"-funksjon i Rational Rose. Nye klasser, metoder, variable osv. vi har lagt inn i JAVA-koden vil da bli lagt inn modellen. Så kan vi arbeide videre med modellen, evt. legge til nye krav, nye klasser osv, og generere ny programkode.

Poenget med hele denne prosessen er selvfølgelig at det vi allerede har lagt inn skal bevares, mens vi hele tiden legger inn nye ting. Fjerner vi noe fra modellen vil det også bli fjernet (dvs. kommentert ut) i programkoden. Totalt sett kaller man dette for "roundtrip engineering" hvor man vekselvis jobber med modellen og programkoden.

En utviklingsmetode

Som allerede nevnt benytter den valgte læreboken en forenklet utgave av en utviklingsmetode som kalles "Rational Objectory Process". Trass i forenklingen har metoden med seg de tre viktigste punktene i metoden, nemlig at utviklingen skal være

drevet av "use-cases"
sentrert på software-arkitekturen
iterativ og inkrementell

Siden disse tre punktene er de sentrale i metoden, skal jeg si litt om hver av dem. Dette blir veldig kort, en mer omfattende beskrivelse av metoden kan finnes på Rational Softwares side for "technical papers" [6] eller kursets lærebok [1].

Use-cases

Et meget sentralt begrep, både i UML og i Rational Objectory Process er "use-cases", eller "bruksmønstre" på norsk. Et bruksmønster er en oppgave som systemet skal kunne håndtere. Hvert bruksmønster skal definere en egen og avsluttende deloppgave for systemet, og man skal også beskrive hvilke aktører som skal benytte seg av hvert bruksmønster. Systemets samling av bruksmønstre settes ofte opp sammen med den/de som skal bruke systemet og brukes til å fange opp systemets kravspesifikasjon.

For å se på et eksempel kan vi ta for oss et system for å registrere bøker, lånere og utlån på et bibliotek. Et passe bruksmønsterdiagram kan da se ut omtrent som i figur 2.

Figur 2. Et bruksmønsterdiagram.

At utviklingsprosessen skal være drevet av bruksmønstrene betyr at man starter med disse, og finner klasser, metoder, variable osv. utfra hva man må ha for å kunne gjennomføre bruksmønsterne. Alle klasser, metoder, osv. skal lages for å kunne gjennomføre et bruksmønster, ingenting lages som ikke er koblet til ett eller flere bruksmønster.

Software-arkitektur

Det neste punktet i metoden er at den er sentrert på software-arkitektur. Det er mye som kan legges i dette begrepet, men her betyr det at man skal beskrive systemet fra 5 ulike synsvinkler, såkalte "views". Av disse synsvinklene er det "use-case view" som er litt spesiell, så man kaller ofte denne oppdelingen for en "4+1 view modell". De andre synsvinkelene er:

Logical view som tar for seg den logiske oppbygningen til systemet. Det vil i praksis si den statiske oppbygningen med klasser og objekter. Her inngår også bruken av "patterns" og "frameworks".
Implementation view som tar for seg systemets oppbygning i pakker og klasser og avhengigheter mellom disse.
Process view som beskriver ulike prosesser i systemet. Dette har størst betydning i systemer med multithreading.
Deployment view beskriver systemets fysiske oppbygning med terminaler, servere, nettverk osv.

Iterativ og inkrementell

Det siste punktet tar for seg hvordan selve utviklingsprosessen kan styres for å minimere risikoen for at prosjektet skal mislykkes. Og de to sentrale begrepene her er iterativ og inkrementell utvikling.

Med iterativ menes at man skal dele utviklingsprosessen opp i en serie iterasjoner, hvor hver iterasjon kan gjennomføres etter tradisjonell "waterfall"-modell. Med dette menes her en modell hvor man tar for seg analyse, design, koding og test og leverer et ferdig produkt etter test-fasen. I en iterativ prosess tenker man seg derimot at utviklingen skal gå i flere omganger, og at hver omgang skal være inkrementell, dvs at man skal utvide systemets funksjonalitet og grensesnitt etterhvert. Og målet må være at det skal lages en fungerende (kjørbar) prototype etter hver iterasjon.

I tillegg til dette fokuseres det også mye på at hver iterasjon skal være "risikodrevet". Det betyr at til hver iterasjon skal det foretas en risikoanalyse for å finne de mest risikable punktene i systemet så langt. Det er nettopp disse punktene som man skal ta fatt i, og dermed skal man stadig eliminere risikable punkter i systemet. Man skal ikke "spare" det vanskelige til slutt, slik det ofte gjøres, men heller identifisere de kritiske punktene på et tidlig tidspunkt og eliminere disse.

Noen erfaringer

Personlig har jeg lært mye under utviklingen av dette kurset og har igrunnen blitt "frelst" når det gjelder bruk av slike modeller og utviklingsverktøy. Jeg kan ikke tenke meg å starte et prosjekt uten først å lage en modell og lage skjelettkode, selv for de minste enkle eksemplene. Og ser vi på litt større systemer tror jeg vi bare er nødt til å bruke metodikk og verktøy av denne typen. Gevinsten er ikke bare at man enkelt får generert kode, men like mye den oversikten metoden gir. Studentene har imidlertid vært litt lunkne, og vist en viss skepsis for behovet og nytten av visuelle modeller og en utviklingsmetodikk. Noen har sett på dette som unødvendig ekstraarbeid (like nyttig som kommentarer i koden...), mens andre etterhvert har innsett at det har en viss verdi. Det er ikke helt umulig at jeg har undervurdert motiveringsdelen av kurset og tatt det for gitt at studentene ville se nytten etterhvert som de lærte mer. En mulig og sannsynlig vei for å overvinne denne skepsisen, ihvertfall for kommende kull, må være å ta med slike verktøy allerede i begynnerkursene. Men det er en annen diskusjon og den får komme senere.

Referanser

Instant UML, Pierre-Alain Muller, Wrox Press inc, ISBN 1-861000-87-1
UML Toolkit, Hans-Erik Eriksson and Magnus Penker, Wiley Computer Publishing, ISBN 0-471-19161-2
Visual Modelling with Rational Rose and UML, Terry Quantrani, Addison-Wesley, ISBN 0-201-31016-3
Kursets hjemmeside: http://tor.hiof.no/~trondl/proglab
Rational Softwares hjemmeside: http://www.rational.com
Rational Objectory Process (pluss noe mer): http://www.rational.com/support/techpapers/

HØit Nr. 1-99