Basic System and Subsystem Structures in the Dataflow Algebra. A. J. Cowling

Transcription

1 Verification Testing Research Group, Department of Computer Science, University of Sheffield, Regent Court, 211, Portobello Street, Sheffield, S1 4DP, United Kingdom dcs.shef.ac.uk Telephone: Fax: Abstract Most of the recent work on the development of the dataflow algebra has been concerned with the algebraic structure of the sequences that are defined in its event layer, with the properties that follow from this algebraic structure. Underpinning the event layer, however, is the topological layer of the algebra, so far only the very basic concepts of this have been defined. For practical applications, however, the algebra has to allow specifications to be constructed for complete systems subsystems, this requires that these concepts can be modelled in the topological layer as well as in the event layer. This report therefore develops the basic structures that are needed within the topological layer to model systems their subsystems, then begins the process of relating these to event layer specifications of their behaviour. Specifically, the report creates definitions for the topological layer structures of systems subsystems, it defines properties of subsystems such as being connected or being disjoint. At the event layer it then goes on to define the restriction operation, which extracts the specification of a subsystem from the specification of the system that contains it, it develops some of the properties of this operation, such as its relationships with the concepts of the alphabet the effective alphabet of a sequence, it establishes that the restriction operation possesses the property of substitutability. Key Words Phrases Formal specifications, dataflow algebra, topological structures of systems, topological structures of subsystems, restriction of specifications. 1. Introduction There have been two main phases so far in the development of the dataflow algebra (DFA from now on), this report marks the beginning of a third phase. The first phase was the development of the basic concepts of the algebra it s relationships to other models of software systems, as such was comparatively informal. It began by identifying the principles of a model based on data flow diagrams [1], then the definition of an abstract syntax for the DFA [2], the use of this by Nike in the work for his PhD thesis [3]. It also involved the initial development of tools for manipulating DFA specifications [4], which included defining the concept of DFA specifications being structured into three layers of detail, along with this it introduced a formal numbering system for different versions of the DFA notation. The second phase was based round the development of a much simpler abstract syntax for the DFA [5], along with the renaming of the three layers in a specification, the identification of a much simpler set of semantic domains (viz SeqConst, SeqExp Seq) the relationships between them. This development also enabled a more rigorous definition of the denotational semantics for the event layer of the DFA, the definition of an operational semantics as well [6] for this layer, to complement the denotational semantics. Subsequently errors were then found in this version of the denotational semantics, so these were corrected [7] new proofs constructed of the results for soundness completeness of the semantics, thus defining version 3 (strictly 3.0.0) of the DFA notation. In creating these semantics it was noted that the models which they used reflected particular forms for the structures of complex sequences, this led to the recognition of a set of normal forms within the DFA [8]. The properties of these forms led in turn to a revision of the definition of equality, so as to include explicitly some properties that previously had only been defined implicitly, then to the derivation of constructive definitions for both the equality inequality operations for the DFA [9]. These various results, taken together, mean that the development of the DFA has now reached a point where the algebra has a complete consistent foundation, in which core concepts such as normal forms, equality inequality are rigorously defined are complete consistent with the semantics of the algebra. This foundation therefore now provides a sound

2 basis for progressing to the third phase of development of the DFA, which will be concerned with exploring issues related to the way in which the DFA models the behaviour of system architectures, the purpose of this report is to commence this third phase by examining the issues related to the concept of a system being composed of a number of subsystems, so that the DFA specification of the complete system needs to be related to the specifications of the individual subsystems. Hence, this report is concerned mainly with developing the machinery needed to model the structures of systems subsystems at the level of the topological layer of the DFA, then beginning to link this with the machinery (much of which has already been at least outlined) for modelling these concepts at the level of the event layer. The first part of this therefore begins in section 2 by defining more rigorously than has been done previously the structure of the topological layer models for systems some of their basic properties, then in section 3 extending this to the related models for subsystems the equivalent properties for them. Section 4 then develops the theory for subsystems further, by showing how subsystems may be decomposed into more primitive structures that are termed partitions. The second part of this development, beginning to link this theory with event layer specifications, forms section 5, which defines the basic relationships between the event layer the topological layer. In particular it defines the operation for extracting the specification of a subsystem from the specification of a system or subsystem that contains it, explores the relationship between this the concepts of the alphabet effective alphabet for a sequence. As such it provides a foundation for the much larger exercise of developing the machinery that would be needed for composing the specifications of two subsystems. The scope of this exercise is such, however, that it would not be practical to deal with it in this report, so section 6 simply discusses the conclusions from the work that has been presented, briefly outlines the further developments that are required. 2. Topological Aspects of Systems The topological layer of any DFA specification reflects the way in which the DFA was developed originally to model the behaviour that is documented in the data flow diagrams (or DFDs) that are used in "structured" analysis design methodologies such as SSADM [10], Yourdon [11] their derivatives, or in the communication diagrams of UML version 2 [12] ( which were formerly known as collaboration diagrams in version 1 of it). DFDs, of course, just specify the static structure of a system the data flows that can occur between them, it is this static structure that the topological layer of a DFA specification is intended to capture. Then, to define the dynamic behaviour of a system UML communication diagrams model the sequencing of the data flows as well, in a DFA specification the formal equivalent of these is provided by adding the event layer to the topological layer. In constructing such models there is a fundamental issue as to whether the models that are to be constructed should describe a system as open or closed. Any system that is of interest (or SoI, as it will be abbreviated from now on) must inherently be an open system, since the whole reason for it being of interest is that it is capable of interacting with other systems that provide its context. On the other h, any model of a system has to put a boundary round it somewhere, explicitly exclude features that are beyond that boundary, so such a model must equally inherently be of a closed system. The way in which this issue is resolved is by modelling both the SoI its context, by pushing the boundary of the context far enough away from the SoI that the approximation resulting from treating the SoI plus context as a closed system leaves the model of the SoI itself as a sufficiently accurate one. Consequently, the DFD model for any SoI must represent all those entities (which SSADM calls external entities) that either provide input to the SoI or receive output from it, it may also need to represent flows of data between these external entities if these are important to understing the context in which the SoI operates. Hence, what SSADM calls the context diagram models both SoI its context, with enough of the context being included in the model that the combination of SoI context form a closed system. Then, the SoI itself forms an open subsystem of this system, so in the DFA topological layer the actions that form the inputs to outputs from the SoI represent the data flows through which it interacts with its context, the processes internal actions of this subsystem model the structure of the SoI itself. This means that a topological layer specification effectively needs to be developed in two stages. Firstly, the combination of an SoI its context need to be modelled as a closed system, so the topological layer needs to be able to represent such systems. The basic mechanisms by which this is done were outlined in [5], but they need to be developed further, this is done in this section. In particular, there are various properties that we would expect such a system model to possess, such as being non-empty connected, the definitions of these properties need to be developed here. Then, the second stage is to model the SoI as a subsystem of this closed system, but this stage was not discussed in any detail in [5]. Hence, the concepts operations that are needed for this second stage must be developed now, even though many of them are essentially extensions of the concepts of systems. This development is considered in the next section, along with both the extension of basic system properties (such as connectedness) to subsystems, the definition of properties that are specific to subsystems. 2

