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