2.5 UML og modellering

Tegn huset før du bygger det

En arkitekt tegner blåkopier før en eneste murstein legges. På samme måte er det lurt å planlegge programvare før du koder. Verktøyet for dette heter UML – Unified Modeling Language – et standardisert visuelt språk for å tegne programvaredesign. UML-diagrammer fungerer som blåkopier for kode: de hjelper deg å tenke gjennom strukturen før du skriver en eneste linje Python.

Hvorfor bry seg? UML gir en felles visuell forståelse av systemet, hjelper med planlegging, dokumenterer designet for andre utviklere, og gjør det lettere å diskutere løsninger. Vi skal se på tre sentrale diagramtyper: klassediagrammer, som viser klasser og relasjoner; use case-diagrammer, som viser funksjonalitet fra brukerens perspektiv; og sekvensdiagrammer, som viser interaksjon mellom objekter over tid.

Klassediagrammet er det vanligste. Hver klasse tegnes som en boks med tre rom: navnet øverst, attributtene i midten og metodene nederst. Foran hvert medlem står et symbol for synlighet: - for privat, + for offentlig (public), og # for beskyttet (protected). En Person-boks med - navn: str og + si_hei() svarer altså direkte til en Python-klasse med et attributt og en metode.

Relasjonene mellom klassene

Et klassediagram blir virkelig nyttig når det viser hvordan klassene henger sammen. Hver relasjonstype har sitt eget symbol. Arv tegnes som en pil med en hul trekant: Student peker opp mot Person fordi en student arver fra en person. Komposisjon vises med en fylt diamant: Bil har en fylt diamant mot Motor, fordi motoren er en integrert del av bilen og ikke kan eksistere uten den. Aggregering bruker en tom diamant for en løsere kobling, som en Skole som har Studenter, der studentene kan eksistere uavhengig. En enkel linje er assosiasjon – at en klasse bruker en annen – og en stiplet pil er avhengighet, der den ene bruker den andre midlertidig.

Disse symbolene oversettes rett til kode. Når diagrammet viser arv fra Person til Student, betyr det class Student(Person) med super().__init__() i konstruktøren. Når diagrammet viser komposisjon mellom Bil og Motor, betyr det at Bil i sin konstruktør lager self.motor = Motor(hk). Forskjellen på den fylte og den tomme diamanten er nettopp forskjellen vi lærte tidligere: komposisjon er tett eierskap, aggregering er løsere. Å lese disse symbolene riktig lar deg forstå et helt systemdesign på sekunder, og å tegne dem riktig lar deg formidle ditt eget.

Use case og sekvens – hva og når

Klassediagrammet viser strukturen, men to andre diagramtyper fanger andre sider av systemet. Et use case-diagram viser funksjonaliteten fra brukerens perspektiv. Det består av aktører – tegnet som strekfigurer, for eksempel en kunde eller bibliotekar – og use cases – tegnet som ovaler, som «logg inn», «se saldo» eller «overfør penger». Linjer kobler hver aktør til det vedkommende kan gjøre. Det viktige er at use cases beskriver hva systemet gjør, ikke hvordan. Skal du designe et nettbutikk- eller bestillingssystem og vise hva kunden kan gjøre, er use case-diagrammet det rette valget.

Et sekvensdiagram viser derimot hvordan objekter samhandler over tid. Objektene står som bokser øverst, hver med en vertikal stiplet livslinje nedover som representerer objektets eksistens. Meldinger tegnes som horisontale piler mellom livslinjene, og tynne bokser på linjen viser når et objekt er aktivt. Tenk på en handlekurv: brukeren kaller legg_til, handlekurven spør en vare om prisen og får 199 kr tilbake, brukeren kaller betal, handlekurven regner ut summen internt og svarer «Betalt». Sekvensdiagrammet viser nettopp rekkefølgen av operasjoner.

I praksis kombinerer du gjerne alle tre når du planlegger. For et biblioteksystem kan use case-diagrammet vise hva bibliotekar og medlem kan gjøre, klassediagrammet vise Bok og Medlem med relasjonene mellom dem, og sekvensdiagrammet vise selve utlånsprosessen steg for steg. Ved å planlegge slik unngår du mange feil før du i det hele tatt koder.

Oppsummering

Akkurat som en arkitekt tegner før byggingen, planlegger vi programvare med UML – et standardisert visuelt språk. Klassediagrammer viser klasser med navn, attributter og metoder, og relasjonene mellom dem: arv (hul trekant), komposisjon (fylt diamant), aggregering (tom diamant), assosiasjon (linje) og avhengighet (stiplet pil). Symbolene oversettes direkte til Python-kode.

Use case-diagrammer viser funksjonaliteten fra brukerens perspektiv med aktører og ovaler – hva systemet gjør, ikke hvordan. Sekvensdiagrammer viser hvordan objekter samhandler over tid, med livslinjer og meldinger i riktig rekkefølge. Ved å kombinere de tre kan du tenke gjennom et helt design – som et biblioteksystem – før du skriver kode. Med dette har du fullført seksjonen om avansert OOP og designmønstre.