Eindverslag. A.S. Koning & R.J.T. Verwoerd. 24 juni Bachelors-project Interactieve website voor publicaties

Transcriptie

1 Eindverslag Bachelors-project Interactieve website voor publicaties A.S. Koning & R.J.T. Verwoerd 24 juni

2 Voorwoord De afgelopen paar maanden hebben wij hard en minder hard gewerkt aan het maken van dit publicatiesysteem. Op enkele momenten na, bijvoorbeeld wanneer het te veranderen ontwerp en de te maken code van elkaar afhankelijk waren, en we even niet wisten waar we nu verder moesten gaan, hebben we steeds met plezier dit systeem in elkaar gezet. Het feit dat binnen een straal van 10 meter een koffiezetapparaat, een schaakbord en een commissiehok met uitstekend-te-pesten-studiegenoten aanwezig waren, waren een extra motivatie. Helaas is het systeem zoals het nu is, niet volledig naar onze wens. Wellicht zijn de periodes waarin we minder hard gewerkt hebben daar debet aan. Wellicht ook het feit dat het idee voor sommige code eenvoudig is, maar de implementatie toch wat langer duurde dan verwacht. En ongetwijfeld zijn er naast de wijzigingen die we zelf nog graag willen doorvoeren, ook andere dingen die verbeterd kunnen worden en wij horen dan ook graag suggesties voor verbeteringen. Onze dank gaat uit naar de afdeling Parallelle en Gedistribueerde Systemen voor het mogelijk maken van dit project (en dan in het bijzonder naar dhr. Sips voor zijn inleidende ideeën, en naar Mathijs de Weerdt voor zijn begeleiding en stok-achter-de-deur-houden), naar studievereniging Christiaan Huygens voor het computerhok, de koffie en het schaakbord, naar Sjoerd en Vincent voor het zijn van een uitstekend target voor het afreageren van onze frustraties, en vooral naar alle (toekomstige) gebruikers van het systeem. Het is een leuke gedachte dat het resultaat van je eindproject echt gebruikt wordt, in plaats van op een elektronische plank stof ligt te verzamelen. Delft, juni 2004 A.S. (Sander) Koning & R.J.T. (Thomas) Verwoerd 2

3 Inhoudsopgave 1 Inleiding 5 2 Analyse 6 3 Ontwerp Database Layout & Navigatie User interface Implementatie Overzicht van publicaties Zoeken op publicaties Beheren van publicaties Importeren van publicaties Exporteren van publicaties Privileges Keuzes met betrekking tot het systeem Testen 14 6 Conclusie & Aanbevelingen Slotwoord Niet toegevoegde, en nog toe te voegen zaken A Het Requirements Analysis Document 17 A.1 Inleiding A.1.1 Doel van het systeem A.1.2 Doelen en succescriteria van het project A.2 Huidig systeem A.3 Voorgesteld systeem A.3.1 Overzicht A.3.2 Functionele eisen A.3.3 Data-eisen A.3.4 Nonfunctionele eisen A.3.5 Pseudo-eisen A.4 Voorbeeldscenario s A.4.1 Inleiding A.4.2 Een publicatie zoeken A.4.3 Een publicatie toevoegen A.4.4 Een lijst van publicaties exporteren A.5 Uitkomsten van gesprekken met (toekomstige) gebruikers

4 A.5.1 Inleiding A.5.2 M.M. de Weerdt (29 maart 2004) A.5.3 H.J. Sips (30 maart 2004) A.5.4 J.M. Valk (6 april 2004) B Het ontwerpdocument 23 B.1 Inleiding B.2 Databaseontwerp B.3 PHP structuur B.3.1 Overzicht van publicaties B.3.2 Zoeken op publicaties B.3.3 Beheren publicaties B.3.4 Importeren publicaties B.3.5 Exporteren publicaties C De planning 26 4

5 1 Inleiding Toen we aan dit project begonnen, hadden we enkele vrij sterke ideeën over hoe we het systeem wilden hebben, en enkele vagere ideeën. Terugkijkend op de afgelopen periode constateren we dat juist die dingen waar we eerst zulke scherpe gedachten over hadden, in mindere mate in het eindproduct naar voren zijn gekomen, terwijl het grootste deel daarvan bestaat uit de dingen waarvan we nog niet precies wisten wat we ermee moesten. In dit verslag willen wij beschrijven wat er, uitgaande van de originele opzet zoals we die hebben gemaakt aan het begin, van de oorspronkelijke ideeën terecht is gekomen. Daarnaast willen we een korte blik werpen op de problemen die we hebben ondervonden, en enkele suggesties doen voor mogelijke uitbreidingen. 5

