A Cloverleaf of Software Engineering - Semantic Scholar

A Cloverleaf

of Software Engineering∗

Dines Bjørner School of Computing, Department of Computer Science National University of Singapore, 3 Science Drive 2, Singapore [email protected] ⊕ [email protected] Abstract We shall touch upon four issues of software engineering (SE): domain engineering, formal techniques, SE sociology, and academic software architects. First, before software can be designed one must understand its requirements; but before requirements can be formulated one must understand the domain. So we assume that requirements development is based on first having established models of the (application) domain. I will illustrate facets of the railway domain. Second, we touch upon all of the three phases: domain engineering, requirements engineering and software design also being done formally, however ”lite”. Third, despite 35 years of formal methods, the SE industry, maturity-wise still lags far behind that of other engineering disciplines. So we examine why. Finally, in several areas, in health care, in architecture, and others, we see that major undertakings are primarily spearheaded by senior academic staff. Professors of medicine daily perform specialised surgery and treatments at hospitals. Professors of architecture design new, daring buildings for industry, and professors of civil engineering head the engineering structural design of new, daring bridges. So we speculate what a similar approach would entail for SE. The paper is provocative, it postulates, but most claims are not (but can and will be [4]) substantiated.

stabilise. What can we do about it? In this invited paper I will first make a technical/scientific plea for yet another software engineering approach. Then the invited paper will become increasingly provocative. As a basis, perhaps or hopefully, for — ie., a contribution to — an unfolding discussion as to how we can each help to mature the industry.

2. Domain Engineering Details of the techniques of domain engineering are given in Vol. 3 of [5].

2.1. The Dogma Before software can be designed one must understand its requirements; but before requirements can be formulated one must understand the domain.

2.2. The Triptych of Software Engineering This dogma forces us to not start on requirements engineering before we have a reasonable theory of the domain in which the required software is to reside. Software design then follows from requirements prescriptions [5].

2.3. An Example Domain: Railways

1. Introduction

We illustrate what it may take to describe a domain. The domain, railways, is part of the transportation infrastructure.

Software engineering — by comparison to other engineering fields — is a young field. Hardly 40 years. It is still seriously flawed as a discipline. New software engineering approaches flash over the SE stage ever so often, at a far more rapid succession than in the classical engineering disciplines. That is to be expected. The field has to mature, to ∗ Invited

paper for SEFM 2005, the 3rd IEEE International Conference on Software Engineering and Formal Methods, Koblenz, Germany, September 5–9, 2005.

2.3.1 Narration of Statics We introduce the phenomena of railway nets, lines, stations, tracks, (rail) units, and connectors. 1. A railway net consists of one or more lines and two or more stations. 2. A railway net consists of rail units.

Proceedings of the Third IEEE International Conference on Software Engineering and Formal Methods (SEFM’05) 0-7695-2435-4/05 $20.00 © 2005

IEEE

Station

Switchable Crossover

Linear Unit

Platform Line

Switch

Track

Crossover

Siding

14. A linear rail unit has two distinct connectors. A switch (a point) rail unit has three distinct connectors. Crossover rail units have four distinct connectors (whether simple or switchable), etc. 15. For every connector of a net there is at least one, and there are at most two rail units of that net which have that connector in common. 16. Every line of a railway net is connected to exactly two distinct stations of that railway net. 17. A linear sequence of (linear) rail units is an acyclic sequence of linear units such that neighbouring units share connectors.

Station Figure 1. A “model” railway net

Linear Unit

Legend:

13. A rail unit has one or more connectors.

Junction, Switch, Turnout

rail:

connector:

2.3.2 Formalisation of Statics We number the formula below to match the numbered narrations above. We otherwise use the RAISE Specification Language, RSL [19, 20, 21, 5].

Crossover Swith

Simple Crossover

units can be switched:

Figure 2. Some rail units 3. A line is a linear sequence of one or more linear rail units. 4. The rail units of a line must be rail units of the railway net of the line. 5. A station is a set of one or more rail units. 6. The rail units of a station must be rail units of the railway net of the station. 7. No two distinct lines and/or stations of a railway net share rail units. 8. A station consists of one or more tracks. 9. A track is a linear sequence of one or more linear rail units. 10. No two distinct tracks share rail units. 11. The rail units of a track must be rail units of the station (of that track). 12. A rail unit is either a linear, or is a switch, or a is simple crossover, or is a switchable crossover, etc., rail unit.

type N, L, S, Tr, U, C value 1. obs Ls: N → L-set 1. obs Ss: N → S-set 2. obs Us: N → U-set 3. obs Us: L → U-set 5. obs Us: S → U-set 8. obs Trs: S → Tr-set 12. is Linear: U → Bool 12. is Switch: U → Bool 12. is Simple Crossover: U → Bool 12. is Switchable Crossover: U → Bool 13. obs Cs: U → C-set 17. lin seq: U-set → Bool lin seq(us) ≡ ∀ u:U • u ∈ us ⇒ is Linear(u) ∧ ∃ q:U∗ • len q = card us ∧ elems q = us ∧ ∀ i:Nat • {i,i+1} ⊆ inds q ⇒ ∃ c:C • obs Cs(q(i)) ∩ obs Cs(q(i+1)) = {c} ∧ len q > 1 ⇒ obs Cs(q(i)) ∩ obs Cs(q(len q)) = {} axiom 1. ∀ n:N • card obs Ls(n) ≥ 1 ∧ card obs Ss(n) ≥ 2 3. ∀ n:N, l:L • l ∈ obs Ls(n) ⇒ lin seq(l) 4. ∀ n:N, l:L • l ∈ obs Ls(n) ⇒ obs Us(l) ⊆ obs Us(n) 5. ∀ n:N, s:S • s ∈ obs Ss(n) ⇒ card obs Us(s) ≥ 1 6. ∀ n:N, s:S • s ∈ obs Ls(n) ⇒ obs Us(s) ⊆ obs Us(n) 7. ∀ n:N,l,l:L•{l,l}⊆obs Ls(n)∧l =l ⇒obs Us(l)∩ obs Us(l)={} 7. ∀ n:N,l:L,s:S•l ∈ obs Ls(n)∧s ∈ obs Ss(n)

