On the Concurrent Object Model of UML *

Transcription

1 On the Concurrent Object Model of UML * Iulian Ober, Ileana Stan INPT-ENSEEIHT, 2, rue Camichel, Toulouse, France Phone (+33) , Fax (+33) {iulian.ober, ileana.stan}@enseeiht.fr Abstract. Designing object models with concurrency features was a preoccupation of numerous researchers for the past two decades. UML, the standard object-oriented modeling language adopted by the OMG, does not tackle the issues of concurrency in its object model in a systematic way. In this paper we outline the position of the UML object model within the design space of concurrent object models described in [10], discuss the inconsistencies in the UML semantics and finally propose an object model, comprising features from UML and ATOM a state-of-the-art concurrent object model. 1 Introduction The problem of integrating the object-oriented concepts and concurrency concepts has been a preoccupation of many researchers for the past two decades. Several concurrent object-oriented languages and models were developed [2,3,5,8,9,11,14,15] and there was research work put into analyzing and classifying them [7,10]. On the other hand, UML [1,13,17] is the standard object-oriented modeling language adopted by the Object Management Group and is becoming the de-facto standard support for object-oriented analysis and design. This paper aims to give a clear idea about the concurrency features that exist in the adopted version of UML [17]. In order to do so, we proceed in a systematic fashion, using the classification of concurrent object models described in [10] and outlined in section 2. From this perspective, in the third section we try to determine the position of UML and outline the weak points of the semantics of certain concurrency features of UML. Finally, in section 4 we describe a fully-functional object model that we have developed, which presents the same facilities as UML, notably state machines, but unambiguously integrates them with the concurrency features of a complex concurrent object model, ATOM, defined in [11,12]. The intended auditory of this paper is both the UML community, since the modeling of concurrency in UML seems not to enjoy the same level of attention as do other features of the language, and the concurrent object-oriented programming community since UML has an ever increasing importance in the spectrum of object-oriented modeling languages. * work supported by CS VERILOG,

2 2 Classification of Concurrent Object Models A well known classification of concurrent object models is given by Papathomas in the chapter 3 of [10]. It uses three dimensions. On the first dimension, object models are divided with respect to what combination of objects they support, into three categories: orthogonal (objects are independent of threads), homogenous (all objects are active), heterogeneous (objects may be active or passive). The second dimension captures the internal concurrency of objects: internally sequential, quasi-concurrent or concurrent. Finally, the third dimension captures the available inter-object communication and synchronization mechanisms: synchronous/asynchronous feature calls, conditional/unconditional acceptance of incoming calls, etc. For details on the classification criteria, the reader is referred to the original work [10]. In the next section we will use this classification for systematically analyzing the facilities of the UML concurrent object model. 3 The Concurrency Features of the UML Object Model Our goal in this section is not to explain in detail the semantics of the UML concepts that we are interested in. We rather outline the modeling of concurrency features and the related anomalies. Therefore, understanding this section may require some general knowledge about the main concepts of the UML meta-model and semantics, like Class, Operation, Method, Action, StateMachine, Event. UML is a modeling language thought to be used for analysis, design and documentation rather than implementation. Its designers wanted it as general as possible. However, some decisions that have been taken in its definition, decisions conforming to the cultures from which UML emerged (OMT, Booch, Objectory, etc.), restrict its area of application. For example, it would be hard model a highly reflective CLOS architecture in UML, simply because UML does not have a meta-class concept. Correspondingly, if UML wants to conform to all possible models of concurrency, it will have to resign form describing its own model. But as soon as it describes such a model for concurrency, it should do that in a coherent and complete way. This is why we allow ourselves to study the inconsistencies in the concurrent object model of UML and to propose an alternative solution. The modeling of concurrency is spread across the UML specification [17], for each concept that is involved in it (Class, Operation, Action and StateMachine). In what follows, we will try to group this information, discuss it and infer the implications with respect to the position of UML in the design space sketched in section Active and passive objects Classes in UML may be either active or passive, as described by the attribute isactive of the meta-model class Class ([17a] pp. 16): "specifies whether an Object of the Class maintains its own thread of control and runs concurrently with other active Ob-