6 2 Analyse In de analysefase hebben wij een onderzoek gehouden in de vorm van interviews onder gebruikers van het huidige systeem. Hieruit kwamen veel wensen van gebruikers en features die leuk of handig zouden zijn, of veel werk uit handen zou kunnen nemen. De uitkomsten van de gespreken hebben we geabstraheerd naar een lijst met eisen. En deze hebben we geordend op aflopende prioriteit. We besloten dat aan de eerste zes eisen voldaan moest worden om dit project te laten slagen. De lijst kwam er als volgt uit te zien. 1. toevoegen en wijzigen van publicaties: het toevoegen, wijzigen, en verwijderen van de gegevens die een publicatie representeren; 2. privileges-systeem (gebruikers vs. hoofdgebruikers): onderscheid maken tussen gasten en erkende gebruikers, en een beheersrechten-hiërarchie voor onderscheid tussen standaard gebruikers en hoofdgebruikers; 3. op eigen naam en project/groep zoeken: een lijst kunnen weergeven van alle publicaties waaraan een bepaalde gebruiker heeft meegewerkt, danwel behoren tot een specifieke projectgroep; 4. statische pagina creëren voor zoekmachines: een regelmatig bij te werken pagina creëren waar een complete lijst van alle publicaties in staat, die aan zoekmachines kan worden aangeboden; 5. BibTEX export van een of meerdere publicaties: het creëren van een BibTEX bestand met de publicatiegegevens zodat dit gebruikt kan worden in een andere, vaak in L A TEX te schrijven, publicatie; 6. links naar persoonlijke webpages: het opnemen van links naar de homepages van gebruikers die in het systeem staan; 7. jaaroverzicht exporteren: het creëren van een jaaroverzicht van alle publicaties die in een jaar (aak het huidige of zojuist afgelopen) zijn gepubliceerd; 8. eigen BibTEX file per gebruiker: elke gebruiker een eigen lijst van publicaties bij kunnun laten houden die niet in de publieke algemene lijst verschjnen, maar waar (andere) gebruikers wel toegang toe hebben; 9. eigen publicaties op homepage opnemen: het mogelijk maken dat elke gebruiker een verwijzing of lijst op zijn homepage opneemt die direct verwijst naar alle door hem aan meegewerkte publicaties; 10. handig ge-layoute vorm in diverse exportformaten: het exporteren van een (deel)lijst van publicaties naar diverse bestandsformaten die door uiteenlopende andere applicaties ingelezen kunnen worden, in een vorm die weinig tot geen aanpassing behoeft; 11. afkortingen voor journals en conferenties: veelgebruikte en standaard afkortingen voor journals, conferenties e.d. zonder extra actie van de gebruiker accepteren en goed verwerken; 12. BibTEX file importeren: het inlezen van een BibTEX bestand en de daarin vermelde afkortingen en publicaties controleren op consistentie, en zo mogelijk toevoegen aan de database; 13. locale documenten opslaan op de server: het kopiëren en beheren van daadwerkelijke publicaties vanaf locale computers naar de server zodat deze bereikbaar blijven, en controleren op wijzigingen en consistentie; 14. EndNote compatibiliteit: communicatie of bestandsinvoer en -uivoer van resp. naar EndNote (een veelgebrukt publicatie-beheersysteem) verzorgen. Deze prioriteiten hebben we verwerkt in een Requirements Analysis Document. Aan de hand daarvan zijn wij het databasemodel gaan opstellen en het project gaan implementeren. 6

7 3 Ontwerp 3.1 Database Het eerste idee van het database ontwerp is veel veranderd: in het oorspronkelijke model was de essentie van de documenten geplaatst in een eigen tabel, waarbij de de consistentie van de tabel en voorwaarden worden gecontroleerd in de tabel met behulp van het controleren op null velden. Hiervoor was gekozen omdatiet alle publicatietype s dezelfde eisen stellen aan een key voor aanwezigheid en dus in het geval van alle mogelijke standaard velden in 1 tabel, de consistentie door de code moest worden afgevangen en hierdoor aanzienlijk meer werk was. Het originele model bleek niet overal zo makkelijk te kunnen worden uitgevoerd. Zo wordt er bijvoorbeeld in enkele publicatietypes geëist dat of het ene veld wordt gebruikt of het andere veld (of beiden). Zoals bijvoorbeeld bij het type book moet er of een auteur of een editor zijn. Dit moest helaas via code afgevangen worden, in plaats van in het database model. Daarnaast zijn er ook wat tabellen bij gekomen waarvan wij niet verwachtten die nodig te hebben. Een van de dingen die er bij is gekomen is informatie voor de formulieren voor het invoeren en wijzigen van de entry s. De veldnamen en helpteksten worden dynamisch opgebouwd via de database, en we hadden hiervoor nog geen ruimte in het originele database model. Ons idee was om alles dynamisch aanpasbaar te maken (door een wijziging in de database, in plaats van in de code). Dit is gedeeltelijk gelukt. Bijvoorbeeld de weergavemanier van een entry in de algehele listing is ook in de database opgeslagen. Deze opmaakstring wordt ook gebruikt door de RTFexportfunctie. Ook voor de project support is er een tabel bijgekomen om makkelijk nieuwe projectgroepen toe te voegen en te zoeken. Verder hebben we op het gebied van de veelgebruikte afkortingen ook gedurende het project het een en ander moeten wijzigen. In fig. 1 staat het model zoals het uiteindelijk is geworden. Wij verwijzen naar de appendix voor het originele model. 3.2 Layout & Navigatie De website bevat een navigatiebalk bovenaan het scherm waarmee tussen de hoofdonderdelen van de site gesprongen kan worden. Voor ingelogde gebruikers bevat deze het extra item Administrative dat zelf een tussenpagina is naar diverse restricted functionaliteit. Wij vonden dit een betere oplossing dan een extra uitbreidingsrij aan de navigatiebalk zelf toevoegen. In het vereenvoudigd navigatieschema (fig. 2) is de belangrijkste functionaliteit en de onderlinge samenhang te zien. Hierin zijn de diverse onderdelen als functie / groep benoemd. Het blok rechtsboven bevat een aantal onderdelen die uit alledrie de lijst-/zoekweergaven toegankelijk zijn. Het uitgebreide navigatieschema (fig. 3) laat de volledige opbouw van de site zien, waarbij elk blok een apart bestand weergeeft in plaats van een functionaliteit of groep bestanden. Doorgetrokken lijnen zijn een directe verbinding, danwel doordat de gebruiker door een link of formulier van de ene naar de andere pagina navigeert, danwel doordat dit door een zogeheten HTTP-headermodificatie (de pagina voert wat code uit, en geeft de webbrowser dan de opdracht direct een andere pagina te openen) automatisch gebeurt. Streeplijnen geven een afhankelijkheid aan, dit wil zeggen dat een bestand van een ander gebruikmaakt (bijvoorbeeld een functiebibliotheek) of ernaar verwijst zonder verlies van controle, bijv door de nieuwe pagina als popup te openen. Er is een algemeen bibliotheekfile dat vanuit veel bestanden geladen wordt. Bij dit file is daarom niet de verbondenheid met alle andere bestanden weergegeven, maar symbolisch door de drie losstaande inkomende pijlen. Dit is er gedurende de implementatie bij gekomen omdat we erg veel code begonnen te hergebruiken die ook in andere bestanden stond. Ook is er net als in het eenvoudige schema een blok met de vanuit alle lijsten oproepbare pagina s weergegeven. De namen van de bestanden zijn in de blokken weergegeven, zonder de standaard.php extensie. 7

