1 / 34

MODEM - Behaviour

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

jerzy
Download Presentation

MODEM - Behaviour

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Topics • Theme recapitulation • Project background • UML state machines • Providing a real world semantics • Deploying the state pattern • Summary • Questions

  3. Theme recapitulation

  4. Theme Recapitulation • Increased precision • Remove constraints

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

  6. 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 Hagenbois 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.

  7. The UML problem Problem is that the UML top level is not designed for real world semantics

  8. Building in a real world semantics (ontology) The real problem in speech is not precise language. The problem is clear language. Richard Feynmann Semantics IDEAS Real World UML Formal 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.

  9. UML behaviour Focus here on UML Behaviour

  10. 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?

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

  13. 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 (?)

  14. Removing implementation structureCombining state machines State machine inside a state machine

  15. Removing implementation structureSub-typing state machines State subtypes another state State machine subtypes another state machine

  16. Providing a real world semantics For UML state machines

  17. Change over time - states A UML State Machine Figure 15.12 - Protocol state machine” (p. 552 - 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)

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

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

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

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

  22. 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.)

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

  24. Views of states; not different machines • 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

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

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

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

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

  29. Deploying the state pattern

  30. Requirement: Combining state machines State machine inside a state machine Different views of the states

  31. Requirement: Sub-typing state machines State machine subtypes another state machine State subtypes another state

  32. Summary

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

  34. Questions

More Related