1 Karl Reed wcre2000. futures The Future Of Software Engineering & Re-Engineering as Software Archaeology Chair IEEE-Computer Society Tech. Council on

1

Karl Reed wcre2000.futuresThe Future Of Software

Engineering & Re-Engineering as Software Archaeology

Chair IEEE-Computer Society Tech. Council on Software Engineering Governor, IEEE-Computer Society(1997-1999,2000-2002), Director, Computer Sys. & Software Engineering Board, ACS, Department of Computer Science & Computer Engineering, La Trobe University Hon. Visiting Professor, Middlesex University

“those who fail to study history are bound to repeat it”

by Assoc. Prof. Karl Reed,FACS, FIE-Aust., MSc,ARMIT

liberal use will be made of ideas from Jason Baragry, David Cleary and Jacob Cybulski

2

Karl Reed wcre2000.futuresThis Seminar will discuss…

2. Some definitions of Engineering, relevant to software development (presented for the benefit of software engineering researchers)

3. Software Process... Often mandated, but not followed… few detailed studies similar to production engineering (see Hess)4. Re-use… not successful, yet components industry emerging

5. Engineering & SE.. Poor choices of analogues from traditional domains, e.g. “immutable components”

1. A fundamental symptom of current software development, and some interpretations

3

Karl Reed wcre2000.futures

“F1. Current software has too many surprises. The sources of surprise are poorly understood.”

Sources of surprises... Real and apparent ambiguity in the means of representation of systems, e.i. Languages (cf 3 pages of c++ with 3 pages of government regulations)

“F2. Key sources of software surprise include immature or poorly integrated software domain sciences, construction (product) principles, and engineering processes. Software research emphases have swung from process to product research, with weak coverage of domain sciences and integration.”

No surprises….!!!(nsf report on s/w research 1998)

4


“F1. Current software has too many surprises. The sources of surprise are poorly understood.”

Sources of surprises... Real and apparent unpredictability in behaviour...

No surprises….!!!(nsf report on s/w research 1998)

“Teenagers have less trouble with PC software because they are adept at playing computer games” Charles Wright, editor Melbourne Age “green pages” computer section 2000

“Building ‘bots’ that play computer games with near human competence is not that hard” US researcher in AI….

5


A better comparison.. cost developing Windows NT vsdesign of and plant costs for a new Pentium (Reed)

A Reality Check?A Reality Check?

It is argued that computer designers and manufacturers do better than software developers..

Not so.....!!!!

Compare the purchase-cost of Delphi or Foxbase with a mainframe equivalent 20 years ago... (Jones)... reductions per unit of delivered end-user functionality of 10 2 to 10 3 Extremely large complex systems, deployed with very large-scale usage,

successful package, tool and “utility” builders around for >30 years

6

Karl Reed wcre2000.futuresBy way of Illustration...Some

Contradictions……and confusion

2. Software Process.. CMM vs fine-grained process independent, Time To Market vs Planned Process, Phase incompletedness, Extreme Programming.

3. Software Process... Often mandated, but not followed… few detailed studies similar to production engineering (see Hess)4. Re-use… not successful, yet components industry emerging

5. Engineering & SE.. Poor choices of analogues from traditional domains, e.g. “immutable components”

1. Software Architecture.. ‘not immutable, not always determinable a’priori,multiple versions in one artefact, retrofitable…. Analog with “built” systems not clear.

7

Karl Reed wcre2000.futuresSome Contradictions……

and confusion (cont’d)

7. Prescriptive Design processes... only slowly beginning to appear, perhaps via UML.8. Requirements Engineering... Cannot always be completed in advance..may be continuous part of the implementation process...

9. Software Crisis… yet increasingly, successful large-scale applications are ubiquitous

10. High Quality training for 30 yrs.. Yet each new s/w development wave starts with a blank mind, e.g. web-based computing

6. SWEBOK.. Organised body of knowledge opposed by leading SE players.

11. Documentation matters but.. It’s seldom actually done

8


Stages of SE...Immature methodologies, Fortran, Cobol, Assembler-70’s,telephone systems

Systems Analysis and Design methodologies70’s-80’s

Formal Methods, info. Hiding, architecture, strong typing, CASE,RE,SCS,formalised testing, banking networks,internet,PC-OS,

OO,CMM,Process Modelling,re-use, cots,dig.flight control systems,EFTPOS

Large-scale s/w, comsumer

goods,engine management

systems, ABS

