Y. Smaragdakis, D. Batory, Implementing Layered Designs with Mixin Layers, 12th European Conference on Object-Oriented Programming, (ECOOP '98), july 1998.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....whereas virtual or abstract types are present in BETA [31] as well as more recently in gbeta [19] Rune [42] and Scala [33] An essential ingredient of these systems are objects with type members. There is currently much work that explores the uses of this concept in object oriented programming [38,40,20,36]. But its type theoretic foundations are just beginning to be investigated. As is the case for modules, dependent types are a promising candidate for a foundation of objects with type members. Dependent products can be used to represent functors in SML module systems as well as classes in object ....

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. Lecture Notes in Computer Science, 1445, 1998.

....outlined a proof that the model correctly implements an SOS, and argued that the model is transparent with respect to the code. Given the increasing popularity of design methods that encourage collaboration based design (e.g. design patterns [8] aspectoriented programming [10] and mixin layers [14]) we expect there will be a growing need for reasoning techniques that are transparent with regard to the role structure of these collaborations. Such proofs typically rely on mathematical abstractions of source code. Because the connection between the actual code and the model is ultimately ....

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In Proc. of the 12th European Conference on Object-oriented Programming, 1998.

.... referred to as collaboration based designs or collaboration based developments [2,3] such as contracts [4] subject oriented programming [5] role components [6] roles [7 10] aspectoriented programming [11] adaptive programming [12] adaptive plug and play components [2] mixin layers [13], and pluggable composite adapters [14] support the decomposition and composition of an application system through their own first class modeling entity for encapsulating collaboration. Among various collaboration based development techniques, the role model adopts the most general and direct ....

....within a framework are fixed. In other words, gluing and the collaborative protocol cannot be dealt with separately. This drawback makes it impossible to selectively bind a core object to a specific role instance rather than to affect all instances of the role within the role system. Mixin layers [13] improve the way role components can be implemented using the C template proposed by VanHilst and Notkin [6] by solving the scalability problem identified by VanHilst and Notkin [27] In Table I, several representative pieces of work related to collaboration based design, including software ....

Smaragdakis Y, Batory D. Implementing layered designs with mixin layers. Proceedings of the European Conference for Object-Oriented Programming,Brussels,Belgium(Lecture Notes in Computer Science, vol. 1445). Springer, 1998.

....types of the interpreter function can be represented as mixins. Each interpreter fragment can then be represented as a mixin module containing both class and mixin definitions. Mixin module combination coalesces the definitions in a type safe manner. Related to the latter work, the JTS project [4, 35] provides support for reusing abstract syntax trees and operations on those trees, with an emphasis on hygienic syntactic ma238 nipulations of ASTs. An interesting point of comparison is that the JTS project recognizes the importance of mixinbased inheritance, at the granularity of collections ....

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In European Conference on Object-Oriented Programming, 1998.

....multiple inheritance. The intention of mixins is, that they should not be instantiated on their own. Instead, they should depict reusable pieces of code that can be added to other classes [ 15] The benefit of mixins is widely known for example for building layered object oriented design [14] or static roles objects [16] Figure 1 shows the usage of a mixin class: the mixin consists of two method definitions m2. The method body of the mixin s body might already refer to other classes expected from the inheritance hierarchy the mixin is applied to. For example method refers ....

.... method is declared within the interface (so the application of introductions to an interface feels more like the traditional F bounded polymorphism [3] The problem with conflicting AspectJ mixins is, that this does not permit to build complex hierarchies of mixin layers as for example used in [14]: it is not possible that an introduced method overrides the implementation of another method (it doesn t matter if introduced or not) In that way, to be able to implement mixin layers in AspectJ, the mixins have to be carefully preplanned. Hence, the benefit for such mixins much more limited ....

Smaragdakis, Y.; Batory, D.: Implementing Layered Designs with Mixin Layers, Proceedings of 12th European Conference on Object-Oriented Programming (ECOOP), LNCS, 1445, Springer-Verlag. 1998

....with its emphasis on aspect weaving. Open classes in Jiazzi are based on mixins [1] where extensibility is gained with classes whose super classes are initially unfixed. Role model components [23] use individual mixins to modularize the many roles an object is involved in. Mixin layers [22] improve on this by using a layer of mixins to modularize a collaboration between many objects. Java Layers [4, 3] adds mixin layers to the Java language. The sibling class pattern [3] enabled by Java Layers provides the same functionality as Jiazzi s open packages. Delegation layers [21] ....

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In Proc. of ECOOP, pages 550--570, June 1998.

....the capability of broad changes to programs. Reflection [23] provided means of introducing crosscutting changes at run time in languages such as Smalltalk. Compile time [5, 32] reflection in C and Java has been developed and extended to load time in Java using byte code editing [6] Mixin layers [28] also provide a way of adding features to methods in several different classes simultaneously. Implicit Context [36] is a method for separating extraneous embedded knowledge (EEK) or cross cutting knowledge) from the design of a program, and re weaving it back in later. Monads and monad ....

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. Lecture Notes in Computer Science, 1445:550--??, 1998.

....Holland [Hol92] for this example are, in fact, general enough to be applicable to a directed graph. If, however, a more efficient, specialized for undirected graphs algorithm was used (as is, for instance, possible for the Cycle Checking operation) the change would yield incorrect results. Sma99, SB98b, BG98] discuss in detail the issue of ensuring that collaborations are actually interchangeable. Although we have focussed on a single application that supports all three graph operations, it is easy to see how variants of this application could be created (e.g. by omitting some operations or ....

....CLOS (and other reflective languages) We can encode mixin layers in CLOS [KRB91] and other reflective systems) by simulating their main elements using reflection (classes as first class entities) Due to lack of space, we elide the implementation specifics. A discussion can be found in [SB98b] and [Sma99] CLOS mixin layers are not semantically equivalent to C mixin layers (for instance, there is no default class data hiding: class members are by default accessible from other code in CLOS) Nevertheless, the two versions of mixin layers are just different flavors of the same idea. ....

