Handleiding YasperWE en InfoPath Jan Martijn van der Werf

15 januari 2007

1. Inhoudsopgave Handleiding YasperWE en InfoPath..............................................................................1 1. Inhoudsopgave .......................................................................................................1 2. Systemen maken met YasperWE:..........................................................................2 3. Benodigde software ...............................................................................................3

3.1. Yasper ............................................................................................................3 3.2. InfoPath..........................................................................................................3 3.3. YasperWE......................................................................................................3

4. Gebruik van Yasper ...............................................................................................4 4.1. Case sensitivity ..............................................................................................4 4.2. Taken en rollen ..............................................................................................4 4.3. Animatie.........................................................................................................5

5. Gebruik van InfoPath.............................................................................................6 6. Gebruik van YasperWE .........................................................................................7

6.1. Stappenplan om een systeem te gaan ontwerpen...........................................7 6.2. Stappenplan bij het ontwerpen van een systeem............................................7 6.3. Definiëren en koppelen van rollen aan taken.................................................7 6.4. Koppelen van InfoPath aan het Petrinet.........................................................9

7. Documenteren en specificeren van taken ............................................................10 8. Debuggen in YasperWE ......................................................................................11 9. Voorbeelden in YasperWE ..................................................................................11

9.1. Voorbeeld 1: een urenregistratiesysteem.....................................................11 10. Referenties .......................................................................................................17 11. Bijlage 1 ...........................................................................................................18

2. Systemen maken met YasperWE: In de colleges systeemmodelleren wordt een methode aangeleerd om (informatie) systemen te ontwikkelen. Centraal in deze methode staat het gebruik van technieken om te kunnen modelleren. Informatiestructuren en –gedrag worden vastgelegd op een wiskundige manier, om zo te laten zien dat het ontwikkelde systeem correct is en doet wat het moet doen. Hierbij wordt gebruik gemaakt van objectmodellen (datamodellen) en Petrinetten. Wanneer we een programma hebben dat Petrinetten begrijpt en kan uitvoeren, samen met de manipulaties op het object model, hebben we een krachtige en snelle methode om systemen te ontwikkelen en daadwerkelijk in te zetten. Met dit doel is YasperWE ontwikkeld. Om ook datamanipulaties door de verschillende gebruikers (actoren) toe te staan, wordt InfoPath gebruikt. Met YasperWE ontwikkel je een applicatie die uit drie onderdelen bestaat:

• een procesmodel dat alle taken (stappen in het proces) definieert en hun volgorde

• formulieren die de eindgebruiker kan invullen, die aan een taak kunnen hangen

• SQL-queries die de gegevens in de formulieren klaarzetten en/of verwerken, waarbij ook een database met achtergrondgegevens gebruikt kan worden.

Het procesmodel, een speciaal soort Petrinet, wordt gemaakt in Yasper (zie sectie 4). De formulieren (zowel de erin voorkomende gegevens als het uiterlijk) worden gemaakt in InfoPath. Je begint daarbij niet met leeg, maar met een speciaal InfoPath-document (een zgn. “InfoPath solution”, extensie .xsn) waar de YasperWE-functionaliteit al in is opgenomen. (Zie voor details sectie 5 en 6.) De SQL-queries worden in Yasper aan de taken gehangen, en het Yasper-model wordt in InfoPath aan de InfoPath solution gehangen. Vervolgens kan het resultaat met InfoPath uitgevoerd worden. (Zie de details in sectie 6.)

3. Benodigde software

3.1. Yasper Gebruik de laatste build van Yasper (versie 2.0b9 of later, [1]). Deze ondersteunt namelijk het aanbrengen van extra informatie (bv. SQL-queries) zoals YasperWE dat verlangt.

3.2. InfoPath Gebruik Microsoft InfoPath SP1, behorende bij Microsoft Office 2003 Professional, te downloaden vanaf de TU/e.

