Liberate computer user from programming - Mathematical Sciences ...

Liberate computer user from programming Teodor Rus [email protected]

The University of Iowa, Department of Computer Science

Liberate computer use from programming – p.1/60

Computers A computer (C) is a composed mechanism C = hP rocessor, M emory, I/Odevicesi where: 1. Memory is an electronic device that can store encoded information representing operations and data. 2. Processor is an electronic device that executes operations stored in memory. It has a register called program counter (PC) and performs the loop: while (PC.opcode is not halt) Execute (PC); PC := Next(PC);

3. I/O devices allow one to store and retrieve information in/from computer memory


Formal expression beginSpec name ComputerSystem is sort Memory, Processor, Devices, Control; opns receive:Device x Control -> Memory, transmit:Memory x Control -> Device, store:Processor x Control -> Memory, fetch:Memory x Control -> Processor, process:Memory x Processor x Control -> Processor, Memory x Processor x Control -> Memory, Processor x Control -> Processor; vars PC: Control; axms Value(PC.operation) in {receive,transmit,store,fetch,process}; actn Run:: while PluggedIn and PowerOn do l_0: Perform (PC); PC := Next(PC) :ˆl_0 endSpec


Problem solving To solve a problems with a computer we need to: 1. Develop an algorithm that solves the problem. 2. Represent the algorithm using the machine-language of the computer. This representation was called a program. 3. Use an input device to load the program in computer memory. 4. Activate the machine by loading the PC register with the memory address of the program start instruction. 5. Use an output device to retrieve the result generated by program.


Computer programming •

Programs are machine-language representations of algorithms to be performed by a computer.

•

Computer programming is the activity of mapping algorithms into programs.


Facts • Fact 1: algorithms are developed using human-logic and are expressed using the natural language of the problem domain. • Fact 2: programs are developed using machine-logic and are expressed using the artificial (binary) language of the machine. • Fact 3: Programming is tedious, error prone, and requires professional knowledge of both problem domains (to develop algorithms) and computers (to represent algorithms using machine languages)


Problem Liberate problem solving from programming! Rationale: 1. Programming is tedious 2. Programming is error prone 3. Problem solving by computer programming is un-natural: it requires problem domain expert to become a computer expert.


Programming is tedious • To make programming simpler and avoid errors, tools (software tools) that allow program development using human languages have been invented. • Conceptual gap: when people think about their problem domain they handle conceptual representations which are fundamentaly different from the reprsentations computers accept when they are programmed [SCS96].


Bridging the gap 1. By raising the level of abstractions computers accept. This fails because of the conceptual gap; it only increases software compexity. 2. By making programming more like thinking This fails because human thinking mechanism is different for differtent problem domains. 3. By make programming easier through domain special languages This fails because language learnig is difficult and it does not bridge the gap.


The solution 1. Characterize problem domain in terms of concepts that are: universal in the domain, stand-alone, and composable. 2. Computationally emancipate problem domain structure it using a domain ontology where terms are associated with computer articats implementing them.

3. Dedicate a virtual machine to problems domain and make the domain problem solving process identical with domain programming. Note:

this problem solving paradigm takes the computer to the problem

rather that taking the problem to the computer.


Example software tools • Generation 0: (assembly languages and assemblers) allow the use of mnemonic notations for the machine binary codes. • Generation 1: (imperative programming languages, compilers, and interpreters) allow the use of symbolic notation for both machine operation and program control-flow. • Generation 2: tools that support a variety of programming styles (functional, logical, concurrent, visual, synchronous, constraint, object-oriented, aspect-oriented. etc.). • Generation 3: tools that support special-purpose programming languages.


Essence of programming It doesn’t matter what programming tool one uses, by programming one creates programs. That is, by programming one creates binary representations of problem solving processes. can computer user be liberated from programming? Question:


Observations It doesn’t matter what tools one uses to create programs: • programming is still the same kind of technically tedious task, albeit carried out on a higher, more appropriate, level of abstraction [Har08]. • program developer needs to understand both the algorithm (problem domain) and program (the computer) • the use of higher abstractions to create programs implies complex software tools and consequently difficulties for computer user.


Liberate programming • Program development tools do not change the essence of programming; • People dream of making programming easier by liberating it from various "straitjackets": 1. Backus [Bac78] liberates programming from Von Newmann style, thus developing functional style. 2. Harel [Har01, Har08] dreams of liberating programming, period. 3. Here I discuss another idea: liberate computer user from programming!


