RASDS, RM-ODP and DoDAF

1
RASDS, RM-ODP and DoDAF

• Version 3
• April 21, 2006
• Takahiro Yamada (JAXA/ISAS)

2
Introduction

• This document contains the result of an analysis
  of the relationship between RASDS and RM-ODP
  (including UML4ODP) and the relationship between
  RASDS and DoDAF.

3
Systems That RASDS Should Describe

• Systems that RASDS should describe are large,
  complex systems with a large number of diverse
  functions performed by different organizations at
  various places using a variety of things
  (hardware and software).
• Organizations that should be described by RASDS
  include space agencies, manufacturers, (tracking
  and communications) service providers, users (of
  data produced by spacecraft), etc.
• Places that should be described by RASDS include
  spacecraft (orbiting and landed), tracking
  stations, control centers, science institutes,
  etc.
• Things (hardware and software) that should be
  described by RASDS include computers, computer
  programs, communications networks, radio
  equipment, hardware elements (such as cameras and
  robot arms), RF links, etc.

4
Elements and Their Relationships

• In order to describe space data systems, it is
  important to show what kinds of elements exist in
  the system and what kinds of relationships exist
  between elements.
• In order to do this, we have defined classes of
  basic elements and classes of basic relationships
  between elements as shown on the next page.
• Each RASDS viewpoint is used to show elements of
  a few kinds and the relationships between these
  elements.
• Consistency between different viewpoints can be
  maintained by using the basic relationships
  between different kinds of elements shown on the
  next page.

5
RASDS Elements and Their Relationships
6
RASDS vs. RM-ODP and UML4ODP (Consistency)

• In RM-ODP, there are only few rules to maintain
  consistency between different viewpoints.
• Consistency between viewpoints can be maintained
  by correspondence between objects, but there are
  only two explicit rules about correspondence
  (i.e., between computational and engineering
  objects, and between engineering and technology
  objects).
• There are no explicit rules on how the enterprise
  or information viewpoint constrains or affects
  the other three viewpoints. For example, it is
  all up to the user to determine ways to describe
  how the policies of enterprise objects are
  implemented in the other viewpoints.

7
RASDS vs. RM-ODP and UML4ODP(General Rules)

• There are only few general rules that are
  applicable to all the viewpoints.
• (Example) Although behaviors of objects are
  mentioned in almost all viewpoints, there are no
  general rules concerning how to describe
  behaviors of objects across all the viewpoints.
• (Example) Although the concept of roles played by
  objects is used in the enterprise and
  computational viewpoints (and possibly in other
  viewpoints as well, because this concept must be
  used for determining whether or not two objects
  can interact with each other), it is discussed
  only in the enterprise viewpoint.

8
RASDS vs. RM-ODP and UML4ODP(Enterprise
Viewpoint)

• It would be useful if there were methods for
  describing different types of enterprise objects
  such as
• Enterprise objects that are almost always used as
  actors of actions (for example, organizations)
• Enterprise objects that are almost always used as
  artifacts in actions (for example, documents)
• Enterprise objects that are almost always used as
  resources in actions (for example, facilities)
• It would be useful if there were methods for
  describing basic relationships between different
  types of enterprise objects (for example, an
  organization owns resources).

9
RASDS vs. RM-ODP and UML4ODP(Information
Viewpoint)

• We need to do some more analysis to determine
  whether the RM-ODP Information Viewpoint is
  sufficient for describing information produced by
  spacecraft.
• We also need to compare the CCSDS Information
  Architecture Reference Model with the RM-ODP
  Information Viewpoint.

10
RASDS vs. DoDAF (General)

• Although we did not use DoDAF for developing
  RASDS, we can define a close mapping between
  RASDS elements and DoDAF elements and between
  RASDS viewpoints and DoDAF views/products, as
  shown on the next three pages.
• A major difference between RASDS and DoDAF is
  that the RASDS information object maps to both
  the information element (OV-3) and the system
  data (SV-6) of DoDAF.
• RASDS does not have a standard way of describing
  behaviors (OV-6 and SV-10), performance (SV-7),
  evolution (SV-8), or forecast (SV-9 and TV-2).

