K. Sullivan and D. Notkin. Reconciling environment integration and software evolution. In Proc. SIGSOFT `90 Symp. on Software Development Environments, Dec. 1990.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....could all be accomplished without the use of events, but, in general, it would require signi cant time and energy above and beyond what would be necessary if events were used. As demonstrated in the simulator example, events can be useful for modular software evolution. Sullivan and Notkin, SN92] further demonstrate that use of events is bene cial for such things as software evolution and composition. Popular component models, such as COM , CORBA, JavaBeans, etc. give further credence to this claim by providing event mechanisms for the purpose of integrating components. Aside from ....

....their dynamic semantics. Second, the imp calculus was selected because it models an object oriented programming style, which is useful for several reasons. First, the objectoriented style promotes reuse and integration, which compliments event mechanisms which also promote reuse and integration [SN92] Second, it provides references, via object member labels, that describe what events handlers can handle. This is better than a calculus where such labels would either be buried in closures or de ned globally, lacking the necessary structure to easily determine what the possible set of ....

[Article contains additional citation context not shown here]

K.J. Sullivan and D. Notkin. Reconciling environment integration and software evolution. ACM Trans. Software Engineering and Methodology, 1(3):229-268, July 1992.

....incurs no runtime overhead. However, these are domain specific solutions. Several models have been proposed to address the problems with hardwired coordination protocols. Synchronizers [9] are a way of extracting synchronization policies from the objects and enabling their substitution. Mediators [14] bind method calls to events such that coordination changes need to be reflected only in the binding, rather than in the components. Both are software frameworks and thus they are not amenable to automatic, topology specific optimizations or real time scheduling. As a more abstract, interface ....

K. J. Sullivan and D. Notkin. Reconciling environment integration and software evolution. ACM Transactions on Software Engineering and Methodology, 1(3):229--268, July 1992.

.... ck are class refinements (func tions) The class c that is produced in Figure 2 can be expressed equationally as c = c(c(c) The simplest implementations of feature refinements are templates [24] 29] More sophisticated ways include generators [5] 20] program transformations [8] and objects [26]. 3 Scaling Refinements Four ideas have led us to a major generalization of the GenVoca model. First, a program has many different representations besides source code. A program can be defined by UML documents, process diagrams, makefiles, performance models, design rule files, etc. in addition ....

K.J. Sullivan, and D. Notkin, "Reconciling Environment Integration and Software Evolution", ACM TOSEM. 1, 3, July, 1992, 229-268.

....in the message distribution component that either conditionally broadcasts a message or replaces it with other messages. This approach, in comparison to our fully programmable coordinator, is limited as it does not facilitate changing the parameters of the messages when defining the policy. SN92] adopt a more semantic approach, using a mediator and implicit invocation mechanism similar to our coordinator and events, to help integration whilst maintaining independence. However, the tools they cite as examples are dealing with method tools that maintain semantically similar models of the ....

....of tool interactions that we handle with planes. Previous work in the area of tool integration concentrates either on tools as separate processes (Field, Forest and Glish [PS93] or as components of programs (for example, by modifying existing languages with an implicit invocation mechanism, SN92] using C , or [GS93] using Ada) We suggest that useful solutions to the problems described in this paper will probably require the support of both, rather than either, of these methods. Persimmon has been designed as both a language and an environment that can support the mechanisms required ....

Sullivan, K.J. and Notkin, D. "Reconciling Environment Integration and Software Evolution", ACM Trans on Soft. Eng. and Methodology 1,3. July 1992.

....no runtime overhead. However, these are domain specific solutions. Several models have been proposed to address the problems with hardwired coordination protocols. Synchronizers [9] are a way of extracting synchronization policies from the objects and enabling their substitution. Mediators [14] bind method calls to events such that coordination changes need to be reflected only in the binding, rather than in the components. Both are software frameworks and thus they are not amenable to automatic, topology specific optimizations or real time scheduling. As a more abstract, interface ....

K. J. Sullivan and D. Notkin. Reconciling environment integration and software evolution. ACM Transactions on Software Engineering and Methodology, 1(3):229--268, July 1992.

.... Suggested integration approaches include rule based process modelling integration such as MARVEL[KBS90] and message broadcasting with and without policy mechanisms[GI91] Rei90] Ger89] Another approach is to add adaptations to particular languages, for example to support implicit invocation [SN92] [GS93] Exploring related work in the area of tool integration brought about the realisation that very little work on integration is done from an environment user s perspective, ie of what use is integration to them. Very little work adopts this viewpoint. Brinkkemper[Bri93] adopts a similar ....

Sullivan, K.J. and Notkin, D. "Reconciling environment integration and software evolution", ACM Trans on Soft. Eng. and Methodology 1,3. July 1992.

....interface, as shown in Figure 5. If the name, or location, of the called service changes then all calling components will have to be changed. call ToolA.Operation24(Object2, Operation24(Object2, Recently there has been a lot of interest in the concept of implicit invocation [SN92], GS93] Rei90] Here a tool requests a service, or notifies that some activity has occurred (this is normally called an event) The event will trigger execution of the required service, or be used to invoke some code relevant to that event. Thus a tool simply signals using an agreed event and ....

....equivalent services for the events without changing the requesting calling code. Other activities depending on this event can be added to the event handler without changing any of the invoking components. There are many ways of organising the tools,events, and event handlers into workable systems. [SN92] investigate several possibilities most of which involve some coordinating tool, which they describe as a mediator. A mediator works with the tools to be integrated. ToolA Object1 Object2 Object3 ToolB Type1 Type2 Type3 Mediator Event Figure 7 shows the tools A and B interacting by ....

[Article contains additional citation context not shown here]

Sullivan, K.J. and Notkin, D. "Reconciling Environment Integration and Software Evolution". ACM Trans on Soft. Eng. and Methodology 1,3. July 1992.

....loose coupling. What we are missing is the notion of a module for bundling several components into a higher level component. Such a module construct would localize the relationships between components outside of the components themselves, playing a mediator role in the vein of Sullivan and Notkin [42]. The modules should themselves be first class components, with their own input and output interfaces, so that they can be composed into higher level modules much the same as objects can be composed into higher level objects in an object oriented system. This is to enable a hierarchical ....

....acceptance and a multitude of implementations, e.g. in Tibco Rendezvous the basic characteristics are extended to support additional features such as bridges connecting multiple busses, integration of transactional activities, and security considerations. Sullivan and Notkin introduce mediators [42] in order to o#er a design approach which explicitly instantiates and expresses integration relationships. An implicit invocation abstraction is used to bundle components and mediators, and, with its own interface, to compose new components. A similar approach regarding visibility is used as in ....

K. J. Sullivan and D. Notkin. Reconciling environment integration and software evolution. ACM Transactions of Software Engineering and Methodology, 1(3):229-- 269, July 1992.

....classes C1 and C2 are composed to form class C. All instantiations of classes C1 and C2 are changed to instantiations of C, so that, at runtime, only C instances exist, like o in the figure. Earlier work on tool integration, including event broadcasting [11] cooperative call [8] and mediators [12], on the other hand, was concerned with tying together sets of separate objects (or other modules, but we confine ourselves to objects in this paper) Mediators, for example, provide for implicit invocation, so that events in an object can trigger a mediator, which can then trigger actions in ....

Sullivan, K.J. and Notkin, D., Reconciling Environment Integration and Software Evolution," ACM Transactions on Software Engineering and Methodology 1(3), pp. 229-268, July, 1992.

....automated model generators for publish subscribe and cyclic task software architectures. To support coordination among behaviors, while maintaining loose coupling between tasks, autonomous systems often adopt one of two forms of component integration: 1. Using publish subscribe interaction [45] tasks are responsible for announcing (or publishing ) significant events. Other tasks may register to be informed of (or subscribe to ) a set of events. When one task publishes an event, it is sent to all subscribers. In this 8 way tasks remain independent since a publisher does not know the ....

K. Sullivan and D. Notkin. Reconciling environment integration and software evolution. In Proceedings of SIGSOFT `90: 4th Symp. on SW Development Environments, Dec.1990.

