Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur

Like dokumenter
Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur

Dagens forelesning. o Litt mer om design med UML sekvensdiagrammer. Sentralisert og delegert kontrollstil

Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur

Metode for ansvarsdrevet OO med UML. Dagens forelesning. Hovedflyt for Meld på kurs. Delegering av ansvar i en trelagsarkitektur

Beskjed fra Skagestein

Metode for ansvarsdrevet OO med UML. Dagens forelesning. Hovedflyt for Meld på kurs. Delegering g av ansvar i en trelagsarkitektur

o UML klassediagrammer

Dagens forelesning. o Litt mer om design med UML sekvensdiagrammer. Sentralisert og delegert kontrollstil

NB! Endring i undervisningsplanen

UML klassediagrammer

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell. Dagens forelesning. Fra krav til objekter

Spesifikasjon av Lag emne. Kursregistrering g bruksmønstermodell. Dagens forelesning. Fra krav til objekter

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell (ny versjon) Dagens forelesning. Fra krav til objektdesign

Fra krav til objektdesign

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Spesifikasjon av Lag emne

Kursregistrering bruksmønstermodell

Erfaringer fra våren Oppsummering: Hvordan utvikles et informasjonssystem? Noen eksamenstips, og litt teknikk Hvordan er eksamensoppgaven?

OO Design, del 2. Oversikt over forelesningene. Metode for ansvarsdrevet OO Hva er et objekt. Uke 12: Fra sekvensdiagram til klasser

Erfaringer fra v2010 Oppsummering: Hvordan utvikles et informasjonssystem? Noen eksamenstips, og litt teknikk Hvordan er eksamensoppgaven?

Oversikt over forelesningene. Fra analyse til objektdesign. Utfordringen i å lage OO-modeller. Metode for ansvarsdrevet OO. Uke 12: Ansvarsdrevet OO:

Persistens. Erik Arisholm. Institutt for informatikk Erik Arisholm INF1050-persistens-1

Kravspesifikasjon. Erik Arisholm. Simula Research Laboratory. Institutt for Informatikk. INF1050-krav-1

Arne Maus, Ifi. delvis lån av gamle foiler

Satsvise, interaktive, sanntids/innbakte systemer. Arne Maus, Ifi. Oppdeling av både program og data på flere maskiner

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav?

UML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller

Utvikling fra skallet og inn

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse

UML-Unified Modeling Language

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering

INF1000: Forelesning 7

INF 1050 BRUK AV MODELLERINGSVERKTØYET RATIONAL ROSE

UML 1. Use case drevet analyse og design Kirsten Ribu

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

INF1000: Forelesning 7. Konstruktører Static

UNIVERSITETET I OSLO

Dagsorden. Hovedtemaene i INF102. Fra kjernen og ut. Produksjon av informasjonssystemer. Produksjon av informasjonssystemer

Eksamen INF1050: Gjennomgang, uke 15

Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson

INF1010 UML. Marit Nybakken 26. januar 2004

Use case drevet design med UML

UKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Innhold. INF1000 Høst Unified Modeling Language (UML) Unified Modeling Language (UML)

Universitetet i Bergen Det matematisk-naturvitenskapelige fakultet Institutt for informatikk

Etter uke 9 skal du. Introduksjon til objektorientert programmering. Innhold. Klasser som abstraksjoner

Hvordan designe en ER-modell med MS-VISIO

Prosjektoppgave våren 2007

INF1050 Systemutvikling

Use Case-modellering. INF1050: Gjennomgang, uke 04

UNIVERSITETET I OSLO

Fra krav til objekter. INF1050: Gjennomgang, uke 05

Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5

Modellering av krav. INF1050: Systemutvikling 11. februar Universitetslektor Yngve Lindsjørn

Kravspesifikasjon med UML use case modellering. Erik Arisholm

Objektorientert design av kode. Refaktorering.

1. Designe ER-modeller med MS Visio

UNIVERSITETET I OSLO

UKE 11 UML modellering og use case. Gruppetime INF1055

t Institutt for informatikk Erik Arisholm 13. mai 2009 INF1050-oppsummering-1

INF1050 Systemutvikling

INF1050 Systemutvikling

Objektorientering og UML. INF1050: Gjennomgang, uke 06

Fra krav til modellering av objekter

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn

The Unified Modeling Language - UML

Objektorientert design av kode. Refaktorering.

Samling av trådene. Persistens. Dagens forelesning. Normal hendelsesflyt for Meld på kurs. Erik Arisholm. o Kort repetisjon. o Design av persistens

