Declarative Programming Tools for Computer Sience Engineering

7/29/2019 Declarative Programming Tools for Computer Sience Engineering

1/130

Declarative

Programming

For Computer Science

Engineering

Yarmouk Private UniversityFaculty of Informatics & Communication Eng

Software Engineering Department

YPU - 2013

Copyrights Yarmouk Private University 2013

http://www.ypu.edu.sy

By

Tareq Jehad AlJebawi

Supervise

Dr. Adnan Ali

Moving from the context

of purely mathematical

applications to figure out

how to apply the ideas of

theoretical models into

computing problems.


2/130

2 | P a g e

Yarmouk Private University

[System Specification Document]

Declarative Programming Tools for Computer Science Engineering

By


Supervising

Dr.Adnan Ali

Registration Date: 01 November 2012

Delivering Date: 21 August 2013

Submitted to the

Faculty of Informatics and Communication Engineering

Software Engineering Department

In partial fulfillment of the requirements

For the award of the degree

Of

Bachelors Degree

In

Software Engineering

August 2013


3/130

3 | P a g e

Table of ContentsAbstract ...................................................................................................................... 6Acknowledgements .................................................................................................... 6List of Tables ............................................................................................................. 7List of Figures ............................................................................................................ 7List of Symbols, Abbreviations or Nomenclature ..................................................... 9

Chapters....................................................................................................................10

[Chapter 1] Theoretical Models ...............................................................................111. Introduction ........................................................................................................... 12

1.1. System Approach ......................................................................................... 121.2. Implemented Models ................................................................................... 13

2. Finite State Automata ............................................................................................ 142.1. Why Finite Automata .................................................................................. 142.2. Deterministic Finite Automata .................................................................... 142.3. Nondeterministic Finite Automata .............................................................. 152.4. Equivalence of Deterministic & Nondeterministic Finite Automata .......... 162.5. Finite Automata with Epsilon-Transitions .................................................. 16

3. Finite State Transducer ......................................................................................... 183.1. What are Finite State Transducers? ............................................................. 183.2. Formal Construction .................................................................................... 183.3. Ways of looking at a finite state transducers ............................................... 193.4. Cascading finite state transducers................................................................ 193.5. Closure properties for regular relations ....................................................... 203.6. Finite State Automata in action ................................................................... 20

4. Pushdown Automata ............................................................................................. 214.1. Definition of the pushdown automata ......................................................... 214.2. The Language of a PDA .............................................................................. 23


4/130

4 | P a g e

4.3. Equivalence of PDAs and CFGs ............................................................... 235. Turing Machines ................................................................................................... 25

5.1. The Turing Machine .................................................................................... 255.2. Programming Techniques for Turing Machines .......................................... 27

6. Context Free Grammar .......................................................................................... 286.1. Context Free Grammars............................................................................... 296.2. Parse Trees ................................................................................................... 306.3. Ambiguity in Grammars and Languages ..................................................... 31

[Chapter 2] System Development Life Cycle (SDLC) ............................................331. Applied Methodology ......................................................................................... 34

1.1. Introduction ................................................................................................. 341.2. Agile Methods ............................................................................................. 35

2. Requirements ...................................................................................................... 362.1. Introduction ................................................................................................. 372.2. Specific Requirements ................................................................................. 37

3. System Analysis and Design .............................................................................. 423.1.

Defining a System ....................................................................................... 42

3.2. System Life Cycle ....................................................................................... 423.3. Phases of System Development Life Cycle ................................................. 433.4. System Behavior .......................................................................................... 54

4. Implementation ................................................................................................... 564.1. Implementing the State class ....................................................................... 584.2. Implementing the StateInput User Control .................................................. 594.3. Implementing the Transition class ............................................................... 604.4. Implementing the TransitionInput User Control ......................................... 624.5. Implementing the UniversalRecognizer class ............................................. 644.6. Implementing the FileManager class ........................................................... 71

5. Deployment and Testing .................................................................................... 755.1. Testing Finite State Automata ..................................................................... 775.2. Testing Finite State Transducer ................................................................... 905.3. Testing Pushdown Automata ..................................................................... 101


5/130

5 | P a g e

5.4. Testing Turing Machines ........................................................................... 1075.5. Testing Context Free Grammar ................................................................. 1115.6. Testing the Additional Functionality ......................................................... 116

[Chapter 3] Results .................................................................................................1181. Discussion and Conclusion .............................................................................. 118

1.1. System Functionality ................................................................................. 1181.2. Discussion .................................................................................................. 119

Bibliography ...........................................................................................................120Appendix ................................................................................................................120

1. C#.NET Programming Language ..................................................................... 1211.1. Classes ....................................................................................................... 1211.2. Converters .................................................................................................. 1211.3. Custom Controls ........................................................................................ 1251.4. Pages .......................................................................................................... 128

2. Prolog: Programming in Logic ......................................................................... 129


6/130

6 | P a g e

AbstractBackground Mathematics was always theoretical approach according to a lot ofstudents, really much of mathematics students where uncertainly about mathematics

and its applications. With existence of computer software and professional

programmers the mathematics reflected to the computer and become the most popular

model implemented in the computer. Now days the need for such applications is

rapidly growing according to the solutions it gives. Taking a model in mathematics

and trying to implements it in software is a very good idea for those how search about

such projects.

Results formal methods are a very popular mathematics models. What happens is thatwe tried to automate some of these models with our available ability. We start by

taking the following models:

a. Finite State Automata

b. Finite State Transducer

c. Push Down Automata

d. Turing Machines

e. Context Free Grammar

f. Hidden Markov Modelg. Probabilistic Automata

h. Probabilistic Context Free Grammar

Take each model alone, collect as information as possible about it, analysis it as

possible and try to design a good implementation for it, is what we did along the

system development life cycle (SDLC) of this system.

Conclusion A theoretical analysis, software engineering power, internet and the

modern technologies all we employ to serve our goal and achieve constructing this

useful system.

AcknowledgementsIn the name of Allah the most beneficent the most merciful. No programmer can

complete a project or a book without a small army of helpful individuals. We are

deeply indebted to Dr.Adnan Ali who draws the line for us. He has an excellent ideasand tactics. He was always reviews our work and gives the best solution for our


7/130

7 | P a g e

problems. When we were starting talking about the project idea he explained the

general idea of what we will do and the problem behind such systems. And we

mustnt forget that this work was to be very excellent if we continue working withdoctor Adnan and meet him continuously, but the stage that our country lived with

denied us from contacting continuously. We cant say except Thanks for Allah foreverything.

Finally, wed to point that the good things happen to us are from Allah. And the badthings happen to us from ourselves. No god but Allah.

List of TablesNO Section Number Description Page1 1.1 Finite State Automata Table1 Transition Table for Figure 2 172 2.3 System Analysis & Design Table2 Finite State Automata Input Frame 45

3 2.3 System Analysis & Design Table3 Finite State Transducer Input Frame 47

4 2.3 System Analysis & Design Table4 Pushdown Automata Input Frame 47

5 2.3 System Analysis & Design Table5 Turing Machines Input Frame 48

6 2.3 System Analysis & Design Table6 Context Free Grammar Input Frame 48

7 2.5 Deployment & Testing Table7 Transition Table for langue L 85

8 2.5 Deployment & Testing Table8 Transition Table example 5.1.7 89

List of FiguresNO Section Number Description Page

1 1.1 Finite State Automata Figure1 General FA machine example 14

2 1.1 Finite State automata Figure2 An e-NFA accepting decimal number 17

3 1.2 Finite State Transducer Figure3 FSA for rules of the previous example 21

4 1.3 Pushdown Automata Figure4 Pushdown Automaton is essentially a

finite state automaton with a stack

data structure

22

5 1.3 Pushdown Automata Figure5 Organization of constructions

