1. Formalizing ODP Computational Viewpoint Specification in Maude Raúl Romero and Antonio Vallecillo EDOC 2004 Dpto. Lenguajes y Ciencias de la Computación Universidad de Málaga, Spain {jrromero, av}@lcc.uma.es

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

3. 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!

4. Motivation: ODP Viewpoints ODPSystem Enterprise Computation Information Technology Engineering

5. 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

6. 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 s in sufficient detail that an can instantiated using it”.

7. Computational Viewpoint Specifications 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

8. The Computational Viewpoint [[ METAMODEL ]] CV Metamodel

9. 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

10. Maude Formal notation (and system) that supports equational and rewriting logic specification and programming Supports OO specifications and computations Classes: class C | a 1 : S 1, …., a n : S n Objects: Messages: msg m : S 1 … S n -> Msg. A configuration is a multiset of objects and messages that evolves by rewriting rules: crl [r] : M 1, …M m … => … M 1 ’ … M q ’ if Cond.

11. Maude A simple example class Account | balance : Int. msg deposit : Oid Int -> Msg. msg transfer : Oid Oid Int -> Msg. crl [1] : deposit(O,M) => if M > 0. crl [2] : transfer(A,B,X) => if X <= M.

12. Modeling the CV in Maude Mappings ODP concept Maude concept Computational object templateMaude class (inheriting from CV-Object ) Computational objectMaude object Computational object configuration Maude Configuration Binding object Maude object Signals Maude messages Operations and FlowsIn terms of signals Computational interfaces Maude object (inheriting from class CV-Interface ) Behaviour specificationRewrite rules Environment contractsa) Guards on rewrite rules b) Invariants

13. 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.

14. 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(..)

15. 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

16. Example The Maude specification — same as the CV specification — is divided into three parts: 1.Computational templates 2.Behaviour specifications 3.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 is pr CV-INTERFACE. class IAudioChannel. subclass IAudioChannel < CV-Interface. msg selectAudioStreamer : Qid -> Msg. msg selectAudioStreamerResponse : Qid Oid -> Msg. msg selectAudioStreamerFailure : Qid -> Msg. endom)

17. 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)) CONF ) > if BO =/= nil and search(PF, Q) == null. A failure indication is returned to the listener A listener requests its service manager to select the channel defined by parameter Q Only if the binding is established and the service manager does not know anything about channel Q

18. Why should we? Maude is executable and counts with a toolkit that allows formal reasoning of the specifications produced:  Run-time verification  Model checking  Monitoring  Theorem proving  etc… We can see how the system behaves based on its specifications (more 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 implementations Advantages of Maude

19. 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

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 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!

21. Thanks! Raúl Romero and Antonio Vallecillo Dpto. Lenguajes y Ciencias de la Computación Universidad de Málaga, Spain {jrromero, av}@lcc.uma.es EDOC 2004