OPPGAVE 5b og 8b Java Kode

Produktrapport Gruppe 9

Gjennomgang av eksamen H99

UNIVERSITETET I OSLO

Introduksjon til objektorientert. programmering. Hva skjedde ~1967? Lokale (og globale) helter. Grunnkurs i objektorientert.

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

Datamodellering med UML. Modellenes to formål. The Unified Modeling Language - UML

Datamodellering med UML

INF1010, 15. januar time. Parametriserte klasser (generiske klasser) Stein Gjessing Inst. for Informatikk Universitetet i Oslo

Læringsmål for forelesningen

Universitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte

Introduksjon til objektorientert programmering

Forskningsmetoder / Evaluering av systemutvikling Pensum: kap. 12 i lærebok (artikkel) + kap

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

INF Forelesning oppsummering forts. Et meget enkelt banksystem. Oppsummering om klasser, objekter, pekere og.

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

(MVC - Model, View, Control)

1 Kodegenerering fra Tau Suiten

INF1000 (Uke 15) Eksamen V 04

INF1000 (Uke 15) Eksamen V 04

INF Obligatorisk prosjektarbeid

Fra problem til program

UNIVERSITETET I OSLO

Løsningsforslag ukeoppg. 6: 28. sep - 4. okt (INF Høst 2011)

Klasser, objekter, pekere og UML. INF gruppe 13

UNIVERSITETET I OSLO

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0>

UNIVERSITETET I OSLO

Datamodellering med UML. Modellenes to formål. The Unified Modeling Language - UML

INF1010, 21. januar Klasser med parametre = Parametriserte klasser = Generiske klasser

Transkript:

Dagens forelesning o Litt mer om design med UML sekvensdiagrammer Sentralisert og delegert kontrollstil Resultater fra et eksperiment o UML klassediagrammer Notasjon: UML klassediagram og objektdiagram Metode: Fra sekvensdiagram til klassediagram Litt om persistens: Lagring av objekter i OO databaser og relasjonsdatabaser Metode for ansvarsdrevet OO Inf050 metoden (Iterativ): Analyse av krav () Identifiser aktører og deres mål (2) Lag et høynivå bruksmønsterdiagram (3) Spesifiser hvert bruksmønster tekstlig med normal hendelsesflyt og variasjoner Objektdesign For hvert bruksmønster: (4) Identifiser objekter og fordel ansvar mellom dem (CRC) (5) Lag sekvensdiagram for normal hendelsesflyt og viktige variasjoner (6) Lag klassediagram som tilsvarer sekvensdiagrammene (7) Lag til slutt klassediagram på systemnivå INF050-klasser- INF050-klasser-2 Delegering av ansvar i en trelagsarkitektur Normal hendelsesflyt for Meld på kurs (sentralisert kontrollstil, kontrollobjektet har ansvar for det meste av handlingsforløpet) Forretningsobjekter ( entity objects ) Kontrollobjekter ( control objects ) ok:=meldpaa(studentid, emnekode, semester) MeldPaa objekter ( boundary objects ) Hvor mye ansvar bør kontrollobjektene ha, og i hvilken grad bør vi bevisstgjøre forretningsobjektene våre?? ok:=meldpaa(studentid, emnekode, semester) =finn(studentid) =finn(emnekode) forutsetter:=forutsetterr() =finn(semester) erledigplass:=ledigplass() paameldingok:=meldpaa(studenten) ermeldtpaa(kurset) INF050-klasser-3 INF050-klasser-4