Proceedings of the Third IEEE International Conference on Software Engineering and Formal Methods (SEFM’05) 0-7695-2435-4/05 $20.00 © 2005

IEEE

⇒obs Us(l)∩ obs Us(s)={} 7. ∀ n:N,s,s:S•{s,s}⊆obs Ss(n)∧s =s ⇒obs Us(s)∩ obs Us(s)={} 8. ∀ s:S • card obs Trs(s) ≥ 1 9. ∀ n:N,s:S,t:T•s ∈ obs Ss(n)∧t ∈ obs Trs(s) ⇒ lin seq(t) 10. ∀ n:N, s:S, t,t;T • s ∈ obs Ss(n)∧{t,t}⊆obs Trs(s)∧t =t ⇒ obs Us(t) ∩ obs Us(t)={} 15. ∀ n:N • ∀ c:C • c ∈ ∪{obs Cs(u)|u:U•u ∈ obs Us(n)} ⇒ 1≤card{u|u:U•u ∈ obs Us(n)∧c ∈ obs Cs(u)}≤2 16. ∀ n:N,l:L • l ∈ obs Ls(n) ⇒ ∃ s,s:S • {s,s} ⊆ obs Ss(n) ∧ s =s ⇒ let sus=obs Us(s),sus=obs Us(s),lus=obs Us(l) in ∃ u,u,u,u:U• u ∈ sus∧u ∈ sus∧{u,u}⊆lus∧ let scs = obs Cs(u), scs = obs Cs(u), lcs = obs Cs(u), lcs = obs Cs(u) in  • ∃ ! c,c :C c =c∧scs ∩ lcs={c}∧scs ∩ lcs={c} end end We encourage the reader to compare the numbered narrative text with the numbered formula — line by line in order — to decipher the meaning of the symbols of the formula — most of which are just sort (i.e., abstract type) and signature definitions and axioms. 2.3.3 Discussion The two different definitions (item 1) of nets are not “different”. The same is true for stations and lines. They are complementary, i.e., support one another — as can also be seen from the axioms. Without the double “definitions” the axiom system which really “assigns meaning” would allow to much “junk” in any of its models. Connectors are mentioned in item 13, but otherwise not defined. That is, they are sorts. The meaning of the ontological terms “has”, “consists of”, “is connected to”, etc., is given by the axioms — but probably ought also be narrated, as is ‘linear sequence’. 2.3.4 Narration of Dynamics We introduce defined concepts such as paths through rail units, state of rail units, rail unit state spaces, routes through a railway network, open and closed routes, trains on the railway net, and train movement on the railway net. 18. A path, p : P , is a pair of distinct connectors, (c, c ), 19. and of some unit. 20. A state, σ : Σ, of a unit is the set of all open paths of that unit (at the time observed). 21. A unit may, over its operational life, attain any of a (possibly small) number of different states ω : Ω.

22. A route is a sequence of pairs of units and paths such that the path of a unit/path pair is a possible path of some state of the unit, and such that “neighbouring” connectors are identical. 23. An open route is a route such that all its paths are open. 24. A train is modeled as a route. 25. Train movement is modeled as a discrete function (ie., a map) from time to routes such that for any two adjacent times the two corresponding routes differ by at most one of the following (cf. Fig. 3): (a) a unit path pair has been deleted (removed) from one end of the route; (b) a unit path pair has been deleted (removed) from the other end of the route; (c) a unit path pair has been added (joined) from one end of the route; (d) a unit path pair has been added (joined) from the other end of the route; (e) a unit path pair has been added (joined) from one end of the route, and another unit path pair has been deleted (removed) from the other end of the route; (f) a unit path pair has been added (joined) from the other of the route, and another unit path pair has been deleted (removed) from the one end of the route; (g) or there has been no change with respect to the route (yet the train may have moved); 26. and such that the new route is a well–formed route. We shall arbitrarily think of one end as the “left end”, and the other end as the “right end” — where “left”, in a model where elements of a list are indexed from 1 to its length, means the index 1 position, and ‘right’ means the last index position of the list. 2.3.5 Formalisation of Dynamics type 18. P = {| (c,c):(C×C) • c =c |} 20. Σ = P-set 21. Ω = Σ-set 22. R ={| r:(U×P)∗ • wf R(r) |} 24. Trn = R 25. Mov = {| m:(T → m Trn) • wf Mov(m) |} value 20. obs Σ: U → Σ 21. obs Ω: U → Ω

Proceedings of the Third IEEE International Conference on Software Engineering and Formal Methods (SEFM’05) 0-7695-2435-4/05 $20.00 © 2005

IEEE

[4] [3] [2] (0)

[1]

(1)

[0]

(2) (3) (4) u1