Y. Smaragdakis and D. Batory, "Implementing Layered Designs with Mixin Layers", ECOOP 1998.

....for modules that are larger than classes have emerged. Besides components as understood in the context of standard component models such as CCM and EJB, which are out of the scope of this paper, several other module proposals have been made for supporting the so called collaboration based design [5, 23, 19, 3, 20, 14, 4, 17]. Approaches of this kind build on the insight that the design of object oriented applications can be organized along two dimensions: structural abstractions (object types) and collaborations in which these abstractions are involved (see Fig. 1 for illustration) In general, an abstraction is ....

....module constructs fully satisfies our needs. By means of an example scenario, we illustrate the features that are needed and indicate what is missing in the current proposals for collaboration modules. We discuss only the three most advanced approaches to collaboration based design: mixin layers [20], family polymorphism [4] and delegation layers [17] This can be done without loss of generality, since the chosen approaches essentially subsume the other approaches to collaboration based design. In response to the shortcomings that we identify, we propose a new kind of collaboration module, ....

[Article contains additional citation context not shown here]

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In Proc. of ECOOP'98, LNCS 1445, pp. 550--570. Springer--Verlag, 1998.

....emerged over the last decade. In addition to components as defined by standard component models such as the CORBA Component Model and Enterprise Java Beans, which are beyond the scope of this paper, several other module proposals have been made for supporting so called collaboration based design [4, 19, 16, 2, 17, 12, 3, 15]. Approaches of this kind build on the insight that the design of object oriented applications can be organized in two dimensions: using structural abstractions (object types) and collaborations in which these abstractions are involved (see Fig. 1) Generally speaking, an object is involved in ....

....is quite a dubious concept in such a setting. For Object Teams, this is a non issue because comparing a role and a base object is meaningless: both exist in disjoint worlds. mixin layers dynamic view connectors pluggable composite adapters family polymorphism delegation reference [17] [6] 13] 3] 15] collaboration refinement declarative method binding confined objects object based inheritance dynamic composition multiple instance binding lifting lowering In contrast to some notable ....

[Article contains additional citation context not shown here]

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In Proc. of ECOOP'98, number 1445 in LNCS, pages 550--570. Springer Verlag, 1998.