showing equivalence of three ways of

defining the CFLs

24

6 1.4 Turing Machines Figure6 Turing Machine Architecture 26

7 1.4 Turing Machines Figure7 A TM viewed as having finite-control

storage and multiple tracks.

129

8 1.5 Context Free Grammar Figure8 Parse Tree for the given grammar 32

9 2.1 Applied Methodology Figure9 Agile Methodology 36

10 2.2 Requirements Figure10 Use Case Diagram 39

11 2.3 System Analysis & Design Figure11 System General Definition 42

12 2.3 System Analysis & Design Figure12 Phases of System Development Life 43


8/130

8 | P a g e

Cycle

13 2.3 System Analysis & Design Figure13 Model General Input/Output View 46

14 2.3 System Analysis & Design Figure14 Relationship between Input Table

and Visual graph

46

15 2.3 System Analysis & Design Figure15 Component Diagram 51

16 2.3 System Analysis & Design Figure16 State Input Design View 5217 2.3 System Analysis & Design Figure17 Transition Input Design View 52

18 2.3 System Analysis & Design Figure18 System Activity Diagram 55

19 2.3 System Analysis & Design Figure19 Models' Class Diagram 57

20 2.3 System Analysis & Design Figure20 State Input User Control 59

21 2.3 System Analysis & Design Figure21 State Input Type Changing 59

22 2.3 System Analysis & Design Figure22 State Input Context Menu 60

23 2.3 System Analysis & Design Figure23 FSA Transition Input User Control 62

24 2.3 System Analysis & Design Figure24 FST Transition Input User Control 63

25 2.3 System Analysis & Design Figure25 PDA Transition Input User Control 63

26 2.3 System Analysis & Design Figure26 TM Transition Input User Control 63

27 2.3 System Analysis & Design Figure27 CFG Transition Input User Control 64

28 2.3 System Analysis & Design Figure28 Graphics Library Class Diagram 74

29 2.5 Deployment & Testing Figure29 New project user interface 76

30 2.5 Deployment & Testing Figure30 User Query builder in two modes 77

31 2.5 Deployment & Testing Figure31 Finite automata simple recognizer 78

32 2.5 Deployment & Testing Figure32 Transition Table for then string 78

33 2.5 Deployment & Testing Figure33 Float signed number Recognizer 80

34 2.5 Deployment & Testing Figure34 Identifier Recognizer 82

35 2.5 Deployment & Testing Figure35 Even number recognizer 83

36 2.5 Deployment & Testing Figure36 Signed even number recognizer 84

37 2.5 Deployment & Testing Figure37 Signed odd number recognizer 8438 2.5 Deployment & Testing Figure38 Transition Graph for the language L 86

39 2.5 Deployment & Testing Figure39 Transition Graph for accepting string

ending with 01

87

40 2.5 Deployment & Testing Figure40 Transition Graph for accepting event

number of 0s and 1s

89

41 2.5 Deployment & Testing Figure41 A very simple deterministic finite-

state transducer

91

42 2.5 Deployment & Testing Figure42 Finite State Transducer with Epsilon

Transition

93

43 2.5 Deployment & Testing Figure43 Simple English - Arabic translator 93

44 2.5 Deployment & Testing Figure44 Simple dictionary Transition Table 9445 2.5 Deployment & Testing Figure45 English nouns plural generator 96

46 2.5 Deployment & Testing Figure46 English nouns plural more

enhancement

97

47 2.5 Deployment & Testing Figure47 Simple Encryption / Decryption

machine

100

48 2.5 Deployment & Testing Figure48 a's and b's counts balancer 102

49 2.5 Deployment & Testing Figure49 Pushdown Automata Transition

Table

103

50 2.5 Deployment & Testing Figure50 an bm cm dn String Recognizer 104

51 2.5 Deployment & Testing Figure51 Parenthesis Recognizer 106

52 2.5 Deployment & Testing Figure52 Turing Machines Transition Table 10853 2.5 Deployment & Testing Figure53 Binary Addition Machine 108


9/130

9 | P a g e

54 2.5 Deployment & Testing Figure54 an bm String Recognizer 110

55 2.5 Deployment & Testing Figure55 Grammar graph tree 111

56 2.5 Deployment & Testing Figure56 Context Free Grammar Transition

Table

112

List of Symbols,

Abbreviations or

NomenclatureNO Symbol, Abbreviation Description

1 DPT Declarative Programming Tools

2 FSA Finite State Automata

3 DFA Deterministic Finite Automata

4 NFA Nondeterministic Finite Automata

5 FST Finite State Transducer

6 PDA Push Down Automata

7 TM Turing Machines

8 CFG Context Free Grammar

9 HMM Hidden Markov Model

10 PA Probabilistic Automata

11 PCFG Probabilistic Context Free Grammar

12 SDLC System Development Life Cycle

13 Epsilon Empty or null

14 Q A finite set of states

15 A finite set of input symbols

16 Is the transition function

17 q0 Is the start state18 F Is the set of accepting states

19 A finite set of output symbols

20 Is a function in Q

21 Is a finite stack alphabet

22 W Is the remaining input.

23 Is the stack contents

24 P Is the next state, in Q

25 D Is a direction, either L or R or S

26 B The blank symbol

27 V Is the set of variables

28 T The terminals.


10/130

10 | P a g e

Chapters

Chapter 1: Theoretical Models

1. Introduction

2. Finite State Automata

3. Finite State Transducer

4. Push Down Automata

5. Turing Machines

6. Context Free Grammar

Chapter 2: System Development Life Cycle [SDLC]

1. Applied Methodology

2. Requirements

3. System Analysis and Design

4. Implementation

5. Deployment and Testing

Chapter 3: Results1. Discussion and Conclusion


11/130

11 | P a g e

[Chapter 1]

Theoretical Models

Chapters Sections:

Introduction

Finite State Automata

Finite State Transducer

Push Down Automata

Turing Machines

Context Free Grammar

n this chapter we will describe all the theoretical concepts that implemented in our system. The examples and

he figures will describe in the chapter 2: Deployment and Testing to give more understanding with the using

f our system


12/130

12 | P a g e

1. IntroductionMany existing computer systems were unthinkable some years ago and theircomplexity is still rapidly growing so that it becomes more and more difficult to detect

errors or to predict their incidence. Formal methods play an increasing role during the

whole system-design process. The term formal methods covers a wide range ofmathematically derived and ideally mechanized approaches to system design and

validation. More precisely, research on formal methods attempts to develop

mathematical models and algorithms that may contribute to the tasks of modelling,

specifying, and verifying software and hardware systems. But students of computer

science often study formal methods in the context of purely mathematical

applications. They have to figure out how to apply the ideas of theoretical models tocomputing problems.

The logic programming language Prolog is easy to learn and use because its syntax

and semantics are similar to that of formal models. The instant feedback provided by

Prologs interactive environment can help the process of learning. The Prologlanguage allows exploring a wide range of topics in computer science engineering.

Prologs powerful pattern-matching ability and its computation rule give us the abilityto experiment in two directions. For example, a typical experiment might require a test

of a definition with a few example computations. Prolog allows this, as do allprogramming languages. But the Prolog computation rule also allows a definition to

be tested in reverse, by specifying a result and then asking for the elements that give

the result. From a functional viewpoint this means that we can ask for domain

elements that map to a given result. A major aim of this project is to integrate, tightly,

the study of formal models with the study of central problems of computer science.

Concepts of formal models are illustrated through the solution of problems that arise

fundamental domains of computer science engineering.

1.1. System ApproachIn our system (Declarative Programming Tools) the idea was not to move the

mathematical concepts into computing problems only, but try to find a way that the

user can declare and use the system in very easy way especially in the way of entering

data and getting outputs. These ways considered as follow:

