NB! Endring i undervisningsplanen

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

Beskjed fra Skagestein

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

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

Fra krav til objektdesign

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

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

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

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

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Spesifikasjon av Lag emne

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

Kursregistrering bruksmønstermodell

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

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

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

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

UML-Unified Modeling Language

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

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

Utvikling fra skallet og inn

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

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

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

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

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

INF 1050 BRUK AV MODELLERINGSVERKTØYET RATIONAL ROSE

UNIVERSITETET I OSLO

INF1000: Forelesning 7

UML 1. Use case drevet analyse og design Kirsten Ribu

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

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

INF1000: Forelesning 7. Konstruktører Static

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

INF1010 UML. Marit Nybakken 26. januar 2004

Use case drevet design med UML

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

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

Universitetet i Bergen Det matematisk-naturvitenskapelige fakultet Institutt for informatikk

Fra krav til objekter. INF1050: Gjennomgang, uke 05

Eksamen INF1050: Gjennomgang, uke 15

Produktrapport Gruppe 9

Objektorientering og UML. INF1050: Gjennomgang, uke 06

Kravspesifikasjon med UML use case modellering. Erik Arisholm

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

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

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

Fra problem til program

Use Case-modellering. INF1050: Gjennomgang, uke 04

UNIVERSITETET I OSLO

UKE 11 UML modellering og use case. Gruppetime INF1055

UNIVERSITETET I OSLO

Objektorientert design av kode. Refaktorering.

Prosjektoppgave våren 2007

INF1050 Systemutvikling

The Unified Modeling Language - UML

INF1000 (Uke 15) Eksamen V 04

INF1000 (Uke 15) Eksamen V 04

Objektorientert design av kode. Refaktorering.

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

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

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

OPPGAVE 5b og 8b Java Kode

Datamodellering med UML

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

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

UNIVERSITETET I OSLO

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

INF1300 Introduksjon til databaser

(MVC - Model, View, Control)

Obligatorisk oppgave 5: Modellering av krav

INF1050 Systemutvikling

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

Fra krav til modellering av objekter

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

Del - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle

1 Kodegenerering fra Tau Suiten

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

1. Designe ER-modeller med MS Visio

Hvordan designe en ER-modell med MS-VISIO

UNIVERSITETET I OSLO

INF1300 Introduksjon til databaser

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

Velkommen til. INF våren 2017

Introduksjon til objektorientert programmering

Læringsmål for forelesningen

Innhold uke 7. Objektorientert programmering i Python: Introduksjon. Lite tilbakeblikk: Programflyt og skop. Lite tilbakeblikk: Funksjoner er uttrykk

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

Mer om objektorientering og UML

OBJEKTER SOM EN PROGRAMMERINGS-TEKNIKK

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

Eksamen 2013 Løsningsforslag

INF Obligatorisk prosjektarbeid

UNIVERSITETET I OSLO

GJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML

Transkript:

NB! Endring i undervisningsplanen Forelesningen 24. mars må dessverre avlyses på grunn av Fagkritisk dag Se beskjed som er lagt ut på kursets nettsider og den oppdaterte undervisningsplanen INF1050-klasser-1 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 INF1050-klasser-2

Metode for ansvarsdrevet OO Inf1050 metoden (Iterativ): Analyse av krav (1) 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å INF1050-klasser-3 Hva er et objekt Et objekt er en representasjon av en virkelig ting. Et objekt har en entydig identitet, en indre tilstand, og evnen til å reagere på meldinger utenfra. Et objekt har altså liv. Virkelighetens objekter er dyr, planter, maskiner og mekanismer. I modeller er alt mulig - også å bevisstgjøre i utgangspunktet døde ting som innsjøer, veier, kommuner, firmaer, lån... INF1050-klasser-4