time to market, extreme

programming, web systems, free-ware, 94-00’s

Customer req dominate,ROI mandatory

Determinate, quality driven, high reliability, business model oriented

Unreliable, technology history free, ROI independent-business model? s/w surprises

Cottage industry, but well intentioned

Mature?Body of Knowledge but no universal success

Cottage industry, reversion to the old-days

9

Karl Reed wcre2000.futuresOur theses….

We face a number of problems

2. Our lack of understanding of engineering, and of the nature of software development.

3. What is the true nature of concepts actually used in software development, and the thought-processes involved?

4. Can re-engineering, program comprehension contribute to this process? process5. How should this impact objectives for future research in SE.

1. The “Universe of Discourse” Problem (UDP)….The creation (and existence of the universal sets of concepts and practices for the dreams of SE to be realised,

After 32 years, the lack of clarity and consensus on Software Engineering is a tad worrying

10

Karl Reed wcre2000.futuresFirstly, what is Engineering? Firstly, what is Engineering?

Engineers are concerned with maintaining and improving living standards and quality of life. …. Engineers are responsible for finding innovative solutions to various problems while protecting the earth's resources.

Engineering involves the application of science and technical knowledge to create systems, services, products and materials used in everyday life. Engineering skills and designs contribute to almost every aspect of modern living.

Engineers determine how and in what way the objectives of a particular project can be met safely and the wisest uses of the available resources. These resources may be budget, time, materials or even human effort. Often, engineers work together in teams with other professionals such as architects, accountants, economists, doctors, scientists and tradespeople. Each group of professionals provides knowledge and skills from their own particular area of expertise to complement the work of others.

11

Karl Reed wcre2000.futuresWhat is Engineering? What is Engineering?

Engineers build economically useful systems and artefacts (anon)(anon)

What is NOT Engineering?What is NOT Engineering?(.. .. The people who build bridges etc. are

called welders, riggers plumbers, labourers, bricklayers, etc. NOT Engineers…)

12


ENGINEERS WORK WITH A DEFINED FRAMEWORK..

MUCH ENGINEERING DESIGN KNOWLEDGE

IS EMPIRICAL AND "RULE OF THUMB"Engineers vs software developers…Engineers explicitly…differentiate between…

situations where these methods do not appear to exist..

"problems" whose solution can be achieved using "prescribed" methods, and

Common, Coherent Universe of Discourse! (terms, methods, techniques)

Theoretical basis of knowledge not always visible

13


Engineers… design artefacts to interface with the real world… (Baragry 1997)”

Engineers vs software developers…(cont’d)

“S/W developers… attempt to build models of real-world phenomena

ENGINEERS DON’T BUILD SYSTEMS!!ENGINEERS DON’T BUILD SYSTEMS!!

the result of an “engineering” process is a set of design the result of an “engineering” process is a set of design documents and plans which will be used by someone else of documents and plans which will be used by someone else of lesser training (but higher aptitude)lesser training (but higher aptitude)

Compare with software development....Compare with software development....

ENGINEERS CHEAT!!ENGINEERS CHEAT!!They invent components & methods which guarantee They invent components & methods which guarantee

analyticityanalyticity

14

Karl Reed wcre2000.futuresThe result of an engineering design

15

Karl Reed wcre2000.futuresEngineering is...Engineering is...

Based upon "abstractions" validated by physical laws which..

Constrain the solution space,

Provides definite failure modes,

Simplifies the process of developing a universe of discourse..

None of this is true for s/w..

Existence of physical laws is neither necessary nor sufficient for engineering properties..

16

Karl Reed wcre2000.futuresIn summary..

Engineering is..

“A directed process of decision making leading to the design of a realisable artefact in which criteria exist for choices which guarantee optimal outcomes according to some pre-determined criteria”

Requires.. Mathematics of a particular kind “teachable” to undergrads, plus prescribed processes ..

Physical laws provide basis for pruning the solution space.

17


18


19


20


21


22


23


24

Karl Reed wcre2000.futuresThe result of an engineering design

25

Karl Reed wcre2000.futuresEngineering is...Engineering is...

“Design-reasoning Explicit… The design CANNOT be completed without performing

explicit “reasoning”, which MUST be recorded, step by step..

Hence, the documentation is an integral part of the process, NOT SOME EXTERNALLY MANDATED MANAGERIAL REQUIREMENT!

The documentation (I.e. design-reasoning record) is capable of being transmitted to third-parties who are able to use it

26

Karl Reed wcre2000.futuresissues

B. Re-use.. The immutable component assumptionC. Baragry’s Conjecture and its implications.. The work-products problem...D. Baragry’s thesis.. Theory building and its implications yet increasingly, successful large-scale applications are ubiquitous

E. The problem of “glue” and component semantics.. The reversible buffer problem (spoon handle)

A. Architecture… the multiple architecture problem...

F. component semantics.. The role of re-engineering.. Holt et al, the linked list problem

G. S/W archaeology)