1. Transition Table

2. Visual Graph


13/130

13 | P a g e

Transition Table means enter or declare the data in a user friendly table and maintain a

collection of these data to be treated into logic programming code and visualizing

them using the Visual Graph.

Visual Graph means draw nodes and arcs using simple tools to generate the same

graph that can generated using the Transition Table, of course this graph can be

converted into the corresponding Transition graph and behave like if we in the

Transition Table mode.

At the end of declaring our data, the system will be ready to make some processing

over these data and add another data to finally generate the desired code we look for,

this process described as generative programming. At this point the system able to

allows the users to test the generated code using the Logic Programming Interpreter

such Prolog and using this interpreter as recognizer or generator.

1.2. Implemented ModelsThe automata theory contains many models and a lot of theories we try to treat the

most important models which are:

1. Finite State Automata.

2. Epsilon Finite State Automata.

3. Finite State Transducer.

4. Push Down Automata.5. Turing Machine.

6. Context Free Grammar.

7. Hidden Markov Model.

8. Probabilistic Automata.

9. Probabilistic Context Free Grammar.

In addition to these models there are some conversion techniques that helps in convert

from one model to another one, really there are three type of conversions that are:

1. Converting from Context Free Grammar to Pushdown Automata

2. Converting from Regular Grammar to Finite State Automata

3. Converting from Finite State Automata to Regular Grammar

We will get benefit from these converting operations because we can declare our

language simply a model rather than another one. In the next sections we will see the

desired models in purely mathematically concepts provided with some examples and

figures to make the idea easier. Then in the second chapter of System Development

Life Cycle (SDLC) we will demonstrate the way that we extract the similarity

between these models and how we planned to employ it.


14/130

14 | P a g e

2. Finite State AutomataThis section introduces the class of languages known as regular language. Theselanguages are exactly the ones that can be described by finite automata. We can say

that finite automata have a set of states and its Control moves from state to state inresponse to external inputs. One of the crucial distinctions among classes of finiteautomata is whether that control is deterministic, meaning that the automata cannot

be in more than one state at any one time, or nondeterministic, meaning that it maybe in several states at once. In effect, non-determinism allows us to program solutions

to problems using a Higher-Level language.

2.1. Why Finite Automata

Finite Automata are used as a model for:

a) Software for designing digital circuits.

b) Lexical analyzer of a compiler.

c) Searching for keywords in a file or on the web.

d) Software for verifying finite state system, such as communication protocols.

For example Finite Automaton modeling an ON/OFF switch

Figure 1: General finite automata machine example

2.2. Deterministic Finite Automata

The term Deterministic refers to the fact that on each input there is one and only onestate to which the automaton can transition from its current state. The term FiniteAutomata will refer to the Deterministic variety, although we shall useDeterministic or the abbreviation DFA normally. To remind the reader of whichkind of automaton we are talking about.


15/130

15 | P a g e

2.2.1. Definition of Deterministic Finite automata

A deterministic finite automaton consists of:

1. A finite set of state, often denoted Q.

2.A finite set of input symbols, often denoted .

3. A transition function that takes as arguments a set and an input symbol andreturns a state. The transition function will commonly be denoted . In ourinformal graph representation of automata, was represented by arcs between

states and the labels on the arcs Ifq is a state, and ais an input symbol, then (q, a) is that statep such that there is an arc labeled a from q.

4. A start state, one of the states in Q. 5. A set of final or accepting states F. The set F is a subset of Q.

In proofs we often talk about a DFA in Five - tuple notation:

A= (Q, , , q0, F)

Where:

A is the name of the DFA.

Q is the set of states.

is the input symbols. is the transition function.

q0 is the start state. F is the set of accepting states.

2.3. Nondeterministic Finite Automata

Nondeterministic finite automata (NFA) have the power to be in several states at once.

This ability is often expressed as an ability to guess something about its input.

Like the DFA, an NFA has a finite set of states, a finite set of input symbols, one start

state and a set of accepting states. It also has a transition function, which we shall

commonly call . The difference between the DFA and NFA is in the type of . Forthe NFA, is a function that takes a state and input symbol as argument like the

DFAs transition function, but returns a set of zero, one, or more states.

An NFA is represented essentially like a DFA: A= (Q, , , q0, F)

Where:

Q: A finite set of states.

: A finite set of input symbols.

: A transition function from Q x to the power set of Q.


16/130

16 | P a g e

q0: A member of Q, is the start state.

F: Subset of Q, is the set of final (or accepting) states.

2.4. Equivalence of Deterministic & Nondeterministic Finite

Automata

Although there are many languages for which an NFA is easier to construct than a

DFA, such as the language of strings that end 01 (that shown in Finite State Automata

Testing in chapter 2), it is a surprising fast that every language that can be described

by some NFA can also be described by some DFA. Moreover, the DFA in practice has

about as many states as the NFA, although it often has more transitions. In the worst

case, however, the smallest DFA can have 2nstate while the smallest NFA for the

same language has only n states.

2.5. Finite Automata with Epsilon-Transitions

We shall now introduce another extension of finite automaton. The new feature isthat we allow a transition on , the empty string. In effect, an NFA is allowed to makea transition spontaneously, with receiving an input symbol. This new capability gives

us some added Programming convenience.

2.5.1. Use of -Transitions

We shall begin with an informal treatment of -NFA, using transition diagrams with allowed as a label. In the examples to follow, think of the automaton as accepting

those sequences of labels along paths from the start state to an accepting state.

However, each along the path is invisible; it contributes nothing to the string alongthe path.

An -NFA accepting decimal numbers consisting of:

1. An optional + orsign.

2. A string of digits.

3. A decimal point.4. Another string of digits.

Of particular interest is the transition from q0 to q1 on any of, +, or -. Thus, state q1

represents the situation in which we have seen the sign if there is one, and perhaps

some digits, but not the decimal point. State q2 represents the situation where have just

seen the decimal point, and may or may not have seen prior digits. In q4 we have

definitely seen at least one digit, but not the decimal point. Thus, the interpretation of

q3 is that we have seen a decimal point and at least one digit, either before or after the

decimal point. We may stay at q3 reading whatever digits there are, and also have the


17/130

17 | P a g e

option of guessing the string of digits is complete and going spontaneously to q5, theaccepting state.

Figure 2: An -NFA accepting decimal number

2.5.2. The Formal Notation for an -NFA

We may represent an -NFA exactly as we do an NFA, with no exception: thetransition function must include information about transitions on . formally, werepresent an -NFA by: A= (Q, , , q0, F)

Where all components have their same interpretation as for an NFA, except that isnow a function that takes as arguments: A state in Q.

A member of U {}, that is, either an input symbol, or the symbol .

Example: The -NFA of previous figure is represented formally as:

E= ({q0, q1 q5}, {., +, -, 0, 1 9}, , q0, {q5})

Where is defined by the transition table:

Table 1: Transition Table for Figure 2

+, - .

0, ,9

q0 {q1} {q1} q1 {q2} {q1, q4}q2 {q3}q3 {q5} {q3}q4 {q3} q5


18/130

18 | P a g e

3. Finite State TransducerWhat are finite state transducers and why are they interesting? First what they are.Start from finite-state automata, and recall that they can be used either as recognizers

or generators. Its simply a matter of how we interpret what we do with the symbolson the transition arrows. If we read the symbols from an input tape, then ourFSA isan acceptor. Alternatively, if we run the machine non-deterministically, followingany legal path from state to state from an initial state to a final state, and output thesymbols that are on the transition arrows as we go, then ourFSAis a generator. Thesame machine can be used either way, and defines the same language in either case.

From these observations its a small step to a finite-state transducer: we put PAIRS of