8 Figuur 1: Het uiteindelijke relationele database model 3.3 User interface De user interface hebben we bewust eenvoudig gehouden om navigatie gemakkelijk te maken en, wat misschien nog wel een belangrijker argument was, om het systeem zo algemeen mogelijk bruikbaar te maken. Dus niet alleen op één bepaald besturingssysteem omdat we bepaalde functies gebruiken die alleen door enkele browsers ondersteund worden. Om deze redenen bestaat de interface alleen uit een titel-/navigatiebalk en de eigenlijke pagina. Het idee voor de navigatiebalk werd gegeven door de heer Sips en wij vonden dat een erg nuttig concept. Aan de interface van de pagina s zelf hebben wij niet veel hoeven ontwerpen. Het grootste deel werd bepaald door de functionaliteit van de pagina, bijv een invulformulier of een lijst met verwijzingen. De kleuren en lettertypes komen overeen met de TU Delft huisstijl. 8

9 Figuur 2: Vereenvoudigd navigatieschema. 9

10 Figuur 3: Navigatieschema. Doorgetrokken lijnen zijn directe verbindingen, streeplijnen zijn afhankelijkheden. 10

11 4 Implementatie Bij het implementeren van de PHP structuur is de module subsysteem structuur aangehouden die beschreven staat in het ontwerpdocument. Helaas is het jaaroverzicht gedeeltelijk vervallen, doordat tussen de contactpersoon van METIS en ons geen gesprek heeft kunnen plaastsvinden. 4.1 Overzicht van publicaties De belangrijkste functionaliteit van de website is het weergeven van een lijst van alle publicaties van de afdeling Paralelle en Gedistribueerde Systemen. Dit onderdeel van de website geeft een overzicht van alle publicaties van de afdeling, met daarbij de benodigde links naar website van auteur(s) en naar de publicatie zelf. De layout van de standaard mogelijke gegevens staat opgeslagen voor alle entry- (publicatie-) types. Hierin staat gedefinieerd welke waarden met welke layout op het beeldscherm komen. Ook kan er string informatie worden bijgezet. Een voorbeeld is het weergeven van de pagina s in een tijdschrift waarop een publicatie is verschenen. Het gebruik van {pp. $pages} bijvoorbeeld: dit wordt weergegeven als pp (als het veld pages de waarde bevat), en niet als pages geen waarde heeft. Door middel van het toevoegen van de accolades wordt er geen informatie weergegeven die niet beschikbaar is. Er bestaat ook de mogelijkheid om deze website te gebruiken op de eigen pagina van de gebruiker. Het is bijvoorbeeld mogelijk om een pagina te genereren die alleen de entry s laat zijn van een bepaalde auteur, jaar of project-groep. Ook is het mogelijk om de pagina weer te geven zonder de standaard boven- en onderbalken, zodat deze direct geïntegreerd kan worden in de eigen webpagina. 4.2 Zoeken op publicaties Er zijn twee zoekmogelijkheden geïmplementeerd, te weten een eenvoudige in de navigatiebalk, en een uitgebreide. De eenvoudige zoekfunctie biedt de mogelijkheid om een zoekterm in te voeren waarna gezocht wordt op alle publicaties die die zoekterm in de auteur of titel bevatten. Bij het zoeken naar publicaties op de uitgebreide manier is er een formulier beschikbaar van het type die ook bij de TU Library wordt gebruikt. Het is mogelijk om op een of meerdere specifieke types publicaties te zoeken. Er kan maximaal op drie velden gezocht worden. De eerste opzet van de GUI van deze zoekfunctie was anders dan de huidige. Bij het testen bleek dit echter niet al te makkelijk te werken voor gebruikers, en niet al te overzichtelijke informatie te zijn. Hierdoor hebben wij besloten om de layout van de zoekmachine om te gooien. Omdat de meeste gebruikers bekend zijn met de zoekengine van de bibliotheek website, hebben we hem hierop laten lijken. 4.3 Beheren van publicaties Het beheren van een publicatie bestaat uit het wijzigen en/of verwijderen ervan. Dit is alleen toegestaan aan ingelogde gebruikers. Bij het wijzigen van een publicatie kan het type niet veranderd worden. Wij hebben hiervoor gekozen om de code en vooral de database query s die hiervoor nodig zijn binnen de perken te houden. Het wijzigen van het publicatietype brengt namelijk veel code met zich mee omdat elk publicatietype zijn eigen set velden heeft. Verder is onder dit deel ook het beheren van de veelgebruikte afkortingen en het beheren van de projecten te noemen. Deze onderdelen bieden de mogelijkheid aan geregistreerde gebruikers om afkortingen toe te voegen, te wijzigen en te verwijderen en om projecten toe te voegen en te verwijderen. 4.4 Importeren van publicaties Bij het implementeren van dit deel is er diverse onvoorziene functionaliteit bijgekomen. In BibTEX is er de mogelijkheid om veel voorkomende lange zinnen af te korten met behulp van een afkorting ofwel 11