3.3. YasperWE Om ook datamanipulatie toe te staan, is YasperWE versie 2 nodig. Deze is te downloaden vanaf [2]. YasperWE is zoals gzegd een InfoPath solution (een .xsn-bestand dat gemaakt en uitgevoerd wordt met InfoPath). Let op, om YasperWE te kunnen draaien, heb je ook MySQL 4.1 of hoger nodig en .NET 1.1. Daarnaast heb je een script, XsnFixer. nodig om de InfoPath solution te kunnen gebruiken. Zie voor alle details de installatiehandleiding, DeploymentManualv2.doc.

4. Gebruik van Yasper

4.1. Case sensitivity Een workflow Petrinet is een Petrinet met één initiële plaats i, d.w.z een plaats zonder ingaande pijlen, en één finale plaats f, d.w.z een plaats zonder uitgaande pijlen, en alle plaatsen en transities liggen op een pad van i naar f. Zo’n workflow Petrinet beschrijft alle mogelijke paden van één instantie van een proces. Deze instantie noemen we een case. Omdat we met simuleren en prototypen van een systeem graag meerdere runs willen kunnen uitvoeren op een workflow, introduceren we een kleur zodanig dat de runs van verschillende processen onderscheidbaar zijn. Deze kleur noemen we case identity. Plaatsen zijn ofwel gekleurd (gele plaatsen in Yasper), dit noemen we case sensitive plaatsen, ofwel ongekleurd (witte plaatsen in Yasper). Een transitie kan vuren als alle geconsumeerde tokens uit de case sensitive plaatsen dezelfde case identity hebben. Als een transitie vuurt, wordt de case identity van de geconsumeerde tokens doorgegeven aan alle geproduceerde tokens die in een case sensitive plaats terecht komen. Een transitie die geen case sensitive inputplaatsen heeft, maar wel case sensitive outputplaatsen, noemen we een emitter. Als deze emitter vuurt, creëert deze een nieuwe case (case identity). Een transitie die case sensitive inputplaatsen heeft, maar geen case sensitive outputplaatsen, noemen we een collector. Deze collector ruimt een case (case identity) op.

4.2. Taken en rollen Transities noemen we taken in Yasper.1 Een taak heeft ofwel AND-semantiek, ofwel XOR-semantiek. De AND-semantiek is de standaard Petrinet-semantiek van een transitie: de taak is enabled als alle inputplaatsen een token hebben, en bij vuring wordt er in alle outputplaatsen een token gelegd. Een XOR-taak is enabled als er in een van zijn inputplaatsen een token ligt, en bij vuring wordt er één outputplaats gekozen om een token in te produceren. In feite kun je een XOR vertalen naar een state machine Petrinet (zie Figuur 1).

1 Dit heeft een reden: in een gewoon Petrinet is het vuren van een taak een atomaire actie. In Yasper is het uitvoeren van een taak een tweestapsactie: beginnen en eindigen. Een Yasper-taak bestaat dus eigenlijk uit twee Petrinet-transities met een plaats ertussen:

Figuur 1: Vertaling van XOR naar een State Machine Petrinet

Een taak kan worden uitgevoerd door een rol, vaak een persoon. In Yasper kun je de verschillende rollen binnen een systeem definiëren en aangeven welke taken deze rollen kunnen uitvoeren. Hangt er een rol aan een taak, dan zal YasperWE er bij het uitvoeren een formulier voor tonen.

4.3. Animatie Yasper heeft een animatie-modus (Run manually), om het token game van Petrinetten met de hand te kunnen uitvoeren. Taken die enabled zijn, zijn rood omlijnd. Door er op te klikken, vuurt de taak. Onder het Petrinet zie je voor iedere rol die een of meer taken kan uitvoeren, een lijst staan, de werklijst. Dit zijn de taken die de rol kan uitvoeren. Door een van de taken in de lijst te selecteren, wordt de taak uitgevoerd. Op deze manier kun je zien wat iedere rol op welk moment kan uitvoeren.

