Transcript RASDS, DODAF and RMODP

RASDS, RM-ODP and DoDAF
Version 3
April 21, 2006
Takahiro Yamada (JAXA/ISAS)
1
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.
2
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.
3
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.
4
RASDS Elements and Their Relationships
RASDS
Top Level Objects
ComposedOf
Organization
Perspective
Mission
Req uirements
FulfilledBy
Contains Objects
Defines Rules
Objectives
Goals
Scenarios
ComposedOf
Exposes Concerns
Owns/Operates
Fulfills
Calls
Produces
Function
Consumes
Logical structure
Behavior
Interfaces
Constraints
Information
IsAllocatedT o
Data
Metadata
ComposedOf
Rules
ContainsInstances
Node
ProvidesService
Uses
Affects
Environment
Type
ImplementedOn
Communication
Attributes
Ports
ConnectVia
Physical Environs
Attributes
Location
ConnectT oPort
Protocol stack
Standards
AssociatedWith
Link
Type
Attributes
5
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.
6
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.
7
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).
8
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.
9
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).
10
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)
11
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
12
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
13
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).
14
DoDAF Elements and Their Relationships
(Partial and not Exact)
Operational
Activity
Performs
Is Implemented
By
System
Function
Generates or
Consumes
Hosts
System
Data
Operational
Node
Owns
System
Node
Is Exchanged
Between
15
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).
16
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?
17
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.
18
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.
19