27


A. Architecture… (and the multiple architecture problem…)§ Originally.. Architecture was to be decided up-front, and adhered to throughout a design (Brooks..) implying that there was only ONE

§ Currently.. Multiple architectures (are they views?)

§ Architecture may impossible to determine up front

§ Architecture may evolve during design

§ Architecture may retrofitted, and re-engineered

§ Architecture determination may not be necessary up front

28


A. Architecture… some definitions...

§ As set of rules for arranging collections of components

§ “That is what architects are, conceivers of buildings. What they do is to design, that is, supply concrete images for a new structure so that it can be put up. The primary task for the architect, then as now, is to communicate what proposed buildings should be and look like.” Kostof 1986

§ As set of rules for arranging collections of components

§ Architects work with a knowledge of structures and an eye to aethsetics

29


§ is "completed", hence is not performed, and has no effect on the final system.

Philosophy of "design" and "architecture"Philosophy of "design" and "architecture"

Various levels of reuse of design (cf "ordinary" architecture) for components and artefacts design …

§ is known to be achievable, hence incompleteness is irrelevant, but may impact final system.

§ is known to be achievable, but may need to be completed to ensure final system is "correct".

§ is not known to be achievable …cf Sydney opera house.

This can be understood easily in terms of standard building architecture.

30


The Architectural View Problem….The Architectural View Problem….

Or multiple simultaneous architecture’s??Or multiple simultaneous architecture’s??

DB repository

UIS

Command

Processor

User Pin

checker

Command

Sequence

Checker

What happens to the What happens to the architecture if we use a architecture if we use a messaging system?messaging system?

31


The Architectural View Problem…The Architectural View Problem…Messaging versionMessaging version

DB repository

UIS

CommandProcessor

User Pin

checker

Command

Sequence

Checker

MessageSystem

What is the “true” What is the “true” architecture?architecture?

What if the names What if the names of addressees are of addressees are passed in variablespassed in variables

call ms(“DBR”,..)call ms(“DBR”,..) target:= “CP”;target:= “CP”;

call ms(target,..)call ms(target,..)

read(target);read(target);

call ms(target,..)call ms(target,..)

DB repository

UIS

CommandProcessor

User Pinchecker

Command Sequence Checker

32


Real “Views”

Australian Contemporary architecture

33


Not-a-view!

34

Karl Reed wcre2000.futuresAn Architecture

35


Re-use.. The immutable component assumption

§ Assumption… Engineers work with immutable libraries of components.. Hence.. Software Developers should also.§ Problem… S/W is inherently immutable hence, functionality can be changed easily.

§ Reality… Engineers do not universally work with “immutable” components.. e.g. families of automobile engines,

…Need for coupling between modules can make immutability impractical

…Modern OO implementation means that “modules” have semantics which are determined by other “modules” whose semantics is not controlled by the invoker.

36


Baragry’s conjectures and their implications.. The work products problem…

“Engineers build artefacts, s/w developers build models.. s/w development is a theory building process”

§ Baragry compared a number of published software designs for cruise control with a number of actual hardware designs

§ Conclusion - engineers started with a prior, common, abstract model of the solution and “fixed” the design analytically to achieve a desired characteristic

§ A S/W system’s true “meaning” cannot readily be deduced by inspection of physical representation

37


Baragry’s conjectures and their implications.. The work products problem…

§ The conclusion was that engineers started with a prior, common, abstract model (the feed-back control system) of the solution and “fixed” the design analytically to achieve a desired characteristics

§ Software developers started with “mental” concepts derived based on their methodology, and used these to model (different) implementations of feed back model.

§ The engineer’s designs were recognisably similar, the software design’s were not!§ There seemed to be no basis for choosing one set of concepts over another during the s/w designs!

38


Baragry’s conjectures and their implications..

The work products problem…

§ what if there is no basis for choosing one set of concepts over another during s/w designs?

