Proceeding of the 3rd International Conference on Informatics and Technology,

Embed Doc
Copy Link
Readcast
Collections

CommentGo Back

Download

REPRESENTATION OF CONDITIONS OF PROGRAMMING STATEMENTS INPOST-COMPILE MODIFIABLE LAYOUTSRam Gopal Raj

Department of Artificial Intelligence,Faculty of Computer Science and Information Technology,University of Malaya, 50603 Kuala Lumpur, Malaysia. Email:ramgopalraj@perdana.um.edu.my

ABSTRACT

Software development for large scale systems is often very costly. Large systems tend to have long service lives and thus meet with ever changing operational requirements. Catering to such changes necessitates changes to thesoftware resulting in increased expenditure. However, allowing the conditions for conditional statements such as ‘if statements’ by which a program operates, to be stored in a format that does not require any application changes but only external file changes can save considerable effort, time and money. Presented here is one of the techniques,used by our chatterbot, RONE, to allow self adaptability on multiple levels. The technique is applicable to all programming purposes, and will enable the making of fewer application changes and hence reduce corresponding costs, for systems with long service lives.

Keywords: SQL, Knowledge Base, Conditions, Adaptability.

1.0 INTRODUCTION

Development of software systems is often tremendously expensive work. Apart from initial development costs,software systems may experience lifetime costs. Lifetime costs occur if a software system requires further changes or adaptations during its time of service. A software system is called

adaptable

if some of its properties, which are stableduring regular use, can be changed in order to meet diversified or changing requirements, [2].Therefore we see two options. One option being to either spend a lot of money initially and build a verycomprehensive system that will have a long service life with minimal maintenance and updating issues or build asimple and comparatively cheap system that will subsequently need frequent and costly changes. The other option,being to have a system that could be modified during its operational lifetime without having to restructure largemasses of source code and change various conditions or add new conditions. For example, if the program was builtwith a smart updating system which requires no recompilation or reinstallation but allows changes to be made duringits uptime, it would posses a considerable degree of reusability of the system itself as opposed to reusability of onlyits components. Such adaptability and reusability would result in considerable savings in terms of long term systemmaintenance.Adaptability is favorable for a number of reasons. For example, human users usually have different needs, views,ways and preferences; and there appears to be no ‘one best way’ to accommodate all their differences. The situationescalates when one considers groups of humans or even entire organizations. As the world we live in becomesincreasingly computerized, accommodating the different human preferences and ever changing operationalenvironment conditions also increases in importance. As such software adaptability is becoming practicallyindispensable. Additionally, by building adaptive systems, developers can maximize their profits by accommodatingeven larger market segments. Currently software development is expensive and most software systems are notcompletely custom-built anymore [1].When we look at adaptability, we need to consider a number of factors. Firstly one needs to know just how muchadaptability is required, what are the aspects of the program that need to be adaptable? Once the required or desireddegree of adaptability has been determined, one must decide how to implement those features. We believe that themost efficient adaptations are those that are implemented by the systems themselves through interacting with users,rather than relying on users to tell the systems how to adapt. Our experience suggests that humans tend to be morehonest about how they would like a machine to behave when the users actually interact or use the machine rather than when they describe how they would like the machine to behave. Finally, one has to figure out how all thisadaptability is to be accommodated in the software architecture? Consideration of these factors, suggests to us thatany system that is to be adaptable must be able to store new information.Conversational programs must have the ability to learn from their interactions with users. In order to learn, theseprograms must have an adaptive knowledge base system that can be updated by the programs themselves. Wehave introduced our learning program, RONE, in a previous paper, [3]. We cover in this paper, a new technique usedby RONE for storing the conditions of programming ‘if’ statements as well as loop numbers in an SQL database inorder to allow a conversational program to adapt to future conversations. While we acknowledge that our researchscope is limited to enabling our system to perform only tele-text conversations with users, it must be clarified thatRONE is a chatterbot. The idea behind its design is to allow it to adapt on its own without requiring any recompilationor reinstallation - a technique that is usable in other programming applications.

©Informatics '09, UM 2009

RDT

7

-

257

Proceeding of the 3rd International Conference on Informatics and Technology, 2009

2.0 COMPONENTS REQUIRED FOR NEW LAYOUT

There are three components that have to be built into a system using our adaptive technique. These are:1. The actual SQL based statements representing the conditions,2. The queries used for retrieving the conditions and3. The programming statements used to process those stored conditions.The traditional 'if' statements as used in programs are converted into very general ‘if’ statements containing no directcondition references and results, but perform based on conditions and results stored in the SQL database. Thequeries are the bridge between the two other components. Of the three components above, only the SQL basedstatements need to be changed in order to adjust the behavior of the ’if’ statements.

2.1 Conversion of traditional programming statements into new format

The queries involve many 'or' conditions in concert with 'not' conditions. The idea is that the 'and or' is simulated bymany 'not and's as seen in Table 1. The limitation here is that it only applies to an 'if' statement with a finite number of conditions. This is because the 'not' must include all the conditions that are not applicable. For example, the formatfor "If before = preposition or conjunction and evenevenbefore = noun or UW then present = nounPhrase" translatedinto "not and" is:"SELECT WRD,EQLS,TMS,DVDS FROM RNCODE" +" WHERE WRD NOT LIKE '%NT" + evenevenbefore +"%' AND EQLS NOT LIKE '%NT" + evenbefore +"%' AND TMS NOT LIKE '%NT" + before +"%' AND DVDS NOT LIKE '%NT" + present +"%') AND MNS NOT LIKE '%NT" + next +"%'Table 1: Example of Storage Format for "or and" method

