1. Klädlådor I byrån finns en strumplåda och en kalsonglåda. Objektmodellera och ge exempel på användning. Strategi: Ställ upp krav i textform Omvandla kraven till use cases Hitta klasser, inkl domänklasser Gör UML-diagram Sekvensdiagram Klassdiagram

Kraven i textform Kunna öppna och stänga byrålådorna. Kunna lägga in i och ta ut saker ur lådorna Kunna ta ut två matchande strumpor

Use case 1: Öppna byrålåda Precondition: Ingen Programmet skriver en lista med saker som användaren kan göra och ber denne välja ett alternativ genom att skriva numret för detta. Användaren väljer alternativet “Öppna byrålåda” Programmet frågar vilken låda som skall öppnas. Användaren skriver lådans nummer. Programmet ändrar lådans tillstånd till “öppen” och uppdaterar listan över möjliga alternativ. Programmet visar återigen en lista med alternativa handlingar och ber användaren välja en. Postcondition: Öppen byrålåda

Use case 2: Lägga in något i en byrålåda Precondition: Det finns en öppen byrålåda. Programmet visar en numrerad lista med alternativa handlingar för användaren. Användaren väljer “Lägga in något i byrålåda”. Programmet frågar i vilken låda något ska läggas. Användaren skriver lådans nummer. Programmet visar saker som kan läggas i lådan. Användaren väljer ett av alternativen. Programmet överför det valda från spelarens lista med saker till lådans och visar återigen en lista med handlingar och ber användaren välja en. Postcondition: Det finns något i en byrålåda.

Use case 3: Finn två matchande strumpor. Precondition: En öppen låda finns. Programmet visar en lista med alternativa handlingar och ber användaren välja en. Användaren väljer “Ta ut något ur byrålåda”. Programmet frågar vad som skall tas ut. Användaren väljer en strumpa. Programmet frågar efter en handling. Användaren väljer “Finn matchande strumpa”. Programmet letar igenom den öppna lådan efter en matchande strumpa. Ifall den inte hittar någon letar den igenom övriga lådor efter en matchande strumpa, vilken överförs till användaren. Postcondition:

Klasser Skriv upp alla substantiv i spelet: Strumpa, Kalsong, Sak, Spelare, Byrå, Låda Byrålåda är helt enkelt en vektor med saker Sak kan vara en egen klass, men strumpa och kalsong behöver inte vara egna klasser. Byrå har internt en vektor med lådor, en vektor med tillstånd öppet/stängt för lådorna.

UML I: Sekvensdiagram användare :UI :Spel :Byrå :Låda görAlt() {ta ut något} taUtUrByrå() visa Låda() Be användare välja vad som ska tas ut get() görAlt() {välj sak} plocka() remove() Be användare välja alternativ görAlt() {välj handling} matchande Strumpa() visa Låda() plocka()

UML II: Klassdiagram 1 2 1 * Byrå ArrayList Sak lådor Huvudprogram +öppnaLåda (int n) : void +stängLåda +lägg(int låda, Sak sak) : void +plocka(int låda, int sakIndex):Sak +boolean[] lådaÖppen; ArrayList Sak +String namn; +String typ; +String färg; lådor Huvudprogram Användar- gränssnitt Här kan “refactoring” löna sig

Kodexempel: metoden öppnaLåda() /** Öppnar en låda * * Postcondition: låda n är öppen ifall n är ett tillåtet tal, annars * kastas ett undantag. */ public void öppnaLåda(int n) throws Lådundantag { if( n < antalLådor && n >= 0 ) lådaÖppen[n] = true; else throw new Lådundantag(“Försök att öppna otillåten låda”); }

Tänka på: XP eller full design? korrekthet och tillräcklighet Korrekthet: Modularisera, kolla invariants flexibilitet och återanvändbarhet.

