DVGB05 Grafiska användargränssnitt. Mjukvarudesign med Model-View-Controller

Transkript

1 DVGB05 Grafiska användargränssnitt Mjukvarudesign med Model-View-Controller

2 Skärmbildsinvarianter Studera bilden Anteckna vilka regler som gäller för visning av verktygen Dessa regler måste upprätthållas av programmet 2

3 Skärmbildsinvarianter Stängd dörr får inte stängas Knappen Stäng dörr inaktiveras vid stängd dörr Annars är knappen Stäng dörr aktiv Öppen dörr får inte öppnas Knappen Öppna dörr inaktiveras vid stängd dörr Annars är knappen Öppna dörr aktiv Rullningslisten ska alltid visa dörrens läge Rullningslisten får inte dras medan dörren rör sig Radioknapparna ska alltid återspegla dörren Stängd/Öppen intryckt dörren är stängd resp. öppen Stängs/Öppnas intryckt dörren är i angiven rörelse 3

4 Skärmbildsinvarianter Regler för GUI - skärmbildsinvarianter Stängd/öppen dörr får inte stängas/öppnas Stängd/öppen dörr ska återspeglas i radioknapparna 4

5 Invarianter och kopplingsgraf Kopplingsgrafen visar beroenden mellan programdelarna En riktad graf mellan påverkande och påverkade noder Engelsk term: Connectivity Graph Invarianterna måste upprätthållas Av alla operationer som kan påverka dem Stäng dörr Passivera Stäng Aktivera Öppna Tryck in Stängd Öppna dörr Motsvarande 5

6 Invarianter och kopplingsgraf Kopplingsgrafen visar beroenden mellan programdelarna En riktad kant mellan påverkande och påverkad nod Invarianterna måste upprätthållas Av alla operationer som kan påverka dem Stäng dörr dimma ner Passivera Stäng Stäng dörr Öppna dörr Aktivera Öppna aktivera Tryck in Stängd aktivera aktivera Öppna dörr Motsvarande Ej hållbar lösning Stängd Öppen se grafen Stäng dörr dimma ner 6

7 Tolkning av kopplingsgrafen Kopplingsgrafen visar hur en programvarudel (nod) påverkar och påverkas av andra noder Varje sådant beroende skapar en oönskad koppling Gör det svårare att konstruera lösningen, varje dels uppgift är beroende av andra delar, det kan bli svårt att dra ansvarsgränser förstå lösningen, förståelsen av en del är kopplad till förståelse av andra delar förändra, en förändring griper in på flera stället Önskar lösningar med få kopplingar helst inte kopplingar kors och tvärs kan skapas genom modularitet 7

8 Kopplingsgrad Kopplingsgraden g k definieras som antalet riktade kanter / antalet noder g k = k / n Kopplingsgraden i exemplet är g k = 8 / 4 = 2, (15/5 = 3) Kopplingsgraden är ett uttryck för komplexitet Om många delar är logiskt beroende av många andra Hög kopplingsgrad tyder på spagetti -logik En förändring på ett ställe påverkar många andra Försvårar underhåll när systemet blir större Tumregel: En kopplingsgrad under 2 verkar hanterbar 8

9 Problem GUI kan förändras för att bli mer användarvänligt Logiken kan behöva uppdateras för att klara av nya krav Vill inte bygga om hela tillämpningen så fort en liten förändring inträffar Får ej bryta skärmbildsinvarianterna Kan vi få ner kopplingsgraden? 9

10 Lösning MVC Härrör från Smalltalk Konstruktionsmönster - ramverk Separering av Modell - Underliggande informationsmodell (logik) Vy - GUI (utmatning, mätdon) Kontroller - Kontroll av indata (inmatning, styrdon) Objektorientering = klasser Observer/Observable-mönstret 10

11 Lösning MVC Ett MVC-organiserat program fungerar som följer: Användaren interagerar med vyerna och kontrollerna När användaren manipulerar en kontroll skickas ett meddelande om att förändra datan i modellen som kontrolleras av kontrollen När data i modellen ändras, antingen av interna beräkningar, användarinteraktion eller något annat, skickas meddelanden till de associerade vyerna om att visa de nya värdena för användaren 11 Bild från:

12 MVC Normalt påverkar inte en kontroller direkt någon vy, förutom sig själv om det rör sig om en view-controller som en slider. En kontroller påverkar modellen och modellen uppdaterar vyerna. På så sätt upprätthålls en viktig egenskap Det finns inget viktigt på skärmen som inte finns representerat i modellen 12

13 MVC-Triangeln Observatör Observerbar 13

14 MVC - Översikt Vy Presentation Läs av tillstånd, getters Uppdatering, Initiering av GUI Användaren begär förändringar av modellen Meddela förändrin g Val av vy Modell Affärslogik Kontrollant Användarkontroll Uppdater a tillstånd, setters 14

15 Scenario - Logisk vy 1 - Användaren utför en åtgärd 2 - Kontrollern tolkar händelsen och begär en förändring på modellen 3 - Modellen förändrar sitt tillstånd och informerar vyn om förändringen notifychanged() modelchanged() 4 - Vyn frågar modellen om dess tillstånd och förändrar sig därefter getstate() 5 - Användaren ser effekter av åtgärd User sees uses Delbild från The Smalltalk MVC paradigm with pluggable views av Tong Sin Yin, Chow Pui Yee 15

