The document discusses the methodologies for software engineering in artificial intelligence, emphasizing an incremental and exploratory approach called the 'rude cycle.' It critiques traditional software development models, like the waterfall and code-and-fix models, and advocates for new paradigms that prioritize robustness, flexibility, and iterative refinement. Additionally, it introduces concepts such as automatic programming and transformational implementation as part of evolving software engineering practices.

1. 1
SOFTWARE ENGINEERING FOR AI

2. 2
2
TEXT BOOK
ARTIFICIAL INTELLIGENCE and SOFTWARE
ENGINEERING
Understanding the Promise of the Future
AUTHOR : Derek Partridg

3. 3
3
An Incremental and Exploratory Methodology
 Classical methodology and Al problems:
 AI software systems have been built and demonstrated,
sometimes to great acclaim (Acknowledgement)
 Does this mean that we must abandon the idea of robust
and reliable (and therefore practical) AI software? Or does
it mean that we must find a way to curb the worst of AI's
excesses and constrain the problems to fit with the SAV
(or SAT) methodology? Or does it mean that we must
generate a new software system development
methodology.

4. 4
4
The RUDE cycle
 Sometimes AI systems are built using ad-hoc ways.
 In particular, AI systems tend to be built
incrementally—an evolutionary paradigm is used.
The essence of these incremental methodologies is
captured in the notion of the RUDE cycle.

5. 5
5
 The fundamental elements of all incremental system
development procedures are:
 1. Run the current version of the system
 2. Understand the behavior observed
 3. Debug the underlying algorithm to eliminate
undesired behavioral characteristics and introduce
missing, but desired, ones
 4. Edit the program to introduce the modifications
decided upon
 Figure : "The RUDE cycle"

6. 6
6

7. 7
The RUDE cycle as a basis for software development has
its problems. That much should be obvious from our
earlier discussion of the problems that beset all software
development together with an inspection of the RUDE
cycle itself—lack of a clear initial specification and
criterion for success, and its iterative framework
containing no guarantee of termination.
7

8. 8
 How do we start?
What we need is a runnable prototype.
prototyping as consisting of four steps:
1. 1.functional selection
2. 2. construction
3. 3. evaluation
4. 4. further use
8

9. 9
 This first version is a probe into the vast space of
behaviors that surround the ideal (but impossible)
solution to the problem.
 The AI-software engineer must gather behavioral data
from this first version of the software, analyze its
import, and then devise a second version of the
software to probe in a potentially more-adequate part of
the space.
 A second crucial requirement is that it does run, and the
further the better.
9

10. 10
Malleable software
 Software that is readily modifiable is called malleable
software.
 It should exhibit a maximum of functional flexibility.
 1) Modularity
 2) understand the working of the system
 3) Modification
 Code developer should know good programing formal
notation called Backus-Naur Form (BNF). It is used to
define the syntax of programming languages.

11. 11
BNF defines is syntactic structure .
Numbers, characters, strings, operators, identifiers etc.
Ex.
11

12. 12
Al muscles on a conventional skeleton
 For our first version of an AI system we want it to be mostly a
robust, reliable, and well-defined skeleton of conventional
software. To this framework we can then attach the AI muscles
that will provide greater power to the overall system but need to
be closely confined and controlled if they are to be developed
effectively.

13. 13
 Clearly, the suggested AI muscles are just such stubs,
although how to elaborate the essential details is no
longer a clear-cut procedure.
 In conventional software engineering, once you've
tested and are happy with the general framework it is
then a fairly straightforward task to design and
implement a mechanism to realize each of the well-
defined stub functions(hard functions).
13

14. 14
The question of hacking
 Boehm (1988) dignifies this (hacking) activity with the
status of a software development model and calls it the
code-and-fix model.This was, as he says, the basic
model used in the earliest days of software
development; it contained two steps:
 1. write some code, and
 2. fix the problems in the code.
14

15. 15
 Boehm sees three primary difficulties with this model:
a). system quickly becomes excessively expensive to
maintain,
b). initial system is such a poor match to user's needs that
it is either rejected outright or expensively redeveloped,
c). lack of preparation for testing and modification of
system means code fixes are expensive.
15

16. 16
 This view of code hacking is clearly a commercial
perspective, with its continual reiteration of the high
costs associated with the code-and-fix model.
 Boehm uses this critique to motivate the emergence of
the waterfall model, and then he goes on to explain the
subsequent spiral model.
16

17. 17
Conventional paradigms
 The single, most widely acknowledged software
development paradigm is based upon the waterfall
model.
 Boehm (1988), who devised the waterfall model,
presents it as a refinement of a stagewise model that
emerged from the problems inherent in the code-and-
fix model.
17

