Closing Remarks

On Programming, Engineering and Management

Most, if not all, software engineering texts and handbooks concentrate on the management aspects and on the informal, human-centered facets of program-ming and engineering.

We shall, in this monograph, focus on abstraction and both informal and formal modelling of systems and languages; focus on the development princi-ples and techniques of a new kind of engineering: domain engineering; bring an altogether new focus to bear on the phases of requirements engineering and software design. We have only briefly, in Chap. 2 and Chap. 5, covered some aspects of software management. The new focus, to remind the reader, is based on all software development being initially based on extensive and seri-ous domain engineering. The stage of domain requirements, and the stages of software design from either and all of the three domain, interface and machine requirements, highlight the new focus — as does the insistence on codevelop-ing both informal and formal specifications.

From this triptych view of software engineering springs a new awareness of software development management. Such management is predicated on the systematic (“light”) or rigorous or even formal use of the principles and tech-niques of these three volumes. Traditional engineering management is predi-cated by laws of natural science and must consider human factors. Software engineering management, in contrast, is predicated on the more mathemati-cal theories of computing science and the application domains, and then must consider human factors. Software development management is a fascinating area. But it is not one that we feel competent to “preach” about.

Current Software Engineering Edifices

In today’s software engineering there are usually no two similar software en-gineering solutions to identical or near-identical problems. Software systems, from different suppliers, but for near-identical application problems usually of-fer significantly difof-ferent user interfaces; and oftentimes vastly difof-ferent (“hid-den”) implementations. Each such software system usually requires significant training. Users switching from one product to what ought be a similar prod-uct most often require significant retraining. Such “reusers” typically do not recognize that these distinct software products are providing near-identical solutions. As a result users become “religious” about software systems that they are using. Companies, for fear of retraining costs, when seeking new staff usually advertise that they are using “such-and-such” software prod-ucts and that applicants must have the proverbial “two and a half years”

prior experience with this product. I consider this a disgrace to our industry.

An airline pilot with Airbus airplane flight experience can with predictable and acceptable costs be retrained for Boeing airplanes. And conversely. Many application solutions require that their users learn a whole vocabulary of con-cepts. Typically these vocabularies are not (theory of) domain-oriented; some-times they are somewhat requirements-oriented; and usually they are strongly implementation-oriented. In any case such vocabularies are detrimental to the intellect of their (forced) users.

Current Software Engineering Jargon

Not all software is end-user software — in the sense of these users being people who have not been trained in IT in general. Two categories of soft-ware (packages) that can be characterised as not being end-user softsoft-ware (packages) are computing systems base software like database systems, com-pilers, multiple-user operating systems, and so on, and so-called middleware.

The current jargon defines middleware software assoftware that allows “front ends” like web browsers/servers or other end-user software packages to com-municate with “back end” base software like database management systems (i.e., databases).

A New View on Software Engineering

The main messages of this monograph is: The diligent reader will gain a view of software engineering which is rather different from the view we think is usu-ally propagated by traditional textbooks. The message here is that software engineering is a highly intellectual activity. In addition to good engineering analysis, software engineering emphasises writing beautiful documents. The view is also characterised by reasoning over texts, and calculation, in the form of transformation (refinement and reification), verification, model checking

ware engineering is only to a small extent based on the natural sciences.

Software engineering is primarily based on computing science and hence on the mathematical disciplines of logic, recursive function theory and modern algebra. The above view applies also when the principles and techniques of these three volumes are applied in their informal version. When applied in the formal version the message covers a spectrum of “formality”: from systematic (“lightweight”), via rigorous, to (fully) formal uses of formal techniques. This view and this message is carried most forcefully by [31–33, Vols. 1 and 2]. If the reader only follows the first message (and therefore hardly deploys even the lightweight formal techniques approach), or follows either of the systematic to formal approaches and then finds, after having studied these volumes, that her view on software engineering has changed accordingly, then the author has achieved a main objective.

Possible Collaborative Domain Projects

A Management Brief

• JAIST/DEDR² has some interest-ing thinterest-ings to offer.

• It is in thedomain engineering area of software engineering:

• This chapter outlines some ideas on

⋆ possible joint collaboration

⋆ centered around the first phase of a triptych of software engi-neering

⋄ domain engineering,

⋄ requirements engineering and

⋄ software design;

⋆ and based on using formal ap-proaches

• There is another JAIST/DEDR sup-porting document. Chapter 1:

⋆ On Domains and Domain Engi-neering

In this note we suggest a number of alternative, collaborative projects within the broader research and engineering area of domain theory and domain engineering.

The common denominators are: The collaborators (i.e., partners), in-cluding the proposing JAIST/DEDR Group, each have their own vested interest in one or another facet of the proposed joint topic of R&D; the

1This is an edited version of [29]. Presented, together with [28], at a number of meetings with Japanese Software and IT industry leaders during the Spring of 2006.

2DEDR: Domain Engineering and Digital Rights, a JAIST COE Project:

http://www.ldl.jaist.ac.jp/drcp/

goal of the project can thus be defined both as the sum of the goals of each partner as well as the sum-total of their working together: namely an increased, mutually beneficial awareness of engineering by academia, and an increased awareness of academic research approaches and results by industry.

Expected outcome of the joint R&D are: (i) Sizable precise descrip-tions (in English and Japanese) of selected (i.e., chosen) domains, their formalisation and analysis; (ii) example software package or sub-system development for selected applications and related to the chosen domain descriptions; (iii) and increased awareness in the Japanese IT commu-nity of the benefits of strict domain engineering, related requirements engineering and trustworthy software.

2.1 Background

The background for this proposal is the emergence of a new technically sound and scientifically fascinating approach to software development: From domain models via requirements to software design. This approach is illustrated es-pecially by Item 3, [33], in the series:

1. Software Engineering, Vol. 1: Abstraction and Modelling. Texts in Theo-retical Computer Science, the EATCS Series. Springer, 2006.

2. Software Engineering, Vol. 2: Specification of Systems and Languages.

Texts in Theoretical Computer Science, the EATCS Series. Springer, 2006.

3. Software Engineering, Vol. 3: Domains, Requirements and Software De-sign. Texts in Theoretical Computer Science, the EATCS Series. Springer, 2006.

We also refer to Chap. 1:

4. Domains and Domain Engineering. Prerequisites for Trustworthy Soft-ware. A Necessity for Believable Project Management.