Resonemang kring komplexitet av funktionerna

I detta avsnitt sammanfattas komplexiteten över de olika funktionerna.

Implementeringstiden sammanställs i den ena tabellen för att få en större överskådlighet. Resonemanget över komplexitet baserar jag på Reschers (1998, s.9) nio olika aspekterna

Komplexitet i system av Langervik (2001). Kompendiet är i stort sett en sammanfattning av boken Objektorienterad analys och design av Mathiassen, Munk-Madsen, Nielsen och Stage (1998).

Komplexiteten delas in i en skala mellan 1 till 5. Då 1 = låg komplexitet, 2 = låg till måttlig komplexitet, 3 = måttlig komplexitet, 4 = måttlig till hög komplexitet och 5 = hög komplexitet. Funktion ^Des cr ip ti ve c om p le xi ty G en er at ive c om p le xi ty C om p u tat ion al c om p le xi ty C on st it u ti on al c om p le xi ty T axon om ic al c om p le xi ty O rgan iz at ion al c om p le xi ty H ie rar ic h ic al c om p le xi ty O p er at ion al c om p le xi ty N om ic c om p le xi ty S u m m a

Dynamisk uppbyggnad och

hämtning av information ^{1 3 5 4 3 3 5 1 4 29} Zoomfunktion 1 3 3 3 1 3 1 3 1 19 Sökfunktion 1 3 3 5 2 3 2 2 1 22 Dynamisktabell 1 2 3 5 1 1 2 2 1 18 Externa länkar 1 3 5 5 3 3 2 1 3 26 Egna anteckningar 1 1 3 4 1 1 2 1 1 15 Funktionaliteten för klickbar navigationsbild ^{1 1 1 1 1 4 1 3 1 14} Innehållsförteckning 1 2 3 4 1 3 3 1 1 19 3D-visualisering 1 1 4 3 1 3 2 4 3 22

Tabell 1. Tabell över komplexiteten i de olika funktionerna.

Som tabell 1 beskriver så har alla funktioner låg descriptive complexity. Detta är på grund av att det är relativt små funktioner och där med går det att göra en sakenlig beskrivning av funktionerna i designdokumentet. Men beskrivningen kan vara luddigt formulerad och där med bli komplex.

Om katalogen är uppbyggd med generiska funktioner så behövs det ofta mer

instruktioner för att bygga upp funktionen än en funktion som är skräddarsydd för just en specifik uppgift. Men om funktionen ska användas för fler ändamål än just den specifika uppgiften så kommer antalet instruktioner vara mindre för den funktionen som är

generiskt uppbyggd. Därmed kommer den generiska funktionen att vara mindre komplex. Computational complexity är även kallad lösandets komplexitet. Lösandets

komplexitet är ett mått över hur mycket tid eller kraft det krävs för att komma fram till lösningen. När katalogen är uppbyggt genom att ha system liggande på en cd-rom och

hämtar informationen från en databas på Internet så kommer tiden det tar att hämta informationen till användaren att vara i förhållandevis hög, och där med ha relativt hög komplexitet.

Constitutional complexity är även kallad mängdens komplexitet, alltså hur många element eller komponenter systemet består av. Ju mer komponenter systemet är uppbyggd med ju komplexare blir systemet. Sökfunktionen i prototypen är uppbyggd med några funktioner i Flashklienten, en PHP-sida som behandlar och utför

sökalgoritmen, en databas där informationen som är sökbar finns. Om man jämför detta med Googles sökmotor kommer det att vara en mindre komplex funktion men om

sökfunktionen skulle vara utformad för att bara söka igenom en sträng så har funktionen i prototypen hög komplexitet.

Taxonomical complexity är även kallad variationens komplexitet. Denna komplexitet är beroende på hur många ingående och utgående element som funktionen klarar av. Länkarna i prototypen klarar av att öppna alla filer som är associerade i operativsystemet. Om inte operativsystemet har den aktuella filtypen associerad kan utvecklarna lagt med ett tillhörande program till den filtypen så filen ändå går att öppna. Detta medför att de flesta ingående filerna går att öppna med hjälp av funktionen och där med har funktionen låg komplexitet.

