IN-OBJ2-EVU - UP/UML- del 1- Inception

1. 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 • Alt er objekter (eller enkle datatyper (int, char, double, ..)) • Alle egenskaper - dvs. data og metoder (prosedyrer) er inne i klasser • Alle utførende setninger er inne i metoder i klasser. • Det finnes klasse-metoder og -data i tillegg til objekt-metoder og -data • Bekyttelse (private, protected, public, ’friendly’/package)) • Enkel arv - alle klasser er sub(eller subsub,...) klasse av class Object • Dynamisk binding - alle metoder er (med mindre man sier noe annet) ’virtuelle’ • Abstrakte klasser og grensesnitt • Søppeltømmer • Unntaks(feil)håndtering • Parallellitet: Tråder • Spesielle 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 : • Kunde kommer til terminal med varer • Kassabetjent starter nytt salg • Systemet registrerer ny varetype og antall • Systemet lager en varelinje med antall type og pris (totalt og denne vare) – vis total på display • Gjenta 3-4 til ferdig • Systemet presenterer total inkl. moms • Betjent ber Kunde om betaling • Kunden betaler og Systemet mottar betalingen • Systemet logfører salg til lagersystem og i økonomisystem • Systemet skriver kvittering • Kunde forlater skranke med kvittering og varene

16. Andre senarioer – eks: • Generelt ved feil, sikre konsistent oppstart og riktig betalings-registrering : • Betjent restarter systemet, logger inn spør om nåværende feilsituasjon • Systemet rekonstruerer tidligere tilstand • Ved feil som hindrer gjenstart: • Systemet signaliserer feiltype til Betjenten, og går over i en annen sikker tilstand • Betjenten starter et nytt salg (hvis mulig å starte) • Kunde sier han skal ha rabatt: • Betjent registrerer rabatt-forespørsel • Betjenten registrerer Kundens identifikasjon • 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 <egenskap X> • 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#,