....the capability of broad changes to programs. Reflection [23] provided means of introducing crosscutting changes at run time in languages such as Smalltalk. Compile time [5, 32] reflection in C and Java has been developed and extended to load time in Java using byte code editing [6] Mixin layers [28] also provide a way of adding features to methods in several different classes simultaneously. Implicit Context [36] is a method for separating extraneous embedded knowledge (EEK) or cross cutting knowledge) from the design of a program, and re weaving it back in later. Monads and monad ....

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. Lecture Notes in Computer Science, 1445:550--??, 1998.

....of classes. With CBD classes are decomposed into the roles they play in the di#erent collabo rations. The idea is nicely visualized by a two dimensional matrix with the classes as the column indexes and collaborations in which these classes are involved as the row indexes. Mixin Layers [26] and delegation layers [23] are two representatives of approaches to CBD. Both approaches provide concepts for composing and decomposing a collaboration into layers, such that a particular collaboration variant can be obtained by composing the required layers. Mixin layers use a nested variant of ....

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin-layers. In Proceedings of ECOOP '98, pages 550--570, 1998.

....reconfiguring the composition of architectural strata) In traditional object oriented programming languages, there is no practical implementation of stratified architectures, due to the inability of an individual object or class to morph itself over the different strata. However, mixin layers [22] (and probably a lot of other existing AOSD methods) can be used to implement this concept. Stratified architectures can also be implemented by means of Lasagne, with the important difference that architectural strata can be composed at run time. Variation points in the component framework are ....

Y. Smaragdakis and D. Batory, "Implementing Layered Designs with Mixin Layers", in Proceedings of the ECOOP'98 Conference, July 1998, Springer-Verlag LNCS 1445, pp. 550-570.

....the resulting code. Since the patterns are not part of the language, however, each programmer is responsible for maintaining or understanding a particular coding discipline. Krishnamurthi et al. 46] explore technology for migrating patterns to language constructs. ffl Smaragdakis and Batory [75] investigate the implementation of mixin layers for applying a family of cooperating mixins en masse to a family of classes. Mixin layers scale the mixin approach for components to larger systems. Smaragdakis and Batory rely on C templates to implement both mixins and mixin layers, but units ....

Smaragdakis, Y. and D. Batory. Implementing layered designs with mixin layers. In Proc. European Conference on Object-Oriented Programming, pages 550--570, 1998.

....client specific views. The discussion on other related work is organized according to the research areas that our work touches. 4.1. Advanced separation of concerns State of the art separation of concerns techniques such as Aspect oriented Programming [12] Hyperspaces [24] Mixin Layers [23], Adaptive Plug and Play Components [16] and Pluggable Composite Adapters [17] allow refinement of a core system with a crosscutting aspect, by simultaneously refining state and behavior at multiple points in the application in a non invasive and modular way. One of the strong arguments in favor ....

Y. Smaragdakis and D. Batory, "Implementing Layered Designs with Mixin Layers", in Proceedings of ECOOP'98, 1998.

....The running example in this paper is a graph collaboration with classes like Node and Edge and variations of this collaboration for colored graphs and weighted graphs. One of the most advanced approaches with respect to our goals is the mixin layer approach by Smaragdakis and Batory [31]. Mixin layers allow (a) sets of classes (which represent a particular collaboration and are implemented as nested classes of an outer class) to inherit from other sets of classes, and (b) the composition of di#erent variants of a base collaboration. With regard to our running example, this means ....

....[5] Mixin inheritance relaxes the strong coupling between a class and its superclass by enabling the instantiation of a class with di#erent superclasses. This property renders mixin inheritance suitable for defining and combining uniform incremental extensions of a class. Mixin layers [31] scale this concept to multi class granularity. In [31] the authors propose the usage of C [11] to implement mixin layers. Fig. 3 shows C mixin layers corresponding to Fig. 1 and 2. The basic technique is that the collaborating classes are implemented as nested classes of an outer class ....

[Article contains additional citation context not shown here]

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin-layers. In Proceedings of ECOOP '98, pages 550--570, 1998.