Normal hendelsesflyt for Meld på kurs (Eksempel på Java kode for metoden meldpaa i en sentralisert kontrollstil) public class MeldPaa { public boolean meldpaa(string studentid, String emnekode, String semester) { // antar at objektet universitetet er tilgjengelig: studenten = universitetet.finn(studentid); emnet = universitetet.finn(emnekode); boolean forutsetter = emnet.forutsetterr(); kurset = emnet.finn(semester); boolean erledigplass = kurset.ledigplass(); boolean paameldingok = kurset.meldpaa(studenten); studenten.ermeldtpaa(kurset); Normal hendelsesflyt for Meld på kurs (delegert kontrollstil: og har overtatt mye av ansvaret fra kontrollobjektet) ok:=meldpaa(studentid, emnekode, semester) MeldPaa ok:=meldpaa(studentid, emnekode, semester) =finn(studentid) =finn(emnekode) ok:=meldpaa(studenten, semester) forutsetter:=forutsetterr() =finn(semester) ok:=meldpaa(studenten) erledig:=ledigplass() ermeldtpaa(kurset) INF050-klasser-5 INF050-klasser-6 Normal hendelsesflyt for Meld på kurs (Eksempel på Java kode for metoden meldpaa i en delegert kontrollstil) Resultater fra et kontrollert eksperiment (*) public class MeldPaa { public boolean meldpaa(string studentid, String emnekode, String semester) { // antar at objektet universitetet er tilgjengelig: studenten = universitetet.finn(studentid); // message #.2. emnet = universitetet.finn(emnekode); // message #.2.2 boolean ok = emnet.meldpaa(studenten, semester); // message #.2.3 Mean Effort (minutes) 0 00 90 80 70 Undergraduate Graduate Junior Intermediate Senior Design DC CC Undergraduate Graduate Junior Intermediate Senior DC = Delegated Control Style CC = Centralized Control Style Totalt 58 Java-utviklere deltok, og skulle gjøre endringer på enten et DC eller et CC design alternativ for det samme systemet. Vi målte tid ( Mean Effort ) og kvalitet ( % correct solutions ) Kun seniorkonsulentene ser ut til å gjøre oppgavene bedre med et DC design % Correct Solutions 00 50 0 Design DC CC * Erik Arisholm and Dag Sjøberg, Evaluating the Effect of a Delegated versus Centralized Control Style on the Maintainability of Object-Oriented Software, IEEE Transactions on Software Engineering, 2004 INF050-klasser-7 INF050-klasser-8

Delegert vs sentralisert kontrollstil Sentralisert kontrollstil: o Lett å få oversikt over hva som skjer i et bruksmønster o Feilsituasjoner/variasjoner som krever tilbakemeldinger fra en aktør (via kantobjektene) kan enkelt håndteres av kontrollobjektet o Introduserer flere avhengigheter mellom kontrollobjekt og forretningsobjekter. Potensielt mindre gjenbrukbar/vedlikeholdbar kode Delegert kontrollstil: o Mer elegant objektorientert design, men: o Overdreven bruk av delegering gjør det vanskelig å få oversikt (spesielt dersom sekvensdiagrammer ikke er tilgjengelige!) Klasse -attributt -attributt2 +metode() #metode2( ) UML Klasser og objekter + betyr public - betyr private # betyr protected En klasse beskriver hva objektene vet (attributter) og hvilke meldinger de forstår (metoder). Objektene er forekomster av klassebeskrivelsen. Objekt:Klasse -attributt aggregering = verdi -attributt2 = verdi sammensetning o Litt mer komplisert å håndtere feilsituasjoner/variasjoner som krever tilbakemeldinger fra en aktør (siden all kommunikasjon med kantobjektene må gå via kontrollobjektene) INF050-klasser-9 INF050-klasser-0 Assosiasjoner Eksempel på UML klassediagram Refleksiv assosiasjon Ansatt Sjef 0.. * Binær assosiasjon Ansatt Rapporterer til er tildelt Parkeringsplass 0.. 0.. (en til en) -antallplasser : int -antallpaameldt : int -semester : String +ledigplass() : boolean +meldpaa(in studenten : ) er meldt på -studentid : String -navn : String +ermeldtpaa(in kurset : ) ProduktLinje består av..* Produkt (en til mange) NB! * = har bestått * * (mange til mange) NB! Fremmednøkler osv vises ikke i et OO klassediagram INF050-klasser- INF050-klasser-2

Eksempel UML objektdiagram -... +...() Infostoff: Eks. på realisering i Java inf050v04 : antallplasser : int = 200 antallpaameldt : int = 43 semester : String = "Vår 2004" inf000h03 : antallplasser : int = 300 antallpaameldt : int = 90 semester : String = "Høst 2003" inf050v03 : antallplasser : int = 50 antallpaameldt : int = 50 semester : String = "Vår 2003" er meldt på er meldt på er meldt på ola : studentid : String = "2345" navn : String = "Ola" kari : studentid : String = "2227" navn : String = "Kari" INF050-klasser-3 * -antallplasser : int -antallpaameldt : int -semester : String +ledigplass() : boolean +meldpaa(in studenten : ) class { -emnet -kurs //assosiasjoner emnet; // referanse til emnet for kurset Vector paameldtestudenter; // liste over påmeldte studenter // attributter private int antallplasser; private int antallpaameldt; private String semester; public boolean ledigplass() { public boolean meldpaa( s) { antallpaameldt = antallpaameldt + ; paameldtestudenter.addelement(s); er meldt på class { //assosiasjoner Vector paameldtekurs; -studentid : String -navn : String +ermeldtpaa(in kurset : ) // attributter private String studentid, navn; public boolean ermeldtpaa( k) { paameldtekurs.addelement(k); // liste over påmeldte kurs INF050-klasser-4 Sammenhengen mellom sekvensdiagram og klassediagram Start med sekvensdiagrammet for normal hendelsesflyt: registrering bruksmønstermodell o Lag klasser for alle objektene. o Hver unike melding til et objekt resulterer i en metode for klassen til objektet. o Legg til de attributtene som metodene bruker o Lag nødvendige assosiasjoner for at klassene skal kunne utveksle meldinger mellom sine objekter For hvert sekvensdiagram for en variasjon: o Legg til nye klasser, attributter, metoder og assosiasjoner i klassediagrammet basert på meldingene i sekvensdiagrammet for variasjonen. INF050-klasser-5 INF050-klasser-6

Spesifikasjon av Meld på kurs Navn: Meld på kurs Aktør: Trigger: ønsker å melde seg på et kurs Pre-betingelse: har betalt semesteravgift og er logget inn på systemet Post-betingelse: er meldt på kurset eller er satt på venteliste Normal Hendelsesflyt:. en velger emne 2. Systemet sjekker at studenten kvalifiserer til å ta emnet 3. Systemet finner kurs for emnet 4. Systemet sjekker om det er ledig plass på kurset 5. Systemet registrerer studenten på kurset Meld på kurs (forts.) Variasjoner: a. t finnes ikke:. en velger et annet emne eller avslutter 2a. t forutsetter andre emner:. Systemet sjekker at studenten har bestått kurs for emner som forutsettes a. en har ikke bestått kurs for emner som forutsettes:. en velger et annet emne eller avslutter 3a. Det holdes ikke kurs i emnet dette semesteret:. en velger et annet emne eller avslutter 4a. et er fullt:. Systemet spør om studenten ønsker å bli satt på venteliste a. en ønsker å bli satt på venteliste:. Systemet setter studenten på venteliste Relatert informasjon: I denne versjonen holdes administrasjon av gruppeundervisning utenfor systemet INF050-klasser-7 INF050-klasser-8 Eks: CRC-kort for bruksmønsteret Meld på kurs Normal hendelsesflyt for Meld på kurs <<boundary>> Kommuniserer med aktøren og kontrollobjektet MeldPaa <<entity>> Oppslagsobjekt som vet hvilke emner og studenter som finnes i systemet <<entity>> Vet min emnekode Vet hvilke emner som forutsettes Vet hvordan man finner kurs i emnet ok:=meldpaa(studentid, emnekode, semester) MeldPaa MeldPaa <<control>> Kontrollerer hendelsesforløpet i bruksmønsteret Meld på kurs <<entity>> Vet min studentid Vet hvilke kurs jeg har tatt Vet hvilke kurs jeg er meldt opp til Vet hvilke kurs jeg står på venteliste på <<entity>> Vet semesteret som (et kurs i) et bestemt emne holdes Vet antall plasser Vet hvilke studenter som er påmeldt Vet hvilke studenter som står på venteliste ok:=meldpaa(studentid, emnekode, semester) =finn(studentid) =finn(emnekode) forutsetter:=forutsetterr() =finn(semester) erledigplass:=ledigplass() paameldingok:=meldpaa(studenten) ermeldtpaa(kurset) INF050-klasser-9 INF050-klasser-20

Klasser for normal hendelsesflyt Klasser og metoder for normal hendelsesflyt MeldPaa + boolean MeldPaa + boolean - emnekode: String - antallrforutsettes; int +finn: + forutsetterr: boolean + finn: + finn: - antallpaameldt: int - studentid: String ) Inkluder klassene du finner i sekvensdiagrammet 2) Inkluder metodene som ble brukt i sekvensdiagrammet 3) Inkluder attributter som metodene trenger INF050-klasser-2 INF050-klasser-22 Komplett klassediagram for normal hendelsesflyt Variasjon 4a..a. (kurset er fullt og studenten ønsker å sette seg på venteliste) + boolean MeldPaa + boolean -emnekode: String - antallrforutsettes; int + finn: + forutsetterr: boolean - antallpaameldt: int 4) Inkluder assosiasjoner som metodene trenger (bruker eller oppretter) 5) Inkluder avhengighetspiler mellom klassene som utveksler meldinger + finn: + finn: kursdeltaker - studentid: String INF050-klasser-23 ok:=meldpaa(studentid, emnekode, semester) [erledig=false] vilvente:=oenskerventeliste() MeldPaa ok:=meldpaa(studentid, emnekode, semester) =finn(studentid) =finn(emnekode) forutsetter:=forutsetterr() =finn(semester) erledig:=ledigplass() [vilvente==true] okvent:=settventeliste(studenten) [okvent==true] ok:=erpaaventeliste(kurset) INF050-klasser-24

