DOCSLIB.ORG

This IBM Podcast. UPDM 2.0, a UML Sysml Implementation of Dodaf 2.0 and MODAF 1.2 for Military Architectures

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
This IBM Podcast. UPDM 2.0, a UML Sysml Implementation of Dodaf 2.0 and MODAF 1.2 for Military Architectures IBM Podcast [ MUSIC ] MATHENY: Welcome to this IBM podcast. UPDM 2.0, a UML SysML implementation of DoDAF 2.0 and MODAF 1.2 for military architectures. I'm Angelique Matheny with IBM. Over the past few years, system architects have often used UML and SysML to capture various architectural frameworks. Without guidance of a well-defined standard, many of these attempts have resulted in ad hoc and one-time solutions. The unified profile for DoDAF and MODAF UPDM specifies a standard for using UML SysML for capturing MODAF DoDAF views. This podcast will help you understand how UPDM helps enable national and international interoperability interchange and a complete lifecycle from enterprise architecture through software architecture. And joining today's discussion is Graham Bleakley, Rational Solution architect for Aerospace and Defense. And Brian Nolan, Market Manager for Aerospace and Defense Rational Systems Marketing. Hi, Graham; hi, Brian. Welcome to the podcast. Thanks for joining us today. BLEAKLEY: Thank you. -1- NOLAN: Thanks very much Angelique. We're glad to be here. As the title says, the unified profile, or DoDAF and MODAF or UPDM, it's what we're here to talk about today. Graham, give us some context is a little bit more detail on what UPDM is. BLEAKLEY: Okay. As it shows in the box, UPDM is Unified Profile for MODAF and DoDAF. The idea has been that the way to interchange models or architectures between MODAF and DoDAF and this is something that is becoming much more common or a need that's becoming much more common given the international nature of a lot of program development in the military world. The other reason why UPDM was developed was that in previous versions of DoDAF, a lot of the tool vendors were building proprietary versions or proprietary protocols for MODAF and DoDAF. And because there was no formal [master] model behind DoDAF, the way that they were doing it, well, they were all slightly different and so there's no ability to interchange models between the different source. And also, there was no standard way to go about representing the different artifacts and how standard workloads about how my might be produced. So, UPDM is, to some degree, an architecture towards this. It certainly gives a standard -2- interchange and a standard format for representation of elements. NOLAN: Thank you Graham. So, DoDAF 1.0, 1.5, 2.0. Then, we have UPDM 1.0 and now 2.0. What has changed in DoDAF? And why has UPDM 2.0 come out so soon after UPDM 1.0? BLEAKLEY: That's a very good question, Brian. It goes back to versions of UPDM...I'm sorry. The versions of DoDAF that were around when UPDM was initially conceived. In this version, in UPDM 1, where you actually supported DoDAF 1.5 and MODAF 1.2. MODAF 1.5 had slightly operational views, system views, technical and the old views. But [also INAUDIBLE]. MODAF 1.2 added another couple of views onto this, and these were the strategic view and it allowed you to develop capability taxonomies and show how they related to organizations and how they could be deployed. And also, an acquisition view, which is about program and product management. This is what was happening in UPDM Version 1. At around the same time or shortly after UPDM 1 came out, DoDAF 2 came out. We couldn't sync up with it at that particular time. And so, UPDM 2 is a different kettle of fish to DoDAF 1.5 for a number of reasons. -3- One, it's based around something called IDEA and this needs to match into EML for UPDM, which is a task that we carried out. The other things is DoDAF 2 also had extra views involved with it. So, within DoDAF 2 now, we have a capability view, which is very similar to the strategic view in MODAF. And we also have a project view, which is similar to the acquisition view in MODAF. Because of this it means that we can do some work in UPDM 1 to help support DoDAF 2 users while UPDM 2 was being developed. And UPDM 2 should be or will be coming out very, very shortly. We're just going through the final stages, which is the OMG will go through its acceptance of the architectural board and it should be coming out as a standard very shortly. NOLAN: Okay. We forgot to mention in our introduction that Graham, you are on the OMG committee for UPDM. Is that correct? BLEAKLEY: Yes. I've been working on it for the past three years. I'm co-chair and one of the architects or lead architect for the architecture team that's been working on UPDM 2. NOLAN: Great. I wanted to get that in. It's important, in terms of the details that we're talking about. -4- And now, you and I have talked about what you just mentioned. One of the motivators for UPDM is to provide the interchangeability between models and tools and architecture. But there's another kind of interchangeability that we have talked about, in terms of in the defense community there's kind of an acquisition group who figures out where the capabilities are needed. And then, there's a group that, in essence, implements those capabilities. So, we've called that the upstream and downstream, in terms of enterprise architecture. How does UPDM and the Rational solutions help bridge what could be a gap between the upstream and downstream communities? BLEAKLEY: I think a lot of it has to do with the requirements of the needs of the different groups carrying out these tasks. Typically, within the upstream community, which is the high-level defense agencies or the high levels of those defense agencies, these tasks have particularly been carried out with system architect, and there's a DoDAF 2 implementation systems architect, so they can carry on working within that world. But typically what happens when we get down to the tier one and the systems integrated, they normally need a lot more -5- detail or they need to flesh out a lot more detail to their development to understand exactly what the agencies are requiring. So, taking it from an operational context down to a systems, or a systems of systems view is very important for these big defense contractors. And they typically take the vague ideas and concepts from the agencies and they start to flesh them out and put a lot more detail on to them. And this is what we mean by downstream engineering. The value that these people are getting from this is because UPDM is based upon a SysML, which is based upon a UML it means that they can transfer these models down the chain from UPDM through SysML and down to UML, where they can develop software. In terms of the integration between upstream and downstream, we can either link artifacts together through some of our Jazz technology or we can start to translate information from system architect down or transfer it into Rhapsody, depending upon what artifacts are available and what work needs to be done. NOLAN: The need really here, as I understand it, is for the ability to trace in essence from the very top levels of the concepts and the concepts of operations, perhaps that is defined at the top level of the community, down to the actual implementation how the architecture which lies -6- underneath that pulls it all together. That's what UPDM helps address. The tools that we have on the Jazz Platform really help make that traceability easier, right? BLEAKLEY: That's correct. I mean, we're not dealing with single models or big monolithic single models and repositories that exist in one space. We're talking about multiple models that live in the different spaces that can be joined up so that you can do traceability all the way down from high-level capabilities, down through the operational activities that start to realize, down to the systems that do realize all the services that are going to realize. And then, even further down to implementation software. NOLAN: So, conceptually UPDM will provide that framework from the very top to the very bottom, right? Without having to jump from one language to another. BLEAKLEY: Yes. It provides the missing glue that sits between what has typically been the agency space in the tier one systems integrators, which is where [INAUDIBLE] the proprietary tools. It's also worth mentioning that UPDM is really a practical and pragmatic approach to doing modeling with DoDAF 2.0. NOLAN: Right. Okay. Well, Graham, I think we've -7- covered what we wanted to cover. So, thanks very much. We have some information that Angelique is going to pass on to close this out. BLEAKLEY: Okay. Thank you very much, Brian. It was a pleasure talking to you. NOLAN: As always, pleasure talking to you Graham. MATHENY: Yes, Graham and Brian, thank you so much for sharing your time today. It was a great discussion to listen to, and we really appreciate it. That was IBM's Graham Bleakley and Brian Nolan discussing UPDM 2.0, a UML SysML implementation of DoDAF 2.0 and MODAF 1.2 for military architectures. To share this podcast with your colleagues or if you're interested in more podcasts like this one, check out the Rational Talks To You podcast page at www.ibm.com/rational/podcasts.
Load more