symbols (or symbol strings) on our transition arrows, viewing one as input and theother as output. One can in principle allow triples and more, but well stick to oneswith pairs, and call the members of the pairs inputs and outputs. Which is up to us,

and in principle thats a free choice analogous to the choice of viewing a straightFSAas an acceptor or a generator? Well give the exact definition shortly.

3.1. What are Finite State Transducers?

A finite state transducer (FST) is a special type of finite state machine. Specifically, an

FST has two tapes, an input string and an output string. Rather than just traversing(and accepting or rejecting) an input string, an FST translates the contents of its input

string to its output string. Or put another way, it accepts a string on its input tape and

generates another string on its output tape.

3.2. Formal Construction

A finite state transducer is a finite state automaton in which the members of (thesymbols labeling the arcs) are pairs, triples, etc., rather than simple symbols.

Traditionally the members of S in a transducer are just pairs, of which the left-handmember is the input symbol and the right-hand member is the output symbol.

A deterministic finite state transducer (DFST) is defined as a septuple

(q0, Q, F, , , , )

Where:

q0 Q: The initial state. Q: A finite set of states.

F Q: The final states, a subset of Q.


19/130

19 | P a g e

: A finite set of input symbols (the input alphabet). : A finite set of output symbols (the output alphabet). : A function in Q Q: is the set of transitions, exactly as for a

deterministic FSA, mapping a pair of a state and an input symbol to a state.

: A function in Q : the transduction function (emission function),mapping a state and an input symbol to an output symbol.

Frequently the transition function and the transduction function are combined into a

single transition-transduction function, which may also be called d, in Q xQ, mapping a pair of a state and an input symbol onto a pair of a state and an output

symbol. A finite-state transducer is non-deterministic if either the transition mapping

or the transduction mapping fails to be a function, i.e. if there is more than one

possible transition or more than one possible output symbol for a given pair of a state

and an input symbol.

3.3. Ways of looking at a finite state transducers

1. We can think of the input symbols as appearing on one tape (usually called the

input tape) and the output symbols on another tape (usually called the output

tape.) In that case the transducer is in translating mode, from input tape tooutput tape, or from the first tape to the second tape. (For the first automatonabove, it translates ah to bh and ae to ce.)

2. Reverse translation: We can just as well use the same machine to translate fromthe second tape to the first. So the first machine in section 2 would then

translate bh to ah and ce to ae.

3. Generation mode. The transducer works like a finite state automaton run in

generation mode, but writes a pair of output strings rather than just one. (Our

automaton generates the pairs of output strings and .)

4. Acceptance mode. (Recognition mode). Both tapes are input tapes; the two

current input symbols have to match the two symbols on the transition arc in

order to make a transition. (Our automaton accepts the pairs of input strings

and .)

3.4. Cascading finite state transducers

A finite state transducer defines a regular relation. Cascading finite state transducerscorresponds to performing a composition of relations to produce a new relation. From

Karttunen (2001):

As is well-known, phonological rewrite rules and two-level constraints can be

implemented as finite-state transducers (Johnson 1972, Kaplan and Kay 1981,Karttunen 1987). The application of a system of rewrite rules to an input string can be


20/130

20 | P a g e

modeled as a cascade of transductions, that is, a sequence of compositions that yields

a relation mapping the input string to one or more surface realizations.

3.5. Closure properties for regular relations

Regular relations, like regular expressions, are closed under

1. Union

2. Concatenation

3. Iteration A+ (one or more concatenations of members of A)

4. Kleene star A* (union of empty string or relation and A+)

5. Optionality (A) : union of A with the empty string or empty relation

Regular relations, unlike regular expressions, are not in general closed under

Complement

Intersection

Regular relations are closed under composition A B

3.6. Finite State Automata in action

FSTs are particularly useful in the implementation of certain natural language

processing tasks. Context-sensitive rewriting rules (ex: ax bx) are adequate for

implementing certain computational linguistic tasks such as morphological stemmingand part-of-speech tagging. Such rewrite rules are also computationally equivalent to

finite-state transducers, providing a unique path for optimizing rule based systems.

Example: the following set of ordered context-sensitive rules:

1. change c to b if followed by x:cx bx2. change a to b ifprecededby rs:rsa rsb3. change b to a ifprecededby rs and followed by xy: rsbxy rsaxy

The time required to apply a sequence of context-sensitive rules is dependent upon the

number of rules, the size of the context window, and the number of characters in the

input string. The inefficiencies in such an implementation are highlighted in this

example by the multi-step transformation required to translate c to b then b to aby rules 1 and 3, and the redundant transformation of a to b and back to a byrules 2 and 3. Finite State Transducers provide a path to eliminate these inefficiencies.

But first we need to convert the rules to State Machines.


21/130

21 | P a g e

3.6.1.Converting Rules to FSTsTo do this, we simple represent each rule as an FST where each link between states

represent the acceptance of an input character and the expression of the corresponding

output character. This input / output combination is denoted within an FST by labeling

edges with both the input and output character separated by the / character.Following is an FST for each of the above rules.

Figure 3: Finite State Automata for rules of the previous example

4. Pushdown AutomataPush down automata is essentially an -NFA with the addition of a stack. The stackcan be read, pushed, and popped only at the top, just like the Stack data structure. Inthis section, we define two different versions of the pushdown automaton: One that

accepts by entering an accepting state, like finite automata do, and another versionthat accepts by emptying its stack, regardless of the state it is in. We show that these

two variations accept exactly the context-free languages; that is, grammars can be

converted to equivalent pushdown automata and vice-versa. We also consider briefly

the subclass of pushdown automata that is deterministic.

4.1. Definition of the pushdown automata

In this section we introduce the pushdown automata, first informally, then as a formal

construct.


22/130

22 | P a g e

4.1.1. Informal Introduction

The pushdown automaton is in essence a nondeterministic finite automaton with -transitions permitted and one additional capability: a stack on which it can store a

string of Stack Symbols The presence of a stack means that, unlike the finite

automaton, the pushdown automaton can remember an infinite amount ofinformation. The pushdown automaton can only access the information on its stack in

a: (Last In - First Out) way.

Figure 4: Pushdown Automaton is essentially a finite state automaton with a stack data structure

A Finite State Control reads inputs, one symbol at a time. The push downautomaton is allowed to observe the symbol at the top of the stack and to base its

transition on its current state, the input symbol, and the symbol at the top of stack.

Alternatively, it may make a spontaneous transition, using as its input instead ofan input symbol. On a transition the PDA:

Consumes an input symbol.

Goes to a new state (or stays in the old).

Replaces the top of the stack by any string. (Does nothing, pops the stack, or

pushes a string onto the stack).

4.1.2. The Formal Definition of push down automata

Our formal notation for a push down automata (PDA) involves seven components: P=

(Q, , ,, q0, Z0, F).

Where:

Q is a finite set of state.

is a finite input alphabet. is a finite stack alphabet.


23/130

23 | P a g e

: Q x U {} * 2Q** is the transition function. Z0 is the start symbol for the stack. q0 is the start state.

F Q is the set of accepting states.

4.1.3. Instantaneous Descriptions of PDA

A PDA goes from configuration to configuration when consuming input. To reason

about PDA computation, we use instantaneous descriptions of the PDA. An ID is

triple (q, w, )

Where:

q is the state.

w is the remaining input.

is the stack contents.

Let P= (Q, , , , q0, Z0, F) be a PDA, Then V w *, *:

(P, ) (q, a, x) (q, aw, x) (P, w , ).We define * to be the reflexive-transitive closure of .

4.2. The Language of a PDA

We have assumed that a PDA accepts its input by consuming it and entering an

accepting state. We call this approach acceptance by final state There is a secondapproach to defining the language of a PDA that has important applications. We may

also define for any PDA the language Accepted by empty stack, that is, the set ofstrings that cause the PDA to empty its stack. String from the initial ID.