....inventors to question its scalability. The mixin layers technique was invented to address these concerns. Mixin layers are mixin classes nested in a pattern such that the parameter (superclass) of the outer mixin determines the parameters (superclasses) of inner mixins. In previous work [4] 24][25], we showed how mixin layers solve the scalability problems of the VanHilst and Notkin method and result into elegant implementations of collaborationbased designs. 1. We gratefully acknowledge the sponsorship of Microsoft Research, the Defense Advanced Research Projects Agency (Cooperative ....

....since they refer to features that no compiler we have encountered implements. Even though we present an introduction to mixins, mixin layers, and their uses, the primary purpose of this paper is not to convince readers of the value of these constructs. The reader should consult [4] 24] [25], 26] or [29] for that. We believe that the information presented here represents a valuable step towards moving some powerful programming techniques into the mainstream. We found that the mixin programming style is quite practical, as long as one is aware of the possible interactions with C ....

[Article contains additional citation context not shown here]

Y. Smaragdakis and D. Batory, "Implementing Layered Designs with Mixin Layers". In ECOOP 98.

....[13] address the issues of separating class features into separate modules. Feature oriented programming [21] and role components [27] use individual mixin like structures to decompose designs into feature hierarchies. An approach similar to the open class pattern is used in Mixin Layers [25]. Instead of using individual mixins, Mixin Layers provides constructs that apply mixins to multiple classes at once. Java Layers [5] is an implementation of Mixin Layers for Java. Jiazzi does not provide a solution for the configuration of runtime behavior as do other component systems such as ....

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In Proc. of ECOOP, pages 550--570, June 1998.