2: Personnummerfält Skapa en komponent med en rubrik och ett fält och som vid returtryckning kontrollerar att person- numret är rätt och fyller i bortglömt bindestreck. Strategi: 1 Ställ upp krav i textform 2 Omvandla kraven till use cases 3 Hitta klasser, inkl domänklasser 4 Gör UML-diagram a) Sekvensdiagram b) Klassdiagram

Kraven i textform Grafisk komponent: Ovan en rubriklabel, under ett textfält. Komponenten skall lyssna på händelser som returtryckning genererar. Komponenten skall kontrollera att personnummer är rätt ifyllt. I textfältet skall användaren bes fylla i personnummer samt upplysas om felaktigt personnummer.

Use case 1: Fylla i personnummer Precondition: Ingen Användaren skriver in ett personnummer och trycker på retur. Personnummerrutan kontrollerar personnumret och fyller i eventuellt saknat bindestreck. Ifall personnumret är korrekt visas detta i textfältet. Annars visas en text med upplysning om felaktigt personnummer.

Klasser 1. Use case innehåller klasserna Textfält, Personnummerruta 2. Dessutom innehåller kraven klasserna Rubriklabel, Lyssnare, Kontroll I en komplicerad situation kan det vara bra att ha en egen klass som svarar för kontroll/parsningav personnummer, här blir det en metod. Likaså behöver vi ingen speciell lyssnarklass, vi låter komponenten vara lyssnare också.

UML I: Sekvensdiagram Användare textfält:JTextField :Person-nummerruta :Person-nummerruta (Lyssnare) {returtryckning} actionPerformed() parsaPNummer() setText()

UML II: Klassdiagram Panel Label Personnummerruta textfält JTextField ActionEvent Designmönstret “Observer” Observer Observee

3: Mejeriinköp Kylarna i butiken behöver ett planeringsprogram för att ta in lagom mycket varor. Objektmodellera! Skissa en simulering med programmet! Strategi: 1 Ställ upp krav i textform 2 Omvandla kraven till use cases 3 Hitta klasser, inkl domänklasser 4 Gör UML-diagram a) Sekvensdiagram b) Klassdiagram

Kraven i textform Det ska finnas varor med bäst-före-datum. Det ska finnas en/flera kylar med en max-volym. Programmet skall bestämma när man ska rensa. Programmet skall ha tillgång till inköpsdata och produktdata. Programmet skall kunna avgöra hur mycket man köper in av varan vid varje inköpstillfälle. Programmet skall bestämma en lagom fyllnadsgrad i kylarna. Programmet skall innehålla en databas av varor med karaktäristika.

Use case 1: Lägga in vara Precondition: Ingen Användaren fyller i antal och typ av vara. Programmet fyller på kylen, samt visar uppdaterad databas alternativt protesterar mot otillåtna indata.

Use case 2: Rensa ut gammal vara Precondition: Ingen Användaren väljer vara och klickar på “rensa gammal”. Programmet rensar ut kyl på gamla varor och visar uppdaterade data.

Use case 3: planera inköp Precondition: Ingen Användaren väljer typ av vara samt klickar på planera inköp. Planeraren visar det antal varor som ska köpas.

Klasser Use case innehåller klasserna Kyl, Planerare, Databas, Vara Dessutom innehåller kraven klasserna Databaspost, Lyssnare Hjärnstorm visar att en kö behövs för varorna i kylarna. Dessutom behövs ett grafiskt gränssnitt.

<<singleton>> UML II: Klassdiagram Kyl +double fyllnadsgrad; +double önskadFyllnadsgrad; Queue 1 * Vara Typ typ; String märke; double volym; Date bästFöre; * Databas Post 1 Planerare (Lyssnare) <<singleton>> ArrayList varutyper; GUI <<singleton>>

Skapa ett sekvensdiagram Välj ut något av de tidigare use cases och gör ett sekvensdiagram. Tänk på att: välja tydliga namn på metoder beskriva metoderna med pre- och postconditions och invariants