C. Szyperski. Independently extensible systems -- software engineering potential and challenges. In Proceedings 19th Australian Computer Science Conference. Australian Computer Science Communications, 1996.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....2. It would also be no problem to assign two roles, e.g. Subject and Observer, to the same class, or assign the same role twice to the same class in two di#erent bindings. For example, a Point can be simultaneously a subject concerning coordinate changes ias well as color changes. In terms of [14], the observer component in Fig. 1 is independently extensible. These features are probably the rationale for the author s decision against an alternative (simpler) implementation of the observer protocol in AspectJ. The alternative solution of which we speak is to declare addObserver( and ....

....editing the class directly. For example, in MultiJava [4] additional methods can be attached to a class. In AspectJ, methods as well as fields can be added to a class by means of introductions. As already discussed in Sec. 2, open classes are in contrast to the concept of independent extensibility [14], an essential prerequisite for reusable and extensible software. On contrary, Caesar o#ers an alternative to open classes that is even more powerful and does not violate independent extensibility. Adaptive Plug and Play Components (APPCs) 10] and their aspect oriented variant of Aspectual ....

C. Szyperski. Independently extensible systems -- software engineering potential and challenges. In Proceedings 19th Australian Computer Science Conference. Australian Computer Science Communications, 1996.

....evolution. Software evolution includes the maintenance and extension of component features and interfaces. Supporting software evolution is important, since components and component systems are architectural building blocks and as such, subject to continuous changes. Extensibility of components [53] is not only required for a smooth component evolution. It is even more desired for enabling the development of families of software applications and product lines in general. Traditionally, components are static black boxes emphasizing encapsulation over extensibility. Features can be added to ....

C. Szyperski. Independently extensible systems -- software engineering potential and challenges. In Proceedings of the 19th Australian Computer Science Conference, Melbourne, Australia, 1996.

....evolution. Software evolution includes the maintenance and extension of component features and interfaces. Supporting software evolution is important, since components and component systems are architectural building blocks and as such, subject to continuous changes. Extensibility of components [Szy96] is not only required for a smooth component evolution. It is even more desired for enabling the development of families of software applications and product lines in general. Traditionally, components are static black boxes emphasizing encapsulation over extensibility. Features can be added to ....

Clemens Szyperski. Independently extensible systems -- software engineering potential and challenges. In Proceedings of the 19th Australian Computer Science Conference, Melbourne, Australia, 1996.

....by having the host application developers design and implement the host application in such a way that add ons are forced to be mutually independent they do not depend on or interact with one another directly. Instead, the host application mediates all interactions among add ons. Szyperski [15] refers to such system as independently extensible as they can cope with the late addition of extensions without requiring a global integrity check. Krishnamurthi and Felleisen [5] have formalized a more restricted notion of independent extensibility. Many operating systems and shrink wrapped ....

Clements Szyperski. Independently extensible systems-software engineering potential and challenges. Proceedings of the 19th 4ustra/asian Computer Science Coherence, Melbourne, Australia, January 31- February 2, 1996.

....b b b b j j j j # # # # H H H H Figure 5.3 : Local unit structure in DrScheme 102 Chapter 6 Related Work on Software Components McIlroy [59] first crystallized the idea of software components produced by a softwarecomponents industry. More recently, Weide et al. 83] and Szyperski [79, 80] substantiate the need to base reusable components on compiled code rather than source code. Szyperski [79] further points out that reuse of compiled components requires a late linking mechanism for connecting them, which is the thesis that we refine and explore in this dissertation. Much of ....

....Work on Software Components McIlroy [59] first crystallized the idea of software components produced by a softwarecomponents industry. More recently, Weide et al. 83] and Szyperski [79, 80] substantiate the need to base reusable components on compiled code rather than source code. Szyperski [79] further points out that reuse of compiled components requires a late linking mechanism for connecting them, which is the thesis that we refine and explore in this dissertation. Much of the existing literature on reuse fails to distinguish between the reuse of source code and the reuse of ....

