D. Riehle, T. Gross, Role Model Based Framework Design and Integration, Proceedings of the 1998.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....of patterns. Generic aspects are represented as structures of roles, called Role Models, where a Role Model defines a family of UML models [6, 5] It is important to note that the notion of roles used in our work differs from the run time object based notion of roles used in OORAM (e.g. see [15, 16]) Our roles are played by instances of the UML metamodel classes (e.g. UML class and association constructs) not by run time instances of application classifiers. For more information on Role Models see [13, 5] The types of concern realizations that can be represented as generic aspects are ....

D. Pdehle and T. Gross. Role Model Based Framework Design and Integration. In Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications (00PSLA '98), pages 117-133, Vancouver, Canada, October 1998. ACM Press.

....decomposition. Decomposition based on grouping entities with similar functionality together. Object Orientated (OO) design is one of the most popular decomposition approaches incorporating this functional decomposition technique, more on this in 2. 1 # Role collaboration based decomposition [40][28][12] Decomposes a system based on the concept that roles can be played by different entities and can create a collaboration. OOram [12] is an example method implementing a role based decomposition. # Domain object decomposition [7] Knowledge of the specific problem domain is used to decompose. ....

Dirk Riehle and Thomas Gross. Role model based framework design and integration. In Proceedings of the conference on Object-oriented programming, systems, languages, and applications,

....The ultimate composed component is a complete application which, for example, provides an interface to start and stop the application, a UI and other functionality. A component can have different roles in a system. Roles represent subsets of related functionality that a component can expose [13]. A component may behave differently to different types of clients. That is, a component exposes different roles to each client. A button, for instance, can have a graphical role (the way it is displayed) at the same time it can have a dynamic role by sending an event when it is clicked on. It ....

....to document what each interface does since each interface is small and has a clear goal. Splitting a component s interface in multiple smaller interfaces causes the total number of interfaces to increase considerably (which can be confusing for developers) However, as Riehle and Gross argue [13], component collaborations are easier to understand when modeled using roles. Example. In the haemo dialysis framework the interfaces are small (see Sections 2 and 3) This indicates that each of them provides an API that is specific to one role, as we suggest in this guideline. The ....

[Article contains additional citation context not shown here]

Riehle D, Gross T. Role model based framework design and integration. Proceedings of OOPSLA '98. ACM Press, 1998; 117--133.

.... often identified with a subsystem or module, the functionality in object oriented systems comes from the cooperation of interacting objects and methods[23, 12] In designing object oriented applications, the importance of modeling how objects cooperate to achieve a specific task is well recognized [24, 15, 19, 3]. Collaboration based or role based design decomposes an object oriented application into a set of collaborations between classes playing certain roles. Each collaboration encapsulates an aspect of the application and describes how participants interact to achieve a specific task. The recovery of ....

....in several collaborations, playing a distinct role in each. Here we have described the collaborations and roles in terms of the design patterns they instantiate. Roles describes the responsibilities of objects in a collaboration, but how a role is actually modeled or specified is often left open [19]. Some design techniques model roles using interfaces [15] or as part of a behavioral contract between participants Observer Composite Mediator Chain of Responsibility Clerk Director Manager Predecessor Predecessor Observer Subject Successor Component Composite Colleague Mediator ....

D. Riehle and T. Gross. Role model based framework design and integration. In Proceedings OOPSLA '98 ACM SIGPLAN Notices, pages 117--133, Oct. 1998.

....follows the time interval of the action DoX. To preserve the sequence in the model we require that the action DoX happens before the action DoY. The mutual influence between roles can be specified in several ways. Examples of different syntax for expressing role s mutual influence can be seen in [Riehle98], Fiadeiro01] Reenskaug96] But the syntax proposed in these works depends on implementation details: roles are assigned to some objects and synthesis is specified as a communication through given object interfaces. These technical details complicate our understanding of synthesis semantics. ....

Riehle, D. and T. Gross. Role Model Based Framework Design and Integration. in Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA '98). 1998: ACM Press.

....of classes. The ultimate composed component is a complete application, which for example provides an interface to start and stop the application, a UI and other functionality. A component can have different roles in a system. Roles represent subsets of related functionality a component can expose [26]. A component may behave differently to different types of clients. That is, a component exposes different roles to each client. A button, for instance, can have a graphical role (the way it is displayed) at the same time it can have a dynamic role by sending an event when it is clicked on. It ....