3 The basis for constructing the topological layer of a DFA specification of a system (which implicitly must be closed) was defined in [5] to consist of two disjoint domains, one corresponding to the processes within that system, denoted by PROC, the other corresponding to the unidirectional channels between the processes, denoted by CHAN. From these two domains a set of possible actions is constructed, denoted by PA, such that any action a in PA has three components that are denoted as a.source PROC, a.channel CHAN a.destination PROC. These therefore form a directed graph, with PROC as the nodes of the graph PA as the edges of it, so this directed graph is the topological layer of the system. Developing this further, we need to make it clear that elements of the domains PROC CHAN are individual processes channels respectively, since this distinction between domains sets of elements belonging to them was not particularly clear from the definition in [5]. Then the domain of systems, which we will call Syst, can be constructed as Syst Í P PROC P CHAN Strictly speaking this is a dependent product rather than a simple Cartesian product, since the elements of CHAN depend on PROC, but there does not seem to be any need to introduce any special notation here to represent this dependency. Hence, the topological layer of any system can be defined as an element of this domain, for it we introduce two observer functions, which we call procs acts, which have signatures Syst P PROC Syst P CHAN respectively, are defined as follows: procs (<ps, cs>) Í ps acts (<ps, cs>) Í cs The nature of the dependency between the two components of a system can be captured by defining an invariant for systems, where the definition of this involves extending to sets of possible actions the observer operations for the components of an individual action that are expressed above using the notation for fields of a record. Hence, two operations need to be defined, which will be called Sources Dests, which both have signatures P PA P PROC, which are defined as follows. Sources (as) Í { a : PA a as a.source } Dests (as) Í { a : PA a as a.destination } Then the dependency can be expressed as an invariant over a characteristic function which is called SysInv, which has the signature that might be expected for a characteristic function of a system, namely Syst Bool, is defined as follows. SysInv (sys) Í Sources (acts (sys)) procs (sys) Dests (acts (sys)) procs (sys) Given this characteristic function, we can make a distinction between the syntactic domain Syst, which does not necessarily incorporate this dependency, the sub-domain of it which does, which we will call LegalSyst. Hence, the syntactic structure of this sub-domain is the same, but it also requires this invariant to hold, so it is defined as follows. LegalSyst Í { sys : Syst SysInv (sys) sys } In what follows, though, we will largely specify the domain of systems as Syst rather than LegalSyst, even in situations where we are also wanting to specify that the invariant must hold. The two operations Sources Dests identify the processes associated with sets of actions, conversely it is also useful to have operations that will identify the actions associated with particular processes. For any specific process there will be two such sets: those that provide inputs to that process, which will therefore be the destination of these actions; those that form outputs from that process, which will therefore be the source of these actions. An issue here is whether an action can be in both sets for some process, meaning that this action would be connecting that process to itself. Such actions, or the channels that they use, might not seem to be particularly useful, but where DFA specifications were being produced from UML sequence diagrams then such channels could be understood as representing self-delegation messages, or the returns from them. Hence they would have some natural role, so there seems to be no good reason to prohibit them. In some situations, though, they do need to be treated as special cases, informally we will from now on refer to such actions as reflexive actions. 3

4 To formalise the concept of these sets of actions we therefore define two operations, called InActs OutActs, which both have the same signature, namely PROC P PA P PA, where the second parameter represents the set of actions from which the identified ones are to be selected. Hence, these two operations are defined as follows. InActs (p, as) Í { a : PA a as a.destination = p a } OutActs (p, as) Í { a : PA a as a.source = p a } It is then convenient to extend these operations to sets of processes as well, so that these extended versions both have the signature P PROC P PA P PA, are defined as follows. InActs (ps, as) Í U OutActs (ps, as) Í U p : PROC p : PROC InActs (p, as) p ps OutActs (p, as) p ps It might also be supposed that one could extend these definitions to systems, but in fact there is little point in doing so, as it follows from the invariant for a system that InActs (procs (sys), acts (sys)) simply evaluates to acts (sys), so too does OutActs (procs (sys), acts (sys)). Indeed, these properties can actually be used as an alternative formulation of the invariant function SysInv, which is expressed as the following theorem. Theorem 1. sys : Syst SysInv (sys) InActs (procs (sys), acts (sys)) = acts (sys) OutActs (procs (sys), acts (sys)) = acts (sys) For the forward implication we have SysInv (sys) Sources (acts (sys)) procs (sys) Dests (acts (sys)) procs (sys) a : PA a acts (sys) a. destination procs (sys) a.source procs (sys) a : PA a acts (sys) a InActs (procs (sys), acts (sys)) a OutActs (procs (sys), acts (sys)) acts (sys) InActs (procs (sys), acts (sys)) acts (sys) OutActs (procs (sys), acts (sys)) InActs (procs (sys), acts (sys)) = U { a : PA a acts (sys) a.destination = p a } p : PROC p procs (sys ) = { p : PROC, a : PA p procs (sys) a acts (sys) a.destination = p a } a : PA, p : PROC p procs (sys) a InActs (p, acts (sys)) a acts (sys) a : PA a InActs (procs (sys), acts (sys)) a acts (sys) InActs (procs (sys), acts (sys)) acts (sys) InActs (procs (sys), acts (sys)) = acts (sys) OutActs (procs (sys), acts (sys)) = U { a : PA a acts (sys) a.source = p a } p : PROC p procs (sys ) = { p : PROC, a : PA p procs (sys) a acts (sys) a.source = p a } a : PA, p : PROC p procs (sys) a OutActs (p, acts (sys)) a acts (sys) a : PA a OutActs (procs (sys), acts (sys)) a acts (sys) OutActs (procs (sys), acts (sys)) acts (sys) OutActs (procs (sys), acts (sys)) = acts (sys). For the reverse implication we have InActs (procs (sys), acts (sys)) = U { a : PA a acts (sys) a.destination = p a } p : PROC p procs (sys ) = { a : PA, p : PROC a acts (sys) p procs (sys) a.destination = p a } a : PA, p : PROC a acts (sys) p procs (sys) a.destination = p a : PA a acts (sys) a.destination procs (sys) Dests (acts (sys)) procs (sys) OutActs (procs (sys), acts (sys)) = U { a : PA a acts (sys) a.source = p a } p : PROC p procs (sys ) = { a : PA, p : PROC a acts (sys) p procs (sys) a.source = p a } a : PA, p : PROC a acts (sys) p procs (sys) a.source = p a : PA a acts (sys) a.source procs (sys) Sources (acts (sys)) procs (sys) so that Sources (acts (sys)) procs (sys) Dests (acts (sys)) procs (sys) SysInv (sys). 4