5. Gebruik van InfoPath InfoPath is een formulierapplicatie. Je kunt er formulieren in ontwerpen die de inhoud van een XML bestand laten zien. Een InfoPath document heet een solution. Een XML bestand heeft zelf ook een structuur, die in InfoPath data source wordt genoemd. YasperWE is zelf een solution. Om het systeem te gaan ontwerpen, moet je deze uitbreiden. Data sources YasperWE maakt gebruik van een database. Om de globale data aan de case data te kunnen koppelen, moet de XML omgezet worden naar een relationele database. Dit heeft tot gevolg dat je géén attributen (datatype: Field (attribute) ) als datatype voor velden kunt gebruiken. Verder is het verstandig om als je een groep definieert, een prefix te gebruiken, om conflicten te vermijden. Houd rekening met de verschillende soorten datatypen die je kunt toevoegen in InfoPath. Een groep die niet repeating is, wordt omgezet in een tabel met een enkele(!) rij, ofwel, een tabel waar je alleen maar updates en selects op mag uitvoeren. YasperWE definieert zelf al een paar stukjes in de data source:

In de groep yasperwe staat alle informatie benodigd voor YasperWE, en het veld choice wordt gebruikt voor XOR-taken, om de outputplaats te specificeren. Blijf van deze dingen dus af, want YasperWE gaat vreselijk kapot als ermee geknoeid is.

Views In een InfoPath solution kunnen meerdere views gedefinieerd worden. Kijk voor iedere taak of je een view kunt hergebruiken, of een nieuwe moet ontwerpen. Geef de view een duidelijke naam.

6. Gebruik van YasperWE YasperWE is een tool waarmee je redelijk eenvoudig een werkend prototype van je systeem kunt maken. Het is ontworpen als een InfoPath solution. Om een nieuw systeem te maken, moet je de solution kopiëren en uitbreiden.

6.1. Stappenplan om een systeem te gaan ontwerpen Om een nieuw systeem te gaan ontwerpen, moet je allereerst de volgende stappen volgen:

1. Installeer de XsnFixer (als je dit nog niet hebt gedaan). 2. Kopieer de YasperWE template Solution naar een nieuwe lokatie, en hernoem

hem. 3. Open de directory waar XsnFixer is geïnstalleerd. Standaard is dit

c:\Program Files\ASPT\XsnFixer\ 4. Sleep de gekopieerde solution op het bestand XsnFixup.js in de XsnFixer map.

Je krijgt dan de volgende melding:

5. De solution is nu gereed om een systeem te gaan ontwerpen.

6.2. Stappenplan bij het ontwerpen van een systeem Om van YasperWE gebruik te maken kun je het beste het volgende stappenplan volgen:

1. Modelleer het Petrinet voor het gehele systeem 2. Controleer of het model goed is (test bijvoorbeeld via de simulator) 3. Definieer de rollen / actoren die de taken uitvoeren. NB Je kunt dus ook

taken hebben die geen enkele rol hebben: automatische taken! 4. Definieer de InfoPath data en de formulieren. Het handigste is om dit

iteratief per taak te doen: a. Definieer de case data nodig voor de taak, b. Definieer de view voor een taak, c. Schrijf de queries die nodig zijn om de case data vooraf in te vullen, d. Schrijf de queries die nodig zijn om de case data achteraf te verwerken

in de globale data (het objectmodel), en e. Test of het werkt.

6.3. Definiëren en koppelen van rollen aan taken Rollen definieer je als volgt in Yasper:

1. Selecteer het menu Roles ���� Define Roles… Je krijgt het volgende scherm te zien:

2. In dit scherm staan de verschillende rollen en hun capaciteit: het aantal

beschikbare rollen. Voeg in het eerstvolgende lege veld de naam van de rol in. De capaciteit wordt automatisch op 1 gezet.

3. Herhaal dit tot je alle rollen gedefinieerd hebt. Vervolgens kun je de rollen aan de verschillende taken koppelen. Dit kan op een tweetal manieren. Als alle taken al gedefinieerd zijn, gaat dit het eenvoudigste via:

1. Selecteer het menu Roles ���� Assign to tasks… Je krijgt dan het volgende scherm te zien:

2. In dit scherm zie je alle taken, en de gedefinieerde rollen. Om een rol aan een taak te koppelen, zet je een vinkje in de juiste cel. Wanneer je een hiërarchisch net hebt, kun je aangeven of je alleen de taken van het zichtbare gedeelte wilt zien (de optie in current net) of alle taken (de optie in whole net).

Daarnaast kun je via de Properties van een taak op het tabblad Advanced aanvinken welke rol(len) de taak kunnen uitvoeren.