....added and or rede ned. A subclass can be implemented before its superclass has been implemented; thus mixins remove the dependence of the subclass on the superclass, enabling dynamic development of class hierarchies. Mixins have become a focus of active research both in the software engineering [27, 25, 14] and programming language design [7, 21, 15] communities. In our approach, we use mixins and mixin application as the coordination mechanism for assembling mobile components in a exible and safe way. The paper proposes a formal calculus, MoMi, that integrates the mixin technology (relying on the ....

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In Proc. ECOOP '98, pages 550-570, 1998.

....different modules. For example, modularisation of roles within collaborations are supported by mixins in the work described in [19] utilising a C template class for each role in each collaboration; complete classes are composed by placing these mixins in a hierarchy. This work is extended in [16] to overcome problems of scalability by grouping sets of roles within each collaboration. There are two main drawbacks to these approaches, relative to the composition patterns model. First, while classes can be mixed together simply by adding mixins to a class hierarchy, individual methods ....

Y. Smaragdakis and D. Batory. "Implementing Layered Designs with Mixin Layers". In Proc. of ECOOP, pp. 550--570, 1998.

....approach, based on the notion of mixins, and in particular on a mixin based calculus [5] for modelling the dynamism required by mobility in case of object oriented code. Mixins (classes parameterized over superclasses) have become a focus of active research both in the software engineering [26,24] and programming language design [7,20,15] communities. Mixin inheritance has been shown to be an expressive alternative to multiple inheritance [6] and a powerful tool for implementing reusable class hierarchies. The key idea of mixin based inheritance is that it is more oriented to the concept ....

Smaragdakis, Y. and D. Batory, Implementing layered designs with mixin layers, in: Proc. ECOOP '98, 1998, pp. 550-570.

....tier (see Figure 2) As such, the system model becomes very uniform and hierarchically structured. 2. 3 Relationship between component frameworks and collaboration based design Our system model is heavily based on combining component frameworks with the notion of collaboration based design [14, 23, 16]. We believe that collaborations are a useful concept to design a component framework as a composition of separately defined and separately verifiable building blocks. We first introduce collaboration based design and then pin down its relationship with component frameworks. Collaboration based ....

....roles that encapsulates relationships across its corresponding objects. In collaboration based design, collaborations express distinct (and largely independent) aspects of an application. This property makes collaborations an interesting way to express and verify software designs in a modular way. [16]. The relationship with component frameworks. An important contribution of component frameworks is the enforcement of architectural policies: in forcing components to perform certain tasks via mechanisms that are controlled by the framework, the framework retains the ability to perform ....

Y. Smaragdakis and D. Batory, "Implementing Layered Designs with Mixin Layers", in Proceedings of ECOOP'98, 1998.

....interceptors encapsulate a context specific customization of the whole core system, with the guarantee of consistency. 4. Related work 4.1. Advanced Separation of Concerns Advanced separation of concerns (ASOC) techniques such as Aspect oriented Programming [9] Hyperspaces [17] Mixin Layers [16], and Adaptive Plug and Play Components [12] allow extension of a core application with a new aspect subject layer collaboration, by simultaneously refining state and behavior at multiple points in the application in a non invasive manner. These approaches however mainly operate at the ....

Y. Smaragdakis and D. Batory, "Implementing Layered Designs with Mixin Layers", in Proceedings of ECOOP'98, 1998.

....[23] In this paper we introduce an abstract component architecture model (Component Framework according to [23] which supports component generators. Based on this model custom speci c systems may be generated from standard components. Our software generator refers to the GenVoca architecture [17] and the collaboration based design [24] The abstract component framework has been developed on base of the experiences gained from di erent software systems [12] In the following we introduce the basic concepts. Firstly, the abstract component framework and the general approach of the ....

....3. Implementing collaboration based Designs using Mixin Layers ThisMix nLayer F rs tC ass SecondC ass Th rdC ass F rs C ass SecondC ass Th rdC ass SuperM x nLayer Inheritance among Outer Classes Inheritance among Inner Classes Legend: Outer Class Inner Class Fig. 4. Mixin Layers [17] A good collaboration based design is the one where collaborations are largely independent of each other. An e ective, scalable way to directly map collaborationbased designs onto implementation are mixin layers. According to [17] a mixin class is a class whose superclass is not speci ed at the ....

[Article contains additional citation context not shown here]

Smaragdakis, Y., Batory, D.: Implementing Layered Designs with Mixin Layers. In: Proceedings of ECOOP'98, 12th European Conference on Object-Oriented Programming. Lecture Notes in Computer Science LNCS 1445. Springer, June (1998) 550 - 570

....model. The key result in this paper is a transparent proof of the correctness of analyses that are computed by inference graphs. Given the increasing popularity of design methods that encourage collaboration based design (e.g. design patterns [9] aspectoriented programming [7] and mixin layers [13]) we expect there will be a growing need for reasoning techniques that are transparent with regard to the role structure of these collaborations. We need proofs of collaboration based designs to be transparent in order to boost confidence confidence in the ultimate correctness of these ....

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In Proc. of the 12th European Conference on Object-oriented Programming, 1998.

....for collaboration or role model based design have been developed [2, 8, 17] On the other hand, main stream programming languages have been equipped with light weight linguistic means to group sets of related classes, e.g. name spaces in C or packages and inner classes in Java. Mixin layers [18] are a more flexible implementation technique for collaborations. The key advantage over traditional framework techniques is (a) that they allow sets of classes to inherit from other sets of classes, that is, inheritance is scaled to a multi class granularity, and (b) these sets of classes can be ....

....of runtime polymorphism for these collaborations. This makes it possible to use existing client code (code that uses a composed collaboration, e.g. the aforementioned graph collaboration) with di#erent collaborations at runtime. In general, this is not possible with mixin layers as presented in [18]. Delegation [11] can be seen as a generalization of mixinbased inheritance that allows to determine the inheritance hierarchy at runtime. For this reason, we think that delegation layers are a natural generalization of mixin layers, and they will be used to enable runtime composition. The ....

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin-layers. In Proceedings of ECOOP '98, pages 550--570, 1998.

....different ways to group methods by functionality rather than by class. Other problems in the literature include the various actions of a bottle deposit machine like depositing and printing a receipt [RA92] various composable pieces of data structure functionality such as searching and allocation [SB98], user interaction concerns such as directory listings and error messages in an FTP server [LM99] and many others. 1.2 Program Organization Program organization refers to the large scale structure of the program, at the level of large interacting groups of objects. My interest in this concern ....

Y. Smaragdakis and D. Batory. Implementing Layered Designs with Mixin-Layers. Proc. European Conference on Object-Oriented Programming, 1998.

....[1 21] has made its way into all modern software formalisms, bringing about many di#erent concepts for breaking a system into parts, with the object concept being the most recent one. In the last decade, a post objective era has emerged represented by role and collaboration based designs [23 8 27 32], reflective architectures [13 10 14 15] and more recent approaches such as aspect oriented programming [11] programming with reusable collaborations [16] and the multidimensional separation of concerns model [30] The main message of this post objective era [5] is that (a) existing software ....

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In Proc. of ECOOP'98, number 1445 in LNCS, pages 550--570. Springer Verlag, 1998.

....client applications that are not interested in these extensions. Furthermore, according to the separation of concerns principle each extension must be implemented as a separate module that can be dynamically added and removed without invasive change in the code of clients and core system [9] 13][21][23] 1] 6] 2) System wide and consistent interaction refinement. Customizing the core system with a single extension goes beyond refining individual components, but involves a system wide refinement of multiple core components at the same time. This is because integration of an extension often ....

