Objektorientert utforming In 140 Sommerville kap. 12

Mål n Forstå hvordan programvare kan utformes som samhandlende objekter med egen tilstand og egne operasjoner n Kjenne de viktigste stegene i en objektorientert utformingsprosess n Forstå de viktigste modellene som kan brukes til å dokumentere en objektorientert utforming n Bli kjent med hvordan disse modellene kan uttrykkes i UML

Introduksjon n "Ting" heller enn funksjoner n Det ferdige systemet bygges opp av samhandlende objekter n Hvert objekt har ansvar for sin egen tilstand og gir adgang til operasjoner på denne tilstanden. n Tilstand er verdiene til objektets attributter

Introduksjon n Objektorientert utforming går ut på –Identifisere og utforme objektklasser –Designe sammenhenger mellom objektklasser n Når det ferdige systemet kjører –Skapes objekter som definert av objektklassene

Introduksjon n Objektorientert utforming er trinn 2 1. Objektorientert analyse gir en objektorientert modell av anvendelsesområdet. Objekter og operasjoner som identifiseres her hører til anvendelsesområdet 2. Objektorientert utforming gir en objektorientert modell av programvaren som skal oppfylle identifiserte krav. Objekter fra analysen kommer igjen her, men flere objekter må opprettes. 3. Objektorientert programmering er å overføre utformingen til et kjørbart program vha et Objektorientert programmeringsspråk som Java, C++, Smalltalk eller Simula)

Introduksjon – Samme notasjon i hvert trinn – Overgang fra trinn til trinn med økende detaljering og nye objektklasser – Innkapsling gir mulighet for å utsette avgjørelser om datarepresentasjon, objektfordeling og sekvensiell vs samtidig eksekvering

Introduksjon – Uavhengige objekter er vedlikeholdbare –Jo færre andre objektklasser det er kobling til jo større uavhengighet –Innmatendringer og øket tjenestetilbud skal ikke gi behov for endringer hos andre objekter – Klar sammenheng mellom programvareobjekter og tilsvarende virkelige objekter gir forståelighet og dermed lettere vedlikehold – Objekter er gjenbrukbare – fordi de representerer virkelige "ting", ting som går igjen i flere systemer. – Flere mulige metoder for utforming

Objekter og objektklasser – Definisjon Et objekt er en ”ting” eller begrep som har en tilstand og et definert sett av operasjoner som arbeider på tilstanden. Tilstanden representeres ved et sett av objektattributter. Operasjonene til et objekt gir tjenester til andre objekter som benytter tjenestene når data skal behandles Objekter skapes i følge en objektklassedefinisjon. Objektklassedefinisjonen tjener dermed som mal for å lage objekter. Den inneholder deklarasjoner av alle attributter og operasjoner som hører til et objekt av klassen

Objekter i UML

Kommunikasjon mellom objekter – Bruk av tjenester fra andre objekter= metodekall – Informasjonsutveksling gjennom parametere og eventuelt funksjonsverdi – Meldingsbasert kommunikasjon – I samme program som tradisjonelle prosedyrekall

Samtidige (Concurrent objekter) n Objekter kan kjøre som parallelle prosesser (tråder) n Objekter kan eksistere på separate systemer n I praksis er standardinnstillingen utførelse i rekkefølge, med metoder som prosedyrekall n Java inneholder støtte for tråder. Enkelt å lage parallelle prosesser n To vanlige løsninger –Severobjekter, som starter for å betjene et behov. Eksempel: separate systemer, utskriftstjeneste. Hensikt: Unngå venting –Aktive objekter, selvstyrte tilstandsmaskiner. Hensikt: Tidsstyrt operasjon, Enklere programlogikk.

An active transponder object

OO utformingsprosess n Definer kontekst og modeller av bruk n Utform systemarkitektur n Identifiser objekter og deres klasser n Utvikle utformingsmodeller n Spesifiser objektgrensesnitt

Eksempel værdatasystem n Hensikt: Lage værkart fra forskjellige datakilder –automatiske værstasjoner –værobservatører –ballonger –satellitter n Lagdelt arkitektur

System kontekst og modeller av bruk n Utvikle en forståelse av relasjonene mellom programvaren som skal utvikles og omgivelsene til systemet n System kontekst –Statisk modell som beskriver andre systemer i omgivelsene. n Modell av bruk av systemet – Beskriver hvordan systemet samhandler med omgivelsene

Lagdelt arkitektur

Subsystemer i værstasjonsystemet

Use-cases for en automatisk værstasjon

Use-case beskrivelse

Utformingsmodeller n Utformingsmodeller viser objekter og klasser og relasjoner mellom dem n Statiske modeller beskriver strukturen til systemet basert på klasser og relasjonene mellom dem n Dynamiske modeller beskriver dynamikken i objekter og/eller mellom objekter

Eksempler på utformingsmodeller n Subsystem modeller n Klassediagrammer n Sekvensdiagrammer n Tilstandsmaskinsmodeller n Use-case

Værstasjonens arkitektur

Weather station object classes

Værstasjonens subsystemer

Subsystem modeller n Viser hvordan utformingen er organisert i logiske deler (pakker) av objekter n Bruker UML ”packages” for å innkapsle delsystemer. Logisk modell, kan være annerledes i programmet.

Sekvensdiagrammer n Viser hvordan objekter samhandler –Objektene på toppen av diagrammet –Vertikal tidsakse –Samhandling vist med piler –Bokser på tidsaksen viser at objektet er aktivt(har kontroll)

Sekvensdiagram for datainnsamling

Tilstandsdiagrammer n Dynamisk modell n Viser hvordan objektet endrer tilstand etter interaksjon med andre objekter

Tilstandsdiagram for værstasjon

Objekt grensesnitt spesifikasjon n Bør defineres så tidlig som mulig => muliggjør parallell utvikling n Ikke definer representasjon av objektet, kun grensesnittet n Objektet kan ha flere grensesnitt n Klassediagrammer kan være tilstrekkelig spesifikasjon, men også bruk av programmerspråk, for eksempel JAVA

Grensesnitt for værstasjon

Evolusjon av objektorienterte systemer n Lett å endre utforming –Attributtrepresentasjon påvirker ikke utformingen –Å endre innmaten i et objekt skal ikke påvirke andre objekter –Lav kobling gjør det lett å introdusere nye objekter –Arv og polymorfisme letter introduksjon av nye objekter –Nye metoder kan introduseres uten å endre metodene som er der fra før.