....System integration Aspect oriented programming, NET Framework. and evolution, 1. INTRODUCTION There is a fundamental conflict in software engineering between requirements for the behavioral integration of components, on one hand, and for the evolvability of integrated systems, on the other [30][31]. Integration requires that component behaviors be coupled, while evolvability demands that implementations be decoupled. The problem is grave if the only mechanism for behavioral coupling is explicit invocation (procedure call) In this case, behavioral integration implies representational ....

....invocation (procedure call) In this case, behavioral integration implies representational coupling, and integration is achieved only by sacrificing modularity and evolvability. The use of implicit invocation, in general [14] and of Sullivan s mediator based design approach, in particular [30][31], has been shown to significantly ease the conflict between integration and evolution. The approach has two major elements. First, the overall behavior of an integrated system is resolved, in the design concept, into separately conceived component behaviors that are integrated by separately ....

[Article contains additional citation context not shown here]

Sullivan, K. and Notkin, D., "Reconciling environment integration and software evolution," ACM Transactions on Software Engineering and Methodology 1, 3, July 1992.

....studies. First, we showed that although it seemed reasonable to use aspects in place of implicitly invoked aspect like mediators to effect component integration [24] the limits of AspectJ precluded the use of the powerful features of the language to achieve a fully satisfactory modular solution [25]. The mediator approach models behavioral relationships, or potential collaborations among objects, as instances of separate classes. Classes expose events as well as methods in their interfaces. Objects announce events to notify registered observers of occurrences. Mediator instances function as ....