....of consistency. 5. Related work The discussion on related work is organized according to the related fields that our work touches. 5.1. Advanced separation of concerns State of the art separation of concerns techniques such as Aspect oriented Programming [9] Hyperspaces [23] Mixin Layers [21], and Adaptive Plug and Play Components [13] allow extension of a core application with a new aspect subject layer collaboration, by simultaneously refining state and behavior at multiple points in the application in a non invasive manner. These approaches however mainly operate at the ....

Y. Smaragdakis and D. Batory, "Implementing Layered Designs with Mixin Layers", in Proceedings of ECOOP'98, 1998.

....the visitor pattern formulates workarounds for defining new operations on the object structure without changing the classes of the elements on which they operate. From an even more general point of view, the problem has been formulated in several works on collaboration based (role based) designs [9, 28, 24]. The term collaboration based designs [1, 10, 23] describes a methodology for decomposing object oriented applications into a set of classes and a set of collaborations. Collaborations express distinct and (relatively independent) aspects of an application which may involve several participants, ....

....of the design, as illustrated in Fig. 1. class K1 class K2 class K3 2,2 role K 1,2 role K 1,3 role K 1,1 role K 2,1 3,2 role K 3,3 role K 4,3 role K 4,2 role K 4,1 role K collab. C1 collab. C2 collab. C3 collab. C4 role K Figure 1: Collaboration Based Decomposition Several works [8, 9, 28, 24] in the area of programming languages indicate the lack of appropriate language constructs for expressing collaboration based designs and motivate the need for language support for bridging the gap between design and implementation. The work presented in this paper follows on the same heels. We ....

[Article contains additional citation context not shown here]

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin-layers. In Proceedings of the European Conference on Object-Oriented Programming ECOOP '98. To appear.

....[7 36] has made its way into all modern software formalisms, bringing about many di#erent concepts for breaking a system into parts, with the object concept being the most recent one. In the last decade, a post objective era has emerged represented by role and collaboration based designs [39 18 46 51], reflective architectures [25 21 26 27] and more recent approaches such as aspect oriented programming [22] programming with reusable collaborations [28] and the multidimensional separation of concerns model [49] The main message of this post objective era [15] is that (a) existing ....

....and eventually a transformation is performed to handle inconsistencies. This transformation has the flavor of DVCs but the purposes are quite di#erent: consistency checking of partial overlapping requirements versus integration of independent components. The work on collaboration based design [18 51 46 28] focuses on developing language support for defining collaborations between several objects separately of the static object model of the system. Our work is related to this research in that we allow tools which can be seen as large scale collaborations to be written separately of the ....