4.2.1. Acceptance by Final State

Let P= (Q, , ,, q0, Z0, F) be a PDA. The language accepted by P by final state is:

L (P) = {w: (q0, w, Z0) * (q, , ), q F}.

4.2.2. Acceptance by Empty Stack

Let P = (Q, , ,, q0, Z0, F) be a PDA. The language accepted by P by empty stackis: N (P) = {w: (q0, w, Z0) * (q, , )}.

Note: q can be any state.

4.3. Equivalence of PDAs and CFGs

Now, we shall demonstrate that the language defined by PDAs are exactly the

context-free language. The goal is to prove that the following three classes oflanguage:


24/130

24 | P a g e

1. The Context-Free Languages, i.e., the languages defined by CFGs.2. The languages that are accepted by final state by some PDA.

3. The languages that are accepted by empty stack by some PDA.

Are all the same class. We have already shown that (2) and (3) are the same. It turns

out to be easiest next to show that (1) and (3) are the same, thus implying the

equivalence of all three.

Figure 5: Organization of constructions showing equivalence of three ways of defining the CFLs

4.3.1. From Grammars to Pushdown Automata

The idea behind the construction of a PDA from a grammar is to have the PDA

simulate the sequence of left. Sentential forms that the grammar uses to generate a

given terminal string w. The tail of each sentential from xAx appears on the stack,with A at the top.

Example: Let us convert the expression grammar to a PDA recall this grammar is:

I a | b | Ia | Ib | I0 | I1|

E I | E * E | E + E | (E)

The set of input symbols for the PDA is {a, b, 0, 1, (,), +, *}. These eight symbols and

the symbols I and E form the stack alphabet. The transition function for the PDA is:

a. (q, , I) = {(q, a), (q, b), (q, Ib), (q, I0), (q, I1)}.b. (q, , E) = {(q, I), (q, E + E), (q, E * E), (q, (E))}.c. (q, a, a) = {(q, )}; (q, b, b) = {(q, )}; (q, 0, 0) = {(q, )}; (q, 1, 1) = {(q,

)}; (q, (, ( ) = {(q, )}; (q, ), ) ) = {(q, )}; (q, +, +) = {(q, )}; (q, *, *) ={(q, )}.

Note that (a) and (b) come from rule (1), while the eight transitions of (c) come from

rule (2). Also, is empty except as defined by (a) through (c).


25/130

25 | P a g e

5. Turing MachinesIn this section we change our direction significantly. Until now, we have beeninterested primarily in simple classes constrained problems, such as analyzing

protocols, searching text, or parsing programs. Now, we shall start looking at the

question of what language can be defined by any computational device whatsoever.

This question is tantamount to the question of language is a formal way of expressing

any problem, and solving a problem is area son able surrogate for what it is that

computer do.

We begin within an informal argument, using an assumed knowledge of C

programming, to show that there are specific problems we cannot solve using a

computer. These problems are called Undecidable. We then introduce a venerableformalism for computers, called the Turing Machine. While a truing machine looks

nothing like a PC, and would be grossly inefficient should some startup company

decide to manufacture and sell them, the Turing machine long has been recognized as

an accurate model for what any physical computing device is capable of doing.

5.1. The Turing Machine

The purpose of the theory of undecidable problems is not to establish the existence of

such problems an intellectually exciting idea in its own right but to provide guidance

to programmers about what they might or might not be able to accomplish through

programming. Theory also has great pragmatic impact when we discuss, problems that

although decidable, require large amounts of time to solve them. These problems,

called intractable problems tend to present greater difficulty to the programmer andsystem designer than do thee undecidable problems are usually quit obviously so, and

their solutions are rarely attempted in practice, the intractable problems are faced

every day.

5.1.1. Notation for the Turing Machine

We may visualize a Turing Machines as in the following figure, the machine consists

a finite controls which can be in any of finite set of states. There is a tape divided into

squares or cells each can hold any one of finite number of symbols.


26/130

26 | P a g e

Figure 6: Turing Machine Architecture

Initially, the input which is a finite-length string of symbols closen from the input

alphabet is placed on the tape. All other tape cells, extending infinitely to the left andright, initially hold a special symbol called the blank is a tape symbol, but not an input

symbol and there may be other tape symbols besides the input symbols and the blank,

as well. There is a tape head that is always positioned at one of the tape cells. The

Turing machine is said to be scanning that cell. Initially, the tape head is at the

leftmost cell that holds the input. A more of the Turing machine is a function of the

state of the finite control and the tape symbol scanned. In one more, the Truing

machine will: Change state. The next state optionally may be the same as the current

state.

Write a tape symbol in the cell scanned. This tape symbol replaces whatever symbol

was in that cell. Optionally, the symbol written may be the same as the symbol

currently there.

Move the tape head left or right. In our formalism we require a move, and do not

allow the head to remain machine stationary. This restriction does not constrain what a

Truing machine can computer. Since any sequence of moves with a stationary head

could be condensed, along with the next tape-head move, into a single state change, a

new tape symbol, and a move left or right.

The formal notation we shall use for a Turing machine (TM) is similar to that used for

finite automata or PDAs. We describe a TM by the 7.tuple

M= (Q, ,,, q0, B, F)

Whose components have the following meanings:

Q: The finite set of states of the finite control.

: The finite set of input symbols.

: The complete set of tape symbols; is always a subset of .


27/130

27 | P a g e

: The transition function. The arguments of (q, X) are a state q and a tapesymbol X. The value of(q, X), if it is defined, is a triple (p, , D), where:

P is the next state, in Q.

is the symbol, in , written in the cell being scanning replacing whateversymbol was there.

D is a direction, either L or R, standing for left or right respectively, andtelling us the direction in which the head moves.

q0: The start state, a member of Q, in which the finite control is found initially.

B: The blank symbol. This symbol is in but not in ; i.e. it is not an inputsymbol. The blank appears initially in all but the finite number of initial cells

that hold input symbols.

F: The set of final or accepting states, a subset of Q.

5.1.2. Transition Diagrams for Turing Machines

We can represent the transitions of a Truing machine pictorially, much as we did for

the PDA. A transition diagram consists of a set of nodes corresponding to the states of

the form X/Y D, Where X and Y are tape symbols, and D is a direction, either L or R.

That is, whenever (q, X) = (P, Y, D), we find the label X/Y D on the are from a top.However, in our diagrams, the direction D is represented pictorially by for leftand for right.

As for other kinds of transition diagrams, we represent the start state by the word

Start and an arrow entering that state Accepting state are indicated by doublecircles. Thus, the only information about the TM one cannot read directly from the

diagrams is the symbol used for the blank. We shall assume that symbol is B unless

we state otherwise.

5.2. Programming Techniques for Turing Machines

Our goal is to give you a sense of how a Turing machine can be used to compute in a

manner not unlike that of a conventional computer. Eventually, we want to convince

you that a TM is exactly as powerful as a conventional computer. In particular, weshall learn that the Turing machine that we saw performed.

To make the ability of TM clearer, we shall present a number of examples of how we

might think of the tape and finite control of the Turing machine.

5.2.1. Storage in the State

We can use the finite control not only to represent a position in the Program of theTuring ma=chine, but to hold a finite amount of data. The following figure suggests

this technique. There, we see the finite control consisting of not only a Control stateq, but three data elements A, B and C. The technique requires an extension to the TM


28/130

28 | P a g e

model; we merely think of the state as a tuple. In the case of the following figure; we

should think of the state as {q, A, B , C}. Regarding states this way allows us to

describe transitions in a more systematic way, often making the strategy behind the

TM program more transparent.

Figure 7: A TM viewed as having finite-control storage and multiple tracks.

5.2.2. Multiple Tracks

