The time sequence of adding posts to a blog gives a simple structure. But for readers of this and similar blogs, this sequential structure is irrelevant: structuring the content of the posts is more important. The structure sketched here is not offered as a comprehensive map of the whole field of software engineering: it is merely the structure of this blog—that is, of the themes and topics on which I intend to post.
The content structure is visible in two mechanisms. First, directional links between posts help navigation: ↑ or ↓ to posts offering a larger view or more detail; and ← or → to a closely preceding or succeeding subject respectively. Second, posts are formed into clusters by labels: clicking a label in the sidebar retrieves and displays all posts bearing that label. These labels are names of four general themes and their sixteen constituent topics, listed here with brief comments: each individual post is labelled with one or more of these names. Labels in square brackets—for example [Feynman]—cluster posts citing the same sources.
CPS Cyber-physical system: a system in which execution of computer software governs the physical world. A CPS is bipartite: two obvious parts are its physical World, and its Machine that executes the software. Data, reified and managed by the Machine, is a physical part of many large systems. The System Behaviour is the key property of a CPS.
World The physical world of a CPS, comprising: parts—including human participants—whose behaviour is governed—that is, partially controlled—by the Machine; parts in which required consequences and effects of this behaviour are located; and the all enclosing physical environment in which the system is designed to operate.
Machine The computing part of a CPS executing the software. In deployment the machine will occupy all or part of many physical computers; but treating it as a single unified machine is a valuable abstraction for developing system behaviour.
Data The physically realised data of a CPS—for example, in a database—created, maintained and read by its machine, and forming a further part of its world.
Behaviour The physical behaviour of a CPS, evoked by interaction of the machine and the world. The system behaviour is the fundamental property of a CPS: success is a consequence of desired behaviour, as failure is of undesired behaviour.
SE Software engineering for cyber-physical systems. SE tasks include designing behaviour in the world to satisfy requirements; developing software; and proving system properties.
Processes System behaviour is the emergent result of machine and world interaction: the SE task includes design of processes both in the machine and in the governed world.
Models Developing models specifically, but not only, of the world: sufficiently faithful models are essential to dependable behaviour of a CPS.
Programs Developing the software to be executed by the machine. In developing behaviour, software architecture should reflect the system behaviour structure. Later, for most systems, software transformation is necessary for efficient deployment and execution in system operation.
Requirements Requirements are the qualities and properties a system should possess. The most important requirements are desired consequences and effects of the system behaviour: only these requirements are seriously considered in this blog.
HUMAN Human aspects of software engineering, based on group and personal traits and intellectual powers, in social contexts large and small.
Traits Personal characteristics, especially those that affect software engineering practice. For example: easier comprehensibility of some descriptive techniques; personal preferences for particular tasks; relegation and and undervaluation of less favoured tasks; preferences for greater or lesser reliance on formality.
Practices Personal and group practices and behaviours exercised within a single development project. For example: project documentation; development product reviews.
Community Human factors across multiple organisations and development projects in what are or should be activities of an established community. Normal design is the product of an engineering community.
Profession Large concerns within engineering more generally. For example: development of specialisations in SE; relationship of SE to established engineering branches; formation of groups by preferred SE practices.
METHOD Development method: intellectual aspects of development method, including choice of languages, structuring techniques, process structure, and general principles.
Thought The intellectual activities necessary to software engineering. These include design, description and analysis, and should be guided by coherent principles and disciplines.
Technique Development techniques such as: behaviour structuring and combination; model structuring and design; descriptive techniques and principles for modelling; program transformation; addressing failure concerns.
Structure Structure is the basic tool for managing and mastering complexity. Structure is needed for: the development process; bounding and clarifying models; recognising the nature and shape of dependability; specific development tasks at every level.
Semantics Choosing the subjects and physical semantic content of models; choosing modelling languages; formalising model and behaviour designs; clarity in addressing the bipartite nature of a CPS, avoiding confusion between the world and the machine.