3 jects. If false, then the Operations run in the address space and under the control of the active Object that controls the caller" ([17a] pp. 21). Therefore the model is heterogeneous. An UML active object has only one thread of control, so active objects are internally sequential. However, the UML semantics says nothing about the situation when multiple concurrent calls are made to the same active object (except for the case when the object has a state machine, case that we will see in more detail later). As only one message may be treated at a time, there will have to exist some mechanism for queuing the calls. Whether this queuing mechanism exists or how it acts, it is not said in [17a]. In the case of passive objects, each Operation is either sequential, guarded or concurrent, according to the concurrency attribute of the meta-model class Operation ([17a pp. 26]). For a certain passive object, only one sequential operation may be active at a time, but this is not enforced by the model. Guarded operations are also mutually exclusive, but they are protected by the model against concurrent calls. Finally, concurrent operations may be called concurrently at any time. We note that the meaning of active/passive is not entirely the same as in [10]: the passive objects still have a degree of control over the invocations made towards them. This statement is further supported by the semantics of state machines. 3.2 Messages The object interaction mechanisms in UML are messages and signals. Signals are discussed together with state machines in the next section. The action of passing a message is called CallAction in the UML meta-model. CallAction has an attribute mode ([17a] pp. 67,69) that may specify either "synchronous" or "asynchronous". Thus, in terms of our classification, the communication means offered by the UML object model are one-way message passing and RPC. An UML synchronous call is what the classification calls a (blocking) RPC. An asynchronous call is what we call one-way message passing since there are no mechanisms for the caller to synchronize with the end of execution of the called method and to retrieve the result. UML does not specify constraints with respect to the target of an asynchronous call. This is problematic, since passive objects execute their methods on the calling thread, if the calling thread "does not wait for the completion of the execution of the Operation but continues immediately", the called operation will have no thread left to execute on. 3.3 State machines The UML object model is different from any other object model studied in connection with the issues of concurrency, in that the behavior of an object in UML may also be specified entirely or partially through a statechart ([17a] pp. 97). According to [17a], if an object has a state machine then all the requests sent to the object pass through its state-machine, whether they are signals or method calls. State machines in UML respond to both SingalEvents and CallEvents. The state machine

4 processes events in a sequential way so that all events are processed following a queuing policy, even if they are method calls. One thing that is not clear in [17a] is whether the methods of an object are executed by its state machine or the state machine is manipulated by the methods. For both active and passive objects, the state machine can respond to a CallEvent either by invoking the corresponding operation, by performing some other actions or by doing nothing. Although slightly unusual, this is a powerful feature that makes it possible to express request scheduling policies through state machines. One problem is that UML does not define a notation to distinguish between the three cases above. Another problem that persists, despite the fact that passive objects with state machines go a long way back in the OOA&D, is that state machines are primarily designed to respond to asynchronous stimuli like Signals. Or a passive object cannot respond to such stimuli, not having its own thread of control. 3.4 UML position in the design space of concurrent object models The following table summarizes the conclusions we have drawn about the position of UML in the design space of concurrent object models as systematized in [10]: The position of UML within the design space of concurrent object models is quite clear, despite the leaks in the specification that we saw in the earlier sections. Besides these leaks, there are some drawbacks in the approach taken by UML towards concurrency, among which: active objects are sequential request scheduling policies can be expressed only using statecharts, which makes it difficult to express very simple activation conditions and is prone to inheritance anomalies (especially since statechart inheritance is not formally defined in UML). asynchronous request-reply communication is not supported natively A careful designer can avoid all these anomalies and UML is already used on a large industrial scale. Still, a cleaner semantics and more powerful primitives are desirable. It is not our goal to define a semantics in this paper, but merely to suggest improvements and clarifications to the model.