Strukturens komplexitet är uppdelad i två delar, dels av organizational complexity alltså organiseringens komplexitet och hierarichical complexity alltså hierarkins komplexitet. Det går antingen att strukturera upp systemet genom att ha en ömsesidig relation mellan de olika funktionerna, i en hierarki eller i kaos. Organiseringens

komplexitet bygger på hur många olika sätt det går att arrangera de olika komponenterna på. Hierarkins komplexitet är beroende på hur hierarkin i systemet ser ut. Prototypen är uppbyggd i sin helhet med en hierarki av movieclips och punktnotation till de olika objekten. Detta för att öka överskådligheten och därmed minska komplexiteten.

Operational complexity är variationen i beteende eller olika sätt systemet kan fungera på. Ju mer frihet funktionen upplevs av användaren, desto mer varierande är systemet. 3D-visualiseringen tillåter användaren att mer eller mindre utforska ett 3D-objekt hur hon vill. Om man skulle jämföra det med en video som visade upp samma 3D-objekt så skulle videon ha låg operations komplexitet medan 3D-visualiseringen skulle ha hög

komplexitet. Användaren kan se objektet från en oförutsägbar vinkel i

3D-visualiseringen men i videon är alla vinklar förbestämda. Där med har 3D-3D-visualiseringen hög komplexitet.

Nomic complexity alltså lagbundhetens komplexitet bygger på noggrannheten och krångligheten de lagar som styr systemet. Systemet blir komplexare ju fler lagar som är inblandade i systemet. Länkarna i prototypen styrs av vilket operativsystem som systemet körs på, vilka program som operativsystemet har associerat, vilka länkar som läses in från databasen på Internet, att det finns en Internetanslutning, att servern är igång där länkarna ska hämtas ifrån, med mera. Länkarna har således hög komplexitet i jämförelse med en funktion som ska addera två tal.

Funktion Implementerin gstid

Tekniker Komplexitet

Dynamisk uppbyggnad och hämtning av information

40 timmar PHP, MySQL, Flash, ActionScript

29/9 = 3,2

Databas 5 timmar MySQL

Zoomfunktion 20 timmar Avancerad

ActionScript

19/9 = 2,1

Sökfunktion 10 timmar Flash, ActionScript,

PHP

22/9 = 2,4

Dynamisktabell 10 timmar Avancerad

ActionScript

18/9 = 2 Externa länkar 10 timmar ActionScript, Flash,

Lingo

26/9 = 2,8 Egna anteckningar 2 timmar ActionScript, Flash,

PHP, MySQL

15/9 = 1,6 Funktionaliteten för klickbar

navigationsbild

1 timme Flash 14/9 = 1,6

Innehållsförteckning 1 timme Avancerad ActionScript

19/9 = 2,1

3D-visualisering 1 timme Cult3D, Lingo 22/9 = 2,4

Tabell 2. Tabell över implementeringstid, tekniker och komplexitet över de olika funktionerna. Siffrorna över komplexitet är hämtade från tabell 1, där summan av de olika aspekterna är dividerat på antalet

aspekter.

För att få en genomsnittig komplexitet för alla aspekter lades de olika aspekterna ihop och sedan divideras på antalet aspekter, se tabell 2.

visualiseringen kan ta längre tid att implementera och tiden att modellera 3D-objektet är inte inräknad. Tid som jag inte har räknat med är den tiden som det tog att lära sig de olika författarverktygen och programmen.

Dynamisk uppbyggnad och hämtning av information via en databas.

Denna funktion är grundpelaren i prototypen och resten av funktionerna är beroende på hur denna funktion är uppbyggd.

Komplexiteten är måttlig enligt förgående analys och tiden det tog att implementera dessa två delar var ca 45 timmar.

Vid en katalog med få produkter blir omfattningen av koden större, där med ökar den generativa komplexiteten (generative complexity) jämfört med en statisk katalog. Men en katalog med många produkter har en låg komplexitet jämfört med en statisk katalog med samma produkter. Anledningen till detta är att koden i den dynamiska katalogen är generisk och samma kod återanvänds i katalogen, därmed skrivs det mindre kod jämfört med en statisk katalog som är uppbyggt på liknande vis.

