9 citations found. Retrieving documents...
M. Mezini, L. Seiter, and K. Lieberherr. Software Architecture and Component Technology: State of the Art in Research and Practice, chapter Component Integration with Pluggable Composite Adapters. Kluwer Academic Publishers, 2001. 137, 139, 255

 Home/Search   Document Not in Database   Summary   Related Articles   Check  

This paper is cited in the following contexts:
Object Confinement in Object Teams - Reconciling Encapsulation.. - Herrmann (2003)   (Correct)

....strong concepts for encapsulation, which help for modular reasoning about aspect oriented programs developed in this model. 1 Object Teams in a nutshell The Object Teams programming model [7, 14] has its roots in the concept of Aspectual Components [11] It has gone through several iterations [12, 5, 6, 17] before its current incarnation as ObjectTeams Java, an implementation based on a combination of a modified Java compiler and a runtime system performing load time byte code adaptation using JMangler [10] Object Teams combine the expressive power for aspect oriented software composition in the ....

....role objects as part of the lifting translation. Transparent insertion of lifting lowering translations at all relevant program locations. Complete encapsulation of the base role link by the runtime system. 2.3. 1 On demand role creation The lifting translation has first been described in [12, 5]. It creates or retrieves a role object from three pieces of information: 1) the base object to be translated, 2) the enclosing Team instance and (3) the required static role type. For the same triplet of inputs, lifting is guaranteed to yield the same role instance. Thus the internal state of a ....

M. Mezini, L. Seiter, and K. Lieberherr. Software Architecture and Component Technology: State of the Art in Research and Practice, chapter Component Integration with Pluggable Composite Adapters. Kluwer, 2001.


Object Confinement in Object Teams - Reconciling Encapsulation.. - Herrmann   (Correct)

....strong concepts for encapsulation, which help for modular reasoning about aspect oriented programs developed in this model. 1 Object Teams in a nutshell The Object Teams programming model [7, 14] has its roots in the concept of Aspectual Components [11] It has gone through several iterations [12, 5, 6, 17] before its current incarnation as ObjectTeams Java, an implementation based on a combination of a modi ed Java compiler and a runtime system performing load time byte code adaptation using JMangler [10] Object Teams combine the expressive power for aspect oriented software composition in the ....

....of role objects as part of the lifting translation. Transparent insertion of lifting lowering translations at all relevant program locations. Complete encapsulation of the base role link by the runtime system. 2.3. 1 On demand role creation The lifting translation has rst been described in [12, 5]. It creates or retrieves a role object from three pieces of information: 1) the base object to be translated, 2) the enclosing Team instance and (3) the required static role type. For the same triplet of inputs, lifting is guaranteed to yield the same role instance. Thus the internal state of a ....

M. Mezini, L. Seiter, and K. Lieberherr. Software Architecture and Component Technology: State of the Art in Research and Practice, chapter Component Integration with Pluggable Composite Adapters. Kluwer, 2001.


Object Teams: Improving Modularity for Crosscutting Collaborations - Herrmann (2002)   (8 citations)  (Correct)

....level. Our approach exploits a similar delegation based approach for collaboration composition. However, our approach eliminates the limitations of delegation layers with respect to supporting separate development of reusable crosscutting collaborations and a posteriori integration thereof [16, 15, 9]. The structure of a sub layer in the delegation layers model has to be a refinement of the structure of its super layer. However, if collaborations are to be developed independently and deployed into existing applications a posteriori, we cannot assume their model structure to be a refinement of ....

....and delegation layers have been discussed in the introduction and throughout the paper. Let us now focus on a comparison within the field of languages for aspect oriented software development. Object Teams build upon and further develop ideas from the works on Pluggable Composite Adapters (PCAs) [15], Aspectual Components [13] and the language prototype LAC [8] which in turn have their common roots in the work on Adaptive Plug Play Components [14] In the following, we will clearly state the commonalities and differences of Object Teams with these predecessor models as well as with other ....

M. Mezini, L. Seiter, and K. Lieberherr. Software Architecture and Component Technology: State of the Art in Research and Industry, chapter Component Integration with Pluggable Composite Adapters. Kluwer, 2001.


Object Teams: Improving Modularity for Crosscutting Collaborations - Herrmann (2002)   (8 citations)  (Correct)

....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 ....

....are implicitly inserted when data flows enter leave a team. Teams are implicitly activated whenever a control flow enters a Team. 3 Related work Object Teams aim at implementing collaboration based designs [16, 2, 19, 17] They have their roots in Adaptive Plug Play Components [12] PCA [13], and Aspectual Components [11] They have been influenced by Hyper J [18] with respect to the separation of concern definition and concern composition as well as its capabilities for on demand restructuring. Influence from AspectJ [9] concerns the technique of weaving into existing code. ....

[Article contains additional citation context not shown here]

