Objektorientert utforming In 140 Sommerville kap. 12.

Presentasjon om: "Objektorientert utforming In 140 Sommerville kap. 12."— Utskrift av presentasjonen:

1 Objektorientert utforming In 140 Sommerville kap. 12

2 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

3 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

4 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

5 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)

6 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

7 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

8 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

9 Objekter i UML

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

11 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.

12 An active transponder object

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

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

15 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

16 Lagdelt arkitektur

17 Subsystemer i værstasjonsystemet

18 Use-cases for en automatisk værstasjon

19 Use-case beskrivelse

20 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

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

22 Værstasjonens arkitektur

23 Weather station object classes

24 Værstasjonens subsystemer

25 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.

26 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)

27 Sekvensdiagram for datainnsamling

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

29 Tilstandsdiagram for værstasjon

30 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

31 Grensesnitt for værstasjon

32 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.