-
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
2/130
2 | P a g e
Yarmouk Private University
[System Specification Document]
Declarative Programming Tools for Computer Science Engineering
By
Tareq Jehad AlJebawi
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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:
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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).
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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 .
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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 .
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
Tareq Jehad AlJebawi
Software Engineering Student
Prepared for
Declarative Programming Tools - Software Engineering / Senior Project
Supervisor: Dr. Adnan Ali
August 2013
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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 -
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
39/130
39 | P a g e
Figure 10: Use Case Diagram
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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.
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
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:
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.
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:
-
7/29/2019 Declarative Programming Tools for Computer Sience Engineering
48/130
48 | P a g e
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.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
... ... ...