Ian M. Holland. The Design and Representation of Object-Oriented Components. PhD thesis, Northeastern University, 1993.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....for complicated functionality. SOP provides a rich specification language for combining subjects. ffl Maps incorporate ideas from Adaptive Programming [9] that can significantly lower their maintenance costs in a wide range of situations. Ian Holland describes contracts and lenses in his thesis [5]. Contracts and lens objects are even more closely related to our views than SOP, being analogous to view class graphs and map objects, respectively. Holland s work is aimed at managing interfaces between separate pieces of behavior (contracts) By combining the contract (view) and lens (map) at ....

I. M. Holland. The Design and Representation of Object-Oriented Components. PhD thesis, Northeastern University, 1993.

....rules only take the state transformations, but not the calls, into account. The semantics of method calls is defined by reduction, which is inappropriate for the problem at hand. Contracts of Helm, Holland, and Gangopadhyay. Helm et al. define a mostly syntactic notion of interaction contracts [24, 25] for the object oriented design of components. External calls can be explicitly specified. However, lacking the distinction between modification and enquiry operations, all specified calls are 4 This is only meaningful if the combined systems, like #(IA: CA, IB: CB) make no external calls. 30 ....

....not be expressed in theirs: SetTwoValues(Value val1, Value val2) value=val1; Notify( value=val2; Hence, their notation cannot satisfactorily be used to express the states in which external calls have to be made. Furthermore, no operation preconditions can be expressed. Holland s thesis [25] gives part of an operational semantics for an objectoriented programming language and for interaction contracts. However, no semantic reasoning is done. There is a notion of contract refinement to design specialized contracts; however, no clear semantic conditions are listed and the examples are ....

Ian M. Holland. The Design and Representation of Object-Oriented Components. PhD thesis, Northeastern University, 1993.

....One of the explored areas (with a good response of the model, which did not require any adaptation at all even when this use had not been anticipated) is reuse contracts. 3. Reuse Contracts The idea of contracts applied to software has been explored under different interpretations (see [4], 6] 7] In this paper, the reuse contract approach due to Carine Lucas [6] is examined. First, because it is a static, declarative model, which better fits our ideas (static analysis is one of the key points for us) Moreover, Lucas contract model allows a higher modularisation than others, ....

Holland, Ian. The Design and Representation of Object-Oriented Components. Doctoral Dissertation, College of Computer Science, Northeastern University, 1992.

.... behavioral change avoidance approach has been studied again in the data base community in the context of Abbreviated Queries [CS92, Sci91, Sci94] and Views [AB91] and in the software engineering community in the form of Adaptive Programming [Lie96] Open Implementation [Kic92] Contracts [HHG90, Hol93] Subjectivity [HO93] Design Patterns [GHJV95b] and programming style rules such as the Law of Demeter [Hol93] Adaptive Programming is the only behavioral change avoidance approach based on the powerful polymorphism provided by succinct subgraph specifications. Architecture. Architecture ....

.... Queries [CS92, Sci91, Sci94] and Views [AB91] and in the software engineering community in the form of Adaptive Programming [Lie96] Open Implementation [Kic92] Contracts [HHG90, Hol93] Subjectivity [HO93] Design Patterns [GHJV95b] and programming style rules such as the Law of Demeter [Hol93] Adaptive Programming is the only behavioral change avoidance approach based on the powerful polymorphism provided by succinct subgraph specifications. Architecture. Architecture description languages (ADLs) GS93] lie between requirement definition languages and programming languages. ADLs ....

[Article contains additional citation context not shown here]

Ian M. Holland. The Design and Representation of Object-Oriented Components. PhD thesis, Northeastern University, 1993. 17

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

I. Holland. The design and representation of objectoriented components. PhD thesis, Northeastern University, Computer Science, 1993.