Szyperski, C. Independently extensible systems: Software engineering potential and challenges. In Proc. Australian Computer Science Conference, 1996.

....The DARWIN model is sketched in the next two sections to the degree relevant in the context of this paper. This sketch includes an example that illustrates the problem that led to the above claim because it shows interesting parallels to the problem of independent extensibility of components ([23]) 2 Darwin and Lava: Combining Class based and Object based Inheritance We assume that the reader is familiar with the notions of class, instance, and class based inheritance ( 28] For simplicity of presentation, we shall introduce DARWIN using the syntax and design of the language LAVA ( 6, ....

....be able to integrate independently developed subclasses (Parent) and child classes (Child) of the same class (DeclaredParent) into one hierarchy, without fear of undesired side effects. The importance of independent extensibility for component programming has already been described by Szyperski ([23, 24]) in a delegationfree environment. Whereas Szyperski focused on the joint use of two independent extensions of a base type by a third party, our discussion relates to the delegation based composition of one independent extension with another one. Overriding. The point of the above discussion of ....

C. Szyperski: "Independently Extensible Systems -- Software Engineering Potential and Challenges --". In Proceedings of the 19th Australasian Computer Science Conference, Melbourne, Australia. 1996.

....dynamic delegation with subtyping is possible and can be integrated into a class based environment. The DARWIN model is sketched next, to the degree relevant in the context of this paper, concentrating especially on the interesting parallels between independent extensibility of components ([Szy96]) and type safety of a system that combines delegation and subtyping. 2 Darwin and Lava: Combining Class based and Objectbased Inheritance We assume that the reader is familiar with the notions of class, instance, and classbased inheritance. For simplicity of presentation, we shall introduce ....

....locate errors. 4 DeclaredParent b( b( self.bang( bang(Bomb) Parent bang(SE) Child c p b( Figure 2: What happens during evaluation of the message c. b( The importance of independent extensibility for component programming has already been described by Szyperski ([Szy96, Szy98]) in a delegation free environment. Whereas Szyperski focused on the joint use of two independent extensions of a base type by a third party, our discussion relates to the delegation based composition of one independent extension with another one. Overriding. The point of the above discussion of ....

Szyperski, Clemens. Independently Extensible Systems Software Engineering Potential and Challenges . In Proceedings of the 19th Australian Computer Science Conference, Melbourne, Australia. Computer Science Association, 1996.

....it precludes changes unanticipated by the original developers. Composition of software add ons is also poorly supported by existing techniques. Most existing techniques circumvent the composition problem by preventing interaction between add ons. This is indeed the approach advocated by Szyperski [18]. Our Approach Our approach to decentralized, post deployment software evolution overcomes many of the limitations 5 of 9 3 2 99 1:46 PM Decentralized Software Evolution http: www.ics.uci.edu peymano papers iwpse98 exhibited by previous approaches. Our approach is based on evolving ....

C. Szyperski. Independently extensible systems-software engineering potential and challenges. Proceedings of the 19th Australasian Computer Science Conference, Melbourne, Australia, January 31- February 2, 1996.

.... has to be changed invasively (with of course less weighty consequences) 4 Independent extensibility A useful property of an extensible component is independent extensibility: A system is independently extensible if it is extensible and if independently developed extensions can be combined [Szy96] The di#culty in achieving independent extensibility when using in place modifications is that di#erent extensions might conflict and no central instance (like the inheriting class in a multiple inheritance hierarchy) is available to resolve this conflict. AspectJ su#ers from this problem in ....

Clemens Szyperski. Independently extensible systems -- software engineering potential and challenges. In Proceedings 19th Australian Computer Science Conference, number 18(1), pages 203--212. Australian Computer Science Communications, 1996.

....into a class based environment, laying the foundations for dynamic component adaptation. The DARWIN model is sketched in the next section to the degree relevant in the context of this paper, pointing out the interesting parallel between type safety and independent extensibility of components ([Szy96]) The use of DARWIN for dynamic component adaptation is described in section 5. 4 Note that the limitations of the Glasgow Proposal s rejected part had already been hardwired into the design of COM ( Box98] 4 Darwin and Lava: Combining Class based and Object based Inheritance We assume ....

....method from Child would therefore be undesirable anyway, because it would silently change the semantics relied upon by methods from Parent, leading to obscure, hard to locate errors. The importance of independent extensibility for component programming has already been described by Szyperski ([Szy96,Szy98]) in a delegation free environment. Whereas Szyperski focused on the joint use of two independent extensions of a base type by a third party, our discussion relates to the delegation based composition of one independent extension with another one. Overriding. The point of the above discussion of ....

Clemens Szyperski. Independently Extensible Systems Software Engineering Potential and Challenges. In Proceedings of the 19th Australian Computer Science Conference, Melbourne, Australia. Computer Science Association, 1996.

....the properties that components of those systems should have, and introduces a components design methodology based on the modular addition of properties. 1 Introduction There is now an increasing interest in the study of Open Systems, and in particular in the Independently Extensible systems [21] as the base for a component market. In this market users are able to buy or rent reusable components o# the shelf and compose them to build their applications. Extensible systems allow new functionality to be added at run time. Independently Extensible systems allow extensions of the system to ....

C. Szyperski. Independently Extensible Systems ---Software Engineering Potential and Challenges---. Proceedings of the 19th Australasian Computer Science Conference, Melbourne, 1996.

....the properties that components of those systems should have, and introduces a components design methodology based on the modular addition of properties. 1 . INTRODUCTION There is now an increasing interest in the study of Open Systems, and in particular in the Independently Extensible systems (Szyperski 1996) as the base for a component market. In this market users are able to buy or rent reusable components off the shelf and compose them to build their applications. Extensible systems allow new functionality to be added at run time. Independently Extensible systems allow extensions of the system to ....

C. Szyperski. "Independently Extensible Systems -- Software Engineering Potential and Challenges--". In Proceedings of the 19th Australasian Computer Science Conference, Melbourne, 1996.

....to be a software engineer 8 76 Appendix I [McI68] But compared to other engineering disciplines where components are used successfully and decide the business success, software component technology is not yet mature. Discussions about components are often mainly limited to the technical aspect [Weg96, Szy96, NT95, OHE96] of interoperability. Contrarily, industry reports to be more challenged by organizational or social aspects when using components in large software projects. Cox [Cox95] argues that the difficulties we have long experienced in the software field including our efforts to reuse software components ....

Szyperski, C:"Independently Extensible Systems - Software Engineering Potential and Challenges -", Proc. of Australasian Computer Science Conference 96, Melbourne, Feb., 1996

....the new construct of type extension in combination with the old concept of procedure variable provides an absolutely sufficient language framework for the creation of amazingly rich and flexible object oriented sceneries . Extensibility has been discussed in various contexts, see [Fra94, Szy96] a review may also be found in [R u96] Another evolutionary step is the Oberon System 3 with its gadgets [Gut94, Gut96, FM98] which has been chosen as a design and implementation basis for the work presented on this paper. 3 The Model Layers During the last decade several models have been ....

C. Szyperski. Independently extensible systems -- software engineering potential and challenges. In Proceedings of the 19th Australasian Computer Science Conference, 1996.

....new generation of COM) As said before, COM is all about interoperability of independently deployed components. In order to achieve interoperability, a system needs to be independently extensible. Independently extensible systems allow components to be plugged into the running system when needed [24]. Since COM does not support implementation inheritance, this is an advantage for developing independently extensible systems because it avoids overly tight coupling between code from different vendors. Versioning of interfaces is an important problem in independently extensible systems. COM ....

....COM off from other object models and are the major motivation for formalizing COM. COM is one of the few examples of available technology to build independently extensible systems. The methodology and theoretical aspects of independently extensible systems have not yet been sufficiently addressed [24]. Therefore, it is worthwhile to build a formal model for independently extensible systems. Starting with a formal model of COM, the hope is that this can then be generalized to a formal model for independently extensible systems. One of the very important COM rules is that all COM interfaces ....

Szyperski C. Independently Extensible Systems - Software Engineering Potential and Challenges. In Proceedings of the 19th Australasian Computer Science Conference, Melbourne, Australia, January 1996. Springer 1996.

....which do not need human interaction. In the analyzing phase, recorded data are evaluated. The results extracted serve as a basis for improvement of workflow schemes. Passing all phases several times in a cycle, business processes are optimized little by little. A component oriented system [11] is an architecture or an implementation for a software system providing infrastructure for components. An implementation consists of an application development environment and a runtime environment for components. A component based system [13] uses components only during development. In the ....

Clemens Szyperski. Independently Extensible Systems --- Software Engineering Potential and Challenges. In Australian Computer Science Communications, 18(1):203--212, February 1996.

....Q Q Q c c c c b b b b j j j j # # # # H H H H Figure 5.3 : Local unit structure in DrScheme 102 Chapter 6 Related Work on Software Components McIlroy [59] first crystallized the idea of software components produced by a softwarecomponents industry. More recently, Weide et al. 83] and Szyperski [79, 80] substantiate the need to base reusable components on compiled code rather than source code. Szyperski [79] further points out that reuse of compiled components requires a late linking mechanism for connecting them, which is the thesis that we refine and explore in this dissertation. Much of the ....

....Work on Software Components McIlroy [59] first crystallized the idea of software components produced by a softwarecomponents industry. More recently, Weide et al. 83] and Szyperski [79, 80] substantiate the need to base reusable components on compiled code rather than source code. Szyperski [79] further points out that reuse of compiled components requires a late linking mechanism for connecting them, which is the thesis that we refine and explore in this dissertation. Much of the existing literature on reuse fails to distinguish between the reuse of source code and the reuse of ....

Szyperski, C. Independently extensible systems: Software engineering potential and challenges. In Proc. Australian Computer Science Conference, 1996.

....feature set as needed rather than be overflowing with features when first loaded. To more formally characterise self extendibility, we begin with the weaker concept of independent extendibility. Szyperski defines an independently extendible system as one which includes the following five features [Szy96] ffl A collection of extension units. ffl Independence of extensions: inclusion of one must not preclude inclusion of others. ffl A polymorphic base upon which the extensions can act. ffl A late linking mechanism. ffl Centralised resource management. An independently extendible system can ....

Clemens Szyperski. Independently extensible systems --- software engeneering potential and challenges. In Proceedings of the 19th Australasian Computer Science Conference, Februrary 1996.

.... refinement behavioral subtyping for classes [20] and matching for components [30] Bertrand Meyer propagates design by contract for component software, albeit of a less formal nature [21, 22] Clemens Szyperski and Rosziati Ibrahim are working on the formalization of Microsoft s COM object model [28, 26] as starting point for a more general investigation in formal methods for component software. The Object Systems Group at the University of Geneva under Nierstrasz and Tsichritzis have researched a number of applications of semi formal methods to component software [24] 8 Conclusions We have ....

Clemens A. Szyperski. Independently extensible systems --- software engineering potential and challenges. In Proceedings of the 19th Australasian Computer Science Conference, Melbourne, 1996.

....modules and where modules are not statically linked. The solution of Chambers and Leavens for multiple dispatch of methods [10] which requires a designated topmost module and flags errors of other modules when compiling this module, is against the spirit of open systems and independent extension [24]. While the first problem could be partly solved by introducing a special notation for symmetrical participants, the second one has no solution which is orthogonal to separate extension. Hence, we do not permit overriding of actions. We could allow overriding for actions with only one participant ....

Clemens A. Szyperski. Independently extensible systems -- software engineering potential and challenges. In Proceedings of the 19th Austalasian Computer Science Conference, Melbourne, 1996.

....we can simply bind against whatever is found first and hope that things will work out ok. That is, unfortunately, the state of the art for the vast majority of systems in use today. 3 How to name components The fact that we want both reuse beyond source sharing and independent extensibility [1] has several consequences on how to name components, and how names on the level of program source are mapped onto names of components. 3 Let s first consider the requirements on the names of components, which we will call strong names. Programmers like to refer to items by simple, readable ....

Clemens Szyperski. Independently Extensible Systems: Software Engineering Potential and Challenge. In 19th Australasian Computer Science Conference, Adelaide, SA, 191996.

.... 5 Related Work The Interface Specification Language (ISL) a pure extension of the CORBA IDL, developed in the Component Based Software Engineering project at CSTaR Software Engineering Lab supports the descriptions of pre postconditions of operations, invariants and protocols of interfaces [15]. ISL opts for featurism, including multiple inheritance across components, rather than simplicity as we promote it. ISL is a sublanguage of the Architecture Specification Language, which also includes the Glue Specification Language and the Configuration Specification Language. Participants in ....

....nitpick www home.html. 13] Cliff B. Jones. A rigorous approach to formal methods. IEEE Computer, pages 20 21, April 1996. 14] Gregor Kiczales. Why are black boxes so hard to reuse. In Proceeding of OOPSLA 94, 1994. http: www.parc.xerox.com spl projects oi towardstalk transcript.html. [15] W. Kozaczynski and J. O. Ning. Concern driven design for a specification language. In Proceedings of the 8th International Workshop on Software Specification and Design, Berlin, Germany, March 1996. 16] WWW Virtual Library. Formal methods. http: www.comlab.ox.ac.uk ....

[Article contains additional citation context not shown here]

Szyperski, C.: Independently Extensible Systems - Software Engineering Potential and Challenges. In Proc. 19th Australasian Computer Science Conference, Melbourne, Australia, 1996. 111

....new generation of COM) As said before, COM is all about interoperability of independently deployed components. In order to achieve interoperability, a system needs to be independently extensible. Independently extensible systems allow components to be plugged into the running system when needed [11]. Since COM does not support implementation inheritance, this is an advantage for developing independently extensible systems because it avoids overly tight coupling between code from different vendors. Versioning of interfaces is an important problem in independently extensible systems. COM ....

