Klassediagram (UML)
En UML-modell av klasser: hver klasse er en boks med navn, egenskaper og metoder. Relasjoner tegnes med piler — åpen trekant (△) for arv (er-en), fylt diamant (◆) for komposisjon (har-en), med multiplisitet som 1..*.
Slik kan du tenke om det
- Boksen leses begge veier Klasseboksen har tre deler i fast rekkefølge: navn, egenskaper, metoder. Oversettelsen går begge veier — hver self.-linje i __init__ blir en egenskap i midtfeltet, og hver def blir en metode nederst. Mer er det ikke.
Vanlige feil
- Du tror et klassediagram bare er løse bokser Det er lett å tro at et klassediagram bare er noen bokser med klassenavn. Men det er *relasjonene* — pilene mellom boksene — som bærer det meste av betydningen. To diagram med nøyaktig samme bokser, men ulike piler, modellerer helt forskjellige programmer.
- Du bruker arv der det egentlig er komposisjon Det er lett å gripe til arv så snart to klasser henger sammen. Men arv passer bare når den ene ER EN av den andre. Hvis den ene heller HAR den andre, er det komposisjon. En spilleliste er ikke en sang — den har mange sanger.
- Du blander attributt og metode Et attributt er noe objektet *har* — en verdi, som `bil.fart`. En metode er noe objektet *gjør* — en handling du kaller, som `bil.kjør()`. I klassediagrammet har de hvert sitt felt: attributtene i midten, metodene nederst. Forvekslingen viser seg som `bil.fart()`, eller som en `def` plassert blant attributtene.
Øv på dette
- Les klassediagrammet
- Flervalg: hvilket symbol?
- Sjekk: trekant eller diamant?
- Fra diagram til kode
- Les komposisjon-diagrammet
- Sjekk: hva mangler i diagrammet?
- Øving: klassediagram for et bibliotek
- Fra klassediagram til konstruktør
- Begrepssjekk: Klassediagram
- Drill: Modellering — symboler
- Drill: Modellering (utfordring)
- Drill: Fra diagram til kode
- Modeller et lite system