5 4 The ATOM-S Object Model The drawbacks of the UML object model drove us in the research of a better combination of a concurrent object model and state machines. The result is the ATOM-S object model. Similar efforts are described in [4,16]. The essential difference is that we start from a concurrent object model, ATOM [11,12], proven to solve many of the classical problems of object-oriented concurrency, such as inheritance anomalies [14]. Our proposal represents an extension of UML. This requires to correct the anomalies that exist in UML and to use the UML extension mechanisms (stereotypes and tagged values) to model the concepts added by ATOM-S. We have implemented a fully functional prototype of this model in the Python [18] programming language. 4.1 Basic notions of ATOM This section is a brief presentation of ATOM and may be skipped by the readers familiar with it. More details on ATOM can be found in [11,12]. ATOM has only quasi-concurrent active objects. [11] presents this choice as a good compromise between expression power and protection of the integrity against concurrent calls. Active objects communicate through two-ways (request-reply) messages, which can be synchronous (blocking or non-blocking RPC) or asynchronous. For asynchronous messages ATOM uses advanced features for reply scheduling. An object can issue a requests towards another object and later retrieve the result or wait for this result to be produced. Delegation of the response by a method to another method is also possible and the reply is routed automatically to the initial requester. Request scheduling is based on activation conditions. A specific mechanism associates actions to specific events, so one can write an action to be executed when a method call is received, when the execution begins or when it ends. [11] shows that this feature solves certain inheritance anomalies. ATOM introduces the notion of abstract state, denoting a named predicate over the attributes of an object used to describe activation conditions. Abstract states are used for coordinating a set of objects. Each object has a notifier service, to which another object can subscribe, to be announced when the object reaches a certain state. 4.2 ATOM-S ATOM-S does not make modifications to the features of ATOM, instead it makes an essential extension by integrating state machines. ATOM-S uses passive objects, because they exist in UML and they may be necessary when all the active object overhead is not needed. Passive objects do not own threads of control, but execute their methods on the caller threads. Therefore they can not respond to asynchronous calls and, unlike in UML, they cannot have a state machine. This difference is justified by the fact that state machines should be used to describe the response of objects to asynchronous signals. This also solves the issue raised in the end of section 3.3.