18. 18
Waterfall model(classical model)
18

19. 19
Refinement to waterfall model:
 (1) Recognition of the feedback loops between stages,
and a guideline to confine the feedback loops to
successive stages to minimize the expensive rework
involved in feedback across many stages.
 (2) An initial incorporation of prototyping in the
software life cycle, via a "build it twice" step running in
parallel with requirements analysis and design.
19

20. 20
Spiral model
20

21. 21
 The spiral model reflects the underlying concept that
each cycle involves a progression that addresses the
same sequence of steps, for each portion of the product
and for each of its levels of elaboration... each cycle of
the spiral begins with the identification of
 • the objectives of the portion of the product being
elaborated (performance, functionality, ability to
accommodate change, etc.);
 • the alternative means of implementing this portion of
the product (design A, design B, reuse, buy, etc.); and
 • the constraints imposed on the application of the
alternatives (cost, schedule, interface, etc.).
21

22. 22
New Paradigms for Software Engineering
 The development of AI systems follows incremental
scheme that is at root the way that most AI systems are
developed.
 And we saw only too clearly that the RUDE cycle, as
basis for the construction of robust, reliable and
maintainable software systems.
 Activity within the software world has not been totally
focused on improving specifications, verification
techniques, and testing.
 And also attempts to appreciate 'the big picture' and set
the software world aright by presenting new paradigms
for software-sys-tem development. 22

23. 23
Automatic programming
 The ultimate goal of artificial intelligence applied to
software engineering is automatic programming.
 It is a bridge to conventional programming to AI
programming.
 Rich and Waters (1986) provide us with a useful
framework within which to develop answers to this
question. They explain their scheme with reference to
Figure 5.2.
23

24. 24
24

25. 25
 Working from the bottom up there are projects to
develop so-called very high level languages.
 Coding (i.e. writing the program) is done with
structures that are both human- and problem-oriented
such that you almost don't realize that you are indeed
programming when you cast your problem in terms of
the a language provided.
 In this sense of automatic programming, the necessary
techniques have been 'compiled' into the very high-level
language, and the programmer is programming without
knowing it.
25

26. 26
Application Generators (AG)
 Horowitz, Kemper and Narasimham (1985) survey the
AG systems available.
 The productivity of software development is called AG.
26

27. 27
27

28. 28
28

29. 29
Transformational implementation
 This is an active, and therefore important, subfield of
automatic programming.
 A transformational implementation scheme is typically
based on the notion of achieving program correctness by
converting programs in an easily readable, very high-level,
widespectrum language into an efficient, directly executable
form.
 Agresti (1986) in his edited collection, New Paradigms for
Software Development, distinguishes between the
operational paradigm and the transformational paradigm.He
illustrates the differences as shown in Figures 5.4 and 5.5
29

30. 30
Figure 5.4 "The operational paradigm"
30

31. 31
Figure 5.5 "The transformational paradigm" about here, both
from Agresti, 1986,
31

32. 32
The "new paradigm" of Balzer, Cheatham, and Green
 A representative example of the work on
transformational schemes can be found in Software
Technology in the 1990's: Using a New Paradigm, by
Balzer, Cheatham, and Green (1983). Figure 5.6
illustrates their new paradigm and contrasts it with a
more conventional paradigm (SAT with pro-totyping).
32

33. 33
33

34. 34
 They sketch out the possibilities for a knowledge-based
software assistant (KBSA);Figure 5.7 depicts their
vision.
34

35. 35
Figure 5.7 "A generalized knowledge-based software
assistant structure" from Balzer, Cheatham, and Green, 1986
35

36. 36
Operational requirements of Kowalski
 Kowalski's methodology is another example of a new
approach to software engineering systems stems from
the logic-programming movement.
 Kowalski gave us the following observation about
programs:
 PROGRAM = DECLARATION + CONTROL
 With the advent of the programming language Prolog,
something quite close to logic became a machine-
executable notation—i.e. a programming language
36

37. 37
Fig "The conventional view" & "The Japanese view"
37

38. 38
"The software development life cycle of DeMarco"
from Kowalski, 1984
38

39. 39
The POLITE methodology
 POLITE - Produce Objectives - Logical/physical design
- Implement - Test – Edit.
 Bader, Edwards, Harris-Jones, and Hannaford (1988)
maintain that "knowledge-based systems" (KBS) are not
yet associated with an accepted software development
life cycle (SDLC) or development methodology.
 They make the point that the major system development
feature that KBSs bring to the fore is a necessity for
iterative refinement, and so something like the RUDE
cycle is a likely basis for the required methodology.
Figure 5.13 is their simplified view of the RUDE cycle
39

40. 40
40

41. 41
"The POLITE life-cycle" from Bader et al., 1988
41