1. Bra och dåliga tasks (6p)

Förklara vilka av följande 6 tasks som är bra/dåliga. Motivera även varför de är bra/dåliga.

1. Lägga in en patientens personuppgifter.

2. Lägga in orsak till en patients sjukhusvistelse och anhöriga/kontaktperson.

3. Skriva ut en patient.

4. Hitta ledig sängplats och tilldela detta till en patient.

5. Ändra en patients uppgifter.

6. Planera framtida vårdplan, hur patienten ska behandlas i framtiden.

2. Klassdiagram och use case (4p)

a) När och varför skapar man framförallt use case-diagram? Jämför detta med klassdiagram, vad är den största skillnaden på

hur man använder dem?

b) Till vilket av use case- och klassdiagram kan man lättast koppla ett sekvensdiagram?

c) Vilken av de tre diagramtyperna är lättast för kunden att förstå och validera?

d) Vilken av de tre diagramtyperna är lättast för en utvecklare att förstå och verifiera?

Frågorna är öppna och det finns mer än ett rätt svar. Det viktigaste är attt motivera sitt svar väl.

Svar/rättningsmall, uppgift 1:

1. Bra task. Sluten och lagom stor samt görs i ett svep.

2. Skulle kunna vara dålig eller bra, mest dålig. Dålig för att den är FÖR specifik, skulle kanske

vara en del av task 1 eller en sub task till task 5. Borde definitivt delas upp i två tasks.

Bra för att den sluten, skall göras ofta och kanske ofta görs efter

en eventuell läkarundersökning (dvs efter att task 1 gjorts).

3. Bra, sluten task som även visar på problemet med vad som ska göras med en patients

uppgifter då de skrivs ut (de ska sparas, men var/hur, etc.)

4. För stor, borde delas upp i två tasks. Hitta ledig sängplats skall vara en enskild task då användaren själv

måste få bestämma vad denne ska göra med informationen. Till exempel passar ju inte alla sängplatser alla patienter

beroende på sjukdom etc.

5. En bra task, borde självklart ha mer detaljerade sub tasks (typ task 2). Sluten och viktig för systemets prestanda.

6. Viktig uppgift, men alldeles för stor och vag. Bör vara mer specifik, en framtida vårdplan bör ju kunna skötas av systemet

men borde ses som en personuppgift. Alltså dålig, vag och ej sluten, går ej alltid att göra i ett svep.

En poäng per rätt beskriven task. Motiveringarna det viktigaste för att få poäng.

Svar/rättningsmall, uppgift 2:

a) Use case-diagram används för att undersöka specifika användningsfall som kan uppstå då systemet används.

Man väljer oftast ut specialfall, då något kanske blir fel eller är oklart. Man väljer ofta även några generella användningsfall för att

visa hur de går till. Klassdiagram däremot beskriver hela systemets design, hur alla klasser kommunicerar med varandra, inte hur

vissa klasser kommunicerar i vissa fall. Klassdiagram är således mer generella.

b) Use case-diagram beskrivs enkelt med sekvensdiagram, eftersom sekvensdiagram också beskriver specifika användningsfall

fast med tidsaspekt. Självklart kan sekvensdiagram även ge exempel på hur olika klasser kommunicerar och kan därmed

användas för att hitta kommunikationslänkar i klassdiagram.

c) Use case-diagram är nog lättast, om man utgår från att kunden ej har IT-vana. Use case-diagram är tydliga och intuitiva och lätta

för lekmän att förstå, skapa själva eller kommentera. Klassdiagram i sin tur kan vara svåra eller omöjliga att förstå om man inte

har programmeringsvana. Sekvensdiagram skulle kunna utnyttjas i samarbetet med kunden, men är nog alltför detaljerade.

d) Utvecklaren har nog lätt att förstå alla diagrammen ovan, de har ju alla tre olika användningsområden i utvecklingsarbetet.

Som underlag för programmering måste klassdiagrammet anses vara bäst. Vad gäller verifieringen är nog sekvensdiagrammet

tydligare och visar vad som är fel i de fall som går åt skogen.

En poäng per rätt svar, motiveringen viktigast även här. Självklart kan andra svar än de ovan ge poäng om motiveringar

och antaganden är bra och rimliga.