Recommended publications
  • Technology Update on the Unified Architecture Framework (UAF)
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by KTUePubl (Repository of Kaunas University of Technology) Technology Update on the Unified Architecture Framework (UAF) Matthew Hause Graham Bleakley Engineering Fellow Solution Architect PTC IBM Analytics [email protected] [email protected] Aurelijus Morkevicius Senior Solution Architect No Magic [email protected] Copyright © 2016 by Matthew Hause, Graham Bleakley, Aurelijus Morkevicius. Abstract. Architecture frameworks continue to evolve. The Unified Profile for the Department of Defense (DoD) Architecture Framework (DoDAF) and the UK’s Ministry of Defence Architecture Framework (MODAF) (UPDM) provides a standard means of representing DoDAF, MODAF, and NATO Architecture Framework (NAF) conformant architectures using the Unified Modeling Language (UML), and Systems Modeling Language (SysML). Since the UPDM V2.0 publication, further information has emerged such as the June 2011 NATO study entitled: “Development of The AMN (Afghanistan Mission Network) Architecture In 2010 – Lessons Learned,” by Torsten Graeber of the NATO C3 Agency. This report identified the following in section 4.1-ARCHITECTURE FRAMEWORKS, sub-section 4.1.2 Observations (Need for a Unified Architecture Framework) and stated that: • differences in DoDAF, MODAF, and NAF make it difficult to match the metamodel one to one. • some of the concepts in the frameworks have the same name but different definitions, i.e. different semantics. • difficult to cross-walk the concepts between the different frameworks leads to miscommunication between architects using different frameworks. Based on the above, the NATO Architecture Capability Team (Architecture CaT) meeting on Sept. 10-11, 2012 committed to move to a single world-wide Architecture Framework.
    [Show full text]
  • Air Force Human Systems Integration Handbook
    Air Force Human Systems Integration Handbook: Planning and Execution of Human Systems Integration Distribution A: Unlimited Distribution Prepared by: Directorate of Human Performance Integration Human Performance Optimization Division 711 HPW/HPO 2485 Gillingham Drive Brooks City-Base, TX 78235-5105 This page intentionally left blank. 2 TABLE OF CONTENTS EXECUTIVE SUMMARY...........................................................................................................................................7 1. INTRODUCTION TO AIR FORCE HUMAN SYSTEMS INTEGRATION ......................................................8 1.1 HANDBOOK PURPOSE........................................................................................................................................8 1.2 HISTORY .............................................................................................................................................................8 1.3 KEY CONCEPTS................................................................................................................................................10 1.4 DOMAINS ..........................................................................................................................................................10 2. IMPLEMENTING AIR FORCE HUMAN SYSTEMS INTEGRATION...........................................................12 2.1 PRIMARY AFHSI ORGANIZATIONS..................................................................................................................12 2.1.1 Air Force
    [Show full text]
  • Sysml Distilled: a Brief Guide to the Systems Modeling Language
    ptg11539604 Praise for SysML Distilled “In keeping with the outstanding tradition of Addison-Wesley’s techni- cal publications, Lenny Delligatti’s SysML Distilled does not disappoint. Lenny has done a masterful job of capturing the spirit of OMG SysML as a practical, standards-based modeling language to help systems engi- neers address growing system complexity. This book is loaded with matter-of-fact insights, starting with basic MBSE concepts to distin- guishing the subtle differences between use cases and scenarios to illu- mination on namespaces and SysML packages, and even speaks to some of the more esoteric SysML semantics such as token flows.” — Jeff Estefan, Principal Engineer, NASA’s Jet Propulsion Laboratory “The power of a modeling language, such as SysML, is that it facilitates communication not only within systems engineering but across disci- plines and across the development life cycle. Many languages have the ptg11539604 potential to increase communication, but without an effective guide, they can fall short of that objective. In SysML Distilled, Lenny Delligatti combines just the right amount of technology with a common-sense approach to utilizing SysML toward achieving that communication. Having worked in systems and software engineering across many do- mains for the last 30 years, and having taught computer languages, UML, and SysML to many organizations and within the college setting, I find Lenny’s book an invaluable resource. He presents the concepts clearly and provides useful and pragmatic examples to get you off the ground quickly and enables you to be an effective modeler.” — Thomas W. Fargnoli, Lead Member of the Engineering Staff, Lockheed Martin “This book provides an excellent introduction to SysML.
    [Show full text]
  • On Using Sysml, Dodaf 2.0 and UPDM to Model the Architecture for the NOAA's Joint Polar Satellite System (JPSS) Ground System (GS)
    https://ntrs.nasa.gov/search.jsp?R=20120009882 2019-08-30T20:31:32+00:00Z On Using SysML, DoDAF 2.0 and UPDM to Model the Architecture for the NOAA's Joint Polar Satellite System (JPSS) Ground System (GS) Jeffrey L. Hayden' and Alan Jeffiies' Jeffries Technology Solutions, Inc. (JeTSI), Herndon, VA, 20170, USA The JPSS Ground System is a lIexible system of systems responsible for telemetry, tracking & command (TT &C), data acquisition, routing and data processing services for a varied lIeet of satellites to support weather prediction, modeling and climate modeling. To assist in this engineering effort, architecture modeling tools are being employed to translate the former NPOESS baseline to the new JPSS baseline, The paper will focus on the methodology for the system engineering process and the use of these architecture modeling tools within that process, The Department of Defense Architecture Framework version 2,0 (DoDAF 2.0) viewpoints and views that are being used to describe the JPSS GS architecture are discussed. The Unified Profile for DoOAF and MODAF (UPDM) and Systems Modeling Language (SysML), as ' provided by extensions to the MagicDraw UML modeling tool, are used to develop the diagrams and tables that make up the architecture model. The model development process and structure are discussed, examples are shown, and details of handling the complexities of a large System of Systems (SoS), such as the JPSS GS, with an equally complex modeling tool, are described. I. Introduction N February 2010, the US Government restructured the National Polar-orbiting Operational Enviromnental Satellite S),stem (NPOESS) into the National Oceanic and Atmospheric Administration (NOAA)lNational Aeronautics and Space Agency (NASA) Joint Polar Satellite System (JPSS) and the Department of Defense's Defense Weather I Satellite System (DWSS).
    [Show full text]
  • Sodiuswillert Product Brochure
    UNLOCKING ASSETS TO EMPOWER INNOVATION THROUGH ENGINEERING DATA INTEGRATION PRODUCT SHEET Move Models from Rhapsody® to MagicDraw™ Whether your goal is to migrate to MagicDraw or deliver in the MagicDraw format, the Publisher for Rhapsody makes model recreation easy and repeatable. AUTOMATE MODEL TRANSFORMATION FROM RHAPSODY TO MAGICDRAW Creating MagicDraw models may be a necessary step in today’s multi-tool Use Cases: environment. We understand the retention of model elements, structure, and diagram layouts are critical and required in any workflow. The Publisher • Publish: maintain your for Rhapsody enables your team to explore the business’s needs of tool knowledge base in Rhapsody flexibility with confidence. but deliver to a customer to integrate in MagicDraw. Explore And Deliver Mandated File Formats • Migrate: move your data out of Publish your Rhapsody models to MagicDraw to deliver mandated file Rhapsody and further develop formats for a customer. Explore your Rhapsody models in MagicDraw for in MagicDraw. projects that mandate the use of MagicDraw for development. Keep your team, training, and licenses with your Rhapsody investment and still deliver to the program’s requirements. $ SAVE ENGINEERING TIME MAINTAIN DATA INTEGRITY IMPROVE YOUR ROI Save months or years of critical Manually migrating data from one Building complex Rhapsody models engineering resources converting SysML tool to another can be prone and correctly converting them into and validating re-written models. to error. The Publisher for Rhapsody MagicDraw can take engineering With the Publisher for Rhapsody, accurately migrates model elements, teams months or even years to users of Rhapsody can automate the diagram and, layouts created in your complete.
    [Show full text]
  • Paper 080: Service-Orientated Representations of the Military Business
    11th ICCRTS COALITION COMMAND AND CONTROL IN THE NETWORKED ERA Title: Paper 080: Service-orientated representations of the military business. Topic: C2 Concepts and Organisation Author 1 (POC): Author 2: Author 3: Geoff Markham Harry Duncan Robert Symonds QinetiQ plc QinetiQ plc QinetiQ plc St Andrew’s Road St Andrew’s Road St Andrew’s Road MALVERN MALVERN MALVERN WR14 3PS WR14 3PS WR14 3PS United Kingdom United Kingdom United Kingdom Tel: +44 1684 896399 E-mail: mailto:[email protected] This abstract is based on research undertaken for the United Kingdom Ministry of Defence and is covered in whole by Crown Copyright. v.0.2.6 GM 12th July 2006 REVISED ABSTRACT In the context of the deployment of military forces, command is the director and integrator of other capabilities, i.e. the structures, processes and assets associated with Inform, Prepare, Project, Operate, Protect and Sustain1. Command is the ‘builder’ or ‘composer’ of the military organization (and its extra-military affiliations) in response to current operational needs. The commander may wish to adopt any of a variety of organizational configurations, yet is constrained to build his organization out of the existing military fabric (e.g. procedures, staff, equipment, HQ facilities). This is the architectural thesis of composition (the whole being constructed from known building blocks through the satisfaction of an architectural ruleset), being applied in the context of the command of a specific operation. Re-composition (re-build) continues in theatre in the form of Task Organization, and the ‘run-time’ behaviour of the organization are then excitations of features of the ‘built’ structure under the conditions of executing operational activities.
    [Show full text]
  • Nato Architecture Framework (Naf)
    NATO ARCHITECTURE FRAMEWORK Version 4 Architecture Capability Team Consultation, Command & Control Board January 2018 Acknowledgments for NAFv4 Publication Throughout the development of version 4 of this publication numerous individual experts of NATO Nations participated, resulting in this significant achievement: The realization of the NATO Architecture Framework. This work would not have been possible without the continuous support of the Ministries of Defence of United Kingdom and France, and the NATO Science and Technology Organization. Also special thanks goes to Partner Nations and Industry Partners for their unwavering support in assigning and providing their best professional resources in the architecture domain. The NATO Architecture Framework is a substantial achievement for the Architecture Capability Team under the Consultation, Command and Control Board. Each member of the Architecture Capability Team worked determinedly over the last four years to provide extensive professional guidance and personal effort in the development of this product. The Architecture Capability Team is grateful to all for their contributions to this effort. 4 NAFv4 NAFv4 5 CONTENTS Chapter 1 - Introduction 1 GENERAL ....................................................................................................................................................................... 11 1.1 Purpose ........................................................................................................................................................................
    [Show full text]
  • Unified Profile for the Department of Defense Architecture Framework (Dodaf) and the Ministry of Defence Architecture Framework (MODAF)
    Date: January 2009 Unified Profile for the Department of Defense Architecture Framework (DoDAF) and the Ministry of Defence Architecture Framework (MODAF) FTF Beta 1 OMG Document Number: dtc/2009-xx-xx Standard Document URL: http://www.omg.org/spec/UPDM/1.0 Associated File(s): http://www.omg.org/spec/20080801 * original files: c4i/2008-08-13, 2008-08-01, 2008-08-03, 2008-09-01 This OMG document replaces the submission document (c4i/08-08-13, Alpha). It is an OMG Adopted Beta Specification and is currently in the finalization phase. Comments on the content of this document are welcome, and should be directed to [email protected] by March 16, 2009. You may view the pending issues for this specification from the OMG revision issues web page http://www.omg.org/issues/. The FTF Recommendation and Report for this specification will be published on September 29, 2009. If you are reading this after that date, please download the available specification from the OMG Specifications Catalog. Copyright © 2003-2008, Adaptive Copyright © 2003-2008, Artisan Software Tools, Ltd. Copyright © 2003-2008, EmbeddedPlus Engineering Copyright © 2003-2008, No Magic Copyright © 2008, Object Management Group, Inc. Copyright © 2003-2008, Rolls Royce Copyright © 2003-2008, Sparx Systems Pty Ltd Copyright © 2003-2008, Visumpoint USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company's products. The information contained in this document is subject to change without notice.
    [Show full text]
  • NCSC Certification for Cyber Security/IA Professionals
    November 2018 Issue No: 5.4 NCSC Certification for Cyber Security/IA Professionals NCSC Certification for Cyber Security/IA Professionals Issue No: 5.4 November 2018 The copyright of this document is reserved and vested in the Crown. Document History Issue Date Comment 1.0 March 2011 First definitive version. Certification Bodies may, at their discretion, accept the Infosec Training Paths Competency scheme qualification as sufficient evidence for 1.1 September 2012 meeting the requirements of the Security & Information Risk Advisor role at responsibility Level 2. Removal of FOIA footer throughout the document. Addition to both the role purpose and the responsibilities for both the 1.2 May 2012 Comsec Practitioner and the ComSO roles. Updates to reflect revised mapping of Mandatory Requirements (MR) in HMG SPF v7.0, October 11. 1.3 May 2012 Minor update to Table 7. Second definitive version. Removal of guidance chapters and their incorporation with NCSC ‘Awareness & Training’ web pages. Removal of statements in Accreditor role definition requiring Senior & Lead Accreditors to meet responsibility requirements of Practitioner and 2.0 September 2012 Senior Accreditors respectively. Change of role title from Security Architect to IA Architect. Additional bullet point to the S&IRA Lead Practitioner role: ‘Leads development of IA training, guidance or professional standards in widespread use across the public sector’. Addition of knowledge statements to skill group definitions – see Annex A Third definitive version. Incorporating HM Treasury GPG on role of internal audit in IA. Additional 3.0 June 2013 bullets to IA Senior & Lead Auditor roles Introduction of flexibility in core skills for IA Auditor role.
    [Show full text]
  • Returning Science to the Social (Making Sense of Confusion: a Case for Honest Reflection) Simon Reay Atkinson
    Defence Academy of the United Kingdom The Shrivenham Papers Returning Science To The Social (Making Sense Of Confusion: A Case For Honest Reflection) Simon Reay Atkinson Number 10 - July 2010 The Defence Academy of the United Kingdom The Defence Academy is the institution responsible for post- graduate education and the majority of staff, command, leadership, defence management, acquisition and technology training for members of the UK Armed Forces and MOD Civil Servants. It is also responsible for the provision of non-technical research and assessment in support of the Department, and for establishing and maintaining itself as the MOD’s primary link with and with international military educational institutions. By operating under unified direction and with a single budget, it capitalises on the combined strengths of its Colleges, enables the cost-effective use of staff, facilities and money and maximises influence both nationally and internationally. The Academy comprises the Royal College of Defence Studies, the Joint Services Command and Staff College, the College of Management and Technology, and the Armed Forces Chaplaincy Centre. The Academy has three strategic partners – King’s College London, Serco Defence, Science and Technology, and Cranfield University – who provide our academic and facilities support and who are vital to our success. DEFENCE ACADEMY OF THE UNITED KINGDOM RETURNING SCIENCE TO THE SOCIAL (MAKING SENSE OF CONFUSION: A CASE FOR HONEST REFLECTION) BY SIMON REAY ATKINSON THE SHRIVENHAM PAPERS NUMBER 10 JULY 2010
    [Show full text]
  • 21 ICCRTS Implementing UPDM to Develop Command and Control
    21st ICCRTS Implementing UPDM to Develop Command and Control Systems Topics Topic 7: Methodological Development, Experimentation, Analysis, Assessment and Metrics Author Rudolph Oosthuizen (CSIR, South Africa; [email protected]) Cobus Venter (CSIR, South Africa; [email protected]) Point of Contact Rudolph Oosthuizen (CSIR, South Africa; [email protected]) Name of Organization: Council for Scientific and Industrial Research PO Box 395 Pretoria 0001 [email protected] 1 Implementing UPDM to Develop Command and Control Systems Abstract Systems engineering is an established approach to develop systems, including complex sociotechnical systems such as Command and Control (C2) systems. These systems often occur through the introduction of a new technology into an existing system. In systems engineering, modelling is applied to capture and represent the mental models of the systems’ stakeholders during the concept development stage. These models, consisting of various views on the system structure and behaviour, can be used to derive requirements for system development. The views of the models must represent the mental model of the originator as well as ensure that the interpreters develop the same understanding. An architectural frameworks, such as the Ministry of Defence Architecture Framework (MoDAF) and Department of Defence Architecture Framework (DoDAF), supports Model Based Systems Engineering (MBSE). The Unified Profile for DODAF and MoDAF (UPDM) supports development of the model to ensure transportability to other participants in the development process. This paper proposes a model development process within UPDM for a C2 system during concept development. 1 Introduction Systems engineering aims to solve problems by bringing systems into being through systems thinking for understanding the part in the context of the whole (Hitchins 2008, Stensson 2010).
    [Show full text]
  • Model-Based System of Systems Engineering with UPDM
    Model- Based System of Systems Engineering with UPDM Matthew Hause Atego Eagle Tower Suite 701 Cheltenham, Glos, GL50 1TN England [email protected] Copyright © 2010 by Matthew Hause. Published and used by INCOSE with permission. Abstract. The Unified Profile for DoDAF and MODAF, (UPDM) initiative was started by members of INCOSE and the OMG. UPDM provides a consistent, standardized means to describe DoDAF 1.5 and MODAF 1.2 architectures in SysML/UML-based tools as well as a standard for interchange. The concepts found in the Systems Modeling Language (SysML) such as parametrics, blocks, complex ports, enhanced activity modeling, and cross-cutting constructs improve the state of the art for systems engineers and architects. The formal meta-model basis of UPDM also provides a basis for trade-off analysis, model execution, requirements traceability, and the transition to systems development and implementation. Finally, the interconnections between views can help combat stovepipe development and improve communication. This paper looks at the current direction of UPDM, how it is improving the state of the art for system architects, and enables interchange of architectural information. We will also examine some of the latest concepts found in DoDAF 2.0 and how the UPDM Group is addressing these. INTRODUCTION What is a Military Architectural Framework? Arguably, the two most widely used military frameworks are the Department of Defense (DoD) Architecture Framework (DoDAF) in the USA and the Ministry of Defence (MOD) Architecture Framework (MODAF) in the UK. Military Architectural Frameworks such as DoDAF define a standard way to organize an enterprise architecture (EA) or systems architecture into complementary and consistent views.
    [Show full text]