u2

u3

u4

u5

u6

u7

u8

u9

Figure 3. Idealised train movement

axiom ∀ u:U•let ω=obs Ω(u),σ=obs Σ(u) in σ ∈ ω ∧ 19. let cs=obs Cs(u) in ∀ (c,c):P•(c,c)∈ ∪ ω ⇒ {c,c} ⊆ obs Cs(u) end end 22. wf R: (U×P)∗ → Bool wf R(r) ≡ len r > 0
∧ ∀ i:Nat • i ∈ inds r let (u,(c,c)) = r(i) in (c,c) ∈ obs Ω(u) ∧ i+1 ∈ inds r ⇒ let ( ,(c, )) = r(i+1) in c = c end end 23. open R: R → Bool open R(r) ≡ ∀ (u,p):U×P•(u,p) ∈ elems r∧p ∈ obs Σ(u) 25. wf Mov: Mov → Bool wf Mov(m) ≡ card dom m ≥ 2 ∧ ∀ t,t:T • t,t ∈ dom m ∧ t < t ∧ adjacent(t,t) ⇒ let (r,r)=(m(t),m(t)),
(u,p):U×P•p ∈ obs Ω(u) in  ∨ 25b. r d(r,r,(u,p)) ∨ 25a. (l d(r,r ,(u,p))  25c. l a(r,r ,(u,p)) ∨ 25d. r a(r,r,(u,p)) ∨ 25e. l d r a(r,r,(u,p)) ∨ 25f. r d l a(r,r,(u,p)) ∨ 25g. r=r) 26. ∧ wf R(r) end adjacent: T × T → Bool adjacent(t,t) ≡ ∼∃ t:T • t ∈ dom m ∧ t < t < t l d,r d,l a,r a,l d r a,r d l a: R × R × P → Bool l d(r,r,(u,p)) ≡ r = tl r pre len r>1 r d(r,r,(u,p)) ≡ r = fst(r) pre len r>1 l a(r,r,(u,p)) ≡ r = (u,p)r r a(r,r,(u,p)) ≡ r = r(u,p) l d r a(r,r,(u,p)) ≡ r = tl r(u,p) r d l a(r,r,(u,p)) ≡ r = (u,p)fst(r) ∼ fst: R → R fst(r) ≡  r(i) | i in 1..len r−1 

2.4. Discussion We have shown the “tip of a mountain”: the initials of a theory of railways. You should now get a “feel” for what might be involved in setting up the basis for such a theory: for example both a concise and hopefully enjoyably readable as well as a formal model: some algebraic sorts, observer and other function (including predicate) signatures, and axioms constraining the sorts and functions. A similar amount of narration and formalisation is needed before we can start identifying interesting theorems that ought be proven. After, for example, having added domain models of time tables, of traffic and of traffic planning, we can state such theorems as “Kirschhoff’s Law” for train traffic: Under the assumption that trains run on time, and viewed in a time interval such that planned train traffic “repeats” itself in subsequent (i.e., adjacent) time intervals, we can state that the number of trains arriving at a station minus the number of trains ending their service at that station plus the number of trains beginning their service at that station equals the number of trains leaving that station — within the given (modulo) interval.

