MODEM - Behaviour ONTOBRAS-2013 The industrial application of ontology: Driven by a foundational...

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


Theme Recapitulation

Increased precision

Remove constraints

Project background

The UML problem

Building in a real world semantics (ontology)

UML behaviour


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.


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


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.


UML behaviour

Useful patterns

Focus here on UML Behaviour


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


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


Removing implementation structureSub-typing state machines

Nation 1


DoorClosed

DoorLocked

Nation 2

State Machine DFridgeDoorOpen

FridgeDoor

Closed


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


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)


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


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


Fusion of Open and Locked Door States

A Temporal

Slice


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


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




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



Views of states; not different machinessp

ace

time

Door Open State#01


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



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


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


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


Prison Door

Cell Viewing

Door

Door Open State#33

time

spac

e


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 Unlocked StatesDoor Open

States

Door Open State#01


Door Open States

Door Unlocked States

Deploying the state pattern

31


Requirement: Combining state machines

Nation 1


DoorClosed

DoorLocked

Nation 2

State Machine DDoor

ClosedDoor

Locked


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


Requirement: Sub-typing state machines

Nation 1


DoorClosed

DoorLocked

Nation 2

State Machine DFridgeDoorOpen

FridgeDoor

Closed


State Machine C

State Machine D

DoorOpen

DoorClosed

DoorLocked

FridgeDoorOpen

FridgeDoor

Closed

State machine subtypes another

state machineState subtypes another state

Taxonomic HierarchyVenn diagram



Fridge Door Open or ClosedFridge Door Open or Closed

FridgeDoor Open

FridgeDoor Open

FridgeDoor Closed

FridgeDoor Closed


Fridge DoorOpen or Closed

Fridge DoorOpen or Closed


Fridge Door OpenFridge Door Open Fridge Door ClosedFridge Door Closed

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

MODEM - Behaviour ONTOBRAS-2013 The industrial application of ontology: Driven by a foundational...

Documents

Transcript of MODEM - Behaviour ONTOBRAS-2013 The industrial application of ontology: Driven by a foundational...