Laboration 1: Design av applikation för uthyrning av maskeradkläder Syfte Uppgift Inledning Syftet med laborationen är att visa förmåga att kunna tillämpa en iterativ process för objektorienterad analys och design för mjukvaruutveckling, t.ex. enligt Agile Unified Process. En ny affär för uthyrning av maskeradkläder i Borås skall startas upp, ni har nu fått huvudansvaret att utveckla ett nytt IT-system som skall stödja verksamheten och dess kunder. Verksamheten fungerar i stort så att kunden ringer upp eller besöker en expedit i affären som i sin tur sköter bokningar, utlämning och återlämning av kläderna. ITsystemet är ämnat för hantering av kläder, bokningar, och fakturor. Systemet skall bestå av två delar, en expeditapplikation och en chefsapplikation. I första hand skall gränssnitten för klasserna i expeditapplikationens affärslager designas medan administratörsapplikationens är en extrauppgift. Expeditapplikationen För att få tillgång till expeditapplikationen måste expediten, logga in med sitt anställningsnummer och sitt lösenord. Därefter skall hon få välja om hon vill göra en av följande saker: 1 av 5 Bokning av kläder. Om expediten väljer att boka kläder skall en lista över tillgängliga kläder visas, för en angiven tidsperiod. Expediten väljer sedan ett eller flera klädesplagg för att boka. Expediten skall tydligt kunna se vilka kläder som hör ihop, dock är det valfritt om man vill boka ett helt kit eller enstaka kläder. Därefter anges kundens information och själva bokningen görs på en gång för alla kläder. Gick inte allt att boka får expediten gör en ny utsökning. Om bokningen gick igenom fås ett bokningsnummer som ges till kunden. Borttagning av bokning. Kunden anger sitt bokningsnummer och expediten tar bort bokningen. Utlämning av kläder. Kunden kommer till affären vid datumet för början av bokningen (eller senare datum inom det bokade intervallet), anger sitt bokningsnummer och expediten lämnar ut kläderna. Återlämning av kläder. När kunden är klar med kläderna, anger denna sitt bokningsnummer och återlämnar kläderna till expediten. Vid återlämnandet skapas en faktura som expediten överlämnar till kunden och som sparas i
Chefsapplikation (frivillig): systemet. Priset på uthyrningen beror på antalet faktiska dygn (påbörjade) och priset per dygn för respektive kläder. Expediten har även möjlighet att korrigera det totala priset på fakturan, med hänsyn till eventuella rabatter (p.g.a. slitna kläder) eller straffavgifter (för sent återlämnande). Chefsapplikationen skall ge full kontroll över registret. Samtliga data i registret skall kunna hanteras. Det skall vara möjligt att lägga till, ta bort och ändra data för kläder, bokningar och alla expediter. Samt söka på alla fakturor. Mer specifikt skall chefen kunna välja att göra något av följande saker: Hantering av expediter. Expediter skall kunna läggas till och lösenord ändras. Hantering av kläder. Nya kläder skall kunna läggas till och uppgifter för befintliga kläder ändras. Man skall kunna söka ut vilka kläder som inte har återlämnats i tid. Man skall även kunna söka ut bokningar (för ett visst datumintervall) på ett visst klädesplagg. Sökning av fakturor. Man skall kunna söka ut fakturor för ett visst datumintervall eller för en viss expedit. Datamodell Det finns data som systemet måste kunna hantera och som beskrivs kort här. Ett klädesplagg har en benämning och ett uthyrningspris (per dag). Det kan ingå som del i ett klädkit, men det är inte nödvändigtvis så. För en bokning måste systemet spara kundens namn, telefonnummer och epostadress, den tilltänkta starttiden och återlämningstiden samt vem som skapade bokningen. För en faktura måste systemet spara motsvarande bokning, de faktiska start och återlämningstiderna samt totalpriset. För expediter och chefer måste systemet spara anställningsnummer, namn, lösenord och roll (expedit eller chef). 2 av 5
Krav Då syftet med laborationen är att visa förmåga att kunna tillämpa en iterativ process för objektorienterad analys och design för mjukvaruutveckling så behöver ett antal olika artefakter lämnas in (ordningen på kraven är inte ordningen artefakterna lämpligen skapas i, se istället den finfördelade iterativa agila OOAD-processen under Tips nedan): 1. Användningsfall för expeditapplikationen. Dessa behöver i slutänden vara så pass förfinade att det finns ett huvudflöde med numrerade steg i varje. 2. Domänmodell med de noterbara konceptuella klasserna i problemdomänen och relationerna mellan dessa. 3. Systemsekvensdiagram för huvudflödena (happy path) av respektive användningsfall som identifierar de systemoperationer som finns. 4. Minst ett systemoperationskontrakt för en av de identifierade systemoperationerna. 5. Ett designsekvensdiagram för var och en av alla systemoperationer i huvudflödet för Bokning av kläder och Återlämning av kläder som fördelar ut ansvaret för respektive operation till lämpliga klasser. 6. Ett påbörjat C# projekt (av typ class library) för expeditapplikationens affärslager där de klasser med metoder, properties och attribut som används i designsekvensdiagramen finns med. Det behöver inte finnas någon funktionalitet i metoderna utan det är gränssnitten hos och mellan klasserna som är huvudsaken. 7. Designklassdiagram över de klasser som skapats för systemoperationerna i huvudflödet för Bokning av kläder och Återlämning av kläder. Kan med fördel skapas i och med Visual Studio. Expeditapplikationen skall vara skiktad i tre lager, men ni gör bara gränssnitten inom affärslagret och mellan det och presentationslagret, det vill säga: Ett presentationslager. (T.ex. Console application eller WPF application.) Behöver inte lämnas in. En enkel Console application ihop med dummy implementationer av metoder i affärslagret kan/skulle kunna användas för att se om designen av affärslagret skulle kunna fungera i praktiken. Ett konkret affärslager, men utan ifyllda metoder. (Class Library) Skall lämnas in. Ett datalager. (Class Library) Behöver inte lämnas in. Affärslagret och dess gränssnitt uppåt och internt skall vara objektorienterat, d.v.s. det ger tillgång till objekt som representerar viktiga saker eller koncept i applikationens domän. Diagrammen som krävs eller behövs kan göras för hand eller i lämpligt program (t.ex. Visio). Lösningen skall vara uppdelad i lämpliga klasser. Varje abstrakt klass eller interface skall vara definierad i en egen fil. Arv och polymorfism skall utnyttjas där så är lämpligt. 3 av 5
Klasser och metodskelett skall vara väl kommenterade och även i övrigt ska koden vara prydlig. De publika metoderna i affärslagrets gränssnitt får endast returnera objekt/värden av specifika typer eller en uppräkning av objekt av en specifik typ (t.ex. List<Foo>, IEnumerable<Foo> eller IQueryable<Foo>). Helt ospecifika typer som t.ex. object får inte förekomma i gränssnitt. Tips Visual Studio kan skapa designklassdiagram direkt från C# kod. Dessa skapas och läggs till i ett projekt via Add->New Item och finns under C#->General i dialogen som öppnas. Klasser kan dras och släppas i diagrammet, hur metoder och attribut visas kan justeras. Det är också möjligt att skapa och utforma en klass i diagrammet och automatiskt skapa ett kodskelett för den. Följande steg är ett förslag på en finfördelad iterativ agil OOAD-process: 1. Gör ett utkast till domänmodell från problembeskrivning och användningsfall. 2. Välj ett användningsfall och förfina det om så krävs. 2.1. Gör ett systemsekvensdiagram av (ett scenario i) användningsfallet för att hitta systemoperationer, förfina domänmodellen. 2.2. Välj en systemoperation och gör ev. ett systemoperationskontrakt, förfina domänmodellen, och påbörja designarbetet: 2.2.1. Gör designsekvensdiagram, tilldela ansvar, osv. för klasser i affärslagret som behövs för att utföra systemoperationen. 2.2.2. Sammanfatta i designklassdiagram. Dessa kan ev. istället genereras från koden efter steg 2.2.3. 2.2.3. Skriv/utöka ett C# projekt (av typ class library) för applikationens affärslager där de klasser med metoder, properties och attribut som används i designsekvensdiagramen finns med. Det behöver inte finnas någon funktionalitet i metoderna utan det är gränssnitten hos och mellan klasserna som är huvudsaken (men kan ev. vara till hjälp för att testa det ni tänkt ut). 2.2.4. Om ny kunskap om domänmodellen och/eller användningsfallsmodellen framkommit uppdatera dessa. 2.3. Repetera steg 2.2 för fler systemoperationer. Repetera steg 1-2 för fler användningsfall. 4 av 5
Redovisning Handledning Examinationer Skiktningen av lösningen underlättas genom att lägga varje lager i ett eget projekt inom lösningen (solution). Projekten skall ha referenser till varandra där det behövs, t.ex. känner användargränssnittsprojektet till affärslagerprojektet och affärslagerprojektet känner till datalagerprojektet. Däremot skall inte användargränssnittet referera direkt till datalagerprojektet (men projektreferensen kan ändå behövas p.g.a. det indirekta beroendet via affärslagret). För att lägga till referenser, högerklicka på projektet och välj Add Reference och klicka sen på Projects och välj önskat projekt. Ni skall arbeta i grupper om 3-4 studenter i varje. Ni ansvarar själva för att finna arbetskamrater att forma en grupp med och meddela detta via Doodle-sidan för gruppval som det finns en länk till på laborationens sida i PingPong. Uppgiften redovisas enligt listan i avsnittet Krav ovan. Packa ihop hela biblioteket med C# lösning och dokument med Zip och ladda upp till PingPong. Om arkivet försvinner vid inlämning, se till att gå igenom det och ta bort eventuella.exe eller.dll filer och försök igen. I en C# lösning behöver inte bin/ och obj/ biblioteken i respektive projekt tas med alls. Om så görs bör det inte finnas några.exe eller.dll filer kvar i arkivet. Det finns 2 block av handledningstider utlagda i KronoX. Mängden tid är satt så att varje grupp får 2 handledningstillfällen under laborationens gång. Ni kan endast utnyttja en tid per grupp och block. Boka handledningstid via doodlelänkarna i PingPong (som ligger på inlämningsuppgiftens sida). Varje laborationsmoment examineras vid 3 tillfällen. Två av dessa tillfällen finns schemalagda under kursens gång (eller strax efter) och det sista i början av juni. 5 av 5