1Arne Maus, Ifi, Uio © 2002
IN-OBJ2-EVU -UP/UML- del 1- Inception
Arne MausInst. 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 :
1. Kunde kommer til terminal med varer2. Kassabetjent starter nytt salg3. Systemet registrerer ny varetype og antall4. Systemet lager en varelinje med antall type og pris (totalt
og denne vare) – vis total på display5. Gjenta 3-4 til ferdig6. Systemet presenterer total inkl. moms7. Betjent ber Kunde om betaling8. Kunden betaler og Systemet mottar betalingen9. Systemet logfører salg til lagersystem og i
økonomisystem10. Systemet skriver kvittering11. 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 feilsituasjon2. Systemet rekonstruerer tidligere tilstand
1. Ved feil som hindrer gjenstart:1. Systemet signaliserer feiltype til Betjenten, og går over i en
annen sikker tilstand2. Betjenten starter et nytt salg (hvis mulig å starte)
2. Kunde sier han skal ha rabatt:1. Betjent registrerer rabatt-forespørsel2. Betjenten registrerer Kundens identifikasjon3. 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#,