1 / 33

Status of MODEM

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

johniem
Télécharger la présentation

Status of MODEM

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. Status of MODEM Lars-Olof Kihlström, ContractorGeneric 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 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.

  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

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

  9. AV: All Views

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

  11. StV: Strategic Views

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

  13. OV: Operational Views

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

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

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

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

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

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

  20. AcV: Acquisition Views

  21. Handling of UML • Why was this required?

  22. UML Behaviour: State chart example

  23. UML Behaviour: Sequence diagram (interaction) example

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

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

  26. Excerpt from detailed part of MODEM deliverable report

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

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

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

  30. Relationship between MODEM and UPDM: SAR

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

More Related