Klassediagram for normal hendelsesflyt og variasjon 4a..a. Variasjon 2a. (t forutsetter andre emner som studenten har bestått) ok:=meldpaa(studentid, emnekode, semester) + boolean + oenskerventeliste: boolean MeldPaa + boolean -emnekode: String - antallrforutsettes; int +finn: + forutsetterr: boolean - antallpaameldt: int + settventeliste:boolean + finn: + finn: kursdeltaker - studentid: String venteliste + erpaaventeliste: void MeldPaa ok:=meldpaa(studentid, emnekode, semester) =finn(studentid) =finn(emnekode) forutsetter:=forutsetterr() [forutsetter=true] emnene:=forutsettes() harbestaatt:=harbestaattefor(emnene) [harbestaatt=true] =finn(semester) erledigplass:=ledigplass() paameldingok:=meldpaa(studenten) ermeldtpaa(kurset) Legger til nye metoder og assosiasjoner for variasjonen 4a..a. INF050-klasser-25 INF050-klasser-26 Klassediagram for normal hendelsesflyt, variasjon 2a. og 4a..a. Eksempel objektdiagram for forretningsobjektene Før Meld På kurs for Anne og Per: Anne (som allerede har meldt seg på og bestått inf000) ønsker å melde seg på Inf050 våren04 Per ønsker å melde seg på Inf000 våren04 (men kurset er allerede fullt) + boolean + oenskerventeliste: boolean emne som forutsettes - emnekode: String - antallrforutsettes; int +finn: + finn: MeldPaa + forutsetterr: boolean +finn: + forutsettes: [] + boolean - antallpaameldt: int kursdeltaker - studentid: String venteliste + erpaaventeliste: void + settventeliste:boolean bestått kurs + harbeståttefor:boolean Legger til nye metoder og assosiasjoner for variasjonen 2a. INF050-klasser-27 (For oversiktens skyld vises ikke attributtverdiene til objektene i dette diagrammet) INF050-klasser-28