5 This characterisation of the input output actions for processes can be extended to define the other processes that form the sources of the inputs or the destinations of the outputs. These sets of other processes can be referred to respectively as the suppliers the consumers for a process, to allow for extension to sets of processes to subsystems it will turn out to be convenient to exclude the process itself from the sets of suppliers consumers. Hence, these two concepts can be defined by a pair of functions called Suppliers Consumers respectively, which both have the same signature, namely PROC P PA P PROC where (as for InActs OutActs) the second parameter represents the set of actions from which the inputs outputs are drawn, the two operations are defined as follows. Suppliers (p, as) Í { a : PA a InActs (p, as) a.source p a.source } Consumers (p, as) Í { a : PA a OutActs (p, as) a.destination p a.destination } As with InActs OutActs it is then convenient to extend these operations to sets of processes as well, where the extension of the property that the suppliers consumers may not include the parameter process itself extends to excluding any of the processes in the parameter set. These versions both have the signature P PROC P PA P PROC, are defined as follows. Suppliers (ps, as) Í { a : PA a InActs (ps, as) a.source ps a.source } Consumers (ps, as) Í { a : PA a OutActs (ps, as) a.destination ps a.destination } We could then extend this to a concept that we will call the neighbours of a process or set of processes, which is a set that simply consists of the union of the suppliers the consumers. Hence, it is represented by a function Neighbours that has two version, each with the same signatures as the corresponding versions of Suppliers Consumers, defined as follows. Neighbours (p, as) Í Suppliers (p, as) Consumers (p, as) Neighbours (ps, as) Í Suppliers (ps, as) Consumers (ps, as) These operations also lead to a classification of those processes for which one or other (or both) of these sets of neighbouring processes is effectively empty, in that if we have a process that has no suppliers then its role in the system must be to generate items of data that are to be passed on to other processes, but it can never receive any data. Similarly, if we have a process that has no consumers then its only role in the system can be to receive data, but it can never generate any. We therefore refer to those processes that can only generate data as founts for data, to those that can only receive data as sinks for it. Then, if a process has neither suppliers nor consumers it must have no neighbours, so is incapable of communicating with any other process, meaning that it is completely isolated from them. To formalise this, we introduce three characteristic functions for processes in relation to sets of actions, which we call IsFount, IsSink IsIsolated respectively, each with signature PROC P PA BOOL, defined as follows. IsFount (p, as) Í Suppliers (p, as) = IsSink (p, as) Í Consumers (p, as) = IsIsolated (p, as) Í Neighbours (p, as) = From the practical modelling perspective we certainly want to exclude isolated processes, since they can not communicate with any other processes in a system, but it is not at all clear what the role of fount sink processes should be. One could argue that the context of any SoI is either incompletely modelled, or perhaps even defective, if it includes processes that are either generating inputs to the SoI without receiving any output from it as feedback, or alternatively receiving data without being in any position to respond to the SoI, such as might be desirable if there appear to be problems with the data that has been received. On the other h, it is not uncommon for models to be created that do have either founts or sinks, or even both, which is why it seems necessary to be able to characterise them, it would also seem to be unwise to restrict models from including founts sinks. The next step in developing these concepts is to consider some of the significant objects that belong to the domain Syst, the properties that these objects possess. It will be apparent that the simplest object belonging to this domain is the empty system <, >, but as a system this is of little use, for most practical purposes we shall be concerned with systems that are non-empty. Indeed, there are certain situations where we shall wish to explicitly confine attention to nonempty systems, so it is useful to define another characteristic function for systems, called IsNonEmpty, which also has signature Syst Bool. The definition of this has to reflect the fact that, if the set of processes for a system is empty, then the invariant means that its set of actions must be empty as well. Consequently, if a system is to have a non-empty set of 5

