Introduktion till Systemering - Högskolan i Gävle
Introduktion till Systemering - Högskolan i Gävle
Introduktion till Systemering - Högskolan i Gävle
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Per Aspenberg ©<br />
Göran Sundberg ©<br />
Kurskompendium <strong>Introduktion</strong> <strong>till</strong> <strong>Systemering</strong><br />
MODELLERING AV GRÄNSSNITT<br />
I funktions- & processanalysen bestäms det blivande datasystemets funktionalitet genom<br />
exempelvis att ett antal aktörer definieras. Deras önskemål om funktionalitet beskrivs sedan i<br />
olika användningsfall, som i sin tur kan dokumenteras som affärsprocesser på detaljnivå där<br />
interaktionen med datasystemet framgår konkret. På detta sätt beskrivs systemets önskade<br />
funktionalitet, alltså vad IT-stödet skall leverera.<br />
Det är svårt att dra en skarp gräns mellan denna kravanalys och arbetet med de mer specifika<br />
designlösningar som skall realisera systemets interaktion med användaren. Från<br />
processanalysen framgår kanske t ex att man i ett visst arbetsmoment önskar att via<br />
datasystemet få fram låntagnummer för en låntagare utifrån att ange namnet på personen. Då<br />
är detta en del av den fasta kravbilden, om än på mycket detaljerad funktionalitetsnivå.<br />
Utformningen av det formulär på skärmen där låntagarens namn skall matas in och där<br />
låntagarnummer sedan skall presenteras är en mer öppen designfråga som troligen aldrig<br />
hamnar under rubriken "kravanalys". Man använder sig vanligen också här av annan<br />
arbetsteknik. Det vanliga vid modellering av GUI-aspekter är att ta fram prototyper för<br />
experimenterande eller försökvis användning. Det ligger sålunda nära <strong>till</strong> hands att placera<br />
utformning av användargränssnitt i ett "annat fack" än den mer teoretiskt analyserande<br />
beskrivningen av önskad grundfunktionalitet hos datasystemet.<br />
Vilka är då de objekt som skall modelleras i gränssnittsmodelleringen? En lämplig metod för<br />
att hitta dessa är en genomgång av alla användningsfall-beskrivningar. Om dessa är<br />
upprättade som aktivitetsdiagram med en särskild "simbana" för datasystemet kan man hitta<br />
de situationer där användaren kommunicerar med systemet (via menyval, frågeparametrar<br />
eller indata <strong>till</strong> databasen) respektive där systemet kommunicerar med användaren (via<br />
menyer, svar <strong>till</strong> skärm på urvalsfrågor, rapporter, OK/fel-meddelanden).<br />
För just Access-miljö kan man enkelt skaffa en egen praxis vilken typ av interaktivitet i<br />
aktivitetsdiagrammet som motsvarar vilken storhet i Access, t ex enligt nedanstående<br />
uppställning:<br />
ÖNSKEMÅL FRÅN MOTSVARAR I ACCESS<br />
---------------------------------------------------------------------------------------------------------------<br />
Val av systemfunktionalitet Användare Menyformulär plus makros<br />
Framtagning av uppgift ur databas Användare Tabeller, frågor (egentligen SQL)<br />
Presentation av d:o på skärm Användare Formulär kopplat <strong>till</strong> fråga<br />
Presentation i listform Användare Rapport kopplad <strong>till</strong> fråga<br />
Inmatning av data <strong>till</strong> databas Användare Formulär för inmatning<br />
Korrigering av inmatning Systemet Felmeddelande/ fältkontroll i formulär<br />
---------------------------------------------------------------------------------------------------------------<br />
Därmed borde man sålunda bl a kunna hitta de formulär (meny och data) och rapporter som<br />
behöver prototypas mot användare.<br />
47
Change language