....easier to document what each interface does since each interface is small and has a clear goal. Splitting a component s interface in multiple smaller interfaces causes the total number of interfaces to increase considerably (which can be confusing for developers) However, as Riehle et al. argue [26], component collaborations are easier to understand when modeled using roles. Example In the haemo dialysis framework the interfaces are small (see 2 and 3) This indicates that each of them provides a API that is specific to one role as we suggest in this guideline. The PeriodicObject interface ....

[Article contains additional citation context not shown here]

Riehle D, Gross T. Role Model Based Framework Design and Integration, Proceedings of OOPSLA '98:117133, ACM Press, 1998.

.... with lightweight linguistic means to group sets of related classes, for example name spaces in C [11] or packages and nested classes in Java [1] On the other hand, the research community has developed a great deal of models related to collaboration or role model based design, for example [4, 15, 29, 34]. Our point of view is that we should not try to invent a completely new kind of module for grouping classes just to realize (sooner or later) that we need means to express variants, hide details, have polymorphism etc. Instead, we propose a model within which all the concepts that proved so ....

....class whenever it satisfies a predicate expression associated with the predicate class. If an object is modified, the classification of an object can change, yielding in a di#erent behavior of the object. There have been a number of proposals related to collaboration or role based design [28, 4, 15, 29, 16, 25]. In contrast to these approaches, delegation layers focus on the definition and on the fly runtime combination of collaboration variants. 8 Summary and Future Work In this paper, we proposed delegation layers, a new mechanism to define and combine sets of collaborating classes and objects. Since ....

D. Riehle and T. Gross. Role model based framework design and integration. In Proceedings OOPSLA '98, 1998.

.... often identified with a subsystem or module, the functionality in object oriented systems comes from the cooperation of interacting objects and methods[22, 12] In designing object oriented applications, the importance of modeling how objects cooperate to achieve a specific task is well recognized [23, 1, 8, 15, 18, 3]. Collaboration based or role based design decomposes an object oriented application into a set of collaborations between classes playing certain roles. Each collaboration encapsulates an aspect of the application and describes how participants interact to achieve a specific task. The recovery of ....

....Successor Observer Composite Component Colleague Mediator Figure 2. Class collaboration matrix for Bureaucracy. Each row represents a collaboration and each cell describes the role the class plays in the collaboration. how a role is actually modeled or specified is often left open [18]. Some design techniques model roles using interfaces [15] or as part of a behavioral contract between participants [8] Collaborations are usually modeled using UML interaction diagrams. These show how participants interact to achieve a task: they are usually succinct and show only one instance ....

D. Riehle and T. Gross. Role model based framework design and integration. In Proceedings OOPSLA '98 ACM SIGPLAN Notices, pages 117--133, Oct. 1998.

....to an objects attributes and methods. Steimann [11] examines roles in the UML and emphasizes the similarity of roles and interfaces. In contrary, we consider roles that have attributes and also mulitplicity demands roles to be instantiable which can not be done with interfaces Riehle et al. [10] emphasize the use of roles in separate role models in order to relate role types. Role types that are appropriately related to each other are then composed to classes. By use of our role classes role models can be built as class diagrams. Relations between roles can be expressed as (stereotyped) ....

Dirk Riehle and Thomas Gross. Role Model Based Framework Design and Integration. ACM SIGPLAN Notices, 33(10):117--133, October 1998.

....Application frameworks [9, 5] have been the first e#ort towards reusable collaborations. However, application frameworks have proven to be too inflexible for a number of reasons, see [14, 21, 15] On the design level, methodologies 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 ....

D. Riehle and T. Gross. Role model based framework design and integration. In Proceedings OOPSLA '98, 1998.

....design of a program or a part of a program expressed as a set of classes [5] 8] Having recognized the importance of object oriented framework, many methodologists propose design methods focusing on framework development. The methods include collaboration based design [3] 4] 10] role based design [14] and design patterns [6] 8] 13] However, desiging well organized frameworks is still an art. Jackson points out two important issues in general on method and problem [7] 1) methods cannot be panaceas (medicines that cure all diseases) and (2) very few problems can be decomposed into ....

Riehle, D. and Gross, T. : Role Model Based Framework Design and Integration, Proc. OOPSLA'98, pp.117-133 (1998).

....than those developed in traditional ways. The notions of role and collaboration are well accepted in object oriented systems design and analysis, e.g. 34] 33] and [13] However, their uses of those two concepts are different from ours, as was concisely illucidated by the following excerpt [27]: Role models provide excellent separation of concerns due to their focus on one particular collaboration purpose, while traditional class diagrams necessarily interwine all different object collaboration aspects. When composing role models, several aspects of object collaborations can be ....