6.4. Koppelen van InfoPath aan het Petrinet

Views koppelen aan taken Het koppelen van InfoPath aan het Petrinet gebeurt op twee manieren. Allereerst moet de view gekoppeld worden aan de taak. In Yasper-termen betekent dit dat de naam van de view in het Performed using form veld (tabblad Advanced) van de taak gekoppeld moet worden. De verschillende views zijn nu gekoppeld aan het Petrinet, en als een taak gekozen wordt, verschijnt de juiste view. Het volgende dat ingesteld moet worden is de datamanipulatie op het objectmodel door de verschillende taken.

Datamanipulatie Zoals eerder al gemeld, werkt InfoPath met XML, terwijl YasperWE een relationele database heeft. Daarom wordt de XML omgezet in een relationeel model en toegevoegd aan het globale dataschema. Op deze manier kun je SQL-queries schrijven om de datamanipulatie uit te drukken. Om deze queries te kunnen schrijven, moet je weten hoe de XML omgezet wordt in een relationeel model. Zogenaamde Groepen in InfoPath worden omgezet naar tabelnamen. Je hebt twee typen groepen: repeating en non-repeating. Beiden worden omgezet naar een tabel, er is enkel een groot verschil: een non-repeating groep heeft slechts één record, een repeating groep een willekeurig aantal. Dit moet je goed in gedachten houden tijdens het schrijven van de verschillende queries. Daarnaast worden velden omgezet naar veldnamen in de tabel. Omdat XML ambigu is in het gebruik van elementen en attributen, is er voor gekozen om de attributen niet mee te nemen. Daarom kun je ook alleen maar gebruik maken van element velden in InfoPath. Let op, het algoritme let er niet op of de tabelnaam al in de database bestaat, dus zorg ervoor dat de groepen in je InfoPath solution andere namen hebben dan de objecten in je object (data) model. Op [3] vind je een tool waarmee je automatisch van een InfoPath solution de tabel definities kunt extraheren. Wanneer we praten over case data bedoelen we de data die InfoPath kan verwerken, ofwel het relationeel model dat uit de XML wordt gegenereerd. Met het object model bedoelen we het globale model dat je eerder in het project gedefinieerd en geanalyseerd hebt. Omdat taken nu invoer kunnen verwachten van de gebruiker / actor, kun je de taak in het Petrinet zien als een taak bestaande uit een drietal subtaken:

1. prepareer de case data, 2. laat de gebruiker de informatie invullen (deze stap is optioneel), en 3. voer postprocessing uit op de case data.

Daarom heb je in YasperWE de mogelijkheid om twee queries te schrijven: prequeries om de case data te prepareren, en postqueries om de case data te gebruiken om het object (data) model te manipuleren. Let op, bij de vertaling naar het relationeel model, wordt er in elke lege case tabel een dummy entry gemaakt. Deze moet je dus eerst verwijderen bij een INSERT query!

Omdat je alleen maar met SQL-queries de data kunt manipuleren, is het handig om te weten hoe je met de MySQL variant van SQL om kunt gaan. Deze biedt namelijk extra mogelijkheden in de vorm van variabelen, if-then-else en case-when functiewoorden. Zie [3] voor een volledige handleiding over MySQL en haar taal.

XOR-taken In Yasper kun je keuzes modelleren met een XOR-taak. Deze kiest een output pijl om een token naar te produceren. In YasperWE kun je deze keuze beïnvloeden door in het myFields-veld choice de naam van de output plaats te zetten. Dit kun je de gebruiker laten doen, maar ook aan de hand van queries. Op deze manier kun je zelf aangeven welke plaats als output plaats wordt gebruikt. Herkent YasperWE de naam niet, dan wordt er een willekeurige outputplaats gekozen.

7. Documenteren en specificeren van taken Bij het specificeren en documenteren van de taken, moet per taak aangegeven worden met welke plaatsen en stores er gecommuniceerd wordt, welke rollen de taak kunnen uitvoeren en welke view dan getoond wordt. Daarnaast moet aangegeven worden hoe de taak het object model manipuleert. In het voorbeeld hieronder is een voorbeeld van documenteren gegeven. Op [6] kun je een transformatie vinden die deze documentatie kan genereren (let op, dit is natuurlijk niet alle documentatie die je moet inleveren). Tevens is hier een tweede transformatie toegevoegd die de queries uit een Yasper document kan halen.

