OOP e2002 - uge 37 - første kursusgang OO-paradigmet jf. XP s. 10f 1. Flyreservations-system, jf. opgave 1 (dvs. Xiaoping 1.1) modellering og design vhja. grafisk designværktøj klassestruktur, brug af interfaces 2. Introduktion af klassediagrammer, grafik, appletter (jf. opgave 2) 3. Et Java-programs liv fra programmering til udførelse m.s.h.p. at forstå afvikling af appletter. 4. Uddybet introduktion til kurset Modularitet (sammenhængende, løst koblede moduler) klasser og pakker abstraktion, indkapsling Beskeder (message passing) send(besked, modtager) modtag(besked) men i form af metodekald 1 modsat delt lager Nedarvning "overskrivning" af metoder (overriding) interfaces (implementation af I. vs. nedarvning fra superklasse) polymorfi - alt sammen skal gøre programmet mere overskueligt 1. Flyreservationssystem "Konstruer en model, dvs. et klassediagram, for et fly-reservationssystem" (online ligesom Xiaopings boghandel) I forhold til analyse + design + implementation, svarer dette til at lave abstrakt design, eller første bud herpå. Det samlede design omfatter mange mere konkrete beslutninger om - arkitektur: modul/lag-struktur? flere computere? fordeling opgaver/computere? - programstruktur: f.eks. den måde flertrådning bruges til at håndtere flere samtidige brugere af systemet. Analyse - her leger vi orakler: vi kender alt til flybranchen, det pågældende flyselskab, kunderness og de ansattes behov etc. "design, then code" vs. "code, then fix" Antagelse om at programudvikling bør starte med at fastlægge et overordnet design, i stedet for straks at begynde at skrive programmet. Rationale: - "tænke sig om før man går i gang", mange fejl kan identificeres i designfase og som ellers vil være vanskelige at rette senere - definere grænseflade mellem dele som udvikles separat, jf. interfaces. Ikke færdiggøre designet før implementation, men iterativ proces: design-implementation-afprøvning-design-etc. - kan bruges til at indhente feedback fra brugere - hurtig feedback i det hele taget, også til design - sjovere - svært at forene med kontrakt baseret på fuldstændig specifikation Xiaoping: micro/macro-perspektiv (abstrakt design / implementation)
Design kan understøttes af diagrammering Metode til abstrakt design jf. Xiaoping s. 28. Klassediagrammer kan opfattes som et sprog - i design-diskussioner er det praktisk at tegne klasser på en måde alle forstår UML - Unified Modeling Language - bl.a. standard for klassediagrammer, tilstandsdiagrammer, aktivitetsdiagrammer, m.m. -- Tommelfingerregler til at lave overordnet klassediagram -- a) Lav kort beskrivelse, understreg navneord (klasser) og verber (metoder). b) Beskriv scenarier (use cases) for at finde yderligere klasser. c) Tilføj åbenlyst relevante metoder til klasserne. d) Beskriv klassernes indbyrdes relationer i klassediagram. Lav kort beskrivelse, understreg navneord (klasser) og verber (metoder). Bud på vigtige klasser Flyreservationssystemet bruges af kunder der laver en reservation. Under reservationsprocessen skal kunden se forslag på basis af kundens specifikation. Forskellen på online-boghandlen er bl.a. at system skal kunne beregne forslag til rejser, mens bogudvalget er givet. Ikke med i ovenstående: hvordan beregnes forslag til rejser? hvad indgår i en reservation - pris, ruter, afgangstider, selskab, business/economy, antal..
Association Interface Reservation Angiver relation mellem klasser. Kan navngives, f.eks. "[kunden] har reservation". Associering (association), generel forbindelse Aggregering (aggregation), "indeholde" Sammensætning (composition), eksklusiv, "eje" Vil typisk, men ikke nødvendigvis, blive implementeret med attributter der er passende reference-variable. Et interface spiller rollen som en "kontrakt" eller grænseflade for en eller flere klasser. Kontrakten/grænsefladen specificerer hvilke metoder, klasserne skal implementere. Interfacet skjuler detaljer, dvs. i dette tilfælde: vi kan let ændre hvad der kan reserveres, nemlig alene ved at skabe en ny klasse, der implementerer interfacet. Princip: Indkapsling af et modul Implementationen af et modul bør adskilles fra dets (kontraktlige) grænseflade og være skjult for modulets klienter (s. 13) Udbygget klassediagram - med struktur a la Xiaoping + interface Jo mindre klienten ved om implementationen, desto løsere bliver koblingen imellem modulets og dets klienter. Implementationen kan skiftes ud, uden at klienterne bliver berørt (så længe grænsefladen ikke ændres)
Dynamik i UML-diagrammer OO udviklingsproces Tilstandsdiagrammer: - et objekts tilstande og overgange imellem dem - f.eks. kan en reservation have tilstandene: ---- "bestilt", "afbestilt", "betalt",.. - fokuserer på tilstandene snarere end overgangene Aktivitetsdiagrammer - viser stort set det samme som sekvensdiagrammer ("hegn"-diagrammer) men på mere enkel måde - den tidsmæssige rækkefølge af metode-kald - dvs. fokus på metoder, procedure, algoritme - f.eks. en reservering foregår i følgende skridt: ---- "opstil rejsemål", "find mulige ruter", "find flere mulige ruter", "undersøg ledige pladser", "reserver",.. Modellering: Programudvikling kan foregå på en naturlig måde, hvor man bygger en model over virkeligheden, fordi klasser og objekter er velegnede til modellering. Xiaoping opfatter modellen som en del af softwaresystemet (s. 6). Xiaopings syn på usikkerhed softwareprojekters succes afhænger af test og fejlretning succes kan ikke garanteres ved at starte med videnskabelig analyse, da hvert system er unikt modsat andre ingeniør/tekniske områder f.eks. brobygning softwareudvikling er derfor umoden (s. 4) OOP e2002 - uge 37 - første kursusgang 2. Klassediagrammer, grafik og appletter 1. Flyreservations-system, jf. opgave 1 (dvs. Xiaoping 1.1) modellering og design vhja. grafisk designværktøj klassestruktur, brug af interfaces 2. Introduktion af klassediagrammer, grafik, appletter (jf. opgave 2) 3. Et Java-programs liv fra programmering til udførelse m.s.h.p. at forstå afvikling af appletter. 4. Uddybet introduktion til kurset A. Tegne klassediagram i ArgoUML. B. Gemme klassediagrammet i gif-format. C. Vise klassediagrammet i grafikprogram. D. Vise klassediagrammet som en del af en applet - i en appletviewer - i en webbrowser
A. Tegne i ArgoUML ArgoUMLs fire vinduer: browser + tegnevindue + egenskaber (+ huskeliste) C. Visning i grafikprogram D. Visning som del af applet Applet: et Java-program som er beregnet til at beregnet til at blive downloaded via webben og vist i en browser downloades og aktiveres via et tag i en html-fil kan vise dynamisk grafik og kommunikere med server Udførelse af applet: udføres af Java-enablet webbrowser (eller en appletviewer). Appletten har ikke egen main()-metode, idet Javaprogramudførelsen begynder i applet-konteksten (htmlfortolkeren). Nedarvning: En applets hovedklasse nedarver fra class Applet class Applet og dens superklasser definerer paint() og andre grafik-metoder, som overskrives i hovedklassen
HTML-filen // FILE: DiagramApplet.java Appletten <HTML> <h1> Denne html fil indlejrer en java applet </h1> <applet codebase="/home/nielsj/dev/java/classes" code="xiaoping.diagram.diagramapplet" width=500 height=200> </applet> </HTML> package xiaoping.diagram; import java.applet.applet; import java.awt.*; public class DiagramApplet extends Applet { public void paint(graphics g) { g.setcolor(color.blue); Dimension d = getsize(); g.fillrect(0,0,d.width,d.height); g.setfont(new Font("Sant-serif", Font.BOLD, 14)); g.setcolor(color.black); g.drawstring("denne java applet viser et ArgoUML klassediagram",25,25); g.drawimage(getimage(getdocumentbase(),"diagram.gif"), 50,50, this); } } OOP e2002 - uge 37 - første kursusgang 3. Et java-programs liv fra programmering til udførelse Eksempel: 1. Flyreservations-system, jf. opgave 1 (dvs. Xiaoping 1.1) modellering og design vhja. grafisk designværktøj klassestruktur, brug af interfaces 2. Introduktion af klassediagrammer, grafik, appletter (jf. opgave 2) 3. Et Java-programs liv fra programmering til udførelse m.s.h.p. at forstå afvikling af appletter. 4. Uddybet introduktion til kurset ArgoUML er programmeret i Java Kan derfor udføres på Windows, Linux, Mac.. fordi Java er uafhængigt af platform (processor + operativsystem) Vigtigt -- at I forstår hvilke filer og programmer der bruges i oversættelsen og udførelsen af et Java-program I skal principielt kunne klare jer uden et udviklingsmiljø, dvs. ved hjælp af en kommandolinje i stedet for et udviklingsmiljø med knapper..
ArgoUMLs liv.. et lidt forvansket tilstandsdiagram Start af Java-program ("applikation") (1) java -classpath <dir1:dir2:..:jar1:jar2:..> <klassenavn> f.eks. klassenavn = xiaoping.hellofromvenus, så søges efter filen HelloFromVenus.class i dir1/xiaoping, dir2/xiaoping,.. samt i jar1, jar2,.. - hver jarfil kan have flere java-klasser, evt. pakke-kvalificerede. HelloFromVenus skal definere main() (2) java <klassenavn> svarer til (1) hvor der bruges værdien af classpath-variablen (3) java -jar <jarfil> Jarfilen indeholder oplysning (i manifestfilen) om hvilken klasse der skal startes (via dens main) <HTML> Start af Java-applet <h1>denne html fil indlejrer en java applet</h1> <applet codebase="/home/nielsj/dev/java/classes" code="xiaoping.diagram.diagramapplet" width=500 height=200> </applet> </HTML> I appletten returnerer getcodebase() ovenst. sti og getdocumentbase() stien til html-filen. classpath klassenavn (pakkekval.) Kontekst for afvikling af Java-applet Kontekst: - java-enablet html-fortolker - kald af paint() parameteroverfører Graphics-objekt til appletten - det som vises er det appletten har "tegnet" i Graphics-objektet Appletten:.. public void paint(graphics g) { g.setcolor(color.blue); Dimension d = getsize(); g.fillrect(0,0,d.width,d.height); g.setfont(new Font("Sant-serif", Font.BOLD, 14)); g.setcolor(color.black); getsize() - arves fra class Applet - returnerer applettens størrelse g.drawstring("denne java applet viser et ArgoUML klassediagram",25,25); g.drawimage(getimage(getdocumentbase(),"diagram.gif"), 50,50, this); }..
Det grafiske koordinatsystem x (0,0) y width height Fejlfinding ved afvikling i applet i browser 1. Tjek at du kan afvikle java applikationer (java MinKlasse). 2. Tjek at du kan afvikle appletten vhja. appletvieweren (appletviewer MitDokument.html). Hvis 1 og 2 lykkes, er appletten og html-filen formentlig korrekt og problemet er i browseren. 3. Tjek at browseren har en Java-plugin og at versionsnummeret (f.eks. 1.1.5 eller 1.3.1) er mindst lige så højt som versionsnummeret på oversætteren. Hvis Java-versionen i browseren er for gammel, kan du opdatere den eller oversætte appletten med en særlig option: javac -target 1.1 MinKlasse.java target betyder at targetplatformen har version 1.1 OOP e2002 - uge 37 - første kursusgang 4. Uddybet introduktion til kurset 1. Flyreservations-system, jf. opgave 1 (dvs. Xiaoping 1.1) modellering og design vhja. grafisk designværktøj klassestruktur, brug af interfaces 2. Introduktion af klassediagrammer, grafik, appletter (jf. opgave 2) 3. Et Java-programs liv fra programmering til udførelse m.s.h.p. at forstå afvikling af appletter. 4. Uddybet introduktion til kurset Kursusdag altid onsdag Teori 9.30-12.00 teorirum 43.2 Øvelser 13.00-14.45 grupperum + usabilitylab 43.2 Opsamling 14.45-14.45 teorirum 43.2 Øvelsesopgaver på ugeseddel torsdag i ugen før. Jeg planlægger ud fra at I er begyndt på opgaverne inden kursusdagen, således at I kan gøre dem (næsten) færdig på øvelsen. Vi kan også prøve andre måder at bruge tiden på.
Kursusplan Del I: Introduktion uge 36-39 Del I: Introduktion Uge 36-39 Afsluttes med frivillig afleveringsopgave Del II: Design og grafik Uge 40-43 Afsluttes med endelig fastlæggelse af eksamensopgave Del III: Samtidighed, større systemer, eksamensopgave Uge 44-47 Afsluttes med aflevering og kursusevaluering Kursuspræsentation mandag d. 2.9. kl. 13.00-13.20 i teorirum 43.2. Uge 37: Introduktion (kapitel 1 + 2). Uge 38: De enkelte elementer af Java Uge 39: Uddybning af klasser: Nedarvning og implementation - Introduktion er højt prioriteret (.. også chancen til at indhente evt. manglende forudsætninger) - mange nye ting, f.eks. UML, uddybning af strenge, undtagelser, overskrivning af metoder, typer/subtyper, nedarvning mellem interfaces - samt første introduktion til tråde Del II: Design og grafik uge 40-43 Uge 40: Design. Ingen øvelser i uge 40 på grund af projektforum. Uge 41: Frameworks. Uge 42: Grafik (I). Uge 43: Grafik (II). Design obs - design er en vigtig vinkel på hele kurset design patterns, modularisering, koderetningslinjer Frameworks 'samlinger' (lister, mængder, iteration), biblioteker Grafik obs - mange grafiske eksempler på hele kurset awt, swing layoutmanagere, knapper, event-handling, hændelsesstyret programmering dobbelt-bufring case: konstruktion af et tegnebræt (elektronisk tavle) Del III: Samtidighed, større systemer, eksamensopgave uge 44-47 Uge 44: Samtidighed (I). Uge 45: Samtidighed (II). Uge 46: Afrunding af hele kursets emnekreds. Uge 47: Evaluering (= sidste kursusdag onsdag d. 18.10). Aflevering af eksamensopgave mandag d. 18. 10. Samtidighed tråde, (in)konsistens, synkronisering, deadlock
Valg --> fravalg Teori: - algoritmer/datastrukturer (f.eks. hashing, balancerede træer) - programmeringssprog, f.eks. semantik, typer Distribution/Internet - Sockets - fjernprocedurekald Andre oo-sprog end Java (C++, Smalltalk, Simula,..)