INF våren Fra problem til program. Utvikling av store datasystemer. Eksempel: Lage en nytt hus. Oversikt:

Transkript

1 Oversikt: INF våren 2008 Fra problem til program Stein Gjessing Inst. for informatikk n Fasene i utvikling av datasystemer n Utviklingsmetoder n Fossefall og Unified Process (UP) n Smidig systemutvikling n Hvordan finne et forslag til klassene i systemet n UML n Substantivmetoden n Design av programmet n Top-down og bottom-up programmering n Innkapsling og grensesnitt n Programmønstre n Testing (bare litt) 1 2 Utvikling av store datasystemer n Aktiviteter: Hvilke ulike arbeidsoppgaver er det i utviklingsarbeidet n Eller er det bare å starte å programmere? n Utviklingsmetodikk: De ulike aktivitetene i arbeidet, er det noen anbefalt måte/rekkefølge å gjøre disse på? n Gjøres de hver for seg i rekkefølge - en etter en? n Gjøres de i parallell - alle sammen eller bare noen? n Gjentas noen av aktivitetene, eller blir man greit ferdig med dem en etter en? n Økonomi: Er det enkelt/mulig å få vite hvor mye et datasystem vil koste å lage? n Vanligvis ikke! - Men vi lærer (kanskje) Eksempel: Lage en nytt hus Arbeidet deles i aktiviteter: n Planlegge rom-behov (typer og antall/størrelse) n Tegne hus (arkitekt) n Bygge hus: n Velge entreprenør/utbygger/håndverkere n Velge materialer/innredning n Søke tillatelser,.., n 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. 3 4

2 Oversikt over aktivitetene i programutvikling: Hvordan utføres aktivitetene i prosjektet 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 Utviklingsmetoder - hvordan gjennomføre aktivitetene : n Bli helt ferdig med en før du begynner på neste. Fossefalls-modellen n Gammeldags, urealistisk, fordi: n Kan ikke ombestemme oss, vanskelig å hel-spesifisere noe man ikke ser eller har testet n Nyttes nå bare nå i militære systemer og romfart n Iterativt ( Unified Process - UP) - starter på flere aktiviteter samtidig og gjør alle aktiviteter flere ganger, men: n Forprosjektet ferdiggjøres raskt n 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. n Et profesjonelt prosjekt går framover ved at det minst hver 2-3 uke lages en ny versjon som kan testes. n Smidig systemutvikling 6 Smidig systemutvikling (agile) n Ett nytt virkende system ofte n Hver uke hver 4. uke n Hver iterasjon inneholder n Planlegging kravspesifikasjon design koding testing - dokumentasjon n Brukere og programmerere snakker mye sammen n Det virkende systemet definerer fremdriften n Ny funksjonalitet og forandringer kan lett legges inn n Lett å holde øye med budsjettet Aktivitetene i UP - (slik de fremstilles av guruene i bransjen) 7

3 Forprosjekt Kravspesifikasjon Skal undersøke om det er vits i å lage et system n Viktigst er: n En grov oversikt over viktige funksjoner n Et første kostnadsestimat n Hvem vil betale for (eie) systemet n Men også: n Vurdering av potensielle brukere (kunder) til systemet n En vurdering av konkurrenterne n Alt dette resulterer i en foretningsplan og plan for finansiering og bemanning, og: n Avgjørelse om vi skal droppe prosjektet eller lage det. 9 n Vi trenger en nøyere spesifikasjon av hva systemet skal gjøre n Hvilke funksjoner skal det ha og avgrensning n Ulik brukergrupper og deres krav og behov n Ulike, ofte motsetningsfylte krav og behov n Ytelseskrav n Hvor store datamengder, n Maksimalt antall brukere og maksimale svartider n Andre krav, n Ergonomi n Kobling mot andre systemer n En kravspesifikasjon tilsvarer ofte en oppgavetekst for dere 10 Analyse Viktig å avgrense systemet n Analyse = best mulig forståelse av problemområdet (for å lage et system) n Viktig å forstå problemområdet vi skal lage system for: n Vi trenger en modell (UML + fritekst) av det området vi skal lage et system for = domenemodell n Hvilke klasser er det i den virkelige verden som interesserer oss n Hvilke funksjoner gjør de ulike klassene våre n Hvordan vil brukerne utveksle data med systemer n Bruks-modellering (Use-case) n Det problemområdet vi ser på har n Et nær utall begreper (= klasser) hvis vi bare ser nøye nok etter n 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, ) n Vi må avgrense systemet n Hvilke begreper som interesserer system vårt n Hvilke data trenger vi om hvert slikt objekt av disse begrepene 11 12

4 UML-diagrammer UML diagram for Bank: Bank Konto n Objektdiagram: Vi tegner for det meste Java datastrukturer isteden. Bank-objekt 1 * Gir denne Java datastrukturen: Navn: String Saldo : double Konto-objekter navn: navn: n Klassediagram: type: HashMap type: Bank Husk å se for deg objekt(er) der boksene (klassene) er tegnet HashMap-objekt navn: type: Bank Hvordan finne klassene Understrek substantivene i kravspesifikasjonen n Gitt et utkast til en kravspesifikasjon, hvordan finne klassene i problemområdet? n Substantivmetoden n 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) " "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: n Eiendomsregister, eiendom, hjørnepunkt, grense, linje, eier, nabo, register(=kommune), gårdsnummer, bruksnummer 15 16