För att minska komplexiteten och tiden det tar att implementera funktionen är att göra prototypen mer statisk. Detta gäller kataloger som innehåller ett fåtal produkter och uppdateras sällan. Ifall databasen tas bort och katalogen hämtar all information från samma medium som katalogen finns på minskar komplexiten i lösningen. Kopplingen till databasen behöver inte heller skapas. Något som är viktig om databasen tas bort och att all information finns inne i huvudkomponenten är att ha naturliga uppdelningar som inte är sammanflätad med resten av produkten. Anledningen till detta är att programkoden blir svårare att överskåda samt att alla delkomponenter blir beroende av varandra. Ifall en generell komponent är skapad fristående så går det eventuellt att återanvända just den komponenten i ett annat projekt.

Vid uppdatering av katalogen är det mindre komplext att ändra en databas än att gå in och ändra i källkoden. Detta gör att vid en produktkatalog som är ska uppdateras ofta bör vara uppbyggd med separerade delar, där den flexibla informationen bör finnas på ett flexibelt medium, alltså inte en CD-ROM. Delarna ska inte heller vara sammanflätade utan de ska vara utbytbara, alltså ifall företaget bestämmer sig för att gå över från en server med stöd för PHP till en server stöd för ASP så ska PHP-delen kunna ersättas med ASP.

Den extra tiden det tar att implementera katalogen dynamisk kan eventuellt sparas in vid uppdateringar av produkterna. Eventuellt ska hela katalogen ligga på samma medium för att minska latensen. Om hela katalogen är webbaserad och ligger på samma server så behöver inte servern anropa en annan server som kanske ligger på andra sidan av

jordklotet för att hämta instruktioner. Ifall allt ligger på samma server så blir katalogen bara beroende av en server.

Zoomfunktion

Zoomfunktionen har låg till måttlig komplexitet men tar ändå ca 20 timmar att

implementera. Anledningen till att det tog 20 timmar att implementera funktionen var att den skulle vara generisk och kunna läsa in olika typer av bilder. Ifall funktionen inte skulle vara generisk utan de bilderna som skulle förstoras är förbestämt och bara ett fåtal, skulle funktionen ta uppskattningsvis ungefär halva tiden att implementera. Funktionen skulle delvis bli mer komplex i så fall för att komponenterna skulle bli mer

sammanflätade och återanvändbarheten skulle försämras. Vid en lösning där det var förbestämda bilder som skulle kunna förstoras skulle tiden det tar att implementera funktionen öka i förhållande till antalet bilder. Lösningen med att ha en generisk funktion som kan läsa externa bilder ökar också implementeringstiden i förhållande till antalet bilder. Men ökningen sker inte i samma takt. Till exempel vid lösningen med

förbestämda bilden skapas det en liknande funktion för varje bild, alltså en ny mask skapas som är sammanfogad med den nya bilden och sedan ska koden för knapparna skrivas om så att de anpassar sig till den bilden. Det tar längre tid än att skicka in en ny sökväg till funktionen.

Om det är många bilder ökar implementeringstiden och komplexiteten för att skapa en funktion där bilderna är förbestämda. Men vid en dynamisk uppbyggd funktion är

komplexiteten låg till måttlig oberoende antalet bilder, implementeringstiden förändring vid fler bilder är försumbar i förhållande till funktionen med förbestämt antal bilder.

Sökfunktion

Sökfunktionen i prototypen har låg till måttlig komplexitet och tar ungefär 10 timmar att implementera. För att få ner implementeringstiden och framförallt komplexiteten är att göra funktionen beroende av mindre antal komponenter. Detta kan vara komplicerat när informationen som sökfunktionen söker igenom ligger i databasen. Ett alternativ för att minska komplexiteten är att skapa strängar med all nödvändig information om

produkterna i olika strängar i flashklienten och sedan matcha strängarna med sökfrasen. Detta är ingen bra lösning men den minskar komplexiteten. Anledningen till att det inte är en bra lösning är att om informationen om produkterna ändras om kommer inte strängarna att ändras om i prototypen. Sökalgoritmen blir enkel och går heller inte att uppdatera om funktionen är inbakad i flashklienten. Därmed blir komplexiteten nästan oförändrad.

Dynamisktabell

