Kap3: Klassemodellering

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

UML 1. Use case drevet analyse og design Kirsten Ribu

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

AlgDat 12. Forelesning 2. Gunnar Misund

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

Fra krav til objekter. INF1050: Gjennomgang, uke 05

Hvorfor objektorientert programmering? Objektorientert programmering i Python: Introduksjon. Læringsmål uke 7. Undervisning og pensum IN1000

Hvorfor objektorientert programmering?

INF1010 våren 2008 Uke 4, 22. januar Arv og subklasser

Fra krav til modellering av objekter

VEDLEGG 7 INFORMASJONSMODELL

Oppgave 1: Multiple choice (20 %)

Etter uke 6 skal du. Introduksjon til objektorientert programmering. Hva skjedde ~1967? INF1001. Grunnkurs i objektorientert programmering

Spesifikasjon av Lag emne

Løsningsforslag til Case. (Analysen)

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

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

Modellering av data. Magnus Karge, Kartverket

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Tom Røise IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar Klassediagrammet. Klasse

Repitisjonskurs. Arv, Subklasser og Grensesnitt

19. januar 2012 Noen punkter fra i går

Use Case-modellering. INF1050: Gjennomgang, uke 04

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

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

Objektorientert programmering i Python. Resten av semesteret. Innhold uke 9 Mer komplekse strukturer. Referanser og objekter, inkl Mentimeter spørsmål

21. Objektorientert Analyse (OOA) Kap. 21 Objektorientert Analyse (OOA)

Introduksjon til objektorientert programmering

UML-Unified Modeling Language

Objekt med Java. Harald Yndestad Høgskolen i Ålesund

Fra krav til objektdesign

Tittel Objektorientert systemutvikling 2

Eksekveringsrekkefølgen (del 1) Oppgave 1. Eksekveringsrekkefølgen (del 2) Kommentar til oppgave 1. } // class Bolighus

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

INF1000: Forelesning 7. Konstruktører Static

class Book { String title; } class Dictionary extends Book { int wordcount; } class CartoonAlbum extends Book { int stripcount; }

Modeller for design av Web-Applikasjoner

INF1000: Forelesning 7

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

Læringsmål for forelesningen

INF1010 våren Arv og subklasser del 1

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP

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

2012 2a. C rc; void main() { rc = new C (); rc.m2(); } } INF 3110/ INF /28/13 1

Tittel Objektorientert systemutvikling 3