8. Debuggen in YasperWE In YasperWE worden geen mooie foutmeldingen gegenereerd als er iets mis gaat. In de tabel ywecasedatalog van de database vind je de verschillende case documenten die gebruikt zijn tijdens de run. Daarnaast is er de tabel ywequerylog. In deze tabel staan alle queries die het systeem uitgevoerd heeft, en eventuele foutmeldingen van de queries. Als er iets misgaat, kun je in de logtabel terugvinden wat er mis is gegaan. De MySQL-query Browser [4] en de MySQL Administrator [5] zijn hierbij zeer handig ehulpmiddelen en besparen je een hoop gepuzzel.

9. Voorbeelden in YasperWE

9.1. Voorbeeld 1: een urenregistratiesysteem Het urenregistratiesysteem is een klein systeem dat gebruikt moet gaan worden in een bedrijf dat veel projecten draait. Ieder project wordt gerund door een manager met een aantal werknemers. De manager definieert de taken in het project, samen met de werknemers die aan de taken mogen werken. Een taak gekoppeld aan een (aantal) werknemer(s) heet een activiteit. Een werknemer kan inloggen in het systeem en zien aan welke projecten hij deelneemt. Wanneer hij een project kiest moet hij de activiteiten zien van het gekozen project en de mogelijkheid hebben om uren te registreren op de uitgevoerde taken.

Eisen Aan het systeem zitten nog extra eisen:

• Het systeem kan niet stopgezet worden als er nog mensen ingelogd zijn en werken met het systeem.

• Als een systeem gestopt moet worden, mogen er geen nieuwe mensen inloggen in en werken met het systeem

• Managers moeten de mogelijkheid hebben om nieuwe projecten toe te voegen

Actoren en hun acties Het systeem kent de volgende actoren, met bijbehorende acties:

• Systeem beheerder: o Kan het systeem opstarten o Kan het systeem stoppen

• Manager: o Werknemers en managers toevoegen o Projecten aanmaken o Projecten verwijderen o Werknemers aan projecten koppelen o Taken toevoegen aan een project o Taken verwijderen aan een project o Werknemers koppelen aan taken o Werkoverzicht opvragen van een project

• Werknemer: o Kan zijn projecten zien o Kan inloggen op het systeem

o Kan inloggen op zijn projecten o Kan zijn activiteiten opvragen o Kan uren aan een activiteit hangen o Kan zijn urenoverzicht van een project opvragen

Object model Om dit systeem mogelijk te maken, zijn er de volgende objecten nodig:

• Project: het object dat een project definieert. • Werknemer: wie er actief is in het systeem. Het type geeft aan of de

werknemer actief is (groter dan, of gelijk aan 0), een gewone werknemer is (gelijk aan 0) of een manager is (groter dan 0).

• Taak: een eenheid binnen een project die gedaan moet worden • Activiteit: een eenheid binnen een project die aangeeft wat er door wie moet

worden gedaan • Werk: een eenheid binnen een taak die aangeeft wie er al hoelang aan gewerkt

heeft Werknemers kunnen in meerdere projecten werkzaam zijn, en er kunnen meerdere werknemers op een taak gepland worden. Dit zijn dus many-to-many relaties. Hiermee komen we tot het volgende data model:

De twee belangrijke constraints in dit model zijn:

• Een werknemer kan alleen activiteiten hebben in een project waar hij in mag werken: c(a) b(p)a(p) e(f(ac)):PWp:Activiteitac =∧=∈∃∈∀

• Een werknemer kan alleen werk invullen voor een taak van een activiteit die hij mag uitvoeren:

c(ac)d(w) f(ac)g(w) :Activiteitac :Werk w =∧=∈∃∈∀

Geïntegreerd systeem Het totale systeem bestaat uit een drietal delen, opgesplitst naar actor. Het hoofdniveau toont het starten en stoppen van het systeem, en wanneer de verschillende actoren mogen inloggen en hun taken uitvoeren. Vervolgens zijn er een tweetal subniveaus, die de verschillende taken van de actoren mogelijk maken.

