FRINK Linked Data Fragments server

Matches in SemOpenAlex for { <https://semopenalex.org/work/W2104958275> ?p ?o ?g. }

• W2104958275 abstract "The object-oriented style of programming (OOP) is gaining increasing importance as a practical technique for organizing large designs and programs. Another striking aspect of OOP is its potential for concurrent and distributed applications which is based on the fact that objects may coexist in time and concurrently may exchange information by message passing. Up to now, however, there is only little progress in the development of formal computation models that exploit the full power of concurrency inherent in the OOP paradigm. (One of the few exceptions is the actor model [1].) As a consequence, there are not many OOP languages such as POOL [2] or Trellis/Owl [7] that provide mechanisms allowing the designer to keep control of how objects are dynamically created, how they interact in a distributed environment, and how objects can be allocated on a network of processors.Our Model. We propose a model of concurrent objects that integrates ideas from three different research areas to cope with what we think is the substance of the object-oriented paradigm: 1) Cardelli's work on a formal semantics of multiple inheritance [3] influenced our way of thinking about object decomposition and inheritance relationships between them; in particular, we adopt his idea to base the decomposition of objects on labeled Cartesian products and disjoint sums. 2) The algebraic foundation of abstract data types provides a representation independent notion of data structures and encapsulation concepts. 3) To support a notion of distributed state and concurrent state changes, we use high level Petri nets. They describe dynamic behavior of concurrent systems in a way that is at the same time formal and visual. It is easy to see that record and variant type constructors can be handled in an algebraic framework, if taking some care of variants. Moreover, in [5] and [6] we have shown that algebraic and Petri net based specification techniques can be unified in a conceptually and semantically coherent framework.In the sequel we give two examples to explain this combination of concepts. Similar to [4], we distinguish between functions to denote object attributes and methods to denote state changing operations: we use Cardelli's notation of variants and records, and an intuitive notation for signatures and conditional axioms. We allow methods to operate concurrently on an object's attributes, provided that they do not share any attribute of that object. Variant objects. Variants are taken to model sequential objects. The disjoint cases of a variant are used to describe the set of distinct states in which a variant object can be observed. All methods defined on a variant object mutually exclude each other and affect a specific state transition. For example, the simple object module SENDER specified below might form a component in the specification of an alternating bit protocol: The axioms both specify constraints to the applicability of methods and the effect a method invocation has on the state of an instance. For example, method get-ack is only applicable if an instance, say S, is in the state labeled snt: the effect of get-ack either is that S is in state ack (in which a new message can be accepted) or in state rdy (in which the old message is to be resent). Like Cardelli, we assume basic operations as-L to extract the contents of a variant object with a particular label L.In place of the axioms, we better could have used high level Petri nets1 to visualize the dynamic behavior of sender objects: Remark: The dependency between the control bits B, B' and the label L involved in method get-ack must be specified by an axiom. The new method is omitted. Record objects. More interesting behavioral aspects are associated with record objects as we view their attributes as potential candidates for concurrent manipulation. To achieve this, we conceptually treat record objects as distributed data structures by splitting them along their decomposition in attributes. For each method we have to indicate which attributes it needs to access. Then, concurrency arises when methods access different attributes of a particular object.In the specification below we discuss some aspects of a host in a communications network. It is composed of different, partly independent subsystems such as a server providing diverse client services, input and output buffers to store incoming and outgoing messages, a sender, and a receiver which are responsible message transmission to other hosts. For simplification we give meaning only to a few of the conceivable methods. Discussion. The above Petri net reflects the behavioral concepts we are interested in as follows: 1) Independently accessible local data appear as distinct data tokens: 2) mutual exclusion between methods is manifested in terms of conflicting accesses to such tokens: 3) sequential dependencies are expressed by a producer-consumer relationship w.r.t. particular tokens (cf. the previous example); 4) concurrency arises when methods access different tokens; and (what has not been shown) 5) object interaction is expressed as participation in common method invocations. Conclusions. The underlying theory of Petri nets offers concepts for reasoning about lifeness and safeness of a behavior specification and provides an appropriate notion of nonsequential observations of method executions while many-sorted partial algebras provide a precise meaning of the local data operated on. Inheritance mechanism have not been discussed here as we are not yet sure whether our initial ideas to extend Cardelli's structural approach to behavior specifications really will hold." @default.
• W2104958275 created "2016-06-24" @default.
• W2104958275 creator A5004271647 @default.
• W2104958275 date "1988-01-01" @default.
• W2104958275 modified "2023-09-26" @default.
• W2104958275 title "Specifying concurrent objects" @default.
• W2104958275 cites W1561510341 @default.
• W2104958275 cites W2008593634 @default.
• W2104958275 cites W2010444348 @default.
• W2104958275 cites W2015910045 @default.
• W2104958275 cites W2132532613 @default.
• W2104958275 cites W2686043342 @default.
• W2104958275 doi "https://doi.org/10.1145/67386.67432" @default.
• W2104958275 hasPublicationYear "1988" @default.
• W2104958275 type Work @default.
• W2104958275 sameAs 2104958275 @default.
• W2104958275 citedByCount "1" @default.
• W2104958275 crossrefType "proceedings-article" @default.
• W2104958275 hasAuthorship W2104958275A5004271647 @default.
• W2104958275 hasConcept C120314980 @default.
• W2104958275 hasConcept C150495011 @default.
• W2104958275 hasConcept C184337299 @default.
• W2104958275 hasConcept C193702766 @default.
• W2104958275 hasConcept C199360897 @default.
• W2104958275 hasConcept C200568363 @default.
• W2104958275 hasConcept C38677869 @default.
• W2104958275 hasConcept C41008148 @default.
• W2104958275 hasConcept C49312422 @default.
• W2104958275 hasConcept C73752529 @default.
• W2104958275 hasConcept C80444323 @default.
• W2104958275 hasConcept C81192388 @default.
• W2104958275 hasConceptScore W2104958275C120314980 @default.
• W2104958275 hasConceptScore W2104958275C150495011 @default.
• W2104958275 hasConceptScore W2104958275C184337299 @default.
• W2104958275 hasConceptScore W2104958275C193702766 @default.
• W2104958275 hasConceptScore W2104958275C199360897 @default.
• W2104958275 hasConceptScore W2104958275C200568363 @default.
• W2104958275 hasConceptScore W2104958275C38677869 @default.
• W2104958275 hasConceptScore W2104958275C41008148 @default.
• W2104958275 hasConceptScore W2104958275C49312422 @default.
• W2104958275 hasConceptScore W2104958275C73752529 @default.
• W2104958275 hasConceptScore W2104958275C80444323 @default.
• W2104958275 hasConceptScore W2104958275C81192388 @default.
• W2104958275 hasLocation W21049582751 @default.
• W2104958275 hasOpenAccess W2104958275 @default.
• W2104958275 hasPrimaryLocation W21049582751 @default.
• W2104958275 hasRelatedWork W1491765830 @default.
• W2104958275 hasRelatedWork W1493627728 @default.
• W2104958275 hasRelatedWork W1521375736 @default.
• W2104958275 hasRelatedWork W1529068879 @default.
• W2104958275 hasRelatedWork W1558552339 @default.
• W2104958275 hasRelatedWork W1581141438 @default.
• W2104958275 hasRelatedWork W1597642018 @default.
• W2104958275 hasRelatedWork W1828820590 @default.
• W2104958275 hasRelatedWork W1954776415 @default.
• W2104958275 hasRelatedWork W2008492266 @default.
• W2104958275 hasRelatedWork W2021519440 @default.
• W2104958275 hasRelatedWork W2039139011 @default.
• W2104958275 hasRelatedWork W2051008498 @default.
• W2104958275 hasRelatedWork W2107318357 @default.
• W2104958275 hasRelatedWork W2119857670 @default.
• W2104958275 hasRelatedWork W2132186989 @default.
• W2104958275 hasRelatedWork W2313939972 @default.
• W2104958275 hasRelatedWork W2318907974 @default.
• W2104958275 hasRelatedWork W2473943433 @default.
• W2104958275 hasRelatedWork W2343199757 @default.
• W2104958275 isParatext "false" @default.
• W2104958275 isRetracted "false" @default.
• W2104958275 magId "2104958275" @default.
• W2104958275 workType "article" @default.