Et låneobjekt kan f.eks. Det bevisste lån o kjenne til sin egen saldo, rentefot, forfallsdatoer osv. o forrente seg selv o purre på avdrag o akseptere innbetalinger lån Hei, du har glemt å betale avdraget! INF1050-klasser-5 Delegering av ansvar i en trelagsarkitektur Forretningsobjekter ( entity objects ) Kontrollobjekter ( control objects ) Kantobjekter ( boundary objects ) Hvor mye ansvar bør kontrollobjektene ha, og i hvilken grad bør vi bevisstgjøre forretningsobjektene våre?? INF1050-klasser-6

Normal hendelsesflyt for Meld på kurs (sentralisert kontrollstil, kontrollobjektet har ansvar for det meste av handlingsforløpet) Normal hendelsesflyt: 1. Studenten velger emne (1 1.2.2) 2. Systemet sjekker at studenten kvalifiserer til å ta emnet (1.2.3) 3. Systemet finner kurset for emnet (1.2.4) 4. Systemet sjekker om det er ledig plass på kurset (1.2.5) 5. Systemet registrerer studenten på kurset (1.2.6 og 1.2.7) CRC kortene forteller deg hvilket objekt som skal motta en bestemt melding INF1050-klasser-7 Normal hendelsesflyt for Meld på kurs (Eksempel på Java kode for metoden meldpaakurs i en sentralisert kontrollstil) public class MeldPaaKurs { } public boolean meldpaakurs(string studentid, String emnekode, String semester) { } // antar at objektet universitetet er tilgjengelig: Student studenten = universitetet.finnstudent(studentid); // message #1.2.1 Emne emnet = universitetet.finnemne(emnekode); // message #1.2.2 boolean forutsetteremner = emnet.forutsetteremner(); // message #1.2.3 Kurs kurset = emnet.finnkurs(semester); // message #1.2.4 boolean erledigplass = kurset.ledigplass(); // message #1.2.5 boolean paameldingok = kurset.meldpaa(studenten); // message #1.2.6 studenten.ermeldtpaa(kurset); // message #1.2.7 INF1050-klasser-8

Normal hendelsesflyt for Meld på kurs (delegert kontrollstil: Emne og Kurs har overtatt mye av ansvaret fra kontrollobjektet) INF1050-klasser-9 Normal hendelsesflyt for Meld på kurs (Eksempel på Java kode for metoden meldpaakurs i en delegert kontrollstil) public class MeldPaaKurs { } public boolean meldpaakurs(string studentid, String emnekode, String semester) { } // antar at objektet universitetet er tilgjengelig: Student studenten = universitetet.finnstudent(studentid); // message #1.2.1 Emne emnet = universitetet.finnemne(emnekode); // message #1.2.2 boolean ok = emnet.meldpaa(studenten, semester); // message #1.2.3 INF1050-klasser-10

Resultater fra et kontrollert eksperiment () Design Design 110 DC CC 100 DC CC Mean Effort (minutes) 100 90 80 70 % Correct Solutions 50 0 Undergraduate Graduate Junior Intermediate Senior Undergraduate Graduate Junior Intermediate Senior DC = Delegated Control Style CC = Centralized Control Style Totalt 158 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 Erik Arisholm and Dag Sjøberg, Evaluating the Effect of a Delegated versus Centralized Control Style on the Maintainability of Object-Oriented Software, Submitted to IEEE Transactions on Software Engineering, 2003 INF1050-klasser-11 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!) o Litt mer komplisert å håndtere feilsituasjoner/variasjoner som krever tilbakemeldinger fra en aktør (siden all kommunikasjon med kantobjektene må gå via kontrollobjektene) INF1050-klasser-12

UML Klasser og objekter Klasse -attributt1 -attributt2 +metode1() #metode2( ) + betyr public - betyr private # betyr protected Objekt:Klasse -attributt1 aggregering = verdi -attributt2 = verdi sammensetning En klasse beskriver hva objektene vet (attributter) og hvilke meldinger de forstår (metoder). Objektene er forekomster av klassebeskrivelsen. INF1050-klasser-13 Assosiasjoner Refleksiv assosiasjon Ansatt Sjef 0..1 Rapporterer til Binær assosiasjon Ansatt er tildelt 0..1 0..1 Parkeringsplass (en til en) ProduktLinje består av 1 1.. Produkt (en til mange) NB! = 0.. Student har bestått Kurs (mange til mange) INF1050-klasser-14