....for graphical editors [Gam98] FRED and the JHotDraw application (along with a tutorial) are freely available at http: www.cs.helsinki.fi research fred. 2 Design contracts and specialization templates Basically, a design contract 4 is a variant of the contract concept introduced by Holland [Hol93]. It is also closely related to a design pattern [Gam95] A design contract is an application independent description of a certain OO design aspect. In contrast to a traditional design pattern, it does not necessarily describe a solution to a frequently occurring problem (or to any problem for ....

Holland I.: The Design and Representation of Object-Oriented Components. PhD thesis, Northeastern University, 1993. 5 For example, for JHotDraw we needed 16 specialization templates. 10

....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, or roles. Each application class may play ....

....between the granularity supported by classes and package modules. The motivation behind (a) is that the unit of reuse is generally not the class, but a slice of behavior affecting several classes. This is actually the core of the object oriented application framework technology. As discussed in [10, 13, 19], since frameworks are described by means of programming languages, they suffer from several problems that are due to the lack of language constructs for clearly expressing patterns of collaborations. The idea is that single methods often only make sense in a larger context, and are difficult to ....

[Article contains additional citation context not shown here]

I. Holland. The design and representation of object-oriented components. PhD Thesis, Northeastern University, 1993.

....by explicitly naming all methods that are invoked through self sends in each method [7] Consider, for example, an abstract class AbstractView 1 , that describes the general behaviour of a view that 1 Throughout this text we use a part of a GUI library as an example. The example is inspired by [4] and [6] visually represents a certain subject. A view can be drawn and updated. The method Update relies on the method Draw and on a number of other methods for its implementation. Class AbstractView Abstract Draw( Concrete Update( self.SetPen(2) self.SetRect(40,60) self.Draw( ....

....and the methods of its acquaintances are at least as important. Just as our current reuse contracts are based on specialisation interfaces, reuse contracts could be developed based on descriptions of interclass relationships. Such descriptions have already been studied in the form of contracts [3, 4], but will not be discussed here. 3 . 2 Definition of Reuse Contracts A reuse contract is a set of method descriptions that is divided into two subsets: the abstract and the concrete method descriptions. Reuse contracts are only interfaces: they never contain actual methods, only descriptions of ....

[Article contains additional citation context not shown here]

Holland, I. The Design and Representation of Object-Oriented Components, PhD thesis, Northeastern University, 183 pages, 1992.

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

I. Holland. The Design and Representation of ObjectOriented Components. PhD Thesis, Northeastern University, Computer Science, 1993. 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 ....

I. Holland. The Design and Representation of ObjectOriented Components. PhD Thesis, Northeastern University, Computer Science, 1993.

....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 simultaneously active. Thus, it is not possible to allow different instances of a class to follow different ....

....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 simultaneously active. Thus, it is not possible to allow different instances of a class to follow different collaboration schemes. ....

[Article contains additional citation context not shown here]

I. Holland. The Design and Representation of Object-Oriented Components. Ph.D. Dissertation, Northeastern University, Computer Science, 1993.

....In fact, the pinned view approach, although conceptually much simpler than SOP, manages to meet most of the goals set out for SOP. 5.3 Contracts and Database Views There have been a number of attempts to represent subschemas of the global database which serve particular applications. Ian Holland [Hol93] has borrrowed the idea of a business contract to serve that purpose. Holland s contracts consist of a package of object declarations and object behavior definitions enclosed by a scope of visibilit . A contract lists participating parties, and for each party defines its obligations in terms of ....

Ian M. Holland. The design and representation of object-oriented components. PhD thesis, Northeastern University, 1993.

....schemas. The behavioral change avoidance approach has been studied again in the data base community in the context of Abbreviated Queries [8, 43, 44] and Views [1] and in the software engineering community in the form of Adaptive Programming [33] Open Implementation [27] Contracts [19, 20], Subjectivity [18] Design Patterns [11] and programming style rules such as the Law of Demeter [20] Adaptive Programming is the only behavioral change avoidance approach based on the powerful polymorphism provided by succinct subgraph specifications. Architecture. Architecture description ....

.... community in the context of Abbreviated Queries [8, 43, 44] and Views [1] and in the software engineering community in the form of Adaptive Programming [33] Open Implementation [27] Contracts [19, 20] Subjectivity [18] Design Patterns [11] and programming style rules such as the Law of Demeter [20]. Adaptive Programming is the only behavioral change avoidance approach based on the powerful polymorphism provided by succinct subgraph specifications. Architecture. Architecture description languages (ADLs) 13] lie between requirement definition languages and programming languages. ADLs have ....

Ian M. Holland. The Design and Representation of Object-Oriented Components. PhD thesis, Northeastern University, 1993.

....can be assigned different responsibilities depending on their time of execution. Many researchers have acknowledged the need to lift abstraction above the class level, and several approaches have been proposed, including Frameworks [Deu89] Clusters [Mey90] Mechanisms [Boo91] and Contracts [Hol93] One key difference between many proposed behavioral encapsulation techniques and ABCs is the ability to adapt as class structures evolve. An additional difference is the composition mechanism employed by ABCs. Component composition is the process of creating new components from existing ones. ....

Ian M. Holland. The design and representation of object-oriented components. Technical report, Northeastern University, 1993. Ph.D. thesis.

.... behavioral change avoidance approach has been studied again in the data base community in the context of Abbreviated Queries [CS92, Sci91, Sci94] and Views [AB91] and in the software engineering community in the form of Adaptive Programming [Lie96] Open Implementation [Kic92] Contracts [HHG90, Hol93] Subjectivity [HO93] Design Patterns [GHJV95] and programming style rules such as the Law of Demeter [Hol93] Adaptive Programming is the only behavioral change avoidance approach based on the powerful polymorphism provided by succinct subgraph specifications. 5.3 Architecture Architecture ....

.... Queries [CS92, Sci91, Sci94] and Views [AB91] and in the software engineering community in the form of Adaptive Programming [Lie96] Open Implementation [Kic92] Contracts [HHG90, Hol93] Subjectivity [HO93] Design Patterns [GHJV95] and programming style rules such as the Law of Demeter [Hol93] Adaptive Programming is the only behavioral change avoidance approach based on the powerful polymorphism provided by succinct subgraph specifications. 5.3 Architecture Architecture description languages (ADLs) GS93] lie between requirement definition languages and programming languages. ....

Ian M. Holland. The Design and Representation of Object-Oriented Components. PhD thesis, Northeastern University, 1993.

....patterns. The implementation of variation points is one of the most critical parts in framework development. Several techniques can be used, such as design patterns (Buschmann et al. 1996; Gamma et al. 1995) meta level programming (Kiczales et al. 1991) and contracts (Helm et al. 1990; Holland, 1993). However, the selection of the most appropriate technique for each of the framework s variation points may be a very difficult task. If the variation points and their properties are not explicitly represented, this task can become even harder. Once the variation points have been documented in ....

Holland, I., The Design and Representation of Object-Oriented Components, Ph.D. Dissertation, Computer Science Department, Northeastern University (1993).

....into path constraints and cardinality constraints (see [LX92] What other kinds of constraints are needed 20. Dynamic aspects of groups of propagation patterns: activate and deactivate a group of propagation patterns in another group (Ian Holland s Ph.D thesis with propagation added [Hol92, Hol93] 4 21. Succinct description of program selectors. Class dictionary graphs serve as program selectors for propagation patterns. How can class dictionary graph abstraction [HLM93] be used to succinctly describe class dictionary graphs 22. Develop process models for adaptive software. Develop ....

Ian M. Holland. The design and representation of object-oriented components. Technical report, Northeastern University, 1993. Ph.D. thesis.

....frameworks. ffl Application frameworks are still rigid artifacts while propagation patterns are flexible structures which adjust more easily to changes. Signatures in propagation pattern are strongly localized; while signatures in application frameworks are disseminated. Contracts Contracts [29, 30, 31] share the spirit of writing generic programs. The contract model supports the definition of multiple interfaces for objects. An interface can be activated by enabling the appropriate contract. This mechanism naturally allows modeling of changing behaviors as an object moves through time. A ....

....can operate on shared objects. Subjects can be composed together according to a set of composition rules. Subjects in a composition do not need to know the details of related subjects. When an object moves from one subject to another subject, similar to moving from one instantiation of a contract [31] to another, the class associated with the object can be automatically changed so that the different perception of the same object by the two subjects can be reflected. Therefore, subject oriented programming allows greater flexibility of software extension than the current objectoriented ....

Ian M. Holland. The design and representation of object-oriented components. PhD thesis, Northeastern University, 1993.

....in the data models. It is important that the derived edges can be utilized by propagation directives. The type system should allow for derived relationships. The current state of our foundation work for adaptive software is presented in [LX93a, LX93c, LX93b] The contract model [Hol92, Hol93] supports the definition of multiple interfaces for objects. An interface can be activated by enabling the appropriate contract. This mechanism naturally allows modeling of changing behavior as an object moves through time. A contract is expressed in terms of participants and their obligations. ....

....other data structures. ffl Meta level software structures Many mechanisms have been invented to make software more flexible. They include partially interpreted schemas [KRT87] algorithmic skeletons [Col89] the Plan Calculus 18 [RW90] implementational reflection [Rao91] and contracts [Hol92, Hol93] Contracts have been refined in our research group. Partially interpreted schemas are program sections that have some portions remaining abstract or undefined. Therefore, a propagation pattern is a partially interpreted schema since the propagation directives don t define a semischema in ....

[Article contains additional citation context not shown here]

Ian M. Holland. The design and representation of object-oriented components. Technical report, Northeastern University, 1993. Ph.D. thesis.

....extensions proposed in [30] which may lead to a very tangled design. Although it can be a good solution it should have a more concise representation at design level. This paper has shown how to use roles to complement the description of variation points implemented by design patterns. Contracts [18, 19] and adaptable plug and play components (APPCs) 24] provide linguistic constructs for implementing collaboration based (or role based) diagrams in a straightforward manner. They may be used to implement variation points since they represent instantiation as first class citizens. However, these ....

I. Holland, "The Design and Representation of Object-Oriented Components", Ph.D. Dissertation, Computer Science Department, Northeastern University, 1993.

....several works aimed at improving the expressiveness of the inheritance structure by relaxing the class subclass relationships that could also support modeling stand alone behavior that can be reused in several scenarios. This category includes the work on mixin based inheritance [4,5] contracts [10], mixinmethods [16] MixedJava [6] Rondo [18] and context relationship [20] These works share the fact that variations on a base behavior are modeled in stand alone artifacts called mixins in [4,5] and [6] contracts in [10] mixinmethods in [16] adjustments in [18] and context objects in ....

.... category includes the work on mixin based inheritance [4,5] contracts [10] mixinmethods [16] MixedJava [6] Rondo [18] and context relationship [20] These works share the fact that variations on a base behavior are modeled in stand alone artifacts called mixins in [4,5] and [6] contracts in [10], mixinmethods in [16] adjustments in [18] and context objects in [20] These artifacts do not commit to any base behavior when defined. Rather, they refer to the base behavior by means of an (unbound) super parameter and the self reference. The individual approaches differ from each other on ....

Holland, I. The Design and Representation of ObjectOriented Components. PhD Thesis. Northeastern Univ., 1993.

....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 [17] 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 simultaneously active. Thus, it is not possible to allow different instances of a class to follow different ....

....and scalability problems. Smaragdakis and Batory solve this by elevating the concept of a mixin to multiple class granularity, using C parameterized nested classes [17] 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 simultaneously active. Thus, it is not possible to allow different instances of a class to follow different collaboration schemes. ....

[Article contains additional citation context not shown here]

I. Holland. The Design and Representation of Object-Oriented Components. Ph.D. Dissertation, Northeastern University, Computer Science, 1993.

....several works aimed at improving the expressiveness of the inheritance structure by relaxing the class subclass relationships that could also support modeling stand alone behavior that can be reused in several scenarios. This category includes the work on mixin based inheritance [2,3] contracts [8], mixin methods [14] MixedJava [4] Rondo [16] and context relationship [18] These works share the fact that variations on a base behavior are modeled in stand alone artifacts called mixins in [2,3] and [4] contracts in [8] mixin methods in [14] adjustments in [16] and context objects in ....

.... category includes the work on mixin based inheritance [2,3] contracts [8] mixin methods [14] MixedJava [4] Rondo [16] and context relationship [18] These works share the fact that variations on a base behavior are modeled in stand alone artifacts called mixins in [2,3] and [4] contracts in [8], mixin methods in [14] adjustments in [16] and context objects in [18] These artifacts do not commit to any base behavior when defined. Rather, they refer to the base behavior by means of an (unbound) super parameter and the self reference. The individual approaches differ from each other on ....

Holland, Ian. The Design and Representation of Object-Oriented Components. PhD Thesis. Northeastern University, 1993.

....several works aimed at improving the expressiveness of the inheritance structure by relaxing the class subclass relationships that could also support modeling stand alone behavior that can be reused in several scenarios. This category includes the work on mixin based inheritance [4,5] contracts [10], mixinmethods [16] MixedJava [6] Rondo [18] and context relationship [20] These works share the fact that variations on a base behavior are modeled in stand alone artifacts called mixins in [4,5] and [6] contracts in [10] mixinmethods in [16] adjustments in [18] and context objects in ....

.... category includes the work on mixin based inheritance [4,5] contracts [10] mixinmethods [16] MixedJava [6] Rondo [18] and context relationship [20] These works share the fact that variations on a base behavior are modeled in stand alone artifacts called mixins in [4,5] and [6] contracts in [10], mixinmethods in [16] adjustments in [18] and context objects in [20] These artifacts do not commit to any base behavior when defined. Rather, they refer to the base behavior by means of an (unbound) super parameter and the self reference. The individual approaches differ from each other on ....

Holland, I. The Design and Representation of ObjectOriented Components. PhD Thesis. Northeastern University, 1993.

....of type GraphClass, but casts it to a GraphNumberClass type when it calls the first, VertexNumbering, traversal (see Fig. 7) Holland s framework implementation required a lens mechanism a kind of modal filter that added an extra layer of indirection to support two separate traversals [10]. In concurrent applications, only one mode could be active at a time. Combining the modal filter with dynamic binding creates two layers of indirection to bind a method body to a call site, making the application do extra work at runtime for a binding that is known at compile time. Our ....

Ian M. Holland. The Design and Representation of Object-Oriented Components. PhD thesis, Northeastern University, 1992.

....the level of individual classes but also at the level of design components. So far, Contracts has been used to specify some of the interactions of objects within the Interviews C Graphical User Interface library [1] It has also been extended for the specification of business MIS applications [3] and graph algorithms [2] This paper presents further applications of the Contracts approach in the networking domain. More specifically, it shows how Contracts can be used to represent variations of a distributed routing protocol as large grained reusable object oriented abstractions. Different ....

....them. The DVA is represented as a contract which includes the Internet sub contract. The DVA is refined to specify the variants of the distributed routing protocol. The work presented in this paper brings another original element. The original computational model behind Contracts, as in [1] 2] [3], is sequential. We are extending the Contracts approach to a parallel model of computation. Extension to a parallel model of computation makes suited application of the Contracts approach to protocols and distributed system applications. The paper is organized as follows. Section 2 reviews the ....

I. M. Holland and I. M. Holland, "The Design and Representation of Object-Oriented Components," Ph.D. Thesis, Northeastern University, Boston, 1993.

.... 1 Introduction This paper describes an approach to generic, composable components that encapsulate collaborations between objects, providing a linguistic construct for expressing design segments found in collaboration based (role based) designs [8, 28, 24] The term collaborationbased design [1, 9, 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, or roles. Each application class may play ....

....designs represent object oriented applications in two different ways: in terms of participants or classes that are involved, and in terms of the tasks or concerns of the design, as illustrated in Fig. 1. This twofold representation results in more comprehensive and reusable designs [1, 9, 23]. For the same reason, several other design methodologies support collaboration diagrams as one of their most important artifacts which facilitate understanding the overall behavior of high level system operations resulting from the use cases [4] class K1 collaboration C1 collaboration C2 ....

[Article contains additional citation context not shown here]

I. Holland. The Design and Representation of Object-Oriented Components. PhD Thesis, Northeastern University, 1993.

....shows the main program rewritten with incremental context object attachment to compute both visitors during one traversal, simply by using the operator. 4 Related Work Holland summarizes extensions to the object model that have been proposed for varying the interface and behavior of an object [10], such as perspectives [7] views [22] and contexts [2] He notes that the extensions can be characterized in terms of: Static Class Def. Static Class Definition Class Equipment void before( void after( Dynamic Class Equipment Definition Dynamic Class ....

....tasks require the collaboration of a group of objects. Researchers have acknowledged the need to lift abstraction above the class level, and several approaches have been proposed for modeling collaborative, task based behavior, including Frameworks [11] Clusters [18] Mechanisms [4] Contracts [9, 10], Propagation Patterns [26, 14] and Subjects [20] As an example, a Contract [9, 10] models a set of object interactions. The participants of the contract have certain obligations (attributes and behaviors) that they must support. A contract defines a template of participants and obligations of ....

[Article contains additional citation context not shown here]

Ian M. Holland. The design and representation of object-oriented components. PhD thesis, Northeastern University, 1993. http://www.ccs.neu.edu/home/lieber/thesesindex. html.

.... Figure 19: Pricing and Inventory visitors rewritten with incremental composition 4 Related Work Holland summarizes extensions to the object model that have been proposed for varying the interface and behavior of an object [Hol93] ffl Are interfaces embedded in the structure of objects or layered on top of objects ffl Are clients of an object restricted to using a specific interface or are all interfaces visible ffl Can an interface have different implementations or is there only one implementation ffl Is the ....

....the collaboration of a group of objects. Researchers have acknowledged the need to lift abstraction above the class level, and several approaches have been proposed for modeling collaborative, task based behavior, including Frameworks [JF88] Clusters [Mey90] Mechanisms [Boo91] Contracts [HHG90, Hol93] Propagation Patterns [Xia94, Lie96] and Subjects [OKH 95] As an example, a Contract [HHG90, Hol93] models a set of object interactions. The participants of the contract have certain obligations (attributes and behaviors) that they must support. A contract defines a template of ....

[Article contains additional citation context not shown here]

Ian M. Holland. The design and representation of object-oriented components. Technical report, Northeastern University, 1993. Ph.D. thesis.

....composition. The basic building blocks of composition are simple: classes act as black boxes encapsulating data and behavior. However, how to best use the above composition mechanisms has been much debated and is far from trivial. Recent work on design patterns [GHJV94] and contracts [HHG91, Hol93] analyze class composition and collaboration in order to achieve more flexible and reusable designs. At the next higher level, we encounter the problem of how to compose design patterns or contracts themselves which is not addressed in the above books. A priori, it is not clear how a class that ....

Ian M. Holland. The design and representation of object-oriented components. PhD thesis, College of Computer Science, Northestern University, Boston, MA, June 1993.

....Visitors group related operations performed on multiple classes (which need not be related through inheritance) together into one program component, supporting a collaborative, task based style of programming. Collaborative styles have become very popular through such mechanisms as Contracts [10], Subjects [11] and Propagation Patterns [12] 13] Figure 7 contains a standard visitor design, similar to the example presented by Gamma et al. [1] An example task computes the total cost of computer equipment, based on accumulating the net price of simple equipment (Card, Drive, FloppyDisk) ....

....arguments. Incremental mode allows a behavior to be dynamically extended rather than overridden, which is in fact the goal of the Decorator pattern [1] IV. Related Work Holland summarizes extensions to the object model that have been proposed for varying the interface and behavior of an object [10], such as Perspectives [18] Views [19] and Contexts [20] He notes that the extensions can be characterized in terms of: ffl Object structure: are interfaces embedded in the structure of objects or layered on top of objects ffl Visibility of interface: are clients of an object restricted to ....

[Article contains additional citation context not shown here]

Ian M. Holland, The design and representation of objectoriented components, Ph.D. thesis, Northeastern University, 1993, http://www.ccs.neu.edu/home/lieber/theses-index.html.

....of class collaborations from which C code is generated. The ways that class structures evolve are detailed, and strategies for maintaining propagation patterns based on those transformations are given. While there exist other models for specifying inter object behavior and patterns [3, 11, 5, 8], Propagation Patterns provide formal language support for the specification and implementation of behavior, with emphasis on supporting class evolution. The ideas presented here are based on experience gained while using the Demeter CASE tools to implement systems for Citibank and Merrill Lynch. ....

Ian M. Holland. The design and representation of object-oriented components. Technical report, Northeastern University, 1993. Ph.D. thesis.

No context found.

Ian M. Holland. The Design and Representation of Object-Oriented Components. PhD thesis, Northeastern University, 1993.

No context found.

Holland, I. M. (1993) The Design and Representation of Object-Oriented Components. PhD Thesis, Northeastern University.

No context found.

Ian M. Holland. The Design and Representation of ObjectOriented Components. PhD thesis, Northeastern University, 1993.

No context found.

Ian M. Holland. The Design and Representation of ObjectOriented Components. PhD thesis, Northeastern University, 1993.

No context found.

Hol93 Holland I., The Design and Representation of Object-Oriented Components. Ph.D. thesis, Northeastern University, 1993.

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