1. Lars-Olof Kihlström, Contractor Generic Systems Sweden AB
Status of MODEM
Lars-Olof Kihlström, Contractor Generic Systems Sweden AB

2. Contents MODEM phase 1 and phase 2 introduction
Summary of MODEM perceived advantages
Updated MODEM plan.
Status of the various MODAF viewgroups as MODEM artefacts.
Handling of UML
Work areas remaining to complete MODEM
Relationship between MODEM and UPDM
Deliverables at the end of phase 2

3. MODEM phase 1 and phase 2 introduction
During the late summer (August) 2010 and throughout the autumn of 2010, two phases of IDEAS foundation integration in MODAF has taken place resulting in a non-UML dependent meta-model labelled MODEM.
Phase 1 concentrated on elements within the views OV-2 and OV-5 and also the bridging and pattern constructs needed to go from the foundation to the MODAF based elements.
Phase 1 was originally intended to deal with OV-6b and c as well, something that turned out not to be possible since MODAF in these views handed over to standard UML as regards state charts and sequence diagrams, something that required a great deal more effort than contained in phase 1.
In addition to OV-2 and OV-5 parts of the StV views and some other OV views were also partly covered.

4. MODEM phase 1 and phase 2 introduction
In November 2010 phase 2 started which concentrated on dealing with the behaviour pattern within UML as well as the remaining StV view, the SOV view, the SV view and the AcV views elements.
Phase 2 is still being worked on and will be finalised during February but will at finalisation not cover all of MODAF. The phase was simply not large enough to deal with all of MODAF.
It is estimated that something between 60% of MODAF will be covered as the phase 2 is finished.
The deliverables expected to be made to the Swedish defence materials administration and the Swedish Armed Forces in February is described later in this presentation.

5. Summary of MODEM perceived advantages
MODEM provides a truly EA tool agnostic representation of MODAF, when all of MODAF is covered.
The semantic underpinning improves the MODAF concepts in a number of areas.
MODEM is grounded in real-world semantics and provides proper handling of individuals, something that MODAF never did.
The UML baggage which in many cases distort the meta-model is removed once MODEM is finished and in many views significant simplifications are achieved.
Common patterns that can be reused have been identified.
When complete, it answers the need of NATO to have a NAF model without UML dependencies.
When complete, it will provide a vehicle for discussions and development of a common enterprise architecture framework for defence (and even outside defence) since it will be based on the same concepts as DoDAF 2.
Properly used and supported MODEM can be used to increase the set of EA tool vendors that base their EA approach on a common meta-model.

6. Updated MODEM plan

7. Status of the various MODAF viewgroups as MODEM artefacts
AV: All Views
StV: Strategic Views
OV: Operational Views
SOV: Service Views
SV: System Views
TV: Technical Standards Views
AcV: Acquisition Views

10. AV: All Views Concern Stakeholder Architecture product View
Enterprise phase
Assigned property
Environment
Architecture description
Whole life enterprise
Has phases
Is part of
Is a speciali- zation of
Has an architecture
Contains
Exists in
Is treated in
Has
Actual organisational resource
Organisational resource

11. AV: All Views

12. StV: Strategic Views Can be a part of Is delivered to
Whole life enterprise
Measurable property
Environment
Has phases
Is part of
Is a speciali- zation of
Capability
Enterprise goal
Enterprise vision
Standard operational activity
Specifies
Supports
Is applicable to
Depends on/ Specializes/ Contains
Project
Capability configuration
Has subgoals
Is delivered to
Delivered by
Is const- rained by
Has
Actual organisational resource
Realizes
Exhibits
Enduring task
Uses
Can be
Is supported by
Can be a part of
Project milestone
Actual organisation
Enterprise phase

13. StV: Strategic Views

14. OV: Operational Views Node parent Operational activity
Standard operational activity
NodeType
Security domain
Logical architecture
Capability
Energy flow
Information element
Materiel flow
Movement of people
Information exchange
Needline
Energy
Logical flow
Organisational resource
Artefact
bundles
Problem domain
Node
Known resource
Can contain
Can con- tain
Type
Carries
Service
Can contain
Is of either Type
Resource Type
Sends/ receives
Sends/ receives
Contains
Can consume/ provide
Has
Trust line
Can describe
High level operating concept
Mission
Illustrates
Is of either Type
Interacts with

15. OV: Operational Views

16. SOV: Service Views Operational activity Standard operational activity
Node
Resource Type
Service level
Service policy
Service attribute
Service interface
Environment
Has interface
Implemented by
Can be instantiated as
Consumes/ Provided by
Can be described as built with
In environment
Achieves parts of
Supports
Supplies/ requires
Has property
Limited by
Capability
Service
Service implementation