12 abbreviation. Dit wordt gedaan via het definiëren van regel waarin de afkorting en de te gebruiken tekst vermeld staan. Alhoewel alle benodigde keywords dynamisch uit de database worden gegenereerd, was dit helaas niet mogelijk voor abbreviations en moest dit worden gedaan via een algoritme voordat de rest van het bestand werdt gegenereerd. Dit bracht natuurlijk een consistentie probleem mee. En daardoor moest er worden gecontroleerd indien er gerefereerd werd naar een abbreviation, of deze daadwerkelijk al bestond of lokaal werd gedefineerd. Dit werd opgelost via het genereren van een look-up tabel van de gegevens aanwezig in de database en tags in de in te lezen file. Daarnaast was het ook onvoorzien dat er in BibTEX de mogelijkheid was om kruisverwijzingen op te geven. Dit houdt in dat er gegevens van andere entry s worden overgeërfd, indien deze niet worden gedefinieerd. Dit was niet al te moeilijk op te lossen door te controleren op het keyword crossref, en alle gedefinieerde gegevens op te slaan, opdat de benodigde gegevens ook later in de BibTEX file komen te staan als de gegevens worden geëxporteerd. Om de gegevens makkelijk uit te kunnen lezen, worden gegevens die met behulp van een kruisverwijzing worden gedefinieerd, totaal opgeslagen, omdat het databasemodel hier niet toe is ontwikkeld en er dus geen echte ondersteuning voor biedt. Het is ook mogelijk in somige entry-types, dat één van twee waarden verplicht is. Bijvoorbeeld of een chapter of een pages moet aanwezig zijn. Dit kon niet in de database worden afgevangen en is dus opgelost met expliciete code in de BibTEX parser. 4.5 Exporteren van publicaties Het exporteren van een publicatie is het genereren van een BibTEX file vanuit de entry s vanuit de database. Bij de implementatie van dit subsysteem hebben we ons redelijk aan het ontwerp kunnen houden. Om ervoor te zorgen dat de gebruiker een bestand krijgt, en de browser geen zaken zelf gaat afhandelen, hebben we het forceren van een downloadn gerealiseerd via het modificeren van de HTTP headers. Hierdoor krijgt de gebruiker de vraag van de browser een bestand te downlaoden. Voor het creëren van een BibTEX file kan er worden gekozen uit een lijst waarbij elke entry geselecteerd kan worden. Er is een mogelijkheid om het formulier te resetten en alles te selecteren. De entry s worden op de zelfde manier weergegeven als de algemene listing. De exporter controleert ook welke abbrevations er worden gebruikt. Het zorgt er voor dat deze in de file aanwezig zijn, zodat de gebruiker het bestand kan gebruiken. In eerste instantie hadden wij nog het idee om iets met een exportfunctie naar Word te doen, of anderszins het gebruik van dit systeem in combinatie met het EndNote pakket mogelijk te maken. Dit is er niet meer van gekomen, wel hebben we exportfunctionaliteit voor RTF-bestanden ingevoegd. Deze bestanden zijn door bijna elke wordprocessor in te lezen. 4.6 Privileges De implementatie van het privileges-systeem hebben wij zeer eenvoudig gehouden. Een gebruiker heeft een access level aan de hand waarvan wordt bepaald of een bepaalde pagina toegankelijk is of niet. Gasten hebben niveau 0, gewone gebruikers 1, en de hoofdgebruiker niveau 16. Daar deze reeks bitsgewijs bedoeld is, zijn de niveaus 2, 4 en 8 nog beschikbaar voor tussenniveaus. 4.7 Keuzes met betrekking tot het systeem Omdat het systeem een database moest bevatten kwamen wij al snel op een keuze voor MySQL, daar dit een vrij te gebruiken database is (en dus ook tijdens de implementatie reeds te gebruiken voor tests) en wij er al ervaring mee hadden uit eerdere vakken. Als programmeertaal hebben we PHP gekozen daar dit ook vrij is en ingebouwde ondersteuning voor MySQL biedt. Binnen de database hebben we gekozen voor tabellen die in het zogeheten BerkeleyDB formaat worden opgeslagen. Dit databasesysteem heeft standaard ondersteuning voor meerdere gebruikers en lockt automatisch een rij of tabel als er toegang benodigd is. Dit zorgt ervoor dat er geen leesoperaties kunnen worden uitgevoerd als er een schrijfoperatie bezig is. Ook wordt er automatisch een logbestand bijgehouden zodat in het geval van een crash alle fouten daaruit hersteld kunnen worden. 12

13 Verder was het een erg praktisch voordeel bij de keuze voor een database en een programmeertaal, dat zowel MySQL als PHP reeds op de server aanwezig is die de zaak uiteindeljk moest gaan draaien. 13

14 5 Testen Bij het testen zijn er 2 manieren gehanteerd. De boundary testing werd gedaan tijdens het ontwikkelen van de code. Gedurende de implementatiefase hebben we herhaaldelijk de, nog steeds in ontwikkeling zijnde, code uitgevoerd om te kijken wat er allemaal in de database gebeurde. Verder hebben we veel gebruik gemaakt van de mogelijkheid droog te testen, d.w.z. op het scherm weergeven welke query s er uitgevoerd zouden gaan worden, zonder daadwerkelijk met de database te werken. Daarnaast werdt er ook getest met het invoeren en uitvoeren van een bestaande invoerfile en deze te vergelijken om te controleren of de gemaakte code geen rare artefacten toevoegde of dingen wegliet. Dit uiteraard aan het eind van het ontwikkeltraject, toen alle code nagenoeg af was. Een groot deel van het testen waren de integratie testen. Het was een grote klus om alle modulaire geschreven code samen te voegen. Zo waren er diverse files met functies. Deze werden verzameld in een algemene file functions.php waardoor een veel overzichtelijkere structuur ontstond in de files. Dit doordat de file nu naar 1 include regel nodig heeft voor de aan te roepen functies. Bij het integratietesten werden ook consistentiefouten ontdekt. Zo bleek de BibTEX export een andere benadering te gebruiken vanuit listings, dan de RTF export. Hierbij is de benadering gelijkgesteld. Dit ging relatief makkelijk omdat de code op zich prima werkte. Toen dit allemaal werkte hebben we een gebruikersonderzoek opgezet, waarbij een vrijwilliger met alleen de gebruikershandleiding diverse taken moet uitvoeren, zoals het invoeren van een publicatie, het opvragen van een BibTEX entry en andere zaken. De uitkomsten van deze testsessie waren tijdens het schrijven van dit verslag nog niet bekend en zullen als appendix worden aangeleverd. 14

