Departement Industriële Wetenschappen
Master in de industriële wetenschappen: Elektronica-ICT afstudeerrichting ICT
Ontwikkeling van een Java API voor een kennisbanksysteem
Masterproef voorgedragen tot het behalen van de beroepstitel van industrieel ingenieur.
Academiejaar 2010-2011
Door:
Calus Nick
Promotor hogeschool:
Dr. Vennekens Joost
Promotor bedrijf:
Dr. Vennekens Joost
Departement Industriële Wetenschappen
Master in de industriële wetenschappen: Elektronica-ICT afstudeerrichting ICT
Ontwikkeling van een Java API voor een kennisbanksysteem
Masterproef voorgedragen tot het behalen van de beroepstitel van industrieel ingenieur.
Academiejaar 2010-2011
Door:
Calus Nick
Promotor hogeschool:
Dr. Vennekens Joost
Promotor bedrijf:
Dr. Vennekens Joost
Voorwoord Bij het maken van deze masterproef heb ik hulp en steun gekregen van een aantal personen. Ik zou hen daarom bij deze hiervoor willen bedanken. In de eerste plaats wil ik mijn promotor dr. Joost Vennekens bedanken voor het inhoudelijk verbeteren van deze tekst en om mij op weg te helpen wanneer ik niet goed wist waar te beginnen.
Ook wil ik mijn ouders, broers en vriendin bedanken voor de steun
en aanmoediging op momenten dat ik de moed even verloren had. Mijn vriendin wil ik daarenboven ook bedanken voor het grammaticaal verbeteren van deze tekst. Indien ik iemand ben vergeten te vermelden die mij ook gesteund heeft, wil ik die alsnog bedanken. Er is hard gewerkt aan deze tekst en de software die ontwikkeld is in deze masterproef. Ik lever het ontwikkelde systeem dan ook met trots af en ben ervan overtuigd dat dit nuttig zal zijn. Veel leesplezier.
ix
Abstract Het Inductive De nition Programming kennisbanksysteem is een expertsysteem dat logische problemen kan oplossen aan de hand van regels en de nities. Een bepaalde soort van deze problemen zijn con guratieproblemen. Bij con guratieproblemen zal de gebruiker van het expertsysteem een aantal parameters van het probleem een waarde geven. Met andere woorden, de gebruiker zal het probleem aan de hand van een aantal parameters con gureren. Door midel van deze con guratie zal het kennisbanksysteem bepalen of er geen, één of meerdere geldige oplossingen zijn voor het probleem. Een voorbeeld van een dergelijk probleem is een applicatie waarmee een ets kan samengesteld worden. De gebruiker kiest het soort ets, het kader, velgen, enz. Afhankelijk van de keuze van een onderdeel zullen andere onderdelen wel of niet beschikbaar zijn. De con guratie van de parameters van het probleem kan gezien worden als het inclusief of exclusief selecteren van een aantal waarden. Een gebruiksvriendelijke manier om waarden te selecteren, is door middel van een gra sche gebruikersinterface of afgekort GUI. Dit laat toe om stap voor stap verschillende waarden toe te kennen aan de parameters van het probleem. De GUI kan gemaakt worden met behulp van verschillende programmeertalen, waarvan Java een goede keuze is. Dit is omwille van de Create once, deploy anywhere loso e van Java. Bij andere gecompileerde programmeertalen bestaat het risico dat, bij het gebruik op meerdere platformen, de applicaties niet meteen werken zonder aanpassingen. Spijtig genoeg is er een grote hoeveelheid Java-code nodig om een GUI in elkaar te knutselen en een aantrekkelijke layout te geven. Er is nog meer werk en code nodig om deze GUI op een correcte manier te koppelen met een achterliggend systeem, zodat deze GUI dat systeem kan aanpassen en de staat van het systeem wordt weergegeven door de GUI. Bijkomend bestaat er geen werkende kant en klare oplossing om het IDP kennisbanksysteem te gebruiken vanuit de Java programmeertaal. Om die problemen op te lossen zal er in deze masterproef een Application Programming Interface ontwikkeld worden in de Java programmeertaal.
In de eerste plaats zal met
behulp van deze API het IDP kennisbanksysteem gebruikt kunnen worden vanuit de Java programmeertaal.
Daarenboven is het mogelijk om hiemee op een snelle, gemakkelijke
en exibele manier GUI applicaties automatisch te koppelen aan een IDP kennisbank, zodat deze GUI de kennisbank kan aanpassen en de staat van deze kennisbank wordt weergegeven door de GUI.
Abstract The Inductive De nition Programming knowledge base system is an expert system that can solve logical problems by using rules and de nitions. A speci c kind of these problems are the con guration problems. When solving a con guration problem, the user of the expert system will provide values for some of the parameters of the problem. In other words, the user will con gure the problem by assigning values to some parameters. Based on this con guration, the knowledge base system will determine if there are one or more solutions, or no solution at all for that problem. An example of such a problem is an application with which a bicycle can be con gured. The user chooses the kind of bike, the frame, rims, etc. Depending on the choices for a component, other components will or will not be available. Con guring parameters of the problem can be seen as inclusively or exclusively selecting some values. A user friendly way of selecting these values, is by the use of a GUI, short for Graphical User Interface. This allows a user to assign values to the parameters of the problem in a step by step fashion. The GUI can be created in one of many programming languages, although Java would be an excellent choice. This is so because of the Create once, deploy anywhere philosophy of Java. In other compiled programming languages, there is always a risk that the application will not work on multiple platforms without modi cations of the source code. Sadly, there is a large amount of Java code needed to put together a professional looking GUI. Even more eort and code is needed to make this GUI interact in a correct way with a backing system. Interacting correctly means that the GUI can alter the backing system and it displays the state of that system. Above and beyond this fact, there is currently no working of the shelf solution to use the IDP knowledge base system in conjunction with the Java programming language. To solve all these problems, an API, short for Application Programming Interface, for the Java programming language will be developed in this masters thesis. In the rst place, this API will enable an application, written Java, to use the IDP knowledge base system. On top of that, this API allows the programmer to create the GUI and connect it in a fast, easy and exible way to the IDP knowledge base system, in order for the GUI to be able to update the knowledge base and display the state of the knowledge base.
Short Summary The goal of this master's thesis is to develop a method or system that enables a Java programmer to easily and rapidly build a GUI which is backed by the IDP knowledge base system. The rst part, which is building a GUI using the Java language, can be easily done using a GUI builder. Several dierent GUI builders exist at the time of writing. Some of them are open source and free, and for others a license can be purchased. There are free GUI builders available for the three most widely known and used IDEs in the Java world: Eclipse (through plug-ins), Netbeans and IntelliJ. Creating a GUI with those builders is not covered by this thesis, because it is very simple and there are enough resources available on the internet to get you started. The second part of the goal is to back the GUI by the IDP knowledge base system. There are a couple of possibilities to accomplish this goal, but some of them have proven to be less desirable than others. The rst possibility is to create a plug-in for one of the known IDEs. This plug-in would generate connection code by dragging and dropping parts of the knowledge base on a graphical component in the GUI. There are however some drawbacks to this method. One IDE has to be chosen for which the plug-in will be made, letting down all programmers which use another IDE. The code generated by the plug-in would probably be di cult to maintain. The plug-in would need to be updated or maybe recreated whenever a new version of the IDE becomes available, which isn't ideal for a master's thesis product since there are no maintainers and the product would become obsolete. Another possible solution would be to use Java Annotations. These metadata classes can be used to tag parts of the GUI. Tagged objects could be parsed and thus automaticaly connected to the IDP system. The advantage of this method is that annotations are part of the Java language standard, so this solution will remain functional as long as the Java language doesn't change drasticaly. The last possible solution involves the Java Enterprise Edition framework. This is a web based framework where the GUI is actually a web page.
For this solution to work, a
Java Application Server is needed, which means you must have a server machine with the application server installed. This can be a costly solution if just a desktop application is required. Another drawback is the complexity of the framework which has to accounted for in the implementation. It is already clear that the solution which uses annotations will have the greatest chance of success. Therefore this solution will be implemented. It should be noted that every
proposed solution would require or at least bene t from the development of an API, so this is in any case the rst and most important task at hand. To succesfully develop an API, a thorough design will have to be made. In the design of the API created in this thesis there are three top level modules. The most important module is the knowledge base abstraction module. This module will add a layer on top of the IDP system to hide its aws and to make it easy to use from within a Java application. The second module is the con guration module. This module will provide the means to con gure every kind of supported GUI component and attach it to the knowledge base. Support for new GUI components can be added to the API by making use of the provided Service Provider Interface. This is a Java technology that can be used to dynamicaly load new implementations of a certain interface into a running application. In fact, this module doesn't support any GUI component by itself.
A few basic components are supported
because a default implementation of the Service Provider Interface is provided. The third and last module is the analysis module.
This module is able to analyse the
written or generated GUI code by looking for annotated elds. It is this module that will automatically connect the GUI to the IDP system, or at least semi-automatic, since the programmer needs to annotate the elds himself. Luckily, this is an easy and small task. Annotating the required elds will take at most the same amount of time as needed to create the GUI with a GUI builder. To connect the annotated components to the IDP system, the other two modules of the API are used by this module. The API is designed and implemented in such a way that it is easy for a programmer to extend its functionality according to the needs of the application.
To accomodate this
extensibility, a lot of interfaces and abstract base classes are available in the API.
Inhoudsopgave 1 Inleiding 1.1
Probleemstelling 1.1.1
1.1.2 1.2
1.3
1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
IDP-taal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1.1
Vocabularium . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.1.1.2
Theorie
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.1.1.3
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Gebruik van het IDP-systeem
. . . . . . . . . . . . . . . . . . . . .
5
Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2.1
con gNow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2.2
Fietscon guratiedemo
. . . . . . . . . . . . . . . . . . . . . . . . .
7
Organisatie van deze tekst . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2 Literatuurstudie
11
2.0.1
Eclipse-Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.1
Annotaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
JavaServer Pages
12
2.2.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
JavaServer Faces
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3
Internationalisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4
Service Provider Interface
. . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.5
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3 Windows programma's
17
3.1
ISO C en C++ standaarden . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2
GidL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.3
Approx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.4
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4 Ontwerp
23
4.1
Overzicht
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.2
Kennisbankabstractie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.2.1
Model
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2.2
Toestand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.2.3
Gegevensverwerking
. . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.2.4
Solution
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.2.5
Event listeners
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.3
Con guratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.4
Analyse
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.5
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5 Implementatie
37
5.1
UndoStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.2
Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.3
Solution
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.3.1
changeState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.3.2
undoChangeSteps . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.4
Solution in een andere Thread . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.5
Con gurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.5.1
ndBestForObject
. . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.5.2
ndToolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.5.3
getJars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.6
6 Gebruik en uitbreiding van de API
51
6.1
Translator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.2
Annotatie parser
53
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1
Snelle methode
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2
Flexibele methode
55
. . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.3
Con gurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.4
Kennisbankabstractie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6.5
Interfaces en abstracte klassen implementeren
. . . . . . . . . . . . . . . .
60
6.6
Maken van een Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
INHOUDSOPGAVE
6.7
xv
6.6.1
Adapter klasse
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
6.6.2
Factory klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
6.6.3
Toolkit klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
6.6.4
JAR samenstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
Besluit
69
Bibliogra e
72
Verklarende lijst van afkortingen en symbolen API
Application Programming Interface. Een verzameling interfaces en klassen die een geheel vormen waarmee een bepaald probleem kan opgelost worden.
GUI
Graphical User Interface. Een gebruikersinterface is het onderdeel van een applicatie waarmee de gebruiker kan interageren met de applicatie.
Men spreekt van een
gra sche gebruikersinterface wanneer er gebruik wordt gemaakt van vensters, iconen, menus, knoppen en een aanwijsapparaat.
HTML
HyperText Markup Language. Een opmaaktaal om de structuur van webpagina's
te de niëren.
IDE
Integrated Development Environment. Een applicatie om software te onwikkelen, waarin alle nodige tools in geïntegreerd zijn.
IDP
Inductive De nition Programming.
Een modeleertaal en een systeem om NP-
problemen mee op te lossen.
JAR
Java Archive. Een op ZIP gebaseerd bestandstype dat gebruikt wordt om een Java applicatie en resources in op te slaan.
JRE
Java Runtime Environment. De combinatie van een JVM en de standaard Javabibliotheek. Dit geheel maakt het mogelijk om Java-applicaties uit te voeren.
JVM
Java Virtual Machine. De virtuele machine waar Java applicaties op worden uit-
gevoerd.
JSF
JavaServer Faces. Een op JSP gebaseerde technologie om op een gemakkelijke manier in een webpagina formulieren te maken die op een GUI gelijken.
JSP
JavaServer Pages. Een scripting technologie om op een gemakkelijke manier HTML opmaak te mengen met Java code.
SPI
Service Provider Interface.
Een standaard manier in Java om dynamisch Jar bi-
bliotheken in te laden in een reeds uitvoerende applicatie. SPI mogelijkheden zijn geïntegreerd in de speci catie van het Jar bestandsformaat.
URL
Uni ed Resource Locator. Een tekenreeks die de locatie van een bron of bestand aanduidt. Deze tekenreeks moet aan bepaalde syntaxvoorwaarden voldoen.
ZIP
Een bestandsformaat dat toelaat om bestanden in te bundelen en deze te comprimeren. De naam ZIP is afkomstig van de inpakhandeling, het dichtritsen van een archief.
L¼st van guren 1.1
De architectuur van con gNow. (Abhinav, 2010) . . . . . . . . . . . . . . .
7
1.2
Originele etscon guratiedemo.
8
1.3
Nieuwe versie van de etscon guratie demo.
4.1
Overzicht van de architectuur van de API
4.2
Overzicht van kennisbank abstractie module
4.3
Klassediagram van de model klassen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
. . . . . . . . . . . . . . . . . .
24
. . . . . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . .
27
4.4
Principe van het veranderen van de toestand in een stap. . . . . . . . . . .
29
4.5
Overzicht van de con guratiemodule
. . . . . . . . . . . . . . . . . . . . .
32
4.6
Overzicht van de analyse module.
. . . . . . . . . . . . . . . . . . . . . . .
34
5.1
Implementatie van het veranderen van de toestand in een stap. . . . . . . .
40
6.1
Oproepen van de Export Wizard.
. . . . . . . . . . . . . . . . . . . . . . .
68
6.2
De Export Wizard
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
Lijst van codefragmenten 1.1
Vocabularium blok
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2
Theorie blok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Data blok
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1
De nitie van de IDPPredicate-annotatie. . . . . . . . . . . . . . . . . . . .
12
2.2
Gebruik van JSF tags.
14
3.1
Code zonder sequence points . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2
Declaratie van de index operator van de vector klasse . . . . . . . . . . . .
20
5.1
De changeState methode, deel 1. . . . . . . . . . . . . . . . . . . . . . . . .
41
5.2
De changeState methode, deel 2. . . . . . . . . . . . . . . . . . . . . . . . .
41
5.3
De changeState methode, deel 3. . . . . . . . . . . . . . . . . . . . . . . . .
42
5.4
De changeState methode, deel 4. . . . . . . . . . . . . . . . . . . . . . . . .
43
5.5
De changeState methode, deel 5. . . . . . . . . . . . . . . . . . . . . . . . .
43
5.6
De undoChangeSteps methode, deel 1.
. . . . . . . . . . . . . . . . . . . .
44
5.7
De undoChangeSteps methode, deel 2.
. . . . . . . . . . . . . . . . . . . .
45
5.8
De ndBestForObject methode, deel 1. . . . . . . . . . . . . . . . . . . . .
46
5.9
De ndBestForObject methode, deel 2. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.10 De ndToolkit methode, deel 1.
. . . . . . . . . . . . . . . . . . . . . . . .
5.11 De ndToolkit methode, deel 2.
47 48
. . . . . . . . . . . . . . . . . . . . . . . .
48
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.1
Deel van een properties bestand met de vertaling van symbolen en tuples. .
52
6.2
Declaratie van geannoteerde velden. . . . . . . . . . . . . . . . . . . . . . .
53
6.3
Code voor de koppeling van geannoteerde velden, de snelle manier.
55
6.4
Code voor de koppeling van geannoteerde velden met meer exibiliteit.
6.5
Koppeling van componenten aan de kennisbank met behulp van Adapters.
6.6
De attachAdapter-methodes voor het koppelen van de adapters aan de
5.12 De getJars methode.
kennisbank.
. . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56 58 59
6.7
Directe wijziging van de staat van de kennisbank.
. . . . . . . . . . . . . .
60
6.8
Klassede nitie, velden en constructor van de ColorJCheckboxAdapter. . . .
62
6.9
De geneste CheckBoxListener klasse.
. . . . . . . . . . . . . . . . . . . . .
63
6.10 De onStateChange methode. . . . . . . . . . . . . . . . . . . . . . . . . . .
64
6.11 De onProcessingStarted en onProcessingEnded methode.
. . . . . . . . . .
65
. . . . . . . . . . . . . . . . . . .
66
6.13 De ColorCheckBoxFactory klasse. . . . . . . . . . . . . . . . . . . . . . . .
67
6.12 De setName en setDescription methode.
6.14 De ColorToolkit klasse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
6.15 Het jidp.con guration.spi.Toolkit bestand.
68
. . . . . . . . . . . . . . . . .
Hoofdstuk 1 Inleiding 1.1 Probleemstelling In deze masterthesis ga ik op zoek naar een methode en implementatie voor het interactief oplossen van logische problemen met behulp van het IDP-raamwerk. IDP kan gezien worden als een kennisbanksysteem, in die zin dat dit systeem in staat is ingewikkelde logische problemen op te lossen door kennis aan te bieden in de vorm van een wiskundig model. De vernoemde ingewikkelde logische problemen zijn meerbepaald NP-problemen ofwel niet-deterministische polynomiale tijd problemen. Dit zijn k beslissingsproblemen die in polynomiale tijd O(n ) opgelost kunnen worden door een niet-deterministische Turing-machine. (Mariën et al., 2006) Een expert in een bepaald kennisdomein kan zijn kennis beschikbaar stellen door een wiskundig model op te stellen van een probleem.
Het domein waarin deze problemen
voorkomen kan sterk variëren. Enkele voorbeelden zijn: planning (van uurroosters), problemen in de grafentheorie, opstellen en oplossen van puzzels, enz. Door het model van een dergelijk probleem in te geven in het IDP-systeem kan in de eerste plaats geveri eerd worden of een instantie al dan niet geldig is. In de tweede plaats is het ook mogelijk om geldige instanties te genereren. Het ontwikkelen van een API in de Java-programmeertaal moet het IDP-systeem toegankelijker te maken voor het ontwikkelen van applicaties. Meer speci ek ga ik mij richten op de ontwikkeling van con guratie applicaties. Dit zijn applicaties waarbij de eindgebruiker van de applicatie door middel van selecties een oplossing gaat zoeken voor een probleem. De gebruiker gaat progressief selecties maken, waarbij het IDP-systeem deze selecties zal veri ëren.
Indien het binnen aanvaardbare uitvoeringstijd mogelijk is, zal
het IDP-systeem ook combinaties uitsluiten die aan de hand van de huidige selecties niet meer tot een geldige oplossing kunnen leiden.
1.1.1 IDP-taal Het IDP-raamwerk bestaat uit een modeleertaal en een systeem om problemen die beschreven zijn met de modeleertaal op te lossen.
Er wordt gesproken van een modeleertaal in plaats van een programmeertaal. programmeertaal wordt de methode beschreven om een probleem op te lossen.
In een Deze
methode wordt een algoritme genoemd en kan omgezet worden naar machinecode, waarna dit uitgevoerd kan worden. In de IDP-taal wordt er geen methode beschreven maar eerder een model.
Dit model bevat voorwaarden en verbanden waaraan een oplossing moet
voldoen om een geldige oplossing te zijn voor een bepaald probleem. Een IDP-model bestaat uit drie delen:
•
Vocabularium
•
Theorie
•
Data
Om deze drie delen nader toe te lichten, zal ik een voorbeeld gebruiken. Dit voorbeeld bevat het model van een puzzelspel, Hitori genaamd. Hitori is een gelijkaardig spel als het meer bekende Sudoku. Het spel bestaat uit een vierkant rooster van een bepaalde grootte. het rooster staat een getal.
In elk vakje van
In elke rij en elke kolom van het rooster mag slechts één
wit vakje met een bepaald getal staan. Als er meerdere vakjes in dezelfde rij of kolom hetzelfde getal bevatten moeten elk van die vakjes behalve één zwart gekleurd worden. Een bijkomende beperking is dat er geen twee zwarte vakjes vlak naast elkaar mogen staan. Tenslotte moeten alle witte vakjes één aaneensluitend gebied vormen. Er mogen dus geen afgezonderde eilandjes zijn van witte vakjes. De bedoeling van het spel is om de juiste vakjes zwart te kleuren zodanig dat aan alle voorgaande voorwaarden voldaan zijn.
1.1.1.1 Vocabularium In het vocabularium gedeelte (codefragment 1.1) zijn de symbolen gedeclareerd die gebruikt worden als in- en uitvoer. Er kunnen ook intern gebruikte symbolen gedeclareerd worden in dit gedeelte maar het is evengoed mogelijk om deze symbolen in het theoriegedeelte te declareren. De lijst van symbolen die als invoer dienen, wordt voorafgegaan door `Given:'. Declaraties in IDP bestaan uit types, predicaten en functies. De declaratie van types gebeurt ofwel in een type blok of door `type' voor de declaratie te plaatsen. Een type moet gedeclareerd zijn voordat het kan gebruikt worden. Om een predicaat of een functie te declareren wordt de signatuur van dit predicaat of functie opgegeven. Voor een predicaat is dit eerst de naam van het predicaat en daarachter komen tussen ronde haakjes de argumenten van het predicaat, gescheiden door een komma. Bij een functie is dit nagenoeg hetzelfde, enkel wordt er bijkomend een dubbel punt en het terugkeertype geplaatst na het sluiten van de ronde haakjes. De lijst van symbolen die als uitvoer dienen voorafgegaan door `Find:'.
Declaraties in
deze lijst gebeuren op dezelfde manier als in de lijst voor de invoer. In tegenstelling tot de invoer is het hier niet mogelijk om types te declareren, aangezien alle types gekend moeten zijn voordat ze kunnen gebruikt worden.
Inleiding 1 2 3 4 5 6 7 8 9 10 11 12 13
3
Given : type { int Xpos int Ypos } type int Number S t a t e ( Xpos , Ypos , Number ) Find : Black ( Xpos , Ypos ) Declare : Reachable ( Xpos , Ypos ) Codefragment 1.1: Vocabularium blok
Het gedeelte voor interne symbolen wordt voorafgegaan door `Declare:'.
1.1.1.2 Theorie De theorie (codefragment 1.2), voorgesteld door regels, wordt voorafgegaan door `Satisfying:'.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Satisfying : d e c l a r e NextTo ( Xpos , Ypos , Xpos , Ypos ) . { }
! x1 y1 x2 y2 : NextTo ( x1 , y1 , x2 , y2 ) => ~( Black ( x1 , y1 ) & Black ( x2 , y2 ) ) . ! x1 x2 y n : ) => x1 = ! x y1 y2 n : ) => y1 = {
15 16 17 18 19 20
NextTo ( x1 , y1 , x2 , y2 ) <− abs ( x1 − x2 ) + abs ( y1 − y2 ) = 1 .
}
S t a t e ( x1 , y , n ) & S t a t e ( x2 , y , n ) & ~Black ( x1 , y ) & ~Black ( x2 , y x2 . S t a t e ( x , y1 , n ) & S t a t e ( x , y2 , n ) & ~Black ( x , y1 ) & ~Black ( x , y2 y2 .
Reachable ( 1 , 1 ) <− ~Black ( 1 , 1 ) . Reachable ( 1 , 2 ) <− Black ( 1 , 1 ) . Reachable ( x , y ) <− NextTo ( x , y , rx , ry ) & ~Black ( x , y ) & Reachable ( rx , ry ) .
! x y : Xpos ( x ) & Ypos ( y ) & ~Black ( x , y ) => Reachable ( x , y ) . Codefragment 1.2: Theorie blok
In dit gedeelte wordt de de nitie gegeven van de gedeclareerde predicaten en functies. Dit zijn de verbanden en beperkingen die opgelegd worden in het model. Om deze ver-
Tabel 1.1: IDP-operatoren
logisch
∧ ∨ ¬ ⇒ ≡ ∀ ∃
IDP
verklaring
&
en
|
of
∼
niet
=>
impliceert
<=>
equivalent
!
voor alle
?
er bestaat
banden en beperkingen uit te drukken in IDP zijn er een aantal operatoren voorzien die overeenstemmen met wiskundige operatoren (tabel 1.1). De betekenis van een uitdrukking !
(x2,y2)).
x1 y1 x2 y2 : NextTo(x1,y1,x2,y2)=> ~(Black(x1,y1)& Black
is dan: voor elke x1, y1, x2 en y2, als punt x1,y1 aangrenzend is met punt x2,y2
mogen beide punten niet tegelijkertijd zwart zijn. In het voorbeeld is ook te zien dat elke uitdrukking moet eindigen met een punt. Wanneer één of meerdere uitdrukkingen omsloten zijn door gekrulde haakjes, dan is dit een expliciete de nitie. Elke uitdrukking in een de nitie moet beginnen met het predicaat dat gede nieerd wordt, gevolgd door `<−' en de uitdrukking waaraan het predicaat gelijk moet zijn. Een de nitie kan ook recursief zijn.
1.1.1.3 Data In dit gedeelte staat de invoer die speci ek is voor elke instantie van het probleem (codefragment 1.3). Als dit de invoer is voor een type, predicaat of functie in het `Given:' blok, dan wordt deze invoer voorafgegaan met `Data:'. Voor een type en predicaat wordt er een verzameling van mogelijke waarden gegeven en voor een functie wordt er een verband gegeven tussen de argumenten en de terugkeerwaarde.
De mogelijke waarden worden
gescheiden door een punt-komma `;'. Wanneer een waarde bestaat uit verschillende symbolen, zoals bij een predicaat of functie met meerdere argumenten, dan worden deze symbolen gescheiden door een komma `,'. Bij een functie wordt er tussen de argumenten en de terugkeerwaarde een pijl `->' gezet die het verband aangeeft. De lijst van waarden voor een type, predicaat of functie wordt omsloten door gekrulde haakjes en voorafgegaan door de naam van het type,predicaat of functie en een isgelijkteken `='. Voor predicaten of functies in het `Find:' blok wordt de invoer voorafgegaan met `Partial:'. Dit is handig wanneer er reeds een gedeelte van de oplossing gekend is. Dit blok wordt op dezelfde manier ingegeven als het `Data:' blok, maar met twee lijsten van waarden achter elkaar per predicaat of functie. De eerste lijst bevat de waarden die zeker wel deel zijn van de oplossing en de tweede lijst bevat de waarden die zeker niet deel zijn van de oplossing.
Inleiding 1 2 3 4 5
6 7 8
5
Data : Xpos = { 1 ; 2 ; 3 ; 4 ; 5} Ypos = { 1 ; 2 ; 3 ; 4 ; 5} Number = { 1 ; 2 ; 3 ; 4 ; 5} State = {1 ,1 ,1; 1 ,2 ,4; 1 ,3 ,1; 1 ,4 ,2; 1 ,5 ,4; 2 ,1 ,2; 2 ,2 ,4; 2 ,3 ,3; 2 ,4 ,4; 2 ,5 ,1; 3 ,1 ,4; 3 ,2 ,1; 3 ,3 ,4; 3 ,4 ,3; 3 ,5 ,3; 4 ,1 ,3; 4 ,2 ,1; 4 ,3 ,4; 4 ,4 ,5; 4 ,5 ,2; 5 ,1 ,5; 5 ,2 ,2; 5 ,3 ,1; 5 ,4 ,4; 5 ,5 ,3} Partial : Black = { 5 , 4 ; 4 , 1 } { 1 , 1 } Codefragment 1.3: Data blok
1.1.2 Gebruik van het IDP-systeem Bij het uitvoeren van het IDP-systeem wordt eerst het model met bijhorende data ingegeven, waarna het systeem één of meerdere oplossingen zal zoeken en weergeven. Deze vorm van uitvoeren is bekend als een batch proces en is eenvoudig en e ciënt, omdat alle variabelen op voorhand gekend zijn. Helaas is het moeilijk om op deze manier interactieve applicaties te bouwen, aangezien die interactie een (quasi) continu proces is. Daarom is er een aangepaste versie van het IDP-systeem gemaakt (Approx). Deze aangepaste versie zal als resultaat niet een oplossing aanbieden maar wel beperkingen in de verzameling van oplossingen. De beperkingen kunnen dan samen met een nieuwe beperking, gemaakt door de gebruiker, terug ingevoerd worden om zo opnieuw naar bijkomende beperkingen zoeken. De bedoeling is dan om stapsgewijs de gewenste oplossing als enige oplossing te behouden.
1.2 Doelstellingen Het doel van deze masterproef is het ontwikkelen van een methode of systeem waarmee een Java-programmeur snel en gemakkelijk een GUI kan maken, die aangestuurd wordt door het IDP-kennisbanksysteem. De vereisten kunnen opgesplitst worden in twee delen: het snel en gemakkelijk maken van een GUI en het snel en gemakkelijk koppelen van deze GUI met het IDP-systeem. Het eerste deel van de vereisten kan opgelost worden met een GUI-builder. Er zijn verschillene GUI-builders beschikbaar.
Sommigen zijn vrij te gebruiken en voor anderen
moet een licentie aangekocht worden. Voor elk van de drie meest gebruikte Java-IDE's is er op zijn minst één vrij te gebruiken builder beschikbaar. Bij Netbeans en IntelliJ is deze inbegrepen en bij Eclipse kan deze als plug-in toegevoegd worden. Een GUI ontwikkelen met een GUI-builder is zeer eenvoudig. Men sleept componenten op de gewenste plaats en zorgt er voor dat de componenten juiste uitgelijnd zijn.
De
procedure om dit te doen zal niet behandeld worden in deze masterproef, aangezien dit een eenvoudige procedure is en er verschillende handleidingen beschikbaar zijn op het internet.
Het tweede deel van de vereisten, de GUI koppelen met het IDP-systeem, is niet zo voor de hand liggend. Er bestaat namelijk geen kant en klare manier om dit systeem te gebruiken vanuit Java. Het IDP-kennisbanksysteem wordt uitgevoerd in een apart proces op de computer. De in- en uitvoer van en naar IDP gebeurt ofwel via tekstbestanden of via de in- en uitvoerstromen van dit proces. Om IDP te kunnen aanspreken vanuit Java, moet eerst het IDP-proces gestart worden, waarna hier invoer naar wordt weggeschreven en uitvoer terug wordt opgehaald. De invoer en uitvoer van het IDP-proces is vrijwel onbruikbaar in ruwe tekstvorm voor een Java-applicatie. Daarom moet de uitvoer worden omgezet in een gestructureerde voorstelling, die gemakkelijk kan gebruikt worden in een Java-applicatie. Andersom moet die gestructureerde voorstelling terug omgezet kunnen worden in een vorm die het IDP-systeem verstaat, zodat dit als invoer kan aangeboden worden. Met behulp van deze gestructureerde voorstelling is het mogelijk om een GUI te koppelen aan het IDP-systeem. Er moet wel een gemakkelijke en snelle manier gevonden worden om die koppeling tot stand te brengen. Er is reeds een kleine Java-bibliotheek, con gNow genaamd, beschikbaar die een gestructureerde voorstelling kan opbouwen van de uitvoer van het IDP-systeem.
Als de
GUI voldoet aan een aantal voorwaarden, is deze bibliotheek in staat de GUI automatisch te koppelen aan IDP. Samengevat is het doel van deze masterproef de functionaliteit van con gNow, die beschreven is in sectie 1.2.1 en sectie 1.2.2, te implementeren en te verbeteren op vlak van correctheid, exibiliteit en gebruiksvriendelijkheid voor de programmeur en gebruiker.
1.2.1 con gNow De bibliotheek con gNow is in staat een GUI, gemaakt met de Swing toolkit, te koppelen met IDP. In guur 1.1 staan de onderdelen van con gNow afgebeeld. Hierin zijn Manager en Support Classes de onderdelen die terug te vinden zijn in die bibliotheek. De andere onderdelen zijn Approx en GidL. Dit zijn de programma's (Zie hoofdstuk 3) die onderliggend gebruikt worden.
De onderdelen Con g.
File, Partial Int.
File en
IDP File zijn de bestanden die het probleem beschrijven en die gebruikt worden voor de in- en uitvoer van IDP. Het onderdeel aan de linkerkant van de guur is de gebruikersinterface. Dit is het onderdeel dat gebruik maakt van con gNow om de kennisbank aan te spreken. Zoals de ontwerper zelf aangeeft in guur 1.1, is de Manager klasse de belangrijkste klasse in de bibliotheek en dienen de andere klassen als ondersteuning van die klasse. Het was oorspronkelijk de bedoeling dat ik con gNow zou uitbreiden en aanpassen, omdat de basisfunctionaliteit hier reeds aanwezig is. Dit was echter een onhaalbare opdracht om verschillende redenen. Als eerste is er nauwelijks een ontwerp of architectuur te herkennen in de bibliotheek. Dit is vooral te wijten aan de enkele Manager klasse, waarvan ook de naam ongelukkig gekozen is. uitzonderingen.
De hulpklassen zijn vooral data klassen, met enkele
Bijkomend is de code niet gedocumenteerd en is de naamgeving van
methodes en variabelen obscuur en weinig betekenisvol.
Inleiding
7
configNow Support Classes
GIDL User Interface
Manager Approx
Config. File
IDP File
Partial Int. File
Figuur 1.1: De architectuur van con gNow. (Abhinav, 2010)
De bibliotheek is ook minder geschikt om gebruikt te worden in een omgeving met meerdere gebruikers, aangezien de in- en uitvoer hier gebeurt via een bestand (Partial Int. File in guur 1.1).
Op een systeem waar deze bibliotheek door meerdere gebruikers
tegelijkertijd gebruikt wordt, moet voor elke gebruiker het in- en uitvoerbestand gekopieerd worden en hieraan een naam toegekend worden. Het gebruik van dit bestand zou vermeden moeten worden. In de bibliotheek zijn ook onvolkomenheden aanwezig die reeds duidelijk worden bij de meegeleverde demoapplicatie.
Deze zouden ook verholpen moeten worden, indien de
bibliotheek gebruikt zou worden.
1.2.2 Fietscon guratiedemo De functionaliteit die con gNow (sectie 1.2.1) aanbiedt, wordt getoond met behulp van een voorbeeldapplicatie. De applicatie in guur 1.2 laat de originele versie van een etscon gurator zien.
In deze etscon gurator kan een ets samengesteld worden door de
gebruiker. Deze versie maakt gebruik van de con gNow bibliotheek. Met behulp van kleurcodes wordt er bij de keuzevakjes aangegeven welke onderdelen verplicht zijn en welke verboden zijn. Bij de keuzelijsten worden de verboden mogelijkheden niet meer weergegeven in de lijst. Wanneer een keuzevakje aangevinkt wordt of een element uit een keuzelijst geselecteerd wordt, zal IDP opgeroepen worden om de geldigheid na te kijken.
Figuur 1.2: Originele etscon guratiedemo.
Inleiding
9
Om de gewenste functionaliteit aan te tonen, zijn een aantal schermafdrukken genomen en weergegeven in guur 1.3. Aan de hand van deze afdrukken zullen de vereisten van de te ontwikkelen API in deze masterproef duidelijk gemaakt worden. In guur 1.3(a) wordt aangetoond dat er nog meerdere keuzemogelijkheden zijn voor het frametype. Hier is ook enkel aangeduid dat een dames ets gewenst is. Als dit vergeleken wordt met guur 1.3(c), zien we dat daar maar één mogelijkheid meer is en dat deze automatisch geselecteerd is. Hetzelfde kan gezegd worden over het etstype. Dit gebeurt niet in het huidige systeem con gNow, aangezien IDP hier maar één keer wordt opgeroepen en sommige gevolgen van een wijziging door IDP niet direct gevonden worden. De nieuwe API moet dus, indien door de gebruiker gewenst, blijven zoeken zolang er in de vorige zoekopdracht nieuwe wijzigingen werden gevonden. In guur 1.3(b) is te zien dat alle gekoppelde componenten worden uitgeschakeld wanneer een bewerking wordt uitgevoerd. Dit maakt aan de gebruiker duidelijk dat hij even moet wachten. De versie die gebruik maakt van con gNow zal in dit geval niet meer reageren, waardoor de gebruiker mogelijk denkt dat de applicatie is vastgelopen. Een vereiste van de API is dus de mogelijkheid om aan de gebruiker aan te geven dat een bewerking in uitvoering is. Figuur 1.3(d) laat dezelfde toestand zien als guur 1.3(c), maar dan aan de hand van kleurencodes. Het moet dus met de API mogelijk zijn om gemakkelijk en snel het gedrag van de componenten te veranderen. Met con gNow is er maar één soort gedrag dat de componenten kunnen aannemen. Er worden ook maar twee componenten ondersteund:
javax.swing.JCheckBox
en
javax.swing.JCombobox.
In de nieuwe API kunnen er vir-
tueel oneindig veel componenten ondersteund worden door nieuwe Toolkits toe te voegen. Verder is er in guur 1.3 te zien dat de labels van de componenten vertaald zijn en dat er een undo-, redo-, check-, clear- en resetknop aanwezig is. De API moet dus voor de gekoppelde componenten een tekst kunnen weergeven die aangepast is aan de lokale taal. Ook moet de staat terug naar de begintoestand gebracht kunnen worden en moet er door de verschillende aangebrachte wijzigingen heen en weer gelopen kunnen worden. Enkel de check- en resetfunctionaliteit is beschikbaar in con gNow.
1.3 Organisatie van deze tekst Het vervolg van deze masterthesis wordt opgesplitst in een aantal hoofdstukken. Om te beginnen worden de oplossingsmogelijkheden toelichten in hoofdstuk 2. Daarna worden in hoofdstuk 3 de opgeloste problemen met benodigde programma's beschreven. Hoofdstuk 4 gaat dieper in op het ontwerp van de API en verklaart en verantwoordt de onderdelen. De implementatiedetails zullen verwerkt worden in hoofdstuk 5. Informatie over het gebruik van de API en hoe deze uit te breiden wordt beschreven in hoofdstuk 6.
(a) Dames ets is geselecteerd. Er zijn nog ver- (b) Alle componenten zijn uitgeschakeld tijdens schillende mogelijkheden voor het frametype. een bewerking.
(c) Een framegrootte van 190 tot 200 cm is gese- (d) Hetzelfde als (c), maar dan met gekleurde lecteerd. Het etstype en frametype kan niet checkbox componenten. meer vrij gekozen worden.
Figuur 1.3: Nieuwe versie van de etscon guratie demo.
Hoofdstuk 2 Literatuurstudie In dit hoofdstuk zullen een aantal mogelijke manieren besproken worden om de doelstelling van de masterproef te verwezenlijken. Ook wordt er gekeken naar een paar technologieën die gebruikt kunnen worden bij het implementeren van de oplossing.
2.0.1 Eclipse-Plugin Eclipse is een platform dat volledig gebaseerd is op plugins.
Dit maakt de Eclipse-
applicatie eenvoudig, maar het platform uitgebreid en complex. Aan de basis van Eclipse-plugins bevinden zich extensions en extension points. (Clayberg and Rubel, 2008) Dit is te vergelijken met een stekker en een stopcontact.
Eclipse en
ook plugins bieden extension points aan. Deze extensionpoints hebben een schema dat beschrijft aan welke voorwaarden een extension moet voldoen om te kunnen koppelen met het extensionpoint. Een plugin heeft één of meerdere extensions waarmee ze functionaliteit aanbied aan het platform. De extensions en extension points van een plugin worden verzameld in het plugin.xml bestand. Eclipse zal dit bestand voor elke geïnstalleerde plugin verwerken. Hoewel het zeer interessant zou zijn om een plugin te ontwikkelen, is dit geen ideale oplossing. Er zou gekozen moeten worden voor een speci eke IDE, wat er toe leidt dat programmeurs die gebruik maken van een andere IDE hierdoor in de kou blijven staan. Bijkomend zou de onwikkelde plugin elke keer aangepast moeten worden wanneer een nieuwe versie van Eclipse uitkomt die niet helemaal compatibel is.
2.1 Annotaties Java Annotations zijn tags die kunnen toegevoegd worden aan klassen, constructoren, velden, methodes, parameters, lokale variabelen en zelfs andere annotaties. Tijdens het compileren van java code worden deze annotaties als metadata aan de klassebestanden toegevoegd.
Met behulp van de ingebouwde
Retention
annotatie kan ingesteld worden dat deze an-
notaties mee ingeladen moeten worden in de Java Virtuele Machine. Annotaties die mee in de JVM worden geladen, kunnen opgevraagd worden met behulp van de Re ection API. Om dit te doen moet er eerst een beschrijving van een klasse worden verkregen. De beschrijving is een instantie van de
Class
klasse en bevat informatie over de velden en
methodes van de klasse waartoe deze beschrijving behoort. Bij een veld hoort informatie zoals de naam, het type en de zichtbaarheid van het veld, maar ook de annotaties die toegevoegd zijn aan dat veld.
Een methode bevat bijkomend nog informatie over het
aantal parameters en de types van deze parameters. Voor elke methode of veld kan gevraagd worden of ze een speci eke annotatie bevatten of alle annotaties kunnen opgesomd worden. (Horstmann and Cornell, 2008) 1 2 3 4 5 6 7
@Documented @Retention ( R e t e n t i o n P o l i c y .RUNTIME) @Target ({ ElementType . FIELD}) public @ i n t e r f a c e IDPPredicate { String value ( ) ; boolean i n v e r t e d ( ) default f a l s e ; } Codefragment 2.1: De nitie van de IDPPredicate-annotatie.
Een voorbeeld van een de nitie van een nuttige annotatie is gegeven in codefragment 2.1. Deze annotatie kan gebruikt worden om een veld te markeren, zodat deze gekoppeld wordt met het IDP-systeem. Een voorbeeld hiervan kan gevonden worden in codefragment 6.2. Annotaties kunnen in deze masterproef gebruikt worden om hoeveelheid te schrijven code te beperken en zo die code overzichtelijker houden.
Hierdoor zal de code beter onder-
houdbaar zijn.
2.2 JavaServer Pages JavaServer Pages technologie maakt het gemakkelijk om Java code te combineren met XML of HTML. JSP maakt gebruik van tags om pagina's op te bouwen.
Deze tags
kunnen gemengd worden met HTML tags en platte tekst. Om rechtstreeks Java code in de JSP pagina te schrijven, wordt er gebruik gemaakt van de <% en %> tags of een variant hiervan. Hoewel op deze manier om het even welk script kan geschreven worden, is dit niet onderhoudbaar en netjes voor grotere applicaties. Daarom is er een alternatief, namelijk de JavaServer Pages Standard Tag Library of JSTL in combinatie met de Uni ed Expression Language. Met de tags die beschikbaar zijn in de JSTL kunnen eenvoudige dynamische webpagina's gemaakt worden. De Uni ed Expression Language wordt gebruikt om Java objecten in te voegen in deze tags. Voor meer complexe applicaties volstaan de standaard tags niet. Gelukkig is het mogelijk om zelf nieuwe tags aan te maken. Nieuwe tags kunnen volledig in een JSP document geschreven worden, maar dat is nog steeds niet overzichtelijk. Om dit te verhelpen moet er een Tag Library Descriptor ge-
Literatuurstudie
13
schreven worden. Hierin staat de beschrijving van de tags in de bibliotheek en de Java klassen die uitgevoerd moeten worden wanneer zo een tag voorkomt in een JSP pagina. De klassen die als Tag Handler gebruikt worden, moeten de
Tag interface implementeren.
JSP tags kunnen zelf nieuwe variabelen aanmaken of bestaande variabelen in de pagina gebruiken en aanpassen. Een tag heeft ook toegang tot de tags waarin deze zich bevindt. Op deze manier kunnen verschillende tags gecombineerd worden om afhankelijk van de situatie de gewenste functionaliteit te verkrijgen.
2.2.1 JavaServer Faces Het JavaServer Faces framework is een JSP tag library waarmee een webapplicatie met een gebruikersinterface kan gemaakt worden die sterk gelijkt op die van een standaard Java applicatie. Aangezien het HTTP-protocol geen toestand bijhoudt, moet die op een andere manier bewaard worden. De applicatieserver zal voor een JSF-applicatie de toestand van de gebruikersinterface automatisch bijhouden en terug opvragen wanneer een volgende HTTP-aanvraag binnenkomt. Achterliggend worden er aan de JSF componenten convertors, validators en eventlisteners gekoppeld. De eventlisteners zijn gelijkaardig aan die van een gewone applicatie. Ze worden uitgevoerd wanneer een knop wordt ingedrukt of een waarde veranderd. De convertors en validators zijn speci ek voor JSF, aangezien de invoer vanuit een HTTP-request moet omgezet worden. Een JSF-component bestaat uit meerdere JSP-tags. Omsluitend is er de component tag, die bepaald welke component er in de pagina wordt geplaatst. In die component worden verschillende tags geplaatst, waardoor de component zijn functionaliteit verkrijgt. Om de koppeling te maken met de kennisbank zou het volstaan om zelf een JSP Tag Library te maken met tags die in een JSF-component geplaatst kunnen worden. Door één van die tags dan in een JSF-component te plaatsen wordt de component met de kennisbank gekoppeld wanneer de Tag Processor de JSP-pagina omzet naar een
Servlet.
Een voorbeeld van een applicatie die gebruik zou maken van de tags is aangegeven in codefragment 2.2.
2.3 Internationalisatie Om een applicatie toegankelijk te maken voor een breed publiek, is het noodzakelijk om na te denken over internationalisatie en localisatie. Internationalisatie is het aanpassen van een applicatie zodat die kan gebruikt worden in verschillende talen. Localisatie is het aanpassen van een applicatie aan verschillende regio's. Deze aanpassingen zijn bijvoorbeeld de weergave van data, valuta of andere getallen. De standaardmanier om een Java applicatie te internationaliseren is volgens Oracle (2010b) door het gebruik van resource bundles. Dit zijn instanties van de
ResourceBundle klasse.
Een resource bundle wordt ofwel ingeladen met een .properties bestand ofwel met een subklasse van de
ListResourceBundle
klasse.
In beide gevallen wordt er een lijst van
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
< j s f : combobox>
< j s f : checkbox/> < j s f : checkbox/> < j s f : checkbox/> Codefragment 2.2: Gebruik van JSF tags.
sleutel-waarde paren voorzien, waarbij de sleutel zorgt voor de identi catie van een stuk tekst en waarbij de waarde een stuk tekst voorstelt in de gewenste taal.
2.4 Service Provider Interface Om het gedrag van de gekoppelde componenten van de GUI gemakkelijk te veranderen, kan er gebruik gemaakt worden van bibliotheken die dynamisch geladen kunnen worden. Ook kunnen er door een bibliotheek toe te voegen nieuwe componenten ondersteund worden. Een mogelijkheid in Java om dynamisch te laden bibliotheken te maken is door het maken van een SPI. `Service Provider' is de term voor een dergelijke dynamische bibliotheek. De service die wordt aangeboden is een implementatie van de SPI. Een SPI bestaat uit één of meerdere interface klassen. Deze klassen zijn gekend door de applicatie die gebruik wenst te maken van de service en door alle service providers.
Als de versies van de interface klassen
verschillen kunnen er con icten optreden bij het gebruik van een service. Daarom is het belangrijk dat de interface klassen bij alle partijen identiek gede nieerd zijn. Een `Service Provider' zal concrete klassen bevatten die de klassen van de SPI implementeren.
Op deze manier kan dynamisch nieuwe functionaliteit aangeboden worden.
Om
de `Service Provider' te kunnen inladen en te kunnen beslissen of een `Service Provider' de gewenste service kan leveren, moet er een providerklasse voorzien worden. De providerklasse moet aan een paar voorwaarden voldoen. De belangrijkste voorwaarde is dat de klasse een constructor moet hebben zonder argumenten, zodat die kan geïnstantieerd worden. De providerklasse moet snel kunnen ingeladen worden door een Java Class Loader omdat bij het zoeken naar `Service Providers' alle gevonden providerklassen ingeladen worden. Er moet een methode gede nieerd zijn in de providerklasse zodat kan bepaald
Literatuurstudie
15
worden of een implementatie van die klasse de gevraagde implementatie is. Verder is de speci catie van een providerklasse vrij. Een `Service Provider' wordt ingepakt in een JAR-bestand.
In de speci catie van het
JAR-formaat is een directory vastgelegd waar services worden gede nieerd. De directory is META-INF/services. Indien er een SPI met een providerklasse
Provider
bestaat
in een pakket be.mijnProject.mijnPakket, dan moet er een tekstbestand met de naam be.mijnProject.mijnPakket.Provider in die directory geplaatst worden om een service aan te bieden die die SPI implementeert.
Veronderstel dat we een implementatie aan-
bieden met de naam ProviderImplementatie in het pakket com.dummy, dan moet in het tekstbestand de regel com.dummy.ProviderImplementatie toegevoegd worden. Als aan de
ServiceLoader wordt gevraagd om een implementatie te zoeken van de Provider-
klasse zal die in alle JAR-bestanden gaan zoeken naar de META-INF/services directory. Indien in die directory een bestand gevonden wordt met als naam de canonieke naam van de providerklasse, be.mijnProject.mijnPakket.Provider, dan zal er in dat tekstbestand een opsomming staan van alle implementerende klassen in het omsluitende JAR-bestand. Het volstaat om die klassen te instantiëren. (Oracle, 2010c)
2.5 Besluit Van een aantal mogelijkheden om een koppeling te maken van een GUI naar het IDPsysteem, zijn annotaties het eenvoudigst te implementeren. Deze technologie zit standaard in Java ingebakken, wat maakt dat het in elke Java applicatie gebruikt kan worden. Er is ook een standaardmanier om de elementen van de GUI in de moedertaal van de gebruiker om te zetten. Tot slot is een SPI een gemakkelijke manier om dynamisch ondersteuning voor nieuwe componenten toe te voegen aan een applicatie.
Ook kan hiermee het gedrag van de
gebruikte componenten veranderd worden zonder dat de applicatie opnieuw moet gecompileerd worden.
Hoofdstuk 3 Operationeel maken van de benodigde Windows programma's De API die in deze masterproef gemaakt wordt, heeft als doel het toegankelijk maken van het IDP-systeem.
Dit systeem is opgebouwd uit verschillende programma's.
Deze
programma's zijn voor het grootste deel in C++ geschreven, aangevuld met gegenereerde C code. Dit zijn native talen wat wil zeggen dat de code, geschreven in deze talen, voor elk platform opnieuw gecompileerd moet worden. Hierbij wordt mogelijk een verschillende compiler en C++ runtime library implementatie gebruikt. De programma's waren ontwikkeld en getest op het GNU/Linux platform en gecompileerd met de GNU C++ Compiler. Het systeem dat ik gebruik bij de ontwikkeling van de API is voorzien van het Microsoft Windows 7 besturingssysteem. Daarom zal ik in dit hoofdstuk beschrijven welke aanpassingen er nodig waren aan deze programma's, zodat ze ook met behulp van de Microsoft C++ Compiler gecompileerd konden worden op het Microsoft Windows platform.
3.1 ISO C en C++ standaarden De C standaard [ISO/IEC 9899:1999] en C++ standaard [ISO/IEC 14882:2003] speci ëren welke taalconstructies geldig zijn en welke tot onbepaald gedrag leiden. Het is niet altijd even gemakkelijk om de situaties af te leiden die tot onbepaald gedrag leiden, aangezien de code die daarvoor verantwoordelijk is niet altijd gegroepeerd is of omdat hiervoor een grondige kennis van de standaard vereist is.
Om een deel van de fouten op te lossen
zijn er richtlijnen opgesteld. Deze richtlijnen geven aan welke naamgevingen de voorkeur hebben, welke structuur en afmeting optimaal is voor functies, enzovoort.
Niemand is
verplicht om die richtlijnen te volgen maar het is wel sterk aanbevolen. Die richtlijnen kunnen ook verschillen aangezien ze niet opgelegd zijn en onder invloed van persoonlijke voorkeuren zijn. Sommige richtlijnen worden beschreven als Design Patterns.
Een voorbeeld van een
belangrijke richtlijn en design pattern in C++ is RAII. Resource Acquisition Is Initialisation wordt gebruikt om te voorkomen dat er geheugen weglekt en dat andere bronnen
in een inconsistente toestand achtergelaten worden.
Een implementatie van RAII om
geheugenlekken te voorkomen is de Smart Pointer.
Deze pointers, verwijzingen naar
geheugenadressen, zijn slim omdat ze automatisch de gegevens, waar ze naar verwijzen, vrijgeven wanneer ze verwijderd worden. Door het gebruik van de richtlijnen wordt de code duidelijker, beter te onderhouden en dus robuuster.
3.2 GidL Een programma dat gebruikt wordt door de API is de grounder, GidL. Dit programma zet de IDP-taal om in een interne voorstelling die gemakkelijker en sneller te verwerken is. Dat is standaard ook het enige dat de grounder kan. Voor deze masterproef is er een aangepaste versie beschikbaar gesteld. Door een instelling van de grounder te veranderen, gaat deze niet langer de invoer omzetten maar hierover informatie teruggeven. De mogelijkheid om die instelling te veranderen werd toegevoegd aan de aangepaste versie. De informatie die wordt teruggegeven zijn de symbolen die gebruikt worden in het IDPbestand. Het is mogelijk om alle symbolen op te vragen door de optie mode=returnvoc te gebruiken. Dit zijn alle gebruikte types, predikaten en functies. Maar ook kunnen enkel de symbolen opgevraagd worden die gebruikt worden als invoer of uitvoer door de opties mode=returngiven of mode=return nd te gebruiken. Bij het compileren van GidL zijn er een aantal fouten opgedoken. Als eerste was er in verschillende functies het return statement vergeten. Dit was ook het geval wanneer er een belangrijke waarde werd teruggegeven.
Ook heb ik een functie gevonden waarvan
twee argumenten dezelfde naam hadden. Na het oplossen van deze fouten werkte GidL en verkreeg ik het te verwachten resultaat.
3.3 Approx Het andere programma dat gebruikt wordt door de API is Approx. Dit is het belangrijkste programma omdat het de oplossing van een probleem berekent of toch benadert.
Om
approx uit te voeren wordt het IDP-probleem ingevoerd samen met een deel van de oplossing die reeds bekend is.
Approx zal dan bepalen of het ingevoerde deel van de
oplossing geldig is en zal ook de oplossing aanvullen. Ook bij dit programma waren er fouten bij het compileren. Zoals bij GidL ontbraken er in verschillende functies het return statement. In een functie waren er een aantal lokale variabelen dubbel gedeclareerd. Hierdoor werden niet alle bewerkingen opgeslagen. Verschillende lokale en object variabelen waren ook niet geïnitialiseerd, wat onvermijdelijk tot onbepaald gedrag leidt.
Als het programma als debug-versie gecompileerd wordt,
zijn deze fouten niet zichtbaar omdat in deze versie al het geheugen dat gealloceerd wordt zal geïnitialiseerd worden met de waarde nul. Wanneer een geoptimaliseerde versie gecompileerd wordt, zal die impliciete initialisatie weggelaten worden waardoor uit het
Windows programma's
19
niets fouten verschijnen. Dit veroorzaakte elke keer een segmentatiefout omdat pointers naar ongeldige geheugenadressen verwijzen en indices van arrays naar elementen verwijzen die niet bestaan. De laatste moeilijk te vinden fout heeft te maken met sequence points. Een sequence point is een moment of plaats in de uitvoering van code waar alle neveneffecten van voorgaande code volledig afgewerkt zijn en nog geen enkel neveneect van nakomende code begonnen is.[ISO/IEC 14882:2003] In C++ is een punt komma `;' één van de sequence points en eveneens het symbool dat een statement beëindigt.
Dat wil zeggen dat alle
neveneffecten van een statement uitgevoerd moeten zijn voordat de uitvoering van een volgend statement kan starten. De genoemde neveneffecten kunnen zo eenvoudig zijn als het wegschrijven van een berekende waarde. Fouten doen zich voor wanneer een sequence point ontbreekt tussen twee operaties die naar dezelfde variabele of hetzelfde geheugenadres schrijven. Het is onzeker welke operatie eerst zal gebeuren, maar ook of de geheugenlocatie nog geldig is na de eerste schrijfoperatie. In codefragment 3.1 ontbreken een aantal sequence points waardoor in sommige gevallen een segmentatiefout wordt veroorzaakt.
Dit is één van de functies die een crash van
getBDD en disj zijn functies en kernel, low en high zijn objecten std::vector. Het gebrek aan sequence points is een samenloop van
Approx veroorzaakte. van het type
omstandigheden.
1
r = getBDD( k e r n e l [ b1 ] , d i s j ( low [ b1 ] , low [ b2 ] ) , d i s j ( high [ b1 ] , high [ b2 ] ) ) ; Codefragment 3.1: Code zonder sequence points
Ten eerste zijn de komma's tussen de argumenten van
getBDD
en
disj
geen sequence
points. Het is dus niet gede nieerd welk argument eerst zal geëvalueerd worden. De enige zekerheid is dat alle argumenten geëvalueerd zijn voordat de functie wordt opgeroepen waarin de argumenten gebruikt worden.
Het is dus mogelijk dat een argument eerst
gedeeltelijk wordt geëvalueerd, waarna een ander argument wordt geëvalueerd en tot slot de evaluatie van het eerste argument verder wordt afgewerkt. In dit geval werd de code zodanig gecompileerd dat eerst beide waarden uit waarden uit
high
en daarna werd de functie
mag dit doen omdat de argumenten van
disj
disj
low
werden opgehaald, daarna beide
twee maal uitgevoerd.
De compiler
geëvalueerd zijn voordat de functie wordt
opgeroepen en bovendien zorgt dit voor een betere prestatie omdat hierdoor de code van de
disj functie na de eerste uitvoering zich nog in de processorcache bevindt en dus geen
tweede keer moet ingeladen worden. Ten tweede zijn
low
en
high
geen lokale variabelen. Daardoor kan
die rechtstreeks of onrechtstreeks wordt opgeroepen door
disj
disj
of een functie
de variabelen aanpassen.
Op zichzelf is dit niet erg, zolang de aanpassingen niet interfereren met elkaar. Maar in
disj
worden de vectoren
low
en
high
aangepast door hier nieuwe elementen aan toe te
voegen. De derde en laatste meespelende factor is de
std::vector
is een containerklasse met veranderlijke grootte.
klasse.
Deze klasse
Wanneer er niet genoeg ruimte is in
een object van die klasse dan zal het object een groter stuk geheugen alloceren.
De
speci catie van
std::vector stelt dat de elementen in de container opgeslagen zijn
in een aaneensluitend geheugenblok.
Als de vector nieuw geheugen moet alloceren en
er is geen ruimte meer vrij vlak achter het gebruikte blok, dan zal een volledig nieuw blok aangemaakt worden en alle bestaande elementen zullen verplaatst worden naar het nieuwe, grotere blok. Het geheugen van het oude blok wordt daarna vrijgegeven. In de documentatie is vermeld dat als dit gebeurt, dan alle externe referenties naar elementen in de vector ongeldig worden. Dit is logisch aangezien die referenties verwijzen naar het vrijgegeven geheugenblok. 1 2 3
namespace s t d { class vector { c o n s t _ r e f e r e n c e o p e r a t o r [ ] ( s i z e _ t y p e n ) const ;
4 5
};
6
/
∗
code
weggelaten
∗/
7 8 9
};
/
∗
code
weggelaten
∗/
Codefragment 3.2: Declaratie van de index operator van de vector klasse
De index operator van de vector klasse is gedeclareerd zoals te zien is in codefragment 3.2. Dit wil zeggen dat het een functie is die als argument een getal aanvaardt van het type
size_type.
De terugkeerwaarde is een constante referentie naar het gevraagde element
in de vector en de functie is een constante functie, wat wil zeggen dat de functie geen veranderingen zal aanbrengen aan het object waarop het opgeroepen is. Het belangrijke gedeelte is de terugkeerwaarde. Ze is constant, wat wil zeggen dat ze niet mag aangepast worden door de code die de operator heeft opgeroepen. De terugkeerwaarde is ook een referentie. Dit betekent dat het een verwijzing is naar het adres waar het element van de vector zich bevindt. Als de drie voorgaande factoren in rekening worden gebracht is het duidelijk dat de code in codefragment 3.1 voor ongede nieerd gedrag kan zorgen. Namelijk, de adressen van de elementen worden eerst opgehaald, aangezien de compiler dit als meest optimale volgorde ziet.
De functie
disj
wordt een eerste keer opgeroepen.
Deze functie gaat onder
bepaalde voorwaarden een element toevoegen aan één van de vectoren. Als er in de vector te weinig geheugen beschikbaar is, zal deze nieuw geheugen alloceren waardoor de bestaande elementen een nieuw adres toegewezen kunnen krijgen. Bij de tweede oproep van
disj
worden de oude adressen gebruikt om de argumenten door te geven. De oude
adressen zijn op dat moment ongeldig en zullen afhankelijk van externe factoren ofwel willekeurige gegevens bevatten ofwel niet meer tot de adresruimte van het proces behoren. Het programma zal daardoor crashen met een segmentatiefout of verder werken met een willekeurige waarde, wat in ieder geval geen betrouwbaar resultaat oplevert. Deze fout kan opgelost worden door één van de drie factoren te elimineren. De implementatie van de vector klasse kan niet veranderd worden. Dat hoeft ook niet want met die klasse op zich is niets verkeerd. Het is zeer moeilijk voor mij om het algoritme zodanig te veranderen dat de vectoren niet meer aangepast worden in de
disj
functie, aangezien
het algoritme voor mij een black box is. Gelukkig is de eerste factor gemakkelijk aan te
Windows programma's pakken. Door de argumenten van de
21 getBDD functie toe te wijzen aan tijdelijke variabelen,
waardoor de code opgesplitst wordt in verschillende statements, zullen de juiste sequence points toegevoegd worden. Nadat alle vernoemde fouten uit de broncode van Approx verwijderd zijn, kan het programma snel en stabiel uitgevoerd worden. Voorheen functioneerde dit programma enkel wanneer het gecompileerd was met debug instellingen en zonder optimisaties. Dat maakte het programma ongeveer vijf keer trager. Hierdoor was het testen van de API lastig en langdurig.
3.4 Besluit De GNU C++ Compiler, die gebruikt werd door de ontwikkelaars van GidL en Approx, genereerde werkende machinecode voor de C++ code met ongede niëerd gedrag. Hierdoor hebben de ontwikkelaars de in dit hoofdstuk vernoemde fouten waarschijnlijk niet opgemerkt en bleven deze fouten onopgelost. Ik heb de ontwikkelaars achteraf gecontacteerd om de oplossingen voor de gevonden fouten aan hen door te geven. Door deze fouten op te lossen, kon de API sneller getest worden. Dit heeft de productiviteit sterk verhoogd.
Hoofdstuk 4 Ontwerp In dit hoofdstuk zal ik de architectuur van de API toelichten, vertrekkende van een overzicht en gaande naar details over de onderdelen van de verschillende modules. Om de API op een degelijke manier te kunnen implementeren heb ik eerst een ontwerp gemaakt. Hierdoor is de API van in het begin logisch en gestructureerd opgebouwd. Dit draagt bij tot de exibiliteit en uitbreidbaarheid van de API. Ontwerp- en implementatieproblemen worden op deze manier ook sneller ontdekt, waardoor de implementatietijd verkort wordt. De API is opgebouwd uit verschillende modules. Deze modules bestaan elk uit verschillende onderdelen, die er samen voor zorgen dat een module zijn taak kan vervullen. Door het opsplitsen in modules kunnen eventuele programmeerfouten sneller ontdekt en opgelost worden. Het is ook gemakkelijker om aparte modules te testen in plaats van het volledige systeem. De mogelijkheid bestaat immers om een module af te zonderen door alle andere hiermee verbonden modules te vervangen door stubs. Een stub is een stuk code die uitwendig dezelfde functionaliteit heeft en dezelfde resultaten teruggeeft als de module die vervangen wordt.
De stub moet zo eenvoudig mogelijk
gemaakt worden, zodat kan verzekerd worden dat deze zelf geen fouten bevat. Door ervoor te zorgen dat er enkel in de geteste module eventuele fouten kunnen optreden, is het mogelijk om deze module individueel te testen. Dit is een groot voordeel van een modulaire opbouw. Opmerking: De guren die in dit hoofdstuk bij elke module gebruikt zijn voor de verdui-
delijking van de inhoud van de module, volgen een bepaalde conventie. De onderdelen die deel uitmaken van de betreende module zijn voorgesteld door witte rechthoeken of, indien ze zich in een ander onderdeel bevinden, door gekleurde rechthoeken. Deze rechthoeken hebben puntige hoeken. De onderdelen die niet tot de module behoren zijn voorgesteld door gekleurde rechthoeken met afgeronde hoeken. De verbindingspijlen tussen onderdelen van de module zullen de onderdelen raken.
De
verbindingspijlen tussen een onderdeel van de module en een externe module, waarmee deze communiceert, raken de onderdelen niet.
Gebruikersinterface Keuze 1 2 Keuze 1 2 3
Opties Optie 1 Optie 2 Optie 3
Verzend
Opnieuw
API Analyse
Configuratie
Kennisbank abstractie
Kennisbanksysteem Approx
Kennisbanken
GidL
Figuur 4.1: Overzicht van de architectuur van de API
Ontwerp
25
4.1 Overzicht De API moet de verbinding verzorgen tussen een kennisbank en een applicatie die gebruik maakt van de API. Op het hoogste niveau bestaat de API uit drie modules ( guur 4.1): de kennisbank abstractie module, de con guratie module en de analyse module. De kennisbank abstractie module zorgt voor een gemakkelijk in Java te gebruiken voorstelling van de kennisbank. Wijzigingen aan de staat van de kennisbank zullen via deze module uitgevoerd worden en de applicatie zal een melding krijgen wanneer de staat van de kennisbank is gewijzigd. De con guratie module zal adapters aanmaken om componenten van de GUI te koppelen met het kennisbanksysteem. Hierdoor hoeft niet voor elke soort van gra sche component een koppelingsklasse geschreven te worden door de applicatieprogrammeur zelf. De analyse module zal aan de hand van annotaties aan de juiste GUI componenten een adapter uit de con guratie module koppelen. In het eenvoudigste geval bestaat de applicatie enkel uit een gebruikersinterface.
Er
wordt dan volledig vertrouwd op de functionaliteit van de API zelf om de applicatie te laten werken. Het is louter voor het opstarten en initieel opbouwen van de interface dat de applicatie zelf logica zal bevatten.
De analyse module is dan de enige module die
aangesproken zal worden door de applicatie. Deze module is dan ook de eenvoudigste en minst exibele module van de drie. Voor meer geavanceerde applicaties zal er vanuit de applicatiecode meer interactie zijn met de twee andere modules van de API. Wanneer er bijvoorbeeld dynamisch nieuwe gra sche componenten aangemaakt en gekoppeld moeten worden, dan is de con guratie module nodig.
De con guratie module levert immers adapters voor de verschillende gra sche
componenten. Die adapters verbinden volledig automatisch de gewenste component met de kennisbank. Indien een zo groot mogelijke controle over de API gewenst is, moet de kennisbankabstractielaag rechtstreeks aangesproken worden. Hiermee kunnen direct veranderingen worden aangebracht aan het op te lossen probleem. Daarenboven is het ook mogelijk om te wachten op berichten over aanpassingen aan het op te lossen probleem.
4.2 Kennisbankabstractie De grootste en belangrijkste module is de kennisbankabstractiemodule ( guur 4.2). Het hoofddoel van deze module is het doorspelen van gestructureerde gegevens tussen de applicatie en de kennisbank.
Dit gebeurt op een zodanige manier dat de applicatie geen
kennis hoeft te hebben over de manier waarop de kennisbank de gegevens verwerkt. Bijkomend zorgt deze module ook voor het verbergen of oplossen van tekortkomingen aan de kennisbank zelf, waarvan een aantal in hoofdstuk 5 zullen behandeld worden.
Progress listener Processing listener
Conflict listener
Conflict listener Conflict listener Conflict listener
Completion listener
Processing listener Processing listener Processing listener
Applicatie
Completion listener Completion listener Completion listener
Solution
- Undo - Redo - Reset
Change State writer
Model Stateless
State listener Change listener Change listener
Stateful
State processor
Solution state
Symbol
Symbol
State
Symbol
Symbol
State
Undo stack
Kennisbanksysteem
Model reader
Figuur 4.2: Overzicht van kennisbank abstractie module
State reader
Ontwerp
27 Model Symbol <>
Instance
*
1
*
Type
StatefulSymbol <>
Predicate
Function
Figuur 4.3: Klassediagram van de model klassen
4.2.1 Model Zoals eerder vermeld is de oplossingstoestand opgebouwd uit de toestanden van toestandsvolle symbolen. Deze symbolen, samen met de toestandsloze symbolen, vormen het model van een probleem. De symbolen in het model zijn alle symbolen die beschikbaar zijn via de API voor een bepaald probleem.
Het probleem bevat mogelijk nog meer symbolen
maar die kunnen enkel intern in de kennisbank gebruikt worden. Die symbolen zullen dus niet terug te vinden zijn in het model aangezien ze niet gebruikt kunnen worden. Door het model in een apart onderdeel te plaatsen is het mogelijk om dit model te delen tussen verschillende oplossingen voor hetzelfde probleem. Eens geladen wordt het model niet meer aangepast. Dit is interessant in situaties waar meerdere instanties van dezelfde applicatie uitgevoerd worden, bijvoorbeeld op een server. Er is op de server op elk moment maar één model object nodig per probleem, ongeacht het aantal oplossingen dat gezocht wordt voor dat probleem. In guur 4.3 is de structuur van de modelklassen weergegeven. Elke entiteit die uit het IDP-systeem wordt opgehaald is een
Symbol. Een Symbol heeft een naam en kan hiermee Symbol zijn: Type, Instance en StatefulSymbol.
opgevraagd worden. De subklassen van
Type-klasse stelt de Instance-objecten voor De
datatypes voor uit de kennisbank. elk
Type
en deze
Instance-objecten
Er bestaan verschillende hebben dat
Type
als da-
tatype. Een
StatefulSymbol
is een
Symbol
waarvoor een toestand kan bijgehouden worden. Dit
gebeurt door middel van parameters die elk van een bepaald van deze parameters een speci eke
Instance
`tuple'. Dit is één bepaalde toestand van het De
Predicate-klasse
Type zijn.
Wanneer voor elk
wordt gekozen, wordt er gesproken van een
StatefulSymbol.
is een symbool dat een toestand kan bevatten aan de hand van
verschillende parameters. De
Function-klasse
geeft een verband tussen een waarde van
de parameters en de resulterende waarde die hiervoor wordt teruggegeven. Deze klasse is echter niet volledig geïmplementeerd in de API, omdat er geen praktisch voorbeeld was
dat een functie gebruikte om de kennisbank te con gureren. Indien een zou gebruikt worden in de kennisbank, kan deze ingekapseld worden met
Function toch een Predicate.
4.2.2 Toestand Eén van de problemen met de IDP-kennisbank is dat deze zelf geen staat kan bijhouden. De kennisbank wordt opgeroepen waardoor deze de nieuwe staat zal berekenen. Zodra dit gebeurd is, wordt als antwoord de nieuwe toestand teruggegeven en beëindigt de kennisbank zichzelf. Daarom is het nodig dat de API de staat van het probleem beheert. De staat van een oplossing wordt bijgehouden in het`Solution state' onderdeel, of oplossingstoestand, dat geïmplementeerd is door de gelijknamige
SolutionState
klasse. Van
dit onderdeel wordt er één exemplaar als huidige toestand bijgehouden in het `Solution' onderdeel. De oplossingstoestand is opgebouwd uit de toestanden van elk toestandsvol symbool. Wijzigingen aan deze toestanden gebeuren via de oplossingstoestand door middel van `Change'-objecten. `Change'-objecten die elk een wijziging voorstellen, worden samengenomen in stappen. Een stap is een verzameling van logisch samenhangende wijzigingen. De toestand wordt enkel als consistent beschouwd wanneer een gehele stap is uitgevoerd. Het is daarom niet zinvol en ook niet mogelijk om individuele wijzigingen ongedaan te maken en opnieuw uit te voeren, dus worden deze bewerkingen altijd uitgevoerd op stappen. Een stap wordt aangemaakt als reactie op een wijziging door de applicatie. De kennisbank zal de net aangemaakte stap verder aanvullen met wijzigingen om de toestand consistent te houden. Dit is dus een kwestie van actie en reactie. De applicatie of gebruiker initieert altijd een wijziging en de kennisbank reageert hierop. Dit gebeurt in één bewerking. De oplossingstoestand zal ook antwoorden met change objecten. Op deze manier wordt aangegeven welke wijzigingen er zijn gebeurd door een operatie die uitgevoerd is op de oplossingstoestand. Dit komt voor bij eender welke bewerking die meerdere wijzigingen als gevolg kan hebben, bijvoorbeeld het herinitialiseren van de toestand of ongedaan maken van een stap. In guur 4.4 wordt getoond hoe een aanpassing aan de toestand in zijn werk gaat. De applicatie maakt in een stap met behulp van `Change'-objecten een tijdelijke toestand. Deze toestand zal door de `Change'-objecten aangepast zijn. Daarna zal het kennisbanksysteem op de tijdelijke toestand wijzigingen uitvoeren om de nieuwe toestand consistent te maken. Alle wijzigingen die in deze stap zijn uitgevoerd, worden door middel van de StateListeners gemeld aan de applicatie.
4.2.3 Gegevensverwerking Om het model in te laden in een applicatie wordt er van een maakt. Deze
ModelReader
gebruik ge-
ModelReader is speciaal ontworpen voor een bepaald kennisbanksysteem, in
dit geval het IDP-kennisbanksysteem. Het is mogelijk om voor een ander kennisbanksys-
Ontwerp
29
Applicatie
Change
State listener Change listener Change listener
Change
Solution
SolutionState
SolutionState
SolutionState
Stap
Change
Kennisbanksysteem
Figuur 4.4: Principe van het veranderen van de toestand in een stap.
teem eenModelReader te implementeren zolang de modelvoorstelling van die kennisbank compatibel is met de modelvoorstelling van de API. Gelijkaardig aan de model reader bestaat er ook een
StateReader.
de toestand inlezen en verwerken, afkomstig van de kennisbank.
StateProcessor StateWrite.
de kennisbank opgeroepen door de geschreven door middel van een De
StateReader, StateWrite
en
StateProcessor
De state reader zal Hiervoor werd eerst
en de toestand naar de kennisbank
zijn ook speciaal ontworpen voor de
IDP-kennisbank. Ook bij deze onderdelen is het mogelijk ze te implementeren voor een andere kennisbank. Uiteraard is dit enkel het geval als de modelvoorstelling compatibel is. Het valt op te merken dat de verwerking van de toestand opgesplitst is in drie onderdelen.
Dit is niet strikt noodzakelijk maar bevordert de testbaarheid en exibiliteit.
De
verklaring hiervoor zal verder toegelicht worden in sectie 5.2.
4.2.4 Solution Het Solution onderdeel (in guur 4.2) komt overeen met de Solution klasse in de API. Deze klasse houdt de kennisbankabstractiemodule bij elkaar. Het houdt de huidige toestand, de verschillende Listeners en de processor met zijn reader en writer bij. Deze klasse zorgt er ook voor dat al deze componenten als een mooi geheel samenwerken. Als wijzigingen binnenkomen van de applicatie zal Solution zorgen dat deze wijzigingen worden toegepast op de toestand en dat het kennisbanksysteem deze wijzigingen controleert en bijstuurt. Ook zal deze component de Listeners oproepen om de wijzigingen te melden.
4.2.5 Event listeners Om de resultaten van een bewerking te verkrijgen wordt er van
EventListeners
gebruik
gemaakt. Er zijn verschillende soorten eventlisteners beschikbaar in de API, elk om een bepaald type van gebeurtenissen op te vangen. Om een gebeurtenis te kunnen opvangen moet de desbetreende event listener geregistreerd worden op het Solution onderdeel. Een eerste soort eventlistener is de
StateListener.
Deze soort wordt enkel geregistreerd
op de symbolen waarvoor dat gevraagd wordt en zal dus ook enkel opgeroepen worden wanneer de toestand van één van die symbolen gewijzigd wordt.
Omwille van perfor-
mantieredenen heb ik deze ontwerpbeslissing genomen. Het is namelijk zo dat regelmatig meerdere symbolen gewijzigd worden in één bewerking. Indien bij elke wijziging alle state listeners zouden opgeroepen worden, waarbij elke state listener voor zichzelf moet opzoeken of het van toepassing is op het gewijzigde symbool, zou dit leiden tot een grotere systeembelasting. Dit is zeker het geval wanneer het aantal listeners toeneemt. De andere soorten eventlisteners worden altijd opgeroepen.
De impact hiervan is veel
kleiner aangezien de methodes van deze listeners hoogstens één maal worden opgeroepen
Ontwerp
31
per bewerking. Bijkomend is er ook geen rechtstreeks verband tussen een instantie van één van deze listeners en een bepaalde wijziging. Door het gebruik van eventlisteners moet er niet gewacht worden op de resultaten van een bewerking. De bewerking wordt gestart en de applicatie die de methode van de API heeft opgeroepen kan onmiddellijk verder werken. Wanneer de resultaten beschikbaar zijn, zal de applicatie verwittigd worden door middel van de event listeners die het voorheen geregistreerd heeft. Dit wordt ook wel asynchrone uitvoering genoemd. Het tegenovergestelde van asynchrone uivoering is synchrone uitvoering en deze techniek maakt gebruik van de terugkeerwaarde. Een bewerking wordt ook hier gestart door een methode op te roepen maar de applicatie kan pas verder werken wanneer de bewerking klaar is en de methode terugkeert met het resultaat als terugkeerwaarde. De applicatie heeft zolang de bewerking wordt uitgevoerd geen mogelijkheid om verder te werken. De doelomgeving van de API zijn applicaties met een gra sche gebruikersinterface. Een GUI is ook gebaseerd op gebeurtenissen. Wanneer de gebruiker interageert met de applicatie, zullen er events gegenereerd worden. Deze events worden in een wachtrij gezet om één voor één afgehandeld te worden in de context van de event thread.
Alle event
listeners die hierop geregistreerd zijn worden eveneens uitgevoerd in de context van de event thread. Het is niet onbegrijpelijk dat het een slechte zaak is indien één van die event listeners een synchrone bewerking zou starten waarvan niet geweten is wanneer die zal eindigen. Zolang de bewerking in uitvoering is, kunnen alle events in de wachtrij van de GUI niet verder verwerkt worden. Dit heeft als gevolg dat de GUI niet meer zal reageren op interacties van de gebruiker, waardoor de gebruiker de indruk krijgt dat de applicatie is vastgelopen. Een vuistregel voor gra sche gebruikersinterfaces is dat de reactietijd onder één tiende van een seconde moet blijven om een vloeiende gebruikerservaring te behouden. Indien dit niet mogelijk is, moet volgens Nielsen (1994) de wachttijd door middel van een visuele hint kenbaar gemaakt worden. Uit tests met de kennisbank heb ik gemerkt dat deze voor meer complexe problemen een uitvoeringstijd heeft in de ordegrootte van een seconde of meer. Om te verhinderen dat de gebruikerservaring geschaad wordt, is het noodzakelijk de bewerkingen op de kennisbank asynchroon uit te voeren.
Dit is, bovenop de exibiliteit, een belangrijke reden om te
kiezen voor event listeners.
4.3 Con guratie De con guratiemodule ( guur 4.5) zal adapters aan de API leveren om GUI componenten te koppelen met de kennisbankabstractiemodule. Op zichzelf is dit een kleine module. Ze bestaat uit de
Configurator-klasse en een aantal klassen die samen een SPI vormen.
De
con gurator zal de juiste `Service Provider' uitzoeken, om hiervan de aangeboden `Service' in te laden. Hoe dit gebeurt, zal toegelicht worden in sectie 5.5. De providerklasse van de SPI die beschikbaar wordt gesteld in deze module, is de klasse. Elke implementatie van de
Toolkit-klasse
Toolkit-
heeft een naam, zodat de con gurator
Gebruikersinterface Keuze 1 2 Keuze
Kennisbank abstractie
Applicatie
1 2 3
Opties Optie 1 Optie 2 Optie 3
Verzend
Opnieuw
Configurator Service Provider Interface Service Providers Service Exception handler
Exception handler factory
Adapter Radio button
Adapter factory Radio button
Adapter Checkbox
Adapter factory Checkbox
Adapter Dropdown list
Adapter factory Dropdown list
Toolkit
Figuur 4.5: Overzicht van de con guratiemodule
Ontwerp
33
op basis hiervan de gewenste versie kan uitkiezen. ries aanleveren: de
Een toolkit kan twee soorten facto-
ProcessingExceptionHandlerFactory
en de
AdapterFactory.
Van
beide soorten factories kunnen er verschillende implementaties gemaakt worden. Elke implementatie kan adapters produceren die bevestigd kunnen worden op een bepaald soort van objecten. Een
AdapterFactory produceert Adapters voor één soort van de gra sche componenten.
Voor elke door de `Service Provider' ondersteunde soort van gra sche componenten bestaat er een factory. Wanneer een symbool of een tuple gekoppeld moet worden met een gra sche component kan aan de juiste factory gevraagd worden om hiervoor een adapter te maken. De aangemaakte adapter zal er voor zorgen dat de toestand van het symbool of het tuple wordt weergegeven door de gra sche component en dat de invoer vanuit de gra sche component de toestand van het symbool of tuple zal wijzigen. Hierdoor is het niet meer nodig dat een programmeur deze objecten manueel verbindt. Dit vermindert sterk de hoeveelheid con guratiecode. De
ProcessingExceptionHandlerFactory
produceert
ProcessingExceptionHandlers.
Hoewel deze klasse niet de term `adapter' bevat, kunnen de instanties ervan toch bevestigd worden aan een soort van objecten. In de kennisbankabstractiemodule kunnen verschillende fouten of
Exceptionss
den waarvoor die module geen eenduidige oplossing kan bieden.
Daarom worden die
Exceptionss
optre-
doorgegeven naar de code die de kennisbankabstractiemodule oproept. Zo-
als vermeld in sectie 4.2.5 kan de API asynchroon gebruikt worden.
Als de methode
die een bewerking gestart heeft reeds is teruggekeerd, is het onmogelijk om via deze weg nog een
Exception
door te geven. Net daarom kan een
ProcessingExceptionHandler
gebruikt worden. Doordat deze handlers als adapter kunnen toegevoegd worden aan bijvoorbeeld een onderdeel van de GUI, is het mogelijk om foutboodschappen in deze GUI te integreren. In een serveromgeving kan het ook interessant zijn om een handler te voorzien die kan bevestigd worden aan een logboek of een database. De reden hiervoor is dat de
Exceptionss die door deze handlers opgevangen worden, kunnen duiden op een verkeerde con guratie van de server of een programmeerfout. Er zijn verschillende gra sche toolkits beschikbaar voor Java.
Daarom is het moeilijk
om voor elke gra sche toolkit een implementatie te maken van de adapters.
Door het
gebruik van de SPI wordt het gemakkelijk om ondersteuning voor bijkomende gra sche toolkits toe te voegen. Eens een serviceprovider voor een bepaalde toolkit ontwikkeld en verpakt is in een JAR, kan dit archief gewoon in de juiste directory geplaatst worden. De con gurator zal dan op zoek gaan naar een implementatie met de gegeven naam.
4.4 Analyse De analysemodule ( guur 4.6) bouwt verder op de automatisering van de con guratiemodule. Daar waar de con guratiemodule de gevraagde symbolen gaat verbinden met een gra sche component, zal de analysemodule in de gebruikersinterface zoeken naar gra sche componenten die verbonden moeten worden met een symbool.
De
Parser
zal met be-
public class Klasse { @IDPAdapterAction("clear") private Button btnClear;
Gebruikersinterface
@IDPAdapterAction("undo") @IDPAdapterVariant("undo") private Button btnUndo; @IDPPredicate("predikaat1") @IDPTuple("keuze1") @IDPAdapterVariant("color") private Checkbox pred1k1;
Keuze 1 2 Keuze
Java Compiler
Kennisbank abstractie
Injecteren 1 2 3
Opties
@IDPPredicate("predikaat1") @IDPTuple("keuze2") @IDPAdapterVariant("color") private Checkbox pred1k2;
Optie 1 Optie 2 Optie 3
@IDPPredicate("predikaat2") private Dropdown pred2; Verzend
/* layout code */
Opnieuw
/* program code */ }
Parser Annotaties @IDPPredicate @IDPTuple Java Reflection API
Configuratie
Parse
Adapter
@IDPAdapterVariant Translator @IDPAdapterAction
Figuur 4.6: Overzicht van de analyse module.
hulp van annotaties bepalen welke gra sche componenten aan welke symbolen gekoppeld moeten worden. De annotaties die voorzien zijn in de analysemodule worden samen met de programmacode ingeladen in de JVM. Door middel van re ectie worden alle componenten in een klasse overlopen. Als een dergelijke component één van de annotaties van deze module bevat dan wordt de annotatie met zijn parameters opgevraagd. Deze parameters vertellen de parser aan welk symbool de component gekoppeld moet worden. Een symbool kan een cryptische naam hebben in de IDP-taal.
Om deze naam om te
zetten in een naam en beschrijving die ook door een leek verstaanbaar is, wordt er gebruik gemaakt van een
Translator.
Niet alleen wordt dit omgezet in leesbare vorm, het is ook
mogelijk om dit aan te passen aan de taal waarin de applicatie gebruikt wordt. Hierdoor kan de applicatie ook in vreemde talen gebruikt worden.
4.5 Besluit In dit hoofdstuk werden de globale architectuur en haar modules en onderdelen opgesomd en toegelicht. Een goed ontwerp zorgt voor minder onverwachte problemen bij de implementatie en voor meer gestructureerde code.
Ontwerp
35
Het werkelijke ontwerpproces is echter niet altijd helemaal rechtlijnig geweest.
Bij de
implementatie zijn er hier en daar toch nog bedenkingen geweest die ertoe hebben geleid dat ik het ontwerp moest herzien. Deze bedenkingen hebben er voor gezorgd dat in de meeste gevallen de API op het gebied van exibiliteit of gebruiksvriendelijkheid verbeterd is. Bij het ontwerpen van de API werd er gebruik gemaakt van verschillende `Design Patterns'. `Design patterns' zijn ontwerpvormen die dikwijls terugkomen bij het maken van software.
Deze ontwerpvormen zijn volgens Holzner (2006) bedoeld om het ontwerp te
verbeteren en meer exibel te maken alsook de code onderhoudbaar te maken. Enkele voorbeelden van design patterns die gebruikt zijn bij het onwerp zijn `Decorator Pattern', `Factory Pattern' en `Adapter Pattern'.
Hoofdstuk 5 Implementatie In dit hoofdstuk worden de implementatiedetails besproken van een aantal onderdelen van de API. Sommige klassen en methodes hebben een niet voor de hand liggende implementatie. Door deze implementaties te beschrijven wordt er een duidelijker beeld gecreëerd van de werking van de API.
5.1 UndoStack Om de Stappen bij te houden in de
SolutionState-klasse
heb ik gebruik gemaakt van
twee stacks: een stack die de stappen bijhoudt om ongedaan te maken en een andere die de stappen bijhoudt om opnieuw uit te voeren. Bij het gebruik van de API zal bij elke wijziging door de gebruiker een nieuwe stap aangemaakt worden. Als het op te lossen probleem omvangrijk is of als de gebruiker veel bewerkingen uitvoert, zullen de opgestapelde stappen meer en meer geheugen innemen. Aangezien geheugen beperkt is en de applicatie zal falen wanneer dit geheugen op is, moet voorkomen worden dat alle ooit gemaakte stappen worden bijgehouden. Om dit probleem op te lossen heb ik de van
Deque,
UndoStack-klasse
gemaakt.
Deze klasse is een implementatie
een interface uit de JRE-bibliotheek. In de
UndoStack-klasse
kan opgegeven
worden hoeveel stappen er worden bijgehouden. De stappen die worden bijgehouden zijn natuurlijk de meest recent toegevoegde stappen. Wanneer de maximale grootte van de stack bereikt is, zal bij het toevoegen van een nieuw element het oudste element verwijderd worden. Zoals de naam van de
UndoStack-klasse aangeeft is dit een ideale implementatie voor een
stack met bewerkingen die ongedaan gemaakt kunnen worden. Deze klasse wordt in de API ook enkel gebruikt voor de stack met stappen die ongedaan gemaakt kunnen worden. Het is niet nodig om deze klasse ook te gebruiken voor de stack met stappen die opnieuw uitgevoerd kunnen worden aangezien deze stack nooit meer stappen kan bevatten dan het aantal in de undostack. Een stap moet immers eerst ongedaan gemaakt worden voordat deze terug kan uitgevoerd worden. Door de grootte van de undostack te beperken wordt dus automatisch de grootte van de redostack beperkt.
5.2 Processing Het processing gedeelde van de kennisbankabstractiemodule dat instaat voor de verwerking van de toestand wordt geïmplementeerd in drie klassen: een reader, een writer en een processor. Om de
Solution-klasse
te kunnen voorzien van instanties van de process-
orklasse wordt er gebruik gemaakt van een factoryklasse. Voor elk kennisbanksysteem wordt er een processor, een reader, een writer en een factory geïmplementeerd.
De reader, writer en processor worden standaard door de factory
gebruikt. Het is mogelijk om de reader en writer te vervangen door een andere implementatie. Voor deze klassen kan er een decorator gemaakt worden die extra functionaliteit toevoegt. (Holzner, 2006) Een mogelijke decorator kan de gegevens die door de writer naar de processor wordt geschreven onderscheppen en in een logboek wegschrijven. Hetzelfde is mogelijk voor een reader. Dit kan handig zijn wanneer een nieuwe kennisbanksysteem is ontwikkeld en er onverwacht gedrag optreedt. Er kan gekeken worden naar de in- en uitvoer van het kennisbanksysteem om te weten te komen waar het onverwacht gedrag vandaan komt. Het is mogelijk dat er een fout zit in de implementatie van het kennisbanksysteem, de reader of de writer. Door de gegevens te onderscheppen met een decorator moet geen van de drie voorgaande onderdelen gewijzigd worden en kunnen de gegevens toch verkregen worden.
5.3 Solution Het `Solution' onderdeel bestaat uit twee klassen. De eerste klasse is de
Solution-klasse.
Dit is een abstracte klasse die alle methodes de nieert die nodig zijn voor de implementatie van het `Solution'-onderdeel (zie sectie 4.2.4 voor de de nitie van het solutiononderdeel). Een aantal triviale methodes zijn al geïmplementeerd in deze basisklasse, zoals de methodes om listeners toe te voegen en te verwijderen.
Door gebruik te maken van deze
abstracte klasse is het gemakkelijk om achteraf, door middel van het `Decorator Pattern', fuctionaliteit toe te voegen zonder dat de gebruiker van de klasse hier iets van merkt. Om de
Solution
klasse te kunnen gebruiken moet er eerst een concrete subklasse ge-
maakt worden die alle abstracte methodes van de solution klasse implementeert.
SolutionImpl-klasse voorzien, die door Solution-klasse kan geïnstantieerd worden.
een dergelijke implementerende statische methode in de
In deze klasse wordt de toestand bijgehouden door middel van
Er is
middel van een
SolutionState-objecten.
Er is slechts één huidige toestand in de Solution klasse maar deze wordt voorgesteld door twee
SolutionState-objecten.
Eén van die objecten is de
inputState welke de toestand
voorstelt die als gevolg van acties door de gebruiker tot stand is gekomen. De andere is de
solutionState
die de volledige toestand bevat. Dit zijn de acties die door de gebruiker
uitgevoerd zijn en de reacties van het kennisbanksysteem op die acties. Oorspronkelijk werd enkel deze laatste toestand bijgehouden, wat wilde zeggen dat deze twee klassen zeer eenvoudig waren. Ze zorgden er enkel voor dat de kennisbankabstractiemodule netjes bij elkaar werd gehouden en delegeerden de handelingen naar de klassen die daarvoor dienen. Bij tests bleek dit niet te werken zoals gewenst was. Wanneer er
Implementatie
39
geprobeerd werd om een gekend symbool terug te verwijderen, werd dit elke keer terug toegevoegd door het kennisbanksysteem. Dit is logisch aangezien het kennisbanksysteem op zoek gaat naar een toestand met zo weinig mogelijk vrijheden. Om dit probleem te verduidelijken volgt er een voorbeeld uit de etscon guratiedemo (sectie 1.2.2). Wanneer een dames ets met framegrootte 190 - 200 cm aangeduid is, zal enkel nog het etstype Grandma bike en het kadertype Centurion Boulevard tot een geldige oplossing leiden. Als de gebruiker wenste de keuze van een dames ets terug ongedaan te maken, zou deze door het kennisbanksysteem terug toegevoegd worden. Volgens de regels van de etscon guratiekennisbank kan er immers enkel een dames ets gemaakt worden van het etstype Grandma bike en het kadertype Centurion Boulevard met framegrootte 190 - 200 cm. Het is dus noodzakelijk om de beperkingen die afkomstig zijn van de applicatie afzonderlijk bij te houden en de toestand van de oplossing hierop te baseren. Het kennisbanksysteem mag dus geen beperkingen toevoegen aan de toestand afkomstig van de gebruiker maar omgekeerd moet die toestand wel invloed hebben op de beperkingen die zullen toegevoegd worden door het kennisbanksysteem.
5.3.1 changeState De
changeState-methode
van de
SolutionImpl-klasse
zal, op vraag van de applicatie,
de toestand van de oplossing voor het con guratieprobleem aanpassen met de gewenste
SymbolChange-objecten.
Daarna wordt het kennisbanksysteem uitgevoerd om die te
controleren en hierop verdere wijzigingen toe te passen.
Dit principe werd reeds kort
toegelicht in sectie 4.2.2.
changeState-algoritme in zijn werk gaat. Eerst worden twee kopies gemaakt van de permanente inputState. De permanente states zijn de toestandsobjecten die worden bijgehouden door de Solution-klasse als oplossingstoeIn guur 5.1 wordt weergegeven hoe het
stand. De twee kopies worden gebruikt om wijzigingen op toe te passen in de loop van het
changeState-algoritme.
Als er iets misgaat, zoals een con ict dat optreedt, worden de
kopies weggegooid en is er niets veranderd. Het voordeel is ook dat de hele operatie wordt gezien als één stap. Elke wijziging op de tijdelijke toestanden wordt uitgevoerd in een aparte stap. Dit is niet anders mogelijk omdat dit in sequentie moet gebeuren. Door achteraf alle wijzigingen in die toestand op te vragen en in één keer uit te voeren op de permantente toestanden, zullen deze als één stap worden gezien. De applicatie wordt ook van deze wijzigingen op de hoogte gebracht. Merk op dat in de loop van het algoritme de voor de gegeven
inputState.
solutionState niet de juiste oplossing bevat
Dit wordt door het uitvoeren van het kennisbanksysteem
opgelost. De gedetailleerde werking van het algoritme zal uitgelegd worden aan de hand van de implementatiecode.
inputState
solutionState
Stap
+ dupliceren
+ dupliceren
inputState
solutionState
Stap Change Applicatie
inputState
State listener
solutionState
Stap Change
inputState
Kennisbanksysteem
solutionState
Change
Change
inputState
solutionState
Figuur 5.1: Implementatie van het veranderen van de toestand in een stap.
Implementatie 1 2 3 4 5 6
41
public void changeState ( C o l l e c t i o n <SymbolChange> symbolChanges ) throws ParserException , IOException , ReaderException , WriterException { onProcessingStarted ( ) ; try { StateProcessor processor = getFactory ( ) . getStateProcessor ( ) ; Codefragment 5.1: De changeState methode, deel 1.
changeState-methode is gegeven in codefragmethode zal de ProcessingListeners verwittigen dat
De declaratie en het eerste deel van de ment 5.1. De eerste regel van de een bewerking gestart is.
Hierna wordt een try blok geopend waarin de rest van de
methode staat. In het nally blok dat hierop volgt worden de
ProcessingListeners ver-
wittigen dat een bewerking geëindigd is. Indien dit niet zo wordt gedaan, zouden bij het optreden van een
Exception
de
ProcessingListeners
niet verwittigd worden. De API
garandeert dat de start en stop verwittigingen in paren voorkomen, dus is het try nally blok noodzakelijk. In het try blok wordt eerst een de
ProcessingFactory.
StateProcessor object opgevraagd uit
Deze processor dient om het kennisbanksysteem op te roepen en
wordt later in deze methode gebruikt.
S o l u t i o n S t a t e newInputState = this . i n p u t S t a t e . c r e a t e D e r i v e d S t a t e ( Arrays . a s L i s t ( symbolChange ) , S o l u t i o n S t a t e . INFINITE_SIZE ) ; S o l u t i o n S t a t e n e w S o l u t i o n S t a t e = this . s o l u t i o n S t a t e ; for ( SymbolChange change : symbolChanges ) { i f ( change . g e t A c t i o n ( ) . e q u a l s ( ChangeAction . Remove ) ) { n e w S o l u t i o n S t a t e = this . i n p u t S t a t e ; } } newSolutionState = newSolutionState . createDerivedState ( symbolChanges , S o l u t i o n S t a t e . INFINITE_SIZE ) ; newSolutionState = newSolutionState . createDerivedState ( Arrays . a s L i s t ( symbolChange ) , S o l u t i o n S t a t e . INFINITE_SIZE ) ;
1 2 3 4 5 6 7 8 9 10 11 12
Codefragment 5.2: De changeState methode, deel 2.
In codefragment 5.2 wordt eerst een tijdelijk stateobject aangemaakt dat gebaseerd is
inputState. Dit tijdelijk object wordt dan aangepast met de wijziging die als argument met de changeState methode werd meegegeven. Als laatste wordt een tijdelijk
op de
stateobject aangemaakt dat afhankelijk van de actie van de wijzigingen gebaseerd is op ofwel de
inputState
ofwel de
solutionState.
Zoals eerder vermeld wil het kennisbanksysteem een gekend symbool niet meer verwijde-
inputState als Remove-actie voorkomt
Remove-actie
ren. Daarom wordt er vertrokken van de
er een
in de wijzigingen. Zelfs als er geen
in de wijzigingen kan ook ver-
trokken worden van de
voorkomt
inputState, alhoewel het kennisbanksysteem dan meer werk moet
verrichten. Gezien het kennisbanksysteem de beperkende factor is op vlak van performantie, moet deze zo weinig mogelijk onnodig belast worden. Om die reden wordt uitsluitend bij een
Remove-actie
de
inputState
gebruikt.
wordt aangepast met de gevraagde wijziging.
Ook het tijdelijk
solutionState-object
try { u p d a t e S o l u t i o n S t a t e ( newSolutionState , p r o c e s s o r , i t e r a t i o n P o l i c y ) ; } catch ( C o n f l i c t i n g S t a t e E x c e p t i o n e ) { onConflictFound ( e ) ; C o n f l i c t S t a t u s s t a t u s = null ; i f ( g e t C o n f l i c t H a n d l e r ( ) != null ) { s t a t u s = g e t C o n f l i c t H a n d l e r ( ) . h a n d l e C o n f l i c t ( this , newInputState , newSolutionState , p r o c e s s o r ) ; onConflictHandled ( status ) ; } i f ( s t a t u s != C o n f l i c t S t a t u s . Resolved ) { return ; } }
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Codefragment 5.3: De changeState methode, deel 3.
In codefragment 5.3 wordt met de methode
updateSolutionState het kennisbanksysteem
opgeroepen. Dit is een interne private methode van deze klasse. Het eerste argument van deze methode is het tijdelijke state object dat zal aangepast worden met de wijzigingen die het kennisbanksysteem aangeeft. Het tweede argument is de processor die in codefragment 5.2 is aangemaakt en waarmee het kennisbanksysteem zal opgeroepen worden. Als laatste argument wordt er een
iterationPolicy
doorgegeven aan de methode.
Approx, het programma dat gebruikt wordt als kennisbanksysteem, zal nieuwe beperkingen zoeken en de nodige wijzigingen hiervoor teruggeven wanneer het opgeroepen wordt. Helaas worden niet altijd alle beperkingen gevonden. De reden hiervoor is dat het kennisbanksysteem anders nog trager zou zijn. Approx kan door middel van een parameter ingesteld worden om langer of minder lang te zoeken, hoewel dit bij een aantal tests weinig invloed leek te hebben op het resultaat. De
updateSolutionState-methode
zal herhaaldelijk het kennisbanksysteem oproepen,
zolang er bij de voorgaande oproep nieuwe wijzigingen worden teruggegeven. Om niet in een oneindige lus te belanden en om een compromis te vinden tussen uitvoeringstijd en nauwkeurigheid wordt de
IterationPolicy-interface
gebruikt.
Een implementatie van
deze interface kan bepalen of de lus moet afgebroken worden, zelfs als niet alle wijzigingen zijn gevonden. Bij het zoeken naar beperkingen door het kennisbanksysteem kunnen con icten optre-
ConflictingStateException gooien. opgevangen en zal een ConflictHandler
den. Indien dit gebeurt, zal de StateProcessor een Zoals te zien is in codefragment 5.3 wordt dit
opgeroepen worden als die beschikbaar is. Als de con icthandler niet in staat is om het con ict op te lossen of als er geen handler voorhanden is, wordt de bewerking afgebroken en zal de methode terugkeren. In dit geval zal de toestand van het solutionobject niet gewijzigd zijn, aangezien de wijzigingen op tijdelijke
SolutionState-objecten uitgevoerd
werden. Indien er geen con ict is opgetreden of het con ict is afgehandeld, zal de methode verder uitgevoerd worden in codefragment 5.4. De code in dit fragment zal de wijzigingen permanent maken door ze op te slaan in de twee stateobjecten van de
Solution-klasse.
Implementatie
43
int s t e p s = newInputState . countUndoSteps ( ) ; newInputState . undoChangeSteps ( s t e p s ) ; C o l l e c t i o n <SymbolChange> inputChanges = newInputState . redoChangeSteps ( s t e p s ) ; this . i n p u t S t a t e . createChangeStep ( true ) ; this . s o l u t i o n S t a t e . createChangeStep ( true ) ; for ( SymbolChange change : inputChanges ) { this . i n p u t S t a t e . changeState ( change ) ; this . s o l u t i o n S t a t e . changeState ( change ) ; } C o l l e c t i o n <SymbolChange> s o l u t i o n C h a n g e s = S o l u t i o n S t a t e . getChangeList ( this . s o l u t i o n S t a t e , n e w S o l u t i o n S t a t e ) ; for ( SymbolChange change : s o l u t i o n C h a n g e s ) { this . s o l u t i o n S t a t e . changeState ( change ) ; }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Codefragment 5.4: De changeState methode, deel 4.
Eerst wordt er bepaald welke aanpassingen er moeten gebeuren aan de wordt gedaan door eerst in de tijdelijke
inputState
inputState.
Dit
alle wijzigingen ongedaan te maken.
Daarna worden die wijzigingen opnieuw gemaakt. Het resultaat van die methode is een verzameling van wijzigingen die gebeurd zijn bij het opnieuw uitvoeren. Na het verzamelen van de wijzigingen wordt er eerst voor gezorgd dat in beide permanente states met een nieuwe, lege stap gewerkt wordt. de nieuwe stap van de permanente
Hierna wordt de verzameling van wijzigingen op
inputState en solutionState toegepast. Vervolgens solutionState. Dit
wordt het verschil opgevraagd tussen de permanente en de tijdelijke
geeft als resultaat een verzameling van wijzigingen die nodig zijn om de toestand van de permanente state identiek te maken aan de toestand van de tijdelijke state. wijzigingen worden ook toegepast op de permanente 1 2 3 4 5 6 7 8 9 10 11
}
Deze
solutionState.
i f ( this . i n p u t S t a t e . hasCurrentChanges ( ) | | this . s o l u t i o n S t a t e . hasCurrentChanges ( ) ) { this . s o l u t i o n S t a t e . createChangeStep ( f a l s e ) ; this . i n p u t S t a t e . createChangeStep ( f a l s e ) ; } n o t i f y S t a t e L i s t e n e r s ( inputChanges , solutionChanges , f a l s e ) ; } finally { onProcessingEnded ( ) ; } return ;
Codefragment 5.5: De changeState methode, deel 5.
Het laatste stuk code van de
changeState
methode is die van codefragment 5.5. In het
eerste stuk van dit fragment wordt getest of de permanente toestand gewijzigd is. dit het geval is, wordt in beide stateobjecten een nieuwe stap aangemaakt. Door
Als
false
als argument door te geven, gebeurt dit zelfs als de huidige stap van het stateobject geen wijzigingen bevat.
De reden hiervoor is het gesynchroniseerd houden van beide
stateobjecten. Indien geen van beide stateobjecten een wijziging bevat dan zal voor geen
van beiden een stap gemaakt worden. Wanneer beide stateobjecten wel wijzigingen bevat dan zal dit hetzelfde eect hebben als wanneer de methode met
true
opgeroepen zou
worden. Het is dus enkel wanneer één van de twee state objecten geen wijzigingen bevat dat voor dit object een lege stap zal toegevoegd worden aan de undostack. Als dit niet zou gebeuren dan zou bij het ongedaan maken één van de twee state objecten één stap achter lopen op de andere. Dit zou tot ongewenst gedrag van de API leiden. Het laatste statement in het try blok zal zorgen dat eerst de wijzigingen van de invoer en dan die van het kennisbanksysteem doorgegeven worden aan de statelisteners. Daarna volgt het nally blok dat de processinglisteners op de hoogte zal brengen van het einde van de bewerking. De methode zal hierna eindigen.
5.3.2 undoChangeSteps De tweede methode die ik zal bespreken is de
undoChangeSteps methode.
Deze methode
zal één of meerdere stappen ongedaan maken. Oorspronkelijk was deze methode zeer eenvoudig. Deze delegeerde de oproep door naar de
solutionState
en verwittigde de applicatie hiervan.
Door het probleem dat zich voordeed bij het verwijderen van een keuze (begin sectie 5.3), moest een tweede toestand, de
inputState,
bijgehouden worden. Hierdoor is ook deze
methode een stuk complexer geworden. De details van het algoritme worden toegelicht aan de hand van implementatiecode. 1 2 3 4 5 6 7 8 9 10 11 12 13 14
public void undoChangeSteps ( int numberOfSteps ) { i f ( numberOfSteps > countUndoSteps ( ) ) { throw new I l l e g a l A r g u m e n t E x c e p t i o n ( " numberOfSteps " ) ; } onProcessingStarted ( ) ; try { for ( int i = numberOfSteps ; i > 0 ; −− i ) { S o l u t i o n S t a t e i n p u t S t a t e = this . i n p u t S t a t e . c r e a t e D e r i v e d S t a t e ( null , S o l u t i o n S t a t e . INFINITE_SIZE ) ; S o l u t i o n S t a t e s o l u t i o n S t a t e = this . s o l u t i o n S t a t e . c r e a t e D e r i v e d S t a t e ( null , S o l u t i o n S t a t e . INFINITE_SIZE ) ; C o l l e c t i o n <SymbolChange> inputChanges = this . i n p u t S t a t e . undoChangeSteps ( 1 ) ; this . s o l u t i o n S t a t e . undoChangeSteps ( 1 ) ; Codefragment 5.6: De undoChangeSteps methode, deel 1.
Het eerste deel van de methode is terug te vinden in codefragment 5.6. Zoals te zien is in dit fragment zal er een lus uitgevoerd worden die voor elke stap die ongedaan gemaakt moet worden een aantal bewerkingen zal uitvoeren.
inputState en de solutionState gemaakt. Daarna wordt bij beide toestanden één stap ongedaan gemaakt, waarvan enkel bij de inputState de wijzigingen worden bijgehouden. Deze wijzigingen worden aan het einde van de methode gebruikt om de StateListeners te verwittigen.
Om een stap ongedaan te maken wordt eerst een tijdelijke kopie van de
Implementatie C o l l e c t i o n <SymbolChange> r e v e r s e I n p u t C h a n g e s = S o l u t i o n S t a t e . getChangeList ( this . i n p u t S t a t e , i n p u t S t a t e ) ; S o l u t i o n S t a t e n e w S o l u t i o n S t a t e = this . s o l u t i o n S t a t e . c r e a t e D e r i v e d S t a t e ( reverseInputChanges , S o l u t i o n S t a t e . INFINITE_SIZE ) ; C o l l e c t i o n <SymbolChange> s o l u t i o n C h a n g e s = S o l u t i o n S t a t e . getChangeList ( s o l u t i o n S t a t e , n e w S o l u t i o n S t a t e ) ; n o t i f y S t a t e L i s t e n e r s ( inputChanges , solutionChanges , true ) ;
1 2 3 4 5 6 7 8 9 10 11 12 13
45
}
} } finally { onProcessingEnded ( ) ; }
Codefragment 5.7: De undoChangeSteps methode, deel 2.
In het tweede deel van de methode, dat te zien is in codefragment 5.7, wordt er gezocht naar de wijzigingen die gebeurd zijn. Hiervoor wordt eerst het verschil berekend van de permanente en de tijdelijke
inputState.
Let op, de permanente toestand is het eerste argument, dus zijn dit de wijzigingen om van de permanente toestand over te gaan naar de tijdelijke. Dit lijkt misschien vreemd aangezien de tijdelijke toestand een kopie is van de permanente toestand wanneer deze nog niet aangepast was en de permanente toestand nu reeds aangepast is. Deze omgekeerde wijzigingen, vandaar de naam
reverseInputChanges,
zijn nodig om de wijzigingen die
door het kennisbanksysteem gemaakt zijn te kunnen extraheren. Bij de volgende operatie wordt er een tweede tijdelijke solutionstate gemaakt. Deze toestand wordt aangepast met de reverseInputChanges welke eigenlijk de voorwaartse wijzi-
inputChanges reverseInputChanges de
gingen zijn. Dit is immers de undomethode. De
zijn dus de wijzigingen
om de stap ongedaan te maken en de
wijzigingen om de stap
opnieuw uit te voeren. De
getChangeList-methode
over te gaan.
geeft de wijzigingen om van de eerste naar de tweede state
Daarom wordt de tweede toestand eerst geplaatst en de eerste toestand
tweedes geplaatst bij de
getChangeList-methode
zodat de wijzigingen verkregen wor-
inputChanges en solutionChanges worden uiteindelijk gebruikt om de StateListeners te verwittigen. Door true als laatste argument van de notifyStateListeners methode te gebruiken, worden eerst de solutionChanges gemeld en dan pas de inputChanges. De wijzigingen den om achteruit te gaan en dus de stap ongedaan te maken.
De
worden dus als het ware achterstevoren afgespeeld. Gelijkaardig als in de
changeState
methode worden ook hier de
ProcessingListeners
verwittigd dat de bewerking beëindigd is.
5.4 Solution in een andere Thread Zoals in sectie 4.2.5 vermeld is, is het noodzakelijk om het kennisbanksysteem in een andere thread te laten uitvoeren dan die van de gebruikersinterface. Deze functionaliteit
SolutionImpl-klasse zou deze klasse te groot en complex maken. Daarom werd de ThreadedSolution-klasse ontwikkeld die deze funtionaliteit toevoegt aan een Solution-object door gebruik te maken het `Decorator Pattern'. Zo is het mogelijk om ook andere implementaties te gebruiken in samenwerking met de ThreadedSolutioninbouwen in de
klasse. Deze klasse maakt gebruik van een die de
ExecutorService-interface
ExecutorService
klasse. Dat is één van de klassen
implementeert en komt uit de JRE-bibliotheek. Door
gebruik te maken van deze klasse wordt het eenvoudig om taken asynchroon uit te voeren. Belangrijk om te weten bij de
SolutionImpl-klasse is dat deze niet voorzien is om tegelijk
in verschillende threads gebruikt te worden. Als dit wel gebeurt dan is het mogelijk dat deze klasse in een inconsistente toestand gebracht wordt. Daarom zal de klasse het
Solution-object
ThreadedSolution-
dat hierin gebruikt wordt aangespreken via één thread. Alle
bewerkingen zullen in een wachtrij geplaatst worden en die thread zal één voor één de bewerkingen uitvoeren die in de wachtrij staan. De
ExecutorService-interface maakt het mogelijk om te wachten op het resultaat van een ThreadedSolution-klasse gebruik
opdracht. Hier wordt door sommige methodes van de
van gemaakt. Dit zijn de methodes die belangrijke resultaten teruggeven en bedoeld zijn om synchroon uit te voeren.
5.5 Con gurator De
Configurator klasse zorgt ervoor dat wanneer een object wordt aangeboden, hiervoor ConfiguratorImpl subklas-
een geschikte adapter wordt teruggegeven. Bijkomend kan de
se aan de hand van de naam van een toolkit deze inladen vanop het bestandssysteem. De naam wordt gekozen door de ontwikkelaar die de
Toolkit-interface
implementeert. Deze
naam moet duidelijk maken voor welke GUI-toolkit deze implementatie gemaakt is en wat de implementatie doet. De standaard implementatie die meegeleverd is met de API draagt bijvoorbeeld de naam Swing - default.
5.5.1 ndBestForObject 1 2 3 4 5 6 7 8
public AdapterFactory f i n d B e s t F o r O b j e c t ( Object o b j e c t , S t r i n g v a r i a n t ) { AdapterFactory f a c t o r y = null ; i f ( o b j e c t != null ) { for ( Class c u r r e n t = o b j e c t . g e t C l a s s ( ) ; c u r r e n t != null && f a c t o r y == null ; current = current . getSuperclass ()) { f a c t o r y = this . s e l e c t ( c u r r e n t , v a r i a n t ) ; } Codefragment 5.8: De ndBestForObject methode, deel 1.
In codefragment 5.8 staat de interne functie van de
Configurator-klasse die de opzoeking
zal doen. Wanneer een object wordt aangeboden aan de con gurator, zal deze de klasse
Implementatie
47 findBestForObject-methode zal voor deze klassen een AdapterFactory zoeken. Hiervoor zal
van het object opvragen. van zijn bovenliggende
De
klasse of één de lus in het
codefragment zorgen. In de lus wordt net zolang gezocht tot een factory gevonden is of de klasse geen bovenliggende klasse meer heeft, wat wil zeggen dat op dat moment de waarde van
Object
current de
klasse is. In het beste geval bestaat er een factory voor de klasse van het object.
Dit heeft als gevolg dat de volledige functionaliteit van dat object zal aangesproken kunnen worden. Bij het vinden van een factory voor een bovenliggende klasse van het object zal enkel de functionaliteit aangesproken kunnen worden die in die bovenliggende klasse gede nieerd is. 1 2 3 4 5 6 7 8 9 10 11 12 13
}
i f ( f a c t o r y == null ) { for ( Class c l a z z : this . g e t S u p p o r t e d C l a s s e s ( ) ) { i f ( c l a z z . i s I n s t a n c e ( o b j e c t ) && c l a z z . i s I n t e r f a c e ( ) ) { f a c t o r y = this . s e l e c t ( c l a z z , v a r i a n t ) ; break ; } } } } else { f a c t o r y = this . s e l e c t ( null , v a r i a n t ) ; } return f a c t o r y ;
Codefragment 5.9: De ndBestForObject methode, deel 2.
Indien er voor geen enkele bovenliggende klasse van het object een factory gevonden is, zal de
factory variabele na deze lus nog altijd de waarde null bevatten.
Er wordt in dit
geval in codefragment 5.9 verder gezocht naar een interface die geïmplementeerd wordt door het object. In deze lus worden alle door de toolkit ondersteunde klassen overlopen. Als er een interface wordt gevonden, dan wordt de factory opgehaald. Hierbij maakt het niet uit welke interface er wordt gevonden aangezien niet kan afgeleid worden welke de meeste functionaliteit zal kunnen aanbieden. De enige gegevens die kunnen opgevraagd worden over de interface zijn het aantal methodes, de namen van de methodes en de argumenten van de methodes die gedeclareerd zijn in die interface. Deze gegevens zijn geen aanduiding voor het al dan niet nuttig zijn van de interface. Er wordt verondersteld dat in de toolkit enkel die interfaces ondersteund worden waarvoor een nuttige factory kan afgeleverd worden.
5.5.2 ndToolkit De methode die gebruikt wordt om een toolkit te zoeken, met een naam die overeenkomt met het gegeven patroon, is de
findToolkit-methode.
Deze methode zal op zoek
gaan naar implementaties voor de SPI op de locaties die vermeld zijn in de `ClassPath' omgevingsvariabele. De locaties in de classpath omgevingsvariabele zijn directories waar klassebestanden staan met de implementatie van Java-klassen.
1 2 3 4 5 6 7 8
private s t a t i c T o o l k i t f i n d T o o l k i t ( Pattern toolkitName , S t r i n g l i b P a t h ) throws IOException , NoSuchToolkitException { T o o l k i t t o o l k i t = null ; S e r v i c e L o a d e r l o a d e r ; ClassLoader parent = Thread . currentThread ( ) . getContextClassLoader ( ) ; URLClassLoader u r l L o a d e r = new URLClassLoader ( g e t J a r s ( parent , l i b P a t h ) , parent ) ; l o a d e r = S e r v i c e L o a d e r . l o a d ( T o o l k i t . class , u r l L o a d e r ) ; Codefragment 5.10: De ndToolkit methode, deel 1.
Codefragment 5.10 beschrijft het eerste deel van de
findToolkit-methode.
Er wordt
ClassLoader opgevraagd die de klassen kan laden uit de JRE-bibliotheek. Deze als ouder toegevoegd aan een nieuwe URLClassLoader, waardoor niet alleen klas-
eerst een wordt
sen geladen kunnen worden vanuit de gegeven URL's, maar ook vanuit de locaties die gekend zijn door de ouder. De
getJars-methode,
die hierna zal besproken worden, zal
de URL's ophalen van alle JAR's die in de directory staan, aangegeven door het argument. Als laatste in dit fragment wordt een implementaties gaat zoeken van de 1 2 3 4 5 6 7 8 9 10 11 12 13 14
}
libPath
ServiceLoader opgevraagd die naar alle
Toolkit-interface.
for ( T o o l k i t tk : l o a d e r ) { try { i f ( toolkitName . matcher ( tk . getName ( ) ) . matches ( ) ) { t o o l k i t = tk ; break ; } } catch ( Throwable t ) { } } i f ( t o o l k i t == null ) { throw new NoSuchToolkitException ( toolkitName . t o S t r i n g ( ) ) ; } return t o o l k i t ;
Codefragment 5.11: De ndToolkit methode, deel 2.
Alle gevonden toolkit-implementaties worden overlopen in codefragment 5.11. Voor elke implementatie wordt de naam vergeleken met het patroon dat als eerste argument is meegegeven aan de
findToolkit-methode.
Indien een implementatie met overeenkomstige
naam wordt gevonden, wordt deze als resultaat van de methode teruggegeven. In het andere geval wordt een
NoSuchToolkitException
gegooid die aangeeft dat er geen toolkit
kan gevonden worden dat voldoet aan het patroon.
5.5.3 getJars De
getJars-methode
classpath.
(codefragment 5.12) zal de URL's van alle JAR's zoeken in de
Eerst wordt de directory opgevraagd die aangegeven is met het
libPath-
Implementatie 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
49
private s t a t i c URL [ ] g e t J a r s ( ClassLoader context , S t r i n g l i b P a t h ) throws IOException { ArrayList j a r s = new ArrayList ( ) ; for (URL u r l : C o l l e c t i o n s . l i s t ( c o n t e x t . g e t R e s o u r c e s ( l i b P a t h ) ) ) { try { i f ( u r l . toURI ( ) . getScheme ( ) . e q u a l s ( " j a r " ) ) { continue ; // u n a b l e t o l o a d JARs f r o m w i t h i n JARs . } F i l e f i l e = new F i l e ( u r l . toURI ( ) ) ; if ( f i l e . isDirectory ()) { File [ ] children = f i l e . l i s t F i l e s (); for ( F i l e f : c h i l d r e n ) { i f ( f . getName ( ) . endsWith ( " . j a r " ) ) j a r s . add ( f . toURI ( ) . toURL ( ) ) ; } } } catch ( URISyntaxException e ) { } } return j a r s . toArray ( new URL[ j a r s . s i z e ( ) ] ) ; } Codefragment 5.12: De getJars methode.
argument. Dit gebeurt in de context van de gegeven
ClassLoader door de getResources-
methode. Het is noodzakelijk dat
libPath
een relatief pad opgeeft omdat
getResources
enkel
hiermee overweg kan. Opzoekingen gebeuren altijd relatief ten opzichte van de bestaande classpath. Door de API te verpakken in een JAR kan opgegeven worden dat de directory waarin de JAR zich bevindt tot de classpath behoort. De URL's die teruggegeven worden door de directories in de
libPath-directory.
getResources-methode zijn alle bestanden en getJars-methode worden
In het volgende stuk van de
deze bestanden ge lterd zodat enkel de JAR-bestanden overgehouden worden. Als eerste ltering wordt er gekeken of het gebruikte protocol van de URL gelijk is aan het `jar'protocol. Dit protocol wordt gebruikt om een bestand aan te geven dat zich in een JAR Bijvoorbeeld jar://http://server.domein.org/directory_van_archief/ archief.jar!/directory_in_archief/bestandsnaam is de URL van een bestand met padnaam /directory_in_archief/bestandsnaam dat zich in een JAR bevindt. Deze JAR is zelf terug te vinden op de locatie http://server.domein.org/directory_van_ archief/archief.jar. (Oracle, 2010d) bevindt.
Er wordt verondersteld dat het bestand dat voorgesteld wordt door de URL een JAR is. Als dit JAR-bestand genest is in een ander JAR-bestand, zal de inhoud van het binnenste JAR-bestand niet geladen kunnen worden. De
URIStreamHandler implementatie voor het
`jar'-protocol is immers niet in staat om geneste JAR's te verwerken. Bestanden in een JAR worden daarom overgeslagen. Vervolgens wordt de URL omgezet in een
File-object.
Van dit object kan opgevraagd
worden of het een bestand of een directory is. We zijn enkel geïnteresseerd in directories,
meerbepaald de directory die opgegeven is door
libPath.
Daarom wordt er in deze
directory op zoek gegaan naar alle bestanden in het JAR-formaat. extentie.
Vandaar de `.jar'-
Als we zo een bestand hebben gevonden, wordt deze toegevoegd aan de lijst
van archieven. De lijst van archieven bevat alle JAR's die mogelijk een `Service Provider' zijn.
5.6 Besluit In dit hoofdstuk zijn de implementaties van een aantal belangrijke methodes en klassen besproken. Dit wil niet zeggen dat de andere onderdelen van de API minder belangrijk zijn.
Moest dit wel het geval zijn, dan werden die beter weggelaten.
De reden dat
een implementatie werd toegelicht in dit hoofdstuk is dat deze naar mijn mening niet vanzelfsprekend is en een verklaring nodig heeft. Andere onderdelen van de API zouden voldoende begrepen moeten kunnen worden door de broncode te bekijken. Ik heb de broncode met zorg uitgewerkt zodat deze zo goed als mogelijk te begrijpen is. Er is daarom aandacht besteed aan de structuur van methodes en de naamgeving van variabelen en methodes. De variabelen en methodes hebben allemaal zinvolle namen gekregen, volgens de conventies van de Java taal, waardoor deze zelfverklarend zijn. Op plaatsen waar niet altijd duidelijk is wat de code doet, werd ook documentatie aan de code toegevoegd. Bijkomend is er voor elke publieke methode Javadoc documentatie voorzien zodat de functie van deze methodes kan opgezocht worden.
Hoofdstuk 6 Gebruik en uitbreiding van de API In dit hoofdstuk zal aan de hand van een aantal voorbeelden duidelijk gemaakt worden op welke manier de API gebruikt kan worden. De beschreven voorbeelden zullen niet alle mogelijkheden van de API dekken. Het is eerder de bedoeling om een idee te geven van de mogelijkheden, zodat men meteen aan de slag kan met de API. Voor de veeleisende gebruikers bestaat de mogelijkheid om de API aan te passen. Ook hiervan zullen een aantal voorbeelden gegeven worden. De voorbeelden die gegeven worden, zijn gebaseerd op de etscon guratiedemo (sectie 1.2.2.
Oorspronkelijk maakte deze applicatie gebruik van de con gNowbibliotheek
(sectie 1.2.1).
De applicatie is aangepast zodat deze nu gebruik maakt van de in deze
masterproef ontwikkelde API. De etscon guratiedemo laat zien hoe een ets zou kunnen gecon gureerd worden. Deze applicatie zou gebruikt kunnen worden door een etswinkel om een ets samen te stellen. Eerst zal er in sectie 6.1 een voorbeeld gegeven worden hoe een applicatie kan aangepast worden aan een lokale taal.
Daarna worden de verschillende methodes beschreven en
verklaard om de API te gebruiken. De eerste en de tweede methode werkt met behulp van annotaties. Hiermee kan een statische GUI automatisch worden gekoppeld aan IDP. In de eerste methode in sectie 6.2.1 wordt de parser op een snelle en gemakkelijke manier met standaardinstellingen aangemaakt. De tweede methode in sectie 6.2.2 zal de programmeur zelf toelaten de parser te con gureren met de functionaliteit die hij kiest. Om een dynamische GUI te koppelen wordt er in sectie 6.3 een derde methode uitgelegd. Als laatste manier om de API te gebruiken, wordt er in sectie 6.4 aangegeven hoe het model en de toestand van de kennisbank rechtstreeks kan opgevraagd en aangepast worden. Het laatste deel van het hoofdstuk zal toelichten hoe een eigen toolkit kan gemaakt worden. Met een dergelijke toolkit kunnen nieuwe GUI componenten ondersteund worden of nieuwe funtionaliteit aangeboden worden voor reeds ondersteunde componenten.
6.1 Translator De
Translator-interface
is een onderdeel uit de API waarmee de symbolen uit de ken-
nisbank een zinvolle naam en beschrijving kunnen krijgen.
In sectie 2.3 is aangegeven
dat de standaardmanier om in Java vertalingen aan te bieden gebruik maakt van resource bundles. Daarom is er in de API een implementatie van de
ResourceBundle-object de ResourceBundleTranslator genoemd.
zien die aan de hand van een implementatie is
1 2 3 4 5 6 7 8 9 10 11 12
SelGen . Male . name = SelGen . Male . d e s c = SelGen . Female . name SelGen . Female . d e s c
Heren Kader voor een h e r e n f i e t s . = Dames = Kader voor een d a m e s f i e t s .
S e l H e i . name = SelHei . desc = S e l H e i . C150160 . name S e l H e i . C160170 . name S e l H e i . C170180 . name S e l H e i . C180190 . name S e l H e i . C190200 . name
Grootte De g r o o t t e van het kader . = 150 cm − 160 cm = 160 cm − 170 cm = 170 cm − 180 cm = 180 cm − 190 cm = 190 cm − 200 cm
Translator-interface
symbolen zal vertalen.
voorDeze
Codefragment 6.1: Deel van een properties bestand met de vertaling van symbolen en tuples.
Om gebruik te maken van de
ResourceBundleTranslator
klasse is een `properties'-
bestand nodig met de vertalingen van de symbolen. In codefragment 6.1 staat een knipsel van een properties bestand. In dit properties bestand staan de vertalingen voor de tuples van twee symbolen en ook voor het tweede symbool zelf.
De syntax van een vertaling
bestaat uit een label en een waarde. De waarde is de vertaling en het label is het symbool waarvoor de vertaling gebruikt moet worden. Het label bestaat voor een symbool uit de naam van het symbool, gevolgd door name voor de vertaling van de naam van het symbool en desc voor de vertaling van een beschrijving van het symbool. Deze twee waarden worden gescheiden door een punt `.'. Voor het label van een tuple wordt tussen de naam van het symbool en name of desc de naam van het tuple toegevoegd. Indien het tuple uit meerdere waarden bestaat zullen deze waarden gescheiden zijn door een underscore `_'. Dit is het geval voor predikaten met meerdere parameters. De symbolen en tuples waarvoor geen vertaling is gegeven zullen door de translator niet vertaald worden. De naam en beschrijving van deze symbolen en tuples zullen gelijk zijn aan de symbolische naam. Dit is de naam van het symbool zoals het vermeld is in het IDP-model. Indien enkel de naam vertaald is, zal de beschrijving dezelfde waarde krijgen als de naam. De naam van het propertiesbestand moet voldoen aan een aantal regels om herkend te worden door de ResourceBundle.(Oracle, 2010b) Het begin van de bestandsnaam is een pre x die dient om onderscheid te maken tussen resource bundles van verschillende pakketten. Deze naam wordt gevolgd door een underscore `_', de lettercode van de te gebruiken taal en de `.properties'-extentie.
Om een standaardvertaling te maken voor
Gebruik en uitbreiding van de API
53
talen die niet ondersteund worden, kan een properties bestand gemaakt worden waarbij in de naam de underscore en de lettercode is weggelaten. Voor het voorbeeld is de `bike'-pre x.
De bestandsnaam voor de standaardvertaling is
dan bike.properties en voor Nederlandse vertaling is dit bike_nl.properties. Om deze bestanden te kunnen laden, moeten ze voor de
ClassLoader beschikbaar zijn als resource.
6.2 Annotatie parser De gemakkelijkste manier om de API te gebruiken is met behulp van annotaties. Componenten die men wil koppelen met de kennisbank kunnen dan met één of meerdere annotaties geannoteerd worden. Het enige wat dan nog moet gebeuren is de con guratie van de verschillende modules van de API.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
public c l a s s BikeScreenAnnotated extends javax . swing . JFrame { @IDPAdapterAction ( " complete " ) private javax . swing . JButton jButtonCheck ; @IDPAdapterAction ( " r e s e t " ) private javax . swing . JButton jButtonReset ; @IDPPredicate ( " SelGen " ) @IDPTuple ( "Male" ) @IDPAdapterVariant ( " c o l o r " ) public javax . swing . JCheckBox @IDPPredicate ( " SelGen " ) @IDPTuple ( " Female " ) @IDPAdapterVariant ( " c o l o r " ) public javax . swing . JCheckBox @IDPPredicate ( " S e l H e i " ) private javax . swing . JLabel
33
@IDPPredicate ( " S e l H e i " ) @IDPTuple ( "C150160" ) private javax . swing . JCheckBox @IDPPredicate ( " S e l H e i " ) @IDPTuple ( "C160170" ) private javax . swing . JCheckBox @IDPPredicate ( " S e l H e i " ) @IDPTuple ( "C170180" ) private javax . swing . JCheckBox @IDPPredicate ( " S e l H e i " ) @IDPTuple ( "C180190" ) private javax . swing . JCheckBox @IDPPredicate ( " S e l H e i " ) @IDPTuple ( "C190200" ) private javax . swing . JCheckBox
34
/
19 20 21 22 23 24 25 26 27 28 29 30 31 32
∗
...
jCheckBox12 ;
jCheckBox13 ; jLabel13 ;
jCheckBox14 ; jCheckBox15 ; jCheckBox16 ; jCheckBox17 ; jCheckBox18 ;
∗/ Codefragment 6.2: Declaratie van geannoteerde velden.
Het voorbeeld in codefragment 6.2 laat de verschillende annotaties zien die gebruikt kunnen worden. De IDPPredicate-annotatie wordt toegevoegd aan een component die bij een predikaat hoort. Dit kan een label zijn waarvan in het codefragment een voorbeeld is gegeven. Mogelijk is dit ook een component, zoals een keuzelijst, die toelaat om een selectie te maken uit alle tuples van een predikaat. Met de
IDPPredicate-annotatie
wordt opge-
geven voor welk symbool de component geannoteerd is. De optionele `inverted'-parameter kan gebruikt worden om aan te geven dat de component voor een negatieve selectie gebruikt moet worden zodat bij het selecteren een van een De
AddPositive-operatie.
IDPTuple-annotatie
AddNegative-operatie
gebeurt in plaats
zal aan een component worden toegevoegd die de controle heeft
over één tuple van een predikaat. Om aan te geven over welk predikaat het gaat, moet de component ook met IDPPredicate geannoteerd zijn. In het codefragment is deze annota-
jCheckBox12-keuzevakje. Wanneer dat keuzevakje geselecteerd wordt, zal een AddPositive actie voor het SelGen.Male-tuple worden uitgevoerd. Bij het deselecteren wordt een Remove-actie uitgevoerd. tie onder andere toegevoegd aan het
De
IDPAdapterAction-annotatie laat toe om een actie toe te voegen aan een component. jButtonReset-knop is deze annotatie toegevoegd met als parameter de waarde
Bij de
reset. Dit wil zeggen dat de resetactie aan de knop gekoppeld zal worden. De ondersteunde acties voor de
reset
IDPAdapterAction-annotatie
zijn:
Zet de staat van alle symbolen terug naar hun beginwaarden. De undo- en redostack wordt leeggemaakt.
clear
Zet de staat van alle symbolen terug naar hun beginwaarden. Deze bewerking voegt een stap toe aan de undo- en redostack.
undo
Maak een stap ongedaan.
redo
Voer een stap opnieuw uit.
complete
Kijk na of het probleem opgelost is.
De wijzigingen die hierbij gebeuren,
worden als een stap toegevoegd aan de undo- en redostack. Deze acties kunnen aan om het even welke adapter gekoppeld worden. Dit wil niet zeggen dat de actie ooit zal uitgevoerd worden aangezien niet elke adapter het commando geeft om een actie uit te voeren. De laatste annotatie,
IDPAdapterVariant,
kan ook voor elke adapter gebruikt worden.
Deze geeft aan welke versie van de adapter gebruikt moet worden. Wanneer de gewenste versie niet beschikbaar is, zal de standaardversie gebruikt worden.
Dit is hetzelfde als
wanneer deze annotatie niet zou gebruikt zijn. Let op, de annotaties voegen enkel metadata toe aan de velden van een klasse.
Deze
velden dienen daarom in dit geval nog verwerkt te worden door een parser. De parser zal door middel van re ectie de waarden van de velden ophalen. Daarom is het belangrijk dat deze velden reeds geïnitialiseerd zijn en de juiste component bevatten op het moment dat de parser deze gaat verwerken.
Gebruik en uitbreiding van de API
55
6.2.1 Snelle methode Deze manier van werken is bedoeld om snel een standaardcon guratie aan de praat te krijgen. Hiervoor moet een toegeving gedaan worden ten opzichte van de exibiliteit. Het is namelijk niet mogelijk om de implementaties van een aantal klassen zelf te bepalen. De parser zal voor deze klassen een standaardimplementatie uitkiezen. Meestal zijn deze implementaties wel de juiste of voldoen ze ten minste aan de vereisten van de programmeur. In vele gevallen kan dus gekozen worden voor deze methode. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
System . s e t P r o p e r t y ( GidLApproxFactory .GIDL_MODULE_PROPERTY, " t o o l s /GidL" ) ; System . s e t P r o p e r t y ( GidLApproxFactory .APPROX_MODULE_PROPERTY, " t o o l s /Approx" ) ; try { Parser parser = Parser . configureParser ( new GidLApproxFactory ( " f i l e s / b i k e .mx" ) , Pattern . compile ( " Swing . ∗ " ) , " f i l e s / b i k e " , new AnnotationParser . Factory ( ) ) ; p a r s e r . p a r s e ( this ) ; parser . getSolution ( ) . reset ( ) ; } catch ( Exception e ) { e . printStackTrace ( ) ; System . e x i t ( − 1); } Codefragment 6.3: Code voor de koppeling van geannoteerde velden, de snelle manier.
Hoe deze methode in zijn werk gaat is beschreven in codefragment 6.3. Het valt meteen op dat er niet veel code nodig is om de kennisbank te koppelen met de geannoteerde velden. Het eerste wat hier gebeurt, is het instellen van twee omgevingsvariabelen. De variabele GidLApproxFactory.GIDL_MODULE_PROPERTY bepaalt op welk relatief pad GidL kan gevonden worden en GidLApproxFactory.APPROX_MODULE_PROPERTY bepaalt het relatief pad voor Approx. Deze twee opdrachten hebben niets met het parsen zelf te maken. Ze moeten ingesteld worden zodat de API weet waar het kennisbanksysteem zich bevindt. Op regel 6 wordt een parser aangemaakt. De eerste parameter is de
processingFactory
die gebruikt zal worden om het kennisbanksysteem op te roepen. Hieraan wordt meegegeven waar het modelbestand van de kennisbank zich bevindt op het bestandssysteem. De tweede parameter die gebruikt wordt om de parser aan te maken is het patroon dat moet overeenkomen met de naam van de toolkit. Op basis hiervan zal een toolkit door de
Configurator uitgekozen worden.
De derde parameter geeft de pre x aan van de resour-
ce bundle die gebruikt zal worden om de symbolen te vertalen. De laatste parameter is een factory die het parserobject zal aanmaken. In dit geval zal er een parser aangemaakt worden voor het parsen van annotaties. Als de parser is aangemaakt, wordt de parsemethode opgeroepen met als parameter het
Solution-object opgevraagd en Indien er ergens in het try blok een Exception optreedt zal deze afgedrukt
object dat moet verwerkt worden. Als laatste wordt het geïnitialiseerd.
worden en de applicatie zal eindigen.
6.2.2 Flexibele methode 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
P r o c e s s i n g E x c e p t i o n H a n d l e r h a n d l e r = null ; S o l u t i o n s o l u t i o n = null ; S t r i n g m o d e l F i l e = " f i l e s / b i k e .mx" ; C o n f i g u r a t o r c o n f = null ; System . s e t P r o p e r t y ( GidLApproxFactory .GIDL_MODULE_PROPERTY, " t o o l s /GidL" ) ; System . s e t P r o p e r t y ( GidLApproxFactory .APPROX_MODULE_PROPERTY, " t o o l s /Approx" ) ; try { c o n f = C o n f i g u r a t o r . newConfigurator ( Pattern . compile ( " Swing . ∗ " ) ) ; P r o c e s s i n g F a c t o r y p r o c e s s i n g F a c t o r y = new GidLApproxFactory ( modelFile ) ; Model model = p r o c e s s i n g F a c t o r y . getModelReader ( ) . read ( ) ; s o l u t i o n = S o l u t i o n . newSolution ( model , p r o c e s s i n g F a c t o r y , 0 , new MaxCountIterationPolicy ( 0 ) ) ; s o l u t i o n . setCompletionHandler ( new DefaultCompletionHandler ( ChangeAction . AddNegative ) ) ; h a n d l e r = c o n f . g e t P r o c e s s i n g E x c e p t i o n H a n d l e r ( null , null ) ; s o l u t i o n = new ThreadedSolution ( s o l u t i o n , h a n d l e r ) ; ResourceBundleTranslator t r a n s l a t o r = null ; try { t r a n s l a t o r = new ResourceBundleTranslator ( " f i l e s / b i k e " ) ; } catch ( M i s s i n gR e s o u r ce E x c e p ti o n e ) { e . printStackTrace ( ) ; } conf . setTranslator ( t r a n s l a t o r ) ; P a r s e r p a r s e r = new AnnotationParser ( s o l u t i o n , conf , t r a n s l a t o r ) ; p a r s e r . p a r s e ( this ) ; solution . reset (); } catch ( Exception e ) { e . printStackTrace ( ) ; System . e x i t ( − 1); } Codefragment 6.4: Code voor de koppeling van geannoteerde velden met meer exibiliteit.
Om volledige controle te hebben over de manier waarop de API gaat functioneren, kunnen de drie parameters die gebruikt worden bij het instantiëren van de parser handmatig gecon gureerd en samengesteld worden.
De parameters die bedoeld worden, zijn een
Solution-, Configurator- en Translator-object.
De werkwijze om deze te con gureren
is beschreven in codefragment 6.4.
Configurator-object en het ProcessingFactory-object aangemaakt worden. Uit het ProcessingFactory-object kan de ModelReader gehaald worden en dan het Model gelezen worden. Als het Model gekend is, kan hiermee een Solution-object gemaakt worden, waarbij ook de ProcessingFactory nodig is. Deze twee objecten worden als parameters doorgegeven aan de methode die een Solution-object zal aanmaken. De Eerst moet het
twee parameters die daar nog achter komen bepalen de maximum grootte van de undostack en het maximum aantal extra iteraties die mogen uitgevoerd worden om de resultaten te ver jnen bij het oproepen van het kennisbanksysteem. Deze parameters zijn niet ver-
Gebruik en uitbreiding van de API
57
eist en bij het weglaten worden hiervoor standaardwaarden ingesteld. De grootte van de undostack mag dan oneindig groot worden en het maximum aantal extra iteraties zal tien bedragen. In dit voorbeeld zijn de waarden
0
en
new MaxCountIterationPolicy(0)
ge-
bruikt. Dit wil zeggen dat er geen undo- en redostack beschikbaar zal zijn en dat er geen extra iteraties toegelaten worden. Deze instellingen zorgen er voor dat de demo vanuit het standpunt van de gebruiker dezelfde (beperkte) functionaliteit heeft als de originele demo die gebruik maakte van con gNow (sectie 1.2.1). Op het
Solution-object
wordt de standaard
CompletionHandler
ingesteld.
Deze zal
alle niet gekende tuples toevoegen aan de negatieve lijst. Vervolgens wordt de standaard
ProcessingExceptionHandler opgevraagd. Op de volgende regel wordt deze gebruikt bij het aanmaken van het ThreadedSolution-object. Dit object voegt de functionaliteit aan Solution toe om in een andere thread uitgevoerd te worden. Daarna wordt een poging ondenomen om een te stellen.
Translator-object
aan te maken en in
Indien dit niet lukt, zal een foutboodschap afgedrukt worden en zullen de
symbolen niet vertaald worden. Vervolgens wordt het parserobject aangemaakt met de net aangemaakte en gecon gureerde objecten. Het resterende gedeelte van de con guratie is identiek aan dat van de snelle methode (sectie 6.2.2). Het is duidelijk dat deze methode meer werk vraagt van de programmeur. Daartegenover staat wel dat die alle instellingen zelf kan kiezen. Zo zijn er een aantal onderdelen in de con guratie die de programmeur mogelijk anders zou willen instellen. De implementatie van de
Configurator
(lijn 10 in het codefragment) zou men bijvoor-
beeld kunnen vervangen door één waarvoor een toolkit gekozen wordt op basis van de ondersteunde klassen in plaats van de naam van de toolkit.
Solution-object gebruikt wordt voor het Solution-object en IterationPolicy.
Op lijn 14 zou ook een andere implementatie voor het
kunnen
worden.
ook de
In de snelle methode (sectie 6.2.2)
standaardwaarden gebruikt voor de undostack Er kan een andere
ProcessingExceptionHandler opgevraagd worden voor het Threaded-
Solution-object. Het is ook mogelijk om de API niet in een andere thread uit te voeren door geen ThreadedSolution-object aan te maken maar door het eerste Solution-object rechtstreeks te gebuiken. Tenslotte kan een andere implementatie van de den. Dit zou bijvoorbeeld een
Translator
Translator-interface
aangemaakt wor-
kunnen zijn die gebruik maakt van Google
Translate of Babel sh.
6.3 Con gurator Er zijn applicaties waarvoor annotaties niet gebruikt kunnen worden. Wanneer de gebruikersinterface bijvoorbeeld dynamisch gegenereerd wordt, is het niet mogelijk om geannoteerde velden van een object te parsen aangezien die velden niet bestaan of nog niet naar een object verwijzen.
Als dit het geval is, kan de
worden om adapters aan te maken.
Configurator
rechtstreeks gebruikt
Om de con guratie van de API te vergemakkelijken, kan er wel gebruik gemaakt worden van een
Parser.
Hoe deze gemakkelijk aangemaakt wordt, is beschreven in sectie 6.2.1.
Hierbij zal de parsemethode van de parser niet veel nut hebben omdat er niets is om te verwerken. Wel kunnen via de getters van de parser de nodige objecten opgevraagd worden zoals de
Configurator-
en
Solution-objecten.
Het is natuurlijk mogelijk om beide methodes te combineren.
De parser kan gebruikt
worden om het statische gedeelte van de GUI te koppelen en de con gurator kan gebruikt worden om het dynamische gedeelte te con gureren.
Solution solution = parser . getSolution ( ) ; Configurator conf = parser . getConfigurator ( ) ; Model model = s o l u t i o n . getModel ( ) ; attachAdapter ( conf , jButtonReset , s o l u t i o n , null , parser . getAction ( " r e s e t " ) ) ; attachAdapter ( conf , btnUndo , s o l u t i o n , "undo" , p a r s e r . g e t A c t i o n ( "undo" ) ) ; symbol = model . g e t P r e d i c a t e ( " SelGen " ) ; t u p l e = StateTuple . g e t S t a t e T u p l e ( symbol , "Male" ) ; attachAdapter ( conf , jCheckBox12 , s o l u t i o n , t u p l e ) ; attachAdapter ( conf , jComboBox8 , s o l u t i o n , model . g e t P r e d i c a t e ( " S elFra " ) ) ;
1 2 3 4 5 6 7 8 9 10 11 12
Codefragment 6.5: Koppeling van componenten aan de kennisbank met behulp van Adapters.
In codefragment 6.5 is voor een aantal componenten een koppelingsactie uitgewerkt. Met behulp van de verschillende
attachAdapter-methodes,
die de programmeur zelf moet
schrijven, worden de componenten aan de kennisbank gekoppeld. de
jButtonReset-
en
btnUndo-knop
In dit voorbeeld is
gekoppeld met de reset- en de undoactie.
undoknop wordt er als vierde parameter ook undo doorgegeven aan de
Bij de
attachAdapter-
methode. Deze parameter is de variant van de adapter. De undovariant van de buttonadapter zal een visuele aanduiding geven als er geen stap meer ongedaan gemaakt kan worden door de knop uit te schakelen. Als de standaardvariant voor deze knop gebruikt wordt, dan kan de gebruiker op de knop blijven klikken zelfs al is er geen stap meer om terug te gaan. Er bestaat ook een redovariant die de knop zal uitschakelen als er geen stap meer is om opnieuw uit te voeren. Verder in het codefragment wordt er ook nog een keuzevakje aan een tuple gekoppeld en een keuzelijst aan een symbool. Voor deze twee moet er ook een
attachAdapter-methode
aangemaakt worden. De
attachAdapter-methodes
worden beschreven in codefragment 6.6. Er zijn vier zulke
methodes aangemaakt in dit voorbeeld. De methode op lijn 1 koppelt knoppen aan acties. Een andere methode op lijn 22 koppelt keuzevakjes aan tuples. Nog een andere methode op lijn 15 koppelt keuzelijsten aan symbolen. De twee laatstvernoemde methodes roepen, wanneer ze een adapter hebben aangemaakt, de methode op lijn 29 op die de adapter verder zal con gureren.
Gebruik en uitbreiding van de API
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
59
private s t a t i c void attachAdapter ( C o n f i g u r a t o r conf , JButton o b j e c t , S o l u t i o n s o l u t i o n , S t r i n g v a r i a n t , Runnable a c t i o n ) { Pattern p a t t e r n = null ; i f ( v a r i a n t != null ) { p a t t e r n = Pattern . compile ( v a r i a n t , Pattern . LITERAL ) ; } Adapter adapter = c o n f . getAdapter ( o b j e c t , pattern , s o l u t i o n ) ; i f ( adapter != null ) { adapter . s e t A d a p t e r L i s t e n e r ( new D e f a u l t A d a p t e r L i s t e n e r ( null , a c t i o n ) ) ; s o l u t i o n . a d d P r o g r e s s L i s t e n e r ( adapter ) ; } } private s t a t i c void attachAdapter ( C o n f i g u r a t o r conf , JComboBox o b j e c t , S o l u t i o n s , S t a t e f u l S y m b o l symbol ) { Adapter adapter = c o n f . getAdapter ( o b j e c t , null , s , symbol , f a l s e ) ; attachAdapter ( adapter , symbol . getName ( ) , s , c o n f . g e t P r o c e s s i n g E x c e p t i o n H a n d l e r ( null , null ) ) ; } private s t a t i c void attachAdapter ( C o n f i g u r a t o r conf , JCheckBox o b j e c t , S o l u t i o n s , StateTuple t u p l e ) { Adapter adapter = c o n f . getAdapter ( o b j e c t , null , s , t uple , f a l s e ) ; attachAdapter ( adapter , t u p l e . getValue ( ) . g e t ( 0 ) . getName ( ) , s , c o n f . g e t P r o c e s s i n g E x c e p t i o n H a n d l e r ( null , null ) ) ; } private s t a t i c void attachAdapter ( Adapter adapter , S t r i n g name , Solution s , ProcessingExceptionHandler handler ) { i f ( adapter != null ) { s . a d d S t a t e L i s t e n e r ( adapter ) ; s . a d d P r o g r e s s L i s t e n e r ( adapter ) ; adapter . s e t A d a p t e r L i s t e n e r ( new D e f a u l t A d a p t e r L i s t e n e r ( h a n d l e r ) ) ; } } Codefragment 6.6: De attachAdapter-methodes voor het koppelen van de adapters aan de ken-
nisbank.
6.4 Kennisbankabstractie Om directe controle uit te oefenen op de kennisbank kan via de kennisbankabstractiemodule gewerkt worden. De applicatie kan dan bijvoorbeeld bij initialisatie een aantal waarden automatisch instellen. In een etswinkel staat bijvoorbeeld een elektronische meetlat aan de con guratiecomputer. bij het starten van de etscon guratiesoftware zal dan automatisch de juiste grootte van het frame gekozen worden aan de hand van de grootte van de persoon die aan de computer heeft plaatsgenomen.
1 2 3 4 5 6 7
/
∗
initialisatie
van
de
parser
∗/
Solution solution = parser . getSolution ( ) ; S t a t e f u l S y m b o l symbol = s o l u t i o n . getModel ( ) . getPredicate (" SelHei " ) ; StateTuple t u p l e = StateTuple . g e t S t a t e T u p l e ( symbol , "C180190" ) ; s o l u t i o n . changeState ( new SymbolChange ( ChangeAction . AddPositive , t u p l e ) ) ; Codefragment 6.7: Directe wijziging van de staat van de kennisbank.
De gebruikte code zou er dan ongeveer uitzien zoals beschreven in codefragment 6.7. Het symbool dat gewijzigd moet worden (SelHei), wordt eerst opgehaald uit het
Solution-
SymbolChange-object aan te maken. changeState-methode van het Solution-object kan de juiste frame-
object. Dan haalt men het juiste tuple op om een Door middel van de
grootte geselecteerd worden.
6.5 Interfaces en abstracte klassen implementeren Het is al een aantal keren aangehaald dat voor sommige onderdelen van de API nieuwe implementaties gemaakt kunnen worden.
Het zijn die onderdelen die de API exibel
en uitbreidbaar maken. In totaal bestaat de API uit 11 pakketten met daarin samen 76 klassen. Hiervan zijn er 45 klassen die dienen voor de standaardimplementatie van de API. De andere 31 klassen dienen om nieuwe funtionaliteit te kunnen toevoegen. Hiervan zijn er 24 interfaces en 7 abstracte klassen om te implementeren. Deze klassen en interfaces zijn ook gebruikt bij de implementatie van sommige van de gewone klassen. Parser, BasicAdapter, BasicAdapterFactory, BasicToolkit, Selector, Solution en SolutionState zijn de abstracte klassen. De interfaces zijn:
ParserFactory, Adapter, AdapterFactory, AdapterListener, Proces-
singExceptionHandler, ProcessingExceptionHandlerFactory, Toolkit, Translator, CompletionHandler, SymbolCompletionHandler, CompletionListener, Con ictHandler, Con ictListener, ProcessingListener, ProgressListener, StateListener, IterationPolicy, IterationSession, ProcessingFactory, ModelReader, StateReader, StateWriter, StateProcessor en SymbolState.
Gebruik en uitbreiding van de API
61
Opmerking: Wanneer een implementatie voor een interface of abstracte klasse wordt ge-
maakt, is het belangrijk dat in deze implementatie het contract van de geïmplementeerde interface of klasse nageleefd wordt. De API vertrouwd namelijk op dit contract om correct te kunnen functioneren. Indien niet aan dit contract wordt voldaan, kan er geen garantie gegeven worden over het al dan niet correct werken van de API. Bijvoorbeeld: Het contract van de
tie van de
ConflictHandler-interface vereist dat de implementa-
handleConflict-methode een con ict probeert op te lossen.
Het slagen of falen
van het oplossen van een con ict moet aangegeven worden door de juiste status terug te geven. Als dit verkeerdelijk wordt gedaan, zal de API niet naar behoren functioneren. Voor informatie over de klassen en hun contracten kan gebruik gemaakt worden van de Javadoc documentatie van de API.
6.6 Maken van een Toolkit Om ondersteuning te bieden voor andere GUI toolkits of om andere implementaties te maken voor een toolkit kan een `Service Provider' aangemaakt worden. Deze zal inhaken op de Toolkit SPI. (sectie 2.4) Als voorbeeld zal er een kleurenvariant gemaakt worden van de adapter die zal koppelen met een object van de
javax.swing.JCheckBox
klasse. De kleurenvariant zal het keuze-
vakje rood kleuren als een keuze niet beschikbaar is, en groen kleuren als de keuze verplicht is. Hiervoor zal ook een implementatie van de
Toolkit-interface
aangemaakt worden die
enkel die adapter zal bevatten. Ook zal er beschreven worden hoe, met behulp van de Eclipse IDE, van deze klassen een JAR gemaakt kan worden die juist gecon gureerd is voor het gebruik met de API.
6.6.1 Adapter klasse Een adapter kan bevestigd worden aan een bepaald object. Hierdoor zal die adapter ervoor zorgen dat het object de toestand weergeeft van het gewenste symbool of een tuple van dat symbool. Bijkomend zal het object de toestand van het symbool kunnen aanpassen. De adapterimplementatie die hier zal toegelicht worden, is speci ek ontwikkeld om bevestigd te worden op een object van de
javax.swing.JCheckBox
klasse. Deze adapter zal
dus code bevatten om met dat soort van objecten samen te werken. De adapterklasse in dit voorbeeld draagt de naam ColorJCheckboxAdapter en is een subklasse van de
BasicAdapter-klasse.
De
BasicAdapter-klasse implementeert de Adapter-
interface en zorgt voor hulpmethodes. Hierdoor zal een deel van het werk niet voor elke implementatie opnieuw moeten gebeuren. De klasse heeft twee velden gede nieerd, zoals te zien is in codefragment 6.8. Het eerste veld houdt het tuple bij waarvoor het keuzevakje de staat moet weergeven en aanpassen. Het tweede veld is een vlag die aangeeft dat een bewerking aan de gang is. Dit veld wordt gebruikt om aan te geven dat geen nieuwe wijzigingen mogen doorgestuurd worden naar de kennisbank.
1 2 3
public c l a s s ColorJCheckboxAdapter extends BasicAdapter<JCheckBox> { private StateTuple tuple ; private boolean processing ;
4
public ColorJCheckboxAdapter ( JCheckBox checkbox , S o l u t i o n s o l u t i o n , StateTuple tup le , boolean i n v e r t e d ) { super ( checkbox , s o l u t i o n , t u p l e . getSymbol ( ) , i n v e r t e d ) ; this . t u p l e = t u p l e ; g e t S u b j e c t ( ) . a d d I t e m L i s t e n e r ( new CheckBoxListener ( ) ) ; }
5 6 7 8 9 10
Codefragment 6.8: Klassede nitie, velden en constructor van de ColorJCheckboxAdapter.
Hierna volgt de constructor. De constructor zal de adapter initialiseren als deze wordt aangemaakt. De constructor van de superklasse wordt ook opgeroepen om ook de velden van die te initialiseren. Er wordt een
CheckBoxListener
toegevoegd die events van het
keuzevakje zal opvangen wanneer deze geselecteerd en gedeselecteerd wordt. De
CheckBoxListener-klasse
is een interne klasse. Deze wordt weergegeven in codefrag-
ment 6.9. Doordat dit een interne klasse is, hoort elke instantie van deze klasse bij een instantie van de omsluitende klasse. Dit heeft als voordeel dat vanuit deze klasse toegang mogelijk is tot de methodes en velden van de omsluitende klasse. De
itemStateChanged-methode van deze klasse wordt opgeroepen wanneer het keuzevakje
wordt geselecteerd of gedeselecteerd, ongeacht of dit door de gebruiker of door de applicatie gebeurt. Dit is lastig omdat de wijzigingen die deze adapter zelf maakt teruggekoppeld zullen worden.
Er moet dus een mechanisme voorzien worden om deze terugkoppeling
te doorbreken. Hiervoor dient de processing vlag. Wanneer een bewerking wordt gestart zal deze vlag waar worden en als de bewerking eindigt zal de vlag terug onwaar worden. Het wijzigen van de processing vlag gebeurt verderop in de omsluitende klasse. Op deze manier zal een wijziging niet teruggekoppeld worden tijdens een bewerking. Een tweede vlag die gebruikt wordt, is de de
itemStateChanged-methode
forwardChanges-vlag.
De eerste keer dat
wordt opgeroepen zal de wijziging nog niet doorgegeven
worden. In plaats hiervan wordt de wijziging opgeslagen en wordt de omgekeerde wijzing uitgevoerd op het keuzevakje. Die wijziging zal deze methode terug oproepen, maar dit keer zullen de wijzigingen wel doorgegeven worden aan het kennisbanksysteem.
Door
de eerste keer het keuzevakje terug op de vorige waarde te zetten, zal die pas de juiste waarde krijgen wanneer de wijziging door het kennisbanksysteem goedgekeurd wordt. Indien dit niet zou gebeuren, dan moet, als achteraf blijkt dat de wijziging niet aanvaard is, de waarde van het keuzevakje teruggezet worden. Dit zou de implementatie complexer maken. Als aangegeven is dat deze adapter een inverterende werking heeft, zal een actie uitgevoerd worden. In het andere geval wordt een
addNegative-
addPositive-actie
uitgevoerd.
Een inverterende werking betekent dat wanneer het keuzevakje aangevinkt wordt, de keuze niet bij de oplossing mag horen. In het normale geval moet een geselecteerde keuze bij de oplossing horen.
Gebruik en uitbreiding van de API
1 2 3
private c l a s s CheckBoxListener implements I t e m L i s t e n e r { private boolean forwardChanges = f a l s e ; private boolean inputSelected = false ;
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
}
@Override public void itemStateChanged ( ItemEvent e ) { if (! processing ) { i f ( ! forwardChanges ) { forwardChanges = true ; i n p u t S e l e c t e d = e . getStateChange ( ) == ItemEvent .SELECTED; getSubject ( ) . setSelected ( ! inputSelected ) ; } else { forwardChanges = f a l s e ; if ( inputSelected ) { if ( isInverted ()) { changeState ( ChangeAction . AddNegative , ColorJCheckboxAdapter . this . t u p l e ) ; } else { changeState ( ChangeAction . AddPositive , ColorJCheckboxAdapter . this . t u p l e ) ; } } else { changeState ( ChangeAction . Remove , ColorJCheckboxAdapter . this . t u p l e ) ; } } } }
Codefragment 6.9: De geneste CheckBoxListener klasse.
63
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
@Override public void onStateChange ( S o l u t i o n s o l u t i o n , f i n a l SymbolChange change , ChangeSource s o u r c e ) { i f ( this . t u p l e . e q u a l s ( change . getValue ( ) ) ) { S w i n g U t i l i t i e s . i n v o k e L a t e r ( new Runnable ( ) { @Override public void run ( ) { JCheckBox box = g e t S u b j e c t ( ) ; switch ( change . g e t A c t i o n ( ) ) { case Remove : box . s e t S e l e c t e d ( f a l s e ) ; box . setForeground ( Color .BLACK) ; break ; case AddPositive : box . s e t S e l e c t e d ( ! i s I n v e r t e d ( ) ) ; box . setForeground ( Color .GREEN) ; break ; case AddNegative : box . s e t S e l e c t e d ( i s I n v e r t e d ( ) ) ; box . setForeground ( Color .RED) ; break ; } } }); } } Codefragment 6.10: De onStateChange methode.
Gebruik en uitbreiding van de API De
onStateChange-methode
65
in codefragment 6.10 wordt opgeroepen wanneer de staat
van het symbool gewijzigd wordt waarvoor deze adapter geregistreerd is.
Dit wil niet
noodzakelijk zeggen dat deze wijziging te maken heeft met het tuple van deze adapter. Er zal enkel gereageerd worden als het tuple overeenkomt met het tuple van deze adapter. Indien dit het geval is, betekent dit dat de wijziging aanvaard is, of dat door de wijziging van een ander tuple dit tuple ook aangepast moet worden. Afhankelijk van de wijziging zal de checkbox al dan niet geselecteerd worden en een andere kleur krijgen.
SwingUtilities.invokeLater-methode. Dit lijkt op het eerste zicht misschien niet nodig, maar de onStateChange-methode wordt opgeroepen door de Solution-klasse. Zoals eerder vermeld in dit hoofdstuk in codefragDeze bewerkingen worden opgeroepen met de
ment 6.4, is het mogelijk dat deze klasse wordt uitgevoerd in een andere thread dan de `Swing GUI'. De speci catie van Swing vermeld dat de `Swing GUI' enkel in de daarvoor voorziene thread mag gebruikt worden. (Oracle, 2010a) Om te voorkomen dat de applicatie zich onverwacht gaat gedragen worden de wijzigingen met behulp van invokeLater in de `Swing thread' uitgevoerd. Dit zal overal in deze adapterklasse zo gebeuren.
@Override public void o n P r o c e s s i n g S t a r t e d ( S o l u t i o n s o l u t i o n ) { S w i n g U t i l i t i e s . i n v o k e L a t e r ( new Runnable ( ) { @Override public void run ( ) { p r o c e s s i n g = true ; g e t S u b j e c t ( ) . setEnabled ( f a l s e ) ; } }); }
1 2 3 4 5 6 7 8 9 10 11
@Override public void onProcessingEnded ( S o l u t i o n s o l u t i o n ) { S w i n g U t i l i t i e s . i n v o k e L a t e r ( new Runnable ( ) { @Override public void run ( ) { processing = false ; g e t S u b j e c t ( ) . setEnabled ( true ) ; } }); }
12 13 14 15 16 17 18 19 20 21
Codefragment 6.11: De onProcessingStarted en onProcessingEnded methode.
onProcessingStarted- en onProcessingEnded-methodes het Solution-object wanneer de verwerking begint en eindigt. De
worden opgeroepen door Hier (codefragment 6.11)
wordt de processing vlag aangepast zodat wijzigingen tijdens de verwerking niet worden teruggekoppeld. Om te voorkomen dat de gebruiker tijdens de verwerking het keuzevakje kan aanklikken, wordt dit bij het begin uitgeschakeld en weer ingeschakeld op het einde. De
setName- en setDescription-methodes in codefragment 6.12 worden gebruikt om aan
de gebruiker aan te geven voor welk tuple het keuzevakje gebruikt wordt.
@Override public void setName ( f i n a l S t r i n g name ) { S w i n g U t i l i t i e s . i n v o k e L a t e r ( new Runnable ( ) { @Override public void run ( ) { g e t S u b j e c t ( ) . setText ( name ) ; g e t S u b j e c t ( ) . setName ( name ) ; } }); }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
}
@Override public void s e t D e s c r i p t i o n ( f i n a l S t r i n g d e s c r i p t i o n ) { S w i n g U t i l i t i e s . i n v o k e L a t e r ( new Runnable ( ) { @Override public void run ( ) { g e t S u b j e c t ( ) . setToolTipText ( d e s c r i p t i o n ) ; } }); }
Codefragment 6.12: De setName en setDescription methode.
6.6.2 Factory klasse Om adapters aan te kunnen maken vanuit de applicatie, moet er een factory voorzien worden. Deze factory zal de klasse van de objecten waarvoor adapters gemaakt kunnen worden aangeven. Ook wordt de variant aangegeven van de adapters die geproduceerd worden. De factory moet uiteraard ook minstens één van de drie
getAdapter-methodes
implementeren om de adapters daadwerkelijk aan te maken. In codefragment 6.13 zijn deze methodes geïmplementeerd. wordt is de
javax.swing.JCheckBox
De klasse die ondersteund
klasse. color is de aangeboden variant aangezien
de keuzevakjes gekleurd zullen worden. Bij het aanmaken van de adapter wordt eerst nagekeken worden dat het doorgegeven object wel van het
JCheckBox-type
is.
Indien dit niet zou gebeuren, zou de cast een
Exception kunnen gooien wanneer een verkeerd object wordt doorgegeven.
Hierna wordt
de adapter aangemaakt en de translator gebruikt om de naam en beschrijving van het keuzevakje in te stellen. Uiteindelijk zal een nieuwe adapter teruggegeven worden en kan de API hiermee verder werken.
6.6.3 Toolkit klasse De
Toolkit-interface is de providerklasse van de Toolkit-SPI. Voor elke `Service Provider' Toolkit-interface imple-
die aangemaakt wordt moet een klasse gemaakt worden die de
Gebruik en uitbreiding van de API 1
public s t a t i c c l a s s ColorCheckBoxFactory extends BasicAdapterFactory {
2
@Override public Class g e t S u p p o r t e d C l a s s ( ) { return JCheckBox . c l a s s ; }
3 4 5 6 7
@Override public ColorJCheckboxAdapter newAdapter ( Object adapted , S o l u t i o n s o l u t i o n , StateTuple tup le , boolean i n v e r t e d ) { ColorJCheckboxAdapter adapter = null ; i f ( adapted instanceof JCheckBox ) { adapter = new ColorJCheckboxAdapter ( ( JCheckBox ) adapted , s o l u t i o n , tuple , i n v e r t e d ) ; adapter . setName ( g e t T r a n s l a t o r ( ) . getName ( t u p l e ) ) ; adapter . s e t D e s c r i p t i o n ( g e t T r a n s l a t o r ( ) . g e t D e s c r i p t i o n ( t u p l e ) ) ; } return adapter ; }
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
67
}
@Override public S t r i n g getVariantName ( ) { return " c o l o r " ; }
Codefragment 6.13: De ColorCheckBoxFactory klasse.
menteerd. Hierin worden alle aangeboden
Adapter-klassen geregistreerd door middel van
hun factory. In codefragment 6.14 is zo een toolkitklasse geïmplementeerd. van de
BasicToolkit-klasse.
de factories te registreren. worden.
De
BasicToolkit-klasse
Deze is een subklasse
voorziet alle functionaliteit om
Hierdoor kan een toolkitklasse zeer snel geïmplementeerd
Het enige wat de maker van een `Service Provider' moet doen is de
implementatie een naam geven en de factories met behulp van de
Toolkit-
putFactory-methode
registreren. Belangrijk is wel dat deze klasse een constructor heeft zonder argumenten. Anders zou de Service Loader deze klasse niet kunnen laden.
6.6.4 JAR samenstellen Het laatste wat moet gebeuren om zelf een Toolkit Service Provider te maken, is deze inpakken in een Java Archief. Om de ColorToolkit klasse bekend te maken als implementatie van de toolkitproviderklasse wordt het bestand dat weergegeven is in codefragment 6.15 aangemaakt. Dit bestand moet in het Java Archief in de /META-INF/services directory geplaatst worden. Als die directory in de Eclipse IDE in de root van het project wordt aangemaakt, zal deze ook aangemaakt worden in het Java Archief. Om Het project te exporteren kan de Export Wizard gebruikt worden. Deze wizard zal aan de hand van vijf screenshots worden verklaard.
1
package t o o l k i t s . swing . c o l o r ;
2 3 /∗ i m p o r t s ∗/ 4 5
public c l a s s C o l o r T o o l k i t extends B a s i c T o o l k i t {
6
public C o l o r T o o l k i t ( ) { putFactory ( new ColorCheckBoxFactory ( ) ) ; }
7 8 9 10 11 12 13 14 15
}
@Override public S t r i n g getName ( ) { return " Swing − c o l o r " ; }
Codefragment 6.14: De ColorToolkit klasse.
1
t o o l k i t s . swing . c o l o r . C o l o r T o o l k i t Codefragment 6.15: Het jidp.con guration.spi.Toolkit bestand.
Figuur 6.1: Oproepen van de Export Wizard.
Gebruik en uitbreiding van de API
69
In guur 6.1 wordt de Export Wizard opgeroepen. Hiervoor wordt met de rechter muisknop op het project geklikt en daarna Export... geselecteerd. De export wizard zal zich openen. Als de export wizard geopend is, zal guur 6.2(a) zichtbaar zijn. Om een Java Archief te maken, moet in de Java categorie het element JAR le geselecteerd worden.
Er
kan een gewoon JAR-bestand gemaakt worden omdat dit niet op zichzelf uitgevoerd zal worden. Klik op volgende. Figuur 6.2(b) zal verschijnen en de inhoud van het archief kan geselecteerd worden. Vink op deze pagina de src en META-INF directories aan. Het is belangrijk dat het bestand uit codefragment 6.15 in de /META-INF/services staat. Als dit bestand vergeten wordt, zal de
ServiceLoader de toolkit niet vinden.
Op deze pagina moet ook de bestandsnaam
en locatie van de aan te maken JAR opgegeven worden. Als alle instellingen naar wens zijn, klik dan op volgende. De volgende afbeelding, guur 6.2(c), kan normaal onaangepast blijven. Klik op volgende. In de laatste stap van de `Export Wizard' ( guur 6.2(d)), kan het gebruikte manifest gekozen worden. Indien het manifest nog niet bestaat kan de wizard deze genereren. Ook hier zijn de standaardinstellingen normaalgezien goed. Als je op nish klikt zal het archief op de gewenste locatie aangemaakt worden. Mogelijk vraagt de wizard toestemming om bestaande bestanden te overschrijven. De `Service Provider' is nu klaar. Door het archief in een directory te plaatsen die door de
Configurator
gebruikt wordt voor het laden van toolkits, zal de nieuwe adapter voortaan beschikbaar zijn in de applicatie.
6.7 Besluit In dit hoofstuk werd het gebruik van de API aan de hand van een aantal voorbeelden behandeld. Om te beginnen werd aangehaald hoe de Translator voorzien kan worden van vertalingen. Dit gebeurt door middel van properties bestanden. Vervolgens werden de verschillende methodes uitgelegd om de API te gebruiken. Hierbij werd er vertrokken bij het gemakkelijkste en minst exibele voorbeeld, om gaandeweg naar het meest uitvoerige en volledig instelbare voorbeeld te gaan. Ook werd getoond hoe de kennisbankabstractiemodule manueel kan aangesproken worden om rechtstreeks via de applicatie wijzigingen door te voeren. Hierna werd er kort de verschillende interfaces en abstracte klassen vermeld die gebruikt kunnen worden om de API te laten functioneren zoals de applicatieprogrammeur dat wenst. Er wordt naar de documentatie verwezen voor meer informatie over het gebruik van de klassen. Tenslotte werd er een voorbeeld toolkit gemaakt om de work ow van het ontwikkelen van een dergelijke toolkit te verduidelijken.
(a) Export dialoogvenster
(b) JAR inhoud
(c) JAR export opties
(d) JAR manifest
Figuur 6.2: De Export Wizard
Besluit Het IDP-kennisbanksysteem is, op zichzelf, een interessant systeem voor academici om mee te experimenteren.
Helaas kan het systeem slechts met veel moeite geïntegreerd
worden in een applicatie. In deze masterproef werd daarom een Java API onwikkeld die op een exibele en eenvoudige manier toegang biedt tot een kennisbank in het IDP kennisbanksysteem. Hierdoor kan voor een brede waaier aan applicaties toegang geboden worden tot het IDP kennisbanksysteem, die de business logic van de applicatie implementeert. Aangezien de API toegang biedt tot een kennisbanksysteem, wordt een bepaalde functionaliteit verondersteld. Het moet mogelijk zijn om de inhoud van een kennisbank uit te lezen, alsook de toestand van die kennisbank te wijzigen. Deze functionaliteit wordt onder andere aangeboden door de kennisbank-abstractiemodule. Maar de API kan veel meer.
Deze bevat immers onderdelen die gebruikt kunnen worden om de applicatie en
dus ook de gebruiker op de hoogte te brengen van wijzigingen in de kennisbank. Ook is het mogelijk om applicatiecode op een bijna-automatische manier te koppelen met een kennisbank. Als er gekeken wordt naar het voorbeeld in sectie 1.2.1 valt het op dat dit niet veel meer is dan een venster met componenten, die rechtstreeks gekoppeld zijn met een kennisbank.
In de code van dit venster kunnen componenten met behulp
van korte aanduidingen, annotaties genoemd, verbonden worden met de kennisbank. Dit vraagt veel minder werk, is overzichtelijker en bijgevolg gemakkelijker aan te passen dan wanneer hiervoor zelf con guratiecode geschreven moet worden. De API die in deze masterproef ontwikkeld werd, is niet vanuit het ijle onstaan. Er was reeds een rudimentaire implementatie beschikbaar, samen met een aantal voorbeelden die hiervan gebruik maken.
Met die implementatie, con gNow genaamd, was het mogelijk
om het kennisbanksysteem aan te spreken, maar ze creëerde meer problemen dan dat ze oploste. In de eerste plaats was er geen documentatie, was de code bijna onbegrijpbaar en deed de implementatie niet altijd wat ervan verwacht werd. Bijkomend was con gNow zo speci ek en rechtlijnig geïmplementeerd, dat het onmogelijk was om deze in een exibele API om te zetten. Daarom is de ontwikkeling van de API met een schone lei gestart.
Hierbij werd eerst
de functionaliteit nagebootst die door con gNow aangeboden werd aan de meegeleverde voorbeeldapplicaties. Voor deze funtionaliteit werd eerst een ontwerp gemaakt en reeds nagedacht over nieuwe functionaliteit die achteraf toegevoegd zou kunnen worden. Hiermee rekening gehouden, werd een eerste versie van de API geschreven.
Door een doordacht ontwerp te maken was het niet moeilijk om nieuwe funtionaliteit toe te voegen en de huidige vorm van de API te bekomen.
In deze vorm is het nog
steeds gemakkelijk om aanpassingen uit te voeren. De ontwikkelde API is een geslaagde implementatie, die gemakkelijk en op verschillende manieren gebruikt kan worden en waarop men kan voortbouwen.
Bibliogra e Abhinav, K. (2010), `Interactive Con guration Tool'. Clayberg, E. and Rubel, D. (2008), Eclipse Plug-ins, Addison-Wesley Professional.
R
Holzner, S. (2006), Design patterns for dummies , John Wiley & Sons, Inc., New York, NY, USA. Horstmann, C. and Cornell, G. (2007), Core Java
TM , volume I-fundamentals, eighth edi-
tion, Prentice Hall Press, Upper Saddle River, NJ, USA.
Horstmann, C. and Cornell, G. (2008), Core Java
TM , volume II-advanced features, eighth
edition, Prentice Hall Press, Upper Saddle River, NJ, USA.
TM EE
Jendrock, E., Ball, J., Carson, D., Evans, I., Fordin, S. and Haase, K. (2006), Java
5 Tutorial (3rd Edition) (The Java Series), Prentice Hall PTR, Upper Saddle River,
NJ, USA. KUL (2008), The IDP system: A model expansion system for an extension of classical logic, ACCO.
Liang, S. (1999), Java Native Interface: Programmer's Guide and Reference, AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA. Mariën, M., Wittocx, J. and Denecker, M. (2006), The IDP framework for declarative problem solving.
Nielsen, J. (1994), Usability Engineering, Morgan Kaufmann Publishers, San Francisco, California.
TM
Tutorials)', http://download. oracle.com/javase/tutorial/uiswing/concurrency/index.html.
Oracle (2010a), `Concurrency in Swing (The Java
Oracle
(2010b),
`Internationalization
(The
TM
Java
Tutorials)',
oracle.com/javase/tutorial/i18n/index.html. Oracle (2010c),
`JAR File Speci cation',
docs/technotes/guides/jar/jar.html.
http://download.
http://download.oracle.com/javase/6/
http://download.oracle. com/javase/6/docs/api/java/net/JarURLConnection.html.
Oracle (2010d), `JarURLConnection (Java Platform SE 6)',
Oracle (2010e), `The Re ection API (The Java
TM Tutorials)', http://download.oracle.
com/javase/tutorial/reflect/class/index.html. Wittocx, J. and Mariën, M. (2010), The IDP system.
