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

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

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

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.

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.

Updated MODEM plan

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

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

AV: All Views

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

StV: Strategic Views

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

OV: Operational Views

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

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

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

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

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

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

AcV: Acquisition Views

Handling of UML Why was this required?

UML Behaviour: State chart example

UML Behaviour: Sequence diagram (interaction) example

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.

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.

Excerpt from detailed part of MODEM deliverable report

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.

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.

Relationship between MODEM and UPDM UPDM 1.0 covers MODAF 1.2.003 and DoDAF 1.5 UPDM 2.0 will cover MODAF 1.2.004 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 email 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.

Relationship between MODEM and UPDM: SAR

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.