UML og informationsmodellering ITU Usability med projekt Brugercentreret

UML og informationsmodellering ITU: Usability med projekt Brugercentreret design, forår 2008 v/ Egil Boisen

UML og informationsmodellering • UML – hvad er det? • Informationsmodellering – Klasser, objekter og relationer… – Principielle udfordringer i praksis – Hvordan går man frem: udgangspunkt i use cases • Use cases (igen) – Kaffetesten og hand-offs (Vendelhaven, 2002) – Cockburn: levels • Udblik, temaer: – Brugercentreret design, BPR – UML: Validering og verificering

Hvad er UML • UML er et sprog – En samling af symboler og diagramformer med syntaks og semantik til objektorienteret systembeskrivelse, analyse og design • Pointen med UML – en beskrivelsesstandard • er ikke er ’gift’ med nogen metode (ex. RUP) – et visuelt sprog der medierer mellem brugere og systemudviklere (og evt. maskinen): • kommunikation med domæneekspertise er afgørende vigtig

Objektorienteret informationsmodellering • Modellering af en begrebslig forståelse af et problemfelt – fænomener/ objekter • både mht. struktur og dynamik • til håndtering af relevant information i et edb-system • mhp. administration, overvågning, styring heraf.

’Klasse’ og ’objekt’ To forskellige abstraktionsniveauer Klasse Objekt – attributter/ generelle egenskaber: at ’en person har et navn’ – operationer/ adfærdsmønster eller procesegenskab – associationer/ association ends (+constraints) • • Klasse: en skabelon for objekter af samme type ikke en mængde af objekter! – identitet – egenskaber og tilstand: statiske og dynamiske værdier – Adfærd/ metoder: de hændelser som et bestemt objekt kan udføre eller påføres. • konkret instans af en klasse – En konkretisering ift. klassen • beskrivelse af et konkret fænomen i problemområdet med – en abstraktion ift. det konkrete fænomen

En klasse er en skabelon – for instantiering af objekter

Abstraktion ~ instantiering • Klasse – som abstrakt beskrivelse af: • Objekt – som abstrakt beskrivelse af: • Fysisk ‘ting’

Klasseskabelonen • En klasses egenskaber er bestemt ved dens: • Attributter • Operationer • Statiske relationer – Associationer – Generalisering fremgår ikke af klasseskabelonen, men af klassediagrammet. Eksempel :

Klassens attributter (objekternes tilstande) • Et objekt beskrives ved sin type = klasse – en klasse kan instantieres af mange objekter; en virksomhed gemmer oplysninger om hvert objekt (forekomst) i form af attributter. • Attributter fortæller om objektets egenskaber og hvordan data skal tolkes – f. eks. at et stykke data i systemet ’rød’ betyder ’rødhåret’ ved at forholde sig til attributten ’hårfarve’. • Klassens attributter skal ses som potentiel information.

Klassens operationer (objekternes metoder) • Objekter karakteriseres også ved deres adfærd – Adfærdsmønsteret: beskrives for klassen som dens operationer ved den mængde af hændelser som objekter af klassens kan være involveret i enten som aktiv eller passiv part. – Adfærd: de hændelser som et objekt udfører eller påføres i sit livsforløb; kaldes også for funktioner eller metoder. – En hændelse: en øjeblikkelig begivenhed der involverer et eller flere objekter.

Operationer og metoder for klassen og objektet

Objektorienteret informationsmodellering • Modellering af en begrebslig forståelse af et problemfelt – fænomener/ objekter • både mht. struktur og dynamik • til håndtering af relevant information i et edb-system • mhp. administration, overvågning, styring heraf.

Statiske relationsformer • Generalisering • Association – Almindelig binær • Navn • Multiplicitet • Roller – Aggregering – Associationsklasse

Kategorisering af fænomener • Generalisering/ specialisering – Nedarvning

Statiske relationsformer • Generalisering • Association – Almindelig binær • Navn • Multiplicitet • Roller – Aggregering – Associationsklasse

Klassediagram

Generalisering Nedarvning af genereller egenskaber ved specialisering

Navn

Navn navn

Multiplicitet/ kardinalitet

Multiplicitet/ kardinalitet multiplicitet

Roller roller

Aggregering når en klasses objekter er indeholdt i den anden klasses objekter.

én M: N => to 1: N-relationer Ass. klasse