17. SV: System Views Resource Type Operational activity
Standard operational activity
Service
Function
Artefact
Physical architecture
Software
Organisational resource
Post Type
Role Type
Organisation Type
Supports
Realizes
Performs
Contains
In order to perform
NodeType
Capability configuration
Service implementation
Achieves parts of
Needs
Consists of
Whole life configuration
Version of configuration
Type
Uses/ Supplies
Measurable Property
Resource interaction
Resource usage
Competence
Interacts with
Measured by
Qualitative Property
Capability

18. SV: System Views Resource Type Organisational resource Post Type
Role Type
Organisation Type
Post
Resource usage
Speciali- sations of
Part of
Physical asset
Sub Organisation
Role
Used Configuration
Platform
System
Human Resource
Hosted software
Part
Software Component
Part of/ Type
Part of
Type
Contains
Artefact
Physical architecture
Software
Capability configuration
Service implementation

19. SV: System Views Resource Type Artefact Physical architecture Software
Organisational resource
Post Type
Role Type
Organisation Type
Capability configuration
Service implementation
Contains
Interacts with
Resource Energy flow
Resource communication
Resource person flow
Resource material flow
Energy flow
Materiel flow
Movement of people
Information exchange
Energy
Data element
Commands
Controls
Interaction only possible between
Is specialised as
Realizes
Resource interaction

20. TV: Technical Standards Views
Entity
Attribute
Spectrum allocation
Capability configuration
Element
Implemented protocol
Protocol layer
Actual organisational resource
Standard configuration
Information element
Data element
Measurable property
Frequency range
Resource port
Protocol
Resource port connector
Is of type
Adheres to
Ratified by
Contains
Marks
Relates to
Defined by
Implements
Has been implemented in
Can run on

21. AcV: Acquisition Views
Capability
Project
Project milestone
Is of type
Capability increment
Out of service
Capability configuration
Configuration deployed
Configuration no longer used
Actual organisational resource
Project Type
Status
Date
Relates to
Has
Responsible for
Removed from
Delivered to
Realizes
Concerns
Starts/ finishes
Specializes
A Part of/ is after

22. AcV: Acquisition Views

23. Handling of UML
Why was this required?

24. UML Behaviour: State chart example

25. UML Behaviour: Sequence diagram (interaction) example

26. Handling of UML
As a result of performing the work regarding state charts as well as interactions it became clear that there was no real-world semantics behind the UML handling of these items, indeed neither for items that formed part of state charts and interaction constructs, nor for elements that were being referred by them
This can be stated succinctly by stating that UML is Broken – behaviour has three siloed diagram methods for behaviour
The MODEM model can help point the problems out as well as show a means to fix this as well as reduce complexity by reusing patterns.

27. Handling of UML: The handling of this is timely
Both tool vendors and other parties involved in OMG have started to detect this problem as evidenced by several papers that have been published fairly recently.

28. Excerpt from detailed part of MODEM deliverable report

29. Handling of UML
The work done as part of MODEM up to now has yielded a benefit that was essentially accidental, namely that the handling of state charts as well as interactions MODEM could be used directly to influence the future development of UML within OMG.
Comments have been requested from the members of the UPDM 2.0 Alpha 1 submission team in order to get thoughts and considerations from some UML vendors relating to the take on State charts and interactions within UML.

30. Work areas remaining in order to complete MODEM
There will be elements as well as relationships in all view groups that have not been covered once phase 2 is complete.
As can be seen by the previous figures, the TV view as well as portions of the AV view largely remains do be dealt with.
Detailed handling of protocol and connector issues as regatrds the system views need to be dealt with.
Cardinality issues need to be dealt with.
Detailed attribute and signal handling for services need to be dealt with.
Examples and tests need to be performed to a greater extent to ensure and verify the MODEM model.

31. Relationship between MODEM and UPDM
UPDM 1.0 covers MODAF and DoDAF 1.5
UPDM 2.0 will cover MODAF and DoDAF 2.02.
A UPDM version dealing with MODEM will presumably be UPDM 3.0 for which an OMG RFP will need to be written and responded to by interested parties (see Matthew Hause’s that discusses UPDM 3.0).
UPDM 3.0 could also be concerned with CUDEAM but this will depend on the speed with which this is produced.

32. Relationship between MODEM and UPDM: SAR

33. Deliverables at the end of phase 2
An explanatory text concerning MODEM
A report describing the technical detail of the model (comparable to the one created for phase 1)
An updated exemplification document containing both a description of a generic model structure as well as the use of MODEM to describe portions of the SAR model created for use in UPDM. This report will contain IDEAS examples and space-time maps
Reports concerning IDEAS foundation use to handle UML state charts as well as UML interactions
HTML model files of MODEM and examples.
Native Sparx files for MODEM and examples.