Liberate computer user Since one cannot change the essence of programming, perhaps we can make it easier by better understanding computer-based problem solving process. • First I analyze the liberation of computer user from programming using the Harel’s dream [Har08] of programming liberation, period. • Then I present a more realistic solutions consisting of two actions: 1. Computational emancipation of problem domain 2. Development of aplication driven software


Programming straitjackets Harel [Har08] identifies the three straitjackets from which he wants to liberate programming: 1. the need to write down a program as a symbolic, textual, or graphical artifact; 2. the need to specify requirements (the what) separately from the program (the how) and to oppose one against the other; 3. the need to structure behavior according to system’s structure, providing each piece or object with its full behavior.


Relaxing the straitjackets Steps taken by others to relax programming straitjackets: (1) is relaxed by the research that decrease the effort involved in writing relevant programs, such as query-by-example [Zlo77]. (2) is relaxed by special languages [Bac78, Apt96] as well as by the research on generative (genetic) programming [Koz92, CE00] (3) is relaxed by the research on aspect-orientation [AFEC04] that tries to ease the need to totally align behavior with structure.


Note The steps taken to relax programming straitjackets do not change the essence of programming: by programming one still creates programs.


Harel’s dream is about “freeing ourselves from the straitjackets of programming" Question:

who are the "ourselves" in Harel’s

dream? ourselves in Harel’s dream are all those who develop computer programs. That is, Harel, as I, talk about freeing the computer user from the straitjackets of programming. Answer:


Getting computers to work Harel dreams of getting computers “to do what we want" intuitive, natural, and also fun. no, I don’t have a solution . . . and I definitely have noting that is magical. But the message here is definitely

Harel’s disclaimer:

“maybe we should be thinking about this something more".


The Dream •

Part 1: program development play in the program

•

Part 2: program execution play out the program


Program development The three main stages in program development: • Structured analysis and design (SAD) • Object oriented analysis and design (OAD) • Conceptual analysis and design (CAD)


Modeling mechanism The modeling mechanism used in the three stages for program development is provided by transition systems, where: • States are functions mapping variables to values (or assigning value to variables); • Transitions are operators mapping functions into functions; • Systems are operatorial expressions.

Note:

somtimes this is done in the domain theory


SAD In SAD structural models are based on functional decomposition and information flow, i.e.: • States are functions mapping variables to values • Operators are function compositions expressed by statements in procedural languiages • Systems are procedural programs expressed by hierarchical data-flow and control-flow diagrams.

SAD does not change the essance of programming. Note:


OAD OAD raises concepts used in SAD to the level of abstraction types by grouping data and operations into types of behaviors called classes. • States are objects obtaines as class-instantiations • Operators are “object creation, destruction, and compositions". • Systems are object-oriented programs expressed by UML diagrams.

Programs are models of behaviors but OAD does not change the essence of programming. Note:


CAD •

CAD is based on specializing the concepts used in OAD to the domain of application.

•

CAD behaviors express characteristic concepts of the application domains.

•

The result of a CAD system is a domain-knowlege, not a piece of data or behavior.


CAD modeling • States are knowledge expressed as tuple (term, implementation) where term is a natural language expression of the domain concept, and imnplementation is a computational object that implements the term. • Opertators are reasoning mechanisms that generate domain knowledge from given domain knowledge. • Systems are domain expressions representing new domain concepts (obtained by reasoning) in terms of given domain concepts

Note:

CAD changes the essence of programming.


Observations Conceptual modeling is the oldest branch of reasoning by modeling (see Springer LNCS on Conceptual Modeling – ER). However: • Conceptual models are static and represent IT concepts [REDF05]. That is:

conceptual models are not problem domain models used in computer-based problem solving process.

• Chen [Che06] suggests dynamic conceptual modeling; such models may evolve as CEADed ontologies. • Rolland [Rol06] relate dynamnic conceptual models to software engineering process (on step behind using conceptual modeling in domain-oriented computer-based problem-solving processw).


Harel’s natural programming Our daily instructions to people and tools concern: • combinations of laying out general principles (accepted conventions), • showing or walking through examples of what we have in mind, • prescribing rules and conditions for what can or must be done versus what must not or cannot be done. Note:

the reliability of these “programs" rely on social laws that

constrain people to be “good citizens"

Could we program computers this way?