16 Modell Spindeln i nätet Representerar & stödjer kärnan av problemet Affärslogiken Känner inte till mekanismerna som exponerar den för resten av världen Mjukvaruutecklare modellerar & implementerar oftast denna del först Kommunicerar med vyer Visa värdeförändring -> samtliga vyer meddelas (multicast) Kommunikation sker med händelser (Observable) 16

17 Modell (forts) Modellens ramverk skickar händelser till intresserade vyer Kärnan av modellen känner inte till vyerna Ramverket har API för att förändra och avslöja modellens tillstånd Behöver inte styras av kontrollern i GUI Kan styras av annan kontroller i annat GUI Modell som representerar ex. hårdvara Måste fortfarande meddela alla intresserade vyer 17

18 Vy Hanterar utdata Synligt för användaren Mätdon (Styrdon) Visar modellens tillstånd Fönster grafik text Novis- eller expertvy Bilder från 18

19 Vy (forts) Känner till modellen & kontrollern Visar värdeförändringar i modellen (Observer) Skickar användarförändringar av modellen till kontrollern (delegering) Hanterar generell uppdatering (utan förändring av modellen) exempelvis initiering av GUI genom att anropa modellen direkt Innehåller information om vyn (ex. storlek, plats, egenskaper, beteende, representation etc.) 19

20 Kontroller Hanterar indata från användaren som ska påverka modellen Mus, tangentbord Bearbetar händelser från användaren och anropar modellen Kontroll av indata - modellens villkor Känner till modellen & vyn Förändrar modellens status Knapptryck -> modellen anropas som reagerar därefter Nytt värde inmatas -> modellen anropas som uppdaterar med det nya värdet Kan även förändra vyn (ex. GUI-inställning) Vy och kontroll Kan kombineras Starkt kopplade (användarsynpunkt) 20

21 Kopplingsgraf - MVC Stäng dörr dimma ner Öppna dörr dimma ner Stängd aktivera Öppen aktivera Kopplingsgrad = 6/5=1,2 8/6=1, Hållbar lösning Dörrmodell Stäng dörr 21

22 Observer-mönster Definierar ett 1-till-m beroende mellan objekt så när ett objekt förändrar tillstånd, blir alla intressenter varse & uppdateras automatiskt Används för att koppla bort den observerade från de som observerar, den observerade behöver lite information för att meddela observerande Java-listeners,.NET (delegates) & Qtsignal/slots 22

23 Observer-mönstret Observer - Vy Godtyckligt objekt som vill bli varse om tillståndsförändringar i annat objekt Observable - Modell Objekt med ett intressant tillstånd & där andra objekt kan registrera sitt intresse 23

24 Exempel - Observer Controller BankAccount AccountView SummaryView deposit(int) setchanged() notifychanged() modelchanged() getbalance() modelchanged() getbalance() 24

25 Fördelar/Nackdelar - Observer + - Mönstret tillåter modellen att meddela multipla vyer Observer s kan (av)registrera sig själva Kan resultera i stort meddelandeflöde 25

26 Distribuerat system Mellanvara DCOM,COM+ RMI,CORBA 26

27 DS - systemstruktur JDBC, ODBC DCOM,COM+,RMI,CORBA 27

28 MVC - Problem & nackdelar Svårt att särskilja rollerna (logisk teknisk) Vy & kontroller samma objekt Qt, VB etc. IDE stödjer inte MVC på ett tillfredsställande vis Gränserna kan flyta ihop Svårt att se skillnad på GUI-logik & modell-logik Omständligt vid pyttesmå projekt Problem kan uppstå vid interface-förändringar Bakåtkompatibilitet Mycket trafik genereras mellan vy & modell även då små förändringar sker Problem speciellt vid distribuerade tillämpningar 28

29 MVC - Fördelar Flera olika utformade GUI till samma (ovetande) modell Utveckla modell och GUI parallellt eller separat Problemområden separeras tydligt Klarare design & kod Återanvända delar av systemet 29

30 MVC Fler fördelar Mjukvaran kan delas upp i mindre moduler Inkapsling av funktionalitet Separata interna förändringar av M, V, C är lättare att utföra Lätt att byta ut komponenter M, V eller C helt respektive plugga in nya GUI Modellens meddelanden når ut till samtliga vyer Förenklar distribution Klient/Server-lösning (proxy mellan GUI & modell) 30

31 Konstruktionsmönster Mönstervarianter - modell meddelar vyer Typ 1 - Fire and forget modellen initierar ett objekt innehållande förändringarna som undersöks närmare i vyn Modell - model.notifychanged(event e), vy.modelchanged(event e) Event e - innehåller förändringarna som vyn får läsa av - e.getchange Ok vid distribuerade modeller Typ 2 - Modellen meddelar förändring sedan får vyn fråga modellen om vad som egentligen hände Modell - model.notifychanged, vy.modelchanged Vy - model.getchange Typ 3 Hybrid Ex. labb 1, 3. Unika signaler som är informationsbärare + event ex. signalgasändrad(int nygas) 31