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
MODAF (UML) MetaModel
Current M3 Framework
UML Superstructure
UML Behaviour
extends
MODAF (UML) MetaModel Extension
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
RealWorld
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.
© 2013 BORO Solutions
UML behaviour
Useful patterns
Focus here on UML Behaviour
© 2013 BORO Solutions
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?
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 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
© 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 structureCombining state machines
Nation 1
State Machine CDoorOpen
DoorClosed
DoorLocked
Nation 2
State Machine DDoor
ClosedDoor
Locked
Coalition (Combined) View
State Machine C
State Machine D
DoorOpen
DoorClosed
DoorLocked
State machine inside a state machine
UML
MODEM
© 2013 BORO Solutions
Removing implementation structureSub-typing state machines
Nation 1
State Machine CDoorOpen
DoorClosed
DoorLocked
Nation 2
State Machine DFridgeDoorOpen
FridgeDoor
Closed
Coalition (Combined) View
State Machine C
State Machine D
DoorOpen
DoorClosed
DoorLocked
FridgeDoorOpen
FridgeDoor
Closed
UML
MODEM
State machine subtypes another
state machine
State subtypes another state
Providing a real world semantics
For UML state machines
18
© 2013 BORO Solutions
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 timea) There are other ways to do thisb) 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
spac
e
time
Door No 73
Door Open State#01
spac
e
time
Door Open State#01
Door Closed State#02
Door Locked State#03
© 2013 BORO Solutions 21
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.
spac
e
time
Door No 73
Door Open State#01
© 2013 BORO Solutions 22
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.
spac
e
time
Door Open State#01
Door Locked State#03
Fusion of Open and Locked Door States
A Temporal
Slice
© 2013 BORO Solutions 23
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.
spac
e
time
Manchester Unitedplaying well
FootballMatch #4
first half second half
© 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
spac
e
time
Door Open State#01
Door Closed State#02
Door Locked State#03
© 2013 BORO Solutions 25
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.
spac
e
time
Door Open State#01
Door Locked State#03
© 2013 BORO Solutions 26
Views of states; not different machinessp
ace
time
Door Open State#01
Door Closed State#02
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
spac
e
time
Door Open State#01
Door Locked State#03
© 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
spac
e
time
Door Open State#01
Door Alarmed State#11
© 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
OPEN DOOR CLOSE DOOR LOCKED DOOR
OPEN DOOR
CLOSE DOOR
LOCKED DOOR
NEXT STATEPREVIOUSSTATE
initial
OPEN-CLOSED-LOCKED DOOR STATES SUCCESSION GRID
final
© 2013 BORO Solutions
Prison Door
Cell Viewing Door
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
Door Open State#01
Door Closed State#02
Prison Door
Cell Viewing
Door
Door Open State#33
time
spac
e
© 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
spac
e
time
Door Open State#01
Door Closed State#02
Door Unlocked StatesDoor Open
States
Door Open State#01
Door Closed State#02
Door Open States
Door Unlocked States
Deploying the state pattern
31
© 2013 BORO Solutions
Requirement: Combining state machines
Nation 1
State Machine CDoorOpen
DoorClosed
DoorLocked
Nation 2
State Machine DDoor
ClosedDoor
Locked
Coalition (Combined) View
State Machine C
State Machine D
DoorOpen
DoorClosed
DoorLocked
State machine inside a state machine
Taxonomic HierarchyVenn diagram
Door Open or Closed or Locked
Door Closed or LockedDoor Closed or Locked
Door Open
Door Closed
Door Locked
Door Open or ClosedDoor Open or Closed
Door Open or LockedDoor Open or Locked
Door Open or Closed or Locked
Door Closed or LockedDoor Closed or Locked
Door Open Door Closed Door Locked
Door Open or ClosedDoor Open or Closed Door Open or LockedDoor Open or Locked
Different views of the states
© 2013 BORO Solutions
Requirement: Sub-typing state machines
Nation 1
State Machine CDoorOpen
DoorClosed
DoorLocked
Nation 2
State Machine DFridgeDoorOpen
FridgeDoor
Closed
Coalition (Combined) View
State Machine C
State Machine D
DoorOpen
DoorClosed
DoorLocked
FridgeDoorOpen
FridgeDoor
Closed
State machine subtypes another
state machineState subtypes another state
Taxonomic HierarchyVenn diagram
Door Open or Closed or Locked
Door Open Door Closed Door Locked
Fridge Door Open or ClosedFridge Door Open or Closed
FridgeDoor Open
FridgeDoor Open
FridgeDoor Closed
FridgeDoor Closed
Door Open or Closed or Locked
Fridge DoorOpen or Closed
Fridge DoorOpen or Closed
Door Open Door Closed Door Locked
Fridge Door OpenFridge Door Open Fridge Door ClosedFridge Door Closed
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