Maybe the design work-products (diagrams, descriptions etc.) mandated don’t represent the “thought processes”

Maybe the design work-products are not transferable between developers, and hence between project phases..

Maybe there are no pre-agreed concepts at the implementation and implementation-solution levels that constitute a universe of discourse amongst the designers ..

missing domain-related universe of discourse...

39


Baragry’s conjectures and their implications..

The work products problem…

§ if the methodologies are not leveraging the design process(Reed),

Documentation will not reflect design...

Documentation will be an external, non-design process… since it is based on conceptual models other than those being used!..

S/W development processes in practice consist of “work arounds” like other prescription based systems

40


“Extreme programming”?

System Test

Programming

Unit Test

Program Design

Systems Analysis

Feasibility Study

Requirements Analysis

System Integration

Optimal task allocation, observed <1970 one or two people

Waterfall S/W Process Model

No need for ‘third-party” readable work products!

Private s/w process? (PeSP compliant?)

41


D. Baragry’s thesis.. Theory building and its implications for s/w methodology and process

That a “classic” discipline of software engineering either is impossible or will differ vastly from any other form of engineering

Our lack of progress is due to a combination of the nature of s/w development plus our lack of understanding of engineering--the delta isn’t correctly defined

Progress towards universes of discourse at any level will require deliberate efforts, or it will be slow. Methodologies and language styles will continue to proliferate Study domains where results are “superior” to see if Baragry’s conjecture holds e.g. SCS

42


D. Baragry’s thesis.. Theory building and its implications for s/w methodology and process(cont’d)

Time to Market strategies are NOT aberrant, and the fact that there is no focus on language, tools or methodology (or CMM 5) is not a surprise

43


E. The problem of “glue” and component semantics..

The belief... “components” must have ‘semantic’ coherence… i.e. that they have descriptions that are “easily” recognisable by an observer.

Classic top-down structured programming doesn’t guarantee to produce such components..

Baker (1995 wcre) suggested that 20%-30% of “straight-line” code consisted of replicated fragments..of unknown semantics

In engineering, the semantics of couplings (glue) may be clear only to a domain expert

44


45


46


47


48


F. component semantics and concept extraction.. The role of re-engineering.. S/W Archaeology...

program is a model of some real world process

exactly what “concepts” are represented in terms of non-procedure replicated code fragments? What are their semantics?

-What impact do these have on program composition?

How do these relate to different problems in the same domain? ..different problems in different domains?

How are components modified in practice and what is the outcome?

49


F. The role of re-engineering.. S/W Archaeology and S/W Architecture....

recovery of standard architectures

identification of s/w construction practices, e.g. shifts from one programming style to another

§ architectural styles

development of maintainability and evolvability classifications for --

development of maintainability and evolvability classifications for architectural styles

§ design methodologies

50


F. component semantics and concept extraction.. The role of re-engineering.. Architecture issues for the S/W Archaeologist

identification of design approaches which ensure that conceptual architectures are transferred to implementation

identification of standard mappings from conceptual to actual architectures which occur using different design approaches on different problems

51


"Powerful" formal methods, cf Laplace xforms vs DE's

"Testability" driven implementation techniques

§ Reduction in logical complexity of programs, perhaps through separation of control and data

Additional major technical problems to be solved..Additional major technical problems to be solved..

Improved Diagramming Techniques,

§ Diagrams should be executable, cf. circuit diagrams etc.

§ Diagrams should reflect nature of (most) problems… async. communicating. parallel processes.

§ Diagrams should represent a completed design c/f engineering.

"Efficient" test techniques

52

Karl Reed wcre2000.futuresImplications for Research

Need for more comparative studies a’ la Baragry

Need to focus on the delta

Need to recognise the uniqueness of the medium

Deliberate generation of common techniques and Universe’ of discourse

More studies of actual s/w production and comparisons of effectiveness

Deliberate generation of common techniques and Universe’ of discourse

53

Karl Reed wcre2000.futuresConclusions

A true discipline of SE is some way off.

The Role of the re-engineering and program comprehension communities is pivotal

Quality of appeals to engineering analogues and terminology MUST be better founded

Extent of study of s/w process warrants a new discipline..

Formal discipline of s/w archaeology required

…s/w development process psycho-analysis

…(our navel gazing is both extensive, therapeutic and not well directed..)

Documents

1 Karl Reed wcre2000. futures The Future Of Software Engineering & Re-Engineering as Software Archaeology Chair IEEE-Computer Society Tech. Council on