An EM perspective on software development can be found in an essay prepared for the Onward! '12 workshop held in Tucson, Arizona, October 2012. This essay includes references to much of the relevant resources relating to this theme.

The idea of EM in engineering design is easier to accept in some respects than EM in the computer science domain. In thinking about software development and computer programming, there is a classical framework for computation to contend with. It is natural to ask the question: how do we place EM in relation to this? Our experience of EM points to some distinctive elements for which the classical theory of computation gives an inadequate account. This suggests that EM should be viewed as potentially serving as a complementary / an alternative / a substitute framework for studying computing. No single characterisation seems appropriate - in some aspects EM can be viewed as each of these three roles.

In understanding the relationship between EM and classical CS, there is a key ontological issue - in what sense should we regard an EM model as a program? We can gain some insight into this issue by referring to the critique of logicism by Brian Cantwell Smith (BCS) [Two Lessons of Logic]. Central to BCS's concern is the relation between what he characterises as the 'first factor' and the 'second factor' (roughly corresponding to what is commonly identified as 'form' and 'content' respectively). BCS argues that in modern computing practice the relation between these factors differs from the relation that pertains in classical logic. For instance, it exhibits context dependence, and does not endorse the logical view that promotes 'promiscuous modelling' (cf. the view that 'all programming paradigms essentially serve the same purpose' and 'all computation is in its essence equivalent to a Turing machine execution'). BCS expresses particular concern about the notion of program semantics that is the dominant focus and underpinning for theoretical computer science.

EM links first and second factors intimately through situated modelling. The structure of an EM model - which may be aptly described as an 'interactive situation model' (ISM) - reflects the user's construal, and lends an explanatory power in interactive use that is beyond formal specification (see CS-RR-205 and CS-RR-207 for more on these themes). In this way, EM emphasises the cognitive significance of different styles of modelling, and so draws attention to the modeller's engagement in interpreting and interacting with the model. Related ideas, in the same spirit as EM, are to be found in Lind's discussion of agent-oriented software engineering [Lin00] - especially in relation to McCarthy's justification (cited by Lind) for ascribing mental qualities to machines. Though EM may aspire in due course to ascribing beliefs, desires and intentions to machines as McCarthy advocates, its concern for the present is with representing the more primitive activities that can potentially justify such a step. EM would endorse the views of BCS - and William James! - that formal logic is ill-suited for this representational role. In EM, the classification of observables in an LSD account, and the use of an artefact to embody such observables, is seen as providing a more primitive basis for thinking about intelligence and reason.

EM can also be viewed from the general context of software development, and specifically development under the 'programming as modelling' banner first introduced in Simula's object-oriented perspective.

Key thinking here is to be found in the debate surrounding the notion of a "silver bullet" for software development. Particularly relevant is David Harel's perception that there is a distinction between 1-person programming and programming reactive systems, and that the latter can be addressed provided that appropriate attention is given to visualisation, to executable models, and to extensive testing of models en route to formal specification. A cornerstone of Harel's approach is the concept of a statechart, now one of the standard diagrammatic techniques in UML. Harel's aspirations for reactive systems development using UML are set out in [From Play-in Scenarios to Code: An Achievable Dream], and are commercially represented in the Rhapsody framework.

The role of ISMs in development in EM resonates well with Harel's concern for visualisation, executability and testing. It also makes sense of the engineering orientation evident in EM that more naturally leans to reactive systems than to abstract algorithms and sequential programming. The digital watch and statechart simulation model ilustrates that the expressive power of scripts to represent state is quite exceptional - a relatively small script can store the entire state of the watch statechart state and much more. Related EM work on this theme is representd in SIT - a statechart editor developed by Rob Carpenter in his third year project (see ~wmb/public/projects/tools/SIT).