Y. Smaragdakis and D. Batory. Implementing Layered Designs with Mixin Layers. In Proceedings of European Conference on Object-Oriented Programming (ECOOP '98), LNCS 1445, pp. 550--570, Springer Verlag, 1998. 1, 17

....[7, 36] has made its way into all modern software formalisms, bringing about many di erent concepts for breaking a system into parts, with the object concept being the most recent one. In the last decade, a post objective era has emerged represented by role and collaboration based designs [39, 18, 46, 51], re ective architectures [25, 21, 26, 27] and more recent approaches such as aspect oriented programming [22] programming with reusable collaborations [28] and the multidimensional separation of concerns model [49] The main message of this post objective era [15] is that (a) existing ....

....and eventually a transformation is performed to handle inconsistencies. This transformation has the avor of DVCs but the purposes are quite di erent: consistency checking of partial overlapping requirements versus integration of independent components. The work on collaboration based design [18, 51, 46, 28] focuses on developing language support for de ning collaborations between several objects separately of the static object model of the system. Our work is related to this research in that we allow tools which can be seen as large scale collaborations to be written separately of the static ....

Y. Smaragdakis and D. Batory. Implementing Layered Designs with Mixin Layers. In Proceedings of European Conference on Object-Oriented Programming (ECOOP '98), LNCS 1445, pp. 550-570, Springer Verlag, 1998.

....on templates and mixins as an alternative to using frameworks [19] However, this approach may result in complex parameterizations and scalability problems. Smaragdakis and Batory solve this by elevating the concept of a mixin to multiple class granularity, using C parameterized nested classes [16]. However, their approach does not address the issue of dynamic customizations as described by Holland [9] A Contract [9] allows multiple, potentially conflicting component customizations to exist in a single application. However, contracts do not allow conflicting customizations to be ....

Y. Smaragdakis and D. Batory. Implementing Layered Designs with Mixin Layers. In Proc. ECOOP'98, 550-570. Springer Verlag, Lecture Notes in Computer Science.

.... Tools might even support both an object oriented view and a functional view (Figure 1) Other example problems include the various actions of a bottle deposit machine like depositing and printing a receipt [AR92] composable pieces of data structure functionality such as searching and allocation [SB98], user interaction concerns such as directory listings and error messages in an FTP server [LM99] adding an operation to a shape hierarchy [FF98] functional testing of a use case scenario, and many others. 2.3. Program Organization Program organization concerns address the large scale ....

....the actual objects it interacts with are usually subclasses of the interacting roles, the class is templated by the final types of the other classes. The actual composition of roles is done in a sequence of template class instantiations separate from the role definitions. Smaragdakis and Batory [SB98] describe mixin layers, a variant of this implementation technique. Their solution groups roles into role models container classes. In Figure 7, the Typecheck role model class is templated by a role model superclass. Each role within the class such as Meth extends the corresponding role in the ....

Y. Smaragdakis and D. Batory. Implementing Layered Designs with Mixin-Layers. Proc. European Conference on Object-Oriented Programming, 1998.

.... ### Indeed, some authors (e.g. BC90] define mixins as abstract subclasses (i.e. subclasses without a concrete superclass) Mixins based on parameterized inheritance in C have been used to implement highly configurable collaboration based and layered designs (e.g. see [VN96, SB98]) 2 In this paper, we present a solution to the constructor problem in parameterized inheritance based mixin programming in C . This problem, which was also described by Smaragdakis and Batory in [SB00] is illustrated in Listing 1. Let us take a closer look at the code. The mixin classes ....

Y. Smaragdakis and D. Batory. Implementing Layered Designs with Mixin Layers. In Proceeding of the 12 th European Conference on Object-Oriented Programming (ECOOP'98), E. Jul, (Ed.), 1998, pp. 550-570

....other distinct chains. These are indicated by the shaded classes of Figure 3c) The reason is that these classes contain all of the features or aspects that were added by higher classes in the chain. These higher classes simply represent intermediate derivations of the bottom class [4] 17][36]. A consequence of instantiating the bottom most class of a chain is that refinement relationships take precedence over typical subclassing relationships. That is, if class A in 4. There are other kinds of refinements beyond those discussed in this paper. An example is an optimizing refinement, ....

....class X implements F class A . class B extends TEqn.A . class C extends TEqn.A . class D . Components like that encapsulate refinements are expressed as mixins classes whose superclass is specified via a parameter. A representation of is a mixin layer [17][36][37] where s parameter s can be instantiated by any component that is of type F: class Y F s extends s implements F class A extends s.A . class B extends s.B . class D extends s.D . class E . In the parlance of the model of Section 2.2.2, x is a value of type ....

[Article contains additional citation context not shown here]

Y. Smaragdakis and D. Batory, "Implementing Layered Designs with Mixin Layers", ECOOP 1998.

....application app that implements vertex numbering and connected components using depth first search on an undirected graph is the equation: app = Prog( Benchmark( Number( Connected( DFS( Undirected ) 3.2 Mixin Layers There are many ways in which to implement refinements. We use mixin layers [Sma98]. To illustrate, recall the Directed program implements a directed graph. This program is defined by multiple classes, say Directed directed graph Cycle(x) cycle checking Undirected undirected graph MSTPrim(x) MST Prim algorithm Weighted(x) weighted graph MSTKruskal(x) MST Kruskal algorithm ....

....improved the clarity of our code, which we document in the following sections. In the process, we learned a simple rule to follow in order to simplify refinement based designs. 4. 1 Adjacency Lists Representation (G) The first representation we tried was based on a legacy C design [Sma98, Bat00a] that had been written years earlier and that implemented few of the refinements listed in Table 2. It consisted of 2 classes: Graph: consists of a list of Vertex objects. Vertex: contains a list of its adjacent Vertex objects. That is, edges were implicit: their existence could be inferred ....

Y. Smaragdakis and D. Batory, "Implementing Layered Designs with Mixin Layers", ECOOP 1998.

....that the system implements. Collaboration based architectures are receiving increasing recognition as providing a flexible and scalable approach to large scale system design, particularly for product line architectures. Scalable, collaboration based designs are fundamentally component based [6, 9]. Collaborations share the features of components [5, 7, 11] at least in principle: they are black boxes that can be combined through external linkage; their composition can be treated hierarchically; and they may be instantiated multiple times when building a system (the latter situation could ....

Smaragdakis, Y. and D. Batory. Implementing layered designs with mixin layers. In European Conference on Object-Oriented Programming, pages 550--570, 1998.

....distinct chains. These are indicated by the shaded classes of Figure 3c) The reason is that these classes contain all of the fea tures or aspects that were added by higher classes in the chain. These higher classes simply represent intermediate derivations of the bottom class [3] 13][25]. Representation. A GenVoca component refinement is encoded in JTS as a class with nested classes. A representation of component X of Figure 3a is shown below, where TEqn.A denotes the most refined version of class A (e.g, classes X.B and X.C in Figure 3a have TEqn.A as their superclass) We ....

....and their Composition A C D BD A A B C D component X A B D component Y composition Y X (a) b) c) B E E Components like Y that encapsulate refinements are expressed as mixins classes whose superclass is specified via a parameter. A representation of Y is a mixin layer [13][25], where Y s parameter can be instantiated by any component that is of type F: class Y F S extends S implements F class A extends S.A . class B extends S.B . class D extends S.D . class E . The composition of Y with X, depicted in Figure 3c, is expressed by: ....

[Article contains additional citation context not shown here]

Y. Smaragdakis and D. Batory, "Implementing Layered Designs with Mixin Layers", ECOOP 1998.

No context found.

Y. Smaragdakis, D. Batory, Implementing Layered Designs with Mixin Layers, 12th European Conference on Object-Oriented Programming, (ECOOP '98), july 1998.

No context found.

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In E. Jul, editor, ECOOP '98---Object-Oriented Programming, volume 1445 of Lecture Notes in Computer Science, pages 550--570. Springer, 1998.

No context found.

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin-layers. In Proceedings of ECOOP '98, LNCS 1445, pages 550--570, 1998.

No context found.

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin-layers. In Proceedings of ECOOP '98, pages 550--570, 1998.

No context found.

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In Proc. of ECOOP'98, number 1445 in LNCS, pages 550--570. Springer Verlag, 1998. 254 304

No context found.

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In Proc. ECOOP '98, pages 550--570, 1998.

No context found.

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. Lecture Notes in Computer Science, 1445, 1998.

No context found.

Y. Smaragdakis and D. Batory. Implementing Layered Designs with Mixin Layers. In Lecture Notes in Computer Science LNCS 1445, pages 550 - 570, 1998.

No context found.

Y. Smaragdakis and D. Batory. Implementing layered designs with mixin layers. In Proc. ECOOP '98, pages 550--570, 1998.

No context found.

Smaragdakis, Y. and D. Batory, Implementing layered designs with mixin layers, in: Proc. ECOOP '98, 1998, pp. 550-570.

No context found.

Smaragdakis, Y. and Batory, D. (1998a), Implementing Layered Designs with Mixin Layers, Proc. of ECOOP98.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC