Skip to content

Commit

Permalink
Merge branch 'master' of git@github.com:johang88/haskellinjavascript
Browse files Browse the repository at this point in the history
  • Loading branch information
Johan Gustafsson committed May 25, 2010
2 parents 4d94845 + bef9e65 commit 92969ef
Show file tree
Hide file tree
Showing 3 changed files with 19 additions and 1 deletion.
2 changes: 1 addition & 1 deletion rapport/kapitel/metod.tex
Expand Up @@ -8,7 +8,7 @@ \subsection{Genomförande}
För att implementera en tolk för Haskell behövs en parser för den aktuella syntaxen, en typcheckare för språkets definierade typregler och tillsist en interpretator som tolkar språket efter dess specifikation.
Det upptäcktes tidigt att de tre modulerna, parser, interpretator och typcheckare inte behövde utvecklas sekvensiellt. De tre modulerna integrerar enbart med varandra genom det abstrakta syntaxträdet, vår interna representation av Haskell, vilket medför att det är lätt att utveckla de olika modulerna helt frånskilt från varandra. Figur \ref{fig:tolkens_struktur} visar hur denna interaktion mellan de olika modulerna är tänkt att gå till. Figuren visar även hur webbläsaren kommunicerar genom ett Javascript API och det abstrakta syntaxträdet och inte direkt med de olika komponenterna.

\begin{figure}[H]
\begin{figure}[h]
\begin{center}
\includegraphics[width=1.0\textwidth]{image1.png}
\caption{Överblick över tolkens struktur och interaktion}
Expand Down
Binary file added rapport/opponering/opponering.pdf
Binary file not shown.
18 changes: 18 additions & 0 deletions rapport/opponering/opponering.tex
@@ -0,0 +1,18 @@
Opponering på grupp DATX02-10-72, Databases for dummies 2

"Databases for dummies 2" är en rapport som beskriver ett program som ska användas för att administrera databaser, utan att man som användare har några kunskaper kring hur en databas fungerar. Vi har läst rapporten i opponeringssyfte och har en del tankar kring dess innehåll.

Överlag tycker vi rapporten var intressant och väldigt väl beskriver arbetsgången av projektet. Vi är positiva till att alla prioritet 1 användarfall framgångsrikt har implementerats. Programmet ser ut att uppfylla de kriterier för att programmet ska vara användbart för sitt syfte.

Det är dock en del stycken i rapporten som vi skulle vilja få en mer utförlig förklaring till.
Av rapporten att döma används en tabullär struktur för att representera en databas. Vi är skeptiska till om detta är det bästa sättet att representera databaser på för en nybörjare. I rapporten har det ej beskrivts om vilka konceptuella modeller som har utforskats för att representera en databas i programmet. Till exempel att använda ER-diagram för att på ett grafiskt sätt beskriva en databas för användare. Att modellera det med ER-diagram skulle kunna underlätta för nybörjare att se sammanhanget mellan olika databaser och eliminera svårbegripliga begrepp som till exempel "foreign keys".

Vi är fundersamma över designbeslutet att bara använda sig av en View-klass. I rapporten, sidan 7, rad 9, nämns det att en namnkonvention för att kunna navigera i View-filen var nödvändig på grund av att den växte ur proptotion och därmed blev svår att navigera i. Som motivering till varför man inte valde att dela upp View-klassen i flera mindre View-klasser nämndes att det skulle vara tidskrävande att omstrukturera den utan att klargöra varför detta skulle vara tidskrävande.

Det grafiska användargränssnittet som beskrivs har ett modernt och proffisionellt utseende, samtidigt som det ser tillräckligt enkelt ut för att användas av nybörjare. Programmet ser självförklarande ut och liknar andra Windowsprogram i menyer vilket är positivt när det riktar sig till nybörjare.

Vidare beskrivs i kapitel "5. Discussion", sidan 22, rad 14, att till en början användes enbart en enda controller-klass som hade prestandaproblem på grund av den hade så många jämförelser i sin action-listener, vilket skapade en fördröjning på flera sekunder. I rapporten hävdas det att prestandeproblemen upphörde när controller-klassen delades upp i flera mindre klasser. Vi är fundersamma hur dessa prestandaproblem var möjliga från och skulle gärna sett en mer utförlig förklaring kring det här problemet.

I teorikapitlet, sidan 2, finns ett avsnitt som beskriver vad ett ER-diagram är, men i rapporten som följer finns det ej något avsnitt som använder sig av ER-diagram, vilket medför att detta stycke känns överflödigt för att förstå rapporten.

Slutligen vill vi säga att rapporten hade en bra struktur och beskrev programmet som utvecklades på ett fullt tillräckligt vis.

0 comments on commit 92969ef

Please sign in to comment.