Blog Structure

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.


  1. Hello Michael, Very nice structure :)

  2.    Modelling  Developing models specifically, but not only, of the [physical?] world: “faithful models?” are essential to “dependable behavior?” of a CPS.

    How do “faithful models” relate to accurate, complete, and essentially complex models? How does “dependable behavior” relate to trustworthy, safe, or resilient behavior?

    These questions are driven by a recent realization that software engineering is rife with simplistic models that are significant barriers to achieving and preserving useful software.

  3.    Proving Requirements  Requirements are the qualities and properties a system should possess. “The most important requirements are desired consequences and effects of the system behavior”: only these requirements are seriously considered in this blog.

    Ouch! This behavioral characterization of “most important” ignores all “internal quality attribute” requirements such as code understandability, verifiability, and compliance. Without internal quality, code may never achieve its functional requirements nor enable their preservation. Internal qualities supports all other quality attributes. One might argue that internal quality attribute requirements are the most important.