Anotheruseful trick is to think of the tape of a Turing machine as composed ofseveral tracks. Each track can hold one symbol, and the tape alphabet of the TM

consists of tuple, with one component for each track Thus, for instance, the cellscanned by the tape head in the previous figure contains the symbol [X, Y, Z]. Like

the technique of storage in finite control, using multiple tracks does not extend what

the Turing machine can do. It is simply a way to view tape symbols and to imagine

that they have a useful structure.

5.2.3. Subroutines

As with programs in general, it helps to think of Turing machine as built from a

collection of interaction component, or subroutines. A Turing machine subroutine isa set of states that perform some useful process. This set of states includes a start state

and another state that temporarily has no moves, and that serves as the return stateto pass control to whatever other set of states called the subroutine.

6. Context Free GrammarWe now turn our attention away from the regular languages to a larger class oflanguages, called the Context- Free Grammar. These languages have a natural,

recursive notation, called context-free grammars. Context-Free Grammars haveplayed central role in compiler technology since the 1960s. More recently, the


29/130

29 | P a g e

context free grammar has been used to describe document formats, via the so-called

document-type definition (DTD) that use in the XML (eXtensible Markup Language)

community for information exchange on the web. In this section, we introduce the

contextfree grammar notation, and show how grammars define languages. We

discuss the parse Tree picture of the structure that a grammar places on the string ofits language.

6.1. Context Free Grammars

We shall begin by introduce the context free grammar notation informally. After

seeing some of the important capabilities of these grammars, we after formal

definitions. We show how to define a grammar formally, and introduce the process of

derivation whereby it is determined which strings are in the language of the

grammar.

6.1.1. An Informal Example

Let us consider the language of palindromes. A palindrome is a string that reads the

same forward and backward, such as otto or madamimadam (madam, Im Adam),allegedly the first thing ever heard of the garden of Eden, but another way, string w is

a palindrome if and only if w=wR . To make things simple, we shall consider

describing only the palindromes with alphabet {0, 1}. This language include is string

like 0110, 11011, and , but not 011 or 0101.

6.1.2. Definition of Context-Free Grammars

There are four important components in a grammatical description of language.

1. There is a finite set of symbols that form the string of the language begin

defined. This set was {0, 1} in the palindrome example we just saw. We call

this alphabet the terminal, or terminal symbols.

2. There is a finite set of variables, also called sometimes nonterminals or

syntactic categories. Each variable represents a language, a set of string. Our

example, above, there was only one variable, P, which we used to represent the

class of palindromes over alphabet {0, 1}.

3. One of the variables represents the language being defined; it is called the start

symbol. Other variables represent auxiliary classes of string that are used to

help define the language of the start symbol. In our example, P the only

variable is the start symbol.

4. There is a finite set of productions or rules that represent the recursive

definition of a language. Each production consists of :

a. A variable that is being (partially) defined by the production. This

variable is often called the head of the production.b. The production symbol .


30/130

30 | P a g e

c. A string of zero or more terminals and variable. This string called the

body of the production represents one way to form strings in the

language of variable of the head. IN so doing we leave terminals

unchanged and substitute for each variable of the body any string that is

known to be in the language of that variable.

The four components just described form a context-free grammar, or just grammar, or

CFG. We shall represent a CFG G by its four components, that is; G= (V, T, P, S).

Where:

V is the set of variables.

T the terminals.

P the set of productions.

S the start symbol.

6.1.3. Derivations Using a Grammar

The process of deriving string S by applying productions from head to body requires

the definition of a new relation

Symbol Suppose. G = (V, T, P, S) is a CFG.

Notice that one derivation step replaces any variable anywhere in the string by the

body of one of its productions. We may extend the relationship to represent zero,one or many derivation steps, much as the transition function of a finite automatonwas extended to . For derivations, we use a * to denote zero or more steps.

6.1.4. Left most and Right most Derivations

In order to restrict the number of choices we have in deriving a string, it is often useful

to require that at each step we replace the leftmost variable by one of its production

bodies. Such a derivation is called a leftmost derivation, and we indicate that a

derivation is leftmost by using the relations lm and*lm, for one or may steps,

respectively. If the grammar G that is being used is not obvious, we can place the

name G below the arrow in either of these symbols. Similarly, it is possible to require

that at each step the rightmost variable is replaced by one of its bodies. If so, we call

the derivation rightmost and use the symbols rm and*rm to indicate one or many

rightmost derivation steps, respectively. Again, the most name of the grammar may

appear below these symbols if it is not clear which grammar is being used.

6.2. Parse Trees

In this section, we introduce the parse tree and show that existence of parse trees is

tied closely to the closely to the existence of derivation and recursive inferences.


31/130

31 | P a g e

6.2.1. Constructing Parse Trees

Let us fix on a grammar G= (V, T, P, S). The parse trees for G are trees with the

following conditions:

1. Each interior node is labeled by a variable in V.

2. Each leaf is labeled by eithera variable, a terminal, or . However, if the leaf islabeled . Then it must be the only child of its parent.

3. If an interior node is labeled A, and its children are labeled X 1, X2, ..., Xk

Respectively, from the left, then A X1, X2, ..., Xk is a production in P.

6.3. Ambiguity in Grammars and Languages

When a grammar fails to provides unique structures, it is sometimes possible to

redesign the grammar to make the structure unique for each string in the language.

Unfortunately, sometimes we cant do so. That I, there are some CFLs that areinherently ambiguous; every grammar for the language puts more than one structureon some strings in the language.

6.3.1. Ambiguous Grammars.

Let us consider a grammar example. This grammar lets us generate expressions with

any sequence of * and + operators, and the productions E E + E | E * E allow us togenerate these expressions in any order we choose.

6.3.2. Removing ambiguity from grammars Good news: Sometimes we can remove ambiguity by hand Bad news: There is no algorithm to do it.

More bad news: Some CFLs ha e only ambiguous CFGs we are studying thegrammar.

1. E I | E + E | E * E | (E)2. I a | b | Ia | Ib | I0| I1

There are two problems:

1. There is no precedence between * and +.

2. There is no grouping of sequences of operators, i.e. is E + E + E mend to be E

+ (E + E) or (E+E)+E.

Solution: We introduce more variables. Each representing expressions of same

binding strength

A factor is an expression that cannot be broken apart by an adjacent * or +. Our

factors are:

Identifiers


32/130

32 | P a g e

A parenthesized expression.

A term is an expression that cannot be broken by +. For instance a*b can be

broken by a1* or *a1 is (by precedence rules) same as a1+ (a * b), and a*b + a1

is same as (a*b) +a1.

The rest are expressions, i.e. they can be broken apart with * or +. Well let Fstand form Factors, T for Terms, and E for expressions. Consider the following

grammar:

I a | b | Ia | Ib | I0 | I1. F I | (E). T F | T * F. E T | E + T.

Now the only parse tree for a + a * a will be

Figure 8: Parse Tree for the given grammar


33/130

33 | P a g e

[Chapter 2] System

Development Life

Cycle (SDLC)

n this chapter we will use the software engineering concepts and methodology to implement our system. We

will describe each phase of system development life cycle in one section and provide it with figures and

iagrams.

Chapters Sections:

Applied Methodology

Requirements

System Analysis and Design

Implementation

Deployment and Testing


34/130

34 | P a g e

1.Applied MethodologyThe field of software development is not shy of introducing new methodologies.

Indeed, in the last 25 years, a large number of different approaches to softwaredevelopment have been introduced, of which only few have survived to be used today.

A recent study argues that traditional information system (IS) development

methodologies are treated primarily as a necessary fiction to present an image ofcontrol or to provide a symbolic status. The same study further claims that thesemethodologies are too mechanistic to be used in detail. It made similar arguments

early on. Another study take an extreme position and state that it is possible that

