Fra problem til program. Stein Gjessing Inst. for informatikk

Transkript

1 INF våren 2009 Fra problem til program Stein Gjessing Inst. for informatikk 1

2 Oversikt: INF Systemutvikling Fasene i utvikling av datasystemer Utviklingsmetoder Fossefall og Unified Process (UP) Smidig systemutvikling Hvordan finne et forslag til klassene i systemet UML Substantivmetoden ti t Design av programmet Top-down og bottom-up programmering Innkapsling og grensesnitt Programmønstre Testing (bare litt) 2

3 Utvikling av store datasystemer Aktiviteter: Hvilke ulike arbeidsoppgaver er det i utviklingsarbeidet Eller er det bare å starte å programmere? Utviklingsmetodikk: De ulike aktivitetene i arbeidet, er det noen anbefalt måte/rekkefølge å gjøre disse på? Gjøres de hver for seg i rekkefølge - en etter en? Gjøres de i parallell - alle sammen eller bare noen? Gjentas noen av aktivitetene, i eller blir man greit ferdig med ddem en etter en? Økonomi: Er det enkelt/mulig å få vite hvor mye et datasystem vil koste å lage? Vanligvis ikke! - Men vi lærer (kanskje) 3

4 Eksempel: Lage en nytt hus Arbeidet deles i aktiviteter: Planlegge rom-behov (typer og antall/størrelse) Tegne hus (arkitekt) Bygge hus: Velge entreprenør/utbygger/håndverkere Velge materialer/innredning Søke tillatelser,.., Kostnadsestimering og finansiering Mange av aktivitetene går i flere runder (tegne hus,..) Man kan f.eks gå tilbake til en tidligere aktivitet (rombehov) som resultat av en annen aktivitet (kostnadene), men noen aktiviteter må klart gå foran andre. Dette er et enkelt problem sammenlignet med å lage et datasystem fordi svært mange lignende hus er laget før. 4

5 Oversikt over aktivitetene i programutvikling: Aktivitetene (stegene) i utviklingen av et datasystem: 1. Forprosjekt 2. Kravspesifikasjon 3. Analyse 4. Design 5. Programmering 6. Testing 7. Dokumentasjon, brukeropplæring, innføring Hvilken rekkefølge skal vi utføre disse stegene, en etter en eller overlappende? En eller flere ganger? Er det noe system - en anbefalt metode? Hva med vedlikehold av et eksisterende programsystem? 5

6 Hvordan utføres aktivitetene i prosjektet Utviklingsmetoder - hvordan gjennomføre aktivitetene : Bli helt ferdig med en før du begynner på neste. Fossefalls-modellen Gammeldags, urealistisk, fordi: Kan ikke ombestemme oss, vanskelig å hel-spesifisere noe man ikke ser eller har testet Nyttes nå bare nå i militære systemer og romfart Iterativt ( Unified Process - UP) - starter på flere aktiviteter samtidig og gjør alle aktiviteter flere ganger, g men: Forprosjektet ferdiggjøres raskt Hver gang vi har gjenntatt Kravspekk, Analyse, Design og Programmering, Testing lager vi en ny versjon av systemet med litt mer funksjonalitet enn den forrige versjonen. Et profesjonelt prosjekt går framover ved at det minst hver 2-3 uke lages en ny versjon som kan testes. Smidig systemutvikling 6

7 Smidig systemutvikling (agile) Ett nytt virkende system ofte Hver uke hver 4. uke Hver iterasjon inneholder Planlegging kravspesifikasjon design koding testing - dokumentasjon Brukere og programmerere snakker mye sammen Det virkende systemet definerer fremdriften Ny funksjonalitet og forandringer kan lett legges inn Lett å holde øye med budsjettet 7

8 Aktivitetene i UP - (slik de fremstilles av guruene i bransjen)

9 Forprosjekt Skal undersøke om det er vits i å lage et system Viktigst er: En grov oversikt over viktige funksjoner Et første kostnadsestimat Hvem vil betale for (eie) systemet Men også: Vurdering av potensielle brukere (kunder) til systemet En vurdering av konkurrentene Alt dette resulterer i en foretningsplan og plan for finansiering og bemanning, og: Avgjørelse om vi skal droppe prosjektet eller lage det. Risikovurderinger 9

10 Kravspesifikasjon Vi trenger en nøyere spesifikasjon av hva systemet skal gjøre Hvilke funksjoner skal det ha og avgrensning Ulik brukergrupper og deres krav og behov Ulike, ofte motsetningsfylte krav og behov Ytelseskrav Hvor store datamengder, Mki Maksimalt antall llbrukere og maksimale ki svartider Andre krav, Ergonomi Kobling mot andre systemer En kravspesifikasjon tilsvarer ofte en oppgavetekst for dere 10

