| 61. |
- Bosch, Jan
(författare)
-
Evolution and composition of reusable assets in product-line architectures : A case study
- 1999
-
Konferensbidrag (refereegranskat)abstract
- In this paper, a case study investigating the experiences from evolution and modification of reusable assets in product-line architectures is presented involving two Swedish companies, Axis Communications AB and Securitas Larm AB. Key persons in these organisations have been interviewed and information has been collected from documents and other sources. The study identified problems related to multiple versions of reusable assets, dependencies between assets and the use of assets in new contexts, The problem causes have been identified and analysed, including the early intertwining of functionality, the organizational model, the time to market pressure, the lack of economic models and the lack of encapsulation boundaries and required interfaces.
|
|
| 62. |
- Bosch, Jan, et al.
(författare)
-
Framework Problems and Experiences
- 1999
-
Ingår i: Building Application Frameworks. - : Wiley & Sons. - 0471248754 ; , s. 55-82
-
Bokkapitel (övrigt vetenskapligt/konstnärligt)
|
|
| 63. |
|
|
| 64. |
- Bosch, Jan
(författare)
-
Language Support for Design Patterns
- 1995
-
Rapport (refereegranskat)abstract
- Design patterns have proven to be useful for the design of object-oriented systems. The power of a design pattern lies in its ability to provide generic solutions that can be specialised for particular situations. The implementation of design patterns has received only little attention and we have identified two relevant problems associated with the implementation. First, the traceability of a design pattern in the implementation is often insufficient; often the design pattern is `lost'. Second, implementing design patterns may present significant implementation overhead for the software engineer. Often, a, potentially large, number of simple methods has to be implemented with trivial behaviour, e.g. forwarding a message to another object. In this paper, the layered object model (LayOM) is presented. LayOM provides language support for the explicit representation of design patterns in the programming language. LayOM is an extended object-oriented language in that it contains several components that are not part of the conventional object model, such as states, categories and layers. Layers are used to represent design patterns at the level of the programming language and example layer types for four design patterns are presented. LayOM is supported by a development environment that translates LayOM code into C++. The generated C++ code can be used as any C++ code for the development of applications. An important aspect of LayOM is that the language itself is extensible. This allows new design patterns to be added to the language model.
|
|
| 65. |
|
|
| 66. |
- Bosch, Jan, et al.
(författare)
-
Multiple Object Interfaces in Object-Oriented Control Systems
- 1996
-
Konferensbidrag (refereegranskat)abstract
- When modelling complex computer systems, four primary modelling techniques are available to the software engineer, i.e. abstraction, composition, functional decomposition and multiple client interfaces (views). Abstraction and composition can directly be expressed in traditional object-oriented models and functional decomposition can often be expressed using subsystems. However, traditional object models provide no expressiveness for multiple client interfaces. This forces designers to either model all different views on a conceptual object as a large, complex implementation object or to model each view as an object and relate the different view objects. Both approaches suffer from problems of complexity, maintainability and reusability. As a solution, we propose the layered object model that allows for the expressive, flexible and extensible definition of multiple client interfaces. To illustrate the problems associated with views and our proposed solution, the domain of industrial control systems is used.
|
|
| 67. |
- Bosch, Jan
(författare)
-
Object Acquaintance Selection and Binding
- 1998
-
Ingår i: Theory and Practice of Object Systems. - 151-68 : Wiley. - 1074-3227 .- 1096-9942. ; 4:3
-
Tidskriftsartikel (refereegranskat)abstract
- Large object-oriented systems have at least four characteristics that complicate object communication: the system is distributed, it contains large numbers of objects, objects need to be reallocated at run-time, and objects can be replaced by other objects in order to adapt to the dynamic changes in the system. Traditional object communication is based on sending a message to a receiver object known to the sender of the message. At linking or instantiation time, an object establishes its acquaintances through name/class-based binding and uses these objects throughout its lifetime. If this is too rigid, the software engineer has to implement the binding of objects manually using pointers. We found the traditional acquaintance communication semantics to be too limited, and we identified several problems related to the reusability of objects and selection mechanisms, understandability and expressiveness. It is important to separate a class or object's requirements on its acquaintances from the way an object selects and binds its acquaintances in actual systems. We studied the necessary expressiveness for acquaintance handling and identified four relevant aspects: type and duration of binding, conditions for binding, number of selected objects, and selection region for binding. To implement these aspects, we defined acquaintance layers as part of the layered object model. Acquaintance layers uniformly extend the traditional OO acquaintance handling semantics and allow for the first-class representation of acquaintance selection and binding, thereby increasing traceability and reusability
|
|
| 68. |
- Bosch, Jan
(författare)
-
Object Acquaintance Selection and Binding
- 1996
-
Rapport (refereegranskat)abstract
- Large object-oriented systems have, at least, four characteristics that complicate object communication, i.e the system is distributed and contains large numbers, e.g. thousands, of objects, objects need to be reallocated at run-time and objects can be replaced by other objects in order to adapt to the dynamic changes in the system. Traditional object communication is based on sending a message to a receiver object known to the sender of the message. At linking or instantiation time, an object establishes its acquaintances through name/class-based binding and uses these objects through its life time. If this is too rigid, the software engineer has to implement the binding of objects manually using pointers. In our experiments we found the traditional acquaintance communication semantics too limited and we identified several problems, related to the reusability of objects and selection mechanisms, understandability and expressiveness. We recognised that it is important to separate a class or object's requirements on its acquaintances from the way an object selects and binds its acquaintances in actual systems. Based on this observation, we studied the required expressiveness for acquaintance handling and identified four relevant aspects: type and duration of binding, conditions for binding, number of selected objects and selection region for binding. To implement these aspects, we defined acquaintance layers as part of the layered object model. Acquaintance layers uniformly extend the traditional object-oriented acquaintance handling semantics and allow for the first-class representation of acquaintance selection and binding, thereby increasing traceability and reusability.
|
|
| 69. |
- Bosch, Jan
(författare)
-
Object-Oriented Frameworks : Problems & Experiences
- 1997
-
Rapport (refereegranskat)abstract
- Reuse of software has been one of the main goals of software engineering for decades. Reusing software is not simple and most efforts resulted in small reusable, black-box components. With the emergence of the object-oriented paradigm, the enabling technology for reuse of larger components became available and resulted in the definition of object-oriented frameworks. Frameworks attracted attention from many researchers and software engineers and frameworks have been defined for a large variety of domains. The claimed advantages of frameworks are, among others, increased reusability and reduced time to market for applications. Although several examples have shown these advantages to exist, there are problems and hindrances associated with frameworks that may not appear before their usage in real projects. The authors have been involved in the design, maintenance and usage of several object-oriented frameworks and based on the experiences from these projects, a number of problems related to frameworks are descr ibed. The problems are organised according to four categories, i.e. framework development, usage, composition and maintenance. For each category, the most relevant problems and experiences are presented. This paper may help software engineers to avoid the described problems, whereas researchers may try to address these topics in their research.
|
|
| 70. |
- Bosch, Jan, et al.
(författare)
-
OOSA '98 : ECOOP'98 Workshop on Object-Oriented Software Architectures - Workshop summary
- 1998
-
Konferensbidrag (refereegranskat)abstract
- Recently, one can recognize an increased awareness in the object-oriented research community with respect to the role of software architectures. Examples of this can, among others, be found in object-oriented frameworks and design patterns. In the call for papers for the workshop, the following topics were identified where software architecture, patterns and frameworks should be studied in more detail: – Building OO software architectures: How can design patterns, frameworks and components be included in the traditional object-oriented analysis and design? How are architecture constraints processed to build OO software architectures? Which techniques can help to build an OO architecture that supports reuse and is scalable? – Language role in architecture: What is the role of a particular object-oriented language when designing an architecture? – Architecture documentation: It has been suggested that design patterns can be used to document the design and rationale of an object-oriented architecture. How well does this work in practice? – OO architectural styles: What is the relation between the architectural styles of Garlan and Shaw and OO design? – Composition of architectures: Since object-oriented frameworks are an accepted technology within the software industry, the composition of two or more frameworks in an application occurs increasingly often. The composition may be far from trivial and the problems that may appear as well as solutions should be investigated.
|
|
