Formalizing ODP Computational Viewpoint
Specification in Maude
Raúl Romero and Antonio VallecilloRaúl Romero and Antonio Vallecillo
EDOC 2004
Dpto. Lenguajes y Ciencias de la ComputaciónDpto. Lenguajes y Ciencias de la ComputaciónUniversidad de Málaga, SpainUniversidad de Málaga, Spain
{jrromero, av}@lcc.uma.es{jrromero, av}@lcc.uma.es
Contents 1. Motivation
2. The ODP Computational Viewpoint
3. Maude
4. Writing CV specifications in Maude
5. An example
6. Conclusions
Motivation: RM-ODP
• 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
• Viewpoints
• Different abstractions of the same system
• Reflect different concerns
• Expressed in terms of specific viewpoint languages
• Powerful mechanism for dealing with the complexity of distributed systems!
Motivation: ODP
ViewpointsODPODPSystemSystem
EnterpriseEnterprise
ComputationComputation
InformationInformation
TechnologyTechnology
EngineeringEngineering
Motivation: The
Computational
Viewpoint
• 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
• 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
(*) “A Template is the specification of the common features of a collection of <X>s in sufficient detail that an <X> can instantiated using it”.
Computational ViewpointSpecifications
• 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
The
Computational
Viewpoint
• [[ METAMODEL ]]
CV Metamodel
Motivation
• 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
Maude
• Formal notation (and system) that supports equational and rewriting l
ogic specification and programming
• Supports OO specifications and computations
• Classes: class C | a1 : S1, …., an : Sn
• Objects: < O : C | a1 : v1, …., an : vn >
• Messages: msg m : S1 … Sn -> Msg .
• A configuration is a multiset of objects and messages that evolves by
rewriting rules:
crl [r] : M1, …Mm
< O1 : C1 | atts1 > … < On : Cn | attsn >=> < Oi1 : C’1 | atts’i1 > …< Oin : C’n | atts’in > < Q1 : C1’’ | atts1’’ > …< Qp : C’’p | attsp’’ > M1’ … Mq’if Cond .
Maude
• A simple example
class Account | balance : Int .msg deposit : Oid Int -> Msg .msg transfer : Oid Oid Int -> Msg .
crl [1] : < O : Account | balance : N >deposit(O,M)
=> < O : Account | balance : N + M > if M > 0 .
crl [2] : < A : Account | balance : N > < B : Account | balance : M >transfer(A,B,X)
=> < A : Account | balance : N -X > < B : Account | balance : M + X >
if X <= M .
Modeling the CV in Maude
Mappings
ODP conceptODP concept Maude conceptMaude conceptComputational 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 rulesb) Invariants
Modeling the CV in Maude
• An abstract platform (CV-
Infrastructure) provides the basic
concepts and mechanisms
defined in the ODP Computational
Viewpoint
CV Infrastructure (I)
class CV-Object | conf : Configuration .
class CV-Interface | uniqueId : Oid,
objectRole : Causality, bind : Oid, input : Configuration, output : Configuration .
• Two basic classes: CV-Object and CV-Interface.
Modeling the CV in Maude
• The CV Infrastructure also provides some predefined operations to Maude objects representing computational objects:
CV Infrastructure (and II)
• 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(..)
• 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)
• Instantiate computational object template:
instantiateObject(..)
Example
• 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.
Description
Example
• The Maude specification — same as the CV specification
— is divided into three parts:1. Computational templates2. Behaviour specifications3. Initial configuration
• Maude modules provide the mechanisms to support
them
• An example of a computational interface template is:
Formalizing Objects and Interfaces
(omod IAUDIOCHANNEL-TEMPLATE ispr CV-INTERFACE .
class IAudioChannel .subclass IAudioChannel < CV-Interface .
msg selectAudioStreamer : Qid -> Msg .msg selectAudioStreamerResponse : Qid Oid -> Msg .msg selectAudioStreamerFailure : Qid -> Msg .
endom)
Example
• For each computational object, we specify (in terms
of Maude rules) how interactions are achieved and
how the system evolves
Formalizing Behaviour
crl [selectAudioStreamer-failure]: < O : ServiceMgr | streams : PF, conf : ( receive(O’, I’, I, selectAudioStreamer(Q))
< I : IAudioChannel | bind : BO,objectRole : server, uniqueId : ‘IAudioChannel >
CONF ) >=> < O : ServiceMgr | conf : ( send(I, selectAudioStreamerFailure(Q))
< I : IAudioChannel | > CONF ) >
if BO =/= nil and search(PF, Q) == null .
A failure indication is A failure indication is returned to the returned to the listenerlistener
A listener requests its A listener requests its service manager to service manager to select the channel select the channel defined by parameter defined by parameter QQ
Only if the binding is established and the service Only if the binding is established and the service manager does not know anything about channel manager does not know anything about channel QQ
Why should we?
• Maude is executable and counts with a toolkit that allows formal rea
soning of the specifications produced:
Run-time verification
Model checking
Monitoring
Theorem proving
etc…• We can see how the system behaves based on its specifications (m
ore than 3 million rewrites per second on standard PCs)
• We can check some properties of the system
• We can make the Maude specifications co-exist with partial implem
entations
Advantages of Maude
Examples
• We can (model)check whether a given predicate will hold for the system:
Maude> (mc initState |=t > [] ~ duplicatedFrame in time < 1000 .)Result Bool :
true
Maude> (mc initState |=t > [] ~ unOrderedFrame in time < 1000 .)Result ModelCheckResult :
counterexample( … )
Maude> (mc initState |=t > <> allFramesArrive with no time limit .)Result Bool :
true
Reasoning about the system
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• 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
• …
Our plans now
• It is verbose and not very appealing, though….
Tool Support for ODP!
Thanks!
Raúl Romero and Antonio VallecilloDpto. Lenguajes y Ciencias de la Computación
Universidad de Málaga, Spain{jrromero, av}@lcc.uma.es
EDOC 2004