Constraints • Constraints = regler – Kan angå klassen • Klassestrukturen (eks. XOR) • Attributter – Farvekode: {rød, grøn, gul} – Status: {betalt, ikke-betalt} » Status : Status = ikke betalt {betalt, ikke-betalt} • Operationer: specificerer pre- & post-condition – før man går i seng, skal man børste tænder – Kan angå associationen • Eks. ‘derived association’: reglen for hvem der kvalificerer som VIP kunder (antal besøg/ betalt kontingent/. . )

Objektorienteret informationsmodellering • Modellering af en begrebslig forståelse af et problemfelt – fænomener/ objekter • både mht. struktur og dynamik • til håndtering af relevant information i et edb-system • mhp. administration, overvågning, styring heraf.

Tilstandsdiagrammer • Objekters tilstande: – Udføre aktivitet – Vente på hændelse – Opfylde betingelse • Tilstandsdiagram viser et objekts statusmaskine – Initial og final tilst. – ‘guard condition’ (Scott, 2002, p. 119)

Sekvensdiagrammer • Fokus: – tidsrækkefølgen af meddelelser som går frem og tilbage mellem objekter – hvilke operationer på hvilke klasser? • Elementer: – objekter – livslinjer – meddelelser • de handlinger som objekter udfører overfor hinanden (eller sig selv) – betingelser UML 2 Tool. Kit, Fig. 5. 30

Aktivitetsdiagram (eb)

Modellering • Objektorienteret modellering • Arbejdsgange/ funktionalitet – Fænomener: – Use cases • Objekttyper: klasser og deres attributter og operationer – Strukturer • Klasse-relationer: generalisering og associationer – Dynamik • Objekters potentielle gøren og laden: metoder, tilstandsdiagram, sekvensdiagram • Værdi for aktører/ interessenter • Et sæt af use cases • Solskins-scenarier/ alternative scenarier – Aktivitetsdiagram – Use case testing • Verificering: lever systemet op til den lovede funktionalitet? • Validering: tilfredsstiller den lovede funktionalitet den brugernes egentlige behov? – Find klasser (ud fra kernenavneord)

Fordele ved OO • sikrer et system der bunder i en begrebslig forståelse af systemets omgivelser, samt indeholder en dynamisk model heraf (analyseobjekt), • muliggør genbrug af forbilleder, mønstre, komponenter (design-objekter), • har stor styrke ved systemer der understøtter en organisations administration, overvågning eller styring af et problemområde (eksempelvis sagsbehandling og koordinering), • letter vedligeholdelse (navnlig med UML), • faciliterer business process reengineering.

UML og kommunikation Fowler, 2000: • One of the biggest challenges is that of building the right system – one that meets users’ needs at a reasonable cost. [. . ] Achieving good communication, along with good understanding of the users’ world, is the key to developing good software. (Fowler, p. 10)

Objektorienteret systemudvikling: Udfordringen – at forstå de abstrakte, generelle sammenhænge mellem klasser og de konkrete sammenhænge mellem specifikke objekter, – at håndtere forskellige opfattelser af de samme begreber, – videreudvikle forståelsen af problemområdet mhp. at opnå administrative eller styringsmæssige forbedringer. » Mathiassen, 1997

BPR Business-process reengineering • 'Ved "proces" forstår vi simplet hen en række funktioner som, under et, producerer noget der er af værdi for en kunde - for eksempel ved at frembringe et produkt. ' – (Hammer & Champy 1994, s. 14) • Fokus på det overordnede formål for hele processen, i stedet for at medarbejderen blot kerer sig om sin egen del-opgave – (H&C 1994, s. 47) – 'Vask tavlen ren', 'start med et hvidt stykke papir': anti-bureaukratisk tænkning

Modellering • Objektorienteret modellering • Arbejdsgange/ funktionalitet – Fænomener: – Use cases • Objekttyper: klasser og deres attributter og operationer – Strukturer • Klasse-relationer: generalisering og associationer – Dynamik • Objekters potentielle gøren og laden: metoder, tilstandsdiagram, sekvensdiagram • Værdi for aktører/ interessenter • Et sæt af use cases • Solskins-scenarier/ alternative scenarier – Aktivitetsdiagram – Use case testing • Verificering: lever systemet op til den lovede funktionalitet? • Validering: tilfredsstiller den lovede funktionalitet den brugernes egentlige behov?

Rational Unified Process

V-model & test levels User needs operational system preparation acceptance test User req. System test Global design Integration test Detailed design component test Implementation