6 1 class ThreadScheduler (ActiveObjectSupport): 2 methods = [ InsertThread, Schedule, EndThread, AlertAdmin, RecoveryProc ] 3 events = [ Recover ] 4 conditions = { 5 InsertThread : not self.instate( Overloaded ) 6 Schedule : not self.instate( Overloaded ) 7 } 8 def InsertThread(self, thread, priority): 9 """... the bodies of the methods are omitted""" 10 statechart = { Normal HQGB,QVHUW7KUHDG>VHOI/RDG@ Alerted UHFYB,QVHUW7KUHDG >VHOI/RDG@ VHOI$OHUW$GPLQ 5HFRYHUVHOI$OHUW$GPLQ VHOI5HFRYHU\3URF Overloaded UHFYB,QVHUW7KUHDG VHOIUHFHLYH(YHQW5HFRYHU } Fig. 1. A simple thread scheduler class in ATOM-S As in UML, the methods of a passive object can be: sequential (raise an exception when called concurrently), guarded (mutually exclusive and protected through semaphores) and concurrent (not protected and free to be called concurrently). In ATOM-S active objects are quasi-concurrent. This represents an extension of the UML internally sequential model: an executing method can explicitly yield the control for example while it is waiting for a return from another object. ATOM-S uses all the communication and synchronization mechanisms of ATOM. To exemplify the features of ATOM-S, we use a simple example: a thread scheduler class whose code is partially given in Fig. 1 (the bodies of the methods are omitted). The example is written in our extension of Python, except for the statechart, which has a Python form but it is more readable in a graphic Statechart [4] format. Besides attributes and methods, an active object may have a state machine that specifies the reactive part of its behavior and responds to asynchronous one-way stimuli, called signals, that may carry parameters. The signals to which a class responds are part of the class signature, just like the methods (Fig. 1 line 3). As in UML, the state machine may specify the complete behavior of an object or only its protocol, case in which its states are used as activation conditions for the object methods. In Fig.1 the activation conditions of InsertThread and Schedule

7 are based on state machine: the methods cannot execute while the object is in the Overloaded state (lines 5,6). To solve the ambiguity that exists in UML about the way CallEvents are processed (see section 3.3), method invocations sent towards an object do not pass through its state machine and only signals are queued and processed one-by-one by the machine. Thus, a method invocation will always result in the execution of the method. The operational semantics of state machines in ATOM-S is based on the fact that the state machine of an active object runs quasi-concurrently with its methods. At object creation time a default thread is created to manage the state machine (if there is a machine). This thread keeps track of the current state of the machine, retrieves signals from the queue and executes the transitions and actions of the state machine. Depending on a priority policy chosen for the object, the state machine thread may yield the control between the processing of consecutive events or only when the event queue is empty. The state machine of an object is notified when a message call is received, when a method starts executing or finishes. Note that, like in ATOM, the moment when the method is received may not coincide with the moment when it starts executing. The following signals are sent by default by the underlying model to the state machine: (when the method is called on that object), (when the method starts executing) and (when the method ends its execution). The introduction of these implicit messages augments the power of expressing request scheduling policies through the state machine in the same way the receipt, pre- and post-actions augment the power of expression of ATOM activation conditions (see [11]). In Fig.1 these implicit signals recv_insertthread and end_insertthread trigger transitions in the state machine. Our model clarifies the relationship between the operations of a class and its statechart, which is vague in UML. As an extension of the ATOM model, the ATOM-S solves the classical problems of concurrency. In addition, it has the expressing power of statecharts and means for combining the two ways of modeling behavior. 5 Conclusions The substantial research work that has been done in the field of concurrent objectoriented programming, although scientifically recognized, has a long way ahead towards the integration in industrial standards, languages and environments. On the other side, UML, which is a popular standard language for analysis, design and documentation, has largely ignored the problem of concurrency in its model. It is therefore an open door through which research results in concurrent object oriented programming languages can penetrate to the industrial world. This paper is only the beginning of a process of correcting the problems and identifying general solutions for the integration of concurrency in UML. We have pointed out some weaknesses of UML face to concurrency. To overpass these problems we have presented in the fourth section a concurrent model, which can be regarded either as an extension of UML or as a design pattern. The model we developed has about the

8 same power of expression as UML. It benefits from the results of research in concurrent object oriented programming, embodied in the ATOM model, and takes an approach as close to UML as possible and does it in a clean, unambiguous way. The prototype that we developed (freely available from the authors of this paper) is an extensible tool, that can be used for experimenting with our model as well as with other variations on this theme. References 1. Booch, G., Jacobson, I., Rumbaugh, J.: The Unified Modeling Language User Guide. Addison-Wesley, (1998) 2. Caromel, D: Towards a Method of Object Oriented Concurrent Programming, Communications of the ACM, vol. 36, no. 9, pp , (1993) 3. Gehani, D., Roome, W.D: The Concurrent C Programming Language, Prentice Hall Harel, D., Gery, E.: Executable Object Modeling with Statecharts IEEE Computer July, pp.31-42, (1997) 5. Kafura, D.G., Lee, K.H.: Inheritance in Actor based concurrent object-oriented languages Proceedings of ECOOP 89, pag , Cambridge University Press (1989) 6. Matsuoka, S., Watanabe, T., Yonezawa, A.: Hybrid group reflective architecture for object-oriented languages Proceedings of ECOOP/OOPSLA 90 Workshop on Reflection and Metalevel Architectures in Object Oriented Programming, (1990) 7. Matsuoka, S., Yonezawa, A.: Analysis of inheritance anomaly in OO concurrent programming language, Research directions in Concurrent OO programming, MIT Press, (Ed. G.Agha, P.Wegner, A.Yonezawa), pg , (1993) 8. Meyer, B.: Object Oriented software construction, Second edition, Prentice Hall, (1997) 9. Nierstrasz, O.: Active Objects in Hybrid. Proc OOPSLA 87, SIGPLAN Notices v.22, no. 12, pp , (1987) 10. Papathomas, M.: Language Design Rationale and Semantic Framework for Concurrent Object-Oriented Programming. PhD Thesis. Université de Genève, (1992) 11. Papathomas, M.: ATOM: An Active Object Model for Enhancing Reuse in the Development of Concurrent Software, RR 963-I-LSR-2, LSR-IMAG, Grenoble, (1996) 12. Papathomas, M., Andersen, A.: Concurrent Object Oriented Programming in Python with ATOM 1st Conference on Python, (1996) 13. Rumbaugh, J., Jacobson, I., Booch, G.: The Unified Modeling Language Reference Manual., Addison-Wesley, (1998) 14. Yonezawa, A.: ABCL: An Object-Oriented Concurrent System. Computer Systems Series. Ed. Akinori Yonezawa, MIT Press (1990) 15. Tomlinson, V. Singh: Inheritance and synchronization with Enabled-Sets. Proceedings of OOPSLA'89, ACM Press, October (1989) 16. Selic, B.: "An Efficient Object-Oriented Variation of the Statecharts Formalism for Distributed Real-Time Systems", Paper submitted to CHDL '93: IFIP Conference on Hardware Description Languages and Their Applications, April 26-28, 1993, Ottawa, Canada. 17. UML Proposal to the OMG, OMG documents ad/ to ad/ a. UML Semantics, OMG document ad/ The Python Language website: