1.

Introduction My project is to create a working and usable simulation of Push-down automata with the Java language, using a suitable graphical user interface framework. The data is to be persisted in an XML format for reuse. This is version 1.3 of my project proposal created on 20/03/2013 The project supervisor is Michael Zakharyaschev. 1.1 Push Down Automata The push-down automata (hereafter abbreviated as PDA) is an abstract model of computation often introduced in classes that deal with the theory of computation as an extension of the more simply defined finite-state automata. They are often defined in conjunction with finite-state grammars, and although often overlooked as a topic a thorough appreciation of the PDA aids with understanding the fundamentals of compilation algorithms, and more advanced topic relating to Turing Machines. A formal, set theoretic definition of the can be defined as (pg 110:

As can be seen, the fundamental concept of a PDA is that it is a processor of data with the datum being an arbitrary input (defined as alphanumeric symbols, traditionally) from an ordered, sequential list of inputs. This is in a sense an abstraction of data such as it appears to a real computer. The key difference with the finite state machine is that it has two state changes, instead of one. As with a finite state machine, the automata will either reject an input as erroneous or change from one state to another based on the design of the automata. However, in addition it has a stack, a form of memory which is equivalent to the data-structure of a stack, defined thus:

As a consequence, any input can force the stack to pop or pop off a symbol, forming a primitive memory. If the string ends in a state defined as accepting or with an empty stack the PDA is said to accept the input depending on type. I will let the user set either, as it could form part of the exploration of the well-known proof of these types of PDAs being equivalent (pg. 114) This representation of the Pushdown automata usually has states represented by: 1.2 Deterministic and non-deterministic PDAs The application will be able to represent both deterministic and non-deterministic finite automata. Determinism has been defined by Hopcroft et al. as (pg 113):

In practicality this will be equivalent to giving the user free-reign between the nodes connected by epsilons, and more than more possible move will be possible for a given input at a time. It should be possible to allow the user to define the type of PDA at the start, and allow them to construct both. In addition, with suitable warnings, the system should be allowed to auto-play all

possible results, although this may have to be curtailed to graphs of certain size given the exponential computational complexity this can introduce on non-deterministic automata (http://swtch.com/~rsc/regexp/regexp1.html). Finding a limit for this will form part of the exploration of the programme. 1.3 Higher-Educational Tool As an abstract concept, the notion of a PDA is often difficult to connect to its applications, due to the larger overhead involved in manual calculating non-trivial examples. My project aims to bridge this gap by producing, using standard GUI tools, a simulator which represents the PDA as a concrete entity. As part of this it is envisioned that the user can construct their own PDAs, use those constructed by someone else, and them operate them in both a step-wise and automatic method. One of the benefits of this is that specific concepts of the application of the push-down model of computation can be worked with, and demonstrated in an animated matter within the control of the student themselves. The problem to be solved by this project is therefore essentially to present the abstract concept of the PDA both in a visually arresting way and with sufficient clarity to aid understanding. The development process should result in automata that are both easy to use, easy to build and assume no prior knowledge of the necessary data structures, XML or FSA. The application should be largely self-documenting, where possible without prompts, and should not require the use of a manual which might discourage its use as an exploratory tool. A secondary consideration of this is that, as an educational tool, the symbolic representation of the automata should adhere as much as possible to the standard circle and line notation found in most textbooks. 1.4 Adjacency List vs. Stack The fundamental representation at the class level of the system could be adjacency lists. This is because the linked-list representation will aid the creation of dynamic nodes that represent moderately complex states and will save a great deal of space on what would, for a typical automation be a fairly sparse adjacency matrix, which is the alternative type of data structure which is used in such circumstances (http://www.algorithmist.com/index.php/Graph_data_structures). Another way of representing pushdown automata, and one I aspire to eventually is a stack based repres 2. Background 2.1 Educational simulations The chief requirement or aim of the project is to produce software that broadly fits under the category of educational. More specifically, the subject matter is relevant to undergraduate study. The use of computer-mediated software has been qualitatively assessed for some time as having many benefits in this environment. Specifically it adds a degree of flexibility and allows the student a degree of control over their own pace of learning and encourages a tempo that fits with their own mind-set. (CMC in an undergraduate setting Paul Light and Vivienne Light Learning with computers pg 169) It adds a layer of anonymity to the learning which may aid

shyer students, and encourages traits of self-learning among the newer students. (pg 170-1) It should be noted however, that many of the positive correlation for these methods are not wholy substantiated, and it is controversial as to whether they are generally applicable (pg173). Consequently, it is necessary to justify the education tool on the specific subject matter. The concept of automata and abstract mathematical computer models in general are often hard to grasp for those whose learning style tends more towards the physical instantiations rather than the abstract, which includes many programmers. As Roger Saljo has demonstrated, there has been a long literary connecting the use of tools with learning, through a connection of human cognition the mental representation of the concept the process of learning it and the mediational means. (Learning as the use of tools pg 154) For example, in Japanese schools paper cut models have been shown to be an effective means of demonstrating abstract elementary geometry to children. In a sense, an operational and animated automata works on an analogous cognitive basis, that is allowing the human mind to form a concrete representation of the abstract concepts operations with regard to a set of deterministic visual stimuli. There is a strong connection between conceptual formation and visualisation (pg 158), which is why graphs are often used to demonstrate the concepts by lecturers. However, an animation has the benefit of allowing operations to happen in real time and with clearly marked transitions, shifting the cognitive burden from understanding the connection of the graphical representations to the underlying logic of the mathematical model. 2.2 System Design patterns Several design patterns will be used in this project. The MVC pattern is, in the type I am using, a pattern whereby there is a tripartite separation of concerns in the program. (see diagram) The view handles the display, and the discovery user interactions, whilst the controller acts as an intermediate between the domain model and the view. (http://www.javaworld.com/jw-041998/jw-04-howto.html) Changes to the model are posted to the view which completes a compartmentalised cycle. Firstly the MVC pattern will structure the GUI. (get ref) The MVC pattern is particularly well suited to this application due to the structure of the system which is based on the operation of a strictly defined and rigid model. As such it has its own internal logic which would be implemented in its own domain. It is also a model which could potentially be implemented in different ways depending on the circumstances. The model at any one stage will be equivalent to the instantaneous description as described in Hopcrofts book. (hopcroft 111) The instantaneous state of any one state machine is itself a well defined mathematical object and the movement to a different state can be mapped as a relation. The system could be regarded as mapping the two aspects of the system - the database itself will represent the push-down automata as a static definition, whereas the model will represent a series of instantaneous descriptions which are its dynamic aspect. For the database I intend to separate the part of the database which generates the objects from the parsing of the database itself. For this purpose a data access object will be used, which is designed to separate the concerns of the database from the actual mechanism of generating the necessary object in the model. (keiths notes) This will make porting the database to a traditional relational DBMS a good deal easier.

2.3 Possible implementation of graph ordering algorithm 2.4 Graphics The application has a key requirement to support a relatively flexible drag-and-drop page for the construction of bespoke push-down automata. As a consequence I will likely be using JavaFX2 (which supports native applications) instead of Swing, which is the main competitor to this. The chief reason is Swings lack of flexibility with formatting (Pro JavaFX 2: A Definitive Guide to Rich Clients with Java Technology pdf pg 167) it is important that I retain a great deal of control over the visual aspects and locations of various components to make the application appear satisfactory. In addition JavaFX offers, as part of its API several in built shapes and a natural format in which to specify start points and end points between graphical objects (http://docs.oracle.com/javafx/1.3/tutorials/ui/overview/index.html) which is important in this application. JavaFX also overs a unique syntax for defining components in a CSS-like format, which will help increase the maintainability of the code and hopefully make reskinning it comparably easy. (javafx book pg 465) The chief downside of using JavaFX is its lack of maturity compared to Swing and the lack of documentation. However the book referenced here on JavaFX should I feel provide sufficient documentation for my needs. 2.5 XML Database As I am writing the code itself in Java, my aim is to use a persistence format that is easily interoperable with other programmes that use a SAX parser, for example, to read the persisted output of the automata. (pg. 275) Java has in-built capacity to read from a relational database such as Oracle or SQL server, but there would be many advantages to using XML instead. Firstly, Java, as with many modern object-orientated languages has rich library support to parse and edit XML format texts. Although JDBC provides similar capacities to do so with relation databases, the mechanics of the passing of SQL instructions and the setting up, pooling and closing of connections make the code both less eloquent, sometimes (at least for small transactions of the type used in this project) slower and less maintainable. (pg 2) There is also typically easier mapping to data formats in the native code and so avoids the need to implement a framework such as hibernate with the overhead that can provide, and ensures the modality of the persistence is closely coupled with the model used as part of the fundamental design pattern of the application. Finally, for an expert user, given the relative simplicity of XML, it should not be too hard to design a full automaton, or more likely, edit one using only a text editor. To this end, I will specific a schema for this database, along with a schema that specifies each automaton. The schema will be written in XML schema, which offers a clean syntax for specifying the database, can be parsed like any other XML file and offers a simple means of porting it to a more traditional database if this is desired. (Professional xml pg 144) The database will be quite simple with a generally flat hierarchy of no more than two levels of relations for the automata, which of course is itself a fairly straightforward data structure. The aim is to allow the user to primarily interact with those automata that are predefined and saved in a simple folder structure within a screen of the page. Selecting a automata specified in XML would allow the user to rapidly display the selected automata on the screen. Although not forming a key component of this project, a nice to have, and a possible extension could see this page utilising Xlink queries (pg 369) to allow the user to specifically bring up automata with certain properties.

3. Specification 3.1 Tasks My aim is to have the programming part of the project finished by the end of June, so as to leave sufficient time to document it. I plan to start as soon as the term begins. My aim is to sequentially build aspects of the application in the following order: 1 Define and construct a DTD for my XML standard of PDAs and generate a parser object tailored to this in Java. My aim is to quickly marshal the XML in an efficient manner so that the persistence model can be simply generated. Create a set of Java objects that represent the model in a data structure. My aim is to use standard features of object-orientation. As part of this a class model will be constructed in UML and will be presented in the documentation. As an initial plan the whole automata will exist as an object. Current states will be generated through the construction of a stack that has design pattern based references to the objects. Finally the links between objects will exist as a list within a list. Standard library objects will be used throughout when possible. Create a console application that reads an XML file and a string of input and generates a success or fail. It is my plan to keep this as a separate executable than can be tested as a stand-only, so testing can be refined on the actual object itself. As a consequence part of the work at this stage will be constructing an interface that can be used by other programmes. The final GUI application will make use of the API and use the same model. Consider time and progress and make a decision as to whether to extend the application to cope with non-deterministic PDA. This might involve extending the DTD to include epsilon moves and a key part of the experimentation in the design will be determining the feasibility of this. In addition logic, which will be given by an UML activity diagram, will be used to determine all possible paths. Develop the GUI system using the JavaFX. A graphical user interface of this nature is necessary in order to meet the criteria specified above for it to be visually arresting and easy to use. This will firstly involve creating the necessary animation from PDA specified. The GUI should support by stepwise actions taken by the user through the automata and an automated process which gives success conditions. The user should be able to enter strings in a textbox below the animation and clear the input as necessary. For automated runs an output of successful or failed runs should be shown below the textbox. Develop a PDA builder as a separate screen. Allow the user to construct the PDA through a drag and drop interface. The user should be able to persist the automata as an XML specification stored within an XML database framework. Should time be remaining three nice-to-have features could be integrated into the application. A method of batch processing a common delimited file of string inputs with output to the textbox console in the application. A slider which controls the speed of the animation of the PDA when automated. A button in the PDA builder screen which organises the PDA into a well organised visual pattern for the user. The ordering of the nodes into pleasant shapes may be accompanied by the use of third party algorithms or APIs. 3.2 Dependencies

The most important dependency is the XML reader, as testing the application without a way to define push-down automata in XML would be timeconsuming. The GUI will be strictly dependent on the model. 3.3 Time Table Task Timeline

3.5 Risk analysis The risks I face can be subdivided in the following areas: Time risk: One of the key risks will be a squeeze in development time by conflicting interests on my part and by unexpected delays or events. This is something that will largely have to be managed by time control on my part, but also a need to assess if the quality of the programming in the given time is of sufficiently high quality to go out. In addition the work is built sequentially, so that at any stage there are deliverables that can be carried forward. Technical risk: Given that I will be using features of C# that I have not used before, there is the possibility, even probability that some tasks will be harder to achieve than expected, if not impossible. This is one of the reasons for the agile design specified above, my plan is to allow the design, whilst keeping with the stated specified requirements above, to flexibly match what is needed rather than attempt to force together technologies poorly matched to the task. Specific issues on this point could revolve around the use of JavaFX, of the class model for the Push down automata, or for the XML data structure. Analysis risk: There is also the possibility for the analysis itself, at least the specification above to be at fault. This is generally fairly low risk, given that there has been many proven examples of equivalent projects of broader scope (quote the java project for finite state machines). Nonetheless some of the specific detals mentioned above may prove infeasible, although this is a low risk. The final documentation will, if this becomes necessary, detail where changes were made.

3.6 Testing methodology Testing is an important part of any project, but for such a user-driven application as I intend to develop it is essential to have a thorough testing strategy to ensure the users experience is not compromised in a distracting manner. Therefore I will clearly set out in my documentation a test plan, and a set of test cases that will be measured. I will define the necessary exit criteria and diagnose bugs according to a priority structure. My aim is to have sufficient user input to have at least one round of testing performed by someone other than myself. 3.7 Documentation My project will use UML to display the analysis and structure of the application. Testing will be presented in a clear format derived from principles I use whilst testing in my employment (I

work as a software tester). Otherwise the documentation will largely follow the template set in Sven Helmers notes for the project. 3.8 Development life-cycle methodology To develop this project I intend to use something close to extreme programming methodology (get reference). I will, until the final stages, primarily be running the application by myself, so the parts of the methodology applicable to teams are no relevant to this. However the essential kernel of test-driven development is. As a consequence I will be rapidly alternating between developing the application, and then testing those recently created, leading to a test-driven development cycle. The tasks above will structure individual sprints in the development process, and within this I will structure sub-tasks that build incrementally on each other to work towards the overarching task. An important part of the extreme programming methodology is feedback (quote) from the system and from the user. The application will be covered as much as possible but a rigorous set of unit tests. Moreover, the primary user will be my supervisor. As part of the general communication between myself and my supervisor, I will give brief demonstrations of progress and work with comments and recommendations made in order to refine the design. In addition, at each stage of development I will look to refactor code from before as my experience of the task at hand deepens. 4. Conclusion The basic aim of the project is to develop a native client application that can visually and engagingly present finite state automata. This will be the chief requirement and one that will override over concerns. This project is to be a culmination of several skills I have learnt, especially in terms of mathematical and programming and shall serve to demonstrate a capacity to create a well engineered application and will hopefully form an important part of my career aspirations towards being a professional developer.