Use case as a contract Contract: actors (goals) and stakeholders (interest) • The system under discussion is a mechanism to carry out a contract between various stakeholders. Use cases provide the behavioral part of that contract. Every sentence is there because it describes an action that protects or furthers some interest of some stakeholder. A sentence must describe an interaction between two actors or what the system must do internally to protect the stakeholders’ interest. – The actors and goals model explains how to write sentences in the use case (detailing the behavioral aspect of the contract)…

Identificering af klasser • Tag udgangspunkt i problemområdet og brugernes opfattelse af det – Conceptual understandning of the users’ world; treat each class as a concept in the users mind. – Forudsætter samarbejde med brugerne: interviews, observation, diskussioner af kandidater til klasser og hændelser. • Find klasser: – Begynd med Use cases (evt. rige billeder eller andre eksisterende beskrivelser af brugernes arbejde) – Brainstorming: skriv en omfattende liste af kandidatklasser, ikke-censureret (åbenhed): • fokuser på navneord; begreber i ’business model’, komponenter i systemet; generelle klasse-typer for tilsvarende systemer, samt faglitteratur. • Vurder kritisk: – klasser og hændelser skal afspejle et behov for registrering af relevant information ift. styring, administration eller overvågning af problemområdet. – Hvilke klasser er nødvendige for at understøtte use cases? Hvilke navneord bliver klasser – hvilke blot attributter på disse? – Af de 12 vigtigste klasser, find mellem 4 – 8 essentielle klasser (Cockburn, 1998) • Find hændelser: – samme, men fokuser på udsagnsord som brugerne bruger til at forklare deres arbejde med (disse kan blive til operationer på klasserne)

Mini-analyse (2) Navneord/ Kandidat-klasser: • afdelingssygeplejersken • søgning • søgekriterie • ressourcer • ydelse/ behandlinger • tid (dato, klokkeslæt) • lokale • personaleressource • apparatur • patient • ressourcepræferencer • alternative behandlinger • bekræftelse Essentielle klasser: • lokale • personale • apparatur • ydelse/ behandlinger: – patient – ressourcer • Ressourcer: – tid (dato, klokkeslæt); lokale; personaleressource; apparatur • søgning: – ressourcer + interval (søgekriterie) • alternative behandlinger • bekræftelse

Mini-analyse (3)

Vanskelighed ved domæneanalyse • Det sete afhænger af øjnene der ser – Hvilken interesse har vi i at repræsentere hvilken information? – Hvad menes med de forskellige begreber, og hvordan håndteres forskellige opfattelser af de samme begreber? – Hvordan kan de kategoriseres: hvordan ser verden ud? (’Women, fire, and dangerous things’)

Begrebet Use case Eriksson et al. : UML 2 Toolkit, OMG, 2004: • ’a set of sequences of actions a system performs that yield an observable result of value to a particular actor. ’ – Begrebet use case definere nogle steder blot som beskrivende en sekvens af steps (eksempelvis Vendelhaven, 2002), men. . – læg mærke til udtrykket ’set of sequences’, ’et sæt af sekvenser’, og ikke bare ’en sekvens’ – der gemmer sig et ’spring i logisk type’ her, ligesom mellem ’klasse’ og ’objekt’ som instantiering af klassen. Fowler, 2000: • a set of scenarios tied together by a common user goal. – A snapshot of one aspect of your system. The sum of all use cases is the external picture of your system, explaining what it will do. – Central to understanding what your users want.

Use case relationer • Generalization: – nogle gange kan man gøre én ting, andre gange noget andet (restaurant: ved velkomst får børnefamilier et børnemenu-kort; par får en rose) • Extend: – en betinget funktion der giver en selvstændig værdi (ex: hvis en gæst ankommer regnvåd, hænges overtøjet til tørre) • Include: – hvis en funktion kan genbruges af andre use cases (der vaskes der hænder).

Scenariebeskrivelse (ex) Buy a Product 1. 2. 3. 4. 5. 6. 7. 8. Customer browses through catalog and selects items to buy Customer goes to check out Customer fills in shipping information (address; next-day or 3 -day delivery) System presents full pricing information, inclding shipping Customer fills in credit card information System authorizes purchase System confirms sale immediately System sends confirming email to customer Alternative: Authorization Failure At step 6, system fails to authorize credit purchase Allow customer to re-enter credit card information and retry Alternative: Regular Customer Third 3 a. System displays current shipping information, princing information, scenario? and last four digits of credit card information Extended 3 b. Customer may accept or override these defaults. use case? Return to primary scenario at step 6 (Fowler, 2000)

