Formalizing ODP

1
Formalizing ODP Computational Viewpoint Specifica
tion in Maude
Raúl Romero and Antonio Vallecillo
Dpto. Lenguajes y Ciencias de la
Computación Universidad de Málaga,
Spain jrromero, av_at_lcc.uma.es
EDOC 2004
2

1. Motivation
2. The ODP Computational Viewpoint
3. Maude
4. Writing CV specifications in Maude
5. An example
6. Conclusions

Contents
3

• RM-ODP is a framework for ODP standardization and
  system specification covering all aspects of
  distributed systems enterprise business, system,
  technology, distribution,
• comprehensive and coherent object-oriented
  modelling concepts
• viewpoints
• viewpoint specifications
• Transparencies
• Common functions

Motivation RM-ODP
4
Motivation ODP Viewpoints
ODP System
5

• The Computational Viewpoint describes the
  functionality of the ODP system and its
  environment through the decomposition of the
  system into objects which interact at interfaces
  in a distribution transparent manner

Motivation The Computational Viewpoint
6

• Computational objects and interfaces are usually
  specified by Computational Object Templates and
  Computational Interface Templates ()
• Binding Objects are computational objects which
  support a binding between a set of other
  computational objects.
• A computational interface template comprises
• an interface signature
• a behaviour specification
• an environment contract

Motivation The Computational Viewpoint
() A Template is the specification of
the common features of a collection of ltXgts in
sufficient detail that an ltXgt can
instantiated using it.
7

• A Computational Specification describes the
  functional decomposition of an ODP system, in
  distribution transparent terms, as
• Configuration of computational objects
• Internal actions of those objects
• Interactions among those objects
• Environment contracts

Computational Viewpoint Specifications
8
CV Metamodel

• METAMODEL

The Computational Viewpoint
9

• ODP Viewpoint languages are abstract, i.e., ODP
  does not prescribe any particular notation for
  expressing Viewpoint specifications
• Without a concrete syntax
• it is difficult to write ODP specifications
• There is no tool support
• No analysis of the specifications (formal or
  informal)
• Formal methods are convenient/needed for enabling
• Precise, unambiguous, and abstract interpretation
  of ODP concepts and specifications
• The development of tools that support writing and
  analyzing ODP specifications
• but traditionally useless

Motivation
10

• Formal notation (and system) that supports
  equational and rewriting logic specification and
  programming
• Supports OO specifications and computations
• Classes class C a1 S1, ., an Sn
• Objects lt O C a1 v1, ., an vn gt
• Messages msg m S1 Sn -gt Msg .
• A configuration is a multiset of objects and
  messages that evolves by rewriting rules
• crl r M1, Mm
• lt O1 C1 atts1 gt lt On Cn attsn gt
• gt
• lt Oi1 C1 attsi1 gt lt Oin Cn
  attsin gt
• lt Q1 C1 atts1 gt lt Qp Cp
  attsp gt
• M1 Mq
• if Cond .

Maude
11

• A simple example
• class Account balance Int .
• msg deposit Oid Int -gt Msg .
• msg transfer Oid Oid Int -gt Msg .
• crl 1 lt O Account balance N gt
• deposit(O,M)
• gt lt O Account balance N M gt
• if M gt 0 .
• crl 2 lt A Account balance N gt
• lt B Account balance M gt
• transfer(A,B,X)
• gt lt A Account balance N -X gt
• lt B Account balance M X gt
• if X lt M .

Maude
12
Mappings
ODP concept Maude concept
Computational object template Maude class (inheriting from CV-Object)
Computational object Maude object
Computational object configuration Maude Configuration
Binding object Maude object
Signals Maude messages
Operations and Flows In terms of signals
Computational interfaces Maude object (inheriting from class CV-Interface)
Behaviour specification Rewrite rules
Environment contracts a) Guards on rewrite rules b) Invariants
Modeling the CV in Maude
13
CV Infrastructure (I)
Modeling the CV in Maude

