Formalizing ODP Computational Viewpoint Specification in Maude

1. Formalizing ODP Computational Viewpoint Specification in Maude 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

2. Motivation • The ODP Computational Viewpoint • Maude • Writing CV specifications in Maude • An example • Conclusions Contents

3. 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! • 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. Enterprise Information Technology Computation Engineering 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 behaviourspecification • an environment contract Motivation: The Computational Viewpoint (*) “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”.

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

11. A simple example classAccount | balance : Int . msgdeposit : Oid Int -> Msg . msgtransfer : Oid Oid Int -> Msg . crl [1] : < O : Account | balance : N > deposit(O,M) =>< O : Account | balance : N + M > ifM > 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 > ifX <= M . Maude

12. Mappings 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 audioframes 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 < CV-Interface . msg selectAudioStreamer : Qid -> Msg . msg selectAudioStreamerResponse : Qid Oid -> Msg . msg selectAudioStreamerFailure : Qid -> Msg . endom)

17. A listener requests its service manager to select the channel defined by parameter Q A failure indication is returned to the listener 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]: < 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 . Only if the binding is established and the service manager does not know anything about channel Q

18. Advantages of Maude • 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 Why should we?

19. Reasoning about the system • 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 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}@lcc.uma.es EDOC 2004