Download thesis - Kjeld Schmidt

andre ord ikke bekymre sig om, hvilken sendemast i nærheden, der har det
bedste signal. Det samme gælder for W-LAN og GPS. Teknologierne finder
selv henholdsvis den W-LAN-hotspot eller den GPS-satellit, der er mest
fordelagtig at benytte.
Vores forestilling er, at den teknologi, der samler egenskaberne for disse
teknologier, skal have samme form for transparens. Brugeren skal altså
ikke bekymre sig om, hvilken af teknologierne der er mest fordelagtig at
anvende i forhold til den situation, brugeren aktuelt befinder sig i.
Som afslutning på dette afsnit vil vi kort understrege, at der findes
andre positioneringsteknologier, der også kan opfylde vores krav til
lokationsbestemmelse. Vi har blot i dette afsnit ønsket at sandsynliggøre, at
vores positioneringsbehov kan dækkes med eksisterende teknologier.
Scenarier og use cases
Termen use case anvendes hyppigt inden for objektorienteret systemudvikling.
Andre specialer benytter termer som fx task og forretningsgang, men
termerne dækker i bund og grund over det samme, nemlig en selvstændig
og afsluttet arbejdsopgave som har ét formål i sig selv. Arbejdsopgaven
affødes typisk af en hændelse (også kaldet event).
Use cases skal formuleres meget generelt, idet de skal være meningsfulde i
forhold til alle tænkelige hændelser, der kan starte dem.
Et specifikt eksempel på en use case kaldes et scenarie. Når man i forbindelse
med feltarbejdet iagttager og identificerer arbejdsgange, er det netop
specifikke eksempler på arbejdsopgaver, man iagttager. Derfor er det ofte
analyser af scenarier, der ligger til grund for formuleringen af use cases.
Br ugergrænsefladen
Det mobile billetsalgssystem- et konceptuelt designfor slag 57
En af de vægtigste årsager til, at man definerer use cases, er, at de som
sagt startes af en hændelse. Et robust system er et system, der kan tage
hånd om alle tænkelige hændelser. Derfor er arbejdet med at definere use
cases en effektiv måde at sikre sig, at ens systemdesign gøres robust, idet
listen af use cases kan fungere som tjekliste, når man skal sikre sig, at
systemet kan håndtere alle relevante arbejdsopgaver.
En anden god (men ofte overset) grund til at definere use cases er, at de
tvinger designeren til at gruppere og rangordne arbejdsopgaver, hvilket er
en stor hjælp, når man skal designe brugergrænseflader.
Søren Lauesen (Professor ved ITU) skriver i [2000], at:
“Det mest springende punkt i systemudviklingen er nok at få alle
arbejdsgaver med og tage hensyn til dem under udviklingen. Det er
et af hovedområderne for alle udviklingsmetoder.”
Vi har stor respekt for nødvendigheden af, at vores systemdesign bliver så
robust som muligt. Desuden har vi følt det magtpåliggende at sikre kravet
om høj grad af brugervenlighed og fleksibilitet i GUI-designet. Det er derfor,
at vi gør os umagen at foretage denne identificering af arbejdsopgaverne
på destinationen.
En arbejdsopgave kan have et utal af varianter, og det vil være en
uoverstigelig opgave at beskrive alle disse. Derfor skal man alligevel holde
sig for øje, at disse varianter, i hvert fald til en vis grad, identificeres i
forbindelse med en implementering af vores system, idet de kan vise sig at
stille helt undtagelsesvise krav til systemet. [Lauesen 2000]
For at der ikke skal herske tvivl om, hvem eller hvad systemets aktører