J. Object Technol.最新文献

{"title":"The Theory of Classification, Part 18: Polymorphism through the Looking Glass","authors":"A. Simons","doi":"10.5381/JOT.2005.4.4.C1","DOIUrl":"https://doi.org/10.5381/JOT.2005.4.4.C1","url":null,"abstract":"In this, the eighteenth article in a regular series on object-oriented type theory, we look at how object-oriented languages might evolve in the future, given that the formal notion of class is now better understood than at the outset. Object-oriented languages were the first family to suppose that there might be systematic sets of relationships between all the program data types and use this as the basis for a kind of type compatibility. However, the early formal models chosen were based on simple types and subtyping [1] and struggled in practice to support all the obvious, systematic relationships that programmers intuitively recognised [2]. For a while, objects were thought to have class and type independently, where class was demoted to a mere implementation construct. Later, it was realised that the notion of class is also a typeful construct that requires at least a bounded second-order λ-calculus model to explain it [3]. We have developed this model in the Theory of Classification, showing how it deals properly with typed inheritance [4, 5] and generic types [6] in a consistent framework.","PeriodicalId":383341,"journal":{"name":"J. Object Technol.","volume":"18 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2005-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123737175","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Reflection-based implementation of Java extensions: the double-dispatch use-case","authors":"R. Forax, É. Duris, G. Roussel","doi":"10.1145/1066677.1066996","DOIUrl":"https://doi.org/10.1145/1066677.1066996","url":null,"abstract":"Reflection-based libraries could sometimes be used to extend the expressive power of Java without modifying the language nor the virtual machine. In this paper, we present the advantages of this approach together with general guidelines allowing such implementations to be practicable. Then, we show how these principles have been applied to implement an efficient and general double-dispatch solution for Java.","PeriodicalId":383341,"journal":{"name":"J. Object Technol.","volume":"32 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2005-03-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121851606","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"The Theory of Classification, Part 17: Multiple Inheritance and the Resolution of Inheritance Conflicts","authors":"A. Simons","doi":"10.5381/jot.2005.4.2.c2","DOIUrl":"https://doi.org/10.5381/jot.2005.4.2.c2","url":null,"abstract":"The author considers the theoretical issues raised by combining multiple implementations. Then, he considers what it means for an object to belong to multiple parent classes, defining the notion of multiple classification.","PeriodicalId":383341,"journal":{"name":"J. Object Technol.","volume":"16 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2005-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132945497","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"The Theory of Classification Part 15: Mixins and the Superclass Interface","authors":"A. Simons","doi":"10.5381/jot.2004.3.10.c1","DOIUrl":"https://doi.org/10.5381/jot.2004.3.10.c1","url":null,"abstract":"The fundamental concepts of mixin, an object oriented language, are discussed. Intended to be combined with any other object, mixin is a freestanding record of extra fields. Mixins are also the primitive building blocks in languages with inheritence-like mechanisms. A mixin can be combined with many different base classes, to yield different extended classes which contain the combined base and mixing features. A mixin has a superclass interface, describing the kind of class from which it expects to inherit.","PeriodicalId":383341,"journal":{"name":"J. Object Technol.","volume":"21 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2004-11-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123128269","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Open Issues in Industrial Use Case Modeling","authors":"Gonzalo Génova, Juan Llorens Morillo, Pierre Metz, R. Prieto-Díaz, H. Astudillo","doi":"10.5381/jot.2005.4.6.a1","DOIUrl":"https://doi.org/10.5381/jot.2005.4.6.a1","url":null,"abstract":"Use Cases have achieved wide use as a specification tool for observable behavior of systems. However, there is still much controversy, inconsistent use, and free-flowing interpretations of use case models, in fact, not even experts widely recognized in the community agree on the semantics of concepts. Consequently, use case models are dangerously ambiguous, and there is an unnecessary divergence of practice. The purpose of the workshop was to identify and characterize some sources of ambiguity. It gathered specialists from academia and industry involved in modeling use cases to exchange ideas and proposals, with an eye to both clear definition and practical application. Some presented topics were discussed in-depth (the UML metamodel for use cases, use case instances, use cases in MDD/MDA, use case model vs. conceptual model, and tools for use cases specification), while others were left as open issues for future research. We hope our suggestions will be useful to improve the metamodel of use cases, and stimulate further research to reach a stronger coupling between the use case model and other static, behavioral and architectural models.","PeriodicalId":383341,"journal":{"name":"J. Object Technol.","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2004-10-11","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123510356","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"The Theory of Classification, Part 14: Modification and Objects like Myself","authors":"A. Simons","doi":"10.5381/jot.2004.3.8.c2","DOIUrl":"https://doi.org/10.5381/jot.2004.3.8.c2","url":null,"abstract":"The Theory of Classification to handle constructor-methods, through the use of which an object can create another object 'like itself', was discussed. It need implementations of List-methods like cons, heads and tail to manipulate the multimaps, which were essentially association lists with duplicate keys. A sequence of model state updates was modelled as a nested series of method invocations. The constructor-level recursion was a generally useful feature used in the theory for the definition of more complex kinds of datatype.","PeriodicalId":383341,"journal":{"name":"J. Object Technol.","volume":"32 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2004-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114348653","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"The Theory of Classification, Part 13: Template Classes and Genericity","authors":"A. Simons","doi":"10.5381/jot.2004.3.7.c2","DOIUrl":"https://doi.org/10.5381/jot.2004.3.7.c2","url":null,"abstract":"The object-oriented type theory for non-specialists is discussed. It is shown that how parametric polymorphism, known as templates in C++ and genericity in Ada and Eiffel, can be added to the Theory of Classification. The generic types could be created by abstracting over parts of simple types. A generic type is modeled as a type function expecting an actual type argument.","PeriodicalId":383341,"journal":{"name":"J. Object Technol.","volume":"91 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2004-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121978468","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"The Theory of Classification, Part 12: : Building the Class Hierarchy","authors":"A. Simons","doi":"10.5381/jot.2004.3.5.c2","DOIUrl":"https://doi.org/10.5381/jot.2004.3.5.c2","url":null,"abstract":"The construction of specific object instances and the development of simple class hierarchy are discussed. The class hierarchy development includes recognizable classes, with mixtures of default, abstract and concrete methods. Generators that are extended into flexible object creation functions with initialization values passed to superclass functions, mimicking the behavior of real object-oriented languages. It is shown that the classes that are derived by inheritance give rise to objects of exact types, which match the expected interfaces of their superclasses and the separately-declared interfaces.","PeriodicalId":383341,"journal":{"name":"J. Object Technol.","volume":"58 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2004-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127779880","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Design by Contract: analysis of hidden dependencies in component based application","authors":"D. Enselme, G. Florin, F. Legond-Aubry","doi":"10.5381/jot.2004.3.4.a2","DOIUrl":"https://doi.org/10.5381/jot.2004.3.4.a2","url":null,"abstract":"Components are increasingly used to create complex and distributed systems and applications.\u0000They are often viewed as simple servers, which limits their capacity for collective action. In this paper, we propose a method to simplify their assembly and their potential re-usability. We use the notion of dependency and contract between components to explicitly design an entity that guarantee the correctness of the built\u0000system. We introduce split contracts and delegations of properties to check, both at conception and execution time, the correctness of the built system. Our solution increases the independence of the participating entities by isolating the core components and transferring the aggregation into specific \"glue\" components.","PeriodicalId":383341,"journal":{"name":"J. Object Technol.","volume":"25 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2004-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125485875","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Concurrent Object-Oriented Programming: The MP-Eiffel Approach","authors":"Miguel Oliveira e Silva","doi":"10.5381/jot.2004.3.4.a6","DOIUrl":"https://doi.org/10.5381/jot.2004.3.4.a6","url":null,"abstract":"concurrent programming Since we are interested in the essential properties of concurrency, we don’t want to bind our concurrent processing entities to specific “lower level” realizations such as threads, processes, object request brokers, MPI, PVM, or any other. Instead, we will use an abstract notion of “processor” adapted from Meyer [Mey97, page 964]: 2 JOURNAL OF OBJECT TECHNOLOGY Submitted to TOOLS USA 2003 2 CONCURRENT PROGRAMMING A processor is an autonomous thread of control capable of supporting the sequential execution of instructions. Nothing is assumed on how this virtual processor will be implemented at runtime. We won’t even exclude the possibility that a processor may start by being a thread in one machine and end as a process in another through a remote procedure call mechanism. In general, concurrency does not require simultaneous (parallel) processor execution. A concurrent program can be thought as the concurrent execution of sequential “programs”, one for each processor (of course, they may depend highly on each other). From a concurrent programming system we expect the ability to – safely – specify and control two things: • concurrent execution of processors; • inter-processor synchronization and communication. Concurrent execution of processors Concurrent systems need mechanisms to start, support, and terminate the execution of processors, either as part of the programming language constructs or provided in a library. In particular they need to assign processors to specific processing devices (threads, processes, computers in a distributed system, or any other). This assignment will be called heterogeneous if the concurrent system allows the assignment of different processing devices for processors, otherwise it will be classified as homogeneous processor mapping. Heterogeneous processor mapping is a desirable property since it enforces the decoupling between a concurrent program and specific processing devices. However, specific types of concurrent programming, such as real-time and embedded systems may pose strong restrictions to valid (feasible) processor mappings. Inter-processor synchronization and communication To ensure a correct inter-processor interaction it is necessary to enforce proper timing constraints between them. Such synchronization requirements may arise from the necessity to guarantee safety properties [Lam83], the verification of some condition, the need to impose a specific processor scheduling strategy [RF77], or several of these possibilities at the same time. Submitted to TOOLS USA 2003 JOURNAL OF OBJECT TECHNOLOGY 3 CONCURRENT OBJECT-ORIENTED PROGRAMMING: THE MP-EIFFEL APPROACH","PeriodicalId":383341,"journal":{"name":"J. Object Technol.","volume":"40 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2004-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129873412","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}