1. No category

Struktureret system udvikling
Minimodul 2: UML og use cases
Rasmus L. Olsen, 4 februar 2011
1
Evalueringen af Struktureret SystemUdvikling
• Udgangspunktet for evalueringen af kurset baserer sig
på de opgaver der bliver lavet i de tre workshops som
afholdes i løbet af kurset.
• Hver workshop vil starte med et oplæg til et givet
problemstilling, der løses gruppevis i løbet af den afsatte
tid. Løsningen til denne problemstilling dokumenteres,
således der for hver workshop dannes et dokument på
en 5-10 sider, som danner udgangspunkt i evalueringen
af faget.
• Faget evalueres individuelt og mundtlig med en
bestået/ikke bestået karakter.
2
Dagens program
• UML
•
•
•
System definition og afgræsninger
Elementer
Eksempler
•
•
Hvad og hvorfor
Betragtninger
•
•
•
U model
Kravspecifikation
Test
• Use case beskrivelse
• Sammenhæng mellem projektforløb og use cases
• Opgaver
3
Problemet med ”traditionelle” krav, features og
begrænsninger
• De beskriver ikke hvad systemet gør
•
Tendens til at beskrive hvad slutmålet skal være
•
Sammenhænget mellem kravene mistes og forståelsen for
kravene er svære at opnå
• Tendens til at være uafhængige af hinanden og i tid
• Svære at konvertere til design
•
Fordi der mangler et tidsligt sammenhæng er udvikleren ofte
nød til at gætte sig frem til hvad der skal ske i systemet
• De er svære at teste
•
Fordi de mangler et sammenhæng
• Svaret på spørgsmålet ingen stillede: Use Cases!
4
Unified Modelling Language (UML)
•
•
•
UML (Unified Modelling Language) = en OMG (Object Management Group)
standard (www.omg.org)
OMG er en sammenslutning af ca. 800 virksomheder.
UML anvendes i dag verden over som beskrivelsesværktøj i forbindelse med
udviklingsprojekter. Eksempler på værktøjer:
• ArgoUML: http://argouml.tigris.org/
• Visual Paradigm: http://www.visual-paradigm.com/
5
Use case notation
Et interface
Use Case
Aktør
System
Grænse
(Ofte
underfor
stået)
“Deltagelse i”
Association
6
Use case,
eksempel
Online butik
Bestil vare
Kunde
Behandle kunderegning
Send ordre
Salgs
Assistent
Finans
organ
7
Mål med Use Cases
En Use Case:
• specificerer en komplet funktionalitet, som har værdi for brugeren
• “Aktør” (aktør/bruger) befinder sig eksternt i forhold til systemet. Kan
være en person, hardware, m.m.
• “Aktør” er karakteriseret ved sin rolle, hvilket også skal fremgå af navnet !
• systemet betragtes som en “black box”
• skal ikke omhandle design !
• kun det antal use cases der er nødvendige for at forstå systemets
funktionalitet
8
Relationer mellem grundkomponenter
Grund Use Case
Grund Use Case
Aktør
<<extend>>
Specifik
Use Case
Udvidet
Use Case
Grund Use Case
Specifik
Aktør
Specifik
Aktør
<<include>>
Inkluderet
Use Case
9
Eksempel på relationer mellem
grundkomponenter
Send
ordre
Kunde
<<extend>>
Håndter
ordre
Kommerciel
kunde
Privat
kunde
<<include>>
Valider
User
Check
Password
10
Use case komponenter
Komponent Beskrivelse
Syntaks
Use case
En sekvens af handlinger, som
Use case
et system (eller andre enheder)
Name
kan udføre, interagere med
aktørerne i use caset
Aktør
Et sammenhængende sæt af
roller, som brugere af use caset,
har mens denne interagere med Aktør navn
use caset.
System
Repræsentation af grænse
grænse
mellem det fysiske system og
aktørerne som interagerer med
det fysiske system
11
Use case, relationer
Relation
Association
Beskrivelse
Interaktion mellem en aktør og
en use case
Generalisering Relation mellem en generel use
case og en mere specifik use
case
Udvidelse
Relation mellem en udvidet use
case, baseret på en given use
case
Indeholdende Relation mellem en given use
case, og i en base use case
Syntaks
<<extend>>
<<include>>
12
Eksempel – MP3 afspiller
MP3 afspiller
“Lytteren”
Afspil mp3 fil
Vis ID-tag info
Forstærker
anlæg
Upload af mp3 filer
“Uploader”
PC
13
Faldgruber #1
Fotograf
Kamera
Kamera
Åben shutter
Tag billede
Flash
Fotograf
Formater
kort
Luk shutter
• Hvor er problemet?
•
•
Åbne/lukke shutter + flash er ikke isolerede anvendelser!
Tidsmæssig afhængighed er bedre beskrevet på andre måder...
• Sekvensdiagrammer, men dem kommer vi til
14
Faldgruber #2
Server
Server
Start/stop
Servicer side
User
Browser
Browser
Sæt URL
Interaktionen mellem User og
Browser er temmelig uklar...
• Vi kan sætte flere use cases op,
der hænger sammen
Admin
Browser
• Hvad er galt her?
•
Servicer side
User
Modtag side
Server
15
Faldgruber #3
Check in passager
<<uses>>
Vej baggage
Tildel vinduesæde
<<uses>>
Tildel sæde
<<uses>>
<<extends>>
<<uses>>
<<extends>>
Tildel midtersæde
• Hvad er problemet nu her?
•
Ved <<uses>> indikerer vi at en opgave har en delopgave der skal løses før
hovedopgaven er løst -> vi kan ikke både tildele et vindue og midtersæde....
• Ved <<extends>> kan vi udtrykke der er flere måder at udføre en
generel opgave på
16
Dagens program
• UML
•
•
•
System definition og afgræsninger
Elementer
Eksempler
•
•
Hvad og hvorfor
Betragtninger
•
•
•
U model
Kravspecifikation
Test
• Use case beskrivelse
• Sammenhæng mellem projektforløb og use cases
• Opgaver
17
Use cases - et andet eksempel
Bank system
• Forestil jer et banksystem
•
Identifikation
ATM
Hæve
Indsætte
Kunde
Konto kontrol
Auditør
•
•
•
•
Hvad skal banksystemet
gøre?
Hvad er dets ansvar?
Hvad er aktørens ansvar?
Hvad skal brugeren gøre
for at kunne udføre de
forskellige ting?
Hvad nu hvis noget går
galt? Brugeren gør noget
uventet? Maskinen gør
noget uventet?
18
Hvad er en use case?
Karakteristika og formål
• En mekanisme til at beskrive operationelle krav til
systemet
• En beskrivelse af det tidslige forhold mellem system og
aktør involveret i systemets anvendelse
• En teknik til at udtrykke hvem, hvad og hvordan et
system skal opføre sig
• En metode til at klargøre en sekvens af aktiviteter, som
tilsammen har en værdi for en ekstern bruger
• En metode til at klargøre afvigende interaktioner
mellem bruger og aktør
19
Use cases
• Use cases fanger overordnede opførsel af systemet
• Anvendes til
•
•
•
•
Design og udvikling af system
Fastholdelse af projektfokus
Test og verifikation af overordnet system
Kommunikationsmiddel mellem forskellige aktører involveret i
udviklingsprocessen
20
Use cases - overordnet
Use case start
Undtagelse
Fortsæt mod
Use case
mål
Undtagelse
Fortsæt mod
Use case
mål
Use case
beskrivelse
Use case
mål
21
Use case beskrivelse
22
Hvem gør hvad og hvornår?
Bruger
ATM
System
1) Indsætter kort
2) Læser
magnet/chip
4) Indtaster PIN
3) Spørger om
PIN
5) Verificerer PIN og
kunde
8) Trykker knap for
hæve
7) Viser menu
6) Henter muligheder
10) Indtaster beløb
11) Trykker OK
9) Spørger efter
mængde
14) Trykker JA
12) Vis mængde
13) Spørger om
udprint
11) Valider mængde og
subtraher
17) Tager kvittering
16) Printer
kvittering
15) Henter historik
19) Tager kort
18) Spytter kort
ud
21) Tager penge
20) Spytter penge
ud
23
Eksempel på use case beskrivelse
24
Udvidelse af use cases
+
Use case
beskrivelse
=
Udvidelser til at
fjerne antagelser
Komplette
Use cases
25
Problemet med flere aktører
26
Alt afhænger af de øjne der ser systemet
Online billetsystem
Bestil billet
Kunde
Validerings
system
• Begge diagrammer er
korrekte, men bemærk
•
•
En er et server
baseret systemmodel
En er en forretnings
model
Billetforretning
Kunde
Køb billet
Validerings
system
Sælger
27
Vi skal forstå de forskellige roller
• Typisk involverede i forhold til systemet, krav og udvikling
•
•
•
Udvikler
Analytiker
Bruger(e)
• Support folk
• Installatører
• Operatører
• Slut bruger
• Andre systemer
• Hvem skal være involveret i udviklingen af use cases?
•
Eller med hvilke øjne skal man angribe use cases?
28
Og de øjne der ser #1
• Udviklere
•
•
Typisk førstevalg fordi de er tilgængelige
Typisk også et forkert valg, fordi de fokuserer på løsninger
• Brugere
•
•
•
Gode til at bidrage med råmateriale til use cases
Ser oftest ikke use cases som en nødvendighed
• Det er da soleklart for enhver, det skal være således!!!
• Med det, er det indforstået at .....!!!
Spørger man forskellige brugere, får man
forskellige svar
29
Og de øjne der ser #1
• Analytikeren
•
•
Faciliterer use case udviklingen og danner bro mellem
udviklere og brugere
Skal være i stand til
• At kunne stille de rigtige spørgsmål
• Opnå enighed mellem involverede
• Have en høj tolerance overfor ukomplethed
• Evne at tænke abstrakt
• Det er med analytikerens øjne der skrives use cases!
30
Forskelle mellem de tre
• En bruger kan f.eks. sige
•
... hvis et medlem er godkendt til medicin, så ....
•
•
•
Hvad definerer godkendelse?
Hvad medicin?
Hvad er et medlem? Er vi alle enige om hvad et medlem er?
• Hvor analytikeren straks vil spørge
• En udviklers tankegang er meget lineær
•
Jeg skal med det her, løse det her problem (fra A til Å via B, C, osv.)
•
Hvad arbejde udfører systemet for brugeren/brugerne?
Og ikke hvordan udførest arbejdet!
• En analytikers tankegang er mere fokuseret på formålet
31
Klar, parat, start
• Hvordan kommer vi godt fra start med use cases?
•
Definer mål og start fra hvad i ved
• Hvad nu, når use casen er ukomplet/fyldt med huller?
•
Iterer, gå videre med huller; på et tidspunkt bliver de fyldt ud
• Hvad nu hvis vi ikke ved hvad der starter en use case?
•
•
•
•
Let – drop det ... indtil videre.
Marker det så i kan se ”startshændelse ukendt” – TBD
Gå igang med indholdet i use casen
Over tid, og via iteration vil i opdage den manglende start
32
Karakteristika af use cases
• ”Dårlige” use cases beskriver
•
•
•
•
Lavtliggende funktioner fra et teknisk synspunkt
• CRUD funktioner (Create, Retrieve, Update og Delete)
Hvilken teknologi der anvendes, f.eks. Bluetooth
Ydelsesorienteret funktioner
Sammenhæng mellem delsystemer
• ”Gode” use cases beskriver
•
•
En identificerbar transaktion der har en brugsværdi for den
angivne bruger/aktør
Metoder hvormed en aktør opnår sine forudsatte mål
33
Do’s og Don’ts
• Brug verber
•
Use cases er altid aktive og orienteret til at bruge verber
F.eks. skriv ”personaliser indhold” istedet for ”personalisering”
hvis man beskriver en use case der tillader en bruger at
personalisere indholdet på en webside (f.eks. ved et content
management system)
• Brug definitive ord (undgå uklarheder)
•
•
Undgå fraser som ”systemet kan måske...”, ”funktion xyz kan
udbydes i nogle tilfælde... ”, ”... i tvivlstilfælde udføres en generel
funktion”.
Hvis der er tvivl om noget, efterlad det i en tilstand af TBD og
diskuter det med den relevant aktør eller anden relevant person
34
Do’s og Don’ts
• Anvend strukturet sprogbrug
•
Sammenlign f.eks.
The order entry system has an
interface to a backend system
and to a terminal
It computes and displays the
the sum of the order item’s cost
The orderer (a system or an entry
person) identifies the name of the
customer & the items on the order
The system displays the cost of
the total order
If the item is in stock and the client
has sufficient credit, ...
Hvad? Hvor? Hvordan?
35
Do’s og Don’ts
• Undgå at udtrykke mål og elementer i tekniske termer og
specifik teknologi
•
•
•
Dårligt: Byg XML parsing infrastruktur
• Måske forståelig for en programmør (men til hvilket formål?)
• Ikke forståelig for en slutbruger
Bedre: Formatter data til udveksling
• Tillader forskellige typer af dataformater og ikke kun XML
• Mere forståelig for en slutbruger (ok ok, måske ikke lige min bedstemor)
Sluttelig, kan man i samme ombæring udnytte formuleringer som
• Use case beskrivelsen ”Formatter data til udveksling” er udført successfuldt
med XML parsing modulet
36
Do’s og Don’ts
• Selvom det kan være nødvendigt at holde ting i en TBD
tilstand, så forsøg at lukke huller hurtigst muligt
•
•
Åbne ender tillader andre at fortolke uden at der er enighed
• Køkkenvask syndromet (Scope creep  )
Det bliver mere svært at vurdere den tid det tager at udvikle
use casen
• Use cases uden undtagelser siger stort set vi har en
perfekt verden
•
•
Og det har vi jo ikke !!!
Der vil altid være en bruger der liiiige skal prøve noget...
(og det kunne være mig!)
37
Andre gode hints
• Overvej hvorfor i har use casene
•
•
•
Find ordre -> Hvorfor skal x finde en ordre?
Måske i virkeligheden i prøver på at sende ordre....?
Søg index -> Hvorfor skal indekset søges?
Måske i virkeligheden i gerne vil håndtere indeks…?
Lokaliser vognmand -> Hvorfor vil i lokalisere vognmand?
Måske i virkeligheden i vil tilknytte vognmand rute..?
• Pointen: at være kritisk overfor de use cases i vil beskrive!
•
•
Use cases skal beskrive på passende niveau hvad systemet skal gøre.
Spørg jer selv: Hvad vil i med denne use case?
38
Dagens program
• UML
•
•
•
System definition og afgræsninger
Elementer
Eksempler
•
•
Hvad og hvorfor
Betragtninger
•
•
•
U model
Kravspecifikation
Test
• Use case beskrivelse
• Sammenhæng mellem projektforløb og use cases
• Opgaver
39
Overordnet planlægning og styring
Forståelse og
overblik for alle
involverede
parter
Satellit
Identifikation af
fejl, mangler og
forbedringer
Analyse
Erfaringer
Krav
Test
Overordnet
design
Integration
Hardware
Software
40
U modellen igen
OO
Analyse
Arkitektur
Design
SW og HW
implementering
af use case X
System
Integrationstest
Accepttest
Kravspecifikation
Analyse og
kravspecifikation
Use Case Model
Iteration
41
Relation mellem kravspecifikation
og use cases
42
Detaljeret planlægning
Drej satellit
Hardware
Integration
Analyse
Valg
Implementering
Test
Software
Modellering
Impl.
Test
Test
Link til overordnet analyse
43
Link mellem use case og blokke
44
Relation til tests
•
•
•
•
En use case er mål orienterede
En use case indeholder scenarier
Hvert scenarie medfører mindst en funktionel test
Hvert scenarie har en start og slutbetingelse,
som kan måles og vejes! Ellers må det ændres!
• En funktionel test indeholder specifikation fra alle
scenarier
• Mere om det i senere minimodul vdr. tests
45
Dagens program
• UML
•
•
•
System definition og afgræsninger
Elementer
Eksempler
•
•
Hvad og hvorfor
Betragtninger
•
•
•
U model
Kravspecifikation
Test
• Use case beskrivelse
• Sammenhæng mellem projektforløb og use cases
• Opgaver
46
Opgaver - i grove træk
• Hente UML værktøj og lære det at kende, tegn use case
diagram for jeres P1 projekt
• UML use case for satellit projekt
•
NB! Hold det overordnet!
• UML use case for jeres P2 projekt
•
Beskriv use case; husk undtagelser!
47