6 actions, which is the main concern in deciding whether the system as a whole is non-empty, then it must have a non-empty set of processes as well, so this function is defined as follows. IsNonEmpty (sys) Í procs (sys) acts (sys) The next simplest objects in this domain are those for which the set of processes is just a singleton set, so that they either have no actions at all, or just actions that connect the single process to itself. In either case these systems are also of little practical use, although they do point to the theoretical possibility that more complex systems could be constructed as the union of two (or more) such systems. Of course, it is intuitively obvious that if the systems being united had disjoint sets of processes then the resulting systems would also not be particularly useful, in that they would consist of components that had no actions by which they could communicate with each other, so we wish to be able to identify such situations. The concepts that are needed for this must be developed formally, this has to be done in four main stages. The first of these stages is to define the union operation between systems, which is represent by the usual symbol has the obvious signature Syst Syst Syst, is defined as sys1 sys2 Í < procs (sys1) procs (sys2), acts (sys1) acts (sys2) > From this there are some obvious properties of this operation, although to express these formally we first need to define equality inequality for systems, as follows. sys1 = sys2 Í procs (sys1) = procs (sys2) acts (sys1) = acts (sys2) sys1 sys2 Í procs (sys1) procs (sys2) acts (sys1) acts (sys2) Then this union operation has the obvious properties that one would expect, namely that it is symmetric, associative, idempotent has the empty system as a zero, which are expressed formally as the following theorem. Theorem 2. sys1, sys2, sys3 : Syst ( sys1 sys2 = sys2 sys1 ) ( sys1 (sys2 sys3) = (sys1 sys2) sys3 ) ( sys1 sys1 = sys1 ) ( sys1 <, > = sys1 ) sys1 sys2 = < procs (sys1) procs (sys2), acts (sys1) acts (sys2) > = < procs (sys2) procs (sys1), acts (sys2) acts (sys1) > = sys2 sys1 sys1 (sys2 sys3) = < procs (sys1) (procs (sys2) procs (sys3)), acts (sys1) (acts (sys2) acts (sys3)) > = < (procs (sys1) procs (sys2)) procs (sys3), (acts (sys1) acts (sys2)) acts (sys3) > = (sys1 sys2) sys3 sys1 sys1 = < procs (sys1) procs (sys1), acts (sys1) acts (sys1) > = < procs (sys1), acts (sys1) > = sys1 sys1 <, > = < procs (sys1), acts (sys1) > = < procs (sys1), acts (sys1) > = sys1. Similarly equality of systems has the usual properties of being reflexive, symmetric transitive, consequently inequality has the usual properties of being symmetric irreflexive, has the usual transitive relationship with equality. These properties are expressed formally as the following theorem. Theorem 3. sys1, sys2, sys3 : Syst ( sys1 = sys1 ) ( sys1 = sys2 sys2 = sys1 ) ( sys1 = sys2 sys2 = sys3 sys1 = sys3 ) ( sys1 sys2 sys2 sys1 ) ( sys1 sys1 ) ( sys1 sys2 sys2 = sys3 sys1 sys3 ) sys1 = sys1 procs (sys1) = procs (sys1) acts (sys1) = acts (sys1) true sys1 = sys2 procs (sys1) = procs (sys2) acts (sys1) = acts (sys2) procs (sys2) = procs (sys1) acts (sys2) = acts (sys1) sys2 = sys1 sys1 = sys2 sys2 = sys3 procs (sys1) = procs (sys2) acts (sys1) = acts (sys2) procs (sys2) = procs (sys3) acts (sys2) = acts (sys3) procs (sys1) = procs (sys3) acts (sys1) = acts (sys3) sys1 = sys3 6

7 sys1 sys2 procs (sys1) procs (sys2) acts (sys1) acts (sys2) procs (sys2) procs (sys1) acts (sys2) acts (sys1) sys2 sys1 ( sys1 sys1 ) ( procs (sys1) procs (sys1) acts (sys1) acts (sys1) (false false ) true sys1 sys2 sys2 = sys3 ( procs (sys1) procs (sys2) acts (sys1) acts (sys2) ) procs (sys2) = procs (sys3) acts (sys2) = acts (sys3) procs (sys1) procs (sys3) acts (sys1) acts (sys3) sys1 sys3. We can also define a containment relation between systems, which will be represent by the usual symbol has the obvious signature Syst Syst Bool, is defined as sys1 sys2 Í procs (sys1) procs (sys2) acts (sys1) acts (sys2) Based on this we can also define a strict containment relation, also represented by the usual symbol having the same signature. In principle there could be two possible definitions of this, since one could either require both components to be not equal, or just require one to be not equal. In practice, though, requiring just one component to be unequal is more consistent with the understing of strict containment as meaning containment but not equality, so this is how we define it, as follows. sys1 sys2 Í sys1 sys2 sys1 sys2 We then have the obvious relationship between containment union, which is expressed as the following theorem. Theorem 4. sys1, sys2 : Syst sys1 sys2 sys1 sys2 = sys2 sys1 sys2 procs (sys1) procs (sys2) acts (sys1) acts (sys2) procs (sys1) procs (sys2) = procs (sys2) acts (sys1) acts (sys2) = acts (sys2) < procs (sys1) procs (sys2), acts (sys1) acts (sys2) > = < procs (sys2), acts (sys2) > sys1 sys2 = sys2. Another important property of this union operation is that, if two systems both satisfy the invariant, their union satisfies it too, this property is expressed as the following theorem. Theorem 5. sys1, sys2 : Syst SysInv (sys1) SysInv (sys2) SysInv (sys1 sys2) SysInv (sys1) Sources (acts (sys1)) procs (sys1) Dests (acts (sys1)) procs (sys1) Sources (acts (sys1)) procs (sys1 sys2) Dests (acts (sys1)) procs (sys1 sys2) SysInv (sys2) Sources (acts (sys2)) procs (sys2) Dests (acts (sys2)) procs (sys2) Sources (acts (sys2)) procs (sys1 sys2) Dests (acts (sys2)) procs (sys1 sys2) so that Sources (acts (sys1)) Sources (acts (sys2)) procs (sys1 sys2) Dests (acts (sys1)) Dests (acts (sys2)) procs (sys1 sys2) Sources (acts (sys1) acts (sys2)) procs (sys1 sys2) Dests (acts (sys1) acts (sys2)) procs (sys1 sys2) Sources (acts (sys1 sys2)) procs (sys1 sys2) Dests (acts (sys1 sys2)) procs (sys1 sys2) SysInv (sys1 sys2). The second main stage in characterising the properties of systems is to formalise the notion of two systems having no processes in common, which we refer to as the systems being disjoint. Provided that the invariant holds for each of the two systems, it is sufficient to specify this in terms of their sets of processes being disjoint, this can be expressed in terms of a characteristic operation called IsDisjoint, which has the signature Syst Syst Bool is defined as follows. IsDisjoint (sys1, sys2) Í procs (sys1) procs (sys2) = 7

8 Then we need to establish formally that the invariant for systems does indeed ensure that if this property holds then the sets of actions must be disjoint as well, this is expressed as the following theorem. Theorem 6. sys1, sys2 : Syst SysInv (sys1) SysInv (sys2) IsDisjoint (sys1, sys2) acts (sys1) acts (sys2) = The proof is by contradiction. Suppose a : PA a acts (sys1) a acts (sys2). Then we must have SysInv (sys1) Sources (acts (sys1)) procs (sys1) Dests (acts (sys1)) procs (sys1) a acts (sys1) a.source procs (sys1) a.destination procs (sys1) SysInv (sys2) Sources (acts (sys2)) procs (sys2) Dests (acts (sys2)) procs (sys2) a acts (sys2) a.source procs (sys2) a.destination procs (sys2) so that a.source procs (sys1) a.source procs (sys2) a.destination procs (sys1) a.destination procs (sys2) but IsDisjoint (sys1, sys2) procs (sys1) procs (sys2) = so there can be no such elements a.source or a.destination that are common to both procs (sys1) procs (sys2), which gives the contradiction. Hence a : PA a acts (sys1) a acts (sys2) acts (sys1) acts (sys2) = so that IsDisjoint (sys1, sys2) acts (sys1) acts (sys2) =. We also have an obvious property of the relationship between disjointness the union operation, namely that if one system is disjoint from each of two others, then it must also be disjoint from their union. This property is expressed formally as the following theorem. Theorem 7. sys1, sys2, sys3 : Syst SysInv (sys1) SysInv (sys2) SysInv (sys3) IsDisjoint (sys1, sys2) IsDisjoint (sys1, sys3) IsDisjoint (sys1, sys2 sys3) IsDisjoint (sys1, sys2) procs (sys1) procs (sys2) = IsDisjoint (sys1, sys3) procs (sys1) procs (sys3) = so that IsDisjoint (sys1, sys2) IsDisjoint (sys1, sys3) ( procs (sys1) procs (sys2) = ) (procs (sys1) procs (sys3) = ) procs (sys1) ( procs (sys2) procs (sys3) ) = IsDisjoint (sys1, sys2 sys3). The third main stage in characterising the properties of systems, particularly ones produced by the union operation, is to develop the notion of connectedness for a system. As is normal for a directed graph there are two versions of this notion, one which reflects the directed nature of an action, the other which ignores it so treats the graph as undirected. For this purpose it is the undirected version of the notion of connectedness that is more appropriate, this is built up in five steps, as follows. The first step is to define a function that characterises a pair of processes that are directly connected, meaning that within a specified set of actions there is some action (with its associated channel) that runs from one to the other, in either direction. The function that represents this property is called IsDConn, has signature PROC PROC P PA Bool, is defined as follows. IsDConn (p1, p2, as) Í p1 p2 ( a : PA a as (a.source = p1 a.destination = p2) (a.source = p2 a.destination = p1) ) In this definition the reason for excluding the case where the two processes are the same, hence ignoring reflexive actions, is that subsequently we will need to construct inductive arguments for connected systems, so will want the definitions to treat the case of two equal processes as separate from the case of two connected processes. As a consequence of this is also that this operation is related directly to the operation Neighbours in a way that is expressed as the following theorem. 8

9 Theorem 8. p1, p2 : PROC, as : P PA IsDConn (p1, p2, as) p2 Neighbours (p1, as) For the forward implication we have IsDConn (p1, p2, as) p1 p2 ( a : PA a as (a.source = p1 a.destination = p2) (a.source = p2 a.destination = p1) ) p1 p2 ( a : PA a as (a OutActs (p1, as) a.destination = p2) (a.source = p2 a InActs (p1, as)) ) p1 p2 ( a : PA a as (a OutActs (p1, as) p2 Dests ({ a })) (p2 Sources ({ a }) a InActs (p1, as)) ) p2 Consumers (p1, as) p2 Suppliers (p1, as) p2 Neighbours (p1, as). For the reverse implication we have p2 Neighbours (p1, as) p2 Consumers (p1, as) p2 Suppliers (p1, as) p1 p2 p2 ( Sources (InActs (p1, as)) Dests (OutActs (p1, as)) ) p1 p2 ( p2 Dests (OutActs (p1, as)) p2 Sources (InActs (p1, as)) ) p1 p2 ( a : PA a as (a OutActs (p1, as) p2 Dests ({ a })) (p2 Sources ({ a }) a InActs (p1, as)) ) p1 p2 ( a : PA a as (a OutActs (p1, as) a.destination = p2) (a.source = p2 a InActs (p1, as)) ) p1 p2 ( a : PA a as (a.source = p1 a.destination = p2) (a.source = p2 a.destination = p1) ) IsDConn (p1, p2, as). The second step in developing the concept of connectedness is to use this operation to define a function that characterises a pair of processes within some specified system that are connected, either directly or indirectly, by actions of that system. The function that represents this property is called IsConn, has signature PROC PROC Syst Bool, is defined as follows, where again we need to exclude the case of a process being connected to itself in order to ensure that inductions over the number of actions needed to connect two processes will terminate. IsConn (p1, p2, sys) Í p1 p2 p1 procs (sys) p2 procs (sys) ( IsDConn (p1, p2, acts (sys)) ( p3 : PROC p3 procs (sys) p3 p1 p3 p2 IsDConn (p1, p3, acts (sys)) IsConn (p3, p2, sys) ) The third step is to extend this second function to systems as a whole, so as to define that a system is connected if every pair of distinct processes in it is connected. This version of the function has signature Syst Bool, is defined as follows, where the definition has to explicitly exclude the cases of an empty system a system with only a single process. IsConn (sys) Í # procs (sys) > 1 p1, p2 : PROC p1 procs (sys) p2 procs (sys) p1 p2 IsConn (p1, p2, sys) The fourth step is then that, in order to reason about connected processes, we require a measure of the distance between two processes, where distance can be measured for this purpose by the number of channels in between them on the shortest route. This measure is defined as a function called ConnDist, which has signature PROC PROC Syst Nat is defined as follows, where to make the function total zero has to be used to signify either that the two processes are not connected, or that they are the same process. ConnDist (p1, p2, sys) Í if IsConn (p1, p2, sys) then 0 elsif p1 = p2 then 0 elsif IsDConn (p1, p2, acts (sys)) then 1 else min ( { p3 : PROC p3 procs (sys) IsDConn (p1, p3, acts (sys)) IsConn (p3, p2, sys) 1 + ConnDist (p3, p2, sys) } ) fi. A corollary of this definition, which is important for using it as a measure for inductions, is that if a pair of processes are connected but not directly connected, then the first one must be directly connected to a third that has a connection distance to the second that is one less than the connection distance of the first. This property is expressed as the following theorem. 9

10 Theorem 9. sys : Syst, p1, p2 : PROC SysInv (sys) p1 p2 IsConn (p1, p2, sys) IsDConn (p1, p2, acts (sys)) ( p3 : PROC p3 procs (sys) p3 p1 p3 p2 IsDConn (p1, p3, acts (sys)) IsConn (p3, p2, sys) ConnDist (p3, p2, sys) = ConnDist (p1, p2, sys) 1 ) The first stage is to show that the conditions of the theorem ensure that # procs (sys) 3. We have IsConn (p1, p2, sys) p1 procs (sys) p2 procs (sys) p1 p2 # procs (sys) 2 IsConn (p1, p2, sys) IsDConn (p1, p2, acts (sys)) ( p3 : PROC p3 procs (sys) p3 p1 p3 p2 IsDConn (p1, p3, acts (sys)) IsConn (p3, p2, sys) ) # procs (sys) 3. Hence it is guaranteed that there is at least one such process p3, there may well be many such. Also, from the definition of ConnDist we have IsConn (p1, p2, sys) IsDConn (p1, p2, acts (sys)) ConnDist (p1, p2, sys) = min ( { p3 : PROC p3 procs (sys) IsDConn (p1, p3, acts (sys)) IsConn (p3, p2, sys) 1 + ConnDist (p3, p2, sys) } ) p3 : PROC p3 procs (sys) IsDConn (p1, p3, acts (sys)) IsConn (p3, p2, sys) ConnDist (p1, p2, sys) = 1 + ConnDist (p3, p2, sys) ConnDist (p3, p2, sys) = ConnDist (p1, p2, sys) 1 IsDConn (p1, p3, acts (sys)) p3 p1 IsDConn (p1, p3, acts (sys)) IsDConn (p1, p2, acts (sys)) p3 p2 Hence, by putting p3 = p3, we get ( p3 : PROC p3 procs (sys) p3 p1 p3 p2 IsDConn (p1, p3, acts (sys)) IsConn (p3, p2, sys) ConnDist (p3, p2, sys) = ConnDist (p1, p2, sys) 1 ). The fifth final step in developing the notion of connectedness is then to establish some key results that follow from this property of the measure of connection distance. The most important such result is that, if two processes are each connected to a third, then they must be connected, this together with the corresponding relationship between the connection distances of the pairs of processes is expressed as the following theorem. Theorem 10. sys : Syst, p1, p2, p3 : PROC SysInv (sys) p1 p2 p1 p3 p2 p3 IsConn (p1, p2, sys) IsConn (p2, p3, sys) ( IsConn (p1, p3, sys) ConnDist (p1, p3, sys) ConnDist (p1, p2, sys) + ConnDist (p2, p3, sys) ) The first stage in the proof is to observe that IsConn (p1, p2, sys) p1 procs (sys) p2 procs (sys) IsConn (p2, p3, sys) p2 procs (sys) p3 procs (sys) so that p1 p2 p1 p3 p2 p3 # procs (sys) 3. Then the proof is basically by induction over the connection distance between the processes p1 p2, so that the main base case for it are where they are directly connected (ie with connection distance one), but there is also a second base case where processes p1 p3 are directly connected. The recursive case is then where p1 p3 are not directly connected, p1 p2 are any pair with connection distance greater than one. The induction hypothesis is therefore that, for any natural number n, the theorem holds for all p1 p2 such that ConnDist (p1, p2, sys) < n, the induction step is to show that the theorem therefore also holds for all p1 p2 such that ConnDist (p1, p2, sys) = n. Hence, the three cases for the proof are as follows, where the recursive case will actually require # procs (sys) 4, although that is a consequence of the proof construction rather than a part of the argument that is needed for the proof. Base case (i): IsDConn (p1, p3, acts (sys)), so that we have immediately IsDConn (p1, p3, acts (sys)) IsConn (p1, p3, sys) IsDConn (p1, p3, acts (sys)) ConnDist (p1, p3, sys) = 1 IsConn (p1, p2, sys) p1 p2 ConnDist (p1, p3, sys) 1 10

11 IsConn (p2, p3, sys) p2 p3 ConnDist (p2, p3, sys) 1 ConnDist (p1, p2, sys) + ConnDist (p2, p3, sys) 2 > 1 = ConnDist (p1, p3, sys) ConnDist (p1, p3, sys) ConnDist (p1, p2, sys) + ConnDist (p2, p3, sys). Base case (ii): IsDConn (p1, p3, acts (sys)) IsDConn (p1, p2, acts (sys)), so that from the definition of IsConn we have IsDConn (p1, p2, acts (sys)) IsConn (p2, p3, sys) IsConn (p1, p3, sys) ConnDist (p1, p3, sys) = min ( { p2 : PROC p2 procs (sys) IsDConn (p1, p2, acts (sys)) IsConn (p2, p3, sys) 1 + ConnDist (p2, p3, sys) } ) 1 + ConnDist (p2, p3, sys) = ConnDist (p1, p2, sys) + ConnDist (p2, p3, sys). Recursive case: IsDConn (p1, p3, acts (sys)) IsDConn (p1, p2, acts (sys)), so that we have IsConn (p1, p2, sys) ConnDist (p1, p2, sys) 0 p1 p2 ConnDist (p1, p2, sys) 0 ConnDist (p1, p2, sys) 1 IsDConn (p1, p2, acts (sys)) ConnDist (p1, p2, sys) 1 ConnDist (p1, p2, sys) > 1 IsConn (p2, p3, sys) ConnDist (p2, p3, sys) 0 p2 p3 ConnDist (p2, p3, sys) 0 ConnDist (p2, p3, sys) 1 IsConn (p1, p2, sys) IsDConn (p1, p2, acts (sys)) ( p4 : PROC p4 procs (sys) p4 p1 p4 p2 IsDConn (p1, p4, acts (sys)) IsConn (p4, p2, sys) ConnDist (p4, p2, sys) = ConnDist (p1, p2, sys) 1 ) theorem 9 IsConn (p4, p2, sys) IsConn (p2, p3, sys) IsConn (p4, p3, sys) induction hypothesis so that from the definition of IsConn we have IsDConn (p1, p4, acts (sys)) IsConn (p4, p3, sys) IsConn (p1, p3, sys) IsConn (p4, p2, sys) IsConn (p2, p3, sys) ConnDist (p4, p3, sys) ConnDist (p4, p2, sys) + ConnDist (p2, p3, sys) ConnDist (p4, p3, sys) ConnDist (p1, p2, sys) + ConnDist (p2, p3, sys) 1 so that from the definition of ConnDist we have IsDConn (p1, p4, acts (sys)) IsConn (p4, p3, sys) ConnDist (p1, p3, sys) 1 + ConnDist (p4, p3, sys) ConnDist (p1, p2, sys) + ConnDist (p2, p3, sys) = ConnDist (p1, p2, sys) + ConnDist (p2, p3, sys). 11 induction hypothesis The induction then starts from the second base case, where ConnDist (p1, p2, sys) = 1, the inductive step is that, since by the combination of the first base case the recursive case the theorem holds for all pairs of processes p1 p2 such that ConnDist (p1, p2, sys) < n, it must therefore also hold for all pairs with ConnDist (p1, p2, sys) = n. Hence the result is proved for successive values of n from 1 upwards, which establishes the theorem as a whole. Given these properties of connected systems the connection distance measure, then there is also another result that is required before we are in a position to show that a union of disjoint systems can not be connected. This result is that, if the set of processes of a connected system is partitioned into two disjoint non-empty subsets, then there must be some pair of processes such that one belongs to each subset the two processes are directly connected. This property of systems is expressed as the following theorem. Theorem 11. sys : Syst, ps1, ps2 : P PROC SysInv (sys) ps1 ps2 = procs (sys) ps1 ps2 ps1 ps2 = IsConn (sys) p1, p2 : PROC p1 ps1 p2 ps2 IsDConn (p1, p2, acts (sys)) ps1 ps2 p1, p2 : PROC p1 ps1 p2 ps2. Then consider any arbitrary pair of such processes p1 p2, we have IsConn (sys) IsConn (p1, p2, sys) so that the result of the theorem could be restated for this pair as IsConn (p1, p2, sys) p1, p2 : PROC p1 ps1 p2 ps2 IsDConn (p1, p2, acts (sys)) Then the proof is basically by induction over the connection distance between p1 p2, so that the base case for it is where they are directly connected (ie with connection distance one), with p1 = p1 p2 = p2, the recursive case is where p1 p2 are any pair with connection distance greater than one. Hence the induction hypothesis is that, for any

12 natural number n, the theorem holds for all p1 p2 such that ConnDist (p1, p2, sys) < n, the induction step is to show that the theorem therefore also holds for all p1 p2 such that ConnDist (p1, p2, sys) = n. Hence, the two cases for the proof are as follows. Base case: IsDConn (p1, p2, acts (sys)), so that we have immediately p1 = p1 p2 = p2 p1 ps1 p2 ps2 IsDConn (p1, p2, acts (sys)). Recursive case: IsDConn (p1, p2, acts (sys)), so that we have IsConn (p1, p2, sys) IsDConn (p1, p2, acts (sys)) ( p3 : PROC p3 procs (sys) p3 p1 p3 p2 IsDConn (p1, p3, acts (sys)) IsConn (p3, p2, sys) ConnDist (p3, p2, sys) = ConnDist (p1, p2, sys) 1 ) theorem 9. Then there are two sub-cases, depending on whether p3 is an element of ps1 or ps2, where ps1 ps2 guarantees that both of these cases could arise, for either of them we would have p3 ps1 ps1 ps2 = p3 ps2 p3 ps2 ps1 ps2 = p3 ps1. Sub-case: p3 ps2, so that we have immediately p1 = p1 p2 = p3 p1 ps1 p2 ps2 IsDConn (p1, p2, acts (sys)). Sub-case: p3 ps1, so that we have immediately IsConn (p3, p2, sys) p1, p2 : PROC p1 ps1 p2 ps2 IsDConn (p1, p2, acts (sys)) induction hypothesis. The induction then starts from the base case, where ConnDist (p1, p2, sys) = 1, the inductive step is that, since the restated version of the theorem holds for all pairs of processes p1 p2 such that ConnDist (p1, p2, sys) < n, it must therefore also hold for all pairs with ConnDist (p1, p2, sys) = n. Hence, since the theorem itself follows immediately from this restated version, the result is proved for successive values of n from 1 upwards, which establishes the theorem as a whole. The fourth final stage in developing the properties of systems is to use this machinery in order to prove the main result concerning systems that have been produced by the union operation, namely that a union of disjoint systems is not connected, this property is expressed as the following theorem. Theorem 12. sys1, sys2 : Syst SysInv (sys1) SysInv (sys2) IsNonEmpty (sys1) IsNonEmpty (sys2) IsDisjoint (sys1, sys2) IsConn (sys1 sys2) The proof is by contradiction. Suppose IsConn (sys1 sys2). Then we have SysInv (sys1) SysInv (sys2) SysInv (sys1 sys2) theorem 5 procs (sys1) procs (sys2) = procs (sys1 sys2) IsDisjoint (sys1, sys2) procs (sys1) procs (sys2) = IsNonEmpty (sys1) IsNonEmpty (sys2) procs (sys1) procs (sys2) so that we must then have IsConn (sys1 sys2) p1, p2 : PROC p1 procs (sys1) p2 procs (sys2) IsDConn (p1, p2, acts (sys1 sys2)) theorem 11 a : PA a acts (sys1 sys2) ( (a.source = p1 a.destination = p2) (a.source = p2 a.destination = p1) ) a : PA a acts (sys1 sys2) ( (a.source procs (sys1) a.destination procs (sys2)) (a.source procs (sys2) a.destination procs (sys1)) ). But a acts (sys1 sys2) a acts (sys1) a acts (sys2) IsDisjoint (sys1, sys2) acts (sys1) acts (sys2) = theorem 6 a acts (sys1) acts (sys1) acts (sys2) = a acts (sys2) a.source procs (sys1) a.destination procs (sys1) a.source procs (sys2) a.destination procs (sys2) a acts (sys2) acts (sys1) acts (sys2) = a acts (sys1) 12

13 a.source procs (sys2) a.destination procs (sys2) a.source procs (sys1) a.destination procs (sys1) so that a : PA a acts (sys1 sys2) ( (a.source procs (sys1) a.destination procs (sys2)) (a.source procs (sys2) a.destination procs (sys1)) ) which gives the contradiction. Hence the original supposition must be false, we have IsConn (sys1 sys2). The significance of this key property is that, when the union of two disjoint systems is constructed, then because the resultant system is not connected it must effectively consist of two (or possibly more) parts that can each be regarded as some kind of subsystem. Furthermore, since these parts can not communicate with each other, it will be intuitively obvious that they are therefore closed, even though we have not yet developed a formal characterisation of this property for any arbitrary part of a system, except for identifying the property that an individual process may be isolated, which is obviously a special case of being closed. The fact that these parts are closed system means that they are of very limited use as subsystems, so we want to distinguish them from normal subsystems, which are expected to be open rather than closed. We will therefore refer to disjoint parts of a system that are of this form as partitions of a system, which implicitly can be understood to be systems in their own right, hence to be closed. In principle we could then try to develop theory to show that any system that is not connected could be constructed as a union of non-empty partitions, where each partition would be either an isolated process or a connected system. In practice, though, since we are primarily concerned with constructing models that are based on connected systems, there is little point in developing such theory, although the fact that subsystems may be closed will mean that such subsystems can also be regarded as a form of partition, so we shall want to develop results of this form for subsystems. In doing this we shall therefore need to explore the relationships between partitions of systems subsystem partitions, so as to show how partitions of systems function as a form of subsystem. 3. Topological Aspects of Subsystems In order to define the more general concept of a subsystem that is needed to characterise open subsystems of a closed system, it is very tempting to equate a subsystem just with some subset of the processes of the system, but of course a subsystem must have a set of actions as well, so it must be more than just some set of processes. Hence, a subsystem has to be characterised by two aspects: the system of which it is a part, the set of processes that defines which part of that system is being considered. We need some terminology for these aspects, so we will call the system that contains a subsystem its host, we will say that the set of processes form the basis of a subsystem, or that a subsystem is based on a set of processes. To formalise this, we therefore define a domain of subsystems that we call SubSyst, which is constructed as SubSyst Í Syst P PROC For this domain we then introduce two observer functions to extract the two components, which we call host basis, so that these have signatures SubSyst Syst SubSyst P PROC respectively, are defined as follows: host (<sys, ps>) Í sys basis (<sys, ps>) Í ps As with the construction of the domain of systems, elements of SubSyst are actually dependent pairs, as for systems this dependency can be expressed as an invariant over a characteristic function. This function is called SubSysInv, has the signature that might be expected for a characteristic function of a subsystem, namely SubSyst Bool. It turns out to be convenient in practice for the definition of this function to also include a term that requires the system invariant to hold as well, so it is as follows. SubSysInv (ss) Í SysInv (host (ss)) basis (ss) procs (host (ss)) Also as for systems we can use this characteristic function to make a distinction between the syntactic domain SubSyst, which does not necessarily incorporate this dependency, the sub-domain of it which does, which in similar fashion we will call LegalSubSyst. Hence, the syntactic structure of this sub-domain is the same, but it also requires this invariant to hold, so it is defined as follows. LegalSubSyst Í { ss : SubSyst SubSysInv (ss) ss } 13

14 Again, though, in what follows we will largely specify the domain of subsystems as SubSyst rather than LegalSubSyst, even in situations where we are also wanting to specify that the invariant must hold. To characterise the actions of a subsystem, we need to observe that for any proper subset of the processes of a system the set of actions may potentially be partitioned into four mutually exclusive subsets. One subset will be those actions that are internal to the set of processes, in the sense that both the sources the destinations of their channels will be processes in this set. A second subset will be those actions that are external to the set of processes in a similar sense, so that both the sources the destinations of their channels will be processes that are outside this set. A third subset will be those actions that represent inputs to the set of processes, so that the sources of their channels will be processes that are outside the set, while the destinations of those channels will be processes in this set. Finally, the fourth subset will be those actions that similarly represent outputs from the set of processes, so that the sources of their channels will be processes that are in the set, while the destinations of those channels will be processes that are outside it. To represent these formally, we define four operations that will extract from a set of actions these four subsets for some set of processes. These operations are called Internals, Externals, Inputs Outputs respectively, they each have the same signature, namely P PA P PROC P PA, are defined as follows. Internals (as, ps) Í { a : PA a as a.source ps a.destination ps a } Externals (as, ps) Í { a : PA a as a.source ps a.destination ps a } Inputs (as, ps) Í { a : PA a as a.source ps a.destination ps a } Outputs (as, ps) Í { a : PA a as a.source ps a.destination ps a } It is then convenient to extend each of these operations to apply to subsystems, so that these versions of the operations will all have the signature SubSyst P PA, they are defined as follows. Internals (ss) Í Internals (acts (host (ss)), basis (ss)) Externals (ss) Í Externals (acts (host (ss)), basis (ss)) Inputs (ss) Í Inputs (acts (host (ss)), basis (ss)) Outputs (ss) Í Outputs (acts (host (ss)), basis (ss)) The combination of the inputs outputs of a subsystem then represents the interface that that subsystem provides to other subsystems, so it is convenient to define an operation to represent it, which is called Interface, has the same signature SubSyst P PA, is defined as follows. Interface (ss) Í Inputs (ss) Outputs (ss) Furthermore, the combination of the internal actions of a subsystem its interface then constitutes the set of those actions that are involved in the operation of the subsystem, so it is also convenient to define an operation to represent this set. We refer to these actions as the included actions of the subsystem, so this operation is called Included, has the same signature SubSyst P PA, is defined as follows. Included (ss) Í Internals (ss) Interface (ss) Also, while we showed that there was no point in extending the definition of InActs OutActs to systems, there is more point in extending them to subsystems, to produce versions which also have the signatures SubSyst P PA, as follows. InActs (ss) Í InActs (basis (ss), acts (host (ss))) OutActs (ss) Í OutActs (basis (ss), acts (host (ss))) We then have some relationships between these various operations, provided that the subsystem invariant holds, in that any input action to some process in the subsystem must either be an input action to the subsystem as a whole, or an internal action of the subsystem, so that it will also be one of the output actions of a process in the subsystem as well. Similarly, an output action from some process in the subsystem must either be an output action from the subsystem as a whole, or again an internal action of the subsystem, if it is also an input action to one of the processes in the subsystem. These properties are therefore expressed as the following theorem. 14