11 Analyse Analyse = best mulig forståelse av problemområdet (for å lage et system) Viktig å forstå problemområdet vi skal lage system for: Vi trenger en modell (UML + fritekst) av det området vi skal lage et system for = domenemodell Hvilke klasser er det i den virkelige verden som interesserer oss Hvilke funksjoner gjør de ulike klassene våre Hvordan vil brukerne utveksle data med systemer Bruks-modellering (Use-case) 11

12 Viktig å avgrense systemet Det problemområdet vi ser på har Et nær utall begreper (= klasser) hvis vi bare ser nøye nok etter Hvert begrep kan gis en nær uendelig lang beskrivelse (eks: Det er ikke ende på hvor mye vi kan finne ut om ett menneske - hele livshistorien, hele DNAprofilen, ) Vi må avgrense systemet Hvilke begreper som interesserer system vårt Hvilke data trenger vi om hvert slikt objekt av disse begrepene 12

13 UML-diagrammer Objektdiagram: Vi tegner for det meste Java datastrukturer isteden. Klassediagram: Husk å se for deg objekt(er) der boksene (klassene) er tegnet 13

14 UML diagram for Bank: Bank 1 * Konto Navn: String Saldo : double Gir denne Java datastrukturen: Bank-objekt navn: type: HashMap Konto-objekter navn: type: Bank navn: HashMap-objekt type: Bank 14

15 Hvordan finne klassene Gitt et utkast til en kravspesifikasjon, hvordan finne klassene i problemområdet? Substantivmetoden Nesten alle generelle begreper er substantiver - finn disse i kravspesifiksasjonen "Et eiendomsregister inneholder flere eiendommer. En eiendom har tre eller flere hjørnepunkter (grensene er rette linjer mellom disse hjørnepunktene). Et hjørnepunkt deles mellom to eller flere eiendommer (som da er naboer). En eiendom eies av en eller flere eiere. En eiendom er entydig identifisert innenfor ett register (= en kommune) med et gårdsnummer (gnr) og et bruksnummer (bnr) " 15

16 Understrek substantivene i kravspesifikasjonen "Et eiendomsregister inneholder flere eiendommer. En eiendom har tre elle flere hjørnepunkter (grensene er rette linjer mellom disse hjørnepunktene).et hjørnepunkt deles mellom to eller flere eiendommer (som da er naboer). En eiendom eies av en eller flere eiere. En eiendom er entydig identifisert innenfor ett register (= en kommune) med et gårdsnummer (gnr) og et bruksnummer (bnr)..." Gir følgende 11 forslag : ser først på de mest brukte substantivene: Eiendomsregister, eiendom, hjørnepunkt, grense, linje, eier, nabo, register(=kommune), gårdsnummer, bruksnummer 16

17 Forslagene til klasser må bearbeides: Hvilke substantiver er samme begrep Eiendomsregister, register, kommune er hele systemet; er eieren av resten av dataene. Nesten alltid er det en slik klasse som: Det lages bare ett objekt av Som eier resten av dataene Er det begrep som kan representeres indirekte, som er motsatsene til hverandre: Hjørnepunkt, grense, linje - representerer det samme på ulike måte - vi velger én f.eks. hjørne Hvilke begreper blir til enkle variable i andre klasser og hvilke blir til egne klasser? 17

18 Når lager vi klasser? Noen blir bare variable i andre klasser Eks: En temperatur Andre opplyslysninger blir til egne klasser som vi lager objekter av Eks: En person, en bankkonto, en eiendom Det er ikke noe ved gjenstanden i verden, i virkeligheten som sier om vi skal lage en klasse eller ikke: Eks: et bilhjul er sammensatt del for en bilfabrikk, men kanskje ikke for Vegvesenents database over norske kjøretøyer. 18

19 Sammensatte ting blir klasser og objekter Hvis vi bare har en opplysning og ingen finere oppdeling av tingen, bruker vi bare en enkel, vanlig variabel Eks: Gnr,og Bnr, temperatur, grenselengde, (grenselengde kan også avledes av grensepunkter) Hvis data om en gjenstand har flere felt, mer enn et datum knyttet t til seg, lager vi en klasse: Hvis vi er i tvil : Lag en klasse (det blir gjerne flere opplysninger jo mer vi jobber med et problem). 19

20 Substantivmetoden gir ikke fasit, men et utgangspunkt Ingen metode - heller ikke substantivmetoden - gir en fasit, men et godt utgangspunkt for å drøfte hvilke klasser vi skal ha i systemet vårt. Husk at vi skal gå flere runder med analyse og design, men vi trenger et utgangspunkt for å lage første, minimale system. 20

