MODEM MODAF Migration Providing an ontological foundation Chris Partridge February 2011 -- 1 of 69 -- 2 Contents Preface ....................................................................................................................................... 3 Executive Summary.................................................................................................................... 4 Real World Analysis Overview ................................................................................................... 6 Background ............................................................................................................................ 6 State Type Succession pattern – real world analysis ........................................................... 12 Interaction Diagrams – real world analysis.......................................................................... 20 Summary .............................................................................................................................. 29 IDEAS Detailed Technical Analysis ........................................................................................... 30 Introduction ......................................................................................................................... 30 State Type Succession pattern –real world analysis ............................................................ 30 Interaction pattern – real world analysis............................................................................. 49 Summary .............................................................................................................................. 58 Appendices............................................................................................................................... 61 Appendix A – MODAF UML Behaviour Scope ...................................................................... 62 Appendix B – State diagram as a mathematical structure – example definition ................ 67 Appendix C – State machines as a formal structure in the UML Superstructure Specification ......................................................................................................................... 68 -- 2 of 69 -- 3 Preface This report on the MODEM project is in three sections: 1. An executive summary that explains the motivation for the MODEM work. 2. An introduction to the real world analysis that was done as part of the MODEM work, which gives a deeper understanding of the ideas that underlie it and provides examples of their use. 3. A detailed technical IDEAS analysis explaining the IDEAS MODEM model. Each of the sections builds upon the previous section and is aimed at a different audience. The first section is aimed at management who need to understand the basis for the MODEM work. The second section is aimed at users who need to understand the issues that the MODEM work raises without delving into the technical details of the IDEAS model. The third and final section provides the detailed IDEAS analysis for the technical experts. -- 3 of 69 -- 4 Executive Summary Coalition operations are going to be a feature in the defence landscape for the foreseeable future. Effective and efficient coalition operations require collaboration at all levels. The IDEAS Group is a multinational project that aims to significantly improve collaboration at the level of military enterprise architectures through the development of a data exchange format. The purpose is to allow seamless sharing of architectures between the partner nations regardless of which modelling tool or repository they use. Prior to the start of the project, the partner nations used a variety of architectural frameworks, tools and repositories and this made sharing of architectures a difficult manual task. The group’s goal is to develop a standard foundation upon which each partner nation builds its architectural framework, which will enable seamless sharing. The group recognised that its most difficult challenge was to develop a format that worked at the level of meaning; so that when deployed it gave assurance of a common understanding of the data exchanged. With this requirement in mind, they developed the tool and repository agnostic IDEAS Foundation and issued it in April 2009. The next stage in the development is for the member nations to migrate their frameworks onto the IDEAS Foundation. The US has now completed the migration of their DODAF metamodel onto the IDEAS Foundation – producing DM2 (DODAF Metamodel 2) – and is consolidating the revised model. Sweden has initiated the MODEM (MODAF Ontological Data Exchange Model) migration project. Its goal is to migrate the MODAF metamodel (M3) onto an IDEAS Foundation. When this is complete, the US DODAF and MODEM architectural framework will have a common foundation. Multi-National Frameworks Multi-National Frameworks Current Situation Target Situation IDEAS extends MODAF (MODEM) MetaModel Extension UML MetaModel extends MODAF (UML) MetaModel Extension extends DODAF MetaModel (DM2) Extension IDEAS extends DODAF MetaModel (DM2) Extension Figure 1 - Migrating to a common ontological framework This will establish a foundation to take the nations to the next level of unification – a core for a unified defence enterprise architecture (EA) model. Clearly, there are many benefits to this. Each nation would have greatly reduced maintenance costs as framework development and change management would be shared between the nations. A single framework with a single metamodel also represents a more attractive market to EA tool vendors and so would increase choice, competition and quality. -- 4 of 69 -- 5 Currently the MODAF metamodel is built upon the UML foundation. There are several issues with this. It limits the vendors that can easily support MODAF to UML vendors. Furthermore UML is not an ideal foundation for EA models. It originated from, and so was designed for, a technical programming environment rather than enterprise architecture. One result is that it has a number of technical features more suited to programming and systems development, some of which can cause EA interoperability problems. In addition, it was not designed to work at the level of meaning and so is unsuitable as a foundation in this project. The migration from UML to MODEM will resolve these issues. NATO nations (and NC3A) have expressed very forcefully the need for a non-UML based NAF (NATO Architecture Framework) foundation. The migration will enable MODAF to meet the requirement from NATO to have a NAF model without UML dependencies. There is a significant investment in MODAF, both directly in the MODAF metamodel and users’ models and indirectly in the investment in UML. The MODEM migration aims to harvest and build upon this investment. The MODEM migration aims to:  harvest the relevant features of UML and the MODAF metamodel and migrate them to MODEM,  winnow out the irrelevant technical features – particularly the constraints that were stovepiping the UML metamodel and the MODAF metamodel built upon it,  provide a clearer picture of the enterprise – one which reveals the common underlying business patterns across what previously appeared as very different areas, and  provide a migration path for the existing MODAF models. This enables the partners using MODAF to take advantage of the significant historic investment made in:  the UML foundation without having to also take on the burden of irrelevant features and constraints,  the UML-based MODAF model, while also providing access to the improved features of the new foundation, and  the users’ existing MODAF models. And to do this while moving to a more flexible foundation that provides a basis for significantly improved collaboration at the level of military enterprise architectures through the seamless sharing of architectures between the partner nations regardless of which modelling tool or repository they use. -- 5 of 69 -- 6 Real World Analysis Overview Background In the late 20th Century, enterprises grew to unprecedented levels of both size and complexity. It was recognised (early on by John Zachman) that this was creating a situation where the enterprise’s architecture needed to be engineered rather than accidental. One of the challenges was devising engineering tools as none existed. John Zachman developed the first of these - his Zachman Framework – and the discipline of Enterprise Architecture was born. Since then a number of other frameworks have been developed and it is now recognised that a framework is an essential tool for enterprise architecture. In the last few years, people have started to recognise that in order to develop a common understanding these frameworks need to be informed by ontology, particularly a top ontology. John Zachman has been vocal about this and started rethinking his framework in the light of this requirement. What ontology brings is a way of enabling the framework to present a clear picture of the enterprise – a real world semantics – where the enterprise models actually accurately reflect the real enterprise. And this clear picture provides a common reference point that is a solid basis for a common understanding. Some years ago, the multi-national IDEAS Group realised the importance of ontology both for enterprise architecture frameworks in general and also specifically for enterprise architecture (EA) interoperability (a key requirement for coalition collaboration). They realised that if the coalition forces used the same top ontology and so shared a real world semantics, they could greatly simplify the exchange of enterprise architectures thereby improving collaboration and coordination. Hence, they devised and published a suitable top ontology – The IDEAS Foundation – to act as a common foundation for each nation’s architectural framework. The US has migrated their architectural framework - DODAF – onto the IDEAS Foundation, producing DM2 (DODAF Metamodel 2). SweAF has taken on the task of starting the migration of the MODAF Meta-Model to the IDEAS Foundation, with the goals of providing a stable baseline for MODAF and aligning with what has been done with DM2. This migration is shown graphically in Figure 2. -- 6 of 69 -- 7 MODAF (MODEM) MetaModel MODAF (UML) MetaModel Current M3 Framework Proposed MODEM Framework UML Superstructure UML Behaviour IDEAS extends MODAF (UML) MetaModel Extension extends MODEM Common Patterns extends MODAF (MODEM) MetaModel Extension Figure 2 - Migrating MODAF to an ontological foundation Real world semantics As noted earlier, a key benefit of the migration is the provision of a real world semantics. From an EA perspective, the boxes and lines in their models need to have a clear connection to the real world – a real world semantics. If the EA model has boxes with the text ‘cat’ and ‘mat’ and a line joining the boxes with them with the text ‘sat on the’ – then there needs to be some confidence that people will interpret this as being about a cat sitting on a mat. There should be no worries that the users might interpret ‘cat’ as a dog or ‘sat on the’ as slept under – or that different users might interpret the model in different ways. In the case of simple examples using cats and mats, there is little reason for concern. But once the enterprise become bigger, there is a need for a semantic framework to bring a level of rigour. In UML, as in many other modelling frameworks, the overarching framework was not designed with these semantic requirements in mind – though the examples often pay lip service it. The UML structures grew from a programming language base and are strongly influenced by this and the desire to be able to automatically generate program code from the models – which are not core requirements for EA. This lead to a focus on formal structure and a corresponding lack of focus on the real world semantics. Appendices B and C give a flavour of this. Appendix B contains a formal description of a state machine and Appendix C contains descriptions of the UML state machine. The result is often a framework that can hinder rather than help the uncovering of the real world semantics - there are a number of examples of this in the analysis section. In modelling situations, such as EA in general and MODAF in particular, it is vital that the real world semantics are clear. Hence, an important aim of this project is to provide MODAF with a semantic framework –the IDEAS Foundation. The introduction of real world semantics to MODAF will help to improve the semantic quality of the data exchange of enterprise architectures. It will lead to the removal of implementation constraints and so give a clearer real world semantics – as well as a more flexible structure. This in turn provides a better picture of the common underlying business patterns. Which leads to simpler, more accurate, models. Which leads to a better common understanding. -- 7 of 69 -- 8 The Approach Devising structures to support UML’s specific goals created architectural pressures that hid the underlying real world semantics. A basic task of the analysis was to reconstruct the hidden real world semantics. It used the BORO Method and this enabled the:  harvesting of the relevant features of UML and migrate them to MODEM,  winnowing out of the irrelevant technical features – particularly the constraints that were stove piping the UML metamodel,  provision of a migration path for the existing MODAF models, and  provision of clearer simpler picture of the enterprise – one which reveals the common underlying business patterns across what previously appeared as very different areas. This enables the IDEAS partners to take advantage of the significant historic investment made in the UML and MODAF metamodels without also having to take on the burden of irrelevant features and constraints. MODAF (MODEM) MetaModel MODAF (UML) MetaModel Current M3 Framework Proposed M3 Framework UML Superstructure UML Behaviour IDEAS extends MODAF (UML) MetaModel Extension extends MODEM extends MODAF (MODEM) MetaModel Extension Useful patterns Irrelevant technical constraints Figure 3 - Harvesting and winnowing the patterns It also provides the vendors with the specification of a migration that would allow existing MODAF users to migrate to the MODEM Foundation and take advantage of the new functionality at little or no cost. Furthermore this ensures that MODEM provides a truly EA tool-agnostic representation of MODAF. The elimination of the UML-dependency should help to increase the set of EA tool vendors that base their EA approach on a common metamodel – providing the IDEAS partners with greater choice. Use of IDEAS Foundation The analysis process used the IDEAS Foundation to reconstruct the missing real world semantics starting from the existing UML metamodel. In order to maximise the benefits of the IDEAS Foundation, great care was taken to ensure that the whole of the IDEAS -- 8 of 69 -- 9 Foundation was used without any modification, and that where a pattern existed in the foundation it was used rather than re-invented at a lower level. Also a clear distinction between the IDEAS Foundation and the MODEM extension was maintained. Where important common business patterns were discovered, these were marked as candidates to be promoted to the foundation in a future version of the foundation. Scope of the report Two aspects of the MODAF metamodel use native UML without any additional MODAF structure – state machines and interactions. In other words, no new stereotypes are defined in M3 for these areas. This presents a challenge to the migration project in that the semantics of those UML aspects must be fully analysed to identify the required functionality to be met by new IDEAS patterns for interactions and state transitions. Both these aspects fall within the UML behaviour model1. This report describes the migration of these two aspects. This report describes the analysis for the behaviour section of M3 and UML and illustrates the harvesting, winnowing and simplifying that has taken place. There is significant scope for this in the behaviour section of the UML metamodel as its constraints lead to a particularly stovepiped architecture. Here are a couple of examples that highlight these issues. The scope of UML behaviour can be traced to MODAF views. State Machine diagrams are used in OV6b and SV10b and Interaction diagrams in OV6c and SV10c, where OV deals with nodes and SV deals with resources. Appendix A contains an overview of these diagrams. State Machine and Interaction diagrams can be viewed as complementary. Where one wants to look at the behaviour of a single object, state machines are used. Where one wants to look at behaviour across objects, interaction diagrams are used. Process Detail The analysis has clarified the main features of the real world semantics for ‘behaviour’ – the relationships between objects over time. It has mined the UML Behaviour model, stripping away the particular implementation decisions that UML made to reveal the underlying structure. The resulting patterns are not only a clearer picture of the real world but they also show the underlying simple straight-forward structures and so are easier for users to work with. Taking away the particular implementation constraints has resulted in a structure that gives a closer fit to EA user requirements and is more flexible than the original UML patterns. The BORO analysis worked from the bottom up. It started by developing a clear picture of the individual objects that the UML structures were describing (the UML structures are several type layers above the individuals). Once this was established, it worked up the type layers. There is a detailed record of this analysis in the Worked Examples report. Given how 1 They are specified in Chapters 14 ‘Interactions’ and 15 ‘State Machines’ in UML Superstructure Specification, v2.3. -- 9 of 69 -- 10 key the formal structure is, extensive automated validation was performed on the MODEM model and examples. It identified two core behaviour patterns that underlie the two UML diagrams:  A pattern that deals with an object’s state successions, which is handled by UML State Machines.  A pattern that deals with the exchanges between the different objects participating in an interaction, which is handled by UML Interaction messages. In UML, these two diagrams are in separate stovepipes with no overlap. The types of element in one diagram cannot appear in the other. One of the identified requirements was to break down this stovepipe and allow elements to appear in both diagrams. The analysis not only did this but also identified that the patterns associated with state machines are at the heart of the interaction diagram. UML Interoperability Issues UML’s lack of a real world semantics (and so the benefits of moving to a MODEM Foundation) can be illustrated by the kind of semantic interoperability issues that are endemic within UML where different nations may take different views of the same domain. UML State Machines and Interaction diagrams tend to assume that there is only a single view of the enterprise and so do not allow any other alternate views. However, in coalitions with multiple partners there are likely to be multiple views. The following examples illustrate the issue. This example is shown graphically in Figure 4. In UML one can choose which states to include in a state machine. If Nation 1 chooses to include three states in a state machine and Nation 2 chooses to only include two of these states, then it is impossible in UML to combine the two models. There is no real world semantics reason why one should not be able to do this, so it is possible within MODEM. Coalition (Combined) View Nation 2 Nation 1 State Machine C 1 2 UML  MODEM  3 State Machine D 1 2 State Machine C State Machine D 1 2 3 Figure 4 - Interoperability issues - partial views This example is shown graphically in Figure 5. In UML one cannot inherit either states or state machines. But if Nation 1 chooses to include three states in a state machine and Nation 2 chooses model sub-states of two of these, this cannot be described directly in -- 10 of 69 -- 11 UML. There is no real world semantics reason why one should not be able to do this, so it is possible within MODEM. Coalition (Combined) View Nation 2 Nation 1 State Machine C 1 2 UML  MODEM  3 State Machine D 4 5 State Machine C State Machine D 1 2 3 4 5 Figure 5 - Interoperability issues - inheritance This example is shown graphically in Figure 6. In UML one can describe exactly the same orthogonal regions in a single state machine or multiple state machines. If Nation 1 describes the two regions in two state machines and Nation 2 describes them in one state machine, then it is impossible in UML to combine the two models. There is no real world semantics reason why one should not be able to do this, so it is possible within MODEM. Coalition (Combined) View State Machine C State Machine A 1 2 State Machine B 3 4 Nation 2 State Machine C 1 2 3 4 Nation 1 State Machine A 1 2 State Machine B 3 4 UML  MODEM  Figure 6 - Interoperability issue example - regions While UML’s constraints might make sense in a programming situation, they hinder interoperability between different nations’ models. -- 11 of 69 -- 12 State Type Succession pattern – real world analysis This section focuses on the real world semantics for state machines. UML State Machines - Examples We use a number of examples to help guide the analysis and illustrate the results. The UML specification contains a number of examples. Figure 7 shows the one used as a basis for the analysis. Figure 7 – “Figure 15.12 - Protocol state machine” (p. 552 - UML Superstructure Specification, v2.3) The Figure 7 example is extended in Figure 8 to show multiple (concurrent) ‘orthogonal regions’ and ‘hierarchically nested states’. ‘Door Open-Closed-Locked’ and ‘Door Alarmed’ are both ‘orthogonal regions’ of the Door State Machine. ‘Alarm Level One’ and Alarm Level Two’ are sub-states of ‘Door Alarmed’ (in its submachine). Figure 8 - Extended Example Real World Semantics for a ‘State Successions’ pattern The starting point for the analysis is the ‘state succession pattern’. The first task in unbundling this is to establish from a real world semantics perspective, what a state is, what it is that has a succession. stm Door State Machine Door State Machine [Door Open-Closed-Locked] [Door Alarmed] Door Closed Door Locked Initial Door Open Door Alarmed Alarm Lev el One Alarm Lev el Tw o close door [doorway->isEmpty()] door creation unlock door lock door open door alarm on - off -- 12 of 69 -- 13 A real world state From the IDEAS perspective, this is well-established. A state of X is a temporal slice of X. For example, a door is opened and then closed. While it is open, the door is in a ‘door open’ state – this is a temporal slice of the whole four-dimensional extent of the door – as shown diagrammatically below. space time Door No 73 Door Open State #01 Figure 9 - A door open state space-time map This slicing works much in the same way one would take a slice out of the middle of a long sausage. The object is sliced at its start boundary and end boundary – and everything in between is in the temporal slice. The limiting case is where one takes a slice off the beginning or the end – then only one real slice is needed, the other being notional. Not every temporal part is a temporal slice. A simple example would be the fusion of two separates temporal slices. For example, as shown in Figure 10, a fusion of a door open and a door locked temporal slice is not itself a temporal slice. There are two indicators of this; firstly, one cannot mark out the state with a slice at the start and another at the end boundary – it needs four slices. Secondly, there is a temporal slice in its middle (marked in the diagram) that is not part of it but is part of the door. When we look at the succession pattern, it will become clear why this can cause a problem. Figure 10 - Example of a non-slice temporal part The example in Figure 10 might lead one to think that the state (temporal slice) must be connected; in other words one can draw a line from any one part to any other part without leaving the state. But it turns out that this requirement is too strong, as there can be perfectly valid scattered temporal slices, so long as it inherits its scattering from the thing it is a slice of. To see this, consider the following example: Manchester United and Wimbledon play a football match in two halves, with a short interval. It seems reasonable to assume that the interval is not part of the match. Then the football match is scattered, as it has two temporally disconnected halves. (The halves are not connected as one cannot draw a line though space and time from one half to the other space time Door Open State #01 Door Locked State #03 Fusion of Open and Locked Door States A Temporal Slice -- 13 of 69 -- 14 without leaving the extension of the football match – just as one cannot draw such a line on the space-time map in Figure 11.) Assume that Manchester United played well for part of the match; that they started playing well after about 10 minutes from the start and stopped playing well about 15 minutes before the end. This gives us a ‘Manchester United playing well’ state of a football match, shown in Figure 11. It is a temporal slice of the football match, with a clear start and end slice but it, like the football match, is scattered – that is, it is not connected. However, because the slice inherits the scattering from the football match, it does not introduce a gap in the slice relative to the whole being sliced. So states can be scattered, so long as they inherit the scattering from the whole of which they are a state. Figure 11 - A scattered state of a scattered football match A real world state succession However, central to the operations of a UML State Machine are the transitions between a set of (UML) states. From a state perspective, this is what we call a state succession. Consider a case where a door is opened, closed and then locked. There is a clear succession (transition) from a door open to a door closed and then to a door locked state – as shown below as a space-time map. space time Door Open State #01 Door Closed State #02 Door Locked State #03 Figure 12 - Open-Closed-Locked Space-Time Map One can see in the space-time map that the states form a chain or line with an initial state followed by a number of state successions (or transitions) and then a final state. (Arrows in the space-time map mark the initial and final states in the space-time map.) The states do not have to immediately succeed one into the other, as in Figure 12. If we consider just the open and locked states, we get a succession that happens after a period of time – see Figure 13. This is valid and it is often useful to have different views. space time Manchester United playing well Football Match #4 first half second half -- 14 of 69 -- 15 space time Door Open State #01 Door Locked State #03 Figure 13 - Open-Locked Space-Time Map Non-causal successions As these examples show, the succession relation is not causal. The first half of a football match does not cause the second half. Nevertheless there is a dependency between the successions, it is logically impossible for there to be a second half of a football match without there being a first half – it is necessary that there is a first half before there can be a second half. Set of Successions Relative to Set of States The last two examples also illustrate the requirement (constraint) that the relevant successions are determined by the collections of states under consideration. So in Figure 13, which excludes the Door Closed State, the succession from Door Open #01 to Door Locked #03 is included. But in Figure 12, which includes the Door Closed State it is not. This shows how being a succession is relative to a set of states. Within that set of states, the succession picks out the next state in the collection – and which state is next depends upon which states are in the collection. This requirement excludes the succession from Door Open #01 to Door Locked #03 (shown in Figure 13) as it does not pick out the next state in the collection – even though both states at the ends of the succession are in the collection. Also, a succession can be associated with more than one set of states – the succession from Door Open #01 to Door Closed #02 is a succession in Figure 13 and Figure 14. space time Door Open State #01 Door Closed State #02 Figure 14 - Open-Closed Space-Time Map This also shows that states and succession can be in many state succession views – something UML does not cater for. Disjoint Set of States Requirement Furthermore, not just any collection of states will have this pattern – the collection of states must be disjoint – in others words, they must not overlap. Otherwise, the successions will not ‘work’ because the end of one state is before the beginning of the next state. For example, a door can be both open and alarmed – in other words, the ‘door open state’ and the ‘door alarmed state’ can overlap as shown in the space-time map in Figure 15. The -- 15 of 69 -- 16 door alarmed state cannot succeed the door open state – as it has started before the door open state has ended. Hence the collection {Door Open State #01, Door Alarmed State #11} is not an example of the state succession pattern. space time Door Open State #01 Door Alarmed State #11 Figure 15 - Overlapping states One can begin to see the reason why scattered temporal parts cannot be states (scattered relative to the things they are states of). If you look at the example in Figure 10 again, then the fusion of the door open with the door locked temporal slice, and the other temporal slice, are disjoint – but there is no way one can succeed the other, as they interleave each other. So both a non-relatively scattered state and disjointness are required to enable succession. Real World Semantics for a ‘State Type Successions’ pattern We have grounded this state succession pattern at the individual level for an individual door; we now need to take it up a level for doors in general. In the next stage we consider the state successions pattern in general, not just for doors. For this first step, we generalise to door state types rather than individual door states. Consider doors in general and their open, closed and locked states. We can describe a pattern of successions between these states in a grid – shown in Figure 16.       OPEN DOOR CLOSE DOOR LOCKED DOOR OPEN DOOR CLOSE DOOR LOCKED DOOR NEXT STATE PREVIOUS STATE initial OPEN-CLOSED-LOCKED DOOR STATES SUCCESSION GRID final Figure 16 - Example succession grid The new feature at this level is the state types – we have divided the individual states into types. And we have three types of states of this thing (doors), whose instances are temporal stages of doors. However, for the successions to ‘work’, there are some additional constraints that need to be satisfied. Instance-wise Disjoint Union of Set of States Requirement At the grounding level, we have the constraint that the states of the whole must be disjoint. This translates into a requirement that the union of the three state sub-types (so the union -- 16 of 69 -- 17 of open, closed and locked states) are disjoint relative to their whole. It turns out that a requirement that state sub-types are just altogether disjoint is too strong. To see this consider this example. We have a prison door and it has a cell viewing door built into it (see Figure 17 below). Clearly the cell viewing door is an integral part of the prison door and both doors can be open and closed independently. Prison Door Cell Viewing Door Figure 17 - An example of a door within a door It is likely that the viewing door will be open when the prison door itself is open, closed or locked. This is shown diagrammatically Figure 18 for the case where the door is open and then closed. This means from a spatio-temporal perspective that the collection of all the door open-closed-locked states (their spatio-temporal extents) overlap, that they are not disjoint. Door Open State #01 Door Closed State #02 Prison Door Cell Viewing Door Door Open State #33 time space Figure 18 – (Non-Instance-wise) Door Overlapping States If we made it a requirement that the states were disjoint, we would exclude cases where there is a clear state succession pattern. Instead, we work with the weaker requirement that for each door instance all its states in the collection must be disjoint. This requirement must be met to enable the successions to work. So, in this example, when we consider the prison door (as the ‘owner’ of the collection of its temporal stages), the cell viewing door states are not considered as they are not states of the prison door. So cases such as the prison door state succession patterns are included. -- 17 of 69 -- 18 This kind of constraint can be difficult to spot as there is a natural assumption that all instances of everyday types (such as doors) are disjoint. However, a little reflection can soon provide one with many counter-examples. Disjoint Set of State Types We need to add one further constraint. Consider a case where we have chosen the two state types: Open Door and Unlocked Door (where this is the union of the Open Door and Closed Door states). This does not violate the ‘instance-wise disjoint union of set of states’ requirement described above as at the individual level, the union of the state sub-types are instance-wise disjoint. However, it does not exhibit the state succession pattern – it does not make sense to talk of an Open Door state transitioning into an Unlocked Door state as it is already in an Unlocked State. The underlying reason is that at the state type level, the state types are not disjoint, they share members – as shown in Figure 19. space time Door Open State #01 Door Closed State #02 Door Unlocked States Door Open States Figure 19 – Non-instance-wise Disjoint Types Space-Time Map This is easy to see in the Venn diagram format in Figure 20. Door Open State #01 Door Closed State #02 Door Open States Door Unlocked States Figure 20 - Non-instance-wise Disjoint Types Venn Diagram This shows the need for an additional constraint; that the state types chosen must be disjoint – they must have no members in common. It also clearly illustrates that the constraint is a property of the collection of states, rather than the individual states. Real World Semantics for the general ‘DisjointStateTypesSets’ pattern The door’s ‘state type succession’ pattern is one example of the general ‘DisjointStateTypesSets’ pattern. In general, something is a ‘DisjointStateTypesSets’ if: 1. It contains a disjoint set of types 2. The union of these types are all temporal stages of some sub-type of ‘Individual’ (an Individual sub-type) and 3. These temporal stages are instance-wise disjoint relative to the sub-type. -- 18 of 69 -- 19 Individual sub-type’s hierarchy of ‘DisjointStateTypesSets’ There is no constraint on how many ‘DisjointStateTypesSets’ an Individual sub-type can have, provided they meet the criteria for ‘DisjointStateTypesSets’. An Individual sub-type will typically have a hierarchy of ‘DisjointStateTypesSets’. We can use the door example to illustrate this. The example contains the set {Door Open, Door Closed, Door Locked}. Consider the sub-sets of this:  {Door Open, Door Closed},  {Door Open, Door Locked},  {Door Closed, Door Locked},  {Door Open},  {Door Closed}, and  {Door Locked}. Each of these is a ‘DisjointStateTypesSets’ in its own right – these are shown in the Venn diagram in Figure 21. From a pragmatic perspective, there may be situations where it is useful to filter out the states an audience is not interested in. This provides the structure to select for each audience the view that contains what they are interested in. Taxonomic Hierarchy Venn diagram Door Open or Closed or Locked Door Closed or Locked Door Closed or Locked Door Open Door Closed Door Locked Door Open or Closed Door Open or Closed Door Open or Locked Door Open or Locked Door Open or Closed or Locked Door Closed or Locked Door Closed or Locked Door Open Door Closed Door Locked Door Open or Closed Door Open or Closed Door Open or Locked Door Open or Locked Figure 21 – Example hierarchy of ‘DisjointStateTypesSets’ Multiple ‘orthogonal ‘DisjointStateTypesSets’ pattern In the example above, the hierarchy of ‘DisjointStateTypesSets’ shared members. It is common to include multiple orthogonal sets – orthogonal2 in the sense that they do not share members (though they may share instances of their members). As noted earlier, the selected worked example (see Figure 8) contains an instance of multiple ‘orthogonal’ sets: AlarmedDoorStateTypeSet and OpenCloseLockDoorStateTypeSet. 2 ‘Orthogonal’ is defined on p. 563 of the UML Specification in relation to regions as ‘Description. A region is an orthogonal part of either a composite state or a state machine. It contains states and transitions.’ Though some formal structure is defined elsewhere, there is no further description of the real world semantics for this. -- 19 of 69 -- 20 As this case illustrates, the union of the two sets may not be a ‘DisjointStateTypesSets’ - Figure 15 shows a Door Open state can overlap a Door Alarmed state. Hence, the behaviour of an individual can be characterised by a number of different state machines. Picking on set of state types does not exclude the overlapping states from being participants in another state succession pattern. Nested ‘DisjointStateTypesSets’ pattern Given that any individual sub-type can have ‘DisjointStateTypesSets’, it follows that the state types in one set can be the owner of its own ‘DisjointStateTypesSets’. This is a common behavioural pattern. The worked example provides an instance of this. The AlarmedDoorStateTypeSet owns the Alarmed Door Level One - Level Two State Type Set as shown in state machine diagram format in Figure 8. The multiple orthogonal ‘DisjointStateTypesSets’ and nested ‘DisjointStateTypesSets’ patterns are examples of structures that are inherited from UML to MODEM. Inheriting the ‘State Successions’ pattern As noted at the beginning of this section, different nations may decide to model their state machines at different levels of generalisation. When combined these lead to a requirement for inheritance of the state successions pattern. The requirement can exists with a MODAF model, where the state type succession in an OV6b is sometimes specialised in a SV10b, adding or removing structure. The analysis clarified that this specialisation is a super-sub- type relation between the state types – and shows how additional structure can be added. This is illustrated with this simple extension to the earlier door example. Consider ‘Fridge Doors’, a sub-type of ‘Doors’ – and assume, as is often the case, that they cannot be locked – in other words, there is no Fridge Door Locked state. Clearly Fridge Doors and the set {Fridge Door Open, Fridge Door Closed} are just a specialisation (in some sense) of the earlier example and exhibit the state type succession pattern – as shown in Figure 22. This is an example of the inheritance pattern in Figure 5. Taxonomic Hierarchy Venn diagram Door Open or Closed or Locked Door Open Door Closed Door Locked Fridge Door Open or Closed Fridge Door Open or Closed Fridge Door Open Fridge Door Open Fridge Door Closed Fridge Door Closed Door Open or Closed or Locked Fridge Door Open or Closed Fridge Door Open or Closed Door Open Door Closed Door Locked Fridge Door Open Fridge Door Open Fridge Door Closed Fridge Door Closed Figure 22 – Example inherited states Interaction Diagrams – real world analysis This section focuses on the real world semantics for interaction diagrams. -- 20 of 69 -- 21 Chosen Example The chosen interaction diagram example (Figure 23) looks at the role of people in an ‘Eat Restaurant Meal’ interaction. This Interaction diagram takes a particular view of the interaction through its choice of participants. One could easily take other views of this interaction by choosing different participants. For example, one could have a cutlery and crockery view or a food and wine view or a money view of this example interaction. Bob/Waiter takes food and wine order order food Fred/ Patron served wine Hank/ Cook cooks food serve wine Bob/ Waiter serves wine order food and wine Fred/ Patron orders food Fred/ Patron eats meal pickup serve food Renee/ Cashier takes payment Person (Fred:) Patron: Person (Bob:) Waiter: Person (Hank:) Cook: Person (Renee:) Cashier:Person pay Bob/ Waiter serves food Figure 23 - Chosen Interaction Diagram Example Two Key Aspects There are two key aspects of an interaction diagram. Firstly, the interaction has as components a number of participations by other Individuals (called in MODEM ‘Interaction Roles’ and in UML ‘lifelines’). Secondly, there are temporal ordering inter-dependencies between components of the interaction. These aspects can be seen in the chosen example. The participation aspect Figure 24 is a space-time map that shows the first aspect – the whole-part relationship between the individual interaction role participations and the overall interaction - for example, the ‘Fred: Patron’ interaction role is the participation by Fred in ‘Fred Eat Restaurant Meal’. -- 21 of 69 -- 22 space time Renee Fred : Patron Hank Bob Fred Bob : Waiter Hank : Cook Renee : Cashier Fred Eat Restaurant Meal Figure 24 - Component participation space-time map Figure 25 abstracts the same structure from the interaction diagram – though this is at a higher type level – working at the level of Patron (IndividualType) rather than Fred (Individual). Person (Fred:) Patron: Person (Bob:) Waiter: Person (Hank:) Cook: Person (Renee:) Cashier:Person Figure 25 - UML Notation for lifeline participations The temporal ordering aspect The second aspect can be seen in Figure 26, which abstracts the temporal orderings from the Interaction diagram. This produces a directed graph in which the interaction components are nodes and dependencies are arrows. As the figure shows there is a close inter-connection between the two aspects; the component nodes are not just components of the interaction, but also components of the participations. This also provides the basis for partitioning the temporal ordering relations into those within and those between the interaction role participations – shown in different colours in the figure. -- 22 of 69 -- 23 Person order food serve wine order food and wine pickup serve food (Fred:) Patron: Person (Bob:) Waiter: Person (Hank:) Cook: Person (Renee:) Cashier:Person pay Figure 26 - Interaction component dependencies UML makes the same distinction. The dependencies across the interaction roles (lifelines) as ‘Messages’, whereas the dependencies within the roles (lifelines) are based upon a ‘GeneralOrderings’. Non-circularity constraint An essential feature of temporal orderings is that they are not circular. One cannot follow a string of temporal orderings and return to where one started. Figure 27 illustrates a circular ordering within an interaction diagram. If one starts at ‘1’ then follows the orderings ‘2’, ‘3’ and ‘4’ one then returns to ‘1’. A telltale clue here is that the lines in the diagram cross. X Y 1 2 4 3 X Y ` Figure 27 - Circular temporal dependencies -- 23 of 69 -- 24 Temporal Ordering within an Interaction Role The ordering within the roles (lifelines) arises from patterns within the lifelines that are not shown in Figure 26. Figure 28 shows the finer detail. In UML, each lifeline (Interaction Role) has two-levels of components, with interaction dependency components at the second level. Bob/Waiter takes food and wine order Fred/ Patron served wine Hank/ Cook cooks food Bob/ Waiter serves wine Fred/ Patron orders food Fred/ Patron eats meal Renee/ Cashier takes payment Person (Fred:) Patron: Person (Bob:) Waiter: Person (Hank:) Cook: Person (Renee:) Cashier:Person Bob/ Waiter serves food Figure 28 - Interaction Roles and their components These components exhibit the same state succession pattern that underlies state machines. The components at the first level (‘ExecutionSpecifications’ in UML-speak) divide the lifeline into sets of disjoint state types. For example, Figure 29 shows the Waiter role/lifeline’s three components as disjoint successions – firstly as an abstraction from an interaction diagram and then as a space-time map. Bob/Waiter takes food and wine order Bob/ Waiter serves wine Person (Bob:) Waiter: Person Bob/ Waiter serves food space time Bob/Waiter takes food and wine order Bob/Waiter serves wine Bob/Waiter serves food Figure 29 - Lifeline components as disjoint state types -- 24 of 69 -- 25 This, in effect, means the lifelife in a UML Interaction diagram is a State Machine. This point can be made explicit notationally by using the UML State Machine notation to represent the lifeline – this alternative notation is shown in Figure 30. Fred/ Patron served wine Fred/ Patron orders food Fred/ Patron eats meal Person (Fred:) Patron: Person Person (Fred:) Patron: Person Interaction diagram notation Patron State Machine Fred/ Patron orders food Fred/ Patron served wine Fred/ Patron eats meal Interaction AND State Machine Diagram notation Figure 30 - Combined Interaction and State Machine UML Notation However, not any state succession is allowed in an Interaction. In the general pattern, there can be orthogonal regions – but not in an interaction diagram. Furthermore, in the general pattern a state type can be succeeded by more than one other type. For instance, in the door example, the door closed could be succeeded by either a door open state or a door locked state. In the interaction diagrams state succession, one state type is always followed by another state type – there is no variety. This leads to a linear chain of state types – and so a linear chain of states in the instances. Temporal Ordering across Interaction Roles In UML, ExecutionSpecifications can contain a second level of events, OccurrenceSpecifications. Where these are MessageOccurrenceSpecifications, they are the send or receive end of a message. Figure 31 provides an example; the yellow MessageOccurrenceSpecification is a send message end and the red MessageOccurrenceSpecification is a receive message end. -- 25 of 69 -- 26 Fred/ Patron served wine serve wine Bob/ Waiter serves wine (Fred:) Patron: Person (Bob:) Waiter: Person Figure 31 - An Example 'Message' From a real world semantic perspective, these are a different kind of ordering from the state successions within the interaction role. Earlier we noted that state successions are not causal; the first half of the football match does not cause the second half. Similarly, the waiter serving the wine does not cause the waiter to serve the food. However, the temporal ordering of the send and receive messages is causal. The sending – the waiter serving the wine – causes the receiving – the patron served the wine. In the MODEM model these are called state interactions. Strong and weak temporal orderings This semantic difference between state interactions and successions leads to a structural difference. If one looks closely at the example, one can see that the waiter serving the wine must start before the patron receiving the wine – a cause cannot start before its effect. However, in this and other cases, it is likely that the patron starts receiving the wine before the waiter has finished serving it. Similarly, the waiter serving the wine must finish before the patron receiving the wine finishes. This is shown graphically in Figure 32. Patron space time Waiter Waiter serves wine Patron receives wine Figure 32 - start-end temporal ordering This kind of temporal ordering is weaker than the strong total temporal ordering of state successions. As noted earlier, one state must end before the next state can start. Unnecessary UML Layering The UML Specification makes a clear and absolute distinction between the two layers in an interaction role (lifeline). The lifeline is divided into ExecutionSpecifications and these are divided into OccurenceSpecifications. The state interaction orderings hang off the -- 26 of 69 -- 27 OccurenceSpecifications. This levelling is superfluous structure. There is no reason why any leaf state should not be a send/receive node. This can be seen clearly in the example. In Figure 33, the two cases (highlighted) where an ExecutionSpecification contains a single Message OccurenceSpecification, the OccurenceSpecification has been removed and the send/receive link transferred to the ExecutionSpecification. Figure 33 - Removing unnecessary levelling This makes things clearer. It conveys the same information, and does this with fewer objects. It is also a more faithful representation of what happens. From real world semantics perspective, there seems to be no appreciable difference between the ExecutionSpecification and OccurenceSpecification. They seem to have been introduced merely to fit in with the UML rules. There is no reason to import this constraint into MODEM. Taking advantage of the embedded state machine pattern As noted earlier, the analysis shows that the UML Interaction diagram uses a version of the state succession pattern – though this connection is not recognised in any way in the UML specification, where State Machines and Interaction diagrams are treated separately – effectively stove piping them. The version used is quite restricted. This raises the question of why these restrictions are in place and whether they are real. One of the restrictions is that the interaction lifeline state machines do not cater for orthogonal regions. We can illustrate what one might look like using the chosen example – shown again in Figure 34. Bob/Waiter takes food and wine order order food Fred/ Patron served wine Hank/ Cook cooks food serve wine Bob/ Waiter serves wine order food and wine Fred/ Patron orders food Fred/ Patron eats meal pickup serve food Renee/ Cashier takes payment Person (Fred:) Patron: Person (Bob:) Waiter: Person (Hank:) Cook: Person (Renee:) Cashier:Person pay Bob/ Waiter serves food -- 27 of 69 -- 28 Figure 34 - UML restricted ordering Let’s relax the dependency between the waiter passing the food order to the cook and the waiter serving the wine by introducing a waiter handles food and wine order process which has the waiter passing the food order to the cook and the waiter serving the wine as states in separate regions. The result is shown in Figure 35. Bob/Waiter handles food and wine order order food Fred/ Patron served wine Hank/ Cook cooks food serve wine Bob/ Waiter serves wine order food and wine Fred/ Patron orders food Fred/ Patron eats meal pickup serve food Renee/ Cashier takes payment Person (Fred:) Patron: Person (Bob:) Waiter: Person (Hank:) Cook: Person (Renee:) Cashier:Person pay Bob/ Waiter serves food Bob/ Waiter hands over food order Figure 35 - Interaction diagram with multiple regions Figure 36 shows the temporal ordering abstracted from the interaction example, with the changes marked in red. Bob/Waiter takes food and wine order order food Fred/ Patron served wine Hank/ Cook cooks food serve wine Bob/ Waiter serves wine order food and wine Fred/ Patron orders food Fred/ Patron eats meal pickup serve food Renee/ Cashier takes payment Person (Fred:) Patron: Person (Bob:) Waiter: Person (Hank:) Cook: Person (Renee:) Cashier:Person pay Bob/ Waiter serves food Person order food serve wine order food and wine pickup serve food (Fred:) Patron: Person (Bob:) Waiter: Person (Hank:) Cook: Person (Renee:) Cashier:Person pay -- 28 of 69 -- 29 order food serve wine order food and wine pickup serve food Person (Fred:) Patron: Person (Bob:) Waiter: Person (Hank:) Cook: Person (Renee:) Cashier:Person pay Figure 36 - Multiple region temporal ordering What this illustrates is that recognising the underlying state succession pattern in the interaction diagram enables new functionality to be added at no extra cost. Summary The analysis has identified the real world semantics behind the UML structures creating the basis for a common understanding. The UML structure is divided into rigid siloes. The real world analysis has shown that these silos are not a reflection of the underlying enterprise. These constraints in original structure need not be migrated to MODEM – making it more flexible. The real world semantics makes the underlying business patterns clearer – and so makes the identification of common patterns simpler. A salient example of this is the appearance of the state machine’s state succession pattern at the centre of the Interactions. The use of these common patterns makes the model simpler and easier to understand. -- 29 of 69 -- 30 IDEAS Detailed Technical Analysis Introduction This is the third section of the report, which presents the detailed analysis. This translates the points raised in the second section into IDEAS diagrams. Some of these diagrams contain a large amount of information. They are included in the report but may be better viewed in the Worked Examples HTML report. This section is divided into two parts, one dealing with the state succession pattern, the other dealing with the interaction pattern. State Type Succession pattern –real world analysis The analysis starts by giving some context by looking at what UML State Machines are. UML State Machines UML State Machines are based upon Harel StateCharts with some additions. The original Harel State Machine focused on the formal structure and relied on an implicit, intuitive real world semantics. The UML State Machines developed the formal structure to meet additional requirements, such as hierarchical state machines and orthogonal regions. Their focus seems to have been more on providing an executable formal structure than developing the real world semantics. One result of this is that the current formal structure of the UML specification for state machines does not map easily onto a real world semantics. However, careful analysis using the (BORO-based) IDEAS Foundation has recovered the underlying intentions and reconstructed a formal structure with a clear real world semantics. UML State Machines specification The UML Superstructure specification contains the specification of state machines (and associated apparatus: regions, transitions and states). A StateMachine contains Regions, which in turn contain Transitions, which in turn link States, which are a sub-type of Vertices (see Figure 37). -- 30 of 69 -- 31 Figure 37 – “Figure 15.2 - State Machines” (UML Superstructure Specification, v2.3) The specification’s diagram is a bit too busy for easy reading, so Figure 38 abstracts this down to the key elements – and adds two missing key elements: StateMachine’s super-type Behaviour and its association with BehaviouredClassifier. -- 31 of 69 -- 32 Figure 38 - UML State Machines The analysis below shows that in some cases this structure obscures the real world semantics, so reconstruction is required to reveal the real world semantics. Clarifying terminology While the types of objects used in UML State Machines are similar to the types that are identified in our analysis, they are different in significant ways. This raises the question of what terms to use for the objects found for our analysis. The benefit in using the same term is that its meaning is already known. The problem is that this known meaning will only roughly correspond to the meaning of the object in the analysis, and so potentially mislead. The benefit of using a new term is that it clearly marks that a different sense is intended, but at the cost of not inheriting an already known sense. These costs and benefits have been traded off to arrive at what we hope is a pragmatic decision on the use of terms. So, it seems sensible to use the term ‘state’ as this is the everyday language term, but in the analysis we use it in the everyday sense (UML uses it for what roughly corresponds to our types of states). However, in other cases, we have used different terms – for example, we use succession for what roughly corresponds to instances of UML transitions. There is a detailed mapping of the terms at the end of the analysis. The chosen example in IDEAS The chosen example was a case where a door is opened, closed and then locked – as shown in the earlier state machine in Figure 8 and the space-time map in Figure 12. There is a clear succession (transition) from a door open to a door closed and then to a door locked state. class 15.3.12 StateMachine StateMachine Region Behavior Transition BehavioredClassifier Vertex State +target 1 +incoming 0..* +state 0..1 +region 0..* +stateMachine 0..1 +region 1..* +submachine 0..1 +submachineState 0..* +source 1 +outgoing 0..* +transition 0..* +container 1 +subvertex 0..* +container 0..1 +context 0..1 -- 32 of 69 -- 33 This is captured in the following two IDEAS diagrams. Figure 39 shows in IDEAS format the states as temporal parts of ‘No 73’s Door’. Figure 40 shows the successions. Figure 39 - States as temporal parts of No 73’s Door Figure 40 – No 73’s Door successions One can see both in the earlier space-time map and the IDEAS succession diagram that the states form a chain or line with an initial state followed by a number of state successions (or transitions) and then a final state. IDEAS ‘State Type Successions’ pattern This shows the state succession pattern grounded at the individual level for an individual door. We then take it up a level for doors in general. In the earlier analysis, we showed the pattern in the grid in Figure 16 – and reproduced in Figure 41. class 10 - No73's Door Open-Close-Lock States «IDEAS:Indi... Doors «IDEAS:Indi... No73'sDoor «IDEAS:TupleType» doorTemporalOpenCloseLockStates «IDEAS:IndividualType» DoorOpenCloseLockedStates «IDEAS:Indi... {No73'sDoor} «IDEAS:Individu... No73InitialOpenState «IDEAS:Individu... No73FirstClosedState «IDEAS:Indi... No73LockedState «IDEAS:TupleType» no73'sDoorOpenCloseLockStatePartitionOfTemporalStageOfs «IDEAS:IndividualType» No73'sDoorOpenCloseLockStates «IDEAS:Type» DoorInstancesDisj ointOpenCloseLockStateTypes t0311 «IDEAS:Type» SetOfDisj ointIndiv iduals t0314 t0313 «IDEAS:typeInstance» doors «place1Type» openCloseLockStates «place2Type» «IDEAS:superSubtype» «IDEAS:typeInstance» «IDEAS:typeInstance» «IDEAS:typeInstance» «IDEAS:typeInstance» «place1Type» «IDEAS:superSubtype» «place2Type» «IDEAS:typeInstance» «tuplePlace1» 1 «tuplePlace2» 1 «tuplePlace1» 1 «IDEAS:superSubtype» «tuplePlace2» «tuplePlace1» «IDEAS:typeInstance» «tuplePlace2» «tuplePlace1» «tuplePlace2» «IDEAS:typeInstance» «tuplePlace1» «tuplePlace2» 1 class 22 - Open, Close, Lock «IDEAS:Indi... DoorOpen «IDEAS:Indi... DoorClosed «IDEAS:Indi... DoorLocked «IDEAS:TupleType» openToCloseStateSuccessions «IDEAS:TupleType» closeToLockedStateSuccessions «IDEAS:Individu... No73InitialOpenState «IDEAS:Individu... No73FirstClosedState «IDEAS:Indi... No73LockedState t039 t038 «IDEAS:typeInstance» «IDEAS:typeInstance» previous «place1Type» next «place2Type» 0..1 next «place2Type»1 «IDEAS:typeInstance» «IDEAS:typeInstance» «tuplePlace2» «tuplePlace1» «IDEAS:typeInstance» «tuplePlace1» «tuplePlace2» 0..1 previous «place1Type» 1 -- 33 of 69 -- 34 This grid tells us which types of succession are possible and which aren’t. For example, if the door is open, it can only be closed, it cannot be locked – a Door Open, if it is succeeded, must always be succeeded by a Door Closed state, it cannot be succeeded by a Door Locked state. One can easily see this in the matrix, as the the Previous State – Open Door row (c