1 / 27

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

IN-OBJ2-EVU - UP/UML- del 1- Inception. Arne Maus Inst. for informatikk, UiO. Oversikt. Litt repetisjon Java UML (P)UP – systemutviklingsprosessen De ulike stadiene og bruk av UML Domene-modellen og designmodellen, interaksjonsdiagrammer

mihaly
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  20. Å 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

  21. Å 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

  22. UP er en Use-case drevet prosess

  23. Domene-modellen

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

  25. 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#,

More Related