• An abstract platform (CV-Infrastructure) provides
  the basic concepts and mechanisms defined in the
  ODP Computational Viewpoint

• Two basic classes CV-Object and CV-Interface.

class CV-Object conf Configuration . class
CV-Interface uniqueId Oid, objectRole
Causality, bind Oid, input
Configuration, output Configuration .
14
CV Infrastructure (and II)

• The CV Infrastructure also provides some
  predefined operations to Maude objects
  representing computational objects

Modeling the CV in Maude

• Initiate signal (message M) at interface I
• send(I, M)

• Signal (message M) from object O at I received
  at local interface I
• receive(O, I, I, M)

• Instantiate computational interface template
• instantiateInterface(..)

• Instantiate computational object template
• instantiateObject(..)

• Create binding from interface I to I and destroy
  a binding in I
• bind(I, I)
• unBind(I)

• Use Trading Function to search for an interface
• lookup(UID, IFClass, O)
• lookupResponse(UID, IFClass, O, I)

15
Description

• A multimedia system composed by listeners who
  want to receive audio frames from an audio
  streamer (i.e. Internet radio station).
• A binding object manages the multicast of audio
  frames from a audio streamer to its registered
  listeners. It control QoS parameters.
• A service manager object de-/registers and
  manages the listener selections.

Example
16
Formalizing Objects and Interfaces

• The Maude specification same as the CV
  specification is divided into three parts
• Computational templates
• Behaviour specifications
• Initial configuration
• Maude modules provide the mechanisms to support
  them
• An example of a computational interface template
  is

Example
(omod IAUDIOCHANNEL-TEMPLATE is pr CV-INTERFACE
. class IAudioChannel . subclass IAudioChannel
lt CV-Interface . msg selectAudioStreamer Qid
-gt Msg . msg selectAudioStreamerResponse Qid
Oid -gt Msg . msg selectAudioStreamerFailure
Qid -gt Msg . endom)
17
Formalizing Behaviour

• For each computational object, we specify (in
  terms of Maude rules) how interactions are
  achieved and how the system evolves

Example
crl selectAudioStreamer-failure lt O
ServiceMgr streams PF, conf (
receive(O, I, I, selectAudioStreamer(Q))
lt I IAudioChannel bind BO, objectRole
server, uniqueId IAudioChannel gt
CONF ) gt gt lt O ServiceMgr conf (
send(I, selectAudioStreamerFailure(Q)) lt I
IAudioChannel gt CONF ) gt if BO / nil
and search(PF, Q) null .
Only if the binding is established and the
service manager does not know anything about
channel Q
18
Why should we?
19
Reasoning about the system

• We can (model)check whether a given predicate
  will hold for the system
• Maudegt (mc initState t
• gt duplicatedFrame in time lt 1000 .)
• Result Bool
• true
• Maudegt (mc initState t
• gt unOrderedFrame in time lt 1000 .)
• Result ModelCheckResult
• counterexample( )
• Maudegt (mc initState t
• gt ltgt allFramesArrive with no time limit .)
• Result Bool
• true

Examples
20
Conclusions

• Maude seems to be a good alternative for
  specifying the ODP CV
• More expressive than other formal languages
  (Z,Object-Z)
• Executable specifications
• Counts with a Toolkit for formal analysis of
  systems

• It is verbose and not very appealing, though.

Our plans now

• Use Maude to support (i.e., provide some
  semantics for) other graphical notations that can
  be more sexy for specifying ODP systems (e.g.
  UML!)
• Make the Maude toolkit available from a UML
  environment
• Prototyping of UML specs of ODP systems
• Model checking of UML specs of ODP systems

Tool Support for ODP!
21
Thanks!
Raúl Romero and Antonio Vallecillo Dpto.
Lenguajes y Ciencias de la Computación Universidad
de Málaga, Spain jrromero, av_at_lcc.uma.es
EDOC 2004