2.5. Domain Theories in Engineering In the middle ages cathedrals were built in Europe. Some of these imploded, collapsed even before they were finished. Today any architect of a building with non–trivial structural supports commissions a professionally educated and trained structural civil engineer to secure sound constructions. That engineer is well-versed in the physics of structures. No company developing non–trivial radio communications gear would hire, as a design engineer, one who is not professionally, i.e., academically trained and well–versed in, for example, Maxwell’s equations. No pharmaceutical company developing medicine would hire, as an R&D engineer a person who is not professionally, i.e., academically trained and well–versed in, for example, microbiology and pharmacology. And so on. But in software engineering companies still develop systems without bothering to ask: do we know of an underlying theory? Accordingly software systems are commissioned and put into service — only to shortly afterwards collapse like were they Gothic cathedrals of the middle ages. It is a disgrace to our profession. Something must be done. What we propose here is to embark on a number of 15-30 year collaborative Grand Challenge (“man on the moon”) projects which aim at building and researching theories of such infrastructure domains as transportation, health care, financial service industry, manufacturing, public administration and so on. One such grand challenge project is the emerging TRain: The RAilway domaIN (http://www.railwaydomain.org) project. These projects are otherwise organised like was the human–

Proceedings of the Third IEEE International Conference on Software Engineering and Formal Methods (SEFM’05) 0-7695-2435-4/05 $20.00 © 2005

IEEE

genome project. Free, open, etc.

3.3. Example Formal Techniques

3. Formal Techniques

There are, by now, 32 years after the first “formal method” first saw the day, several such stable “methods”. We list, more or less chronologically, VDM [7, 8, 16], Z [51, 52, 53, 30], RAISE [19, 20], B [1], CafeOBJ [18, 17, 15], Casl [3, 13, 41]. To this add several formal techniques (as well with their diagrammatic notations): Petri nets [37, 42, 43, 45, 44] (from well before VDM), CSP [31, 47, 50], message sequence charts [33, 34, 35] and live sequence charts [14, 28, 38], Statecharts [24, 25, 27, 29, 26], the duration calculi [55, 56], TLA+ [39, 40], and many more. B, VDM–SL, and Z are primarily model–oriented. CafeOBJ, CASL and Duration Calculus are exclusively property–oriented. Petri nets, message and live sequence charts and statecharts are operational in that they are concerned with specification of (oftentimes detailed) process steps and process interaction. RAISE features both model– and property–orientedness.

What is usually known by the term formal method I shall refer to as formal technique. By a method I understand a set of principles for selecting and applying analysis and construction techniques and tools in order, for humans, to understand and/or (initially) design an artifact. By a formal software development technique I shall understand a (property–oriented) technique based on logic, one that allows me to specify what it is I wish to express: either describe (as for domains) or prescribe (as for requirements) or design (as for software), and one which allows me to potentially prove properties of a specification of a relationship between pairs of specifications. By a model–oriented software development technique I shall understand one which in addition to basic property–orientedness also uses mathematical constructs such as sets, Cartesians, lists, maps (i.e., functions) to express specifications.

3.1. Why Not Formal Methods? So why do I refer to formal techniques and not to formal methods? The answer is: the principles for selecting and deciding when to apply techniques and tools — those principles — are, in our context, to be carried out by humans. The principles can therefore not be formal — as humans are not formal devices. But some of the techniques and hence some of the tools can be formal, or be based on formal theories. The hedge ’initially’ was inserted above. It makes room for part of the design process to be automated. And an automated development step is usually one that is based on a formal theory. But the initial part of development cannot be automated as it transforms necessarily informal domain knowledge, in the minds of people, into formal theories.

3.2. “Lite”, Rigorous and Formal Approaches Formal techniques can be use in a spectrum of ways: from formally, via rigorously to lightly (“lite”). In formal software development all phases, stages and steps are specified formally and all relevant proof obligations (of properties, including correctness) are formulated and discharged. In rigorous development not all aspects of all steps may be formally specified and far from all proof obligations are formulated, let alone proven (discharged). “Lite” development usually only produces formal specifications (as in this paper), and do not formulate proof obligations let alone prove any.

3.4. Integrated Formal Techniques and UML No one individual of the above listed “methods” and notations are capable of covering any full development of software. So combinations are needed [6]. This problem has been addressed in one way by UML [10, 49, 36, 23]. It is being addressed, in a far more professional manner by researchers applying their skills to the pairwise (etc.) integration of formal techniques [2, 22, 11, 9]. UML will not suffice: One cannot conduct reasonably formal reasoning in UML, there is no way of telling whether one UML specification relates to another UML specification (for example, is a refinement of ), and the various diagrammatic notations that are usefully imported into UML (Petri nets, message sequence charts, state machines, etc.) are not properly “interfaced” (i.e., integrated). It is somewhat problematic to try make UML professionally acceptable as one would then try to capture an erratically (read: politically) moving target. We prefer, rather, to be inspired by the unquestionably good ideas of importing diagrammatic notations into UML by, instead, integrating them into clusters of formal techniques [6].

3.5. On Professionalism in Software Engineering Academically educated engineers in the classical disciplines are trained in the use of applied mathematics. No “big deal”. So why is it that in software engineering we allow programmers that are unaware of, or do not use formal techniques on key projects, developments that contain a significant element of research in that the programmers are not familiar with the domain? To this we turn next.

Proceedings of the Third IEEE International Conference on Software Engineering and Formal Methods (SEFM’05) 0-7695-2435-4/05 $20.00 © 2005

IEEE

4. A Sociology of Formal Software Engineering

Despite more than 32 years of formal techniques they have yet to be commonly accepted as an established engineering approach. So why have we yet to attain this state? I believe that there are several converging reasons for this.

software houses choose to neglect that evidence. Most managers in the software industry are unaware of formal techniques. They do not take “rumours” about their relevance to their business seriously. And they do not, of their own will, contact academic computing scientists to obtain advice on how to better to handle our new candidates, and so on. The result is that most of our formally trained candidates all too quickly end up in development teams which follow a path of least resistance, and, at most, uses UML [10, 49, 36, 23]. But UML does not help the practicing software engineer to abstract, does not help in stepwise development, and does not help the programmer to reason (for example, about correctness), however informally. Our formally trained candidates are being managed by people whose educational level falls far short of our candidates’ capabilities. So established software house management is to be blamed — and to be told that their conduct soon approaches criminal neglect. A group of more than 40 software houses and others, worldwide, have, however, formed a formal techniques industry association, ForTIA, to counterbalance this situation. We refer to www.fortia.org.

4.1. Computer & Computing Scientists

4.3. Software is Generally Not Critical

By computer science we understand the study and knowledge about the things that can exist inside computers, and by computing science we understand the study and knowledge about how to construct such things. Several computer science departments around the world are staffed by people several of whom do not understand that one might wish to contemplate a distinction such as the above. Furthermore, far too many do not really know what is meant by formal methods. As scientists those people may write “formally” looking papers on some computer science topic or other. They use a(n oftentimes forbidding) notation that is inherited from a mixture of mathematics sources. The same theories that they are trying to express can — and in my opinion should — be expressed in some formal specification language. The result is that our students cannot possibly take formal methods serious when not even their teachers do it. A similar situation in mathematics is basically unthinkable: algebra, calculus (differential and integral calculi), combinatorics and graph theory, probability theory and statistics, and so on, are recognised by all mathematicians to be core topics. So many of our colleagues in our departments really are to be blamed — before anyone else. They, of course, assume that we understand their notation!

They can get away with sloppy software. Really, it’s unbelievable: all other engineering products carry warranties — but not software. It must be because most software, when faulty, at most creates a nuisance, at worst creates a hard to assess loss of money. And it must be because users have gotten used to sloppy, erroneous software — and believe that that is how is has to be. So, as a result, software really is not taken serious: In most cases, when it fails, users claim that they can readily see that the software has produced unexpected, i.e., erroneous results. And, as a result the profession of software engineering is not taken serious. Customers who ought to know better are to blame, because they do not demand near zero defect software.

An engineering approach is seen to be established when the following conditions are satisfied: • Every academically trained (BSc and MSc) software engineering candidate can either lead or be a non– trivially contributing member of a team which uses the engineering approach. • Every engineering design center have their non–trivial and core business developments deploy that engineering approach. • The majority of customers mandates the use of that engineering approach.

4.2. Industry Approaches Criminal Neglect Although there is increasing evidence in favour of the use of formal techniques in commercial developments most

4.4. Programmers are Na¨ıve and Narcissistic Yet programmers continue to be in demand and at far too high salaries. Also in India (comparatively speaking)! Even not so bright candidates soon command salaries that are higher than their teachers at university. The almost yuppie–like aura (salary, hectic travel activity, etc.) that surrounds the individual programmers quickly, it seems to me, lulls those programmers into believing that they are indispensable. Whatever formal techniques they might have learned are quickly forgotten, they can still advance in the field, mumble–jumble. The programmers are, mostly, still allowed to work as individuals — but it is changing. Instead of using formal techniques programmers are asked to subject their programming to a plethora of pseudo–scientific,

Proceedings of the Third IEEE International Conference on Software Engineering and Formal Methods (SEFM’05) 0-7695-2435-4/05 $20.00 © 2005

IEEE

pseudo–technical check activities. Programmers who ought to know better are to blame, because they do not demand to work professionally.

4.5. Government is Focusing on IT Gadgets Somehow it has slipped into the minds of the general public, through the media, mostly, and hence it has slipped into the minds of politicians that the real revolution is IT: The hard, manifest technological gadgets that become forever smaller, computationally faster, economically more affordable, with larger storage capacity. Yet what could be computed some 30-40 years ago is still the only thing that can be computed today and tomorrow. IT, information technology, constitutes a universe of quantity and is associated with an oftentimes forbidding jargon. Informatics, the study and knowledge of what can be computed and how to compute it, the combination of domain engineering, requirements engineering and software design, constitutes a universe of quality: Better, more pleasing, more affine to real needs, etc. Governments are to be blamed because they are focusing on IT and not on informatics: They are not aware of the enormous challenges that lie ahead in uncovering domain theories of the infrastructure components that only governments can enhance, and hence they are not getting the quality they could have of software that supports activities within and between these infrastructure components.

5. Academics in Liberal Professions In which situations are academics, that is, professors at universities also working in practice? We shall examine the situation and shall propose a new “order” for software engineering!

5.1. Current Practices

through that, can bring far more experimental designs to bear on client projects. Customers expect it, namely to get most “daring”, artistic designs to bear on the design of their edifice! The schools of architecture in a significant majority of cases wishes to hire the most artistically gifted architects back to the school as full professors — and in this way “all parties” are better off. At schools of civil engineering professors are often asked to engage in state-of-the-art engineering construction projects: New, long and daring bridges, special hydro electric power plant (water reservoir) dams, etc. The Paris Cube (La Grande Arche), at La Defence, was architected by an architectural school professor and its structural engineering was likewise secured by a civil engineering school professor (Johan Otto von Spreckelsen and Erik Reitzel, respectively). 5.1.2 In Software Engineering What is the situation in software? Well, many SE and computer science professors come up, in their university-paid research, with (usually “gadget”) insight which they then proceed to commercialise through own, privately owned companies. But this situation is significantly different from those of the examples of the previous subsection. The medical academics’ employment involved both research and practice. The architectural academics’ employment is often predicated upon their sharing their time and remuneration between the university and their practice. In most of the cases that I have seen, in North America and in Europe, of computer science academics also being engaged in practice it is basically of the nature: Cashing in on short term skills and fashions. Almost all of those private practice owning university academics that I know of are no longer in a position to challenge their best students with the most advanced problems since they appropriate those to their own companies. The sum total of all this is that academia computer scientists involvement in practice rarely constitutes a proper transfer of science into technology, from academia to industry. I am not proud of such colleagues.

5.1.1 In Other Sciences & Engineerings Very often specialised surgeries, and invariably surgeries for life–threatening diseases are carried out at hospitals under the “baton” of a professor at the university to which that hospital is “attached”. Expressed in the reverse order: Medical school professors (at all levels) split their time more or less even between medical practice at the university hospital and research. The two often go very much hand-in-hand. The employment of this staff is predicated upon this practice. Patients almost expect it, namely to get latest research knowledge to bear on daily practice. At schools (universities or academies) of architecture it is also very common practice that professors of architecture keep an own, private practice, i.e., design office and,

5.2. Possible Informatics Scenarios Many commercial software development projects, from small to very large, contain significant elements of research. It therefore seems a very good idea if the software industry could be convinced to “share” leading staff with a nearby university’s computing science cum software engineering department. I suggest the following arrangement, an adaptation between the ways things are done between medical schools and hospitals (&c.), between architectural schools and architectural firms (&c.), and between civil engineering schools and civil engineering consulting firms (&c.). First the top university leadership must be involved: A new kind

Proceedings of the Third IEEE International Conference on Software Engineering and Formal Methods (SEFM’05) 0-7695-2435-4/05 $20.00 © 2005

IEEE

of professorial chairs as well as new types of other, perhaps time limited, however renewable, assistant and associate professor positions seems to be required. Such software engineers in industry, usually holding a PhD, who are also leading major designers of software (yes, are software architects!) should be hired back, part time, into university. They are expected to publish, that is, to do research, but they are also expected to head, at any time, a major new development project at their “other” part time employer, the software house. They are expected to act as a conduit, a channel, of research results into industry — by securing their application on the ongoing commercial project(s). I can foresee combinations of software houses and university computing science departments bid for major new software development projects. I can foresee the need for many more staff to work in the university computing science departments also part time between these and software houses. And I can foresee many, many more students being part time salaried on such development projects, thus staffing these projects well above, in quantity as well as in quality, how the software houses commonly staff their projects — thus also in this way making it a palatable choice. It is, however, needed to temper the enthusiasm of both computing science cum software engineering departments (and hence their universities) and software houses by mandating that the outcome, the software, be subject to warranties. Without such legally binding guarantees the “old system” of doing things will just continue. The clients are not helped. They must be secured that economic damages be payable should the software be faulty.

6. Conclusion 6.1. Summary I have outlined a “lucky cloverleaf” of software engineering, that is, one with four leaves. I have advocated a near exclusive focus on domain engineering in the early stages of any software development project. I have taken it for granted that formal techniques, as well as informal descriptive, prescriptive and specificational narratives, be deployed in all phases, stages and steps of development. I have suggested several causes for the lack of spread of formal techniques: Notably amongst these is the ignorance and arrogance of our own colleagues in CS departments. And I have proposed that universities start hiring leading edge industry software engineers with a PhD to limited, but renewable term full professorial appointments in an attempt to ensure that future commercial R&D-oriented development projects possess state-of-and-beyond-the-art staff and that clients, and hence users, get the best that can be done.

6.2. Future Work (1) It now behooves us to change the way our colleagues speak about automata and formal languages, how they define and teach Petri nets, live sequence charts, statecharts, etc. (2) We also must ensure the integration of formal techniques, also as “inspired” by UML, so that when our candidates, are being forced to use UML — and in any case, when developing software, do so at a professional level. (3) We, who propagate formal techniques, and when acting as responsible citizens, must help ensure that procurement of critical public software builds on domain models and uses formal techniques. Clients and users must demand near zero defect software. (4) We must encourage our candidates to only work in professionally responsible firms — why waste our work on their education? (5) And we must increasingly work through our recent candidates and through our university senates to secure the creation of a new kind of salaried professorial chairs — between industry and academia.

6.3. Synergy I believe that the sum total of, for example, the combination of issues (1–5) of the previous subsection will work in the same direction and that their respective pursuit will mutually influence and help secure the mutual and combined success of all these issues.

6.4. The SE Book The author of this invited paper has been rather aggressive in this paper. Perhaps a reason is that he is publishing, in the summer of 2005, a three volume, 2250 page, book on software engineering [5] (cf. www.comp.nus.edu.sg/˜bjorner/Software Engineering). That book has been 25 years in the making. First, till the end of the 1980s, formulated in VDM it has since been reformulated in RSL. But that is not important. It could as well be formulated, I believe, in Z or B or in the notation of some other formal technique. I strongly believe that there is basically no excuse anymore for not using formal techniques. My book covers all aspects of software development, from domains via requirements to software design. In the latter it can and need be complemented by existing text books, viz. [20]. The book can otherwise serve in a variety of up to nine different courses in various topics of software engineering (cf. www.comp.nus.edu.sg/˜bjorner/vol1/guide.ps).

6.5. Acknowledgments I wish to express my gratitude to Messrs. Bernhard & Bernhard, Aichernig and Beckert, program chairs of SEFM

Proceedings of the Third IEEE International Conference on Software Engineering and Formal Methods (SEFM’05) 0-7695-2435-4/05 $20.00 © 2005

IEEE

2005 for their kind invitation to me to present this mostly informal paper. I also thank my colleague, Prof. Christian Gram, for valuable comments while preparing this paper. Thanks are also due to Zhao Xiangpeng.

[13]

[14]

References [1] J.-R. Abrial. The B Book: Assigning Programs to Meanings. Tracts in Theoretical Computer Science. Cambridge University Press, Cambridge, England, 1996. [2] K. Araki, A. Galloway, and K. Taguchi, editors. IFM 99: Integrated Formal Methods, volume 1945 of Lecture Notes in Computer Science, York, UK, June 1999. Springer–Verlag. Proceedings of 1st Intl. Conf. on IFM. [3] M. Bidoit and P. D. Mosses. C ASL User Manual. LNCS 2900 (IFIP Series). Springer, 2004. With chapters by T. Mossakowski, D. Sannella, and A. Tarlecki. [4] D. Bjørner. Computer versus Computing Science: Models of Communicating Transaction Processes. Research report, National University of Singapore, School of Computing, 3 Science Drive 2, Singapore, June 2005. This research report is based on and contrasts with [48] and is otherwise based on joint work with Yang Shaofa [54]. [5] D. Bjørner. Software Engineering, volume 1: Abstraction and Modelling, vol. 2: Specification of Systems and Languages, vol. 3: Domains, Requirements and Software Design of Texts in Theoretical Computer Science, the EATCS Series. Springer–Verlag, 2005. Chapters 12–14 of vol.2 primarily authored by Christian Krog Madsen. [6] D. Bjørner, C. George, A. E. Haxthausen, C. K. Madsen, S. Holmslykke, and M. Pˇeniˇcka. “UML”–ising Formal Techniques. In INT 2004: Third International Workshop on Integration of Specification Techniques for Applications in Engineering, volume 3147 of Lecture Notes in Computer Science, pages 423–450. Springer–Verlag, 28 March 2004, ETAPS, Barcelona, Spain. To be published in INT–2004 Proceedings, Springer–Verlag. [7] D. Bjørner and C. Jones, editors. The Vienna Development Method: The Meta-Language, volume 61 of LNCS. Springer–Verlag, 1978. This was the first monograph on Meta-IV. . [8] D. Bjørner and C. Jones, editors. Formal Specification and Software Development. Prentice-Hall, 1982. [9] E. A. Boiten, J. Derrick, and G. Smith, editors. IFM 2004: Integrated Formal Methods, volume 2999 of Lecture Notes in Computer Science, London. England, April 4-7 2004. Springer–Verlag. Proceedings of 4th Intl. Conf. on IFM. ISBN 3-540-21377-5. [10] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1998. [11] M. J. Butler, L. Petre, and K. Sere, editors. IFM 2002: Integrated Formal Methods, volume 2335 of Lecture Notes in Computer Science, Turku, Finland, May 15-18 2002. Springer–Verlag. Proceedings of 3rd Intl. Conf. on IFM. ISBN 3-540-43703-7. [12] D. Cansell and D. M´ery. Logical Foundations of the B Method. Computing and Informatics, 22(1–2), 2003. This paper is one of a series: [46, 15, 41, 21, 40, 30] appearing in

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24] [25]

