I och med att hela kursen varit uppbyggd kring iterationer kan vi främst dra slutsatser om den struktur och ordning som Scrums artefakter bidrog med un- der iteration två. Vi kan fastställa att gruppen presterat mycket bra med hjälp av ramverket och dess komponenter. I jämförelse med iteration ett blev det en märkbar skillnad i vad vi lyckades producera tillsammans trots att andra variab- ler också kan ha bidragit till detta, som exempelvis inlärningskurvan av PySide. Majoriteten av gruppen har samma känsla: många av Scrums artefakter bidrog starkt till en betryggande ordning och säkerhet i att vi skulle kunna leverera någonting innan iterationens slut. Mycket tack vare att vi spårade progressionen under tiden.
A
Python för prototyputveckling
En utredning skriven av Jonatan Branting, konfigurationsansvarig i Grupp 8 i kursen TDDD96, vid Linköpings universitet.
A.1
Inledning
Valet av programmeringsspråk är en av de viktigaste beslut som kan tas i början av ett projekt. Fel programmeringsspråk kan leda till buggar, förseningar och generellt sämre kodkvalitet. Det finns tyvärr inte heller något programmerings- språk som passar i alla lägen. Därför är det viktigt att kunna identifiera vilket språk som skulle passa bäst för det givna projektet. Att utveckla en prototyp av ett program medför ytterligare krav på språket; det måste vara lätt och snabbt att testa nya idéer och koncept. Utöver det måste språket ha en relativt låg inträdeströskel, så teamet kan komma igång med utveckling på kortast möjliga tid.
A.1.1 Syfte
Syftet är att undersöka vare sig Python lämpar sig som programmeringsspråk vid prototyputveckling av ett nytt program utav en ny, oerfaren grupp utveck- lare.
A.1.2 Frågeställning
Frågeställningen som utredningen avser att behandla är följande:
• Var Python rätt val som programmeringsspråk för vårt kandidatsprojekt?
A.2
Bakgrund
När vi valde programmeringsspråk för projektet enades gruppen bakom pro- grammeringsspråket Python, med motiveringen att alla hade tidigare använt språket, och att det "kändessom ett bra språk för vårt ändamål; att utveckla en prototyp av en front-end för kundens simulatormiljö för 2g-nätverk på en relativt kort tid (Tre månader).
A.3
Teori
Olika programmeringsspråk är designade för olika ändamål. Utöver det så har olika programmeringsspråk olika höga s.k. inträdeströsklar, d.v.s. hur svårt eller hur mycket kompetens som krävs för att ett programmeringsspråk ska vara effektivt att använda. Denna tröskel vill vi hålla så låg som möjligt, för att ge möjligheten för hela gruppen att bidra så enkelt som möjligt.
A.4
Metod
För att ta reda på ifall Python lämpar sig som programmeringsspråk vid Pro- totyputveckling har nedan följande kriterier identifierats. Jag kommer att titta på valet av språk och dessa kriterier ifrån perspektivet av ett oerfaret team.:
1. Ej verbost. Då vi har begränsad tid vill vi kunna fokusera på att skriva kod som faktiskt gör någonting. Att skriva rad efter rad av boilerplate-kod är inte produktivt och tar viktig tid och koncentration ifrån den faktiska uppgiften.
2. Tillgängliga bibliotek för att underlätta lösningen av problem som kommer att bearbetas. Då vårt program bygger på ett par mer komplexa system (UI- och SSH-ramverk, m.fl.), vill vi gärna utnyttja kod som redan är skriven. Att återuppfinna hjulet är ej att eftertrakta.
3. Kraftfullt standardbibliotek. Om stöd för funktioner följer med standard- biblioteket kan vi räkna med bättre stöd än från tredjepartsbibliotek, och sparar oss viktig tid från att leta reda på bibliotek.
4. Lätt att skriva och förstå kod. Då vi snabbt vill komma igång och vår grupp är relativt oerfaren (Gentemot den genomsnittlige programmera- ren), måste barriären för att bidra till projektet vara så låg som möjligt. Alltså vill vi att det ska vara lätt att skriva kod, samt förstå kod andra har skrivit. Att lära utav varandra är också väldigt viktigt, vilket tydlig och klar syntax underlättar med.
5. Lätt att sätta upp en utvecklingsmiljö för språket. Då vi har en tämligen strikt tidsbegränsning måste det gå snabbt att komma igång. Att få igång utvecklingsmiljöerna är då väldigt viktig då allt annat hänger på att detta fungerar.
6. Det måste vara lätt att testa nya ändringar. Då vi kommer att iterera mycket är det viktigt att båda kunna testa hur nya ändringar kommer att påverka resten av programmet, samt att kunna hitta buggar och annat som lätt kan introduceras när en grupp oerfarna programmera slår sig samman.
Denna lista är ett resultat av min egen erfarenhet, samt [17], där Patrick Kiefer, Uwe Schmitt och Julia A. Vorholt skriver att t. ex C++ ej är optimalt då ”Alt- hough such frameworks [written in e.g. C++] have a rapid application run time, the testing of new workflows and concepts is cumbersome because programming requirements are high, and edit-compile cycles are slow”.
Vi visste att vi från början ville komma igång så snabbt som möjligt, och att prestanda inte skulle vara något problem. Vi ville kunna börja programmera så snabbt som möjligt, då tiden var väldigt begränsad. Att kunna testa program- met samt tillhörande ändringar lätt var också någonting vi dömde som väldigt viktigt. Om detta tar för lång tid är det svårt att hitta och fixa buggar, samt gör det svårare att testa nya idéer, någonting som förstås är väldigt viktigt inom prototyputveckling.
A.5
Resultat
För att komma fram till följande resultat har jag analyserat både mina egna erfarenheter och tankar, samt flera olika artiklar som tar upp liknande fråge- ställningar.
1. Är Python verbost? I vår erfarenhet, nej. Dynamisk typning, kombinerat med list-comprehensions", decoratorsöch andra syntastiska godbitar gör att Python håller sig väldigt "kortskrivet".
def run_in_thread(func):
"""Runs the decorated function in a separate thread."""
def wrapper(*a, **kw):
t = Thread(target=func, args=a, kwargs=kw) t.start()
return t return wrapper class Connection():
def __init__(self, hostname, username, password): self.ssh = paramiko.SSHClient()
self.ssh.connect(hostname, 22, username, password) @run_in_thread
def exec_command(self, command, output):
output.append(self.ssh.exec_command(command)) if __name__ == ’__main__’:
connection = Connection(hostname, username, password)
output = [] # Will contain the results of the executed command.
connection.exec_command("<insert command here>", output) För att skriva en modul för att koppla upp sig via SSH till given server och exekvera kommandon asynkront är ovanstående kod det ända som behövs. Till skillnad från många andra imperativa språk kan man uttrycka sig väldigt kort och samtidigt åstadkomma väldigt mycket. Detta är dessutom en väldigt utökbar bas, och liknande kod används för back-end":en i vårt projekt.
Detta stöds också av Jon McLoone i en undersökning av antalet rader kod som krävs för olika uppgifter [18], där Python hamnar näst först i effektivitet i klassen imperativa programmeringsspråk, och kräver nästan hälften så mycket kod för ”en stor uppgift” som exempelvis C++. Här ser vi dock också att funktionella språk är mycket mindre verbosa än alla imperativa språk, och kan i vissa fall vara 8-9x mindre verbosa.
2. Finns bibliotek tillgängliga för att underlätta lösningen av problem som kommer att bearbetas? I vår erfarenhet, ja. Under vår förstudie stötte vi på mängder av UI-, SSH-, och grafikrenderingsbibliotek, dock med olika grad av stöd. Detta är föga förvånande då Python är ett oerhört populärt programmeringsspråk.
3. Är standardbiblioteket kraftfullt? I vår erfarenhet, ja. Det märktes väldigt tydligt när stränghantering kom in i bilden då vi var tvungna att bearbeta text vi hämtade hem från Ericssons servrar. Alla funktioner man kan tän- kas behöva då man ska hantera en generell textsträng finns tillgängliga. Detta var otroligt smidigt och gav oss möjligheten att lägga viktig tid på
andra saker. Utöver det var det dessutom mycket lättare att komma fram till hur vi skulle hantera en viss output på bästa sätt.
def print_func(func):
"""Prints the decorated function with supplied arguments."""
def wrapper(*args, **kwargs): print("Function:", func) print("Args:", args, kwargs) return func(*args, **kwargs) return wrapper
@print_func
def keep_above_number(list, number):
"""Example of (very) simple list comprehensions that returns a list of all elements in ’list’ that are greater than ’number’."""
return [x for x in list if x > number] if __name__ == ’__main__’:
list = [4, 7, 2, 5, 1, 6] number = 4
print("Output:", keep_above_number(list, number))
# Returns the output:
Function: <function keep_above_number at 0x00000000023BBD90>
Args: ([4, 7, 2, 5, 1, 6], 4) {} Output: [7, 5, 6]
Ovanstående kodsnutt visar på s.k.k list comprehensions och decorators. 4. Är det lätt att sätta upp en utvecklingsmiljö för språket? Nej, inte i vår
erfarenhet. Nedan följer en lista av problem vi stötte på.
(a) Mängder av olika lösningar för s.k. virtual environments, olika versio- ner av Python som är kopplade till olika versioner av bibliotek skapar förvirring och osäkerhet. Detta är dock någonting som blir mindre av ett problem ju mer erfaret teamet bakom projektet är.
(b) Det dök det upp mängder av fel under installationen av olika biblio- tek. Detta berodde i de flesta fall på nedanstående punkt.
(c) Windows kräver en väldigt precis version av Microsoft Visual C++ Compiler, som måste kopplad till den versionen Python var kompile- rad på. Problem uppstår också då vi ska kompilera paket åt Python för OS X, då xcode måste vara installerat. Detta är dock ganska smärtfritt då vilken version det är inte alls är lika strikt som i Win- dows.
(d) För att få PySide samt Paramiko att installeras på Windows be- hövde vi jaga rätt på binärfiler för de system vi ville installera en utvecklingsmiljö på. Dessa var ej distribuerade officiellt, vilket ska- par problem då vi ej vet vem som har distribuerat dessa binärfiler. Kan vi verkligen lite på att dessa binärfiler är rena från exempelvis virus, bakdörrar eller annan skadlig kod?
5. Är det lätt att testa nya ändringar? I vår erfarenhet, ja. Språket behöver ej att kompileras, så det går väldigt lätt att bara köra igång programmet efter en snabb ändring. Utöver det finns det mängder av lösningar för automatiserade testning någonting vi inte använde oss av fullt ut, men när projekt växer är detta någonting som skall ses som väldigt attraktivt. De ovanstående punkterna förstärks av Diane Garey och Steve Lang som skri- ver att, ”Given its [Python] minimalist development philosophy, clear syntax, flexible programming approaches and large standard library, Python provides a high productivity development language for any domain expert, including ex- perts in HPC. It allows for fast prototyping, much like MATLAB and similar tools, making it useful for research projects and ad hoc development. As an open source language, though, Python allows users to avoid the cost of purchasing a commercial tool and eliminates the need to learn a proprietary prototyping language.” [19].
A.6
Diskussion
Python lyckas att kryssa i många av de rutor som är nödvändiga för att pro- grammeringsspråket ska vara ett bra val för oss. Vi stötte dock på flera problem då utvecklingsmiljön skulle sättas upp för olika platformar. Detta kan sätta käp- par i hjulen tidigt för nya, oerfarna grupper, men kan även medföra problem när det blir tid att distribuera programmet.
I det stora hela lämpar sig dig Python riktigt bra för prototyputveckling. Kod går snabbt att skriva, är lätt att testa och det finns mängder av verktyg och bibliotek som ska underlätta för utvecklingen av program. Värt att tänka på är att stödet för Windows ej är optimalt; att sätta upp en fungerande utvecklingsmiljö kan dra ut på tiden.
I vårt fall tjänade Python oss väl. Under utvecklingen av vårt program var vi tvungna att hantera strängar och mönster på väldigt många olika sätt då vi kommunicerade med Ericssons servrar. Då Pythons standardbibliotek i detta fallet är väldigt kraftfullt kunde vi fokusera på själva algoritmerna och sträng- hanteringen istället för att behöva återuppfinna hjulet och skriva stränghante- ringsfunktionerna själva. Detta lät oss få igång en fungerande prototyp relativt snabbt, vilket i sin tur lät oss börja iterera tidigt.
A.7
Slutsatser
Av min egen erfarenhet, samt resultaten, att döma, ser vi tydligt att svaret på frågeställningen är ja, Python var rätt språk för vårt projekt. Python uppfyller nästan alla kriterier, och passar således väldigt bra för utveckling av prototyper. Dock kan det vara en utmaning att få igång utvecklingsmiljöerna, vilket innebär att en bra konfigurationsansvarig är ett måste.
B
Utvecklandet av ett grafiskt gränssnitt
En utredning skriven av Martin Byhlin, specialist i Grupp 8 i kursen TDDD96, vid Linköpings universitet.
B.1
Inledning
I den här utredningen undersöks verktygen som användes till att konstruera GUI under projektet. Flera faktorer tas hänsyn till, bland annat inlärningstid och kodgenerering. Verktygen som användes under projektet och som undersöks är Qt Designer och PySide.
B.1.1 Syfte
Syftet med den här utredningen är att undersöka hur väl gruppens val av verktyg till utvecklandet av GUI fungerade, och hur väl gruppen lyckades använda dem till att uppnå det de ville.
B.1.2 Frågeställning
Frågeställningen som utredningen avser att behandla är följande: • Hur väl fungerade vårt val av GUI-byggande verktyg?
• Hur väl lyckades gruppen uppfylla de visioner som både gruppmedlemmar och kunden hade om gränssnittet?
B.2
Bakgrund
Till det här projektet valde vi att använda oss av verktyg som skulle underlätta utvecklandet. Tanken var den att om vi gjorde ett bra val av verktyg så skulle programmet kunna bli väl strukturerad och se modernt ut. Ett mål var även att gruppen inte skulle behöva lägga mycket tid på de grafiska delarna, och fokus istället kunde primärt läggas på att utveckla bakgrundsfunktionalitet.
Gruppen valde att skriva i programmeringsspråket Python tillsammans med ramverket Qt4, bindningspaketet PySide och GUI-byggaren Qt Designer. Dessa var besluten som vi tänkte passade in bäst för det här projektet, och det kan vara intressant att se just hur bra det fungerade i praktiken, och om det är värt att faktiskt använda dem.
B.3
Teori
Qt är ett ramverk som används till att implementera GUI. I projektet användes versionen Qt4, som hade en licens som gjorde att vi kunde använda det, som Qt5 ej hade.
I den här rapporten tas Qt Designer upp, vilket är ett GUI-byggande program som innehåller hjälpmedel för assistera användaren på olika vis [12]. Exempel på dessa hjälpmedel är möjligheten att placera objekt i GUI genom drag med musen, och att kunna se och ändra objekts egenskaper i en lista. Det GUI som man bygger i Qt Designer lagras i en XML-fil.
Vid sidan om Qt Designer finns bindningspaketet PySide [11, 10]. PySide använ- des för att koppla ihop Python med Qt, vilket tillåter användaren att använda delar av Qt, som klasser och paket, i Python-program. I PySide finns det även ett skript som kan skriva om XML-filen från Qt Designer till en körbar Python-fil. Resultat från ett användbarhetstest tas upp för att analysera kommentarer från en framtida användare. I ett användbarhetstest testas ett program genom att en användare får uppgifter som den ska lösa [20]. Användaren ombeds tänka högt och förklara hur den tänker när den ska utföra de givna uppgifterna. Kommen- tarer och åsikter insamlas utav personen som håller i testet.
B.4
Metod
Den här utredningen utfördes främst genom insamling och analys av data, varav ett flertal olika data kom i fokus.
En form av data som var av intresse var hur väl verktygen fungerat för grupp- medlemmarna. För att ta reda på detta fick gruppmedlemmar besvara frågor i en enkät om hur verktygen har fungerat för dem, som i deras inlärningstid, svårigheter som uppstått, och vad de tycker kunde gjorts annorlunda. Genom detta kunde åsikter bland gruppen enkelt samlas in och sammanställas. För att mäta den ökade effektiviteten vid användningen av verktygen utfördes tester för detta. I dessa testerna jämfördes tiden som krävdes för att arbeta i Qt Designer med rader kod som genererades, både direkt från Qt Designer, och från PySide-skriptet.
För att få åsikter från en mer betydande källa så granskades även kommentarer insamlade från ett tidigare utfört användbarhetstest [21]. Detta test utfördes under iteration 2 av projektet och hade endast en deltagare, detta på grund av att fler deltagare ej ville delta. Den enstaka deltagaren var en potentiell framtida användare av programmet, vilket gjorde hans åsikter extra värdefulla och intressanta för den här utredningen.
B.5
Resultat
Här nedan presenteras resultaten från de olika undersökningarna som utförts till den här utredningen.
B.5.1 Enkät
Sammanställning av resultat från enkäten som gruppmedlemmar fick besvara. Enkäten bestod i majoritet av frågor där man fick förklara sitt svar med eg- na ord. Följande svar är sammanfattningar av samtliga svar från en faktiska enkäten.
Har du arbetat med Qt Designer under projektet? 62.5% av gruppen har använt Qt Designer under projektet.
Hur finner du funktionaliteten i Qt Designer? Vad är bra och vad är inte så bra?
Det var inte så invecklat att påbörja, smidigt att man lätt med några knapptryck kan få ett GUI ungefär som man vill och det är även inte så knepigt att justera utseende. Dock så ser både Qt Designer och de GUI som man bygger stela ut och estetiskt trista. De känns väldigt statiska och omoderna.
Uppskattat, hur många timmar skulle du säga att det tog tills du kände dig insatt i Qt Designer och PySide?
Mellan 8 och 15 timmar i medelvärde.
Hur väl överstämmer programmet som vi tagit fram med den vision som du hade tidigare i projektet?
De flesta tycker att det vi fått fram stämmer överens med det som de siktade mot. Blev lite begränsade utav stelheten i Qt Designer och Qt4.
Anser du att vi valde bra verktyg för just det här projektet?
De flesta är någorlunda nöjda, men skulle velat ha något modernare, som Qt5 eller PyQt.
Om du kunde förändra EN grej, vad som helst, med verktygen: Vad skulle det vara?
Det skulle varit skönt med mer modernisering av verktygen, ännu en gång Qt5 eller PyQt.
B.5.2 Effektivitetstest
Sammanställning av tester som utfördes för att undersöka ökning i effektivitet då man använder Qt Designer och det nämnda PySide-skriptet [22]. Testerna utfördes av en person som har arbetat Qt Designer en stor del av projektet, och då är insatt i det. I testerna jämförs tiden det tar att implementera UI i Qt Designer mot antalet rader som genereras, i både XML-filen och i Python-filen. Med XML-kod menas koden som genereras direkt av Qt Designer, och med Python-kod menas den som genereras då man kör PySide:s inbyggda skript för att generera körbar Python-kod.
Uppgift 1:
Lägger till en knapp i ett redan existerande gränssnitt. Knappen ska bestå av en ikon och ha en fixerad storlek. Den ska även vara kryssbar.
Resultat:
Qt Designer: 53 sekunder.
XML-kod: 29 rader. 33 rader/minut. Python-kod: 11 rader. 12 rader/minut. Uppgift 2:
Skapa ett helt nytt fönster med en egen titel. Inuti fönstret ska det finnas ett redigerbart textfält och två knappar. De två knapparna är ”Cancel” och ”OK”. Resultat:
XML-kod: 67 rader. 54 rader/minut. Python-kod: 28 rader. 22 rader/minut. Uppgift 3:
Skapa ett helt nytt fönster. I detta fönster ska det finnas en checklista med fyra alternativ, ett icke-redigerbart textfält, och två knappar som säger ”Cancel” och ”OK”. Kryssrutorna och textfältet ska ha en redigerad text.
Resultat:
Qt Designer: 1 minut och 47 sekunder. XML-kod: 102 rader. 57 rader/minut. Python-kod: 46 rader. 25 rader/minut. B.5.3 Användbarhetstest
Sammanställning av resultat från ett användbarhetstest utfört av projektets testledare efter iteration 2 av projektet. Endast ett test utfördes och endast resultat relaterade till den här utredningen tas upp.
Vad tyckte användaren om programmets design?
Användaren tyckte att programmet såg bra ut. Designen kändes standard, och den påminde om andra program som användaren använder på jobbet.
B.6
Diskussion
I enkäten ses att den generella åsikten i gruppen är den att funktionaliteten i Qt Designer och Qt4 känns omodern. Dock så visade kommentarer från användare i användbarhetstestet att utseendet faktiskt liknar de verktyg som framtida användare redan är vana vid. Vilket är viktigast: att programmet efterliknar moderna standarder, eller det är någonting som användaren är van vid och redan känner sig bekväm med?
Från testet i effektivitet kan slutsatsen dras att Qt Designer kan vara ett väldigt