The time sequence of adding posts to a blog gives a simple structure. But for this and similar blogs, this sequential structure is irrelevant for readers: structuring the content of the posts is more important. Here the content structure is visible in two mechanisms. First, directional links between posts help navigation: ↑, ↓, ← or → to posts offering a larger view, more detail, or a closely related subject respectively. Second, posts are formed into clusters by labels: clicking a label in the sidebar finds 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; additional labels on a post mention cited sources.
Please understand that 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.
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. Shared 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.
The Whole 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 larger physical environment in which the system is designed to operate.
The 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. Shared 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.
System 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 of software for cyber-physical systems. SE tasks include designing behaviour in the world to satisfy requirements; developing software; and proving system properties.
Developing Behaviour System Behaviour is the emergent result of machine and world interaction: the SE task is to program the whole bipartite system—the world and the machine together—as a unified system.
Modelling Developing models specifically, but not only, of the world: faithful models are essential to dependable behaviour of a CPS.
Programming Developing the software to be executed by the machine. In developing behaviour, software architecture should reflect the system behaviour structure. Later, software transformation is necessary for efficient deployment and execution in system operation.
Proving 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.
Personal Traits Personal characteristics, especially those that affect software engineering practice. For example: easier comprehensibility of some descriptive techniques; personal preferences for particular tasks and undervaluing less favoured tasks; preferences for greater or lesser emphasis on formality. Project Practices Personal and group practices and behaviours exercised within a single development project. For example: project documentation; development product reviews.
Communal Activities Human factors across multiple development projects in what are or should be activities of an established commuity. Normal design is one product of an engineering community.
Social Effects 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.
Thinking The intellectual activities necessary to software engineering. These include design, description and analysis, and should be guided by coherent principles and disciplines.
Techniques Development techniques such as: behaviour structuring and combination; model structuring and design; descriptive techniques and principles for modelling; program transformation; addressing failure concerns.
Structures 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 physical semantic content of models; choosing modelling languages; formalising model and behaviour designs; clarity in addressing the bipartite nature of a CPS.