Blog Structure

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.


  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.