Arne Maus, Ifi, Uio © IN-OBJ2-EVU - UP/UML- del 1- Inception Arne Maus Inst. for informatikk, UiO

2 Oversikt  Litt repetisjon  Java  UML  (P)UP – systemutviklingsprosessen  De ulike stadiene og bruk av UML  Domene-modellen og designmodellen, interaksjonsdiagrammer  Vi skal gå gjennom de 3 første fasene i UP med et eksempel

3 Java - repetisjon zAlt er objekter (eller enkle datatyper (int, char, double,..)) zAlle egenskaper - dvs. data og metoder (prosedyrer) er inne i klasser zAlle utførende setninger er inne i metoder i klasser. zDet finnes klasse-metoder og -data i tillegg til objekt-metoder og -data zBekyttelse (private, protected, public, ’friendly’/package)) zEnkel arv - alle klasser er sub(eller subsub,...) klasse av class Object zDynamisk binding - alle metoder er (med mindre man sier noe annet) ’virtuelle’ zAbstrakte klasser og grensesnitt zSøppeltømmer zUnntaks(feil)håndtering zParallellitet: Tråder zSpesielle mekanismer for www (applet, mm)

4 Faser, aktiviteter, iterasjoner og produkter (RUP)

5 Om aktiviteter og faser – kap 2 Aktiviteter (radene)  Forretnings-modellering - > Domenemodel  Kravspec -> Use Case + andre krav  Analyse & Design -> Designmodel +.. Faser (kolonnene, iterasjonene):  Oppstart/Interception (Use Case, Kravspec, Prosjektmål, enkle estimater)  Vidererbearbeiding/Elaboration (mer Use Case & krav, analyse design, kjernearkitektur, et enkelt system kjører  Konstruksjon/Construction ( Mer krav, mer analyse&design, implementasjon,...)  Trasisjon( beta test, sette i drift)

6 Aktiviteter og produkter (oversikt)

7 Problem 1 POS (kasse-apparat) – kap 3 Ny generasjon kasseapparat :  Hva gjør et salgs-punkt-kasse apparat  Registrerer salg (ulike typer varer & inndatakilder)  motta betaling (ulike former : cash, kort, sjekk, krita..)  gi kvittering  gi opplysninger (skatteberegninger, logføre salg, oppdatere lagerbeholdning..)  feilsituasjoner  spesielle situasjoner (rabatter, vedlikehold, endringer i priser)

8 Oppstart / Inception – kap 4  Hva er forretningsideen for prosjektet  Er det gjennomførbart  Hva kjøpes / hva lages selv  Første kostnadsoverslag  Fortsette eller stoppe ?  Varighet: Et par uker max.

9 Hva skal lages (delvis)  Produkt-ideen / Forretningsplanen 1 utkast  Use Case – de fleste navngis eller lages i 1 versjon  Andre kravspesifikasjoner  Sentrale begreper defineres  Risiko – list vanskelige/dyre krav  Lag en enkel prototyp (prøve ut ett par vanskelige punkter) – kastes  Iterasjons-plan – 1 ver.  Finne/navngi de fleste sentrale aktører (de med interesse i produktet)

10 Å forstå prosjektkravene – typer av krav – kap 5  Funksjonelle  egenskaper / antall & typer funksjoner, sikkerhet,..  Brukervennlighet  Ergonomi, GUI, dok, mm  Ytelse svartider, maks. antall brukere oppetid,.  Support  Endrbarhet, vedlikeholdbarhet, internasjonalisering,.. + Språk, vektøy, hw, grensesnitt, samarbeidende systemer, regelverk (lov om..)

11 Hvordan få ned kravene til systemet – kap 6  Bestemme systemets grenser / virkeområde  Hva er utenfor, hvilke forbindelser har systemet, hva gjør det selv  Finne sentrale aktører  de som har kontakt/samhandling / gjør noe med systemet eller systemet gjør noe med  Både mennesker og andre datasystemer  Identifisere aktørenes mål for / hensikt med systemet  Skrive typiske brukssituasjoner = Use Cases  N.B er en tekstlig liste av brukssituasjoner – IKKE diagrammer først  Ikke bare normale tilfeller, men også for alle typer feilsituasjoner  Andre krav identifiseres  Ytelse, verktøy, hw, database,..

12 Finne aktører – Kasseapparat  Hvem  Bruker systemet daglig - kassabetjenten  starter/stopper systemet - Butikksjef  tar hånd om sikkerhet - Systemansvarlig  leser logger, bruker data som fanges – ledelsen i firma / salgssjef  Oppdatere datagrunnlaget (regler, kontanttabeller (priser)) – systemansvarlig eller butikksjef  Hvilke  andre data-systemer kommuniserer det med – lagersystemet, regnskap, skatteberegning  Lag liste over aktørene og deres mål med systemet

13 Bruksitusjoner (Use Case) – hvordan lage første (ufullstendige) utkast  Spør etter hensikten for en aktør med systemet – ikke hva man forventer det skal gjøre  Start med et verb for å navngi et Use Case  Behandle systemet som en ’sort boks’

14 Eks: Kassaterminalen – aktører og ønsker  Primær aktør: Kassabetjent  Ønsker høy nøyaktig (få feil), rask registrering, ingen betalingsfeil, brukervennlig (ergonomi mm)  Selger:  Ønsker registrert salg (bonus) på seg  Firma  ønsker nøyaktig registret antall solgte varer og beløp, fornøyde kunder, drift selv om linjer til bank etc. er nede, minimalt svinn  Staten  Ønsker registret nøyaktig salg – muligens direkte innrapportert  Bank / Visa / MasterCard  Nøyaktig registrering av kort, autorisering av bruker, sikker overføring. Identifikasjon av kassabetjent

15 Use Cases - eksempler  Salg - hovedsenario – uten feil : 1. Kunde kommer til terminal med varer 2. Kassabetjent starter nytt salg 3. Systemet registrerer ny varetype og antall 4. Systemet lager en varelinje med antall type og pris (totalt og denne vare) – vis total på display 5. Gjenta 3-4 til ferdig 6. Systemet presenterer total inkl. moms 7. Betjent ber Kunde om betaling 8. Kunden betaler og Systemet mottar betalingen 9. Systemet logfører salg til lagersystem og i økonomisystem 10. Systemet skriver kvittering 11. Kunde forlater skranke med kvittering og varene

16 Andre senarioer – eks: 1. Generelt ved feil, sikre konsistent oppstart og riktig betalings-registrering : 1. Betjent restarter systemet, logger inn spør om nåværende feilsituasjon 2. Systemet rekonstruerer tidligere tilstand 1. Ved feil som hindrer gjenstart: 1. Systemet signaliserer feiltype til Betjenten, og går over i en annen sikker tilstand 2. Betjenten starter et nytt salg (hvis mulig å starte) 2. Kunde sier han skal ha rabatt: 1. Betjent registrerer rabatt-forespørsel 2. Betjenten registrerer Kundens identifikasjon 3. Systemet gir nå ny total-pris basert på rabatt-type (hvis gyldig)

17 Ethvert Use Case har sin for- og etter betingelse  Forbetingelse:  Noe som alltid må gjelde før et Use Case kan starter  Eks: KassaBetjenten har identifisert seg og logget inn før salg kan starte  Etterbetingelse  Noe som gjelder etter at et Use Case er ferdig  Eks: Salget er sikret både på egen logg, i lagersystemet og i regnskap, Kvittering utskrevet, Evt. kommisjon godskrevet selger.

18 Om Use Case  Et Use Case :  håndterer en oppgave for en person på ett sted og til en tid for å gjøre en handling som endrer vedkommendes (forretnings)interesser målbart, og som etterlater data i en konsistent tilstand.  Dvs. Lag et Use Case for hver av aktørenes mål  Utvidelse / feilsituasjoner er mye lenger enn normaltilfellet – langt flere alternativer  Lag betingelser for Use Case som Systemet kan oppdage (Hvordan starter et Use Case)  Eks: Systemet oppdager linjefeil til bank – IKKE: Linjen til banken er nede  Bland ikke inn GUIen (brukergrensenittet) i et Use Case

19 Use Case er IKKE objekt- orientert  Grovt sett drives resten av systemutviklings- prosessen videre av at man utvikler flere Use Case og implementerer disse.  En iterasjon (i enten viderebearbeiding eller realisering) er å velge noen Use Case som implementeres i den iterasjonen.  Tegn UML diagrammer for hvert mål for hver aktør  (N.B. Ikke for alle Use Case’ne)  Lag oversiktsliste for Use Casene

21 Å finne andre krav – kap 7  Funksjonalitet  Logging av transaksjoner og feil,  Forretningsregler (kan endres)  Sikkerhet  Ergonomi (Eks: Tall synlige på 1 m.- bruk lydsignal ved strek-kodelesing)  Ytelse, feilhåndtering, konfigurering, krav til hw og sw.  Prissetting, rabatter, kredittsystem, Moms, ulike strekkoder  Ulike rapporter  Lisenser mm.  brukerstøtte, opplæring, dok

22 Å lage et forretningsmål, visjon for systemet  Består av opptil 50 egenskaper for Systemet  Gruppert i ulike overskrifter  En egenskap skal kunne brukes i flg. setning:  Systemet skal kunne  eks: Gjøre betalings-autorisasjon, håndtere et salg, skrive kvittering, gi feilmeldng ved uleselig strek-kode, oppdatere lager-registeret,.....  Skriv først et utkast til visjon  Identifiser brukermål og tilhørende Use Case’er  Skriv ut Use Case og tilhørende tilleggskrav  Redeifiner visjonen for systemet

23 UP er en Use-case drevet prosess

24 Domene-modellen

25 Design-modellen (videreutvikles fra domenemodellen, tar bl.a med I/O, maskinene)

27 Oppsummering av Oppstart / Inception  De fleste aktører, mål og use case’r er navngitt  Noen av Use casene er delvis utskrevet  De vanskeligste kravene er identifisert, risikoliste utarbeidet  Forretningsideen ver. 1 laget  Tekniske vanskelige punkter uttestet (Eks: Java Swing mot ’berøringsskjerm’ – virker det?)  Laget prototyp for litt av brukergrensesnittet  Vektøy og ferdige komponenter innkjøpt  Plan for første iterasjon laget  Utkast til høynivå arkitektur (Eks. to-lags arkitektur med fete klienter, SQL-Server,.NET og C#,