RUG eDocs Op weg naar flexibele communicatie tussen bedrijven
Bedrijf Opdrachtgever Uitvoering Datum Versie
Rijksuniversiteit Groningen Faculteit technische bedrijfskunde Dhr. F. Blommestein A. H. J. Broeksema 30-08-2006 1.2 (definitief)
Voorwoord Na ruim vier jaar hogere informatica gestudeerd te hebben - waarvan de eerste twee aan de Hogeschool Enschede en de overige jaren aan de Hanze hogeschool in Groningen - sluit ik de studie af met het project waar ik in dit rapport verslag van doe. Ik heb mijn afstudeerproject uitgevoerd bij de Rijksuniversiteit Groningen aan de faculteit technische bedrijfskunde. Hier heb ik me beziggehouden met het ontwikkelen van een XSLT-applicatie waarmee formulieren gegenereerd kunnen worden. Graag wil ik hier de heer Blommestein bedanken voor het delen van zijn inzichten in de gebruikte standaarden en de gegeven begeleiding tijdens het project. De heer Jorritsma wil ik bedanken voor zijn begeleiding bij het schrijven van dit rapport. Verder wil ik de heer Baas bedanken voor het kritisch lezen van dit rapport. Tenslotte wil ik mijn vrouw bedanken voor haar steun tijdens deze drukke periode. Bertjan Broeksema Groningen, 1 september 2006
Samenvatting Het onderzochte probleem is onderdeel van een onderzoek dat de heer Blommestein uitvoert aan de Rijksuniversiteit van Groningen. Zijn onderzoek is erop gericht digitale bedrijfscommunicatie ten behoeve van e-commerce te flexibiliseren. Mijn opdracht was een applicatie te ontwikkelen die beschrijvingen van berichten1 in een formulier omzet dat in een normale webbrowser te bekijken is. Hiervoor diende ik zoveel mogelijk gebruik te maken van (reeds geaccepteerde) standaarden. Hierbij kon ik gebruik maken van een voorbeeldbericht en een eenvoudig prototype die door de heer Blommestein ontwikkeld waren. Allereerst heb ik me hiervoor verdiept in de standaarden die gebruikt moesten worden. De belangrijkste standaard met betrekking tot de berichtbeschrijving is de core component standaard2. En de belangrijkste standaard voor de formulieren was de XFORMS-standaard. Om bekend te raken met de XFORMS-standaard en om te onderzoeken hoe de core component standaard hierin vormgegeven moest worden, is eerst een mapping gemaakt van core component datatypen naar XFORMS-elementen. Vervolgens is deze mapping gebruikt om te bepalen welke code gegenereerd moest worden en is begonnen met de implementatie van de applicatie in XSLT. Hier is een groot deel van de tijd in gaan zitten met als resultaat een applicatie die in staat is om alle datatypen uit de core component standaard om te zetten naar een XFORMS-document. Het XFORMS-document is in staat om een bericht te genereren dat voldoet aan de beschrijving van het bericht aan de hand waarvan het XFORMS-document zelf gegenereerd is. Daarna is begonnen met de implementatie van een systeem om de opmaak van het document te bepalen. Op het moment van schrijven is dit nog niet zover gevorderd dat het gedemonstreerd kan worden maar reeds uitgevoerde testen op deze code zijn veelbelovend. Voor zover het geïmplementeerd is, lijkt het te werken zoals verwacht. Maar er moeten nog een aantal zaken geïmplementeerd worden voordat de resultaten zichtbaar zijn in het formulier. Tijdens het project is gebruik gemaakt van een ontwikkelmethode die veel lijkt op rapid application development. Hierbij is zwaar geleund op een webapplicatie genaamd trac3. Dit heeft geleid tot een website waarop de ontwikkeling van de applicatie goed is terug te vinden, en waar ook documentatie is opgenomen voor degenen die hierna aan het project moeten werken. Wegens verschillende factoren was het lastig om een goede schatting te maken voor een planning. Er is daarom met een zeer globale planning gewerkt. Dit heeft als nadeel gehad dat het moeilijk in te schatten was welke functies te implementeren zouden zijn in de beschikbare tijd. Concluderend kan gezegd worden dat de staat van het product een goede basis is voor verdere ontwikkeling. Voordat het product commercieel ingezet gaat worden zal het wel nodig zijn om het intensiever te testen. Door de modulaire opbouw en de documentatie op de trac-site is geprobeerd om de inwerkperiode voor degenen die na deze afstudeeropdracht moeten werken aan dit product te verkorten. Intensief gebruik van de trac-site wordt aanbevolen om een goed beeld te krijgen van de staat van het product. Tenslotte zal er onderzoek gedaan moeten worden naar de opmaakeigenschappen van een formulier en de implementatie van deze eigenschappen in de stylesheet.
1 Een eenvoudig voorbeeld van een bericht is uitgewerkt in bijlage II 2 Zie voor gebruikte standaarden de bijlage standaarden. 3 http://trac.edgewall.org/
Inhoudsopgave 1. Inleiding...........................................................................................................................................5 2. Geschiedenis....................................................................................................................................6 3. Context.............................................................................................................................................8 3.1 Bedrijfsproces in schema's.......................................................................................................8 3.2 Het ontwikkelen van een semantiek.........................................................................................9 3.3 Uitwisseling van berichten baseren op veelgebruikte standaarden........................................11 3.4 Gewenste onderzoeksresultaten..............................................................................................11 4. Plan van aanpak.............................................................................................................................12 4.1 Opdrachtomschrijving............................................................................................................12 4.1.1 Doelstelling....................................................................................................................12 4.2 Randvoorwaarden...................................................................................................................12 4.3 Meetbaarheid..........................................................................................................................13 4.4 Werkzaamheden.....................................................................................................................14 4.5 Planning..................................................................................................................................14 4.6 Ontwikkelmethodiek..............................................................................................................15 4.6.1 Meegewogen aspecten....................................................................................................15 4.6.2 Gekozen werkwijze........................................................................................................16 4.6.3 Evaluatie werkwijze.......................................................................................................16 5. Functioneel ontwerp......................................................................................................................17 5.1 Product context.......................................................................................................................17 5.2 Functioneel ontwerp...............................................................................................................19 5.2.1 Stylesheet........................................................................................................................19 5.2.2 Annotaties.......................................................................................................................19 6. Werkzaamheden en resultaten.......................................................................................................21 6.1 Verrichte werkzaamheden......................................................................................................21 6.2 Resultaten...............................................................................................................................22 6.2.1 Mapping..........................................................................................................................23 6.2.2 De stylesheets.................................................................................................................23 6.2.3 De website......................................................................................................................24 7. Conclusies en aanbevelingen.........................................................................................................25 7.1 Conclusies...............................................................................................................................25 7.2 Aanbevelingen........................................................................................................................25 Bijlage I Gebruikte standaarden........................................................................................................26 Bijlage II Een voorbeeld bericht........................................................................................................28
1. Inleiding In bedrijfsprocessen is communicatie een onmisbaar element. Er wordt gecommuniceerd tussen mensen onderling, tussen mens en computer en tussen computers onderling. Voor de communicatie tussen mensen (of beter tussen bedrijven onderling in deze context) wordt veelal nog gebruik gemaakt van papieren documenten. Slechts de grote bedrijven die in staat zijn om in dure back-end systemen te investeren, zijn tot op grote hoogte in staat om de communicatie ten behoeve van de bedrijfsprocessen te digitaliseren. Gebruik makend van de ervaring die hij heeft op het gebied van standaardisering doet de heer Blommestein onderzoek naar methoden om digitaal dataverkeer te ten behoeve van e-commerce te flexibiliseren. De opdracht die ik uitvoer maakt deel uit van dit onderzoek. In hoofdstuk twee zal ik ingaan op de geschiedenis van het gebruik van digitale berichten in de handelssector en de standaarden die hiervoor ontwikkeld zijn. Zo kan het onderzoek beter in de context geplaatst worden en kan beter inzicht verkregen worden in de toepassing ervan. Dan zal ik in hoofdstuk drie verder inzoomen op het onderzoek zelf. Er zal hier verder ingegaan worden op de onderdelen waaruit het onderzoek bestaat en welke plek de uitgevoerde opdracht heeft binnen dit onderzoek. In hoofdstuk vier worden eerst de opdrachtomschrijving en de doelstelling geformuleerd. Daarna zullen de randvoorwaarden die gelden voor dit project uiteengezet worden. Ook zal er ingegaan worden op zaken als meetbaarheid, werkzaamheden en de ontwikkelmethodiek. Tevens is een globale planning opgenomen. Na het plan van aanpak komt in hoofdstuk vijf het functioneel ontwerp. Hier zal eerst dieper ingegaan worden op de context van het product. Vervolgens wordt het functioneel ontwerp zelf uiteengezet. In hoofdstuk zes zullen de behaalde resultaten en tevens de werkzaamheden die uitgevoerd zijn om tot deze resultaten te komen worden toegelicht. Tenslotte zijn in hoofdstuk zeven de conclusies te vinden.
5
2. Geschiedenis Handel wordt al sinds mensenheugenis gedreven. Om een context te schetsen waarin mijn opdracht geplaatst kan worden, wil ik me beperken tot de ontwikkeling van internationale afspraken met betrekking tot handel in de laatste vijftig jaar. In 1947 werd de United Nations Economic Commission for Europe4 (UNECE) opgericht. Dit is gedaan met als doel de handel tussen de lidstaten van de Verenigde Naties te stimuleren. Er zijn momenteel 55 lidstaten, met naast een groot aantal Europese landen ook landen als de Verenigde Staten, Canada en Israël. Deze commissie houdt zich onder andere bezig met het opstellen van standaarden die betrekking hebben op handel. Hierbij kan gedacht worden aan de opmaak van handelsdocumenten, de inhoud van berichten en methoden om bedrijfsgegevens te modelleren. In de jaren '60 heeft de UNECE een werkgroep opgezet om een standaard te ontwikkelen voor de layout van handelsdocumenten. Dit heeft geleid tot de United Nations Layout Key, die later is aangenomen als ISO standaard voor de opmaak van handelsdocumenten (ISO 6422). Deze standaard heeft er aan bijgedragen dat de efficiëntie van de handel verbeterd werd. Met de opkomst van digitale netwerken werden de handelsberichten ook meer en meer gedigitaliseerd. Daarom werd er een standaard ontwikkeld voor digitale gestructureerde data uitwisseling. Deze standaard heet EDI wat staat voor Electronic Data Interchange. EDI-berichten bevatten dezelfde data die voorheen met papieren documenten verzonden werden en vervullen dan ook dezelfde functie als deze documenten. EDI is niet beperkt tot handel maar omvat ook gebieden als medische gegevens, transport en engineering. Er zijn twee grote EDI-standaarden. UN/EDIFACT is de enige internationale standaard en is het meest gebruikt in alle gebieden buiten Noord Amerika. In Noord Amerika wordt voornamelijk de ANSI ASC X12 gebruikt. De UNECE definieert EDI als: “Een set van internationaal overeengekomen standaarden, indexen en richtlijnen voor de elektronische uitwisseling van gestructureerde data, en in het bijzonder de uitwisseling gerelateerd aan handel in goederen en services tussen onafhankelijke, geautomatiseerde systemen.”5 kan in de praktijk alleen gebruikt worden door grote bedrijven. Dit komt doordat de software voor het gebruik van EDI complex en duur is. Er moet veel geld gestoken worden in de infrastructuur en het opzetten van data-uitwisseling tussen twee bedrijven. Kleine bedrijven en (bedrijven in) ontwikkelingslanden zijn nooit in staat geweest deze technologie te gebruiken en missen daardoor de voordelen die deze technologie oplevert. Met de opkomst van het internet is er een infrastructuur gekomen die ook betaalbaar is voor kleine bedrijven en tevens toegankelijk is voor ontwikkelingslanden. Daarnaast biedt de opkomst van XML-technologieën, zoals XSLT, XPATH en XFORMS, nieuwe mogelijkheden voor communicatie waardoor de drempel voor gebruik lager wordt. Een belangrijke reden hiervoor is dat deze technologieën ondersteund worden door de veelgebruikte browsers. EDI
Hoewel EDI een cruciale component was voor de ontwikkeling van de elektronische handel bleek eind jaren '90 dat de elektronische handel faalde om als globale oplossing te dienen voor de 'papieren berg' in de handelssector. Als antwoord op het toegenomen gebruik van informatie- en communicatie-technologieën door zowel overheden als de handelssector, zette het UNECE het United Nations electronic Trade Documents (UNeDocs) project op om de documentatie 4 http://www.UNECE.org/ 5 http://www.UNECE.org/trade/untdid/texts/d100_d.htm
6
problematiek van de handelssector te analyseren en oplossingen te ontwikkelen. Het UneDocs project ontwikkelt een elektronisch equivalent van papieren handelsdocumenten. Deze standaard is gebaseerd op de United Nations Layout Key. De documenten worden beschreven in XML-documenten waardoor ze met behulp van stylesheets kunnen worden omgezet naar verschillende formaten zoals html, pdf of Microsoft infopath. Het United Nations Centre for Trade Facilitation and Electronic Business6 (UN/CEFACT), een onderdeel van het UNECE, is momenteel bezig met het creëren van een bibliotheek met beschrijvingen van standaard XML-berichten voor internationale handel. Deze standaard is gebaseerd op de Core Component Specificatie die ook door UN/CEFACT is ontwikkeld. Dit is een specificatie voor het modelleren van data in bedrijfsprocessen. Ook wordt er onderzoek verricht naar technieken waarmee het mogelijk is om berichten die gemodelleerd zijn met behulp van UML om te zetten naar zowel EDI- als XML-berichten. Omdat beide soorten berichten vanuit hetzelfde model gegenereerd worden, wordt het mogelijk om EDI- en XMLberichten één op één te mappen.
6 http://www.UNECE.org/cefact/
7
3. Context De opdracht die ik voor mijn afstuderen uitvoer gebeurt in het kader van het promotie onderzoek van de heer. F. van Blommestein. Hij doet onderzoek naar methoden om digitale communicatie tussen bedrijven flexibeler te maken. In het vorige hoofdstuk heb ik globaal de geschiedenis geschetst van de ontwikkeling van digitale communicatie in en ten behoeve van bedrijfsprocessen. In dit hoofdstuk zal ik ingaan op het onderzoek van dhr. Blommestein en dit onderzoek in het kader van de geschetste ontwikkeling plaatsen. Mijn afstudeerproject maakt deel uit van het promotieonderzoek waar dhr. Blommestein momenteel mee bezig is. Zijn onderzoek is op te delen in drie delen, namelijk: 1. Het bedrijfsproces in de berichtenschema's vastleggen. 2. Het ontwikkelen van een semantiek om toekomstige berichten uit te breiden. 3. Een mechanisme creëren om het uitwisselen van berichten toegankelijk te maken voor het midden- en kleinbedrijf door het te baseren op XSLT en XFORMS.
3.1 Bedrijfsproces in schema's Voor het leveren van producten en diensten moet er het een en ander gebeuren voordat de dienst of het product daadwerkelijk geleverd kan worden. De stappen die uitgevoerd moeten worden om tot het product of de dienst te komen, moeten in een bepaalde volgorde uitgevoerd worden. Dit geldt binnen het bedrijf maar ook in de communicatie met andere bedrijven. Bij elke overgang naar de volgende stap vindt er overdracht van informatie plaats. Dit kan geïllustreerd worden aan de hand van een eenvoudig voorbeeld: “Een klant van een chemiebedrijf bestelt 1000 liter spiritus en wil deze geleverd hebben in flessen van één liter verpakt in dozen van 10 flessen. Als de order binnen komt bij het bedrijf verstuurt de persoon (of het systeem) die de order ontvangt een bevestiging van de order met een geschatte leverdatum.”
8
Dit voorbeeld van een bedrijfsproces kan verduidelijkt worden met het sequencediagram in figuur 3.1.
Figuur 3.1: Sequence diagram van een vereenvoudigd bedrijfsproces Hoewel dit voorbeeld slechts een klein deel van het proces beschrijft dat nodig is om de 1000 flessen bij de klant te krijgen, is duidelijk te zien dat er verschillende acties zijn met informatieoverdracht. Het is duidelijk dat het sturen van een orderbevestiging niet zinnig is als er geen order geplaatst is. Ook dat het onzinnig is om een orderbevestiging te sturen van een order die niet door de klant geplaatst is. Momenteel is het zo dat de gegevens die verstuurd worden (de informatieoverdracht) los staan van het bedrijfsproces. Het bedrijfsproces en de inhoud van berichten worden in verschillende documenten beschreven. Dit is één van de onderwerpen van het onderzoek van dhr. Blommestein. Hij onderzoekt hoe de beschrijvingen van de berichten op een dusdanige manier kunnen worden aangepast dat hier niet alleen in te vinden is hoe bijvoorbeeld een orderbevestiging eruit ziet, maar ook welke informatie nodig is voordat een specifieke orderbevestiging daadwerkelijk gecreëerd mag worden. Er wordt dus gekeken hoe en welke informatie in berichten opgenomen moet worden zodat voor beide partijen duidelijk is in welke volgorde berichten verstuurd en ontvangen mogen worden.
3.2 Het ontwikkelen van een semantiek De berichten die ten behoeve van een bedrijfsproces verstuurd worden, kunnen worden gemodelleerd met behulp van de Core Component standaard die ontwikkeld is door UN/CEFACT7. Dat is de situatie waar in dit verslag vanuit gegaan wordt, hoewel er ongetwijfeld ook andere standaarden bestaan voor het modelleren van deze gegevens. De reden hiervoor is dat deze standaard precies bedoeld is om de informatieoverdracht tussen bedrijven te modelleren terwijl 7 Een eenvoudig voorbeeld hiervan is uitgewerkt in bijlage II.
9
andere standaarden op dit gebied alleen gericht zijn op interne bedrijfsgegevens. Juist deze eigenschap van deze standaard draagt eraan bij om tot een bruikbaar resultaat te komen. Als twee bedrijven met elkaar zaken willen doen zullen ze met elkaar overeen moeten komen op welke manier dat gebeurt. Ze maken afspraken over levertijd, de betaalmethode, annulering etc. Het probleem hierbij is dat als in de loop van het proces deze afspraken veranderen, ook de schema's van de berichten aangepast moeten worden. Dit wil ik nogmaals illustreren aan de hand van een voorbeeld: “Het bedrijf dat de spiritus bestelde, heeft zo'n grote afname van dit product dat het niet elke keer opnieuw wil bestellen. Daarom wordt besloten dat er altijd spiritus op voorraad moet zijn. Als de voorraad onder een vastgestelde grens komt moet er een bericht gestuurd worden naar de leverancier die de voorraad dan aanvult met een afgesproken hoeveelheid.” Dit voorbeeld kan verduidelijkt worden met het sequencediagram in figuur 3.2.
Figuur 3.2: Sequence diagram van het aangepaste bedrijfsproces
Het is duidelijk dat er na doorvoering van deze verandering andere berichten gestuurd worden dan in de voorgaande situatie. Er wordt geen order meer geplaatst maar een bericht gestuurd dat de voorraad onder het afgesproken niveau is gedaald. Onder de huidige omstandigheden betekent deze verandering dat beide partijen met elkaar af moeten spreken hoe deze nieuwe set van van berichten eruit gaat zien en moeten deze berichten geïmplementeerd worden in het systeem. Waar de heer. Blommestein onderzoek naar doet is hoe deze veranderingen in het bedrijfsproces op een dynamische manier geïmplementeerd kunnen worden. Hij wil hiervoor een semantiek (een soort taal) ontwikkelen die het mogelijk maken om dit soort veranderingen te beschrijven in berichten. Hierdoor wordt het mogelijk om in de loop van het proces deze veranderingen door te voeren zonder dat daar veel daadwerkelijke implementatie aan te pas hoeft te komen.
10
3.3 Uitwisseling van berichten baseren op veelgebruikte standaarden Het derde deel van zijn onderzoek is het ontwikkelen van een mechanisme waardoor het uitwisselen van berichten makkelijker te implementeren is. Hierdoor zijn niet alleen grote organisaties met geavanceerde back-end systemen om het berichtenverkeer af te handelen, in staat om deel te nemen aan het digitale handelsverkeer maar ook het midden- en kleinbedrijf moet hierdoor kunnen deelnemen aan het digitale handelsverkeer. Er moet dus een oplossing komen die in staat is om berichten te creëren die voldoen aan de Core Components standaard. Tevens moet deze oplossing toegankelijk zijn voor het midden- en kleinbedrijf. Zo kunnen er namelijk berichten gecreëerd worden door het midden- en kleinbedrijf waar grote bedrijven al mee overweg kunnen. De implementatie van dit systeem moet zoveel mogelijk gebaseerd zijn op algemeen geaccepteerde open standaarden. Zo kan er een generieke oplossing gecreëerd worden die niet afhankelijk is van dure software.
3.4 Gewenste onderzoeksresultaten Als het onderzoek van de heer Blommestein is afgerond en de aangedragen oplossingen geïmplementeerd zouden zijn, dan zou de volgende situatie ontstaan bij bedrijven die gebruik maken van deze oplossing. Allereerst zijn deze bedrijven in staat om aan de hand van de reeds ontvangen berichten en de berichtbeschrijvingen die gelden voor deze berichten te bepalen welke berichten verzonden mogen worden. Daarnaast zijn ze in staat om met berichten de afgesproken volgorde van berichten te veranderen. Zelfs dit proces, het onderhandelen over het nieuwe proces kan via deze berichten gedaan worden. Tenslotte zijn bedrijven, die geen backend-systemen hebben om deze berichten af te handelen, in staat om formulieren te genereren aan de hand van de beschrijvingen.
11
4. Plan van aanpak 4.1 Opdrachtomschrijving In het vorige hoofdstuk heb ik in grote lijnen uiteengezet wat het onderzoek van de heer Blommestein inhoudt. Mijn opdracht heeft betrekking op het derde onderdeel van zijn onderzoek (zie hoofdstuk drie paragraaf drie). Het gaat om het ontwikkelen van een mechanisme dat het creëren van berichten ook mogelijk maakt als er slechts een browser beschikbaar is. Hierbij moet gebruik gemaakt worden van standaarden die algemeen geaccepteerd en geïmplementeerd zijn/worden. De berichten waarover gesproken wordt zijn XML-berichten die voldoen aan de naming and design rules8 standaard van UN/CEFACT. De inhoud van deze berichten wordt beschreven met behulp van een XML-schema9. Deze schema's schrijven voor welke elementen er in een bericht voor mogen komen, van welk type deze elementen moeten zijn, of ze verplicht zijn, etc. Deze schema's moeten gebruikt worden om een XHTML document te genereren waarin een XFORMS10 formulier is opgenomen. XFORMS is een standaard die ontwikkeld is door de standaardisatie organisatie w3c en wordt als opvolger beschouwd van de huidige (X)HTML formulieren. Voor de generatie van deze formulieren moet gebruik gemaakt worden van XSLT. Hier is door de heer Blommestein voor gekozen omdat deze techniek al in de meeste browsers aanwezig is. In combinatie met XFORMS, waar ook browser-plugins voor zijn ontwikkeld, ontstaat zo een krachtige combinatie waarvoor de drempel om het te gaan gebruiken laag is. De XML-schema's waarmee de formulieren gegenereerd moeten worden, zeggen uitsluitend iets over de inhoud van het bericht. Daarom moet er ook een annotatie-bestand ontwikkeld worden dat bij het genereren van het bericht gelezen wordt. Hierin staat informatie over de opmaak van het bericht en standaardwaarden voor bepaalde items in het bericht. 4.1.1 Doelstelling Samenvattend is de doelstelling voor dit project als volgt te formuleren: Creëer een applicatie met behulp van XSLT die de aangeleverde berichtschema's kan transformeren naar XHTML documenten voorzien van XFORMS formulieren. Er moet daarbij een systeem ontwikkeld worden waarmee de gebruiker in staat is om standaardwaarden en opmaak-eigenschappen van het formulier aan te passen. De XFORMS formulieren moeten nadat ze ingevuld zijn door de gebruiker een XML-bericht genereren dat voldoet aan het schema aan de hand waarvan het formulier gegenereerd is. De voorbeelden zullen worden samengesteld door de heer Blommestein en representeren samen een bedrijfsproces.
4.2 Randvoorwaarden Bij het uitvoeren van deze opdracht gelden een aantal randvoorwaarden waaraan voldaan moet 8 Zie bijlage I -gebruikte standaarden 9 Zie bijlage I -gebruikte standaarden 10 Zie bijlage I -gebruikte standaarden
12
worden. Deze voorwaarden zet ik hier uiteen met waar nodig een toelichting. 4. Het resultaat moet een met XFORMS verrijkt XHTML document zijn. Toelichting: Andere mogelijkheden zijn bijvoorbeeld het gebruik van gesloten software zoals Microsoft infopath of Adobe Acrobat. Voorbeelden hiervan zijn te vinden op de site van het UNeDocs project (http://www.unece.org/etrades/unedocs/). Nadeel hiervan is dat de gebruiker dan gebonden wordt aan third party software met gesloten standaarden. Hierdoor worden de mogelijkheden van gebruik behoorlijk ingeperkt. 5. De stylesheet moet geschikt zijn voor alle schema's die voldoen aan de naming and design rules standaard (een standaard die beschrijft hoe core components in een XML-schema genoteerd moeten worden). Toelichting: De voorbeelden genoemd bij het vorige punt werken alleen voor een specifiek bericht zoals de Fiata Forwarding Instruction in het pdf voorbeeld. De ontwikkelde stylesheet zal niet werken als het schema van de Fiata Forwarding Instruction wordt aangepast en zal zeker niet werken voor andere schema's. Dit is een van de grote problemen waarmee het UNeDocs momenteel kampt en waar de heer Blommestein op in wil springen met het te bouwen product. 6. De schema's moeten voldoen aan de standaard. Toelichting: Dit lijkt triviaal maar is zeker het vermelden waard. Dhr. Blommestein heeft een prototype ontwikkeld dat aantoont dat het mogelijk is om bepaalde mechanismen te implementeren die nodig zijn om onder andere de opmaak van een component te bepalen. Hij heeft hiervoor echter aanpassingen gedaan in het schema op een manier waarop in de nieuwste versie van de standaard uitdrukkelijk vermeld staat dat het betreffende element (het zogenaamde app-info element) niet gebruikt mag worden. Er zal dus een andere manier gevonden moeten worden om annotatie-gegevens te koppelen aan een schema. Verder moet opgemerkt worden dat het er vooral om gaat dat het eindproduct aantoont dat de ideeën die de heer Blommestein heeft te implementeren zijn. Hij heeft nadrukkelijk gezegd dat het niet om een product gaat dat gereed is om op de markt gebracht te worden. Daarom liever een product dat veel features demonstreert dan een door en door getest systeem met een beperkt aantal features.
4.3 Meetbaarheid Nu het duidelijk is wat de opdracht is en welke randvoorwaarden gelden, moet duidelijk worden hoe aangetoond kan worden dat aan deze opdracht is voldaan. Daarom wil ik aan de hand van de opdrachtomschrijving en de randvoorwaarden een aantal eisen omschrijven die getest kunnen worden aan het eind van het project. 1. De XSLT-stylesheet kan de geleverde voorbeelden transformeren naar een XHTML document met een XFORMS formulier. 2. Aanpassingen in het mechanisme om de opmaak en standaardwaarden te veranderen hebben als resultaat dat deze zichtbaar zijn in het formulier nadat dit opnieuw gegenereerd is. 3. De look-up methode voor het vinden van parameters voor een bepaald element, dat in het prototype van de heer Blommestein is ingebouwd, werkt ook in het eindproduct. Toelichting: Deze methode heeft te maken met de overerving-structuur die in de XMLschema's wordt gehanteerd. Deze structuur heeft wat weg van overerving in object georiënteerde omgevingen met dit verschil dat overerving geen uitbreiding maar inperking betekent.
13
4. De formulieren waarschuwen de gebruiker als er waarden ingevuld worden die niet toegestaan zijn volgens het schema. 5. De berichten die worden gegenereerd door de XHTML-documenten op basis van de ingevulde informatie zijn geldige instanties van de schema's waarnaar ze verwijzen. Toelichting: Dit kan getest worden met zogenaamde XML-schema validators die een XMLdocument controleren aan de hand van een schema.
4.4 Werkzaamheden Om tot een planning te komen is het belangrijk te onderscheiden welke taken er uitgevoerd moeten worden. Allereerst zal ik me moeten verdiepen in de standaarden die gebruikt worden. Dat betekent het doorlezen van de verschillende standaarden. De meest belangrijke zijn de Core Components standaard, de naming and design rules standaard, de XSLT standaard en de XFORMS standaard. Omdat XSLT en XFORMS beide XML-gebaseerde technieken zijn, zal ik ook een aantal tutorials moeten doornemen om meer inzicht te krijgen in de werking van deze technieken. Een basiskennis van XML is al wel aanwezig maar het ontwikkelen van applicaties met behulp van XML verschilt wezenlijk van het ontwikkelen van applicaties met behulp van derde generatie programmeertalen. Dit wordt onder andere duidelijk in het feit dat het in XSLT stylesheets niet mogelijk is om dynamische variabelen te gebruiken. Zoals vermeld wordt er binnen de schema's gebruik gemaakt van een overervingstructuur. In de core component standaard worden 11 typen gedefinieerd die unqualified datatypes worden genoemd. Deze typen kunnen verder ingeperkt worden en worden daardoor gekwalificeerd. Daarnaast zijn er nog componenten die een verzameling van deze typen omvatten (Aggregate Components) en componenten die verwijzen naar een datatype of een Aggregate Component. Deze worden Association Components genoemd. Om te bepalen hoe deze typen weergegeven kunnen worden met behulp van XFORMS zal er een mapping gemaakt moeten worden. Dit dient er allereerst voor om te bepalen welke code gegenereerd moet worden door de XSLT. Daarnaast biedt het de gelegenheid meer inzicht te krijgen in de werking van XFORMS. En tenslotte wordt ook duidelijker welke opties er zijn voor het aanpassen van uiterlijke zaken en het bepalen van standaardwaarden. Tenslotte moet de stylesheet gemaakt worden die de schema's omzet in XHTML documenten. De heer Blommestein zal in de tussentijd de voorbeeldschema's maken. Zolang die er nog niet zijn, zal gebruik gemaakt moeten worden van een zeer eenvoudig voorbeeld dat voor het prototype gebruikt is. Deze moet nog wel aangepast worden aan de nieuwste versie van de naming and design rules.
4.5 Planning De werkzaamheden zoals hierboven beschreven moeten worden uitgevoerd in de periode van 1804-2006 tot 28-8-2006. In tabel 1 heb ik een globale planning weergegeven van de werkzaamheden zoals hierboven beschreven. Zoals te zien is in de tabel is er geen specifieke tijd ingepland voor testen. Hier zijn twee redenen voor. Ten eerste is het product zoals eerder vermeld in eerste instantie niet als een markt gereed product bedoeld. Het demonstreren van features is belangrijker dan een door en door getest product. De tweede reden is dat er in feite tijdens het ontwikkelen constant getest wordt. Na aanpassingen in de stylesheet zal deze uitgevoerd worden om te kijken of deze verandering ook de gewenste resultaten oplevert. Week
Datum
Werkzaamheden
16 (1)
18-4-2006
Standaarden lezen en geschikte tutorials zoeken/doornemen.
17 (2)
24-4-2006
18 (3)
1-5-2006
19 (4)
8-5-2006
Mapping maken van Core Corecomponents naar XFORMS.
14
20 (5)
15-5-2006
21 (6)
22-5-2006
22 (7)
29-5-2006
23 (8)
5-6-2006
24 (9)
12-6-2006
25 (10)
19-6-2006
26 (11)
26-6-2006
27 (12)
3-7-2006
28 (13)
10-7-2006
29 (14)
17-7-2006
30 (15)
23-7-2006
31 (16)
31-7-2006
32 (17)
7-8-2006
33 (18)
14-8-2006
35 (20)
28-8-2006
34 (19) 21-8-2006 Stylesheet ontwikkelen en testen.
Oplevering eindproduct.
Tabel 1: Globale planning 4.6 Ontwikkelmethodiek Tenslotte rest nog de keuze voor een geschikte software-ontwikkelmethodiek. Om tot een verantwoorde werkwijze te komen wil ik eerst nagaan welke aspecten meewegen in het kiezen van een methodiek. Daarna zal ik kijken welke ontwikkelmethodiek het best aansluit bij deze aspecten. Tenslotte zal ik de gebruikte werkwijze evalueren. 4.6.1 Meegewogen aspecten Bij het kiezen van een ontwikkelmethode hebben een aantal aspecten meegespeeld. Het eerst aspect is het feit dat de opdrachtgever nadrukkelijk gezegd heeft dat het in deze opdracht om de featurres van het product gaat. De kwaliteit van het product en de gebruikte methode om tot het product te komen zijn van ondergeschikt belang hieraan. Een ander aspect is het feit dat ik de opdracht alleen moest uitvoeren. Dat betekent dat alle taken die in een ontwikkelmethodiek aan bod komen per definitie door mij uitgevoerd moeten worden. En gezien het feit dat de nadruk meer ligt op het product dan op het proces zal ik ook in de toepassing van de gekozen methodiek weinig tot geen aandacht schenken aan procesdocumentatie. Vanwege de aard van het product (onderdeel van een onderzoek) staat onderhoud in feite gelijk ontwikkeling. Het product is nooit klaar maar staat altijd onder invloed van de voortgang van het onderzoek. Onderhoud is daardoor in feite niet echt een issue omdat onderhoud doorontwikkeling betekent. Onderhoud gaat pas spelen als het product commercieel ingezet gaat worden en ik hoef er geen rekening mee te houden dat dit plaats zal vinden in de periode dat ik aan het afstuderen ben. Het laatste aspect dat ik hier wil noemen is het feit dat het voor mijn opvolger relatief makkelijk moet zijn om het werk weer op te pakken vanaf het punt waarop ik het achtergelaten heb. Hiervoor is het belangrijk dat bekend is welke documenten belangrijk zijn en hoe het product zich ontwikkeld heeft.
15
4.6.2 Gekozen werkwijze Er zijn verschillende methodieken ontwikkeld om het softwareontwikkelproces vorm te geven en te beheersen. Bekende voorbeelden hiervan zijn het waterval model, extreme programming (XP), prototyping en rapid application development (RAD). Het waterval model schrijft een strakke afbakening van de processtappen en de volgorde van deze stappen voor. Dit is een grote belemmering voor het project omdat de eisen voor het product in grote mate veranderlijk zijn. Extreme programming en rapid application development hebben wel wat weg van elkaar. Beide werken met korte iteraties waarin nieuwe features worden toegevoegd en leggen nadruk op het belang van teamleden. Hierin zitten elementen die van belang zijn voor mijn project. Hoewel ik alleen werk, heb ik al aangegeven dat het voor de opvolger relatief eenvoudig moet zijn om het werk op te pakken. Het delen van kennis is daarom belangrijk. Ook het toevoegen van features in iteraties is een eigenschap die goed van toepassing is op de uit te voeren opdracht. Uiteindelijk heb ik gekozen voor een werkwijze die sterk lijkt op RAD. Hoewel ik dit niet bewust aan het begin van het project heb gedaan, is dit gegroeid vooral door het gebruik van de trac website die ik opgezet heb. Op deze manier heb ik geprobeerd om, ondanks de ontbrekende voorzieningen op het gebied van ondersteunende tools voor softwareontwikkeling, op een gestructureerde manier te werken. 4.6.3 Evaluatie werkwijze Ik ben afgeweken van RAD op het punt van iteraties. Hoewel ik wel feature voor feature heb toegevoegd, heb ik dit niet gedaan met een strakke planning van de iteraties. Dit had te maken met het feit dat ik niet zo goed bekend was met XSLT en de core components standaard dat ik een betrouwbare schatting zou kunnen maken van de tijd die nodig is voor een bepaalde feature. De trac website heeft veel bijgedragen aan het bijhouden van documentatie. Issues waar ik tegen aanliep konden snel gedocumenteerd worden. Het heeft relatief weinig tijd gekost om een lijst met belangrijke documenten aan de site toe te voegen. Omdat trac gekoppeld is aan de Subversion11 (SVN) repository, biedt het de mogelijkheid om op verschillende manieren de SVN-repository te bekijken. Door het toevoegen van zinnig commentaar aan een SVN-commit en de mogelijkheden die trac biedt is het vrij eenvoudig om een beeld te krijgen van de ontwikkeling die het product heeft doorgemaakt. Door deze manier van werken is er een centraal punt ontstaan waar de code en de documentatie te vinden zijn. Dit is daardoor een goed startpunt voor mijn opvolger. Een van de dingen waar ik tegen aangelopen ben, is het feit dat ik de enige ben geweest die het product getest/gebruikt heeft. Hierdoor zijn er minder bugs aan het licht gekomen dan anders waarschijnlijk gebeurd zou zijn. De trac website biedt goede mogelijkheden voor het melden van bugs en het bijhouden van de status. Het zou geholpen hebben als er een meer complete set voorbeeld documenten was of als er meer mensen zouden zijn die het product zouden testen. Een ander punt is dat het schatten van de tijd voor de implementatie van features lastig was. Hierdoor had ik geen goed beeld van hoever ik zou komen met de implementatie van het product. Hier heeft mijn eigen onervarenheid op dit gebied meegespeeld en verder het feit dat er geen voorzieningen waren op het gebied van procesmanagement.
11 Subversion is een versie beheersysteem voor broncode. ( http://subversion.tigris.org)
16
5. Functioneel ontwerp In dit hoofdstuk wil ik dieper ingaan op de functionele specificaties van het product dat ontwikkeld moet worden. Daarom zal ik eerst het proces schetsen waar het product onderdeel van is.
5.1 Product context Omdat het te ontwerpen product deel uit maakt van een breder proces is het belangrijk dit proces te schetsen om een beter beeld te krijgen van het te bouwen product. In de doelstelling werd aangegeven dat het product XML-schema documenten moet transformeren naar xHTML documenten met XFORMS-formulieren waarmee de gebruiker vervolgens in staat is om berichten te genereren die verstuurd kunnen worden. De doelgroep voor het product is in eerste instantie de e-business markt. En het gaat hierbinnen specifiek over twee handelspartners die berichten met elkaar uitwisselen. Om te begrijpen wat de inhoud van een bericht betekent, worden eenduidige afspraken gemaakt over de inhoud van deze berichten. Deze afspraken worden vastgelegd in XML-schema's. Beide partners hanteren dezelfde set schema's voor hun berichten. Dit wordt aangegeven door de gevulde en gesloten pijlen in figuur 5.1. De niet gevulde en gesloten pijl geeft aan dat de XML-berichten voldoen aan de XML-schema's.
Figuur 5.1: Schematische weergave communicatie
Figuur 5.1 geeft slechts een globaal overzicht van het berichtenverkeer. De XML-berichten zijn instanties van de XML-schema's. Beide groepen zijn echter XML-documenten. Daarom hebben ze hetzelfde symbool. Ze verschillen alleen conceptueel van elkaar. Het is ook niet de bedoeling om hier aan te geven in welke volgorde de berichten komen of wat precies de inhoud van deze berichten moet zijn. Wel wil ik nog verder inzoomen op het verzenden en ontvangen van deze berichten. Hoewel de berichten van beide bedrijven moeten voldoen aan de XML-schema's die gebruikt moeten worden, zegt dit niets over de manier waarop deze berichten gegenereerd worden. Dit kan verschillen per bedrijf. 17
Zoals ik in de inleiding al aangaf, wordt het elektronische dataverkeer voornamelijk gegenereerd door EDI-systemen. En dit geldt dan ook nog eens voornamelijk voor grote berichtstromen die weinig veranderlijk zijn. Het onderzoek van de heer Blommestein is erop gericht om ook meer veranderlijke berichten digitaal te gaan verzenden. En tevens om het midden en kleinbedrijf de mogelijkheid te bieden deel te nemen aan het digitale handelsverkeer. Ter illustratie ga ik er vanuit dat in figuur 5.1 bedrijf 1 een bedrijf is dat EDI geïmplementeerd heeft en bedrijf 2 een kleine klant met een XML oplossing. De XML-berichten voldoen aan een standaard die gebaseerd is op een modelleertechniek waarmee ook EDI-berichten gemodelleerd kunnen worden. De XML-berichten die bedrijf 1 ontvangt, kunnen daardoor relatief eenvoudig omgezet worden naar EDI-berichten zodat deze verder verwerkt kunnen worden door het systeem. De focus van de opdracht zal echter meer liggen bij bedrijf 2. Dit is tenslotte een belangrijk deel van de groep waarbinnen de problemen spelen die onderdeel zijn van het onderzoek van dhr. Blommestein. Daarom wil ik verder inzoomen op de verwerking van berichten binnen bedrijf 2.
Figuur 5.2: Bericht afhandeling
Figuur 5.2 is een schematische voorstelling van de berichtafhandeling in bedrijf 2. Hierbij moet vermeld worden dat dit de gewenste situatie is. Het onderzoek van de heer Blommestein is gericht op de haalbaarheid van deze situatie. Er zijn een aantal zaken die belangrijk zijn. Allereerst de vermelding dat de XML-schema's pre- en post condities bevatten. Dit is nodig om het bedrijfsproces vast te leggen in de schema's. Hoewel hier nog nader onderzoek naar gedaan moet worden, is al
18
wel aangetoond dat het mogelijk is om condities op te nemen in XML-schema's en deze te gebruiken12. Verder valt op dat er twee mechanismen nodig zijn. Hoewel ze gescheiden weergegeven zijn in het schema kunnen ze op implementatieniveau bij elkaar gebracht worden. Ik heb ze gescheiden om twee redenen. De eerste reden is dat ze conceptueel van elkaar verschillen, de tweede reden is dat mijn opdracht gericht is op het tweede mechanisme. Gezien de complexiteit van het geheel is dit in overleg met de opdrachtgever besloten. Voor beide mechanismen zijn zowel de XML-schema's als de instanties (de reeds ontvangen berichten) nodig. In het eerste geval omdat het alleen mogelijk is om te bepalen welke berichten gestuurd mogen worden als bekend is welke reeds ontvangen zijn. Ook moet bekend zijn welk bericht als antwoord op een ontvangen bericht gestuurd mag worden. In het tweede geval wordt het schema gebruikt om te bepalen welke componenten het te genereren formulier moet bevatten. De ontvangen berichten worden gebruikt om het te genereren bericht aan te vullen met informatie die reeds bekend is.
5.2 Functioneel ontwerp Nu de context waarin het product plaats moet krijgen duidelijk is, wil ik verdergaan met het functioneel ontwerp. Zoals duidelijk is geworden in de vorige paragraaf zal het product op zich zelf niet zo zinnig zijn. Het moet plaats krijgen in een groter geheel. Tevens wordt het product ontwikkeld in een onderzoeksomgeving. Het gaat er meer om dat het product aantoont dat bepaalde features te implementeren zijn, dan dat er een gebruiksklaar product afgeleverd wordt. De belangrijkste features wil ik hier behandelen en kort toelichten. Verder zal tijdens de implementatie moeten blijken welke mogelijkheden er zijn en welke beperkingen. 5.2.1 Stylesheet Allereerst moet het product bestaan uit een XSLT-stylesheet dat een XML-schema van een bericht transformeert naar een XHTML-document met daarin een formulier dat opgebouwd is met behulp van XFORMS. De gegenereerde formulieren moet worden gekoppeld aan de XML-schema documenten die gebruikt zijn om het formulier te genereren. Het schema wordt door de XFORMS-processor gebruikt om de ingevoerde data te controleren op correctheid. Ook het gegenereerde bericht wordt gekoppeld aan deze schema's zodat ook de ontvanger in staat is om te controleren of het bericht correct is. 5.2.2 Annotaties De gebruiker moet in staat zijn om de opmaak van het formulier te veranderen. Hiervoor moet een systeem ontwikkeld worden wat toegankelijk is voor een gebruiker (of toegankelijk gemaakt kan worden). Met deze annotaties kunnen eigenschappen van het formulier zoals achtergrondkleur, lettertypen, randen, positie, etcetera ingesteld worden. Hierbij moet wel gebruik gemaakt worden van de standaard voor het beschrijven van XML-schema's. De overervingsstructuur die in de naming and designrules beschreven wordt, moet worden gebruikt om delen van een bericht van bepaalde opmaak-eigenschappen te voorzien als deze gedefinieerd zijn en anders terugvallen op waarden die gedefinieerd zijn in hogere klassen. Tevens moet in het opmaakmechanisme gebruik gemaakt worden van skinning. Hiervoor zijn twee mechanismen nodig. Allereerst moet per core component type gezocht worden naar de waarde van een bepaalde opmaakeigenschap. Dit gebeurt door de hiërarchie van het type naar boven af te lopen. De waarden van de eigenschappen dienen functioneel beschreven te worden. Als een waarde gevonden wordt, moet vervolgens op documentniveau worden gekeken wat deze functionele 12 Dit is onder andere mogelijk m.b.v. Schematron. (http://www.schematron.com/)
19
waarde betekent. Een voorbeeld hiervan is uitgewerkt in par 6.2.2. Een voorbeeld hiervan is een randje om een element. Op typeniveau kan hiervoor bijvoorbeeld voor de eigenschap rand-dikte de waarde 'dik' uitkomen. Vervolgens moet het document (dit is het bericht dat verstuurd is, bijvoorbeeld een order) afgelopen worden om te kijken wat de waarde 'dik' betekent voor de eigenschap randdikte. En hier zou dan bijvoorbeeld 3px uit kunnen komen. Als de waarde 'dik' van eigenschap randdikte verandert zullen dus alle randen met de waarde 'dik' veranderen.
20
6. Werkzaamheden en resultaten In dit hoofdstuk wil ik toelichten welke producten er afgeleverd zijn en de staat waarin ze afgeleverd zijn. Maar eerst zal ik de werkzaamheden die ik verricht heb om tot deze producten te komen beschrijven en toelichten.
6.1 Verrichte werkzaamheden De eerste weken ben ik voornamelijk bezig geweest met het lezen van documentatie. Het ging vooral om de standaarden die gebruikt worden en moesten worden. Met name de core component standaard en de naming and design rules heb ik goed bestudeerd. De eerste beschrijft hoe de data gemodelleerd moet worden volgens deze standaard, en welke naamgeving hierbij gebruikt moet worden. Vooral het gedeelte over de naamgeving was belangrijk omdat de standaard van de naamgeving gebruikt wordt in het mechanisme voor het ophalen van opmaak-eigenschappen van het formulier dat gegenereerd wordt. De laatste beschrijft hoe de standaard toegepast moet worden om de berichten te beschrijven met behulp van XML-schema, een XML-standaard om de inhoud van XML-berichten te beschrijven. Deze standaard is ook belangrijk omdat aan de hand hiervan bepaald kan worden welke elementen in een berichtschema waar verwacht kunnen worden. Nadat ik enigszins vertrouwd begon te raken met de standaarden die betrekking hebben op de berichtschema's ben ik documentatie gaan lezen over XFORMS. Ook heb ik een aantal voorbeeld formulieren bestudeerd om inzicht te krijgen in het gebruik van deze standaard. Er zijn een aantal implementaties van deze standaard beschikbaar, zowel als browser plugin als stand-alone applicatie. De verschillende implementaties die ik bekeken heb, zijn een plugin voor Mozilla firefox, formfaces, formsplayer en een novell applicatie. Mijn voorkeur ging in eerste instantie uit naar de Mozilla plugin. Deze is net als de browser vrij verkrijgbaar wat goed aansluit bij het uiteindelijke doel van het onderzoek van de heer Blommestein (digitale communicatie toegankelijk maken voor midden en kleinbedrijf). Helaas is de huidige staat van deze implementatie nog niet dusdanig dat deze al gebruikt kan worden voor meer complexe XFORMS documenten. Voor zowel de formfaces als de novell implementatie geldt dat ik daar alleen de meegeleverde voorbeelden werkend kreeg. Eigen documenten kreeg ik niet werkend bij deze implementaties. Daarom is uiteindelijk gekozen voor de implementatie van formsplayer (www.formsplayer.com). Deze is gratis te downloaden van de site, na dertig dagen geeft deze echter formsplayer icoontjes weer in het formulier. Er kan een commerciële versie gekocht worden die dit niet doet. Ondanks dit biedt het toch een complete implementatie van de XFORMS standaard. Daarom heb ik uiteindelijk gekozen voor deze implementatie. Werken met één implementatie heeft als gevolg dat je niet weet of de XFORMS documenten ook in andere implementaties het gewenste resultaat hebben. Hier heb ik gezien de aard van het project geen rekening mee gehouden. De core component specificatie beschrijft elf datatypen die gebruikt worden als bouwstenen voor de berichten. Deze datatypen bestaan uit twee delen, allereerst het deel dat de inhoud bevat en ten tweede een set eigenschappen die iets vertellen over de inhoud. Een voorbeeld hiervan is het AmountType datatype. Dit type bevat bedragen (bijvoorbeeld de prijs van een product) en dit type heeft een eigenschap die currencyCode wordt genoemd. Het mag duidelijk zijn wat deze eigenschap over de inhoud verteld. Alle elementen in het bericht die getypeerd zijn als een van deze elf bevatten de informatie die door de gebruiker ingevoerd moet worden. Ze worden in de standaard Basic Bussiness Information Entities genoemd (BBIE). Verder bestaat een bericht uit nog 21
twee soorten elementen die de opbouw van het document bepalen. Omdat de BBIE's die een bericht gebruikt voorkomen de informatie bevatten die door de gebruiker ingevoerd moet worden, moesten deze elementen naar XFORMS elementen gemapped worden. Daarom heb ik voor elk datatype een XFORMS document gecreëerd die een weergave is van het type. Deze code heb ik later gebruikt bij de generatie van documenten. De mapping heeft meer inzicht gegeven in het gebruik van XFORMS. Alle bovengenoemde werkzaamheden dienden als voorbereiding voor de hoofdtaak: het creëren van een set stylesheets die in staat zijn om schema's die opgesteld zijn volgens de naming and design rules te transformeren naar een XFORMS document. De resterende tijd voor mijn werkzaamheden heb ik hiervoor gebruikt. Hoewel ik al wel eens met XSLT gewerkt had was er toch nog aardig wat tijd voor nodig om er echt vertrouwd mee te raken. Er waren een aantal zaken die ervoor gezorgd hebben dat ik minder snel vorderde dan ik aanvankelijk hoopte. 1. Allereerst is het erg lastig om stylesheets te debuggen. Hoewel er wel debuggers zijn voor XSLT, is het mij niet echt gelukt in deze periode om er op een dusdanige manier mee vertrouwd te raken dat het hielp bij mijn werkzaamheden. Hierdoor was het vaak lastig om te bepalen waar het fout ging als de stylesheet niet door de processor kwam, of als de uitvoer anders was dan verwacht. 2. Een tweede oorzaak ligt in het feit dat alle documenten XML-documenten zijn. De schema's zijn XML-documenten, de stylesheets zijn XML-documenten, en het resultaat is in feite ook een XML-document (XHTML + XFORMS). De verschillende documenten moeten worden opgesteld volgens een of meerdere standaarden. Hierdoor was het lastig om over te schakelen tussen de verschillende documenten. Vooral als een XFORMS formulier niet werkte, was het lastig te achterhalen waarom dat zo was. Hier kwam nog bij dat een formulier dat niet werkte een gegenereerd document is. In tegenstelling tot een document dat met de hand gemaakt en gewijzigd wordt is het bij een gegenereerd document moeilijker om te zien wat anders is ten opzichte van de vorige (door een wijziging in de stylesheet). De code van de stylesheets en de voorbeelden heb ik ondergebracht in een SVN-repository. (Dit is een applicatie om de wijzigingen in de code bij te houden, zodat bij problemen teruggeschakeld kan worden naar een vorige versie), Omdat op de universiteit deze faciliteiten niet geboden werden, heb ik dit eerst op mijn eigen pc gezet. Dit was echter geen optimale oplossing met betrekking tot backups en het feit dat ik in september de universiteit weer zou verlaten. Daarom ben ik opzoek gegaan naar een andere oplossing. Hierdoor kwam ik op http://opensvn.csie.org terecht. Een voordeel hiervan is dat hier niet alleen SVN aangeboden wordt maar ook een wiki en een bug tracking systeem. Daarom ben ik hier op overgestapt. Tevens heb ik de extra functionaliteiten die deze site biedt gebruikt om het een en ander te documenteren. Zo is er onder andere te lezen hoe mijn code gebruikt kan worden, een korte SVN handleiding en problemen in de standaard waar ik tegen aanliep en hoe ik deze omzeild/aangepast heb. Deze documentatie is in de eerste plaats handig voor dhr. Blommestein en in de tweede plaats voor degenen die na mij aan het product gaan werken.
6.2 Resultaten Het resultaat bestaat uit drie verschillende onderdelen. Het eerste onderdeel is een aantal files met daarin de mapping van core components naar XFORMS elementen. Het tweede deel is de set stylesheets die een XML-schema document transformeren naar een XFORMS document. Het derde deel is een website met documentatie.
22
6.2.1 Mapping Om bekend te raken met XFORMS en om uit te zoeken welke code voor welk core component type gegeneerd moest worden, ben ik begonnen met het maken van een mapping. Dat wil zeggen dat ik voor elke core component een xHTML-document verrijkt met XFORMS elementen heb gemaakt. Deze documenten komen niet meer helemaal overeen met de code die nu gegenereerd wordt door de stylesheets. Maar voor degenen die na mij aan dit product moeten werken is het een goed begin om een beeld te krijgen van de code die gegenereerd wordt en waarom deze gegenereerd wordt. De documenten zijn op de website geplaatst zodat ze makkelijk terug te vinden zijn. 6.2.2 De stylesheets Met de huidige staat van de stylesheets is naar mijn idee een stevige basis gelegd voor verdere uitwerking van de ideeën van de heer Blommestein. De laatste versie (0.1.1) is in staat zowel gekwalificeerde als ongekwalificeerde datatypen af te handelen. Dit houdt in dat de stylesheet een compleet formulier kan maken van de XML-schema's. Deze formulieren zijn tevens in staat om de ingevulde informatie om te zetten naar een XML-bericht dat voldoet aan het XML-schema aan de hand waarvan het formulier gegenereerd is. De datatypen die verwijzingen bevatten naar codelijsten halen deze codelijsten op, ook ingeperkte codelijsten worden opgehaald. Met het mechanisme om de opmaak van het formulier aan te passen is een begin gemaakt. In versie 0.1.1 zijn een aantal eenvoudige opmaakeigenschappen opgenomen. Hoewel deze wel werken, voldoen ze niet aan de eisen voor het eindproduct. Voor het eindproduct moeten de waarden van opmaakeigenschappen namelijk functioneel vastgelegd worden voor datatypen en moet op documentniveau worden gekeken naar de waarde van deze eigenschappen. Om een voorbeeld te geven: “Er wordt uitgegaan van een zeer eenvoudige order die bestaat uit een orderregel. De orderregel bevat een productbeschrijving (die ver niet van belang is voor het voorbeeld en een bedrag van het type Rug_ Euro_ AmountType. Een AmountType heeft voor de eigenschap border-width de waarde 'standaard', een Euro_ AmountType heeft de waarde 'dik' voor deze eigenschap en het type Rug_ Euro_ AmountType heeft geen waarde voor deze eigenschap. Nu moet eerst gekeken worden of er een waarde is gedefinieerd voor Rug_ Euro_ AmountType. Dat is in dit geval 'dik' omdat het geërfd wordt van Euro_ AmountType. Daarna moet op documentniveau gekeken worden wat dik betekent. Daarvoor wordt gekeken in de orderregel. Als er geen waarde gevonden wordt in de orderregel wordt tenslotte in de order gekeken.” Aan dit mechanisme ben ik begonnen maar op moment van schrijven is dit nog niet dusdanig geïmplementeerd dat het gedemonstreerd kan worden. Tevens heb ik me hierbij op dit moment gericht op eigenschappen die met behulp van CSS te regelen zijn. Er moeten in de toekomst ook eigenschappen ingesteld kunnen worden die niet met CSS te regelen zijn. Deze vereisen extra werk, eigenschappen die wel met CSS te regelen zijn kunnen toegevoegd worden zonder dat de stylesheets daarvoor aangepast hoeven te worden. Bij de implementatie heeft performance geen rol gespeeld. Dat wil zeggen dat ik daar op geen enkele manier rekening mee heb gehouden. Dit was ook niet nodig omdat het buiten de doelstelling van de opdracht viel om een product te maken dat gebruiksklaar is. Dat betekent dat afhankelijk van het systeem waarop de transformatie uitgevoerd wordt dit zo'n drie tot twintig seconden duurt. De XFORMS documenten worden snel trager naar gelang ze groter worden. Zoals misschien wel duidelijk is geworden, bestaat het product uit meerdere stylesheets. Dit is gedaan om voor een betere leesbaarheid te zorgen en om het geheel beter onderhoudbaar te maken. Waar ik dacht dat het nodig was, heb ik commentaar toegevoegd en ik heb zoveel mogelijk geprobeerd te voorkomen dat er dubbele code in de stylesheets is opgenomen. Tenslotte moet nog opgemerkt worden dat de stylesheets alleen met relatief eenvoudige 23
voorbeelden getest zijn. Vlak voordat ik begon aan deze opdracht is er een vak gegeven waarin een van de opdrachten was een bedrijfsproces uit te werken en de berichten die daarbij horen om te zetten in XML-schema documenten die aan de laatste standaard voldoen. Helaas heeft deze opdracht niet tot een bruikbare uitwerking geleid. Zelf heb ik om tijd te besparen een paar eenvoudige voorbeelden in elkaar gezet die voldoende complex waren om aan te tonen dat de geïmplementeerde mechanismen werken. Een probleem hierbij is dat bepaalde elementen in de XML-schema's niet door de XML-schema standaard geëist worden maar wel door de core component specificatie. Hierdoor kan een schema wel als een geldig document door de XML-schema validator komen, maar toch een ongeldig document zijn voor de stylesheets. Een aantal van de verplichte elementen wordt namelijk gebruikt in de stylesheets. 6.2.3 De website De website die ik bijgehouden heb, is een extra service die geleverd wordt bij de SVN server waarop ik de bestanden geplaatst heb. Er is daar gebruik gemaakt van trac (http://trac.edgewall.org) een web-based applicatie voor projectmanagement en bugtracking. Hier zit tevens een wiki in waardoor het makkelijk werd om extra informatie op te nemen op de website zonder dat er veel tijd gestoken hoefde te worden in het opzetten van een website. Op de site (https://opensvn.csie.org/traccgi/RUGeDocs/ niet toegankelijk zonder inlog-gegevens) kan de SVN-repository bekeken worden, kan er een tijdsplanning uitgezet worden, kunnen bugs of features bijgehouden worden en er kan extra informatie bijgehouden worden. Op het moment van schrijven staat er een tutorial voor het gebruik van SVN en voor het gebruik van de stylesheets in
XML editor. Verder heb ik een pagina bijgehouden waarop aangegeven wordt wanneer, hoe en waarom van de standaarden afgeweken is als dat nodig was. Ook zijn daar andere onvolkomenheden die opvielen in de standaard opgeschreven. Verder is er een verwijzing naar het README document opgenomen waarin de globale structuur van de stylesheets beschreven staat. Hoewel meer en specifiekere documentatie wenselijk is, is de website een goed startpunt geworden voor degene die na mij aan het product moet werken. En gezien de aard van de website zal het toch altijd een 'werk in uitvoering' zijn.
24
7. Conclusies en aanbevelingen In dit hoofdstuk zal ik de conclusies formuleren die ik getrokken heb na uitvoering van het project. Tevens zal ik een aantal aanbevelingen doen voor een vervolg van dit project.
7.1 Conclusies Staat van het product - De laatste versie biedt een stevige basis voor verdere ontwikkeling van het product. De belangrijkste functies voor het omzetten van een schema naar een formulier zijn geïmplementeerd en lijken voor zover ze getest zijn goed te werken. Aan de implementatie van de functies met betrekking tot de opmaak van het formulier is begonnen maar vereist nog enige werkzaamheden voordat dit bruikbaar is. Kwaliteit van het product - Het product is getest met eenvoudige schema's en met een implementatie van de XFORMS-specificatie. Om echt zinnige informatie over de kwaliteit van het product te geven zal het uitvoeriger getest moeten worden. Voor zover het getest is met de voorbeelden en de XFORMS-implementatie die gebruikt is, lijkt het product goed te werken. Onderhoudbaarheid van het product - Het product is opgedeeld in verschillende modules die zodra men meer bekend is met XSLT en de core components standaard een logische indeling hebben. Op de website waarvan de opdrachtgever de inloggegevens heeft, is gedocumenteerd waar de informatie over XSLT en de core components standaard gevonden kan worden. Dit alles bij elkaar verlaagt mijns inziens aanzienlijk de inwerkperiode die nodig is om aan het product te kunnen werken. Gebruikte ontwikkelmethode - De ontwikkelmethode die sterk lijkt op rapid application development is geschikt voor een project als deze. Wel heeft het als nadeel dat het lastig is om schattingen te maken van de tijd die nodig om bepaalde functies te implementeren.
7.2 Aanbevelingen Voor een vervolg van dit project is het verstandig als er intensiever gebruik gemaakt wordt van de mogelijkheden die trac biedt. Allereerst zouden de functies die het product moet bevatten opgenomen moeten worden als tickets. Deze kunnen vervolgens aan een milestone toegewezen worden. Op deze manier kan bijgehouden worden hoeveel tijd er gemiddeld gebruikt wordt om een functie te implementeren. De verkregen gegevens kunnen vervolgens gebruikt worden om betere schattingen te kunnen maken. Er zal iemand moeten komen die gaat onderzoeken welke opmaakeigenschappen er precies allemaal van belang zijn voor een formulier. En tevens zal hij de gevonden eigenschappen moeten implementeren in de stylesheets.
25
Bijlage I Gebruikte standaarden XML
staat voor eXtensible Markup Language. Dit is een standaard waarmee zowel de structuur als de inhoud van een document in platte tekst weergegeven kunnen worden op een formele manier. Doordat XML-bestanden als platte tekstbestanden opgeslagen worden, zijn ze leesbaar voor zowel mens als machine. XML
De standaard is beschreven op http://www.w3.org/XML/. XSD
staat voor XML Schema Definition. Dit is een standaard om vast te leggen wat de inhoud van een mag zijn. XML-documenten die volgens een bepaald schemadocument opgemaakt zijn kunnen hiernaar verwijzen. Vervolgens is het mogelijk om met een XML-schemavalidator te controleren of de inhoud van de XML-instantie voldoet aan de beschrijving die gegeven is in het schema. Het schema zelf is ook een XML-document waarvan de inhoud vastgelegd is op http://www.w3.org/XML/Schema. XSD
XML-document
XSLT
staat voor XSL Transformations. XSL staat hierin voor eXtensible Stylesheet Languange. Met behulp van XSLT kunnen transformaties beschreven worden die op een of meerdere XML-documenten uitgevoerd moeten worden. Het resultaat kan een nieuw XML-document zijn maar ook een HTML pagina of gewoon platte tekst. Voor het uitvoeren van de transformatie is een XSLT-processor nodig zoals saxon (http://saxon.sourceforge.net/). Ook xslt is een op xml gebaseerde standaard en de beschrijving hiervan is te vinden op http://www.w3.org/TR/xslt/. De xsl standaard is te vinden op http://www.w3.org/TR/xsl/. XSLT
XPATH
staat voor XML Path Language. Deze standaard beschrijft een syntaxis om delen van een XMLdocument te kunnen adresseren. Deze standaard wordt onder andere toegepast in de XSLT-standaard. Naast het lokaliseren van bepaalde elementen in een XML-document bevat het ook verschillende functies waaronder string-bewerking en wiskundige functies. De standaard wordt beschreven op http://www.w3.org/TR/xpath. XPATH
XFORMS
is de opvolger van HTML-formulieren. Formulieren op html pagina's worden gebruikt om het mogelijk te maken dat de bezoeker van de pagina informatie verzendt naar de server. De XFORMSstandaard is netter dan de oude HTML-formulieren. Zo is er scheiding aangebracht tussen model en view. Ook zijn XFORMS-formulieren gebaseerd op XML-documenten en zijn ze in staat om de ingevulde gegevens op te slaan als XML-documenten. De XFORMS-standaard is te vinden op http://www.w3.org/TR/xforms/. XFORMS
26
CORE COMPONENTS
De core components standaard is ontwikkeld door de UNECE en beschrijft een methode om data te modelleren. De standaard heeft als doel informatie voor applicaties in de e-business branche beter uitwisselbaar te maken. Een belangrijk aspect van deze standaard is de regelgeving omtrent naamgeving. De standaard is te vinden op http://www.unece.org/cefact/ebxml/CCTS_V2-
01_Final.pdf. NAMING AND DESIGN RULES
Deze standaard is een aanvulling op de core components standaard en heeft als doel om informatie die gemodelleerd is volgens de core components standaard weer te geven in XML-schema. Deze standaard is daardoor ook een aanvulling op de XML-schema standaard. Er worden een aantal extra elementen toegevoegd en het gebruik van XML-schema wordt op sommige punten ingeperkt. Een beschrijving van deze standaard is te vinden op http://www.disa.org/cefactgroups/atg/downloads/XML Naming And Design Rules V2.0.pdf
27
Bijlage II Een voorbeeld bericht In deze bijlage zal ik een voorbeeld uitwerken van een vereenvoudigd bericht. Dit voorbeeld heeft als doel om een beeld te krijgen van de opbouw van een bericht volgens de core component standaard. Eerst een weergave van het bericht in UML. Hier moeten een aantal opmerkingen bij gemaakt worden. Het schema zoals in figuur 7.1 te zien is voldoet niet volledig aan de standaard. Zo klopt de naamgeving niet helemaal en ook de symbolen zijn niet allemaal correct volgens de standaard. Zo geeft het overervingssysmbool in UML uitbreiding aan terwijl het in de core components standaard inperking betekent. De inperking heb ik aangegeven door middel van de notities die aan de Amount klassen verbonden zijn. Ik heb toch voor UML gekozen omdat deze techniek ook in de standaard gebruikt wordt.
Figuur 7.1: UML diagram van een eenvoudig bericht De items Klant en Order ID in de Order klasse worden in de standaard Basic Business Information Entities (BBIE) genoemd. Zijn in dit geval van het type Text en ID. Deze typen worden net als Amount ongekwalificeerde datatypen genoemd. De klassen Adres en Order Regel worden Aggregate Business Information Entities (ABIE) genoemd. In feite is de Order klasse ook een ABIE maar in de standaard wordt het root element niet als zodanig behandeld. De items Klantadres en Orderregel van de klasse order worden Association Business Information Entities genoemd (ASBIE). ASBIE's verwijzen naar ABIE's of naar datatypen (al dan niet gekwalificeerd). De klassen Euro_ Amount en Rug_ Euro Amount worden gekwalificeerde datatypen genoemd omdat ze het datatype Amount inperken. 28
Het bericht zoals hierboven beschreven zou er in xml grofweg als volg uitzien (let op: dit is niet het schema van het bericht maar een instantie van het bericht):
J. Bruintjes <straat>Straatweg 3 <postcode>1243 PH Lutjegast 0000235 <product>Softwarepakket a 1 <prijs>150.00
29