Den dynamiska tabellen i prototypen har låg till måttlig komplexitet och tog ungefär 10 timmar att implementera. Det går att minska implementeringstiden och komplexiteten genom att dra ner på de dynamiska funktionerna eller ersätta tabellen med en bild. Komplexiteten och implementeringstiden ökar i takt med funktionaliteten.

Externa länkar

Den dynamiska tabellen i prototypen har måttlig komplexitet och tog ungefär 10 timmar att implementera. Det som gör att komplexiteten och implementeringstiden är måttlig istället för låg är att det behövs ett tredjepartsprogram för att öppna filer på ett korrekt sätt ifrån en flashklient. Det går att minska komplexiteten och implementeringstiden drastiskt ifall filerna öppnas med GetURL() kommandot. Det som händer vid användningen av GetURL() är att klienten börjar ladda ner filen som anropas. GetURL() tar inte reda på om det finns något program associerat på datorn till den aktuella filen och funktionen kommer att fungera olika på olika datorer om den ens fungerar på vissa datorer på grund av säkerhetsskäl.

Anteckningar

Anteckningsfunktionen tog ungefär två timmar att implementera och har låg till måttlig komplexitet. Anledningen till att det bara tog två timmar att implementera denna funktion var att den använder sig av redan implementerade funktioner, detta gör i sin tur att

komplexiteten ökar. För att skapa en enskild funktion som har låg komplexitet tar uppskattningsvis fem gånger så lång tid att implementera.

Komplexiteten och implementeringstiden kommer att öka beroende på vilket sätt anteckningarna ska sparas på. Ifall anteckningarna ska sparas i en gemensam databas där varje användare ska kunna spara sina personliga anteckningar behövs det någon form av igenkänning, exempelvis inloggning eller att varje skiva har ett unikt nummer.

Ifall anteckningarna ska sparas på klientens dator måste det finnas skrivrättigheter till den platsen som klienten ska skriva anteckningarna till. Denna lösning ökar också komplexiteten.

Funktionaliteten för klickbar navigationsbild

Komplexiteten och implementeringstiden är låg. Anledningen till att

implementeringstiden bara tog ungefär en timme var att all funktionalitet redan fanns i grunduppbyggnaden av prototypen. Det som behövdes göra var att skapa knappar i ett movieclip och sedan länka in movieclipet som en produktbild i katalogen.

När systemet är uppdelat på detta sätt är systemet sammankopplat och inte sammanflätat. Om systemet skulle vara sammanflätat skulle uppdateringarna av den klickbara bilden bli mycket mer komplicerade.

Innehållsförteckning

Innehållsförteckningen i prototypen tog ungefär en timme att implementera och har måttlig komplexitet. Innehållsförteckningen använder sig av redan implementerade funktioner, till exempel sökfunktionen. På grund av det ökar komplexiteten men minskar implementeringstiden. En annan faktor till att innehållsförteckningen är komplex är att den använder sig av många komponenter, dessa komponenter är i stor grad

sammankopplade och inte sammanflätade vilket gör att de olika funktionerna går att byta ut och är inte lika beroende av varandra.

Tidskomplexiteten i starten av funktionen är hög på grund av att information måste hämtas från en databas på Internet. Men efter att innehållsförteckningen har hämtat sin information har den låg till måttlig tidskomplexitet. Tidskomplexiteten skulle därmed inte minska drastiskt om det skulle vara en öppen nätverksanslutning via sockets istället för att göra anrop över http-protokollet.

3D-visualisering

3D-visualiseringen har låg implementeringstid och låg till måttlig komplexitet. Detta är till stor del på grund av att programmet Cult3D används. Ifall 3D-visualiseringen skulle implementeras i Director skulle komplexiteten och implementeringstiden öka drastiskt. Cult3D är uppbyggt på ett okomplicerat och enkelt sätt för användaren, detta gör att komplexiteten för att bygga upp funktionen minskar samt att implementeringstiden minskar.

Men om 3D-visualisering ska ha funktioner som inte stöds av Cult3D blir det genast mer komplicerat och komplext att implementera 3D-visualiseringen i Cult3D. Därför är det bra att ta reda på vad målgruppen har för behöv och vad för funktionalitet som behövs innan tekniken väljs.