21 Design av programsystemet Analysen var (den gode) beskrivelsen av problemområdet (med baktanke om at det skal inn i et datasystem) Design er utformingen av selve programsystemet (inkl. evt. database og kommunikasjonsløsning ikke i inf1010) Vi starter med det vi har så langt: Kravspesifikasjon (nesten ferdig) Analysen med: UML-diagram av problemområdet Brukernes interaksjon med systemet for ulike funksjoner Husk at analysen bare er et forslag vi skal gå flere runder med: Kravspesifikasjon -> analyse -> design -> koding -> testing (Men ikke ta for lett på det av den grunn) 21

22 Mer om design: Innkapsling og grensesnitt En klasse gir ikke andre klasser adgang til sine data direkte, men via et antall metoder for å lese og skrive på disse data (get- og set- metoder) Dette gjelder ikke bare enkeltdata, men også data som kan avledes - for eksempel summen og gjennomsnitt av data i et objekt eks. gjennomsnittstemperatur, grenselengder Adgang til data bare via metoder kalles innkapsling Gjør det mye enklere å teste, feilsøke og endre et program 22

23 Hvor skal vi legge metodene (funksjonene) Kan synes opplagt, men er det ikke alltid To prinsipper i (gir ofte, men ikke alltid samme resultat): Legg en funksjon der (nesten alle) data er som funksjonen skal jobbe på Legg funksjonene der de hører hjemme naturlig / i virkeligheten Ofte samme resultet, men ikke her: I et student/eksamens-system skal det skrives ut vitnemål. Skal metoden skrivvitemål() legges i: Class Student - hvor data ligger Class SkoleAdministrasjon - hvor funksjonen utføres i den virkelige verden Vl Velg det siste - blir lettere å vedlikeholde ld systemet (SkoleAdministrasjon henter data fra Student) 23

24 Design - kjente grep for å strukturere koden Top-down nedbryting av funksjoner til flere enklere metoder i ett eller flere nivåer Tidligere ble dette nyttet til å lage hele systemet. Nå nyttes OO. Top-down nyttes for enkelte funksjoner Bottom-up programmering Lage generelle klasser og operasjoner (metoder) vi vil trenge i systemet vårt fra bunnen av eller med grunnlag i biblioteker jfr. Java-biblioteket med ca generelle klasser for de fleste behov. Design-mønstre (patterns) For eksempel MVC Model View Control: del systemet opp i tre moduler/komponenter/klasser: Modell En ren datastruktur (i lageret) som holder alle data om problemet. Utsyn Usy Egen modul for å presentere modellen for brukeren på ulike måter valgt av brukeren (via kontrollen) Kontroll Egen modul/klasse for å motta ordre fra brukeren og enten endre modellen (legge inn nye data, endre, fjerne data) eller sende et nytt bilde av modellen til utsynet 24

25 Top-down nedbrytning av en beregning Eksempel værdata fra Met. Inst. (jfr Oblig4 i inf1000): Anta at vi har en enkel modell av værobservasjoner for Meteorologisk institutt, og at observasjonene gjøres på værstasjoner. Annenhver time, hver dag, hele året igjennom registreres temperatur og nedbør siden forrige observasjon. Nå kan vi tenke oss at vi er interessert i maksimums- og minimumstemperatur hver dag, og i gjennomsnittlig temperatur og samlet nedbør hver dag, hver måned og for hele året fra disse observasjonene. Hvordan skal vi regne ut gj.snitt temp og snitt nedbør for en stasjon per år? 25

26 Top-down: Gj.snitt nedbør per år og mnd. Enten en metode i class Stasjon med tre løkker inne i hverandre, over alle Måneder, Dager, Observasjoner Komplikasjon: Håndtering av manglende data på alle nivåer Alternativt - bedre: Hver av klassene har sin beregngjennomsnittnedbør() metode, som bare kaller neste tilsvarende det riktige antall ganger (og som til sist leser av verdien i Observasjon) 26

27 Kjente mønstre for programoppdeling Det er mange kjente og velprøvde måter å dele opp programkoden. Slike kjente måter kalles design patterns. Tatt fra standard designer i arkitekturen Christoffer Alexander Et slikt mønster lærte dere i INF1000 med kommandoløkka kk som legger ut en meny og tar kommando fra brukeren. Og i INF1010: Modell - Kontroll Utsyn Gå til bake og repeter Bank-eksemplet 27

28 Testing Alle klasser og metoder testes først separat, så samlet Unit testing i obligene. Integrasjons-testing. System-testing Regresstesting kjør alle gamle tester + evt. nye hver gang noe endres (ikke bare test det nye med nye tester) Binær søking Bruk av debugger Testing kan aldri vise fravær av feil, bare at systemet t virker for visse inndata. Bevis av programmer? Særs vanskelig og dyrt Lønner seg bare i helt spesielle tilfeller Jfr. invarianter i løkker og datastrukturer Legg tester inn i programmet (for- og bak -betingelser (bak-tilstand)) Sist, men ikke minst: Dokumentasjon, brukeropplæring, innføring (INF1050) 28