WRD EQLS TMS DVDS MNS PLS

Breakdown evenevenbefore evenbefore before present next nullExample NTinterjectionNTatheanNTconjunctionNTprepositionNTverbNTadjectiveNTadverbNTquestionwordNTpronounNTnounPhrase# NTinterjectionNTathean NTnounNTverbNTadjective,NTadverbNTquestionwordNTpronounNTnounPhrase=noun # #EquivalentprogrammingstatementIf before = preposition or conjunction and evenevenbefore = noun or UW then present = nounPhraseAll Possibilitiesinterjection, athean, conjunction, preposition, noun, verb, adjective, adverb, questionword, pronoun,nounPhraseThe "not and" conditions in Table 1 are labeled with an "NT" to differentiate the conditions from the solutions whichare marked with a "=". Our examples involve a part of speech prediction algorithm that we implemented in RONE.The algorithm consists of a finite number of outcomes, the eight parts of speech, as well as a finite number of conditions since the algorithm is based on preceding words and on occasion subsequent words. Due to the adaptivenature of RONE, the complete set of rules as listed were derived from RONE's experiences rather than determinedby us. The rules were determined by experiences of recognized word patterns and the preceding and following wordsin the sentences in which the relevant words appeared. Therefore the rules themselves were in part derived by theprogram, adding proof to the suitability of using our technique in adaptive programming.

3.0 IMPLEMENTATION OF NEW FORMAT

When RONE encounters an unknown or never encountered word (UW), it will use an algorithm to predict what part of speech that word belongs to. The algorithm is based on English sentence structures. Instead of the implementation

Proceeding of the 3rd International Conference on Informatics and Technology, 2009

©Informatics '09, UM 2009

RDT

7

-

258

method of "not and" as seen in Section 2.0, we chose to use regular "or" matches for greater flexibility as well as thesuitability in matching multiple patterns since it is more flexible than the "not and" implementation.In almost any complete sentence an unknown word is often surrounded by other words, either before or after theunknown word (UW). The exceptions of course are punctuation marks that the system segregates as other wordssince these punctuation marks often have an impact on the meaning of a sentence and the UW being at thebeginning or the end of a sentence. However it is still possible to accommodate those circumstances. The namingconventions used are ‘present’ for the part of speech of the present word that the system is looking at, ‘before’ for thepart of speech of the word before, ‘evenbefore’ and ‘evenevenbefore’.The following are the basic rules used in the algorithm:If present = UW then check before.If before = adjective or verb then present = maybe a noun or an adjective = maybeMnoun/adjective.If the word before is a, the, or an, athean in our naming convention, i.e. before = athean, or before = preposition or before = conjunction then present = maybeMnoun/adjective.If before = maybeMnoun/adjective then present = noun and before = adjective.If before = UW and present = UW, if evenbefore = conjunction then before = nounPhrase.If before = noun then present might be a verb or maybeverb.If before = preposition or conjunction and evenevenbefore = noun or UW then present = nounPhrase.If before = maybe/nounProper then before and present = nounPhrase.If before = pronoun then present might be a noun or maybenoun.If before = questionword and/or evenbefore = interjection then present = verb.If before = interjection then present = pronoun or noun.The above set of algorithm rules caters for a ‘present’ word the system is looking at. However for the purpose of processing all the ‘maybes’ that may be generated in the ‘present’ processing algorithm, when the system has movedon to the following word, what was the ‘present’ word becomes the ‘before’ word. Thus the ‘before’ word may need tobe processed. However the algorithm for the ‘before’ word is outside the scope of this paper. Hence it is covered inother publications and not in this paper.The algorithm for the ‘present’ word can be implemented as a set of ‘if’, ‘else if’ and ‘else’ statements but for thepurpose of the system’s evolving and learning capability, the algorithm is stored as a combined ‘if’, ‘else if’ withconditions stored in the knowledge base itself using the technique described in this paper.

3.1 Statement storage as part of the knowledge base

In order for the system to be able to learn on multiple levels, we have implemented the statements as part of thesystem’s knowledge base. To insert the conditions into the database, SQL INSERT statements such as the onebelow are used.INSERT INTO RNCODE (WRD,EQLS,TMS,DVDS,MNS,PLS)values ('#','#','adjective || verb','= noun','athean || pronounPossession || adjective || preposition','#')Each table in the knowledge base has six columns that are used as a filter for what a particular word could representor mean. The six columns are WRD, EQLS, TMS, DVDS, MNS and PLS. The intention here is not to produce aregular relational database, using standard database design rules and practices such as normalization, but to use thetuples and rows in a unique manner that will allow the knowledge base to grow at the program’s disposal and yetcontinue to be manageable, meaningful and usable. Therefore, normalization or database design diagrams are notused or presented in this description of RONE.The conditions and solutions are stored in our standard knowledge base layout shown in Table 2.Essentially we use each subsequent row as a step by step ‘if’ and ‘else if’ format. The code loops the same SQLstatement repeatedly through the table row by row until all the lines have been gone through. The SQL statement weused for the system is as follows:"SELECT WRD,EQLS,TMS,DVDS FROM RNCODE" +" WHERE codeNum =" + (countRules+1) +" AND (WRD LIKE '%" + evenevenbefore +"%' OR EQLS LIKE '%" + evenbefore +"%' OR TMS LIKE '%" + before +"%' OR DVDS LIKE '%" + present +"%') AND MNS NOT LIKE '%" + next +"%'"

Proceeding of the 3rd International Conference on Informatics and Technology, 2009

©Informatics '09, UM 2009

RDT

7

-

25

9

of 00

Leave a Comment