project profsdfsdposal push down

7/29/2019 Project Profsdfsdposal Push Down

1/7

1. IntroductionMy 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.1Push Down AutomataThe 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.2Deterministic and non-deterministic PDAsThe 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


2/7

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.3Higher-Educational ToolAs 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.4Adjacency List vs. StackThe 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 LightLearning with computers pg 169) It adds a layer of anonymity to the learning which may aid
http://swtch.com/~rsc/regexp/regexp1.htmlhttp://swtch.com/~rsc/regexp/regexp1.htmlhttp://swtch.com/~rsc/regexp/regexp1.htmlhttp://www.algorithmist.com/index.php/Graph_data_structureshttp://www.algorithmist.com/index.php/Graph_data_structureshttp://www.algorithmist.com/index.php/Graph_data_structureshttp://www.algorithmist.com/index.php/Graph_data_structureshttp://swtch.com/~rsc/regexp/regexp1.html


3/7

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 whygraphs 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-04-

1998/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.


4/7

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 andedit 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.
http://docs.oracle.com/javafx/1.3/tutorials/ui/overview/index.htmlhttp://docs.oracle.com/javafx/1.3/tutorials/ui/overview/index.htmlhttp://docs.oracle.com/javafx/1.3/tutorials/ui/overview/index.htmlhttp://docs.oracle.com/javafx/1.3/tutorials/ui/overview/index.html


5/7

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 tosequentially 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 tailoredto this in Java. My aim is to quickly marshal the XML in an efficient manner so that the

persistence model can be simply generated.

2 Create a set of Java objects that represent the model in a data structure. My aim is to usestandard 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 listwithin a list. Standard library objects will be used throughout when possible.

3 Create a console application that reads an XML file and a string of input and generates a successor 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.

4 Consider time and progress and make a decision as to whether to extend the application to copewith 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.

5 Develop the GUI system using the JavaFX. A graphical user interface of this nature is necessary inorder 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.

6 Develop a PDA builder as a separate screen. Allow the user to construct the PDA through a dragand drop interface. The user should be able to persist the automata as an XML specification

stored within an XML database framework.

7 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


6/7

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 conflictinginterests 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 thequality 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, thereis 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 specificationabove 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


7/7

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 capacityto create a well engineered application and will hopefully form an important part of my career

aspirations towards being a professional developer.

project profsdfsdposal push down

Documents