traditional methods are merely unattainable ideals and hypothetical straw men thatprovide normative guidance to utopian development situations. As a result, industrial

software developers have become skeptical about new solutions that are difficult tograsp and thus remain not used. This is the background for the emergence of agile

software development methods.

1.1. IntroductionAgility refers to the quality of being agile. Internet software industry and Mobile and

wireless application development industry are looking for a very good approach of

software development. Conventional software development methods have completely

closed the requirements process before analysis and design process. As this approachis not always feasible and compatible with all other projects. In contrast to the

conventional approaches, Agile methods allow developers to make late changes in the

requirement specification document. The focus of the agile software development as

given by Agile Software Development Manifesto is presented in the following:

Individuals and interactions over processes and tools

Working software over comprehensive documentation.

Customer collaboration over contract negotiation

Responding to change over following a plan

1. There is vital importance of communication between the individual who are in

development team, since development centers are located at different places. The

necessity of interaction between Individuals over different tools and different

versions and processes is very vital.

2. The only objective of software development team is to continuously deliver the

working software for the customers. New releases must be produced for frequent

intervals. The developers try to keep the code simple, straight forward and

technically as advanced as possible and will try to lessen the documentation.


35/130

35 | P a g e

3. The relationship between developers and the stakeholders is most important as the

pace and the size of the project grows. The cooperation and negotiation between

clients and the developers is the key for the relationship. Agile methods are using

in maintaining good relationship with clients.

4. The development team should be well-informed and authorized to consider thepossible adjustments and enhancements emerging during the development process.

1.2. Agile MethodsAgile methods are designed to produce the first delivery in weeks, to achieve and

early win and rapid feedback. These methods invent simple answers so that change

can be less. This also improves design issues and quality as they are based on

iteratively incremental method.

What makes a method an Agile?

When the process is:

1. Incremental: Small releases with rapid iterations

2. Cooperative: Customer and developer relationships

3. Straight: The method which is easy to learn and modify with documentation

4. Adaptive: Able to embrace changes instantly

Software development which can be delivered fast, quick adaptation to requirements

and collecting feedback on required information. The agile software methods and

development is practices based approach empowered with values, principles and

practices which make the software development process easier and in faster time.

Agile methods which encompasses individual methods like Extreme programming,

Feature Driven Development, Scrum, etc are more coming into the commercial and

academic worlds.


36/130

36 | P a g e

Figure 9: Agile Methodology

2.RequirementsDeclarative Programming Tools for Computer Science Engineering

Software Requirements Specification

Version 0.1 - 2013


Software Engineering Student

Prepared for

Declarative Programming Tools - Software Engineering / Senior Project

Supervisor: Dr. Adnan Ali

August 2013


37/130

37 | P a g e

2.1. IntroductionSoftware engineering depending on multiple criteria in order to produce useful

applications. Collecting requirements is main step in software production in order to

organize the data flow and the user, system interaction.

2.1.1.PurposeIn this document SRS (Software Requirement Specification) we will describe all the

information needed to implement our system provided with figures and diagrams. In

general following such documents is the engineering way to work. It looks like a road

map walking through the specification and data to finally get the desired product.

2.1.2.ScopeDeclarative Programming Tools which are:

Finite State Automata.

Epsilon Finite State Automata.

Finite State Transducer.

Push Down Automata.

Turing Machines.

Context Free Grammar.

Means a collection of tools packed in one system allow the users to make some

declaration (Entering some data) with very easy tools to finally get the desiredmodels code. The generated code can be run and tested using Prolog environment.The given models will develop to be used in the same style.

2.2. Specific RequirementsIn our system approach we consider that the benefit of Formal Methods in themathematically concepts need to transformed to computing problems in which it will

be more useful and more clearly and fast implementation. To do this job we need to

know some concepts and articles. Our system takes about seven models and tries totreat it in the same way in which the user can deal with them all as one model. The

main idea was to give the user the ability to enter the data needed in a simple way and

provide a mechanism to visualize these data, then he can get the result he want

without writing any code, so we can consider the user as a programmer for such

models in a declarative manner. We can list the job or goal of our system in the

following list:

1. The user can enter the system in an interactive manner in which the system

displays its functionality and services to allow the user use it.


38/130

38 | P a g e

2. The user can select a model to make a new project, so the system display the

provided model in a list and allows the user to select one option and start his

new project.

3. The system initializes the environment for the new project.

4. The system allows the user to save his work in the created projects directorywith other helped file. And give the user the ability to load this project later.

5. The system allows the user to make a new paper or lecture from a saved model

and give him the full control over this document.

6. The system allows the user to make a whole bunch of different management

choices or customize the work in other word.

With this general introduction it provided us with the systems general idea. Of courselater in the Analysis and Design section we will detailed this concepts and we will

extends our discussion. The best way to represents the system any system by the wayis using the Use Case diagram.

2.2.1.Use Case Diagram:A use case diagram at its simplest is a representation of a user's interaction with the

system and depicting the specifications of ause case. A use case diagram can portray

the different types of users of a system and the various ways that they interact with the

system. This type of diagram is typically used in conjunction with the textualuse

caseand will often be accompanied by other types of diagrams as well.

Due to their simplistic nature, use case diagrams can be a good communication tool

for stakeholder. The drawings attempt to mimic the real world and provide a view for

the stakeholders to understand how the system is going to be designed.

We should take care of some concepts when using Use Case diagram:

1. Always structure and organize the use case diagram from the perspective of the

actor.

2. Use cases should start off simple and at the highest view possible. Only then

can they be refined and detailed further.

3. Use case diagrams are based upon functionality and thus should focus on the

"what" and not the "how".
http://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Use_Case


39/130

39 | P a g e

Figure 10: Use Case Diagram


40/130

40 | P a g e

There are two use cases:

1. Transition Table

2. Visual Graph

These use cases are the user interfaces that the user interact with to define his model,

The Transition Table is a simple table to interact with, and it convert to the second use

case Visual Graph which also can be converted to the corresponding Transition Table.

Each use case diagram need to be organized which mean more details and description

this process called Use Case Refinement, where we can take the use cases each alone

and describe it. Here is the refinement of some use cases, and we should know that the

flow of the provided model is made similar.

F in ite State Automata Use Case:

1. Name: Finite State Automata.

Brief specification: The system allows the user to create a new Finite State Automata

Model project and manipulate the transitions input, visualize and testing for the output

program.

2. Actors: User or Student.

3. Precondition: No precondition here just creates a new project from the

Management Panel Use Case.4. Main Flow:

a. The system presents the provided models.

b. The Actor selects the suitable project.

c. The Finite State Automata Frame appears with the Transition Table for inputs

and Graph canvas for visualization.

d. Save the inputs (as prolog .pl)

e. Test and ability to redefine the inputs is possible here.

5. Conflicts or Errors may happens:a. Asynchronous between Transition Table and Graph that means: if the user

made some changes to the graph and didnt reflect it to the transition table orvice versa.

b. If the user runs the project without save it, he will get an empty program (no

code), and then no testing is available.

Transition Table Use Case:

6. Name: Transition Table.


41/130

41 | P a g e

Brief specification: After the user select a model to work with the system presents to

him a window contains a table to enter some data which represents the declaration

process in the system. The table provided with some functionality makes the work

easy.

7. Actors: User or Student.

8. Precondition: A new project from the provided models should be created to

customize the table according to this model.

9. Main Flow:

f. The system presents the Transitions Table inside the Main Model Window.

g. The Actor starts to entering or declaring data inside this table.

h. The system maintains a collection of data from this table to process and

generating the desired code.

i. The data converted to a visual graph to more understanding.j. The user saved the work and at this point he able to make tests.

10.Conflicts or Errors may happens:c. The user may enter data and miss some other; the visual graph gives him the