....COM off from other object models and are the major motivation for formalizing COM. COM is one of the few examples of available technology to build independently extensible systems. The methodology and theoretical aspects of independently extensible systems have not yet been sufficiently addressed [11]. Therefore, it is worthwhile to build a formal model for independently extensible systems. Starting with a formal model of COM, the hope is that this can then be generalized to a formal model for independently extensible systems. One of the very important COM rules is that all COM interfaces ....

Szyperski C. Independently Extensible Systems - Software Engineering Potential and Challenges. In Proceedings of the 19th Australasian Computer Science Conference, Melbourne, Australia, January 1996.

....interface inheritance. As said before, COM is all about interoperability of independently deployed components. In order to achieve interoperability, a system needs to be independently extensible. Independently extensible systems allow components to be plugged into the running system when needed [14]. COM s lack of support for implementation inheritance is an advantage for developing independently extensible systems because it avoids overly tight coupling between code from different vendors. Versioning of interfaces is an important problem in independently extensible systems. COM interfaces ....

....COM off from other object models and are the major motivation for formalizing COM. COM is one of the few examples of available technology to build independently extensible systems. The methodology and theoretical aspects of independently extensible systems have not yet been sufficiently addressed [14]. Therefore, it is worthwhile to build a formal model for independently extensible systems. Starting with a formal model of COM, the hope is that this can then be generalized to a formal model for independently extensible systems. One of the very important COM rules is that all COM interfaces ....

Szyperski C. Independently Extensible Systems - Software Engineering Potential and Challenges. In Proceedings of the 19th Australasian Computer Science Conference, Melbourne, Australia, January 1996. Springer 1996.

No context found.

C. Szyperski. Independently extensible systems -- software engineering potential and challenges. In Proceedings 19th Australian Computer Science Conference. Australian Computer Science Communications, 1996.

First 50 documents

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