a double issue of the same journal: Logics of Specification Languages — edited by Dines Bjørner. CoFI (The Common Framework Initiative). C ASL Reference Manual, volume 2960 of Lecture Notes in Computer Science (IFIP Series). Springer–Verlag, 2004. W. Damm and D. Harel. LSCs: Breathing life into Message Sequence Charts. Formal Methods in System Design, 19:45–80, 2001. Early version appeared as Weizmann Institute Tech. Report CS98-09, April 1998. An abridged version appeared in Proc. 3rd IFIP Int. Conf. on Formal Methods for Open Object-based Distributed Systems (FMOODS’99), Kluwer, 1999, pp. 293–312. R. Diaconescu, K. Futatsugi, and K. Ogata. CafeOBJ: Logical Foundations and Methodology. Computing and Informatics, 22(1–2), 2003. This paper is one of a series: [46, 12, 41, 21, 40, 30] appearing in a double issue of the same journal: Logics of Specification Languages — edited by Dines Bjørner. J. Fitzgerald and P. G. Larsen. Developing Software using VDM-SL. Cambridge University Press, The Edinburgh Building, Cambridge CB2 1RU, England, 1997. K. Futatsugi and R. Diaconescu. CafeOBJ Report The Language, Proof Techniques, and Methodologies for ObjectOriented Algebraic Specification. AMAST Series in Computing – Vol. 6. World Scientific Publishing Co. Pte. Ltd., 5 Toh Tuck Link, SINGAPORE 596224. Tel: 65-6466-5775, Fax: 65-6467-7667, E-mail: [email protected], 1998. K. Futatsugi, A. Nakagawa, and T. Tamai, editors. CAFE: An Industrial–Strength Algebraic Formal Method, Sara Burgerhartstraat 25, P.O. Box 211, NL–1000 AE Amsterdam, The Netherlands, 2000. Elsevier. Proceedings from an April 1998 Symposium, Numazu, Japan. C. George, P. Haff, K. Havelund, A. Haxthausen, R. Milne, C. B. Nielsen, S. Prehn, and K. R. Wagner. The RAISE Specification Language. The BCS Practitioner Series. PrenticeHall, Hemel Hampstead, England, 1992. C. George, A. Haxthausen, S. Hughes, R. Milne, S. Prehn, and J. S. Pedersen. The RAISE Method. The BCS Practitioner Series. Prentice-Hall, Hemel Hampstead, England, 1995. C. George and A. E. Haxthausen. The Logic of the RAISE Specification Language. Computing and Informatics, 22(1– 2), 2003. This paper is one of a series: [46, 12, 15, 41, 40, 30] appearing in a double issue of the same journal: Logics of Specification Languages — edited by Dines Bjørner. W. Grieskamp, T. Santen, and B. Stoddart, editors. IFM 2000: Integrated Formal Methods, volume of Lecture Notes in Computer Science, Schloss Dagstuhl, Germany, November 1-3 2000. Springer–Verlag. Proceedings of 2nd Intl. Conf. on IFM. O. M. Group. OMG Unified Modelling Language Specification. OMG/UML, http://www.omg.org/uml/, version 1.5 edition, March 2003. www.omg.org/cgi-bin/doc?formal/0303-01. D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 1987. D. Harel. On visual formalisms. Communications of the ACM, 33(5), 514–530 1988.