visual showing to more understanding and round this conflict.

d. Asynchronous between Transition Table and Graph that means: if the user

made some changes to the graph and didnt reflect it to the transition table orvice versa.

Lecture Use Case:

1. Name: Lecture.2. Brief specification: The system allows the user to create a new lecture from a

previous saved model files. Then the user can use this lecture in education

process or learning process.

3. Actors: User or Student.4. Precondition: The user should has a file that contains a data for a model, then

he can use this file to create the desired lecture.

5. Main Flow:a. The system presents the frame in which the user can manage the lectureand ask the user to specify a file path.

b. The Actor browses the file path.

c. The system analysis the file and create the suitable data such as transition

functions, set of states and a set of final or accept states and graph to this

model.

d. The system allows the user to add articles to this lecture and modify the

presented data as the need.

e. The system allows the user to print out this lecture to usage.


42/130

42 | P a g e

6. Conflicts or Errors may happens:a. The use may select a file that contains invalid data or corrupted file then he

cant see what he want.

3.System Analysis andDesign

3.1. Defining a SystemA system is a collection of components that work together to realize some objectives

forms a system. Basically there are three major components in every system, namelyinput, processing and output.

Figure 11: System General Definition

In a system the different components are connected with each other and they are

interdependent. For example, human body represents a complete natural system. We

are also bound by many national systems such as political system, economic system,

educational system and so forth. The objective of the system demands that some

output is produced as a result of processing the suitable inputs. A well-designed

system also includes an additional element referred to as control that provides afeedback to achieve desired objectives of the system.

3.2. System Life CycleSystem life cycle is an organizational process of developing and maintaining systems.

It helps in establishing a system project plan, because it gives overall list of processes

and sub-processes required for developing a system. System development life cycle

means combination of various activities. In other words we can say that various

activities put together are referred as system development life cycle. In the System

Analysis and Design terminology, the system development life cycle also means

software development life cycle.


43/130

43 | P a g e

Following are the different phases of system development life cycle:

Preliminary study

Feasibility study

Detailed system study System analysis

System design

Coding

Testing

Implementation

Maintenance

The different phases of system development life cycle are shown in the figure below:

Figure 12: Phases of System Development Life Cycle

3.3. Phases of System Development Life CycleLet us now describe the different phases and related activities of system development

life cycle in short definitions to take a view over what we will describe later and what

we described previously.

1.Preliminary System StudyPreliminary system study is the first stage of system development life cycle. This is a

brief investigation of the system under consideration and gives a clear picture of what

actually the physical system is? In practice, the initial system study involves the

preparation of a System Proposal which lists the Problem Definition, Objectives of


44/130

44 | P a g e

the Study, Terms of reference for Study, Constraints, Expected benefits of the new

system, etc. We saw this in the Introduction section.

2.Feasibility StudyIn case the system proposal is acceptable to the management, the next phase is to

examine the feasibility of the system. The feasibility study is basically the test of the

proposed system in the light of its workability, meeting users requirements. We sawthis in the Requirements section.

3.Detailed System StudyThe detailed investigation of the system is carried out in accordance with the

objectives of the proposed system. This involves detailed study of various operations

performed by a system and their relationships within and outside the system. During

this process, data are collected on the available files, decision points and transactions

handled by the present system. Interviews, on-site observation and questionnaire are

the tools used for detailed system study. Using the following steps it becomes easy to

draw the exact boundary of the new system under consideration:

Keeping in view the problems and new requirements.

Workout the pros and cons including new areas of the system.

4.System AnalysisSystems analysis is a process of collecting factual data, understand the processes

involved, identifying problems and recommending feasible suggestions for improving

the system functioning. This involves studying the business processes, gathering

operational data, understand the information flow. The major objectives of systems

analysis are to find answers for each business process:

What is being done?

How is it being done?

Who is doing it?

When is he doing it?

Why is it being done?

How can it be improved?

Systems analysis is an iterative process that continues until a preferred and acceptable

solution emerges.

4.1. Models Input Output OverviewAs we talk previously in our vision the models of the system should be work the same,

and the best way to collect data is the tables. Tables really is a good data entering tool,

each model has its own data types and forms. Now we will take a near look at thesetables and how we think it should be. This abstract view gives us a general


45/130

45 | P a g e

representation of what we should have to implement our models. In the flowing we

will list the inputoutput models for our models showing the main differencesbetween these models will be trivial. We starting with transition table view to show

the form of data then we will show the relationship between the transition table and

the transition graph.

4.1.1.Finite State Automata Input Output ModelThe Finite State Automatas transition table will be similar to the following table:

Table 2: Finite State Automata Input Frame

NO Source State Target State Input Symbol

1 String String String or Symbol

2 String String String or Symbol

... ... ... ...

Table components:

1. NO: It is normally a serial number for transitions.

2. Source State: It is a representation of the state that the transition starts from.

3. Target State: It is a representation of the state the transition goes to.

4. Input Symbol: It is a Symbol or String that represent the action that makes the

transition.

Here we need to mention that the state has a type which is one of the following:

1. Start State

2. Fix State

3. Accept State

4. Start Accept State

The demonstration of these types will be shown in the system design section, we will

see that each state provided with image describing the type.

This table will give us the ability to enter our data that we need for this model, this

data should be take out and processed to get the desired result in specific word to get

that prolog (logic programming) code that can run this data and test it.


46/130

46 | P a g e

Figure 13: Model General Input/Output View

Form this view we can see there is two files (file or arcs) and (file of situation) these

files consist our models and be combine them we get the desired declarative

programming goal.

What is so important in this process is the graph representation of these table entries.

The transition graph in specific word is a very important component in this model and

other models, it gives a clearly view to the actual data we provided, so let us take a

look to the relationship between this graph and our input table:

Figure 14: Relationship between Input Table and Visual graph


47/130

47 | P a g e

From this view it gives us more ideas for the models. In which we need to represent

our data in a transition graph the question was why we cant form our data or fill theinput table from the transition graph? The answer came there is no problem to do such

problem in which it will give the user more easily working and using. Later in this

chapter in System Design section we will go through more details about this view andhow it designed.

4.1.2.Finite State Transducer Input Output ModelThe Finite State Transducers transition table will be similar to the following table:

Table 3: Finite State Transducer Input Frame

NO Source State Target State Input Symbol Output Symbol

1 String String String or Symbol String or Symbol

2 String String String or Symbol String or Symbol... ... ... ... ...

Table components:





transition.

5. Output Symbol: It is a Symbol or String that represents the output results from

the transition movement.

The way to compose the model from the generated arcs and prolog interpreter and the

relationship between the transition tables with the transition graph is the same in the

Finite State automata model and it will be so for the other models.

4.1.3.Pushdown Automata Input Output ModelThepushdown automatas transition table will be similar to the following table:

Table 4: Pushdown Automata Input Frame

NO Source State Target State Input Symbol Top of Stack New Top of Stack

1 String String String or Symbol String or Symbol String or Symbol

2 String String String or Symbol String or Symbol String or Symbol

... ... ... ... ... ...

Table components:


48/130

48 | P a g e





transition.5. Top of Stack: It is a Symbol or String that represents the current value of the

stack

6. New Top of Stack: It is a Symbol or String that represents the new value of the

stack (top of stack) after the operation applied.

4.1.4.Turing Machines Input Output ModelThe Turing Machines transition table will be similar to the following table:

Table 5: Turing Machines Input Frame

NO Source State Target State Input Symbol Output Symbol Direction

1 String String String or Symbol String or Symbol LeftRightStay

2 String String String or Symbol String or Symbol L, RorS

... ... ...

Declarative Programming Tools for Computer Sience Engineering

Documents

Transcript of Declarative Programming Tools for Computer Sience Engineering