1. Building a Real World Semantics for MODAF
Why MODAF needs a real world semantics

2. 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
IDEAS
UML
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.

3. Ontology and the real world
The question ontology asks can be stated in three words
‘What is there?’
and the answer in one
‘everything’.
Not only that, “everyone will accept this answer as true” though “there remains room for disagreement over cases.” (Quine “On What There Is”).
If you want a more technical definition
An ontology is
"the set of things whose existence is acknowledged by a particular … system." (E. J. Lowe, The Oxford Companion to Philosophy)
So an ontology tells you the things that exist in the real world.

4. One real world: how many (UML compliant) entities? I
This seems a reasonable entity
But so do these
And these
All these are UML compliant.

5. One real world: how many (UML compliant) entities? II
This seems a reasonable entity
but they can they exist in the same model, it looks like two different ways to model address
But so does this
What about this?
All these are UML compliant.

6. M3 starts to map the real world
Problem is that the UML top level is not designed for real world semantics

7. Top level real world semantics
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.

8. Build upon what already exists
There is a significant investment in MODAF
Harvest the relevant features
Winnow out the irrelevant technical features

9. Building a semantic foundation
implicit semantics
From a semantic perspective, it is like an iceberg, with visible ‘explicit semantic’ and hidden ‘implicit semantics’.
M3 was designed as a UML profile.
The goal is to:
Peel off the implementation structure, and
Make the implicit semantics explicit
semantic
foundation M3
UML Profile
implementation structure
explicit semantics
As a result it has both implementation structure and (explicit) semantics

10. Two examples Example 1 – SuperSubType
Example 2 – Change over time - states

11. Real world semantics – example 1: super-sub-type

12. Recovering the supersubtype semantic structure
MODEM
superSubType is not the same as UML Generalisation.

13. Example 2: Change over time - states
A UML State Machine
Figure Protocol state machine” (p UML Superstructure Specification, v2.3)
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)

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

15. UML States 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 (?)

16. Removing Implementation Structure Combining state machines
State machine inside a state machine

17. Removing Implementation Structure Sub-typing state machines
State subtypes another state
State machine subtypes another state machine

18. Building in a ‘clear’ real world semantics
IDEAS
Real
World
UML
Formal

19. More details concerning MODEM can be found at:
Analysis Report - March 2011.pdf