....hurdles to language adoption [12] The remaining constructs are irregular and not sufficient to address the problem in a general way. For example, there is no way to associate an aspect instance in AspectJ with two object instances of different types, e.g. to integrate their behaviors [24] [25] [26] Nor is the idea of aspect C# new. AspectC# [17] is an AOSD implementation for C#. It enables weaving of type level aspects without language extension. Cross Language Aspect Weaving (CLAW) 20] borrows many features from AspectJ. It contains an Execution Engine that weaves base and aspect ....

[Article contains additional citation context not shown here]

Sullivan, K. and Notkin, D., "Reconciling environment integration and software evolution," ACM Transactions on Software Engineering and Methodology 1, 3, July 1992.

No context found.

K. Sullivan and D. Notkin. Reconciling environment integration and software evolution. In Proc. SIGSOFT `90 Symp. on Software Development Environments, Dec. 1990.

No context found.

K. Sullivan, D. Notkin, Reconciling environment integration and software evolution, in: Proc. SIGSOFT `90 Symp. on Software Development Environments, 1990.

No context found.

K. J. Sullivan and D. Notkin. Reconciling environment integration and software evolution. ACM Transactions of Software Engineering and Methodology, 1(3):229--269, July 1992.

No context found.

K. Sullivan, D. Notkin. Reconciling environment integration and software evolution. ACM Transactions on Software Engineering and Methodology . vol 1, no 3, July 1992.

No context found.

Sullivan, K. and Notkin, D., "Reconciling environment integration and software evolution," ACM Transactions on Software Engineering and Methodology 1, 3, July 1992.

No context found.

Sullivan, K.J. and Notkin, D., Reconciling Environment Integration and Software Evolution," ACM Transactions on Software Engineering and Methodology 1(3), pp. 229-268, July, 1992.

No context found.

K. J. Sullivan and D. Notkin. Reconciling environment integration and software evolution. In Proceedings of SIGSOFT `90: Fourth Symposium on Software Development Environments, Irvine, December 1990. evolution. ACM Transactions on Software Engineering and Methodology, 1(3):229-- 268, July 1992.

No context found.

K. J. Sullivan and D. Notkin. Reconciling environment integration and software evolution. ACM Transactions on Software Engineering and Methodology, 1(3):229--268, July 1992.

No context found.

K. Sullivan and D. Notkin. Reconciling environment integration and software evolution. In Proc. of SIGSOFT `90: Symp. on Software Development Environments, Dec. 1990.

No context found.

K. J. Sullivan and D. Notkin. Reconciling environment integration and software evolution. ACM Transactions of Software Engineering and Methodology, 1(3):229-- 269, July 1992.

No context found.

K.J. Sullivan and D. Notkin, "Reconciling Environment Integration and Software Evolution," ACM Trans. Software Eng. Methodology, vol. 1, no. 3, pp. 229-268, July 1992.

No context found.

K. Sullivan and D. Notkin. Reconciling environment integration and software evolution. ACM Transactions on Software Engineering and Methodology, 1(3):229--268, 1992. 78, 239, 257

No context found.

K. Sullivan and D. Notkin. Reconciling environment integration and software evolution. In Proc. of SIGSOFT `90: Symp. on Software Development Environments, Dec. 1990.

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