1 Mjukvaru-utveckling av interaktiva system God utveckling av interaktiva system kräver abstrakt funktionell beskrivning noggrann utvecklingsmetod Slutanvändare bör involveras i behovsanalysfasen under utvecklingens gång då kan man skilja på oumbärliga egenskaper och frivilligt valbara egenskaper

2 Betydelsen av abstraktion utvecklingsprocessen Abstrakt formulerade behov möjliggör diskussion om systemet innan det är byggt hittandet och definierandet av generella egenskaper som alla interaktiva system bör ha ökar möjligheten till återanvändning av moduler

3 Spelet Min: ett studieexempel två spelare sju tändstickor en eller två tändstickor plockas bort varje omgång den som plockar sista vinner

4 Enklast möjliga system tändstickorna visualiseras på skärmen verktyg för att ta bort dem tillhandahålls saknar: stöd för att komma ihåg vems tur det är kontroll att reglerna följs (max två stickor etc.) kontroll för när och vem som vinner

5 Generella egenskaper hos interaktiva system system-tillstånd operationer restriktioner funktioner som måste evalueras presentation av systemets tillstånd (och via denna invänta ny input (gäller bara DM))

6 Abstrakta arkitekturer Återanvändbara komponenter som kan ärvas: is_a-strukturer eller adresseras: has_a-strukturer

7 is_a-strukturer formar hierarkier subklasser ärver men specialiserar exempel: Game -> Two_Player_Game -> Min problem: finns alltid alternativa klassificerings-sätt. tumregler: om två klasser delar många attribut – abstrahera dessa till en superklass om en klass bara har en subklass är distinktionen onödig

8 Tillstånd och tillståndsrum [1] Definitioner: tillstånd: en mängd specifika namn-värde- mappningar vid en viss tidpunkt tillståndrum: mängden av alla möjliga namn- värde-mappningar

9 Tillstånd och tillståndsrum [2] Z-schema signaturdel variabler och deras typtillhörigheter predikatdel logiska begränsningar hos signaturdelens variabler måste alltid uppfyllas/vara sanna Ett schema är det tillståndsrum som spänns upp av alla ”godkända” värden på variablerna

10 Z-schema Läs mer om syntax i boken!

11 has_a-strukturer Klasser som typer skapar aggregat/ container-klasser

12 skillnader mellan is_a och has_a-strukturer has_a-strukturer kan uppdateras när som helst variablers värden kan utan problem förändras is_a-strukturer kan inte uppdateras efter att en instans av klassen skapats eftersom förändringar i klassers struktur påverkar subklasser

13 Förfining (refinements) [1] från abstrakt representation till konkret implementation behåller systemets abstrakta egenskaper men möjliggör tillägg av egenskaper som kan underlätta för slutanvändaren och programmeraren. användarorienterad design

14 Förfining [2] operationsförfining dataförfining

15 Förfining [3] operationsförfining utöka operationens domän ex: så att ”ta-operationen” klarar av att hantera fallet när spelare vill ta fler än två stickor säkerställa operationens determinism ex: se till att det finns ett garanterat slut på en tänkbart oändlig exekveringsslinga

16 Förfining [4] dataförfining berika representationen av variabler ex: låt tändstickorna se ut som en mängd tändstickor och inte som en siffra Men: viktigt att den berikade representationen entydigt adresserar de underliggande abstrakta representationerna ex: tändstickor får ej skymma varandra på skärmen

17 Mer om dataförfining [1] åtkomstfunktionen ”access” access: C -> A vanliga krav: otvetydig surjektiv

18 Mer om dataförfining [2] homomorfism - garanterar att de abstrakta och de konkreta tillstånden aldrig blir inkonsistenta

19 Praktiska arkitekturer [1] Separerar applikationsspecifika och återanvändbara komponenter Kan göras både inom is_a och has_a- arkitekturer is_a => bibliotek av återanvändbara klasser has_a-separering sker under exekvering, ex: client-server relationer mellan objekt

20 Praktiska arkitekturer [2] Kända tillvägagångssätt: Dialoghanterare Modell-vy-arkitekturer Modellbaserade arkitekturer Verktygslådor Yt-interaktion Läs om detaljerna i boken!