Eksempel objektdiagram for forretningsobjektene Etter Meld På kurs for Anne og Per: Anne er nå meldt på Inf050 våren -04, og Per er satt på venteliste for Inf000 våren -04. Klassediagram på systemnivå Lag emne som forutsettes Lag -emnekode: String - antallrforutsettes; int +finn: + finn: + forutsetterr: boolean +finn: MeldPaa + forutsettes: [] + boolean + boolean + oenskerventeliste: boolean MeldAv - antallpaameldt: int kursdeltaker - studentid: String BetalSemesteravgift venteliste + erpaaventeliste: void + settventeliste:boolean bestått kurs + harbeståttefor:boolean RegistrerEksamensResultat (For oversiktens skyld vises ikke attributtverdiene til objektene i dette diagrammet) INF050-klasser-29 De andre bruksmønstrene vil introdusere nye kontrollobjekter og evt. nye forretningsobjekter, samt nye assosiasjoner, metoder og attributter på eksisterende forretningsobjekter. objektet vil få flere metoder (antar ett kantobjekt i systemet) INF050-klasser-30 Litt om lagring av objektene (persistens) Hva lagres? o Tilstanden (identitet, attributter og assosiasjoner) til forretningsobjektene Metoder for lagring o Filer: En fil pr objekt? Eksempel: Serializable i Java o Objektorientert database: Eksempel: ObjectStore http://www.progress.com/objectstore/index.ssp o Relasjonsdatabase: JDBC (Java Database Connectivity): Du må selv skrive kode som oversetter mellom objekter og relasjonsdatabase Hente/lagre attributter som tilhører hvert objekt vha SQL assosiasjoner realiseres vha fremmednøkler og evt oppslagstabeller Mer avanserte klassebiblioteker som skjuler oversettingen mellom objekter og relasjonsdatabase Eksempel: Hibernate http://www.hibernate.org/ INF050-klasser-3