Scientific support • Work on visual-formalisms for reactive system develpment (statecharts, message sequence charts, live sequence charts) • Succes of software tools based on visual approach and UML (statemat, rhapsody, rational rose) • Trends of software development: Structural Analysis and Designs → OO Analysis and Design → Conceptual Analysis and Design • Computational emancipation of applicatiobn domain (CEAD) by computational thinking developed in IT.


Example To answer the question raised above Harel shows us how to use natural programming to program a mobile phone.


Assumptions 1. The phone consists of a display screen, standard keys, and additional buttons. 2. The phone user knows “the basic separate capabilities of each phone component". For example, when the user presses and releases a given button the phone goes on and the display is illuminated. 3. But the phone was not yet endowed with a phone-like behavior; one can press the phone keys and nothing happens. 4. There are some magic fairies that allows us to “talk to the phone"! There are no fairies in Harel paper, they are the creation of Jacqueline and Isabella (my grad-daughters); I adopted them here to help us talk to the phone.


Natural phone programming Hey phone, listen and do: 1. Whenever I press the button b1 and hold it for 1 second you should switch the phone one; if I press and hold the button b1 for 2 seconds you switch the phone off. And the fairy behind b1 does it. 2. Don’t ever switch off if display shows that text is in progress. And the good fairy obey this rule too. 3. If I press and release a sequence of 12 standard keys followed by the pressing and releasing of the button b2 you should connect to the phone identified by the number I just dialed, if one exists! 4. And many other similar instructions.


Is it feasible? • Harel discusses this example natural programming as a dream; but he and his students have created the language live sequence charts [DH01, HM03] and have really implemented this behavior. • However, as other researchers who approached the problem of “programming liberation", the solution Harel offers just make the programming a more complicated business. • So, can we really liberate computer user from programming? To answer this questions I will show how I and my students would naturally program the phone using our approach of Computational Emancipation of the Application Domain (CEAD).


Harel observations 1. We talk to a computerized mock-up image of the phone. 2. Natural programming is about communicating (in a natural style) to a system that consists of multi-modal components (chunks of behavior). I call them characteristic components of the domain. 3. The "talking" to the phone is like a play-in action that manipulate computing objects; 4. Feasibility is illustrated by human-computer interaction such as Microsoft tabletop computing systems [Wil].


What about straitjackets? 1. Play-in is carried out directly and visually and does not require the programmer to prepare a complete artifact. However, programmer manipulates prefabricated computing artifacts; but we don’t care of what artifacts a fairy manipulates.

2. There is no need to separate specifications from operational tasks; anything what is been played-in is legal. 3. Play-in is universal hence the programmer is free to specify any behavior anyway anytime. Note that fairies are dedicated to the domain, they only perform domain actions.


Observations • Completeness: since the requirements are part of the program, programming is always complete. • Integration: since every action is complete there are no integration constraints. Hence, system change is direct. • Inheritance: objects can be substitutes freely as long as behavior is preserved. In a nutshell:

the programmer teaches and guides the computer to get

to “know" about the system’s intended behavior.

We may easily fall into the

usual programming trap if we don’t use domain dedicated fairies


Facts 1. The play-in process is a language that expresses something that the computer knows how to execute/run. Harel believes that “we can harness the computer to do that". It is more natural to harness the application domain.

2. Played-in behavior is subjected to the “on-the-fly processing" (by speech and natural language recognition?), formalization, and logical captures. This is obvious in our approach. 3. This process is somehow recorded and thus transformed into a formal artifact whose semantic captures “the properties of the allowed traces of system behavior". This is a domain-algorithm associated with a new fairy and is recorded as a SADL process.


Natural program execution 1. Programmer (computer user) needs to get immediate feedback about how the playing in has been rendered. 2. Programmer needs to observe both the generated formal version of the played-in behavior as well as its immediate effect on the played interface. 3. At any point in the play-in programming process the programmer can ask to run the current version of the program. This was termed play-out. 4. The programmer should be able to play-in with the play-out thus making changes in the formal rendition.


How to implement it? Play-out should be doable in interpreter mode (direct-execution) or in compiler mode (synthesizing an executable).


Conclusion When the programmer feels that the system has received enough instructions and guidelines she lets it free to “start behaving". This belongs to the dream. with our approach the system is associated with a name in the domain ontology and a fairy is in charge of performing it. This is not a dream. Note:


