Laste ned presentasjonen
Presentasjon lastes. Vennligst vent
PublisertVetle Holt Endret for 9 år siden
1
Arne Maus, Ifi, Uio © 2002 1 IN-OBJ2-EVU - UP/UML- del 1- Inception Arne Maus Inst. for informatikk, UiO
2
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
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
4 Faser, aktiviteter, iterasjoner og produkter (RUP)
5
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
6 Aktiviteter og produkter (oversikt)
7
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
23 UP er en Use-case drevet prosess
24
24 Domene-modellen
25
25 Design-modellen (videreutvikles fra domenemodellen, tar bl.a med I/O, maskinene)
27
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#,
Liknende presentasjoner
© 2024 SlidePlayer.no Inc.
All rights reserved.