Handoffs Vendelhaven (2002) • Når sagen ‘hænger i luften’, skifter bord/ hænder • hvem har ansvaret for patienten på venteliste? • To muligheder mod handoffs: – undgå at en sag skifter hænder, – styrk informations-interfacet når det sker – Eb - ? • Klargør regler, evt. med højere-ordens use cases

Kaffe-testen • Kan aktøren med god samvittighed tage sig en kop kaffe efter endt interaktion med systemet – Bruges for at teste om handlingerne giver en meningsfuld værdi for aktøren – sea level eller fish level?

Cockburns use case niveauer Why? How?

Oversigt – Sky Level Opsætning Forbered vagtplan Vagtplan Ændringer Faktiske timer Ledelsesinfo ? ? ? Generel info 01 Afdelinger 10 Medarbejdere 20 Opret skabelon 30 Byt vagt 40 Komme/gå tider 50 Budgetopfølgning 60 Velkomst tekst 02 Medarbejdertyper 11 Kompeten-cer 21 Opret plan 31 Se ledige vagter (? ) 41 Godkend timer 51 Se timer/ dage 61 Fælles dok 03 Løntimer 12 Budget 22 Arbejdsplan 32 Overdrag vagt 42 Se løntimer 52 Fraværsoverblik 62 Telefonliste 04 Tidsregistrering 13 Rækkefølge i plan 23 Kommuniker plan 33 Ret plan 53 Flexkonto 63 Brugervejledning 05 Drikkepenge 14 Kalender 24 Se plan Andet 54 Brug af Tamigo 64 Kompetenceoversigt 55 Antal arbejdsdage 65 Sendte beskeder 15 Fravær System 70 Fordel drikkepenge 80 Log på 71 Indtast lead 81 Log af 72 Fritekst besked 82 Skift password 56 Udestående vagter 15. 1 Ferier

Vagtplan – Kite Level 2. Vagtplan 20 Skabelon 21 Plan 22 Arbejdsplan 23 Kommuniker plan 24 Se plan 20. 1 Opret Skabelon 21. 1 Indlæg vagter 22. 1 Indlæg arbejdsplan 23. 1 Læg ud på Tamigo 24. 1 Se plan på sms 20. 2 Gem som skabelon 21. 2 sammenhold med budget 20. 3 Hent skabelon 21. 3 Brug komp. krav 24. 1. 2 Se ugeplan touch skærm 20. 4 Rediger skabelon 21. 4 Fordeling på arbejdsplads 24. 2 Se plan på Tamigo 20. 5 Slet skabelon 21. 5 Gem plan 24. 2. 1 Se planer for flere uger 23. 2 SMS, mail, kalender 24. 1. 1 Se plan på mail 24. 3 Print plan 24. 3. 1 Print plan fra Word

System – Fish Level 8. System 80 Log på 81 Log af 82 Skift password 80. 1 brugernavn og pw 81. 1 Log af 82. 1 Vælg nyt password 80. 2 Password per SMS

Log på inklusiv use case Mål/ værdi: bruger logger på Tamigo, vælger evt. afdeling og ser afdelings forside. Aktører: medarbejder, planlægger, administrator. 1. Systemet viser ’skallen’ af Tamigo med mulighed for at logge på. 2. Aktør indtaster emailadresse og password. 3. Systemet viser afdelingens forside. 3 a. Bruger er tilknyttet flere afdelinger. Systemet beder bruger om at vælge mellem disse.

Ændringer – Kite Level 3. Ændringer 30 Byt vagt 31 Ledige vagter 33 Ret i plan 32. 1 Udbyd vagt 31. 1 SMS Byd på ledig vagt 33. 1 Vælg uge 30. 2 SMS Tag stilling til bytteforslag 32. 2 SMS Byd på udbudt vagt 31. 2 SMS Accept/afvis bud på vagt 33. 2 Tilføj vagt 30. 2. 1 SMS Tag stilling (touch) 32. 2. 1 Byd på vagt (touch) 33. 3 Flyt vagt 32. 3 SMS Accept/afvis bud på vagt 33. 4 Slet vagt 30. 1 SMS Foreslå vagtbytte 30. 3 SMS Accept/afvis vagtbytte 32 Overdrag vagt