EM is also closely related in spirit to the more general context of OO thinking, at any rate as it was originally conceived by Birtwistle et al. Underlying their vision for object-orientation in Simula was the idea that content should informs the form, and that modelling the world in objects leads to programming. Birtwistle himself, and others, now believe that the idea of OO is failing to deliver to thsi agenda (cf Kaindl's concern for the mismatch between OOA and OOD [Kai99]) or has been subverted (e.g. by taking object-orientation away from real-world modelling towards artificial programming concerns, such as modularisation etc).

From an EM perspective, it would appear that objects are simply not as good a basis for carrying through the programming-as-modelling programme as observation / dependency and agency. Somewhat related is the historically significant re-orientation of software development towards an engineering paradigm in response to the software crisis in the 70s. EM can be seen as offering an approach to software development that is engineering-oriented insofar as it stresses the role of observation and experiment in design activity, but there are also significant points of difference. Central to traditional classical engineering (such as has been dominant in the academic engineering traditions) is an emphasis on:

objective physical world + rational problem-solving + optimisation + method

In contrast, EM is related more closely to conceptual and creative design. It's characteristic emphasis is quite different:

subjective, cognitive + reflection in action + understanding + exploration

The distinction between these two engineering cultures is highlighted by Brodner. It is a macro-level expression of the micro-level controversy between Bradley and James regarding the role of rationalisation in making sense of experience. The contrast in the engineering perspective is between system construction through preconceived specification vs emergence of a system through empirical study. This distances EM from engineering in some respects.

Several practical examples illustrate the 'engineering-like' but distinctively different qualities of EM models:

• heapsort model: consider system-like qualities as they emerge from observation in heapsort; data structures as artefacts in the design; logical propositions as a restricted kind of observation of state
• draughts model: extracting 'components' and adapting contexts for experiment
• translation from an EM model - OXO in PASCAL as illustrating how optimisation can be associated with the compilation of (open) dependencies in a script into (a frozen) program structure [not enough that can recompile the program to achieve a new functionality - must respect the conceptual state in which this new functionality is to be invoked]

Have the dishwasher example as a comparative study to allow EM to be contrasted with the use of the UML and Rhapsody framework. Illustrated how EM is artefact-based - qualities of the machine important - tuning issues, situated modelling, different modes of observation in UML and EM - such that can envisage incorporating dynamic UML diagrams within the EM model but not vice versa, engaging with the requirement, interaction outside the scope of the specific requirement (as in filling the tank as an engineer might), different ways to construe the modelling of the water management (water supply / valve cuts off when the tank is full irrespective of where we are in the dishwashing cycle etc), capacity, adding interfaces (so that we can inspect the values that are significant to the engineer) and changing the model. Illustrates also the complementary roles for the EDEN script and an associated LSD account. [For a more abstract discussion of the relationship between EM and other methods of software development, see the AMORE paper (ref 071.pdf in ~empublic/papers).]

Much of the EM thinking about software development stems from the concept of transposing the concurrent engineering framework into an approach to software development for reactive systems (see [CS-RR-207] for an account of how 1-person programming / classical sequential programming can be viewed as a special-case of reactive systems programming). This strand of research begins with the discussion of requirements by WMB and SBR [CS-RR-277], and is taken up by Ness, Sun, Y-C Chen. Also have RIC's JaM2 application at the BBC as evidence of the potential practical usefulness and power. Key point here (as set out in seminar wed_seminar4.htm from the MSc notes) is that building a system entails determining the component agents and identifying / specifying their states, oracles, handles and protocols and their context for interaction in a way which is physically realisable. EM and ISMs are used to develop and embody the necessary construal, and in the process identify the specific agency (as empirically established to be feasible) to be programmed into these agents.

Pi-Hwa Sun's thesis promotes EM as an 'amethodical' approach to software development. No systematic way in which to use LSD etc - guided by experiment and pragmatic concerns. Useful to relate to discussion of modes of software development by Nardi [Nar93] and Truex et al [Tru00]. Key idea is that the way in which ISMs are exploited in EM is crucial to the use that can be made of them in development - there is a general failure to appreciate the fundamental significance of knowledge representation by interactive artefacts rather than logical specification in respect of the the following aspects:

• providing an essential complement, and in the first instance a necessary alternative to logicist approaches to agent-oriented modelling / programming cf. [Lin00].
• supplying a conceptual framework and principled foundation for pragmatic development using spreadsheets such as is discussed by Nardi in [Nar93].
• offering a basis for interpreting 'amethodical' approaches to software development that deliver to the prospectus laid out by Truex et al [Tru00] - the behaviour of an ISM is 'not specified' and 'not implemented' in a sense that is not represented in a partial prototype (e.g. that implements a limited set of use-cases, as e.g. in XP), and supports a style of development that is not best construed as rapid iteration between phases.

In summary, EM treats formal specifications, systems and methodical processes not as a primitive, but as latent in agency we enlist or create in environments we discover or contrive.