Kap. 22 Objektorientert konstruksjon (OO, OOD) 22. Objektorientert Design (OOD) OO konstruksjon () overfører OO analysemodellen til en OODmodell. OOD har modularitet på flere nivå: Hovedkomponenter i systemet organiseres i systemnivå moduler som vi kaller. Data og operasjoner innkapsles i objekter (klasser) som er moduler som er byggesteiner i OO systemer. OOD må beskrive data(attributter), hvordan de er organisert, og operasjonene (prosedyrene) som utføres (data og algoritmer). Systemutvikling Kap.22 Objektorientert 1 Systemutvikling Kap.22 Objektorientert 2 22. Objektorientert Design (OOD) OOD bygger på 4 viktige konstruksjonsbegreper: 1. Abstraksjon (abstraction). 2. Informasjonsskjuling (information hiding) 3. Funksjonell uavhengighet (functional independence). 4. Modularitet (modularity). Konstruksjonsaktivitetene i OOD inkluderer: OO Design OO Programmering OO Testing Systemutvikling Kap.22 Objektorientert 3 22.1 Konstruksjon av OO system Som i tradisjonell (kap.13), har vi også i OOD en konstruksjonspyramide med 4 lag (fig. 22.1): 1. Subsystem konstruksjon. 2. Klasse- og objektlag. - Klassehierarki og representasjon for hvert objekt. 3. Meldingslag. - Kommunikasjon med samarbeidspartnerne, eksterne og interne grensesnitt i systemet. 4. Ansvarslag. - Datastrukturer og algoritmekonstruksjon for alle attributter og operasjoner for hvert objekt. Ansvars Det er også et lag til i som er fundamentet som pyramiden hviler på. Det er domene objekter (her kalt Meldings konstruksjonsmønster) som har en nøkkelrolle i å bygge en infrastruktur for OO systemer. De skal gi støtte Klasse og objekt til menneske-maskin grensesnitt, oppgave- og dataadministrasjon, og de kan også Subsystem brukes til å utfylle selve applikasjonen. Fig.22.1: OO pyramide Systemutvikling Kap.22 Objektorientert 4 Object-Oriented Design message des ign class and object subsys tem des ign res ponsibilities 22.1.1 Sammenlikning av vanlig og OO OO er lik vanlig på: data (når attributter skal representeres) grensesnitt (når en meldingsmodell lages) prosedyrekonstruksjon (når operasjoner (metoder) lages). På arkitekturkonstruksjon er det forskjeller: Et OO system har ikke en hierarkisk kontrollstruktur som vanlige program. I et OO system er det mer samarbeid mellom objekter. Fig. 22.2 viser sammenhengen mellom OO analysemodell (kap. 21), og desingmodellen som utvikles fra den. På side 588 er det også listet opp 10 punkter for sammenlikning av vanlig og OO Systemutvikling Kap.22 Objektorientert 5 Systemutvikling Kap.22 Objektorientert 6 1
OOA and OOD OOA and OOD Attributes, operations, collaborators Objectrelationship CRC Index Cards model Use cases Object-Behavior Mode l message Class and object subsys tem res pons ibilities Analysis Model classes attributes methods relations hips behavior Design Model objects data structures algorithms messaging control THE ANALYSIS MODEL THE DESIGN MODEL Systemutvikling Kap.22 Objektorientert 7 Systemutvikling Kap.22 Objektorientert 8 22.1.2 Hovedtrekk i Meyer foreslår 5 kriterier for å vurdere en metodes evne til å oppnå modularitet: Dekomponeringsmuligheter (decomposability) Sammensetningsmuligheter (composability) Forståelighet, selvforklarende (understandability) Kontinuitet (continuity) Beskyttelse (protection) 22.1.3 OO metoder De OO analysemetodene vi så på i kap 21 har også tilsvarende metoder. Metodene er: Boochs metode Rambaughs metode Jacobsons metode (OOSE) Coad og Yourdans metode Wirfs-Brocks metode Systemutvikling Kap.22 Objektorientert 9 Systemutvikling Kap.22 Objektorientert 10 22.1.3 OO metoder Metodene er ganske like, og de kan sammenfattes til følgende generelle trinn: 1. Beskriv hvert 2. Velg en stategi for implementering av dataadm, grensesnitt, og oppgave adm. 3. Lag en kontrollmekanisme for systemet 4. Objektkonstruksjon prosedyrebeskrivelse for operasjoner og datastrukturer for attributter. 5. Meldingskonstruksjon ut fra samarbeid mellom objekter og obj. relasjoner. 6. Lag en meldingsmodell. 7. Gjennomgå konstruksjonsmodellen, og gjør nødvendige iterasjoner Disse stegene er iterative (gjentas), og det må utføres mer OOA innimellom. Prosessen fortsetter til vi har en komplett konstruksjon. 22.1.4 UMLs OO Design UML har to (hoved-) aktiviteter: System representasjon av program-arkitektur. Objekt fokuserer på å beskrive objekter og kommunikasjonen mellom dem: Detaljert spesifikasjon av datastrukturene til attributtene. Prosedyre av alle operasjoner Grensesnitt mellom objekter Komplett meldingsmodell I forhold til andre OOD er UML utvidet med Design av brukergrensesnitt Data-administrasjon (data management) Oppgaveadministrasjon (task management) for ene Fig 22 viser prosessflyten fra analyse til Systemutvikling Kap.22 Objektorientert 11 Systemutvikling Kap.22 Objektorientert 12 2
Process Flow for OOD 22.2 Systemkonstruksjonsprosessen Følgende trinn inngår i OO systemkonstruksjon: Del analysemodellen opp i Identifiser parallelle (samtidige) aktiviteter. Fordel er på oppgaver (og prosessorer). Design brukergrensesnitt Velg basisstrategi for dataimplementering og -administrasjon Identifiser globale ressurser og kontrollmekanismer som er nødvendige for å aksessere dem. Konstruer en passende kontrollmekanisme for systemet. Vurder hvordan grensebetingelser skal håndteres. Gå gjennom (review) og vurder avveininger (valgmuligheter - trade-offs) I de følgende seksjoner gjennomgås detaljene i hvert steg. Systemutvikling Kap.22 Objektorientert 13 Systemutvikling Kap.22 Objektorientert 14 22.2.1 Del opp analysemodellen Kriterier for å isolerer : Subsystemet skal ha et klart definert grensesnitt som all kommunikasjon med resten av systemet skal gå gjennom. Med unntak av et lite antall kommunikasjonsklasser, skal klassene i et bare samarbeide med andre klasser i et. Det bør være et lite antall er Subsystemene kan deles internt for å redusere kompleksiteten. Når to kommuniserer, kan de etablere en klient-server eller toveis (peer-to-peer) forbindelse. (Klient-server: et utfører tjenester for andre, peer-to-peer: ene utfører tjenester for hverandre.) Kommunikasjons- og informasjonsflyten kan representeres i et dataflytdiagram (DFD) der sirklene (prosessene) er. Systemutvikling Kap.22 Objektorientert 15 22.2.2 Samtidighet og allokering av Objekter eller er som reagerer asynkront og samtidig på hendelser er parallelle (samtidige). Vi har da to allokeringsalternativ: Hvert tildeles en egen uavhengig prosessor Subsystemene kjører på samme prosessor. Operativsystemet må da synkronisere parallelliteten. Samtidige oppgaver defineres ut fra tilstandsdiagrammet for hvert objekt. Hvis hendelsesflyten indikerer at bare et objekt er aktivt av gangen, kan en kontrolltråd (thread of control) etableres. Oppgaver (tasks) i OO systemet konstrueres ved å isolere kontrolltrådene. For å velge prosessorstrategi, må ytelseskrav, kostnader, og administrasjon av prosessor-prosessor-kommunikasjon vurderes. Systemutvikling Kap.22 Objektorientert 16 22.2.3 Oppgaveadministrasjon Coad og Yourdon foreslår følgende strategi for å konstruere objektene som administrerer parallelle oppgaver: Bestem karakteristikken til oppgavene (event/interrupt eller klokkestyrt) En koordinatoroppgave og tilsvarende objekter defineres. Koordinator og andre oppgaver integreres. Vi må også bestemme prioriteten til oppgavene, og hvor kritiske de er: Høyt prioriterte oppgaver må ha umiddelbar aksess til prosessor. Høyt kritiske oppgaver må fortsette selv om tilgjengelige ressurser reduseres, eller system kjører i redusert utgave. 22.2.3 Oppgaveadministrasjon Når karakteristikkene til oppgavene er bestemt, må objektenes attributter og operasjoner som kreves for koordinering og kommunikasjon defineres. Mønstret for spesifisering av en oppgave: Objekt (oppgave)navn (task name) Beskrivelse Prioritet (på oppgaven) Tjenester - liste av operasjoner som objekter er ansvarlige for. Koordinert av - måten objektet er aktivert (startet) på. Kommuniserer via - input og output dataverdier relevante for oppgaven. Systemutvikling Kap.22 Objektorientert 17 Systemutvikling Kap.22 Objektorientert 18 3
22.2.4 Brukergrensesnitt Ved konstruksjon av brukergrensesnitt (Human-computer interface - HCI) tar en utgangspunkt i brukerscenarier (use cases). Det lages et kommandohierarki som definerer de forskjellige menyer. I dag finnes det ferdige klasser for GUI. De har funksjoner for kontroll av vinduer, ikoner, mus osv. 22.2.5 Dataadministrasjonskomponenten Dataadministrasjon kan deles i to områder: 1. Adm av data som er kritisk (viktig) for applikasjonen. 2. Oppretting av en infrastruktur for lagring og gjenfinning av objekter. Dataadministrasjon konstrueres lagdelt: Lavnivå krav for manipulering av datastrukturer skilles fra høynivå krav for behandling av systemattributter. På systemnivå kan et databasesystem brukes, med egne klasser fra leverandøren (gjenbruk). Ved konstruksjon av dataadministrasjon, må en konstruere attributter og operasjoner. Systemutvikling Kap.22 Objektorientert 19 Systemutvikling Kap.22 Objektorientert 20 22.2.6 Ressursadministrasjon Globale systemressurser kan være: eksterne enheter som tilgang til disk, prosessor, kommunikasjonslinjer, eller abstraksjoner som en database eller et objekt. Det bør lages en kontrollmekanisme for adm av ressurser, for eksempel ved å lage en klasse som eier ressursene, og som administrerer all tildeling av dem. (Synkronisering, løse opp konflikter). 22.2.7 Kommunikasjon mellom Vi kan bruke samme modell for samarbeid mellom er som vi brukte til O-O samarbeid. Fig. 22.4 viser prinsipper for samarbeid, enten klient-server, eller to-veis (peer-to-peer) modell. Vi må spesifisere kontrakten som er opprettet mellom ene. Kontrakten spesifiserer hvordan er kommuniserer med hverandre. Systemutvikling Kap.22 Objektorientert 21 Systemutvikling Kap.22 Objektorientert 22 client peer contract System Design request request request server contract peer contract 22.2.7 Kommunikasjon mellom Vi kan bruke følgende fremgangsmåte for å spesifisere en kontrakt for et : 1. List alle forespørsler som samarbeidspartnere kan gjøre til et. Sorter forespørslene etter, og definer dem innenfor en eller flere passende kontrakter. Husk også kontrakter som er arvet! 2. For hver kontrakt, noter operasjonene (også de arvede) som kreves for å implementere ansvarsforhold som følger av kontrakten. Sørg for å tilordne operasjonene til spesifikke klasser i et. 3. Ta en kontrakt av gangen, og lag en tabell som vist i fig. 22.5. 4. Hvis kommunikasjon og samarbeid mellom ene er komplisert, kan det lages en samarbeidsgraf som vist i fig. 22.6. Systemutvikling Kap.22 Objektorientert 23 Systemutvikling Kap.22 Objektorientert 24 4
Subsystem Collaboration Table Subsystem Example Control panel request for status assign to zone test status Sensor request for system status specification of type of alarm periodic status check request for alarm notification periodic check-in require for configuration update Central communication Systemutvikling Kap.22 Objektorientert 25 Systemutvikling Kap.22 Objektorientert 26 22.3 Objektkonstruksjonsprosessen I objektkonstruksjon lager vi en detaljer konstruksjon av attributtene og operasjonene som hver klasse består av, og meldingene som forbinder klassen til samarbeidspartene. 22.3.1 Objektbeskrivelse En beskrivelse kan ha en av to former: 1. En protokollbeskrivelse som beskriver grensesnitt og meldinger som objektet kan motta, og operasjonene som utføres som følge av de enkelte meldingene. 2. En implementasjonsbeskrivelse som viser implementasjonsdetaljer for hver operasjon som følger av en melding som sendes til objektet. Den vil bestå av: 1. En spesifikasjon av objektets navn og referanse til klasse. 2. En spesifikasjon av private datastrukturer med elementer og typer. 3. Prosedyrebeskrivelse av hver operasjon, evt. referanse til en beskrivelse. Systemutvikling Kap.22 Objektorientert 27 Systemutvikling Kap.22 Objektorientert 28 22.3.2 Konstruksjon av algoritmer og datastrukturer Konstruksjon av algoritmer og datastrukturer i OOD følger samme prinsipper som i vanlig konstruksjon (og i alg. met.!). En algoritme spesifiserer en operasjon, for eksempel en beregning eller en prosedyresekvens som kan implementeres som en selvstendig modul. Kompliserte moduler må deles opp i mindre moduler. Datastrukturer konstrueres parallelt med algoritmene. Operasjoner kan deles i tre klasser: 1. Datamanipulering (legge til, slette, reformatere, velge (søke)) 2. Beregningsoperasjoner 3. Overvåking (monitorering) av et objekt for en kontrollhendelse. 22.3.2 Konstruksjon av algoritmer og datastrukturer Når objektmodellen er konstruert, må den optimaliseres. Følgende tre innfallsvinkler brukes: Gå gjennom objekt-relasjonsmodellen for å kontrollere at konstruksjonen fører til effektiv utnyttelse av ressurser, og at den er lett å implementere. Legg til redundans der det er nødvendig. Kontroller attributt datastrukturene og tilsvarende operasjoner (algoritmer) for å forbedre prosesseringseffektiviteten. Lag nye attributter for å spare utledet (beregnet) informasjon, og dermed spar reberegning. Systemutvikling Kap.22 Objektorientert 29 Systemutvikling Kap.22 Objektorientert 30 5
22.4 Konstruksjonsmønster Gode konstruktører på alle områder har en evne til å se mønster som karakteriserer et problem, og tilsvarende mønster kan kombineres for å lage en løsning. OOD er mer fleksibel, elegant og utnytter gjenbruk. I hele OOD prosessen må en undersøke mulighetene for å bruke eksisterende konstruksjonsmønster, og lage nye der gjenbruk ikke er mulig. 22.4.1-3 Eksempler på konstruksjonsstruktur Eksempler på konstruksjonsstrukturer: Et eksemplar av et objekt i en anvendelse (en file manager i et operativsystem). Mønster for å overvåke lagring og gjenfinning av systemtilstand (Memento) Sekvensiell prosessering av data (rapporteringsprogram) Systemutvikling Kap.22 Objektorientert 31 Systemutvikling Kap.22 Objektorientert 32 22.4.4 Beskrivelse av en konstruksjonsstruktur Alle konstruksjonsstrukturer (-mønster, pattern) kan beskrives ved å spesifisere følgende punkter (klassifikasjonskriterier, taxonomi): Navnet på strukturen Hensikten med strukturen Problemet strukturen vanligvis anvendes på. Klasser som er nødvendig for implementering Ansvar og samarbeid mellom klaser Retningslinjer for programmering (effektiv implementering). Eksempel på kildekode Kryssreferanse til relaterte konstruksjonsmønstre. 22.4.5 Fremtiden for konstruksjonsstruktur Konstruksjonsstrukturer (-mønster, pattern) vil (kanskje), sammen med komponenter, føre til at systemutvikling blir mer likt andre ingeniørdisipliner. Klasser vil tilsvare komponenter i elektronikk, og mønstre vil tilsvare små kretser som er bygd opp av komponenter. Det er fortsatt mye arbeid i å kartlegge og katalogisere mønstre. Systemutvikling Kap.22 Objektorientert 33 Systemutvikling Kap.22 Objektorientert 34 22.5 Objektorientert programmering (OOP) Dette underkapitlet viser hvordan objekter dokumenteres i UML. 22.5.1. Klassemodell Fig 22.10 viser klassebeskrivelse Kunde Navn Adresse Status GetKonto():Kontosamling SetNavn(Nyttnavn); GetNavn(): String 22.5.2 Generalisering Fig. 22.11 viser generalisering AktivKonto Konto SpareKonto Kommentarboks: Ikke alle attributter og operasjoner er vist Ingen attributter og operasjoner er vist Systemutvikling Kap.22 Objektorientert 35 Systemutvikling Kap.22 Objektorientert 36 6
22.5.3. Aggregering og sammensetning Fig 22.12 viser aggregering Fabrikkprodukt Fig. 22.13 viser generalisering og aggregering Fabrikkprodukt 22.5.3. Aggregering og sammensetning Fig 22.14 viser sammensetning Kunde 22.5.4 Assosiasjon (forbindelse) Fig. 22.16 viser multiplicitet Leder Komponent Hul diamant viser aggregat Komponent KontoSamling Fylt diamant viser sammensetning (composition) 1 1..* En leder er leder for En eller flere ansatte Ansatt Komponent Komponent Komponent Systemutvikling Kap.22 Objektorientert 37 Systemutvikling Kap.22 Objektorientert 38 22.5.5 Brukstilfeller (Use-Cases) Fig. 22.19 viser enkelt brukstilfelle Fig. 22.20 Flere brukstilfeller Fig. 22.21 Eksempel på brukstilfeller som bruker et annet brukstilfelle Lag statusrapport <<uses>> Låner Lån bøker Leder Fordel arbeidsoppg Varehusleder Spør etter produkt <<uses>> Spør etter lagerbeholdning Verifiser produkt Avslutt prosjekt Det vil være mange flere brukstilfeller for en varehusleder <<uses>> Spør etter ordredetaljer Initier prosjekt Systemutvikling Kap.22 Objektorientert 39 Systemutvikling Kap.22 Objektorientert 40 Fig. 22.22 Et enkelt sekvensdiagram Fig. 22.24 Eksempel på tilstandsdiagram GammelKunde: BankKunde Leder: Ansatt Oppdater Rapport SalgsRapport Salgs- Transaksjon Avslutt konto Opprett konto Endredetaljer Lag transaksjoner Aktiv konto Transaksjon Tom konto Transaksjon Systemutvikling Kap.22 Objektorientert 41 Systemutvikling Kap.22 Objektorientert 42 7