Struktureret system udvikling Minimodul 2: UML og use cases

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 Use case beskrivelse Hvad og hvorfor Betragtninger Sammenhæng mellem projektforløb og use cases U model Kravspecifikation Test 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 Tendens til at være uafhængige af hinanden og i tid Sammenhænget mellem kravene mistes og forståelsen for kravene er svære at opnå 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 Aktør Use Case Deltagelse i Association System Grænse (Ofte underfor stået) 6

Use case, eksempel Online butik Kunde Bestil vare Behandle kunderegning Salgs Assistent Send ordre 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 Inkluderet Use Case <<include>> 9

Eksempel på relationer mellem grundkomponenter Kunde Send ordre <<extend>> Håndter ordre <<include>> Valider User Kommerciel kunde Privat kunde Check Password 10

Use case komponenter Komponent Beskrivelse Syntaks Use case Aktør System grænse En sekvens af handlinger, som et system (eller andre enheder) kan udføre, interagere med aktørerne i use caset Et sammenhængende sæt af roller, som brugere af use caset, har mens denne interagere med use caset. Repræsentation af grænse mellem det fysiske system og aktørerne som interagerer med det fysiske system Use case Name Aktør navn 11

Use case, relationer Relation Beskrivelse Syntaks Association Interaktion mellem en aktør og en use case Generalisering Relation mellem en generel use case og en mere specifik use case Udvidelse Indeholdende Relation mellem en udvidet use case, baseret på en given use case Relation mellem en given use case, og i en base use case <<extend>> <<include>> 12

Eksempel MP3 afspiller MP3 afspiller Lytteren Afspil mp3 fil Vis ID-tag info Forstærker anlæg Uploader PC Upload af mp3 filer 13

Faldgruber #1 Kamera Åben shutter Kamera Tag billede Fotograf 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 User Browser Servicer side Browser Servicer side Admin Hvad er galt her? Interaktionen mellem User og Browser er temmelig uklar... Browser Sæt URL Vi kan sætte flere use cases op, der hænger sammen User Modtag side Server 15

Faldgruber #3 Check in passager <<uses>> Vej baggage <<uses>> Tildel sæde <<extends>> <<uses>> Tildel vinduesæde <<extends>> <<uses>> 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

Use cases - et andet eksempel ATM Kunde Bank system Identifikation Hæve Indsætte Konto kontrol Auditør Forestil jer et banksystem 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 Use case mål Fortsæt mod Use case mål Use case beskrivelse 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 8) Trykker knap for hæve 10) Indtaster beløb 11) Trykker OK 5) Verificerer PIN og kunde 7) Viser menu 6) Henter muligheder 9) Spørger efter mængde 14) Trykker JA 12) Vis mængde 13) Spørger om udprint 17) Tager kvittering 16) Printer kvittering 19) Tager kort 18) Spytter kort ud 21) Tager penge 20) Spytter penge ud 11) Valider mængde og subtraher 15) Henter historik 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 Kunde Bestil billet Validerings system Begge diagrammer er korrekte, men bemærk En er et server baseret systemmodel En er en forretnings model Kunde Sælger Billetforretning Køb billet Validerings system 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å... Hvor analytikeren straks vil spørge Hvad definerer godkendelse? Hvad medicin? Hvad er et medlem? Er vi alle enige om hvad et medlem er? En udviklers tankegang er meget lineær Jeg skal med det her, løse det her problem (fra A til Å via B, C, osv.) En analytikers tankegang er mere fokuseret på formålet Hvad arbejde udfører systemet for brugeren/brugerne? Og ikke hvordan udførest arbejdet! 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

Overordnet planlægning og styring Analyse Forståelse og overblik for alle involverede parter Krav Overordnet design Satellit Hardware Software Integration Identifikation af fejl, mangler og forbedringer Test Erfaringer 40

Kravspecifikation U modellen igen Analyse og kravspecifikation OO Analyse Arkitektur Design SW og HW implementering af use case X System Integrationstest Accepttest Use Case Model Iteration 41

Relation mellem kravspecifikation og use cases 42

Detaljeret planlægning Drej satellit Hardware Analyse Valg Implementering Software Test Integration Test Modellering Impl. 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

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