Eksempel på UML klassediagram Kurs -antallplasser : int -antallpaameldt : int -semester : String +ledigplass() : boolean +meldpaa(in studenten : Student) -paameldtekurs 0.. er meldt på -paameldtestudenter 0.. Student -studentid : String -navn : String +ermeldtpaa(in kurset : Kurs) NB! Fremmednøkler osv vises ikke i et OO klassediagram INF1050-klasser-15 Eksempel UML objektdiagram inf1050v04 : Kurs antallplasser : int = 200 antallpaameldt : int = 143 semester : String = "Vår 2004" inf1000h03 : Kurs antallplasser : int = 300 antallpaameldt : int = 190 semester : String = "Høst 2003" -paameldtekurs -paameldtekurs -paameldtekurs er meldt på -paameldtestudenter -paameldtestudenter er meldt på ola : Student studentid : String = "12345" navn : String = "Ola" inf1050v03 : Kurs antallplasser : int = 150 antallpaameldt : int = 150 semester : String = "Vår 2003" er meldt på -paameldtestudenter kari : Student studentid : String = "22127" navn : String = "Kari" INF1050-klasser-16

-... +...() Emne Infostoff: Eks. på realisering i Java 1 -emnet -kurs Kurs -antallplasser : int -antallpaameldt : int -semester : String +ledigplass() : boolean +meldpaa(in studenten : Student) -paameldtekurs 0.. er meldt på -paameldtestudenter 0.. Student -studentid : String -navn : String +ermeldtpaa(in kurset : Kurs) class Kurs { class Student { } //assosiasjoner Emne 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(student s) { antallpaameldt = antallpaameldt + 1; paameldtestudenter.addelement(s); } } //assosiasjoner Vector paameldtekurs; // attributter private String studentid, navn; public boolean ermeldtpaa(kurs k) { paameldtekurs.addelement(k); } // liste over påmeldte kurs INF1050-klasser-17 Sammenhengen mellom sekvensdiagram og klassediagram Start med sekvensdiagrammet for normal hendelsesflyt: 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. INF1050-klasser-18

Kursregistrering bruksmønstermodell INF1050-klasser-19 Spesifikasjon av Meld på kurs Navn: Meld på kurs Aktør: Student Trigger: Student ønsker å melde seg på et kurs Pre-betingelse: Student har betalt semesteravgift og er logget inn på systemet Post-betingelse: Student er meldt på kurset eller er satt på venteliste Normal Hendelsesflyt: 1. Studenten 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 INF1050-klasser-20

Meld på kurs (forts.) Variasjoner: 1a. Emnet finnes ikke: 1. Studenten velger et annet emne eller avslutter 2a. Emnet forutsetter andre emner: 1. Systemet sjekker at studenten har bestått kurs for emner som forutsettes 1a. Studenten har ikke bestått kurs for emner som forutsettes: 1. Studenten velger et annet emne eller avslutter 3a. Det holdes ikke kurs i emnet dette semesteret: 1. Studenten velger et annet emne eller avslutter 4a. Kurset er fullt: 1. Systemet spør om studenten ønsker å bli satt på venteliste 1a. Studenten ønsker å bli satt på venteliste: 1. Systemet setter studenten på venteliste Relatert informasjon: I denne versjonen holdes administrasjon av gruppeundervisning utenfor systemet INF1050-klasser-21 Eks: CRC-kort for bruksmønsteret Meld på kurs Kant <<boundary>> Kommuniserer med aktøren og kontrollobjektet MeldPaaKurs Universitet <<entity>> Oppslagsobjekt som vet hvilke emner og studenter som finnes i systemet Emne Student Emne <<entity>> Vet min emnekode Vet hvilke emner som forutsettes Vet hvordan man finner kurs i emnet Kurs Kurs Emne MeldPaaKurs <<control>> Kontrollerer hendelsesforløpet i bruksmønsteret Meld på kurs Universitet Emne Kurs Student Kant Student <<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å Kurs <<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 Student INF1050-klasser-22

Normal hendelsesflyt for Meld på kurs (ytterligere detaljering: sekvensdiagram med betingelser) Normal hendelsesflyt: 1. Studenten velger emne (1 1.2.2) 2. Systemet sjekker at studenten kvalifiserer til å ta emnet (1.2.3) 3. Systemet finner kurset for emnet (1.2.4) 4. Systemet sjekker om det er ledig plass på kurset (1.2.5) 5. Systemet registrerer studenten på kurset (1.2.6 og 1.2.7) CRC kortene forteller deg hvilket objekt som skal motta en bestemt melding INF1050-klasser-23 Klassediagram for normal hendelsesflyt INF1050-klasser-24

Variasjon 4a.1.1a.1 (kurset er fullt og studenten ønsker å sette seg på venteliste) 4a. Kurset er fullt (1.2.5): 1. Systemet spør om studenten ønsker å bli satt på venteliste (1.2.6) 1a. Studenten ønsker å bli satt på venteliste (1.2.6): 1. Systemet setter studenten på venteliste (1.2.7 og 1.2.8) INF1050-klasser-25 Klassediagram for normal hendelsesflyt og variasjon 4a.1.1a.1 = nye metoder og assosiasjoner for variasjonen 4a.1.1a.1 INF1050-klasser-26

Variasjon 2a.1 (Emnet forutsetter andre emner. Studenten har bestått kurs for emnene som forutsettes) 2a. Emnet forutsetter andre emner (1.2.3): 1. Systemet sjekker at studenten har bestått kurs for emner som forutsettes (1.2.4-1.2.5) INF1050-klasser-27 Klassediagram for normal hendelsesflyt, variasjon 2a.1 og 4a.1.1a.1 = nye metoder og assosiasjoner for variasjonen 2a.1 INF1050-klasser-28

Eksempel objektdiagram for forretningsobjektene Før Meld På kurs for Anne og Per: Anne (som allerede har meldt seg på og bestått inf1000) ønsker å melde seg på Inf1050 våren04 Per ønsker å melde seg på Inf1000 våren04 (men kurset er allerede fullt) (For oversiktens skyld vises ikke attributtverdiene til objektene i dette diagrammet) INF1050-klasser-29 Eksempel objektdiagram for forretningsobjektene Etter Meld På kurs for Anne og Per: Anne er nå meldt på Inf1050 våren -04, og Per er satt på venteliste for Inf1000 våren -04. (For oversiktens skyld vises ikke attributtverdiene til objektene i dette diagrammet) INF1050-klasser-30

Foreløpig klassediagram på systemnivå INF1050-klasser-31 Litt om lagring av objektene (persistens) Hvilke objekter skal lagres? o Forretningsobjektene (f.eks. objektene på forrige objektdiagram) Hva lagres? o Tilstanden (identitet, attributter og assosiasjoner) til objektene Media for lagring o Filer: En fil pr objekt? Blir fort ganske uhåndterlig o Objektorientert database: Eksempel: ObjectStore, Poet Tilstanden til forretningsobjektene lagres i en database uten at programmet trenger å tenke så mye mer på det o Relasjonsdatabase: Ikke trivielt, men ofte kan det likevel gjøres ganske elegant ved at man bruker standard klassebiblioteker som skjuler implementasjonsdetaljer Hente/lagre attributter som tilhører hvert objekt vha SQL assosiasjoner realiseres vha fremmednøkler og evt oppslagstabeller INF1050-klasser-32