Constraints 1. Whatever programmer has told the system that it must do it will indeed do. 2. Whatever programmer has told the system that is not allowed to do it will never do. 3. Whatever programmer has told the system that it might do (such as nondeterministic or probabilistic choice among possibilities) the system will decide whether to do or not in the appropriate fashion.


Book of rules Humans cannot be expected to be pedantically obedient but computer can! 1. Humans have their “books" of rules containing all manner of instructions, regulations, guidelines, and laws relevant to their existence. 2. If humans chose to adopt the “good citizen stand" they carry-out the behavior algorithm just as described: live anyway they chose as long as it is within the confines of the “books of rules". Questions:

can we reliably transfer this procedure to the formal realm of

computing? And if so, what kind of computational tools are required?


Realizability The generation of actual behaviors that are consistent with a collection of play-in behaviors was called realizability [Var06]. Observations:

1. The realizability in general is difficult; however, realizability on a given domain of behaviors is almost obvious! 2. Hence, one-size-fits-all pattern of current computer-based problem solving process need be changed.


Rationale for realizability 1. The components of a realizable behavior may be multimodal and can contain constraints as well as operational instructions, and thus they may limit or even contradict each other. 2. Are there computational techniques to verify the consistency of play-in and play-out behaviors? 3. Such computations should be doable on the fly such that the programmer can be warned that a behavior being played-in contradicts what has already programmed.


Neuroscience • Harel believes that realizable computational techniques can be developed within the framework of temporal logic [MP92]; • I think that the natural realizable computational techniques can be the result of Neuroscience [KSJ00, PAF+ 07]. • But note, domain-dedicated realizable computational techniques are at hand today.


Feasibility • Harel model: scenario based programming [DH01, HM03]. This model support the natural programming as dreamed about but it complicates programming and is not feasible with the current computation techniques.

• Computational Emancipation of Application Domains, (CEAD) [RC06, RC07] is an achievable model of natural programming: 1. it requires domain-dedicated software tool development (well-understood). 2. it is feasible with the current computation techniques (semantic-web). 3. it moves computer-based problem-solving process in the application domain.


Domain driven software Our approach for liberating computer user from programming moves problem solving process from computer environment into problem domain environment and consists of: 1. Structure application domains using appropriate ontologies 2. Develop problem solving algorithms (not programs) in terms of domain characteristic abstractions 3. Execute algorithms (not programs) directly by domain-dedicated software


Making the dream feasible 1. Chunks of behavior: domain characteristic abstractions (universal, stand alone, composable). 2. Computerized mock-up: a knowledge representation network (use description logic). 3. Play-in: problem-solving activity in terms of domain concepts 4. Play-out: computations performed by a virtual machine executing domain abstraction.


Implementing the dream By Computational Emancipation of Application Domain (CEAD): 1. Identify problem-domain characteristic abstractions 2. Organize domain abstraction into a domain ontology 3. Associate concepts in the ontology with URI-s of computer artifacts implementing them 4. Design and implement the domain-dedicated virtual-achine


A phone ontology We first identify the problem domain, the phone business domain (PBD) and structure it in terms of main-concepts as seen in Figure 1. PBD

XXX XXX @ XXX @ z 9 R @ Display screen

Standard keys

HH j H k1 k2

Additional buttons

HH j H

. . . kn b1 b2

Figure 1:

Main actions

HH j H

. . . bm a1 a2

. . . ak

Phone domain representation


CEAD-ing the phone Secondly, we will use our fairies to computationally emancipate the PBD by associating each concept in phone ontology with a fairy that allow us to talk to it, Figure 2. Phone

XXX @ XXX XXX @ 9 z R @ Display screen DF

Standard keys

HH j H k1 k2

Additional buttons

HH j H

. . . kn b1 b2

Main actions

HH j H

. . . bm a1 a2

. . . ak

Fk1Fk2 . . . FknFb1Fb2 . . . FbnFa1Fa2 . . . Fan

Figure 2:

Phone domain computationally emancipated Liberate computer use from programming – p.52/60

Phone programming Define new actions in terms of the actions already defined on Figure 2 and evolve PBD by adding the new actions to the domain representation. Example new actions:

• Calling a number: a1 ; ki1 , ki2 , . . . , ki12 ; a2 ; • Sending a text: a1 , a3 ; ki1 , ki2 , . . . , kit ; a2 ; Note: here the fairy associated with the button a3 make the standard key selection represent letters rather than numbers; • Phone user is free to define, add, remove actions as she pleases