....(some self) is currently in some role. 4.6.2 The Daemon Role A collaboration typically defines a special role called daemon, which controls for example who is allowed to take which roles and how many participants can take a certain role 2 . When a participant attempts to take a role 2 [27] described four possible role constraints: role dontcare, role implied, role equivalent, and role prohibited. Actually more possibilities exist. For example, one can not take on the student role in a given course if she was once the teaching assistant of the from an ongoing session, the daemon of ....

Dirk Riehle and Thomas Gross, Role Model Based Framework Design and Integration, in Proceedings of ACM OOPSLA'98

....levels of detail. The descriptions are quite informal, and this lack of formality may lead to misconceptions by the user. Although the patterns described in (Johnson, 1992) are based on an Alexandrian narrative, they respect a pattern form and can be seen as a cookbook with more structure. Riehle and Gross (1998) proposes an extension of the OOram methodology (Reenskaug et al. 1996) to facilitate framework design and documentation. They propose the use of role diagrams to explicit document the interaction of the framework with its clients. Although this approach produces good results for pattern ....

....work capabilities and graphical representation is now being developed in Java. This tool will be used to experiment with different objet oriented models and evaluate the impact of these models in framework design. More concretely, the tool will provide a uniform way of validating how roles (Riehle and Gross, 1998; Reenskaug et al. 1996) and ADVs (Cowan and Lucena, 1995) can enhance framework design and how they can be used together with UML F. ....

Riehle, D. and Gross, T., Role Model Based Framework Design and Integration, OOPSLA'98, ACM Press, 117-133 (1998).

....the variable method in the hook class. The use of tags that indicate meta pattern roles complement the UML F description for variation points implemented by design patterns, further clarifying the design. A similar solution for identifying design diagrams with pattern roles is described in [30]. ShowCourse separation, template showCourse( selectCourse( showContent( SelectStrategy separation, hook select( dynamic select 1 ConcreteSelect appl class select( ShowCourse showCourse( selectCourse( variable, dynamic showContent( Framework design ....

....However, in a typical framework design a single variation point class can participate in various design patterns. Then the approach of using design pattern names as class names becomes obfuscated. One possible solution for this problem is the use of role based modeling technique, as shown in [30]. Meta level programming [21] which can be seen as an architectural pattern [4] provides a good design solution for allowing runtime system reconfiguration. Therefore, the use of meta level programming is a useful technique for modeling variation points that require runtime instantiation, and ....

[Article contains additional citation context not shown here]

D. Riehle and T. Gross, "Role Model Based Framework Design and Integration", OOPSLA'98, ACM Press, 117-133, 1998.

....and several new associations like the instance type association that specifies how to logically connect an object with its class. 3. 2 Physical Architecture The physical architecture is a set of Java classes (in our case) that interact in well defined ways; it forms an object oriented framework [28, 25]. The physical architecture provides the physical classes for the representation of logical objects. Every object in the logical architecture has both a logical class and a physical class. The logical class defines its model relevant properties and the physical class is the ....

Dirk Riehle and Thomas Gross. "Role Model Based Framework Design and Integration. Dirk Riehle and Thomas Gross." In Proceedings of the

No context found.

D. Riehle, T. Gross, Role Model Based Framework Design and Integration, Proceedings of the 1998.

No context found.

D. Riehle and T. Gross. Role model based framework design and integration. In Proceedings of the 1998.

No context found.

Dirk Riehle and Thomas Gross. Role model based framework design and integration. In Conference on Object-Oriented Programming Systems and Applications (OOPLSA), pages 117--133. ACM Press, 1998.

No context found.

D. Riehle and T. Gross. Role model based framework design and integration. In Proceedings of the 1998.

No context found.

D. Riehle and T. Gross. Role Model Based Framework Design and Integration. In Proc. OOPSLA'98, pages 117--133, 1998.

No context found.

D. Riehle and T. Gross. Role model based framework design and integration. In Proceedings OOPSLA '98, 1998.

No context found.

D. Riehle and T. Gross. Role model based framework design and integration. In Proc. of the Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA), 1998.

No context found.

Dirk Riehle and Thomas Gross, Role Model Based Framework Design and Integration, in Proceedings of ACM OOPSLA'98

No context found.

Riehle, D., T. Gross, "Role Model Based Framework Design and Integration," OOPSLA'98, Proceedings of the 1998 Conference on Object- oriented Programming Systems, Languages and Applications, ACM Press, 1998.

No context found.

Riehle, D., T. Gross, "Role Model Based Framework Design and Integration," OOPSLA'98, Proceedings of the 1998 Conference on Object- oriented Programming Systems, Languages and Applications, ACM Press, 1998.

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