MODEM - Behaviour ONTOBRAS-2013 The industrial application of ontology: Driven by a foundational ontology A structural constraints case study

© 2013 BORO Solutions Topics Theme recapitulation Project background UML state machines Providing a real world semantics Deploying the state pattern Summary Questions

Theme recapitulation

© 2013 BORO Solutions Theme Recapitulation Increased precision Remove constraints

Project background The UML problem Building in a real world semantics (ontology) UML behaviour

© 2013 BORO Solutions MODEM sponsors MODEM (MODAF Ontological Data Exchange Model) is the result of a Swedish led effort within IDEAS aiming for an evolution of M3 by exploiting the IDEAS foundation. The Swedish Armed Forces Joint CIO - Capt (N) Peter Haglind is the Swedish Armed Forces government sponsor for MODEM. Lt Col Mikael Hagenbo is the Swedish Armed Forces IDEAS sponsor The requirement is practical applicability in terms of a stable product that can act as a means of standardization between UML tool vendors and non-UML tool vendors for defence EA purpose. Defence EA needs to be standardized so that data exchange in a semantic coherent way can be achieved regardless of repository or tooling environment. MODEM should be recognized as the current standard semantic foundation and the quality assured baseline for the future development towards defence EA framework convergence.

© 2013 BORO Solutions Summary UML was not designed to provide a real world semantics It has a formal semantics MODAF started to establish middle level real world semantics, within UMLs top level formal semantics Had to fit within the UML constraints MODAF as it currently stands has no top level real world semantics MODEM uses IDEAS (BORO) to bring these semantics in.

© 2013 BORO Solutions The UML problem Problem is that the UML top level is not designed for real world semantics

© 2013 BORO Solutions Building in a real world semantics (ontology) The real problem in speech is not precise language. The problem is clear language. Richard Feynmann Formal Semantics Real World UML IDEAS And if the language doesnt provide a clear picture of the real world, how do people and machines know what is being talked about.

© 2013 BORO Solutions UML behaviour Focus here on UML Behaviour

© 2013 BORO Solutions Report For full details see report: MODEM MODAF Migration: Providing an ontological foundation Available at: Behaviour%20Analysis%20Report%20-%20March% pdf/view?

UML state machines 12

© 2013 BORO Solutions Breaking down behaviour stovepipes Reflecting its history, a number of types of diagrams. Analysis focused on two main types; UML State Diagrams UML Interaction Diagrams Identified two core behaviour patterns that underlie the two types of UML diagrams: A pattern that deals with an objects 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. Here we focus on the unearthing of the first pattern: UML State Machines

© 2013 BORO Solutions UML state machines Have a very constrained structure. For example, cannot: Have a state inside more than one state machine Have one state machine inside another Subtype a state Why not? Can this happen in the real world (Yes!) Makes the formal structure easier (?)

© 2013 BORO Solutions Removing implementation structure Combining state machines State machine inside a state machine

© 2013 BORO Solutions Removing implementation structure Sub-typing state machines State machine subtypes another state machine State subtypes another state

© 2013 BORO Solutions Interoperability issue example - regions 17

Providing a real world semantics For UML state machines 18

© 2013 BORO Solutions Change over time - states Figure Protocol state machine (p UML Superstructure Specification, v2.3) A UML State Machine This is one way UML can be used to represent change over time a)There are other ways to do this b)This can be used to represent most algorithms (abstract state machines)

© 2013 BORO Solutions What is state in the real world? You can know the name of a bird in all the languages of the world, but when you're finished, you'll know absolutely nothing whatever about the bird... So let's look at the bird and see what it's doing that's what counts. I learned very early the difference between knowing the name of something and knowing something. Richard Feynmann

© 2013 BORO Solutions What is a real world state? From the BORO 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 in the (door open state) space-time map below. 21

© 2013 BORO Solutions Example: Non-slice temporal part Need to be careful as not every temporal part is a temporal slice. A simple example is the fusion of two separate temporal slices. Take, as shown below, a fusion of a door open and a door locked temporal slice This 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 (shown 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. We use the succession pattern as one test for a slice. 22

© 2013 BORO Solutions Example: A scattered state Intuitively, it seems like continuity is the criteria; but it is not quite that simple; continuity is not necessary. Consider this 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 without leaving the extension of the football match – just as one cannot draw such a line on the space-time map below.) 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 10. 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. 23

© 2013 BORO Solutions A real world state succession Central to the operations of a UML State Machine are the transitions between a set of (UML) states. From a BORO 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. 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.) 24

© 2013 BORO Solutions Open-Locked Space-Time Map Again, it may seem intuitively as if continuity is necessary (an essential feature); but again, it is not. The states do not have to immediately succeed one into the other. If we consider just the open and locked states, we get a succession that happens after a period of time This is valid and it is often useful to have views with states that do not necessarily cover the whole lifespan of the object. 25

© 2013 BORO Solutions Views of states; not different machines 26 One can pick the types of states that one is interested in; Door Open/Locked or Door Open/Closed. This gives different views (and different UML State Machines). It also gives different (sets of) successions

© 2013 BORO Solutions Disjoint set of states requirement To get the state machine behaviour one needs to be pick the right set of real world states. We have a good intuitive feel for this; which needs to be made explicit. One example: the states need to be necessarily disjoint; If a door can be alarmed, and it can be alarmed while it is open, then these two types of state cannot be in the same succession pattern 27

© 2013 BORO Solutions State succession grid A set of (types of) states that has a succession pattern can be organised into a grid. Here is the grid for doors and their open, closed and locked states. 28

© 2013 BORO Solutions Disjoint state of X States are states of something (ontological dependence) One can devise examples to illustrate this. The prison door states succeed one another So do the cell viewing door states But their states are not either spatially or temporally disjoint. Disjointness is relative to the state owner. 29

© 2013 BORO Solutions Disjoint set of state types There are more features we need to consider. Consider a case where we have two state types: Open Door and Unlocked Door (where this is the union of the Open Door and Closed Door states). The individual instances are disjoint. But, 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 30

Deploying the state pattern 31

© 2013 BORO Solutions Requirement: Combining state machines State machine inside a state machine Different views of the states

© 2013 BORO Solutions Requirement: Sub-typing state machines State machine subtypes another state machine State subtypes another state

Summary 34

© 2013 BORO Solutions Summary As these examples show There are inappropriate formal constraints lurking in many commonplace structures A top ontology based approach enables these constraints to be Identified, and Removed Practitioners know about the constraints and have developed workarounds But these lead to an increase in accidental complexity and reduced functionality A top ontology based approach provides a level of semantic quality assurance, reducing accidental complexity and increasing functionality 35

Questions 36