Object Management Group OMG Unified Profile for Do

Object Management Group (OMG) Unified Profile for Do. DAF & MODAF (UPDM)

The Need for UPDM § Motivation § To significantly enhance the quality, productivity, and effectiveness associated with enterprise and system of systems architecture modeling, promote architecture model reuse and maintainability, improve tool interoperability and communications [among] stakeholders, and reduce training impacts due to different tool implementations and semantics § To improve integration between system of systems modeling & system modeling to support post acquisition life cycle design modeling § Implements the Conceptual Models of Do. DAF and other AFs § Compatibility with Existing Tools § Unified Modeling Language (UML 2. x) (UPDM Level 0) § System Modeling Language (Sys. ML 1. x) (UPDM Level 1) § Support: UPDM fully supported by Do. D, MOD, and International Defence Enterprise Architecture Specification (IDEAS) Working Group § Statement and slides available on OMG website 2

Historical Development of Architectural Frameworks _____ * NAF = NATO AF MODAF Meta-Model (M 3) NAF* NAF v 1. 0 v 3. 0 expressed using 2005 UML Notation C 4 ISR Architectur e Framework v 2. 0 MODAF v 1. 0 v 1. 1 2005 2007 Scope of “Unified Profile for Do. DAF and MODAF” (UPDM)approved Dec 2008 MODAF v 1. 2 Do. DAF 2008 1997 Do. DAF C 4 ISR Architectur e Framework v 1. 0 1996 v 1. 0 2003 Do. DAF v 1. 5 2. 0 (Late 2008) 2007 3

Cross References and Links § Cross references § Do. D Metadata Registry (DMDR) § Do. D Architecture Registry (DARS) § GIG Technical Guidance § Links § UPDM Group: http: //www. updm. com/ § Do. D Position on Unified Profile for Do. DAF & Mo. DAF (UPDM) OSD DISR UPDM RFC Brief to OMG C 4 I DTF 2008 -09 -23 § UPDM Group Position Statement presented at the OMG UPDM Position Statement UKUS_Final § Do. D Enterprise Architecture Conference 2009, St Louis, MO; 1 – 4 June 2009: http: //www. afei. org/brochure/9 a 05/index. cfm 4

Systems Architecture & Design Lecture 6 The Design Process Brian E. White, Ph. D. 25 May 2009 Version 2 (v 2) 5

Functional and Logical Decomposition Outputs (1/2) § System architecture model § Defines the underlying structure and relationship of system elements (e. g. , hardware, software, communications, operations, etc. ) and basis for partitioning of requirements into lower levels to point that design work can be accomplished § Usually results in Do. DAF Operational View products 6

Systems Architecture & Design Lecture 7 Analysis of Alternatives Brian E. White, Ph. D. 1 June 2010 Version 3 (v 3)

Example: Enterprise Architecture (EA) Repository EA Repository Business Architecture Systems Architecture Technical Standards Profile Business Process Data Base (DB) Program /Earned Value Management (EVM) Tracking Other EA Repositories Standard Operating Procedure (SOP) Manuals Policies Systems Inventories Network Mgmt System Organization/ Staff Module Resource Request Matrix (RRM) DB Government Performance and Results Act (GPRA) Reporting Others? Performance Contract Mgmt DB Technical Standards Profile 8

Architecture or Archeology? Both! Asset Analysis & Repository Design: Info Representations Documents & Reports User Profiles Bringing Order to Chaos Operational Processes Network Modeling Key Decisions Information Assurance Systems Analyses Application Inventories Data Sharing & Integration Leverage Existing Artifacts: Content & Format Business Analyses Decision Analyses Information Relationships Data Analyses Model Design Interface Analyses Access/Usage Analyses Pedigree Analyses System Inventories Connectivity Analyses Network Access & Availability Enterprise Information Repository Development Conceptual Information Model Meta-data Modeling Variety of Skills & Activities! Meta-Model Development Logical DM Development DBMS Design Data Integrity Analyses Avoid “Creative Writing” Physical DM Development Identification of Authoritative Information for Decision Support 9

Systems Architecture & Design Lecture 8 Decision Analysis Brian E. White, Ph. D. 8 June 2010 Version 3 (v 3)

Systems Architecture & Design Lecture 9 Architectural Modeling, Architectural Description Languages, and Systems Architecting Challenges Brian E. White, Ph. D. 15 June 2010 Version 2 (V 2)

What is Architectural Modeling? § Architecture can be regarded as the set of principal design decisions made about a system § We can define models and modeling in those terms § An architectural model is an artifact that captures some or all of the design decisions that comprise a system’s architecture § Architectural modeling is the reification* and documentation of those design decisions § How we model is strongly influenced by the notations we choose § An architectural modeling notation is a language or means of capturing design decisions § Often called an Architecture Description Language (ADL) § There will be more about ADLs in the next section _____ * That which makes something abstract more concrete or real 12

How Do We Choose What to Model? § Architects and other stakeholders must make critical decisions 1. What architectural decisions and concepts should be modeled? 2. At what level of detail? 3. With how much rigor or formality? § These are cost/benefit decisions § The benefit of creating and maintaining an architectural model should significantly exceed the cost 13