Proceedings of the Third IEEE International Conference on Software Engineering and Formal Methods (SEFM’05) 0-7695-2435-4/05 $20.00 © 2005

IEEE

[26] D. Harel and E. Gery. Executable object modeling with Statecharts. IEEE Computer, 30(7):31–42, 1997. [27] D. Harel, H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman, A. Shtull-Trauring, and M. B. Trakhtenbrot. STATEMATE: A working environment for the development of complex reactive systems. Software Engineering, 16(4):403–414, 1990. [28] D. Harel and R. Marelly. Come, Let’s Play – Scenario-Based Programming Using LSCs and the Play-Engine. SpringerVerlag, 2003. [29] D. Harel and A. Naamad. The STATEMATE semantics of Statecharts. ACM Transactions on Software Engineering and Methodology (TOSEM), 5(4):293–333, 1996. [30] M. C. Henson, S. Reeves, and J. P. Bowen. Z Logic and its Consequences. Computing and Informatics, 22(1–2), 2003. This paper is one of a series: [46, 12, 15, 41, 21, 40] appearing in a double issue of the same journal: Logics of Specification Languages — edited by Dines Bjørner. [31] C. Hoare. Communicating Sequential Processes. C.A.R. Hoare Series in Computer Science. Prentice-Hall International, 1985. See also [32]. [32] C. Hoare. Communicating Sequential Processes. Published electronically: http://www.usingcsp.com/cspbook.pdf, 2004. Second edition of [31]. See also http://www.usingcsp.com/. [33] ITU-T. CCITT Recommendation Z.120: Message Sequence Chart (MSC), 1992. [34] ITU-T. ITU-T Recommendation Z.120: Message Sequence Chart (MSC), 1996. [35] ITU-T. ITU-T Recommendation Z.120: Message Sequence Chart (MSC), 1999. [36] I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software Development Process. Addison-Wesley, 1999. [37] K. Jensen. Coloured Petri Nets, volume 1: Basic Concepts (234 pages + xii), Vol. 2: Analysis Methods (174 pages + x), Vol. 3: Practical Use (265 pages + xi) of EATCS Monographs in Theoretical Computer Science. Springer– Verlag, Heidelberg, 1985, revised and corrected second version: 1997. [38] J. Klose and H. Wittke. An automata based interpretation of Live Sequence Charts. In T. Margaria and W. Yi, editors, TACAS 2001, LNCS 2031, pages 512–527. Springer-Verlag, 2001. [39] L. Lamport. Specifying Systems. Addison–Wesley, Boston, Mass., USA, 2002. [40] S. Merz. On the Logic of TLA+. Computing and Informatics, 22(1–2), 2003. This paper is one of a series: [46, 12, 15, 41, 21, 30] appearing in a double issue of the same journal: Logics of Specification Languages — edited by Dines Bjørner. [41] T. Mossakowski, A. E. Haxthausen, D. Sanella, and A. Tarlecki. CASL — The Common Algebraic Specification Language: Semantics and Proof Theory. Computing and Informatics, 22(1–2), 2003. This paper is one of a series: [46, 12, 15, 21, 40, 30] appearing in a double issue of the same journal: Logics of Specification Languages — edited by Dines Bjørner. [42] C. A. Petri. Kommunikation mit Automaten. Bonn: Institut f¨ur Instrumentelle Mathematik, Schriften des IIM Nr. 2, 1962.