Arv. Book book1 = new Book(); book1. title = "Sofies verden" class Book { String title; } class Dictiona ry extends Book {

1. Modellering av objektorienterte systemer

Læringsmål uke 7. Objektorientert programmering i Python: Introduksjon. Innhold uke 7. Lite tilbakeblikk: Programflyt og skop

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

Datamodellering med UML

Obligatorisk oppgave 5: Labyrint

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

Objektorientering og UML. INF1050: Gjennomgang, uke 06

Post-it spørsmål fra timen (Arv og subklasser)

Innhold uke 10. Objektorientert programmering i Python. Oblig 7 og 8. IN1000 Seminar! IN1000 Høst 2018 uke 10 Siri Moe Jensen

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

The Unified Modeling Language - UML

Pensum: fra boken (H-03)+ forelesninger

Konstruktører. Bruk av konstruktører når vi opererer med "enkle" klasser er ganske ukomplisert. Når vi skriver. skjer følgende:

Data design p.1/17. Data design. Lage ER modell av kravspesifikasjoner.

Introduksjon til fagfeltet

Pensum: fra boken (H-03)+ forelesninger

UKE 11 UML modellering og use case. Gruppetime INF1055

Use case drevet design med UML

INF1010 våren Arv og subklasser del 1

Innhold. Forord Det første programmet Variabler, tilordninger og uttrykk Innlesing og utskrift...49

OptimalJ-kurs UIO Oppsummering av kurset. De ulike modellene egenskaper og formål

INF1010 UML. Marit Nybakken 26. januar 2004

INF Obligatorisk innlevering 7

Kapittel 7: Mer om arv

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

Dagens tema Syntaks (kapittel Komp. 47, kap. 1 og 2)

Litt om kompilering og interpretering. Dagens tema Syntaks (kapittel Komp. 47, kap. 1 og 2) Syntaks og semantikk

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

UNIVERSITETET I OSLO

Forklaring til programmet AbstraktKontoTest.java med tilhørende filer Konto.java, KredittKonto.java, SpareKonto.java

UNIVERSITETET I OSLO

God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu

Velkommen! I dag. Viktige beskjeder. Studieadministrasjonen. IN Høst Siri Moe Jensen Geir Kjetil Sandve Henrik Hillestad

Oppsummering. Thomas Lohne Aanes Thomas Amble

AlgDat 10. Forelesning 2. Gunnar Misund

IN1010 V18, Obligatorisk oppgave 5

Kapittel 1: Datamaskiner og programmeringsspråk

1. Datamodellering Kommentarer til læreboka

Objektorientert programmering i Python

Distribuerte objekter og objekt-basert mellomvare

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

Aksiom 3.1 (Likhet av mengder). La A og B være mengder. Da er A og B like hvis og bare hvis de har akkurat de samme elementene.

Forside Eksamen INF1055 V17

Beskjed fra Skagestein

Generiske mekanismer i statisk typede programmeringsspråk

Distribuerte objekter og objekt-basert mellomvare

Innhold uke 9. Objektorientert programmering i Python. Om ukens pensum. Referanser og objekter Tema: Mer komplekse strukturer

Factory Patterns Interface Deklarerer at klassen skal bruke et interface (implements i Java) Definerer implementasjoner for alle metodene i interfacet

Lykke til! Eksamen i fag TDT4140 Systemutvikling NTNU Norges teknisk-naturvitenskapelige universitet

AMS-case. Eksemplifisering av modellbasert. tilnærming til design av brukergrensesnitt

1. Modellering av objektorienterte systemer

INF5120 Oblig gjennomgang

Distribuerte objekter og objekt-basert mellomvare

ITGK - H2010, Matlab. Dagens tema : Teori - Databaser

Transkript:

Kap3: Klassemodellering I dag: Litt repetisjon fra sist (innledende om klassemodellen) Deretter egentlig litt mer repetisjon, men nå fra intro- Felt-/Instansvariabler og kurset i Java: Klasser og Objekt, attributter. Metoder og Ope erasjoner.. UML notasjon for klasser, assosiasjoner osv. Generalisering/spesialisering og Arv OBS: Ikke pensum: 3.5.1 3.5.3 3

Fra sist Klassemodellen Beskriver den statiske struktur av objekter, deres relasjoner, attributter og operasjoner: Klasser representerer sentrale begreper fra domenet. Generalisering brukes for å dele struktur og oppførsel mellom klasser. Utgjør kontekst og grunnlag for diagram innen de andre modellene Klassemodellen er den viktigste av de tre modellene..og den gir en intuitiv grafisk representasjon som også er verdifull for kommunikasjon mot brukere/oppdragsgivere/kunder

Klassediagram Gir en grafisk notasjon for modellering e av klasser og sammenhengen mellom disse Nyttige for både abstrakt modellering og for å designe faktisk program Objektdiagram Viser eksempel på klasse + individuelle id objekt og deres eventuelle relasjoner

Objekt og Klasse Objekt: Er et konsept, en abstraksjon eller en ting med identitet som har en betydning for en applikasjon Alle objekt har identiteter og kan skilles fra hverandre. Eks: to helt identiske e epler e vil fortsatt være to individuelle due e epler. e Og et objekt er en instans av en Klasse Klasse: Beskriver en gruppe av objekt med de samme egenskaper (attributter/instansvariabler), den samme adferd (operasjoner), de samme relasjoner til objekt av både egen og andre klasser, og den samme semantikk. Vi abstraherer problem ved å gruppere objekt i klasser.

Klassediagram & Obje ektdiagram Attributter og verdier e Merk at Verdi står til Attributt som Objekt står til Klasse Merk dere også at UMLs notasjonsform for Klasse har en hvis likhet med hvordan vi definerer en klasse i Java (som er et objektorientert språk..)

Operasjoner og Metoder Operasjoner De funksjoner (prosedyrer) som en legger til en klasse. Det er disse som gir adferd til objekt av klassen. Alle objekt av en klasse deler de samme operasjonene. Kan også ha at den samme operasjonen deles av flere klasser. Operasjonen er da polymorfisk. Metoder Den faktisk implementeringenn av en operasjon for eksempel i Java. a

Notasjon for klasse TOD061, IKT-2, Blaha & Rumbaugh, kap. 3

Linker og Assosiasjon ner Link Representerer den fysiske (for eksempel Bok og Kapittel) eller konseptuelle (for eksempel Company og Person) forbindelsen mellom objekt. Assosiasjon Representerer en beskrivelse av en gruppe linker med felles struktur og felles semantikk. Husk at en assosiasjon kan leses begge veier.

Multiplisitet Spesifiserer det antall av instanser fra en klasse som kan relateres til en enkelt instans i en assosiert klasse. Mulige notasjoner: 1 m * 1..1 0..m 1..m 1..* 2..5 osv

Assosiasjoner og nota asjoner, flere eks.

Assosiasjoners sluttnavn Hjelper med å sette roller til klasser i en assosiasjon Er en absolutt nødvendighet for assosiasjoner mellom to objekt av samme klasse

Assosiasjoners sluttnavn, et eks. til..

Orden og sekvens i mange assosiasjoner Orden Ode Angir en form for prioritering, for eksempel at bare øverste vindu er synlig på en skjerm (se under) Sekvens Angir en ordnet samling hvor også duplikater er lovlig (se under)

Assosiasjonsklasse En assosiasjon asjo som også er en klasse Har attributter som hører til klassene linken og ikke til noen av

Assosiasjonsklasse, litt mer

Kvalifisert assosiasjon En assosiasjon asjo hvor et attri butt kalt qualifier kvalifiserer e et objekt for medlemskap i assosiasjonen

Generalisering/spesia alisering og arv Generalisering i Når en ser at to eller flere klasser har flere ting til felles hva gjelder både attributter, operasjoner på disse og assosiasjoner mot andre klasser. Samler da det som er felles i en felles superklasse. De enkelte klassenes særegenheter hva gjelder attributter, operasjoner og assosiasjone er legges da til de opprinnelige klassene som kalles subklasser. Subklassene arver så alt av attributter, tter operasjoner og assosiasjoner fra superklassen.

Generalisering/spesiali isering og arv, forts. Spesialisering se Motsatt vei av generalisering. En har en opprinnelig klasse, men føler behov for å avlede denne til en eller e flere e spesialiseringer. se Beholder det som er felles i superklassen Lar så subklasser av superk klassen inneholde attributter, operasjoner og assosiasjoner som er nødvendige for de ønskede spesialiseringer. Tenk: Har oppfunnet bilen, men finner så ut at det kan være behov for både personbiler, lastebiler og busser. Mye er felles for de tre nye sublassene og legges i en superklasse BIL, mens de tre subklassene så får innhold for spesialiseringer.

Generaliserings/spes. hierarkier Enkle generaliseringer/spe sialiseringer organiserer klasser gjennom et hierarki: Hver subklasse har en og ba are en superklasse En superklasse vil naturlig nok ha (to eller) flere subklasser direkte under seg En subklasse kan så være superklasse for nye subklasser (flere (eenivå åav geease generaliseringg /spesialisering) se En subklasse (etterfølger) arver fra sine foreldre/superklasser (forfedre) på alle nivå over Generaliserings/spesialiserings-sett navn: Kan sette beskrivende attributtnavn på generalisering/spesialisering Notasjon nærmest som et tre Eksempel: se fig. 3.24 og 3.25

Generaliserings/spes. hierarkier, forts. Hvorfor o Generalisering/Sp e pesialisering: se Støtter polymorfisme: Inn med ny subklasse og mye av dennes kode er allerede tilgjengeligg gjennom arv. Bedre struktur og oversiktlighet i kode: oppretter en taxonomi samt organisering av objekter på bakgrunn av likheter og forskjeller Gjenbruk av kode: Hvorfor skrive på nytt..? Dybde på hierarkier? For dype gir gjerne mindre lesbarhet men, av og til behov for en hvis dybde Tommelfingerregel: unngå dypere enn 5-6 nivåer

Arv og overskriving (/ utviding) Overskriving (override) En subklasse kan overskrivee en egenskap fra superklasse ved å definere denne på nytt (bruke samme navn) i subklassen. Subklassens definisjon gjennom overskriving vil alltid gjelde over den i utgangspunktet arvedee (likt navn) fra superklassen. Utvidelse En subklasse kan også bygg ge videre på en superklasses egenskap gjennom en utvidelse av denne. Lært på første javakurset? OBS: Ikke foreta endringer av grensesnitt: eks. metodekall

De to siste UML eksempl lene fra kap. 4 Fig 3.26: Klassemodell for et vindussystem Forskjellige typer vindu for et vindussystem på en datamaskin, ink. komponenter for de enkelte vindu Basert på arv Merk klasse ScrollingCanvas som er basert på dobbel arv (både fra klasse ScrollingWindow og klasse Canvas) Forsøk å forstå (lese) diagrammet Fig 3.27: Klassemodell for kredit ttkort og kontoer Basert på arv En institusjon kan utstede mange kredittkort, hvert enkelt identifisert ved et kontonummer (kvalifiserer) Kan ha flere (samme adresse/ i familie) med samme kredittkort Har så (måneds?)-utskrifter for hvert kort inneholdende forskjellige transaksjoner

Før vi forlater kap. 3 Husk å jobbe med stoffet: Oppgave 3.1 Oppgave 3.2 Oppgave 3.13a Klassediagram for følgende klasser med assosiasjoner: skole, lekeplass, rektor, skoleråd, klasserom, bok, student, lærer, kafeteria, hvilerom, røykerom, PC, pult, stol, dør, disse Oppgave 3.15 Det anbefales at dere gjør flest mulig av oppgavene i boken (hver for dere, diskuter deretter løsninger med andre).