HOW TO SPECIFY SERVICES?

1
HOW TO SPECIFY SERVICES?

• Takahiro Yamada (JAXA/ISAS)
• CCSDS Meeting, Heppenheim, Germany
• 2 October 2007

2
Purpose of This Presentation

• The purpose of this presentation is to propose a
  method for specifying services that can be
  applied to any service definition produced by
  CCSDS.
• This proposal corresponds to the CCSDS Service
  Reference Model that Gert Villemos showed in his
  paper entitled How to Specify Services?
  (TER-63-CCSDS-TN-0001) and and (hopefully)
  provides a starting point for discussion toward
  generating that model.

3
The Proposal

• This proposal is based on my research work on
  extending the international standard on
  Reference Model of Open Distributed Processing
  (RM-ODP) (IOS/IEC 10746-2).
• Some of the concepts/definitions presented here
  were directly taken from RM-ODP, but most of the
  concepts/definitions are results of my research.
• This proposal defines basic elements and
  relationships among them using textual
  descriptions and UML-like diagrams. The diagrams
  should be used as a basis for developing an
  ontology for the CCSDS Service Reference Model.
• This study is still at a very preliminary stage
  and any comments are welcome!

4
Basic Elements (1)

• Object A model of an entity.
• Service A capability provided by an object for
  another object. A service is realized with a set
  of operations.
• Action Something which happens.
• Operation An action performed by an object and
  triggered by another object.
• Interaction A set of actions which two or more
  objects perform jointly. Some of the actions
  involve sending and receiving messages.
• Message A set of pieces of information sent from
  an object to another object at one time.

5
Basic Elements (2)

• Behavior A collection of actions associated with
  an object with a set of constraints on when they
  may occur. A behavior is described with a set of
  states and state transitions.
• State At a given instant in time, the condition
  of an object that determines the set of behaviors
  that the object can take.
• Port An abstraction of the behavior of an object
  which consists of the actions belonging to a
  subset of the interactions which that object
  participates in.

6
UML-like Representation of Basic Elements
Service
Realized with
Operation
Triggers
Object
Behavior
Action
Port
Described by
Send/Receive
Participates in
State
Interaction
Message
Involves
7
Structuring Relationships

• ltXgt Type A predicate characterizing a collection
  of ltXgts. ltXgt can be any basic element.
• Each service type is described with types of
  elements (see the diagram in the next page).
• Examples of service types are transfer service
  type, management service type, monitor and
  control service type, etc.
• Role Identifier for a port (or a part of a port)
  of objects that participate in a type of
  interactions. A role is a kind of port type.
• For each interaction type, each of the objects
  that take part in it plays one or more roles.
• An object may have multiple ports, each with a
  different role.

8
UML-like Representation of Service Type
Object
Service
Behavior
Port
Interaction
Message
Operation
ObjectType
Behavior Type
Port Type or Role
Interaction Type
Message Type
Operation Type
Described with
Service Type