M. Mezini, L. Seiter, and K. Lieberherr. Software Architecture and Component Technology: State of the Art in Research and Practice, chapter Component Integration with Pluggable Composite Adapters. In M. Aksit (ed.) Software Architecture and Component Technology: State of the Art in Research and Practice. Kluwer Academic Publishers, 2001.


Towards a New Component Composition Process - Vanderperren, Wydaeghe (2001)   (1 citation)  (Correct)

....there is no direct match (both on a syntactic and semantic level) Depending on the mismatch between the components we want to compose, more or less glue code has to be written. Component composition thus ranges from plugging together over wrappers and adapters to writing extensive glue code [1]. The existing component documentation does not offer support to the developer to write this glue code or even to distinguish a perfect match from a complete mismatch of a set of components. It is widely believed that component based development follows all major software engineering principles ....

Mezini, M., Seiter, L. & Lieberherr, K. Software Architectures and Component Technology: The State of the Art in Research and Practice. Kluwer. 2000. Available at http://www.ccs.neu.edu/research/demeter/biblio/Compo nentIntegration.html


Views and Concerns and Interrelationships - Lessons Learned from .. - Herrmann (2002)   Self-citation (Mezini)   (Correct)

No context found.

M. Mezini, L. Seiter, and K. Lieberherr. Software Architecture and Component Technology: State of the Art in Research and Practice, chapter Component Integration with Pluggable Composite Adapters. Kluwer Academic Publishers, 2001. 137, 139, 255


Combining Composition Styles in the Evolvable Language LAC - Herrmann, Mezini (2001)   (1 citation)  Self-citation (Mezini)   (Correct)

....a larger family of languages. Section 4 brie y shows, how the simplicity of Lua facilitated rapid development of LAC, which can easily be extended to other styles of de ning and composing modules. This work builds upon the experience, we gained when developing Pluggable Composite Adapters (PCA [7]) and Dynamic View Connectors (DVC [3] Aside from similarities in the language model, DVCs also used some of the same technique, basically because it is implemented in the same language: Lua. There are two major di erences between both developments: DVCs are embedded into a framework for ....

....Lua, because of the well designed hotspots by which the interpreter can be in uenced. 4 By this technique we managed to combine di erent concepts that so far almost seemed incompatible. LAC allows modular software composition along these lines: It allows collaboration based development like PCA[7], some techniques of generative programming [12] and Hyper J [11] Activating and deactivating Connectors provides for dynamic, stateful contexts as in PCA[7] and Context Relations [10] Using wildcard based weaving allows modularization of code that would otherwise be scattered through many ....

[Article contains additional citation context not shown here]

M. Mezini, L. Seiter, and K. Lieberherr. Software Architecture and Component Technology: State of the Art in Research and Practice, chapter Component Integration with Pluggable Composite Adapters. Kluwer Academic Publishers, 2000.


On the Need for a Unified MDSOC Model: Experiences from.. - Herrmann, Mezini (2000)   Self-citation (Mezini)   (Correct)

....into the base behavior at the level of classes, methods, or even blocks, such as catch. Q3: Explicit integration: Is concern integration defined separately or is it part of the concern definitions The models of subject oriented programming (SOP [5] and Pluggable Composite Adapters (PCA [17]) allow to define integration in separate units whereas, e.g. in AspectJ [20] concerns and their integration are defined in the same place. Q4: Binding time: Are concerns bound at compile, link or load time or can binding be delayed until run time The role objects in delegation based ....

M. Mezini, L. Seiter, and K. Lieberherr. Software Architecture and Component Technology: State of the Art in Research and Industry, chapter Component Integration with Pluggable Composite Adapters. Kluwer, 2000.


Connectors for bridging Mismatches between the Components of .. - Herrmann, Mezini (2001)   Self-citation (Mezini)   (Correct)

....operate on isolated objects: tool speci c documents are rather composed from a (large) number of (collaborating) objects. Integration of tools should therefore handle graphs of objects. This suggests that ideas from collaboration based modeling in general and Adaptive Plug Play Components (AP PC) [10, 9] in particular might be worth considering when designing mechanisms for tool integration in SEEs. In the following we present the design of an SEE in a language which supports specifying tool integration concerns in rst class entities, called Dynamic View Connectors (DVC for short) We indicate ....

....and its data model (the repository model) Furthermore, the repository and all tools should be allowed to evolve even with respect to their respective model without breaking the existing integration. Conceptually, DVCs share many features with AP PC and their successor Pluggable Composite Adapters [9]: they can be considered as a concrete instantiation of these models in the domain of repository based SEEs. At the implementation level, DVCs make use of role objects [17] 3 Dynamic View Connectors We will present the main features of DVCs by means of a simple example. Consider the two models ....

M. Mezini, L. Seiter, and K. Lieberherr. Software Architecture and Component Technology: State of the Art in Research and Practice, chapter Component Integration with Pluggable Composite Adapters. Kluwer Academic Publishers, 2000 (to appear).

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