15 6 Conclusie & Aanbevelingen 6.1 Slotwoord Terugblikkend op wat wij de laatste drie maanden hebben gedaan, het eerste document lezend en naar het resultaat kijkend, dachten wij bij veel dingen O ja, dat wilden we er ook in hebben. Door het gehele proces heen hebben we helaas steeds meer moeten laten zitten of minder uitgebreid maken. De tijd die wij dachten nodig gehad te hebben is helaas te vaak onderschat en soms verkeerd ingedeeld. Mede hierdoor zijn we laat op gang gekomen. We hielden ons wel netjes aan de planning, maar de implementatiefase en vooral het goed krijgen van het databaseontwerp heeft meer tijd gekost dan we vooraf hadden verwacht. Desalniettemin zijn wij tevreden met ons resultaat. We zouden het echter graag uitgebreider hebben gemaakt. Het ontwerp had daarom, achteraf gezien, wel wat beter mogen zijn. Zoals al eerder genoemd hebben wij veel aan het oorspronkelijke ontwerp moeten veranderen en zelfs op het laatste moment hebben we dingen aan de database veranderd omdat er iets niet helemaal lekker zat. Dit kostte tijd en was vooral frustrerend omdat reeds gemaakte code aangepast moest worden naar het nieuwe databasemodel. Dit vereiste goede en heldere communicatie. Het samenwerken is ons redelijk goed bevallen. Dit gedeeltelijk doordat we elkaar al goed kenden voordat we aan dit project begonnen maar vooral omdat het met twee mensen erg gemakkelijk is om afspraken te maken over wie wat moet gaan doen. Toch was enige miscommunicatie onvermijdbaar. Zo zijn er vooral bij het importeren van de BibTEX bestanden en het verwerken daarvan enkele dingen misgegaan door onduidelijkheden. Samengevat had het dus allemaal wel net wat beter kunnen lopen. Je verkijkt je altijd op de hoeveelheid werk die ergens in gaat zitten. Daarom ook hebben wij nog de nodige ideeën over zaken die wij graag ook in het systeem willen zien. Deze worden in de volgende paragraaf uitgewerkt. Wat we van dit project geleerd hebben is vooral dat communicatie en een goed ontwerp nog belangrijker zjn dan je wordt verteld tijdens de colleges. Daarnaast is het nu eens voor het echt uitvoeren van het hele ontwerp-, implementeer- en documenteerproces een ervaring op zich, waarbij niet echt is aan te geven wat we er nu precies van hebben opgestoken. Verder hebben we wat meer gevoel gekregen voor hoeveel tijd dingen nu werkelijk kosten. Zouden we het over moeten doen, dan zouden we vooral in het begin een snellere start maken en van te voren langer nadenken over het ontwerp. Wellicht een vertaling maken van het ontwerp naar wat er nu echt mee gedaan kan worden als het geïmplementeerd is. 6.2 Niet toegevoegde, en nog toe te voegen zaken Er zijn een paar dingen die wij niet hebben geïmplementeerd terwijl dat wel in het oorspronkelijke plan stond. Verder beschrijven we hier een paar dingen die wij graag in het systeem zouden zien maar die wij door tijdgebrek en prioriteitsstelling niet hebben gemaakt. Jaaroverzicht Door communicatieproblemen (ook intern) zijn wij er niet meer aan toegekomen om het genereren van het jaaroverzicht van publicaties toe te voegen aan de functionaliteit van het systeem. Wij hopen dat vooralsnog de lijstweergave per jaar een voldoende overzicht kan bieden. Eigen publicaties bijhouden Het was oorspronkelijk een van de ideeën dat elke gebruiker eigen publicaties kon bijhouden in een aparte sectie. Daar wij geen consistente en vooral bevredigende implementatie hiervan konden creëren, hebben wij dit gedeelte weggelaten. Eventueel kunnen gebruikers die per se een deel van hun publicaties apart willen houden, daar een apart project voor aanmaken. Standaard afkortingen Het systeem biedt in de huidige vorm wel de mogelijkheid om afkortingen te bewaren en leest deze ook in als er een BibTEX bestand wordt geïmporteerd, maar heeft geen standaard voorraad aan afkortingen voor journals, conferences, e.d. 15

16 Betere behandeling van kruisverwijzingen Kruisverwijzingen (crossrefs) worden nu ingelezen maar niet opgeslagen. Gegevens die overgenomen worden van andere publicaties worden gedupliceerd in de verwijzende entry omdat het databasemodel onvoldoende gebouwd is op het accepteren van kruisverwijzingen. Endnote compatibiliteit De Endnote compabiliteit / export is door gebrek aan tijd en informatie over het Endnote systeem vervangen geworden door een RTF exportfunctie. Diverse layouts Een van de zaken die het erg prettig voor gebruikers zou maken, was ons idee, is het kunnen kiezen van een van een aantal standaard aanwezige layoutformaten bij het exporteren naar een lijst. Helaas moeten wij gebruikers die deze functie graag zouden gebruiken, teleurstellen. Een tussenoplossing is het converteren naar BibTEX formaat en dan een van de standaard BibTEX stijlen gebruiken. De ingebouwde layouts zijn wel relatief eenvoudig te wijzigen. 16

17 A Het Requirements Analysis Document A.1 Inleiding A.1.1 Doel van het systeem Het doel van het systeem is gebruikers (in eerste instantie leden van de afdeling Parallelle en Gedistribueerde Systemen, maar mogelijk ook anderen) de mogelijkheid geven hun publicaties via een eenvoudig te gebruiken web-interface toe te voegen en te wijzigen. Daarnaast zal het systeem voor de gebruikers overzichten in diverse formaten moeten creëren. A.1.2 Doelen en succescriteria van het project Het project is geslaagd als het systeem minimaal voldoet aan de functionele eisen zoals die in paragraaf genoemd zijn. Daarnaast willen wij hieraan een aantal uitbreidingen toevoegen om het systeem gemakkelijker te gebruiken te maken. Zie hiervoor paragraaf A.2 Huidig systeem Het huidige systeem is een website, die een BibTEX-file met entries uitleest. Iedereen heeft toegang tot de webserver en kan op iedere plaats entries wijzigen, toevoegen en verwijderen. De webinterface is wel gemakkelijk, maar erg statisch. Het huidige systeem wordt nu gebruikt voor het zoeken op eigen naam en projectgroep. Ook is het mogelijk om de publicatielijst over te nemen op je eigen homepage. Ook worden er statische pagina s gegenereerd die ook makkelijk over te nemen zijn in eigen pagina s. Een nadeel van het huidige systeem is de onhandigheid van het invoeren. Nu moet eerst de BibTEX-file worden uitgechecked via CVS en dan kan men pas iets wijzigen. Dit is omslachtig. A.3 Voorgesteld systeem Het voorgestelde systeem zal ook bestaan uit een website. Nu echter zullen de publicatiegegevens in een database worden opgeslagen om het zoeken en wijzigen eenvoudiger te maken. De goede delen van het huidige systeem, zoals het maken van een publicatielijst en van statische pagina s, zullen ook in het voorgestelde systeem geïmplementeerd worden. A.3.1 Overzicht Het systeem zal een webinterface bieden aan gebruikers waarmee zij publicaties kunnen invoeren, bekijken en wijzigen. Verder zal het systeem additionele functionaliteit bieden in de vorm van het uitdraaien van jaaroverzichten, het gebruik kunnen maken van eigen publicatielijsten, en meer. A.3.2 Eisen Functionele eisen De volgende functionaliteit dient per se beschikbaar te zijn: 1. Het systeem moet de mogelijkheid bieden om gemakkelijk publicaties in te voeren. 2. De ingevoerde publicaties moeten gewijzigd kunnen worden. 3. Het systeem dient privileged te zijn opdat publicaties niet door onbevoegden gewijzigd kunnen worden. 17

18 4. Er moet kunnen worden gezocht in de beschikbare publicaties op groeps-id, datum van publiceren, schrijver, projectnaam en titel. Deze gegevens moeten op diverse manieren gesorteerd kunnen worden. 5. Er moet een mogelijkheid zijn voor het genereren van statische pagina s. Dit moet op verzoek en automatisch kunnen. 6. Exporteerfuncties, zowel naar het standaardformaat BibTEX als naar andere formaten. 7. Verwijzingen naar de publicaties zelf moeten worden kunnen toegevoegd. 8. Verwijzingen naar de persoonlijke webpagina s van de gebruikers van de website. Dit moet aansluiten op het huidige gebruikte systeem. Uitbreidingen Indien daartoe tijd en gelegenheid is, is het de bedoeling een of meerdere van de volgende uitbreidingen ook te implementeren: 1. De gebruiker moet in staat worden gesteld een lijst van publicaties voor eigen gebruik op de server op te slaan. 2. De gebruiker moet in staat zijn om eigen velden toe te voegen aan de publicatie. 3. In publicaties kunnen verwijzingen naar andere publicaties worden ingevoerd met een afkorting. Hierbij moeten standaard afkortingen ook ondersteund worden. De gebruiker moet die ook voor zichzelf kunnen aanmaken. A.3.3 Data-eisen Bij de implementatie en het gebruik van de database moet er rekening gehouden worden met het volgende: 1. Wachtwoorden (voor het privileges systeem) dienen gecodeerd te worden opgeslagen. 2. Consistentie binnen de database dient gegarandeerd te worden. A.3.4 Nonfunctionele eisen Het systeem moet beschikbaar zijn op alle gebruikte systemen binnen PGS. Dit zijn *nix, Windows en Macintosh. Gebruikersinterface en menselijke factoren De gebruikersinterface moet makkelijk te gebruiken zijn. Dit moet worden gerealiseerd door een logische opbouw van de schermen. Ook dient een overdaad aan schermelementen te worden voorkomen en zal er duidelijke feedback nodig zijn. De interface zal in het Engels worden opgesteld. Dit omdat de rest van de website van PGS ook in die taal is opgesteld. Documentatie Bij het gebruik van het systeem is On demand -help beschikbaar. Er moet ook een feature list beschikbaar zijn. Foutafhandeling en extreme omstandigheden Het moet duidelijk zijn welke pagina s bruikbaar zijn en waar gebruikers dingen kunnen aanpassen. Het mag niet mogelijk zijn om bestanden van andere gebruikers te wijzigen tenzij men hier voor geauthoriseerd is. 18

19 Systeemwijzigingen Het systeem zal in de loop der tijd waarschijnlijk nog wel wat aangepast worden. Een ander uiterlijk, efficiëntere functionaliteit, etcetera. Dit gaat waarschijnlijk niet door de oorspronkelijke ontwikkelaars gedaan worden. Fysieke omgeving Daar de webinterface en achterliggende functionaliteit geheel softwarematig geregeld wordt, zijn er geen specifieke eisen aan de omgeving. Het beheren van de server die de interface e.d. gaat verzorgen is geen werkzaamheid van ons. In het systeem moeten privileges geïmplementeerd worden, zodat de gegevens be- Veiligheidseisen schermd worden. A.3.5 Pseudo-eisen Het is handig als het systeem met behulp van PHP en MySQL opgezet kan worden daar dit reeds op de webserver aanwezig is. Implementatie vereist dan geen nieuwe omgevingen. A.4 Voorbeeldscenario s A.4.1 Inleiding Om een beeld te geven van hoe de gebruikers het systeem zouden ervaren geven wij hier enkele gebruiksscenario s. A.4.2 Een publicatie zoeken De bezoeker komt op de website aan om een publicatie van H.J.Sips over Voltage Scaling te zoeken. Op de indexpagina van de publicatie- subsite staat een zoekvak waarin een enkele term ingevoerd kan worden. Omdat de wensen van de bezoeker specifieker zijn gaat hij naar de uitgebreidere zoekpagina, waar specifiek op auteur, titel, en andere velden gezocht kan worden. In het auteursveld vult hij de naam Sips in, en in het titelveld Voltage Scaling. Bij beide kiest hij voor de partial functie omdat auteur noch titel exact overeenkomen met de gezochte term. Na een druk op de Search-knop verschijnt de lijst met de gevonden publicaties die overeenkomen met die termen op het scherm. A.4.3 Een publicatie toevoegen Na aankomst op de website klikt de gebruiker eerst op Login om zich aan te melden bij het systeem. Door invoeren van gebruikersnaam en wachtwoord wordt herkend dat hij gerechtigd is en de persoonlijke lijst van publicaties wordt weergegeven. Met een druk op de Add-knop gaat de gebruiker naar een keuzescherm waarin het type publicatie gekozen kan worden. Hij heeft een artikel over vervoersplanning gepubliceerd en klikt dus op de Article-knop. Hierna verschijnt er een pagina met een aantal velden die van toepassing zijn op een artikel. Behalve het invullen van de standaardvelden kan de gebruiker ook andere velden toevoegen aan de entry voor de database. Hij besluit dit niet te doen en klikt dus na het invoeren van de gegevens op de Add knop. Na een controle op ontbrekende gegevens wordt de publicatie toegevoegd en de gebruiker keert terug naar zijn persoonlijke lijst. A.4.4 Een lijst van publicaties exporteren De gebruiker meldt zich aan bij het systeem. Hij wil een lijst in HTML gaan exporteren van alle publicaties uit Dit doet hij door op de Search-knop te klikken. Op de uitgebreide zoekpagina voert hij in dat alleen publicaties uit 2004 getoond moeten worden. Hij klikt op Search en de lijst verschijnt op het scherm. Bovenaan de lijst staat een Export-knop en de gebruiker klikt hierop. De exportpagina biedt de keuze uit diverse formaten, waaronder HTML, dat hier gekozen wordt. Na het bepalen van de bestandsnaam waarin het document opgeslagen moet worden heeft de gebruiker de geëxporteerde lijst als HTML-bestand ter beschikking. 19

20 A.5 Uitkomsten van gesprekken met (toekomstige) gebruikers A.5.1 Inleiding Deze appendix bevat de uitkomsten van de gesprekken met een aantal toekomstige gebruikers van het door ons op te zetten systeem. We hebben er (ook door het feit dat de tijdens het gesprek gemaakte notities niet de letterlijke tekst weergeven) voor gekozen om deze uitkomsten geparafraseerd op te nemen. Dit echter zonder de werkelijke inhoud aan te passen. A.5.2 M.M. de Weerdt (29 maart 2004) Goede punten aan het huidige systeem Er is op de eigen naam van de gebruiker en op groep/project te zoeken Het is mogelijk om met behulp van een query de eigen publicaties op een webpagina op te nemen Er wordt een statische pagina gemaakt waarop de publicaties vermeld staan De webinterface is makkelijk te gebruiken. Niet gebruikte functionaliteit van het huidige systeem Omdat het onhandig is om publicaties in te voeren (men moet CVS gebruiken om het bestand met publicaties aan te passen) worden publicaties vaak te laat ingevoerd. Ontbrekende functionaliteit Er ontbreekt een handige manier om publicaties toe te kunnen voegen. Negatieve punten aan het huidige systeem. Het systeem is heel onduidelijk voor mensen. CVS wordt pas s nachts geupdate waardoor de ingevoerde wijzigingen niet direct zichtbaar zijn. Het is ook mogelijk om de aanwezige reservekopie van het publicatiebestand te wijzigen met als gevolg dat wijzigingen bij de eerstvolgende update verloren gaan. Fouten kunnen gemaakt worden ten laste van publicaties van andere gebruikers. Dit zou verbeterd moeten worden door een instelling dat men alleen wijzigingen mag maken aan publicaties waar men zelf aan gewerkt heeft. (Uitzondering is een eventuele hoofdgebruiker die wel alles mag wijzigen.) Verdere wensen In een HTML-pagina een tag kunnen zetten waarmee automatisch eigen publicaties ingevoegd worden. Als dat niet dynamisch kan is een exportfunctie naar een kaal HTML-bestand ook nuttig. In artikelen in Word moeten ook referenties op de standaardmanier ingevoegd kunnen worden (dus via een database of iets dergelijks), in plaats van via het BibTeX2HTML programma moeten werken. Een handig ge-layoute vorm moet eruit kunnen rollen in diverse formaten. Eigen velden kunnen toevoegen is nuttig. De database gebruiken voor een eigen publicatiebestand (als extra eigen lijst) zou een goede toevoeging zijn. 20

21 Afkortingen van journals waar men vaak in publiceert zouden gebruikt moeten kunnen worden. Hetzelfde geldt voor conferenties, die hebben ook standaard afkortingen. Een eigen bibfile kunnen importeren is nuttig (met selectie van wat er dan geïmporteerd wordt). Men moet snel hulp kunnen krijgen door in het scherm op een link te klikken, en daarnaast dient er een reference manual en een feature list aanwezig te zijn. Een jaaroverzicht kunnen uitdraaien en in goed formaat kunnen aanleveren (nu wordt dat weer handmatig ingevoerd in Metis ). Overige opmerkingen Er is een algemene standaard voor wat er ingevoerd moet worden. Deze stijlen zijn standaard bij BibTEX meegeleverd. Daarnaast leveren journals een standaard layout aan. A.5.3 H.J. Sips (30 maart 2004) Negatieve punten aan het huidige systeem. Iedereen die toegang heeft tot de webserver kan op iedere plaats nieuwe publicaties invoeren. Dat is niet handig: de publicaties zijn niet gesorteerd, er is geen controle op fouten. Er moet mbv een dummybestand gecontroleerd worden of alles goed staat ingevoerd. Wensen Bij het invoeren is het wellicht het handigst als de gebruiker van te voren een BibTEX stijl kiest waarna de voor die stijl verplichte en optionele velden ingevuld kunnen worden. Het zou nuttig zijn als er een BibTeX beschrijving van een publicatie gecreerd kan worden via een button (in de publicatielijst). Een handige feature zou dan ook zijn om dat van een aantal publicaties tegelijk te doen. Het systeem moet beschikbaar zijn op Windows, *nix, en Mac systemen (maar die zijn tegenwoordig ook *nix). Bij elke publicatie zit een link, soms zijn die naar een locale schijf. Nuttig zou zijn om dat bestand te kopiëren naar een centrale entry zodat er toegang toe blijft bestaan. Probleem is hierbij als de locale file wordt gewijzigd. Oplossing daarvoor kan zijn om een rapport te kunnen genereren met gewijzigde locale files. Beveiliging: een privileges-systeem is handig. Sommige gebruikers mogen alleen hun eigen publicaties invoeren/wijzigen, de hoofdgebruiker(s) alle. Structuur: nu kun je zoeken op projectnaam. Als het systeem buiten de groep ook gebruikt gaat worden moet er nog een groeps-id bij komen waardoor je binnen je eigen groep kan zoeken. De standaard startpagina zou dan de publicaties van je eigen groep weergeven. Achter personen staan nu links naar de publicaties van die persoon en een link naar de persoonlijke webpage. Dit zou op de een of andere manier via een centraal systeem gelinkt moeten kunenn worden omdat anders die gegevens stoffig worden. Idealiter wordt dat dan door het secretariaat bijgewerkt. Verder zouden Endnote compatibiliteit (exporteren naar Word e.d.) en een eigen BibTEX bestand per gebruiker handige toevoegingen zijn. 21

22 A.5.4 J.M. Valk (6 april 2004) Naast de punten die ook al uit de vorige besprekingen zijn gekomen hebben we de volgende dingen uit deze bespreking gehoord: Andere gebruikers zouden leesrechten moeten hebben op de persoonlijke bibfiles. Vaak worden die publicaties namelijk hergebruikt. Een nuttige uitbreiding is vanuit de LaTeX source (\cite{...}) een BibTEX entry kunnen creëren, op de een of andere manier een semantische afspraak maken over hoe namen van referenties opgesteld worden. Alles dat niet met BibTEX te maken heeft moet in principe te customizen zijn. 22

23 B Het ontwerpdocument B.1 Inleiding Dit document beschrijft het ontwerp proces voor de interactieve website voor publicaties. Als sleutel voor de juiste oplossing vonden wij dat de database structuur het belangrijkste element is van het systeem. B.2 Databaseontwerp Voor het ontwerp van het database is er gekozen het ontwerp te baseren vanuit een EER-model, zeer schematisch weergegeven in fig. 4. Dit model zal worden omgezet in een relationeel model. Figuur 4: Het EER-diagram Alle algemene informatie is toegevoegd aan de entry, zoals groepnummer en beheerder van het document. Daarnaast heeft het model voor elk type publicatie een tabel met daarin alle verplichte en niet standaard verplichte velden. Hierin wordt ook consistentie bewaakt door het controleren op NULL waarden. Verder is er een tabel voor alle niet verplichte velden. deze heeft per entry een aantal mogelijke velden. Zie figuur 5 voor het relationele model. De structuur van de tabellen is belangrijk, aangezien de formulieren voor het invoeren van webpagina s automatisch gegenereerd worden vanuit de beschrijving van de tabelen. Per tabel is aangegeven hoe het veld in de form er uit komt te zien. dit wordt gedaan door middel van de description tag in de tabel. Ook wordt er aan de hand van de tabellen gegenereerd welke publicaties er toevoegbaar zijn. B.3 PHP structuur Het PHP deel valt op te delen in diverse subsystemen. Er zijn meerdere onderdelen onderscheidbaar. Onderscheidbaar zijn een systeem voor het weergeven van alle publicaties, een systeem van het beheren van alle publicaties en zo voort. Ontwerptechnische details van elk subsysteem worden in het bijbehorend subkopje besproken. B.3.1 Overzicht van publicaties Voor het overzicht van de publicaties is het belangrijkste wat de volgorde van de weergave wordt. Er moeten diverse mogelijkheden zijn om makkelijk te sorteren op auteur, jaar, groep en titel. Dit is makkelijk te realiseren door middel van een query naar de MySQL database. 23

24 Figuur 5: Het relationele database model B.3.2 Zoeken op publicaties Bij het zoeken zijn er twee mogelijkheden. Je kan op de basis beginselen zoeken, de auteur en titel van de publicatie. Maar ook moet er de mogelijkheid zijn om op aparte velden te zoeken. Dit kan via een systeem waarbij de door te zoeken velden meegegeven worden aan de query. B.3.3 Beheren publicaties In het beheren is het mogelijk om alle velden, behalve het id, aan te passen via het zelfde form om aan te maken. Verder is er de mogelijkheid om de gegevens te verwijderen en aan te passen door de beheerder of de eigenaar van het document. B.3.4 Importeren publicaties Voor het importeren van publicaties wordt weer dynamisch uit de database bepaald welke voorwaarden er moeten worden voldaan om een bestand te mogen importeren. Daarnaast wordt er ook bekenen aan welke velden er in de publicatie moeten staan. Voor het lezen van het bestand wordt er gebruik gemaakt van het uploaden van een bestand op de server en het daarna verwijderen van het bestand. 24

25 B.3.5 Exporteren publicaties Voor het exporteren van de publicaties wordt de voorgaande procedure omgekeerd. Alle geselecteerde publicaties worden eerst omgeschreven naar een bestand, dat via een geforceerde download direct op de computer van de gebuiker wordt geschreven. 25

26 C De planning De planning die we aan het begin van het project hebben opgesteld is bijgevoegd in figuur 6. Wij hebben wat uitloop gehad met alles werkend krijgen, maar dit heeft naar onze mening geen noemenswaardige gevolgen gehad. Figuur 6: Onze originele planning In figuur 7 is weergegeven wat er daadwerkelijk van de planning is terechtgekomen. 26

27 Figuur 7: Een vergelijking van de planning en de werkelijkheid 27

28 Bronnen Wij hebben gedurende het project van de volgende bronnen gebruikgemaakt: G. Kotonya en I. Sommerville, Requirements Engineering: Processes and Techniques, Wiley and Sons, 1998 Oren Patashnik, BibTEXing Online onder andere op btxdoc/btxdoc.html, meegeleverd met standaard L A TEX distributies. Rich Text Format (RTF) Specification, version 1.6. Microsoft Corporation, Online onder andere op dev.mysql.com 28