11
Correspondence Between RASDS and DoDAF Elements
DoDAF Elements RASDS Elements
Operational Nodes (OV-2) Enterprise Objects (EV)
Needlines (OV-2) Enterprise Interactions (EV)
Information Elements (OV-3) Information Objects (IV)
Operational Activities (OV-5) Enterprise Operations (EV)
Systems Nodes (SV-1) Nodes (CV)
Systems (SV-1) Sub-nodes (CV)
System Interfaces (SV-1) Links (CV)
Key Interface (SV-1) Cross-support interface (CV)
System Functions (SV-4) Functional Objects (FV)
System Data (SV-6) Information Objects (IV)
12
Correspondence Between RASDS and DoDAF Views (1/2)
DODAF View and Product RASDS Viewpoint
Overview and Summary Information (AV-1) None
Integrated Dictionary (AV-2) None
High-Level Operational Concept Graphic (OV-1) None
Operational Node ConnectivityDescription (OV-2) Enterprise Viewpoint
Operational Information Exchange Matrix (OV-3) Information Viewpoint
Organizational Relationships Chart (OV-4) Enterprise Viewpoint
Operational Activity Model (OV-5) Enterprise Viewpoint
Operational Rules Model, etc (OV-6) None
Logical Data Model (OV-7) Information Viewpoint
Systems Interface Description (SV-1) Connectivity Viewpoint
Systems Communications Description (SV-2) Comm. Viewpoint
Systems-Systems Matrix (SV-3) None
13
Correspondence Between RASDS and DoDAF Views (2/2)
DODAF View and Product RASDS View
Systems Functionality Description (SV-4) Functional Viewpoint
Operational Activity to Systems Functionality Traceability Matrix (SV-5) None
Systems Data Exchange Matrix (SV-6) Information Viewpoint
Systems Performance Parameters Matrix (SV-7) None
Systems Evolution Description (SV-8) None
Systems Technology Forecasts (SV-9) None
Systems Functionality and Timing Descriptions (SV-10) None
Physical Schema (SV-11) Information View
Technical Standards Profile (TV-1) (partially, Comm. Viewpoint)
Technical Standards Forecast (TV-2) None
14
RASDS vs. DoDAF (Consistency)

• Consistency between different views in DoDAF can
  be maintained in a similar way to RASDS.
• In DoDAF, relationships between elements in
  different views/products are clearly defined
  (e.g., operational activities are implemented by
  system functions at system nodes) and the users
  must specify the relationships between instances
  of different elements.
• Although it is not shown in the DoDAF documents,
  we can draw a diagram similar to the one on page
  5 (see the next page).

15
DoDAF Elements and Their Relationships(Partial
and not Exact)
Performs
Operational Node
Operational Activity
Is Implemented By
Owns
Hosts
System Function
System Node
Generates or Consumes
Is Exchanged Between
System Data
16
Things That Should (Hopefully) Be Done About
RASDS-RMODP-DoDAF

• Extract general rules that lie under RASDS,
  RM-ODP and DoDAF, including
• Rules for describing views,
• Rules for describing elements,
• Rules for describing relationships between
  elements,
• Rules for describing behaviors of elements,
• Rules for describing roles played by elements,
  and
• Rules for describing information and data
• Define a UML profile for the above rules.
• Is this too difficult or too late? I hope not!
• But, to do this, we have to answer some
  theoretical questions (see the next page).

17
Theoretical Questions

• Someone must prepare answers to the following
  questions that can be used in any architectural
  technique.
• What are models?
• What is the relationship between models and
  things that are modeled?
• What are views?
• How should views be constructed?
• How should different views be related?
• How should consistency between views be
  established and checked?

18
ANSI/IEEE 1471-2000

• ANSI/IEEE 1471-2000 Recommended Practice for
  Architectural Description of Software-Intensive
  Systems provides answers to many of the
  questions listed in the previous.
• However, I think we need to check whether this
  standard provides guidance necessary for
  different groups to develop different views in a
  consistent way.
• If there is a need, we should consider expanding
  this standard.

19
How Should We Proceed?

• I think it would be very beneficial if we could
  establish a forum to discuss the relationship
  between different architecting/modeling
  techniques in hope of finding common solutions.