5 Forslagene til klasser må bearbeides: n Hvilke substantiver er samme begrep n Eiendomsregister, register, kommune er hele systemet; er eieren av resten av dataene. Nesten alltid er det en slik klasse som: n Det lages bare ett objekt av n Som eier resten av dataene n Er det begrep som kan representeres indirekte, som er motsatsene til hverandre: n Hjørnepunkt, grense, linje - representerer det samme på ulike måte - vi velger én f.eks. hjørne n Hvilke begreper blir til enkle variable i andre klasser og hvilke blir til egne klasser? Når lager vi klasser? n Noen blir bare variable i andre klasser n Eks: En temperatur n Andre opplyslysninger blir til egne klasser som vi lager objekter av n Eks: En person, en bankkonto, en eiendom n Det er ikke noe ved gjenstanden i verden, i virkeligheten som sier om vi skal lage en klasse eller ikke: n Eks: et bilhjul er sammensatt del for en bilfabrikk, men kanskje ikke for Vegvesenents database over norske kjøretøyer Sammensatte ting blir klasser og objekter Substantivmetoden gir ikke fasit, men et utgangspunkt n Hvis vi bare har en opplysning og ingen finere oppdeling av tingen, bruker vi bare en enkel, vanlig variabel n Eks: Gnr,og Bnr, temperatur, grenselengde, (grenselengde kan også avledes av grensepunkter) n Hvis data om en gjenstand har flere felt, mer enn et datum knyttet til seg, lager vi en klasse: n Hvis vi er i tvil : Lag en klasse (det blir gjerne flere opplysninger jo mer vi jobber med et problem). n Ingen metode - heller ikke substantivmetoden - gir en fasit, men et godt utgangspunkt for å drøfte hvilke klasser vi skal ha i systemet vårt. n Husk at vi skal gå flere runder med analyse og design, men vi trenger et utgangspunkt for å lage første, minimale system

6 Design av programsystemet Mer om design: Innkapsling og grensesnitt n Analysen var (den gode) beskrivelsen av problemområdet (med baktanke om at det skal inn i et datasystem) n Design er utformingen av selve programsystemet (inkl. evt. database og kommunikasjonsløsning ikke i inf1010) n Vi starter med det vi har så langt: n Kravspesifikasjon (nesten ferdig) n Analysen med: n UML-diagram av problemområdet n 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) n 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) n Dette gjelder ikke bare enkeltdata, men også data som kan avledes - for eksempel summen og gjennomsnitt av data i et objekt n eks. gjennomsnittstemperatur, grenselengder n Adgang til data bare via metoder kalles innkapsling n Gjør det mye enklere å teste, feilsøke og endre et program Hvor skal vi legge metodene (funksjonene) n Kan synes opplagt, men er det ikke alltid n To prinsipper (gir ofte, men ikke alltid samme resultat): n Legg en funksjon der (nesten alle) data er som funksjonen skal jobbe på n Legg funksjonene der de hører hjemme naturlig / i virkeligheten n Ofte samme resultet, men ikke her: n I et student/eksamens-system skal det skrives ut vitnemål. Skal metoden skrivvitemål() legges i: n Class Student - hvor data ligger n Class SkoleAdministrasjon - hvor funksjonen utføres i den virkelige verden Velg det siste - blir lettere å vedlikeholde systemet (SkoleAdministrasjon henter data fra Student) 23 Design - kjente grep for å strukturere koden n Top-down nedbryting n av funksjoner til flere enklere metoder i ett eller flere nivåer n Tidligere ble dette nyttet til å lage hele systemet. Nå nyttes OO. Top-down nyttes for enkelte funksjoner n Bottom-up programmering n 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. n Design-mønstre (patterns) For eksempel MVC Model View Control: del systemet opp i tre moduler/komponenter/klasser: n Modell n En ren datastruktur (i lageret) som holder alle data om problemet. n Utsyn n Egen modul for å presentere modellen for brukeren på ulike måter valgt av brukeren (via kontrollen) n Kontroll n 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

7 Top-down nedbrytning av en beregning Top-down: Gj.snitt nedbør per år og mnd. 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 n Enten en metode i class Stasjon med tre løkker inne i hverandre, over alle Måneder, Dager, Observasjoner n Komplikasjon: Håndtering av manglende data på alle nivåer n 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 Kjente mønstre for programoppdeling Testing n Det er mange kjente og velprøvde måter å dele opp programkoden. Slike kjente måter kalles design patterns. n Tatt fra standard designer i arkitekturen Christoffer Alexander n Et slikt mønster lærte dere i INF1000 med kommandoløkka som legger ut en meny og tar kommando fra brukeren. n Og i INF1010: Modell - Kontroll Utsyn n Gå til bake og repeter Bank-eksemplet n Alle klasser og metoder testes først separat, så samlet n Regresstesting kjør alle gamle tester + evt. nye hver gang noe endres (ikke bare test det nye med nye tester) n Binær søking n Bruk av debugger n Testing kan aldri vise fravær av feil, bare at systemet virker for visse inndata. n Bevis av programmer? n Særs vanskelig og dyrt n Lønner seg bare i helt spesielle tilfeller n Jfr. invarianter i løkker og datastrukturer 27 28

8 Dokumentasjon, brukeropplæring, innføring n Ikke del av dette kurset, men meget viktig. n Dekkes av kurs fra ISU-gruppa 29