Hoofdniveau

In dit systeem zien we dat het systeem maar één keer opgestart wordt. Meerdere instanties tegelijk zijn niet mogelijk. De emitor startEngine zorgt ervoor dat het systeem gestart kan worden. Zodra deze gevuurd heeft, kunnen werknemers en managers in het systeem inloggen. Wanneer de systeembeheerder het systeem stopt via stop, kunnen er geen nieuwe actoren inloggen op het systeem. De lopende cases moeten nog afgerond worden, waarna het systeem via de taak End daadwerkelijk stopt. De collector Collect zorgt voor eindiging van het geheel, waarna het systeem weer opnieuw gestart kan worden.

Verificatie Wanneer we naar het systeem kijken, zien we een tweetal problemen in verband met analyseerbaarheid: de taak End en de plaats runningCases. Iedere keer als de taak EnterWerknemer of EnterManager vuurt, zal er een token in runningCases bij komen. Dit betekent dat de plaats runningCases unbounded is. Ervan uitgaande dat de subsystemen Werknemer en Manager sound zijn, zal iedere keer als EnterWerknemer, respectievelijk EnterManager vuurt, endWerknemer, respectievelijk endManager uiteindelijk ook vuren. Het aantal tokens in runningCases zal dus uiteindelijk altijd weer terug gaan naar het initiële aantal, namelijk 0 tokens, dus zal uiteindelijk de taak End ook kunnen vuren, en kan het systeem eindigen.

Werknemer subniveau

We komen in dit subsysteem als een werknemer succesvol heeft ingelogd op het systeem (de taak inloggenInSysteem van het hoofdniveau). De taak _doorvoer_ heeft enkel de functie om ervoor te zorgen dat het subsysteem een correct Workflow net blijft. De werknemer kan inloggen op een project via de taak Inloggen, en vervolgens zijn activiteiten, taken, voor het project bekijken en zijn werk aan toevoegen.

Verificatie Het gehele systeem, op de taak Inloggen na, is een state machine. De taak Inloggen is een XOR-taak en dus te vertalen als een state machine. Het gehele subsysteem is dus een state machine, en dus per definitie sound.

Manager subniveau

De taak _doorvoer_ heeft hier dezelfde functie als bij werknemer, ervoor zorgen dat het geheel een correct workflow net is. We zien dat een manager kan Inloggen via de taak Inloggen. Wanneer dit lukt, kan de manager de aanwezige projecten zien, projecten toevoegen en projecten verwijderen. Ditzelfde kan hij met werknemers. Daarnaast kan hij een project selecteren via SelecteerProject en taken, activiteiten en werknemers definiëren en koppelen aan het project.

Verificatie Het gehele systeem, op de taak Inloggen na is een state machine. De taak Inloggen is een XOR-taak, en dus te vertalen als een state machine. Het gehele subsysteem is dus een state machine. Omdat het tevens een correct workflow net is, is het systeem per definitie sound.

Case data In de figuur hieronder is de case data weergegeven als een XML boom. Zoals te zien zitten de standaardvelden benodigd voor YasperWE erin, samen met overige informatie nodig om de verschillende views te kunnen vullen. Belangrijk om te weten

hierbij is het verschil tussen gewone groups en repeating groups. In de figuur daarnaast is de XML data omgezet naar een SQL schema (zonder attributen hier). De tabellen in de omlijning zijn repeating tabellen en kunnen dus meerdere rijen bevatten. Op de overige tabellen mogen enkel(!) UPDATE en SELECT queries uitgevoerd worden. Houd hier rekening mee!

myfields

cd_inloggen

cd_projecten

cd_hulp

cd_taak

cd_taken

cd_project

cd_werknemers

cd_werknemer

cd_werken

cd_werk

cd_Activiteiten

cd_activiteit

Views Voor iedere taak binnen het model moet een view gemaakt worden. Dit betekent voor dit systeem dat de volgende views aanwezig zijn:

• OnlySubmit Enkel een submit button, veelal om te testen, of voor taken zonder datamanipulatie