Implementation 1. Walk the phone ontology and associate each fairy with the URI of a computer artifact that implements its behavior. 2. Associate the phone ontology with a virtual computer that perform the loop: CurrentURI = StartingFairy; while (CurrentURI.action is not halt) Execute(CurrentURI.action); CurrentURI := Next(CurrentURI);

3. CurrentURI is associated with the fairy responsible with the user-phone communication


Another example A mathematician wants to use natural programming to program her computer to do signal processing using Discrete Fourier Transform. Assumptions:

1. The mathematician employs complex algebra, matrix algebra, and Fourier Transforms. 2. The mathematician knows how to sample discrete signals. 3. The mathematician has fairies that perform complex operations, matrix operations. 4. The mathematician has a fairy that can generate the Fourier Matrix that corresponds to a signal sample.


Frequency sampling Using natural programming the mathematician constructs the program that compute Frequency Sampling as shown in Figure 3. Discrete Fourier Transform

PP PP PP q P ? ) Matrix algebra Complex algebra Signal processing PPP PP PP q ) Signal sampling

Frequency computation

? sig:vector(a1 , . . . , an )

HH H Hj H

Fourier matrix: F M (sig)

Figure 3:

Frequency sampling: F S = F M (sig) × sig T

Discrete Fourier Transform Liberate computer use from programming – p.56/60

Fourier matrix • Let sig = (a0 , a1 , . . . , an−1 ) be a signal sample. • The discrete spectrum of frequencies of sig is a vector ν(sig) = (b0 , b1 , . . . , bn−1 ) whose components are computed by Pn−1 the formula: bj = k=0 ak ∗ ei2π/n∗j∗k , j = 0, 1, . . . , n − 1. • Fourier matrix of sig, F M (sig, n) is: ˛ ˛ ei2π/n∗0∗0 ˛ ˛ ˛ ei2π/n∗1∗0 ˛ ˛ ˛ ei2π/n∗2∗0 ˛ ˛ ... ˛ ˛ ˛ ei2π/n∗(n−1)∗0

ei2π/n∗0∗1

ei2π/n∗0∗2

...

ei2π/n∗0∗n−1

ei2π/n∗1∗1

ei2π/n∗1∗2

...

ei2π/n∗1∗n−1

ei2π/n∗2∗1

ei2π/n∗2∗2

...

ei2π/n∗2∗n−1

...

...

...

...

ei2π/n∗(n−1)∗1

ei2π/n∗(n−1)∗2

...

ei2π/n∗(n−1)

2

˛ ˛ ˛ ˛ ˛ ˛ ˛ ˛ ˛ ˛ ˛ ˛ ˛


Notations One can simplify the Fourier matrix F M (sig, n) by the notation: w(n) = ei2π/n = cos(2π/n) + i sin(2π/n) and w(n)n = 1 Note:

the elements of F M are powers of w(n) and thus we have:

F M (sig, n) =

1

1

1

...

1

1

w(n)

w(n)2

...

w(n)n−1

1

w(n)2

w(n)4

. . . w(n)2(n−1)

...

...

...

1

w(n)

n−1

w(n)

2(n−1)

...

...

. . . w(n)

(n−1)2


Fourier Transforms • The Discrete Fourier Transform (DFT) is the algorithm that computes ν(sig) using the scalar product ν(sig) = F M (sig, n) × sig T . Hence, the mathematician programs his machine by writing (or telling): F1: let Sig=(a_1,a_2,...,a_n); generate FM(n); transpose Sig to SigT; compute Fq(Sig) = FM X SigT

• Fast Fourier Transform [CT65] uses properties of FM to reduce the complexity of ν(sig) from O(n2 ) to O(n logn).


Bibliography References [AFEC04] M. Aksit, R.E. Filman, T. Elard, and S. Clarke. Aspect Oriented Software Development. Addison-Wesley, 2004. [Apt96]

K. Apt. From Logic Programming to PROLOG. Prentice Hall, 1996.

[Bac78]

J. Backus. Can programming be liberated from the von newmann style? a functional style and its algebra of programs. Comm. ACM, 21(8):613–641, 1978.

[CE00]

K. Czarnecki and U. Eisenecker. Generative Programming: Methods, Tools, and Application. Addison-Wesley, 2000.

[Che06]

Liberate use from programming – p.60/60 P.P. Chen. Suggested research directions for acomputer new frontier