Byt vagt (30) Kite level Mål/ værdi: medarbejdere arrangerer vagtbytte som godkendes/ afvises af planlægger. Aktører: medarbejdere, planlægger. 1. 2. 3. 4. 5. 6. Medarbejder A vælger fra listen en kollega (medarbejder B) og foreslår vagtbytte (30. 1). Tamigo sender sms herom til medarbejder B. Medarbejder B tager stilling til vagtbytteforslag (30. 2) i vagtbørsen og accepterer det. Tamigo sender vagtbytteforespørgsel til planlægger. Planlægger håndterer vagtbytteforslag (30. 3) i vagtbørsen. Tamigo sender sms til de pågældende medarbejdere om planlæggers accept (og opdaterer vagtplanen) eller afvisning af forslaget (vagtplan opdateres ikke). 2 a. Medarbejder B angiver afslag på bytteønske. Tamigo sender sms herom til medarbejder A og opdaterer Medarbejder A’s ugeoversigt (ift. bytteforslag). Use case stopper.

Foreslå vagtbytte sea level (30. 1) Mål/ værdi: medarbejder forespørger kollega om vagtbytte. Aktører: medarbejdere. Startbetingelser: Medarbejder er logget på og har valgt vagtbørsen. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Medarbejder A vælger at se ’Mine vagter’. Systemet viser medarbejderens vagter. Medarbejder A vælger en vagt med henblik på at bytte den med en kollega. Systemet beder Medarbejder A om at vælge en kollega fra listen over dem der har mulighed for at tage pågældende vagt. Medarbejder A angiver en kollega (medarbejder B). Systemet viser dernæst en række vagter som Medarbejder B har og som Medarbejder A kan få i bytte. Medarbejder A vælger en vagt fra listen. Systemet viser hvilket bytteforslag der er tale om og afventer bekræftelse fra Medarbejder A, og skriver at vagten stadig tilhører Medarbejder A indtil Medarbejder B har givet sit samtykke. Medarbejder A bekræfter vagtbytteforslaget. Systemet sender sms herom til Medarbejder B, giver Medarbejder A besked herom og gør endnu en gang opmærksom på at vagten stadig tilhører Medarbejder A, men at vedkommende vil få sms, når Medarbejder B har håndteret vagtbytteforslaget. Medarbejder A angiver at være indforstået hermed. Systemet opdaterer ’Mine vagter’ for Medarbejder A så vedkommende kan se at pågældende vagt ligger som vagtbytte og at der afventes håndtering heraf fra pågældende kollega.

Tag stilling til vagtbytteforslag sea level (30. 2) Mål/ værdi: medarbejder accepterer eller afviser forespørgsel fra kollega om vagtbytte. Aktører: medarbejdere og planlægger. Startbetingelser: Medarbejder B er logget på og har modtaget sms om vagtbytteforespørgsel fra Medarbejder A. 1. 2. 3. 4. Medarbejder B vælger Vagtbørsen og herunder Bytteforslag. Systemet viser listen af bytteforslag. Medarbejder angiver sin accept af et forslag fra kollega (Medarbejder B) og opdaterer listen for at registrere dette. Tamigo sender sms til både Medarbejder B og Planlægger om accepten, og ændrer visningen af vagten som ’Venter på OK’. 1 a. Medarbejder B vælger vagtbørsen og herunder Bytteforslag via Touchfacilitet (30. 2. 1). 3 a. Medarbejder A afviser vagtbyttet. Tamigo sender sms herom til Medarbejder B og opdaterer vagtbørsen. Use casen stopper.

Håndtere vagtbytteforlag (Planlægger; 30. 3) Mål/ værdi: Planlægger angiver sin accept eller afvisning af forespørgsel om vagtbytte blandt to medarbejdere. Aktører: Planlægger og medarbejdere. Startbetingelser: Planlægger er logget på og har modtaget sms om vagtbytteforespørgsel. 1. 2. 3. 4. Planlægger vælger Vagtbørsen og herunder Accepter bytteforslag. Tamigo viser listen af bytteforslag. Planlægger angiver sin accept eller afvisning af det pågældende forslag og opdaterer listen for at registrere dette. Tamigo ændrer listen tilsvarende og sender sms herom til begge medarbejdere. 3 a. Systemet kan ikke finde vagten i godkendte timer for medarbejderen og viser en fejlmeddelelse herom.