• inloggenProjectWerknemer Inloggen op een project in het systeem. Zowel voor manager als werknemer

• inloggenWerknemer Inloggen in het systeem met gebruikersnaam en wachtwoord. Zowel voor manager als werknemer

• toevoegenProject Toevoegen van een of meerdere projecten

• verwijderenProject Verwijderen van een project

• toevoegenTaak Toevoegen van een of meerdere taken

• toonTaak Aanwezige taken

• verwijderTaak Aanwezige taak verwijderen

• toonWerknemers Werknemers in het systeem tonen

• toevoegenWerknemer Toevoegen van een of meerdere werknemers aan het systeem

• verwijderenWerknemer Verwijderen van een werknemer van het systeem

• toevoegenActiviteit Toevoegen van een activiteit: het koppelen van een activiteit aan een werknemer

• verwijderenActiviteit Verwijderen van een activiteit: het ontkoppelen van een activiteit met een werknemer

• toonActiviteiten Toont de koppelingen binnen dit project tussen werknemer en activiteit

• toevoegenWerk Toevoegen van een werkzaamheid aan een taak door een werknemer

• toonWerk Toont de verschillende werkzaamheden die uitgevoerd zijn. Hetzij horende bij een taak van een project (manager), hetzij de taken die een werknemer uitgevoerd heeft bij een taak (werknemer)

• verwijderWerk Verwijdert werk van een werknemer

Takenpecificatie Zie bijlage 1.

10. Referenties [1] Yasper, versie 2.0b9: http://wwwdev.yasper.org/beta [2] YasperWE, versie 2: http://dev.yasper.org/we/ [3] MySQL handleiding: http://dev.mysql.com/doc/refman/4.1/en/index.html [4] MySQL-query browser: http://dev.mysql.com/downloads/query-browser/ [5] MySQL Administrator: http://dev.mysql.com/downloads/administrator/ [6] Transformaties op PNML: http://wwwis.win.tue.nl/~jmw/pnml/

11. Bijlage 1 Deze bijlage bevat enkele van de taakspecificaties van het urenregistratie voorbeeld. Check user data Input: pl6 Output: failed, employee, manager Stores: Roles: View: Function: Deze taak zorgt voor het automatisch inloggen van werknemers en

managers. Prelogic: Postlogic: SELECT @choice := CASE w.isWerkgever

WHEN 0 THEN 'employee' WHEN 1 THEN 'manager' END, @id := w.id FROM werknemer w, Urenregistratie u WHERE w.naam=u.`username` AND w.wachtwoord=u.`password`; UPDATE myfields SET `choice` = IFNULL(@choice,'failed'); UPDATE Urenregistratie SET `userid` = IFNULL(@id,'');

Time Registration Input: pl15 Output: pl15 Stores: Roles: Employee View: toevoegenWerk Function: Deze taak zorgt voor het invullen van werk door werknemers. Allereerst

worden de projecten in de case data geladen, om zo selectie op projecten mogelijk te maken. Na het tonen van formulier worden de uren weggeschreven in het systeem.

Prelogic: DELETE FROM caseProject; INSERT INTO caseProject (id,projectnaam,caseProject en_Id) SELECT id, naam, 1 FROM project;

Postlogic: SELECT @id := userid FROM Urenregistratie; INSERT INTO taak (start,eind,omschrijving,werknemer ,project) SELECT p.start, p.eind, p.omschrijving, @id, p.proj ect FROM caseUur p; DELETE FROM caseUur; DELETE FROM caseProject;

View Report Input: pl15 Output: pl15 Stores: Roles: Employee View: toonWerk Function: Deze taak verzorgt het tonen van het werkrapport van de huidig ingelogde

gebruiker. Prelogic: DELETE FROM rapportItem;

INSERT INTO rapportItem (werknemernaam,starttijd,eindtijd,werkomschrijving, project2, rapport_id) SELECT w.naam, t.start, t.eind, t.omsch rijving, t.project, 1 FROM taak t, urenregistratie u, werkne mer w WHERE t.werknemer = u.userid AND w.id = u.userid;

Postlogic: DELETE FROM caseUur;