Playing with Patterns

Playing with Patterns Fiona A. C. Polack Abstract Susan Stepney has created novel research in areas as diverse as formal software modelling and evolutionary computing. One theme that spans almost her whole career is the use of patterns to capture and express solutions to software engineering problems. This paper considers two extremes, both in time and topic: patterns for formal modelling languages, and patterns related to the principled modelling and simulation of complex systems. 1 Introduction Software engineering uses patterns to express possible solutions to common problems. Patterns have been widely used both to capture expertise and to explore generic solutions to problems: in engineered emergence, for instance, it is often noted that if we could capture the patterns of multi-scale behaviour that results in desired emergent behaviours, we might be able to develop patterns that could be instantiated to efficiently engineering reliable emergent systems [57]. This paper summarises the origins of patterns (Sect. 2), and explores two areas of pattern research representing different approaches to pattern creation. Stepney’s work on formal modelling, and subsequent research on formal language patterns, aimed to support practitioners and those tasked with making formal models accessible; this work is reviewed in Sect. 3. Subsequently, the focus of Prof. Stepney’s work shifted to complex systems. An engineering interest in the simple algorithms that give rise to complex emergent behaviours (flocking, cellular automata, L-systems and the like) ultimately led to the CoSMoS project and patterns for simulation and modelling of complex systems, introduced in Sect. 4. The final sections focus on common features of patterns and potential directions for research, as well as reflecting specifically on Stepney’s contribution. F. A. C. Polack (B) School of Computing and Mathematics, Keele University, Keele, Newcastle ST5 5BG, UK e-mail: [email protected] © Springer Nature Switzerland AG 2020 A. Adamatzky and V. Kendon (eds.), From Astrophysics to Unconventional Computation, Emergence, Complexity and Computation 35, https://doi.org/10.1007/978-3-030-15792-0_5 103 104 F. A. C. Polack 2 Patterns Patterns, like methods, capture expertise in a way that is accessible to less-expert or less-experienced practitioners. Patterns were developed by the architect, Christopher Alexander, to demonstrate his approach to creating buildings and townscapes [11]. Many other disciplines have subsequently adopted the concept of patterns, and successful patterns have entered the language of discourse of these disciplines. Computing-related pattern research (e.g. human computer interaction, software design, safety-critical software engineering, systems of systems and other work on large or complex computer systems) is responsible for more direct citation of Alexander’s original pattern works than any other discipline [61]. At the time that his ideas were gaining popularity in software engineering, Prof. Alexander found himself being invited to address high-profile computing conferences. Coplien [10], in his introduction to a journal reprint of Alexander’s address to the 1996 OOPSLA conference, states: Focusing on objects had caused us to lose the system perspective. Preoccupation with design method had caused us to lose the human perspective. The curious parallels between Alexander’s world of buildings and our world of software construction helped the ideas to take root and thrive in grassroots programming communities worldwide. The pattern discipline has become one of the most widely applied and important ideas of the past decade in software architecture and design.1 Coplien [10] goes on to identify Alexander’s influence as one of the three underpinnings of patterns in computing—the others being the PloP (Pattern Languages of Programming) conference series2 and the pattern book of Gamma et al. [26]. Alexander’s work is, of course, a key influence on both PLoP and the Gamma et al. book. However, Alexander was always sceptical about computing patterns, and of the implicit view that patterns “can make a program better” [10]. Alexander stresses the process of design [9, 11], whereas most computing-related patterns aim to provide an instantiatable solution to a problem—not a process. Alexander made his scepticism about computing’s use of patterns abundantly clear when he spent a year as an honorary associate of the EPSRC CoSMoS project, 2007– 2011 (see Sect. 4). A decade after his 1996 address to OOPSLA, he was still concerned that patterns—even computing-related patterns—needed to express things that made people’s lives better. Alexander had a lifelong, deep but intuitive, understanding of the complexity of social and architectural environments, and was focused on the search for an objective way to express and understand the essential properties of positive spaces—that is, process patterns for making the built environment a more positive space and a reflection of a natural environment. It is unfortunate that, although patterns in computing contexts owe so much to Alexander, there is little to offer Alexander in return. 1 Note that the youTube recording of the 1996 talk, https://www.youtube.com/watch? v=98LdFA-_zfA is slightly different from the journal reprint [10]. 2 http://hillside.net/plop/archive.html. Playing with Patterns 105 2.1 Developing and Evaluating Computing-Related Patterns Alexander identifies two ways in which patterns can be discovered [9]. The first starts from a specific problem or class of problems, and proposes a solution that can be generalised as a pattern. The second, which depends on established practice and experience, considers the commonalities in the ways that a problem is addressed in practice, and extracts the characteristics of best-practice into patterns. The earliest published computer patterns are of the second type: for example, Gamma et al’s 1994 book [26] presents software engineering patterns derived from observation of good solutions to common problems. Software engineering also introduced antipatterns (also called bad smells) that capture the common features of poor solutions to common problems, again based on experience and observation of practice [19, 25]. The latter, in particular, are widely discussed in the programming literature and even in educating programmers, and have motivated work on refactoring and code evolution. The approach of patterns-from-practice can be applied as a systematic process (rather than an intuitive retrospective), to derive patterns for a new domain, as demonstrated by Wania and Atwood [62]. From a systematic review of the ways in which 30 existing information retrieval (IR) systems solved six aspects of an interaction problem, Wania and Atwood derive a pattern language of 39 novel IR patterns [62]. Interestingly, further systematic research by Wania and Atwood [62] finds that many software products that are generally considered to have good quality attributes share common solutions—things that might be expressed as patterns—whereas poorer-quality software development tended not to share these quality-enhancing characteristics. It seems that the pattern-from-practice approach is embedded in good-quality software engineering, even where authors have not captured a software engineering pattern. This is good, since other work (some by the same authors) has shown that computer pattern work focuses on the development of pattern languages and libraries but pays very little attention to providing objective evidence that the identified patterns make any difference to quality or productivity [21, 23, 61]. We can speculate what an objective evaluation of a pattern catalogue—or even a single pattern—might look like. It might, for instance, address and measure usage criteria (is it commonly used to solve the associated problem, do users find it easy to understand and instantiate, is it flexible to the contexts in which the problem arises). However, a subjective measure of the success of a pattern is the extent to which the pattern’s name has entered the language of the domain. For example, even undergraduate students discuss their programming projects in terms of model, view, controller (MVC) and factory patterns; these are now so fundamental in OO and user-facing programming contexts that they are inherent rather than being seen as patterns to be applied. Interestingly, MVC pre-dates the formal introduction of patterns in computing: it appears to have been devised in the 1970s, as a solution architecture for systems with a user interface, and is described as a “user interface paradigm” in 1988 [33]. The factory pattern is a creational pattern from Gamma et al. [26] that addresses a very common problem in OO programming; its description 106 F. A. C. Polack is: “Define an interface for creating an object, but let subclasses decide which class to instantiate” [26]. Pattern discovery can cheat the popularity metric, by adopting a name from the language of the domain—this is true of many of the formal patterns in Sect. 3. However, with these exceptions, most of the patterns considered here have not made it into the language of discourse, but they do capture an aspect of expertise or experience that the pattern’s discoverers felt to be worth preserving. The pattern languages discussed in Sects. 3 and 4 include patterns-from-practice and patterns that are created as proposed solutions to a specific problem (Alexander’s first approach to pattern discovery, above). 3 Patterns for Formal Modelling In the late twentieth century, formal methods such as Z [31], B [1] and VDM [16] were seen as a major factor in future software reliability. Notations underpinned by sound mathematical theory allowed precise software specification and proof of properties at the specification stage. Formal refinement [36] allowed the systematic formal derivation of code from formal specifications, such that proved properties could be shown to be preserved—though it had long been realised that refinement could only preserve functional properties; properties such as safety and security (and, indeed emergent properties [40]) are not guaranteed to be preserved by systematic formal refinement, not least because the refinement says nothing about the ability of the implementation platform to preserve non-functional properties in the design. There are some programming languages that correspond so closely to formal modelling languages that programs can be correct-by-construction if appropriate coding memes (essentially patterns) are used correctly—for instance, liveness properties proved using the formal language, CSP [29] can be implemented directly in the occam-π language [64]. Formal methods are often stated to be “difficult”. In reality, once a practitioner has grasped the basic principles of defining updates on mathematical sets and relations, and can read the notations, the act of writing a specification is not hard (it is certainly easier than the process of working out what the specification should have in it in the first place). It is not so much their inherent difficulty which affects use, but the lack of alignment with industrial software engineering methods [17, 28, 34]. However, like coding, there are good ways and less good ways to construct and document a formal model. Again, like coding, there are ways to achieve particular goals that are specific to one formalism. Crucially, some ways of writing a proposal suit particular purposes better than others—for instance, a specification that is written for readability is unlikely to be in a format that facilitates (semi-)automated proof of properties or formal refinement. For Stepney et al. [55], the purpose and motivation for writing a catalogue of Z patterns was to capture good practice and presentation, and to support use of Playing with Patterns 107 Z-specific processes. Later, some of the Z patterns and the conceptual-level ideas introduced via Z patterns were generalised to other formal languages [56]. The Z patterns build on best-practice developed by Logica UK’s Formal Methods Team (LFM), of which Prof. Stepney had been a member. In the 1990s, LFM was a key player in the industrial use of formal specification and proof, and published the book, Z in Practice [15]. In LFM, Prof. Stepney worked extensively on large-scale industrial specification and proof. Published examples include the DeCCo compiler for a high-integrity system [52], and the Mondex electronic purse [51, 69]. These are significant industrial achievements, which required not a little formal methods research. The formal modelling and proof underpinning Mondex resulted in its being awarded ITSEC level E6 security clearance [49, 51, 69]; until this point, the formalism requirements of level E6 had been widely considered unattainable for software-based systems. Although not explicitly presenting Z patterns, the LFM book [15] presents good practice in a clear and applicable manner. A decade later, our Z patterns use the LFM house style throughout. We also capture the LFM house style in patterns as, “some simple Patterns . . . to aid the original specification process, and to help with maintenance” [55]: • • • • Comment the intention Format to expose structure Provide navigation Name consistently. We also introduce anti-patterns that capture our experience of bad presentation, for instance: • Overmeaningful name • Overlong name .3 Like all good (i.e. clear, usable) patterns, the names of these patterns are almost entirely self-explanatory—even Provide navigation is an obvious name to someone using Z (it proposes that, where a Z schema includes—references and incorporates— other schemas, the accompanying text should make clear what is used, rather than leaving the reader to search a potentially large formal text for the specification of the included schemas). As noted above, many of the patterns are named with the familiar Z names of structures or activities (Delta/Xi, promotion, etc.). In writing the Z patterns [53–55], we identified a range of possible uses for patterns. The LFM house style patterns are examples of presentation patterns. Four other uses of pattern are documented: idioms, structure patterns, architecture patterns and development patterns. • Idioms are stylistic patterns and anti-patterns that relate to common challenges encountered in expressing a model in Z such as Represent a 1:many mapping, Use free types for unions, and Overloaded numbers. 3 In line with usage in the Z Patterns report [55], we use a sans-serif font for pattern names and an italicised font for anti-pattern names. 108 F. A. C. Polack • Structure patterns aim to address the problem of structuring a long or complicated Z specification, and encapsulate good practice in modularisation. This includes patterns to address readability, such as Name meaningful chunks and Name predicates; ways to model specific structural elements such as Modelling optional elements or Boolean flag ; and stylistic patterns such as Use generics to control detail. The anti-pattern Fortran warns against writing code in Z rather than exploiting the abstraction and power of the language. • Architectural patterns express paradigmatic ways in which Z notation can be used, aiming to facilitate ways of writing Z that are often unfamiliar to mainstream Z users. The patterns include Object orientation, and Algebraic style, whilst the anti-pattern Unsuitable Delta/Xi pattern captures the fact that the mainstream Z approach, of specifying a state and then specifying predicates that specify formal update and read operations on that state (see e.g. [15, 46]), is unsuitable for some uses of Z. Examples of (appropriate use of) the algebraic style can be found in the definitions that underpin Z: for instance, Stepney et al’s Z definitions and laws [59], or Woodcock and Loomes’ theory of natural numbers [68, Chap. 11]. • Development patterns are stylistic and usage patterns that can be applied in working with Z, such as Use integrated methods. They include patterns such as Do a refinement, Do sanity checks and Express implicit properties. The architectural and development patterns come close to Alexander’s conception of process patterns, in that they guide a user in creating or working with an appropriate (in aesthetic and architectural terms) Z model. The Z catalogue takes the support for the development process further in generative patterns: collections of patterns that capture what needs to be done to achieve or manage a particular form of Z model. Examples include collections of patterns relating to creation of a good quality Delta/Xi (state-and-operations) specification, and a collection which can be applied to create a Z Promotion, in which local operations are defined on a local state and then “promoted” to global operations on a global state. A set of patterns to support a full formal refinement was also presented [54]. In presenting the Z Pattern Catalogue, the original intention had been to extend the catalogue over time as formality became embedded in software engineering. To support this aim, the catalogue includes a pattern template. To make our Z patterns accessible to a wider audience, we also defined a diagrammatic language—a domain-specific language (DSL) in modern parlance. Diagrams with clearly-defined meanings were used to illustrate the structure and behaviour of pattern components. Later, the DSL was elaborated and applied to other formal languages [56]. The Z Pattern Catalogue and associated papers were well received at the time of writing, but Z patterns did not enter the language of discourse (except where we named patterns with terms from the existing language of discourse) and did not become the major resource for formalists that we had hoped.4 In retrospect, we see that our work on making Z more accessible came at the start of the decline in the belief 4 In 2018, the various papers had only some 30 citations. However, to put that in context, the LFM book [15], has only 142 citation. Playing with Patterns 109 that formal methods would be the underpinning of all software engineering; indeed, in the twenty-first century, the predominant approach to software specification and design uses model-driven engineering, and metamodelling approaches to language definition (e.g. [18]). 4 Patterns for Modelling Complex Systems: CoSMoS The Z Pattern Catalogue comprises patterns-from-practice, building on many years of experience using the Z language in practice and as part of a software development process. Even the seemingly-esoteric definitions and laws of Z [59] are motivated by practical requirements for fit-for-purpose formal specification tool-support, and the need to demonstrate the internal consistency of ISO standard Z [31]. In the last decade, Prof. Stepney’s focus has shifted to complex systems, combining interests in complexity and software engineering. Stepney led development of CoSMoS, a principled approach to the modelling and simulation of complex systems, targetted to research and engineering uses of simulation.5 Simulations developed following the CoSMoS approach and principles include, for instance [2, 27, 37, 47, 48, 66]. The CoSMoS process is summarised as a life-cycle, phases and products (see Fig. 1); the high-level problem is thus how to support the the activities that are needed in each phase. CoSMoS patterns represent ways to address the sub-problems identified in decomposing the top-level problem of engineering a demonstrably fit-for-purpose simulation [58] (an example of Alexander’s first pattern-discovery approach). The top-level CoSMoS process can be summarised in three patterns [50, 58], • carry out the Discovery Phase, • carry out the Development Phase, • carry out the Exploration Phase. Further patterns are identified as the phases are decomposed. For the Discovery Phase, for instance, the next level of patterns are [50, 58]: • • • • identify the Research Context, define the Domain, build a Domain Model, Argue Appropriate Instrument Designed. Focusing on the pattern, Identify the research context, Stepney [50] uses the Intent, Context and Discussion sections of the pattern to convey the role that the research context plays in a CoSMoS development (reproduced in Table 1). Notice 5 The CoSMoS project, 2007–11, was led by Susan Stepney (York: EPSRC EP/E053505) and Peter Welch (Kent: EPSRC EP/E049419), along with researchers from York, Kent, University of the West of England and Abertay. The outputs of CoSMoS can be found online at https://www.cosmosresearch.org/about.html. Background and motivation to CoSMoS can be found in [13, 42–45, 58]. 110 F. A. C. Polack Fig. 1 Phases (ellipses) and products (boxes) of the CoSMoS process [13, 50, 58]. The CoSMoS lifecycle starts with identification of the domain (not shown), and proceeds through development of the domain and platform models, the simulation platform and the results model. Information collected en-route is summarised in the research context, which is used to map between simulation results and domain observables that further patterns are identified in the pattern’s Discussion section: whenever a variant of a problem is identified, and a potential solution identified, whether from scratch or from the wider software engineering experience of the CoSMoS team, a pattern captures the solution. Again, antipatterns identify some of the things to avoid in defining the research context [50, 58]. For example, avoiding an ever-expanding scope or scale, which is referred to as Everything but the kitchen sink . To further develop a research context, we decompose the problem again, and seek to capture more potential solutions as patterns. The following list of problems to be solved shows where patterns have been documented [50, 58]: • Document the research goals • Document Assumptions relevant to the research context • Identify the team members, including the Domain Expert, the Domain Modeller, and the Simulation Implementor, their roles, and experience • Agree the Simulation Purpose, including criticality and impact • Note the available resources, timescales, and other constraints • Determine success criteria • Revisit between phases, and at discovery points; if necessary, change the context, and Propagate Changes. Playing with Patterns 111 Table 1 The intent, context and discussion sections of stepney’s pattern, Identify the Research Context [50, 58] Intent Identify the overall scientific context and scope of the simulation-based research being conducted Context A component of the Discovery Phase, Development Phase, and Exploration Phase patterns. Setting (and resetting) the scene for the whole simulation project Discussion The role of the research context is to collate and track any contextual underpinnings of the simulation-based research, and the technical and human limitations (resources) of the work The research context comprises the high-level motivations or goals for the research use, the research questions to be addressed, hypotheses, general definitions, requirements for validation and evaluation, and success criteria (how will you know the simulation has been successful) The scope of the research determines how the simulation results can be interpreted and applied. Importantly, it captures any requirements for validation and evaluation of simulation outputs. It influences the scale and scope of the simulation itself Consideration should be made of the intended criticality and impact of the simulation-based research. If these are judged to be high, then an exploration of how the work can be validated and evaluated should be carried out Determine any constraints or requirements that apply to the project. These include the resources available (personnel and equipment), and the time scale for completion of each phase of the project. Any other constraints, such as necessity to publish results in a particular format (for example, using the ODD Protocol), should be noted at this stage. This helps ensure that later design decisions do not violate the project constraints. Ensure that the research goals are achievable, given the constraints. As information is gathered during the project, more understanding of the domain and the research questions will be uncovered. For example, a Prototype might indicate that a simulation of the originally required detail is computationally infeasible. The research context should be revisited between the various phases, and also at any point where major discoveries are made, in order to check whether the context needs to change in light of these discoveries Whilst some of these patterns are specific to a CoSMoS-style simulation development, all the patterns draw on general software engineering or simulation best practice. For example the patterns that decompose the problem of identifying roles draw on software engineering roles (cf. Scrum roles6 ). A CoSMoS role implies particular responsibilities, but it does not imply a single person—typically, the domain expert role is taken by a lab or research team; it is also possible for one person to play several, or even all, the roles. As for the Z generative patterns (Sect. 3), lists of patterns that capture what could be done to address a particular problem are not ordered steps, but a collection of activities that should be considered in order to address the sub-problem of a higher goal [50, 58]. As in other pattern catalogues, patterns may be optional, alternatives, or might be instantiated in spirit only in smaller or less critical projects. 6 https://www.scrumalliance.org/. 112 F. A. C. Polack 4.1 Fitness for Purpose and Patterns Documenting a whole development process by successive problem decomposition is not a task to take lightly: a full set of CoSMoS patterns has recently been published [58]. However, some of the lower-level patterns have been adopted in practice.7 In this section, I present some patterns that we have developed to support documentation of the fitness-for-purpose of a simulation using arguments [2, 3, 42, 66]; first, however, I explain how and why CoSMoS addresses fitness for purpose. CoSMoS is a process to support principled modelling and simulation of complex systems. Principled modelling and simulation implies that we can show that our modelling and simulation match the purpose of our simulation—in most cases, that the models are appropriate models of the domain, and that the simulation faithfully implements the models. Validation of simulations has often been limited to checking that the simulation produces the expected results by a process that looks a bit like reality; there is little concern for the quality of the underlying simulation [24]. The lack of overt emphasis on fitness for purpose in simulation has led to intellectual debate over whether it is possible to do science through simulation [20, 22, 35, 38, 45, 65]. Similar issues with the validity of simulation and use of simulation evidence arise in safety critical systems engineering [12], and in social simulation [65]. Wheeler et al. [65] summarise the concerns about simulation in noting that to assess the role and value of complex systems simulation, we need to address deep questions of comparability: we need a record of experience, of how good solutions are designed, of how to chose parameters and calibrate agents, and, above all, how to validate a complex system simulation. Many of these issues were subsequently considered in the CoSMoS project [13]. Of particular interest here are simulations created as tools for scientific exploration. A scientific tool enhances the ability of a human to observe or understand a scientific subject. Humphreys [30] identifies three ways in which scientific instruments enhance the range of natural human abilities. • Extrapolation describes the extension of an existing modality. For example, vision is extended using a microscope. • Conversion changes the mode through which something is accessed. For example, a sonar device has a visual display that converts sonar echoes into a threedimensional image of a surface. • Augmentation is used to access features that people cannot normally detect in their original form. Examples include the detection of magnetism or elementary particle spin. Tools that use extrapolation, conversion or augmentation exhibit an increasingly tenuous or abstract link to reality (the domain of study). Conversely, the implicit or explicit model of reality plays an increasingly important role in understanding the outputs of the scientific instrument. 7 see e.g. the simulation projects of the York Computational Immunology Lab, https://www.york. ac.uk/computational-immunology/. Playing with Patterns 113 For simulation, the properties of the real domain are often estimated and always abstracted: the environment, the input parameters, and the layers and the forms of interaction are necessarily simplified. However, just as with conventional scientific instruments, the simulation needs to be constructed, calibrated and documented in a way that allows it to be used as a robust tool. This puts a significant responsibility on the modelling. Without a principled approach to development, the results of a simulation cannot be interpreted in any meaningful way. The CoSMoS process has mostly been used for research simulation, aiming to create a simulation (usually an agent or individual based simulation) that is a credible tool for testing or developing specific scientific hypotheses in a specific laboratory (domain) context. The intended purpose and the scope of simulation are determined by the domain expert, in conjunction with the developer, (who usually has the more realistic idea of what is possible in a simulation). Purpose is defined by, and is that of, the domain expert laboratory. It is not the whole of that scientific domain. In this respect, CoSMoS-style simulation differs from much scientific simulation, which seeks to create a simulation of a whole concept using information from many domain experts and related sources—see for instance the Chaste project, which is building an in silico heart model.8 A CoSMoS simulation purpose typically relates to the investigation of some dynamic process that underpins an observable behaviour of a real system—for example, the development of cell clusters or the evolution of a pathology that depends on cell and molecular interactions over time and/or space. The simulation is needed either because the dynamic systems behaviour cannot be observed, or because it is useful to be able to perturb the dynamics in ways that cannot easily be attempted in vivo, in vitro or in dead tissue. The fitness-for-purpose of the simulation is assessed against the purpose, and must be re-assessed if the simulation purpose is changed. As a CoSMoS-style development proceeds, many discussions and some research take place, to establish a model of the domain. In engineering terms, the team aims to establish the scope and scale of a simulation that is computationally feasible, and can meet the purpose of the simulation. Many design decisions are made, both in terms of the domain and in terms of the modelling and potential realisation of the simulator. Many assumptions are also identified and recorded. (Of course, there are many un-noticed assumptions and instinctive design decisions that are not recorded, but that is another story.) Most CoSMoS-based simulation projects use argumentation to capture the belief of the team that specific aspects of the development are fit for purpose. Arguments lend themselves well to patterning. CoSMoS argumentation is derived from safety case argumentation, which, from its earliest days, has used patterns to capture the structure of common safety cases such as Component contributions to system hazards and Effects of other components [32, 63]. In safety case argumentation patterns, the top-level goal or claim often presents a generalisation of a common hazard or safety concern, and further patterns present potential decompositions of 8 www.cs.ox.ac.uk/chaste. 114 F. A. C. Polack the main claims (referred to as goals) of the argument. The solutions represented by safety argumentation patterns capture best practice in safety critical engineering as well as ultimately presenting evidence that a goal has been met. Safety case arguments are typically presented using the Goal Structuring Notation (GSN) [39, 67]. CoSMoS adopts, and slightly adapts, GSN for the visual representation of fitness-for-purpose arguments [4, 41, 42]. Whereas a safety case argument must be complete, from goal to evidence, the primary purpose of a fitness-for-purpose argument is to expose and express the reasoning behind a particular aspect of the simulation design. For example, Alden [2] captures a detailed rationale for the fitness-for-purpose of the domain model created to model Peyers’ patch development in an embryonic mouse gut. The top claim, that the [m]odel is an adequate representation of the biology, is addressed using the decomposition strategy, [a]rgue over scientific content, the adequacy of the abstraction and the experimental results. Each element of the decomposition can be addressed in turn, broken down into sub-goals, and, in Alden’s case, used to point to the eventual evidence (data, statistical analysis) that the simulator is capable of generating results that are comparable to observations of the domain. Fig. 2 An argument pattern for the top-level fitness-for-purpose of a domain model for a simulation. Claims are represented as rectangles, strategies as parallelograms, contextual information (which could also include assumptions, justifications, etc.), as soft-cornered rectangles. Instantiation of the pattern replaces names in angle-brackets and elaborates the sub-claims [14, 42] Playing with Patterns 115 Fig. 3 Representation of an argument pattern for the appropriateness of statistical analysis. Claims are represented as rectangles, strategies as parallelograms, contextual information (which could also include assumptions, justifications, etc.), as soft-cornered rectangles. Instantiation of the pattern replaces names in angle-brackets Alden’s top-level argument [2] is based on an instantiation of one of the sub-claims of the top-level fitness-for-purpose argument pattern shown in Fig. 2.9 The argument in Fig. 2 presents a possible solution to the problem of demonstrating fitness for purpose of a whole simulation (the top claim, Claim 1). The argument points to sources of information about the claim in two “Context” statements—one is a pointer to the definition of the system that we want to show to be fit, and the other, here, points to the statement of purpose against which fitness is to be judged. These contextual elements are essential in documenting an argument that something is fit for purpose. Other contextual items, assumptions and justifications could be added. The top-level claim in the argument (Fig. 2) is addressed using a decomposition strategy: arguing over the fitness for purpose of the modelling, the software engineering and the results of the simulation. Each decomposed element results in further claims, and each of these can be broken down and documented in the same way. To instantiate this argument, the terms in angle-brackets must be replaced by appropriate terms from the project, and thought must be given both to how to elaborate each sub-claim, and to what assumptions, justifications and context statements are needed to substantiate the claims. 9 Argument representations in this paper have been produced using YCIL’s open-source Artoo argu- mentation tool https://www.york.ac.uk/computational-immunology/software/artoo/, which runs in a browser, loads and stores argument structures as XML, and generates .png images. The tool underpins Simomics Ltd’s Reason tool, www.simomics.com. 116 F. A. C. Polack To illustrate a pattern and its instantiation, it is easiest to take a more focused argument. A common problem in demonstrating fitness for purpose in a simulation (or real-life) context is showing that the statistical analysis undertaken has used an appropriate statistic. Most common statistics make some assumptions about whether data is continuous or discrete and how population and sample data and data errors are distributed. Figures 3 and 4 illustrate a general pattern for an argument about Fig. 4 An instantiation of the argument pattern in Fig. 3 for the use of Vargha and Delaney’s A test [60]. A fuller version of the argument, showing how it has been applied to specific experimental results, can be found in [42] Playing with Patterns 117 the appropriateness of a statistic, and an instantiation of that argument for the A test [60], which can be used to compare medians (an example use of the argument can be found in [42]). A key benefit of argumentation is that anyone can review the argument: for example, in Fig. 4, someone might spot an error in our assumptions, or might challenge the validity of the strategy used. As an aside, we show the argument of fitness for the A test here because it is a test that many CoSMoS-style simulations have used, in situations where the distribution characteristics of the data cannot be known. It is one of a number of statistical tests built into the Spartan10 tool [5–8] which supports analysis of CoSMoS-style simulation and domain results. 5 Discussion The concept of a pattern is appealing to engineers because it encapsulates a solution to a typical problem. In this paper, I have given examples of patterns that are synthesised from practice and experience, exemplified by the Z and formal methods patterns; and patterns that are proposed as potential solutions to problems, exemplified by the CoSMoS development and argumentation patterns. Both approaches to pattern discovery illustrate some typical issues with patterns. The patterns-from-practice approach relies on there being established usage and expertise; the risk (demonstrated by the Z patterns work) is that the patterns are distilled too late to be of value: in a fast-changing area such as software engineering, this is not uncommon. However, the capturing of solutions in patterns can highlight aspects of solutions or best practice that are of relevance beyond the specific pattern domain. For instance, in the Z patterns work, we used generative patterns to identify sets of specific development (etc.) patterns that can be used to develop different styles of formal solution: the same meme is used in the CoSMoS patterns, and we suggest that the principle of providing a set of patterns relating to a particular problem takes patterns closer to Alexander’s intent of process patterns. In work on formal patterns, our use of “meta-patterns” shows how we adapt Z patterns to other formal and less formal modelling approaches, to capture design processes. If we replace the Z-specific patterns with either generic or other languagespecific patterns, we might be able to improve the quality of development more widely. To illustrate, consider Table 2, which takes three of the component patterns from the generative pattern for a conventional Z Delta/Xi specification [55], and suggests how these might relate to, and illuminate, a more general development process. It is interesting to observe in Table 2 how things that are implicit in one context (e.g. type-checking in a formal context; drawing design diagrams in a general context) need to be made explicit in another context. It is tempting to suggest that there is 10 https://www.york.ac.uk/computational-immunology/software/. 118 F. A. C. Polack Table 2 Using components of a Z generative pattern to illuminate more general development patterns and vice versa Z generative patterns: intent Delta/Xi: specify a system as a state, with operations based on that state Diagram the structure: create a visual representation of the structure of the solution, to summarise the structure and allow critical review Strict convention: Use the ∆/Ξ Z naming convention strictly, to avoid surprising the reader with hidden constraints. Note: Z schemas whose name starts with ∆ define a pre and post state, and can be used to formally define updates to the state; those whose name starts with Ξ require that the pre and post states are equal, so can only define read operations Change part of the state: define an operation that changes only part of the state Note: Z allows “set difference” to be applied to schemas, constraining hidden elements to remain unchanged in operations General development Model the state and operations of the proposed system—note that a formal model can be proven internally consistent; a non-formal model needs an additional validation step Create and validate diagrammatic models; validate internal consistency of models Consider the meaning of notations and state semantic variations For example, when modelling in UML, consider whether the MOF definitions of class, generalisation, etc., are used strictly; consider stating the semantics of generalisation in terms of specific theory of OO inheritance, etc. Validate operations to ensure that unintended side-effects are eliminated; ensure that a requirement not to change part of a state is explicit and tested scope for comparison of developmental patterns for different contexts and languages, to identify a superset of generic quality or validation patterns. Turning to patterns invented to address existing problems, a similar effect can be observed. In developing a new pattern catalogue, we use our experience of working in other problem-solving domains and with other approaches or languages. Thus, one of the underpinnings of our work on the CoSMoS pattern language is our background in formal methods and software engineering. The CoSMoS team included experienced academic and industrial software engineers who had experience of a wide range of methods, techniques and languages. Experience with formal methods (the team had a good working knowledge and practical experience of Z, B and CSP) focuses attention on the use and misuse of models more generally; typechecking focuses attention on the need to cross-validate models. In terms of software engineering modelling, the team’s expertise covers conventional Harel statecharts, Petri nets, and many of the software modelling languages that comprise or influenced UML/MOF, as well as a number of bespoke modelling languages, and research expertise in model driven engineering. A strong background in notations and semantics, and a broad experience of modelling languages, inevitably focuses attention on the difficulty of knowing whether and to what extent a model adequately captures what is intended. Overall, this led to the CoSMoS Research Context (colloquially, the repository of all the stuff that we accumulate about the domain and the development) and the focus on fitnessfor-purpose and argumentation. Thus, whilst experience of principled modelling Playing with Patterns 119 and simulation is still limited, the CoSMoS patterns are well-grounded in extensive software engineering practice and experience. Again, it would be tempting to suggest a more systematic review of pattern languages, to establish links to patterns in other domains which may already have solutions to some of the problems of a CoSMoSstyle development. 6 Summary and Conclusion Patterns, building on the work of Alexander, have become influential and mainstream in software engineering. Prof. Stepney’s work has returned to patterns repeatedly, both as a means of capturing long-time experience, and as a way to present potential solutions to problems. Stepney and her teams have produced novel patterns, with a focus on visual representations, as well as on practicality and use. This platform of pattern research has the potential for improving software development both of research simulators and more generally. Even if none of the patterns presented here and in the referenced work was never used again, they remain an archive of experience and practice, presented in an accessible way, to future researchers and software developers. The examples show the breadth of software engineering research led by Prof. Stepney over the last three decades. References 1. Abrial, J.-R.: The B-book: Assigning Programs to Meanings. CUP (1996) 2. Alden, K.: Simulation and statistical techniques to explore lymphoid tissue organogenesis. Ph.D. thesis, University of York (2012). http://etheses.whiterose.ac.uk/3220/ 3. Alden, K., Andrews, P., Timmis, J., Veiga-Fernandes, H., Coles, M.C.: Towards argumentdriven validation of an in-silico model of immune tissue organogenesis. In: Proceedings of ICARIS, vol. 6825, LNCS, pp. 66–70. Springer (2011) 4. Alden, K., Andrews, P.S., Polack, F.A.C., Veiga-Fernandes, H., Coles, M.C., Timmis, J.: Using argument notation to engineer biological simulations with increased confidence. J. R. Soc. Interface 12(104) (2015) 5. Alden, K., Andrews, P.S., Veiga-Fernandes, H., Timmis, J., Coles, M.C.: Utilising a simulation platform to understand the effect of domain model assumptions. Nat. Comput. 14(1), 99–107 (2014) 6. Alden, K., Read, M., Andrews, P.S., Timmis, J., Coles, M.C.: Applying Spartan to understand parameter uncertainty in simulations. R J. (2014) 7. Alden, K., Read, M., Timmis, J., Andrews, P., Veiga-Frenandes, H., Coles, M.: Spartan: a comprehensive tool for understanding uncertainty in simulations of biological systems. PLoS Comput. Biol. 9(2) (2013) 8. Alden, K., Timmis, J., Andrews, P.S., Veiga-Fernandes, H., Coles, M.C.: Extending and applying Spartan to perform temporal sensitivity analyses for predicting changes in influential biological pathways in computational models. IEEE Trans. Comput. Biol. 14(2), 422–431 (2016) 9. Alexander, C.: The Timeless Way of Building. OUP (1979) 120 F. A. C. Polack 10. Alexander, C.: The origins of pattern theory: the future of the theory, and the generation of a living world. IEEE Softw. 16(5), 71–82 (1999) 11. Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I., Angel, S.: A Pattern Language—Towns, Buildings, Construction. OUP (1977) 12. Alexander, R.: Using simulation for systems of systems hazard analysis. Ph.D. thesis, Department of Computer Science, University of York, YCST-2007-21 (2007) 13. Andrews, P.S., Polack, F.A.C., Sampson, A.T., Stepney, S., Timmis, J.: The CoSMoS process, version 0.1. Technical Report, Computer Science, University of York, YCS-2010-450 (2010) 14. Andrews, P.S., Stepney, S., Hoverd, T., Polack, F.A.C., Sampson, A.T., Timmis, J.: CoSMoS process, models and metamodels. In: CoSMoS Workshop, pp. 1–14. Luniver Press (2011) 15. Barden, R., Stepney, S., Cooper, D.: Z in Practice. Prentice-Hall (1995) 16. Bjørner, D., Jones, C.B. (eds.): The Vienna Development Method: The Meta-Language, vol. 61, LNCS. Springer (1978) 17. Bowen, J.P., Hinchey, M.G.: Seven more myths of formal methods. IEEE Softw. 12(4), 34–41 (1995) 18. Brambilla, M., Cabot, J., Wimmer, M.: Model-driven Software Engineering (MDSE) in Practice, 2nd edn. Morgan & Claypool (2017) 19. Brown, W.H., Malveau, R.C., McCormick, H.W., Mowbray, T.J.: AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, 1st edn. Wiley (1998) 20. Bryden, J., Noble, J.: Computational modelling, explicit mathematical treatments, and scientific explanation. In: Proceedings of Artificial Life X, pp. 520–526. MIT Press (2006) 21. Dearden, A., Finlay, J.: Pattern languages in HCI: a critical review. Hum. Comput. Interact. 21(1), 49–102 (2006) 22. Di Paolo, E., Noble, J., Bullock, S.: Simulation models as opaque thought experiments. In: Proceedings of Artificial Life VII, pp. 497–506. MIT Press (2000) 23. Duncan, I.M.M., de Muijnck-Hughes, J.: Security pattern evaluation. In: Proceedings of SOSE, pp. 428–429. IEEE (2014) 24. Epstein, J.M.: Agent-based computational models and generative social science. Complexity 4(5), 41–60 (1999) 25. Fowler, M.: Refactoring: Improving the Design of Existing Code. Addison-Wesley (1999) 26. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Objectoriented Software. Addison-Wesley (1995) 27. Greaves, R.B., Read, M., Timmis, J., Andrews, P.S., Butler, J.A., Gerckens, B., Kumar, V.: In silico investigation of novel biological pathways: the role of CD200 in regulation of T cell priming in experimental autoimmune encephalomyelitis. Biosystems (2013). https://doi.org/ 10.1016/j.biosystems.2013.03.007 28. Hall, A.: Seven myths of formal methods. IEEE Softw. 7(5), 11–19 (1990) 29. Hoare, C.A.R.: Communicating Sequential Processes. Prentice-Hall (1985) 30. Humphreys, P.: Extending Ourselves: Computational Science, Empiricism, and Scientific Method. OUP (2004) 31. Information Technology—Z formal specification notation—syntax, type system and semantics. ISO Standard 13568 (2002) 32. Kelly, T.P.: Arguing safety—a systematic approach to managing safety cases. Ph.D. thesis, Department of Computer Science, University of York, YCST 99/05 (1999) 33. Krasner, G.E., Pope, S.T.: A cookbook for using the model-view controller user interface paradigm in Smalltalk-80. J. Object Oriented Program. 1(3), 26–49 (1988) 34. Le Charlier, B., Flener, P.: Specifications are necessarily informal or: some more myths of formal methods. Syst. Softw. 40(3), 275–296 (1998) 35. Miller, G.F.: Artificial life as theoretical biology: how to do real science with computer simulation. Technical Report Cognitive Science Research Paper 378, University of Sussex (1995) 36. Morgan, C.: Programming from Specifications, 2nd edn. Prentice Hall (1994) 37. Moyo, D.: Investigating the dynamics of hepatic inflammation through simulation. Ph.D. thesis, University of York (2014) Playing with Patterns 121 38. Nance, R.E., Sargent, R.G.: Perspectives on the evolution of simulation. Oper. Res. 50(1), 161–172 (2002) 39. Origin Consulting (York): GSN community standard version 1. Technical report, Department of Computer Science, University of York (2011). http://www.goalstructuringnotation.info 40. Polack, F., Stepney, S.: Emergent properties do not refine. ENTCS 137(2), 163–181 (2005) 41. Polack, F.A.C.: Arguing validation of simulations in science. In: CoSMoS Workshop, pp. 51– 74. Luniver Press (2010) 42. Polack, F.A.C.: Filling gaps in simulation of complex systems: the background and motivation for CoSMoS. Nat. Comput. 14(1), 49–62 (2015) 43. Polack, F.A.C., Andrews, P.S., Ghetiu, T., Read, M., Stepney, S., Timmis, J., Sampson, A.T.: Reflections on the simulation of complex systems for science. In: Proceedings of ICECCS, pp. 276–285. IEEE Press (2010) 44. Polack, F.A.C., Andrews, P.S., Sampson, A.T.: The engineering of concurrent simulations of complex systems. In: Proceedings of CEC, pp. 217–224. IEEE Press (2009) 45. Polack, F.A.C., Hoverd, T., Sampson, A.T., Stepney, S., Timmis, J.: Complex systems models: engineering simulations. In: Proceedings of ALife XI, pp. 482–489. MIT press (2008) 46. Potter, B., Till, D., Sinclair, J.: An Introduction to Formal Specification and Z, 2nd edn. Prentice Hall (1996) 47. Read, M., Andrews, P.S., Timmis, J., Kumar, V.: Techniques for grounding agent-based simulations in the real domain: a case study in experimental autoimmune encephalomyelitis. Math. Comput. Model. Dyn. Syst. 18(1), 67–86 (2012) 48. Read, M.N.: Statistical and modelling techniques to build confidence in the investigation of immunology through agent-based simulation. Ph.D. thesis, University of York (2011) 49. Stepney, S.: A tale of two proofs. In: BCS-FACS Northern Formal Methods Workshop. Electronic Workshops in Computing (1998) 50. Stepney, S.: A pattern language for scientific simulations. In: CoSMoS Workshop, pp. 77–103. Luniver Press (2012) 51. Stepney, S., Cooper, D., Woodcock, J.C.P.: An electronic purse: specification, refinement, and proof. Technical Monograph PRG-126, Oxford University Computing Laboratory (2000) 52. Stepney, S., Nabney, I.T.: The DeCCo project papers, I to VI. Technical Report, Computer Science, University of York, YCS-2002-358 to YCS-2002-363 (2003) 53. Stepney, S., Polack, F., Toyn, I.: An outline pattern language for Z: five illustrations and two tables. In: Proceedings of ZB2003, vol. 2651, LNCS, pp. 2–19. Springer (2003) 54. Stepney, S., Polack, F., Toyn, I.: Patterns to guide practical refactoring: examples targetting promotion in Z. In: Proceedings of ZB2003, vol. 2651, LNCS, pp. 20–39. Springer (2003) 55. Stepney, S., Polack, F., Toyn, I.: A Z patterns catalogue I: specification and refactorings, v0.1. Technical Report, Computer Science, University of York, YCS-2003-349 (2003) 56. Stepney, S., Polack, F., Toyn, I.: Diagram patterns and meta-patterns to support formal modelling. Technical Report, Computer Science, University of York, YCS-2005-394 (2005) 57. Stepney, S., Polack, F., Turner, H.: Engineering emergence. In: ICECCS, pp. 89–97. IEEE Computer Society (2006) 58. Stepney, S., Polack, F.A.C.: Engineering Simulations as Scientific Instruments: A Pattern Language. Springer (2018) 59. Valentine, S.H., Stepney, S., Toyn, I.: A Z patterns catalogue II: definitions and laws, v0.1. Technical Report, Computer Science, University of York, YCS-2003-383 (2004) 60. Vargha, A., Delaney, H.D.: A critique and improvement of the CL common language effect size statistics of McGraw and Wong. J. Educ. Behav. Stat. 25(2), 101–132 (2000) 61. Wania, C.E.: Investigating an author’s influence using citation analyses: Christopher Alexander (1964–2014). Proc. Assoc. Inf. Sci. Technol. 52(1), 1–10 (2015) 62. Wania, C.E., Atwood, M.E.: Pattern languages in the wild: exploring pattern languages in the laboratory and in the real world. In: Proceedings of DESRIST, pp. 12:1–12:15. ACM (2009) 63. Weaver, R.A.: The safety of software—constructing and assuring arguments. Ph.D. thesis, Department of Computer Science, University of York, YCST-2004-01 (2003) 122 F. A. C. Polack 64. Welch, P.H., Barnes, F.R.M.: Communicating mobile processes: introducing occam-pi. In: Proceedings of 25 Years of CSP, vol. 3525, LNCS, pp. 175–210. Springer (2005) 65. Wheeler, M., Bullock, S., Di Paolo, E., Noble, J., Bedau, M., Husbands, P., Kirby, S., Seth, A.: The view from elsewhere: perspectives on ALife modelling. Artif. Life 8(1), 87–100 (2002) 66. Williams, R.A., Greaves, R., Read, M., Timmis, J., Andrews, P.S., Kumar, V.: In silico investigation into dendritic cell regulation of CD8Treg mediated killing of Th1 cells in murine experimental autoimmune encephalomyelitis. BMC Bioinform. 14, S6–S9 (2013) 67. Wilson, S.P., McDermid, J.A.: Integrated analysis of complex safety critical systems. Comput. J. 38(10), 765–776 (1995) 68. Woodcock, J., Loomes, M.: Software Engineering Mathematics. Addison-Wesley (1990) 69. Woodcock, J., Stepney, S., Cooper, D., Clark, J.A., Jacob, J.L.: The certification of the Mondex electronic purse to ITSEC Level E6. Form. Asp. Comput. 20(1), 5–19 (2008)