Object-oriented specification of reactive systems

Järvinen, Hannu-Matti; Kurki-Suonio, Reino; Sakkinen, Markku; Systä, Kari

doi:10.1109/icse.1990.63604

Cited by 56 publications

(21 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Multi-methods [16] in CLOS, the object system based on LISP [15], define multi-polymorphic methods that are selected not only based on the receiver but on all parameters and as such can be used to define coordinated behavior of a set of objects of predetermined types. Schrefl et al [24] introduce the notion of cooperation contracts in the context of object-oriented databases and [14] define joint actions. All three approaches model coordinated behavior of a group of objects as a separate entity that can be explicitly invoked for a matching set of objects.…”

Section: Related Workmentioning

confidence: 99%

Object acquaintance selection and binding

Bosch¹

1998

Theory Pract. Obj. Syst.

View full text Add to dashboard Cite

Large object-oriented systems have, at least, four characteristics that complicate object communication, i.e the system is distributed and contains large numbers, e.g. thousands, of objects, objects need to be reallocated at run-time and objects can be replaced by other objects in order to adapt to the dynamic changes in the system. Traditional object communication is based on sending a message to a receiver object known to the sender of the message. At linking or instantiation time, an object establishes its acquaintances through name/class based binding and uses these objects through its life time. If this is too rigid, the software engineer has to implement the binding of objects manually using pointers. In our experiments we found the traditional acquaintance communication semantics too limited and we identified several problems, related to the reusability of objects and selection mechanisms, understandability and expressiveness. We recognised that it is important to separate an class or object's requirements on its acquaintances from the way an object selects and binds its acquaintances in actual systems. Based on this, we studied the necessary expressiveness for acquaintance handling and identified four relevant aspects: type and duration of binding, conditions for binding, number of selected objects and selection region for binding. To implement these aspects, we defined acquaintance layers as part of the layered object model. Acquaintance layers uniformly extend the traditional object-oriented acquaintance handling semantics and allow for the first-class representation of acquaintance selection and binding, thereby increasing traceability and reusability.

show abstract

Section: Related Workmentioning

confidence: 99%

Object acquaintance selection and binding

Bosch¹

1998

Theory Pract. Obj. Syst.

View full text Add to dashboard Cite

show abstract

“…Formally, the encapsulation of activities resembles the work of Kellomäkki and Mikkonen [36], who use the DisCo language [37] to capture specifications that are reusable solutions to problems. To reuse solutions in an application, they show that it suffices to integrate a more abstract template, and that properties proven for the solution are maintained when the template is applied.…”

Section: Related Workmentioning

confidence: 99%

Automated Encapsulation of UML Activities for Incremental Development and Verification

Kraemer

Herrmann

2009

Model Driven Engineering Languages and Systems

View full text Add to dashboard Cite

Abstract.With their revision in the UML 2.x standard, activities have been extended with streaming parameters. This facilitates a reuse-oriented specification style, in which dedicated functions can be contributed by self-contained activities as building blocks: Using streaming parameters, activities can be composed together in a quite powerful manner, since streaming parameters may also pass information while activities are executing. However, to compose them correctly, we must know in which sequence an activity may emit or accept these streaming parameters. Therefore, we propose special UML state machines that specify the externally visible behavior of activities. Further, we develop an algorithm to construct these state machines automatically for an activity based on model checking. Using these behavioral contracts, activities can then be composed without looking at their internal details. Moreover, the contracts can be used during system verification to reduce the complexity of the analysis.

show abstract

“…For example, in [24] patterns are defined by using the object-oriented specification language DISCO [10]. These approaches basically take the informal description of a pattern, as given in e.g.…”

Section: Related Workmentioning

confidence: 99%

(Behavioural) Design Patterns as Composition Operators

Lau

Ntalamagkas

Tran

et al. 2010

Component-Based Software Engineering

View full text Add to dashboard Cite

Abstract. Design patterns are typically defined informally, albeit in a standard format, and have to be programmed by the software designer into each new application. Thus although patterns support solution reuse, in practice this does not translate into code reuse. In this paper we argue that to achieve code reuse, patterns should be defined and used in the context of software component models. We show how in such a model, behavioural patterns can be defined as composition operators which can be stored in a repository, alongside components, thus enabling code reuse.

show abstract

Object-oriented specification of reactive systems

Cited by 56 publications

References 23 publications

Object acquaintance selection and binding

Object acquaintance selection and binding

Automated Encapsulation of UML Activities for Incremental Development and Verification

(Behavioural) Design Patterns as Composition Operators

Contact Info

Product

Resources

About