MODEM - Behaviour: A ‘structural constraints’ case study

Report
For full details see report:
MODEM MODAF Migration: Providing an ontological foundation
Available at: http://www.borosolutions.co.uk/research/content/files/SwAF-MODEM-Behaviour%20Analysis%20Report%20-%20March%202011.pdf/view?
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 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.
Here we focus on the unearthing of the first pattern:
UML State Machines
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 (?)
Removing implementation structure
Combining state machines

State machine inside a state machine
Removing implementation structure
Sub-typing state machines
State machine subtypes another state machine
State subtypes another state
Interoperability issue example - regions
17

Providing a real world semantics
For UML state machines
18
Change over time - states
Figure 15.12 - Protocol state machine" (p. 552 - UML Superstructure Specification, v2.3)
A UML State Machine
This is one way UML can be used to represent change over time
There are other ways to do this
This can be used to represent most algorithms (abstract state machines)
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


UML state machines

12
MODEM - Behaviour
ONTOBRAS-2013
The industrial application of ontology: Driven by a foundational ontology
A 'structural constraints' case study
Topics
Theme recapitulation
Project background
UML state machines
Providing a real world semantics
Deploying the state pattern
Summary
Questions

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 doesn't provide a clear picture of the real world,
how do people and machines know what is being talked about.
The UML problem

Problem is that the UML top level is not designed for real world semantics

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 UML's 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.
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.

Project background
The UML problem
Building in a real world semantics (ontology)
UML behaviour
Theme Recapitulation
Increased precision
Remove constraints
Theme recapitulation

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

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
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
UML behaviour
Focus here on UML Behaviour

Requirement: Sub-typing state machines
State machine subtypes another state machine
State subtypes another state
Summary

34
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
Deploying the state pattern

31
Requirement: Combining state machines

State machine inside a state machine
Different views of the states
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

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

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

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

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

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
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

Note: Fridges (in the UK) usually do not have locks.
33
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.
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.
29




Click to edit Master title style
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
#



© 2013 BORO Solutions

9

6






Click to edit Master title style
Click to edit Master subtitle style


3
Click to edit Master title style
#
Click to edit Master title style
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level

#






Click to edit Master title style
Click to edit Master subtitle style


Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level

#