IEEE 1471 Architecture Description Standard Has System 1 Architecture Described by 1. . * What do you think of this diagram? Architecture Description 1. . * Stakeholder 1. . * Covers Concern 1. . * Viewpoint Conforms to 1 1 1. . * Covers 1. . * View 1. . * Defines Method 1. . * Model Viewpoint Library 14

IEEE 1471 in Words § A system has 1 architecture § An architecture is described by 1 or more architecture descriptions § An architecture description is composed of 1 or more of stakeholders, concerns, viewpoints, views, and models § A stakeholder has 1 or more concerns § A concern has 1 or more stakeholders § A viewpoint covers 1 or more concerns and stakeholders § A view conforms to 1 viewpoint § A viewpoint defines the method of a model § A view has 1 or more models and a model is part of 1 or more views § A viewpoint library is composed of viewpoints 15

Survey of Modeling Approaches § Generic approaches § Natural language § Power. Point-style modeling § UML/Sys. ML § Early architecture description languages § Darwin § Domain- and style-specific languages § Koala § Architecture Analysis and Design Language (AADL) § Extensible architecture description languages § Acme What does extensible mean here? § Architecture Description and Markup Language (ADML) § x. ADL 16

Early Architecture Description Languages § ADLs proliferated in the 1990 s and explored ways to model different aspects of software architecture § Many emerged from academia § Focus on structure § § Components Connectors Interfaces Configurations § Focus on formal analysis § None used actively in practice today § Tool support has waned § Ideas influenced many later systems though 17

Darwin § General purpose language with graphical and textual visualizations focused on structural modeling of systems § Advantages § Simple, straightforward mechanism for modeling structural dependencies § Interesting way to specify repeated elements through programmatic constructs § Can be modeled in -calculus formal analysis § Mathematical formalisms for describing and analyzing properties of concurrent computation § Does not contain primitives such as numbers, Booleans, data structures, variables, functions, or even the usual flow control statements (such as if. . . then. . . else, while. . . ) § Can specify hierarchical (i. e. , composite) structures § Disadvantages § Limited usefulness beyond simple structural modeling § No notion of explicit connectors 18

Koala § Darwin-inspired notation for specifying product lines of embedded consumer-electronics devices § Advantages § Advanced product-line features let you specify many systems in a single model § Direct mapping to implemented systems promotes design and code reuse § Disadvantages § Limited to structural specification with additional focus on interfaces 19

AADL § In November 2004, the Society of Automotive Engineers (SAE) released the aerospace standard AS 5506, named the Architecture Analysis & Design Language (AADL) § AADL is a modeling language that supports early and repeated analyses of a system’s architecture with respect to performance-critical properties through an extendable notation, a tool framework, and precisely defined semantics § The language employs formal modeling concepts for the description and analysis of application system architectures in terms of distinct components and their interactions 20

AADL (Continued) § It includes abstractions of software, computational hardware, and system components for § Specifying and analyzing real-time embedded and high dependability systems, complex systems of systems, and specialized performance capability systems § Mapping of software onto computational hardware elements § AADL is especially effective for model-based analysis and specification of complex real-time embedded systems 21

AADL (Concluded) § Advantages § Allows detailed specification of both hardware and software aspects of a system § Automated analysis tools check interesting end-to-end properties of system § Disadvantages § Verbose § Large amount of detail required to capture even simple systems § Emerging tool support and UML profile support 22

Archi. Mate § The Open Group's open and independent modeling language for enterprise architecture § For describing, analyzing and visualizing the relationships among business domains in an unambiguous way § A common language for describing the construction and operation of business processes, organizational structures, information flows, IT systems, and technical infrastructure § See http: //www. archimate. org/ 23

Architecture and Strategy § Strategic decisions are technical § Technical decisions are strategic § Consider the loop What company might this remind you of? ! § Strategic Identity is “We take end-to-end responsibility. ” § Dominant error types are hard to find, except in the field § Drives toward designs that provide good diagnostics, easy fixes § Enables strategy of “We take end-to-end responsibility. ” § Another alignment (or failure to) § Do you know the tradeoff of revenue vs. cost for getting it right versus getting it sooner? § How do discovery costs and recovery costs compare? § Is your technical architecture supportive of the tradeoff? § Do you know how to adapt to the tradeoff in your business or organization? 24

Architecture and Strategic Identity What is this system? § At the simplest level, architecting is about bringing problem and solution into alignment § It’s about finding satisfactory and feasible solutions to ill-structured problems § At another level, architecting is about aligning tensions between problem, solution, program, and organization § Program: How we go about implementing a solution? § Organization: The human grouping that does the solving § The “Art” of Systems Architecting has, at least, two components § The art of synthesis of creative solutions § The art of balance in multiple, disparate dimensions of problem, organization, and program 25

Three Systems Paradigms Ill-structured problem: A problem where the statement of the problem depends on the statement of the solution 26 Adapted from: Maier and Rechtin, The Art of Systems Architecting, second edition, CRC Press, 2000