[43] W. Reisig. Petri Nets: An Introduction, volume 4 of EATCS Monographs in Theoretical Computer Science. Springer Verlag, May 1985. [44] W. Reisig. A Primer in Petri Net Design. Springer Verlag, March 1992. 120 pages. [45] W. Reisig. Elements of Distributed Algorithms: Modelling and Analysis with Petri Nets. Springer Verlag, December 1998. 400 pages. [46] W. Reisig. The Expressive Power of Abstract–Sate Machines. Computing and Informatics, 22(1–2), 2003. This paper is one of a series: [12, 15, 41, 21, 40, 30] appearing in a double issue of the same journal: Logics of Specification Languages — edited by Dines Bjørner. [47] A. Roscoe. Theory and Practice of Concurrency. C.A.R. Hoare Series in Computer Science. Prentice–Hall, 1997. [48] A. Roychoudhury and P. Thiagarajan. Communicating Transaction Processes. In Proc. of the 3rd IEEE International Conference on Application of Concurrency in System Design (ACSD’03). IEEE Press, 2003. [49] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, 1998. [50] S. Schneider. Concurrent and Real–time Systems — The CSP Approach. Worldwide Series in Computer Science. John Wiley & Sons, Ltd., Baffins Lane, Chichester, West Sussex PO19 1UD, England, January 2000. [51] J. M. Spivey. Understanding Z: A Specification Language and its Formal Semantics, volume 3 of Cambridge Tracts in Theoretical Computer Science. Cambridge University Press, Jan. 1988. [52] J. M. Spivey. The Z Notation: A Reference Manual. Prentice Hall International Series in Computer Science, 2nd edition, 1992. [53] J. C. P. Woodcock and J. Davies. Using Z: Specification, Proof and Refinement. Prentice Hall International Series in Computer Science, 1996. [54] S. Yang and D. Bjørner. A Formal Specification of CTP: Communicating Transaction Processes (see [48]). Technical report, School of Computing, National University of Singapore, Science Drive 2, Singapore, June 2005. [55] C. C. Zhou and M. R. Hansen. Duration Calculus: A Formal Approach to Real–time Systems. Monographs in Theoretical Computer Science. An EATCS Series. Springer–Verlag, 2004. [56] C. C. Zhou, C. A. R. Hoare, and A. P. Ravn. A calculus of durations. Information Processing Letters, 40(5):269–276, 1991.

Proceedings of the Third IEEE International Conference on Software Engineering and Formal Methods (SEFM’05) 0-7695-2435-4/05 $20.00 © 2005

IEEE