Results 11 - 20
of
31
Assessing Optimal Software Architecture Maintainability
- fifth European Conference on Software Maintainability and Reengineering, 2002
, 2002
"... Over the last decade, several authors have studied the maintainability of software architectures. In particular, the assessment of maintainability has received attention. However, even when one has a quantitative assessment of the maintainability of a software architecture, one still does not have a ..."
Abstract
-
Cited by 8 (1 self)
- Add to MetaCart
Over the last decade, several authors have studied the maintainability of software architectures. In particular, the assessment of maintainability has received attention. However, even when one has a quantitative assessment of the maintainability of a software architecture, one still does not have any indication of the optimality of the software architecture with respect to this quality attribute. Typically, the software architect is supposed to judge the assessment result based on his or her personal experience. In this paper, we propose a technique for analysing the optimal maintainability of a software architecture based on a specified scenario profile. This technique allows software architects to analyse the maintainability of their software architecture with respect to the optimal maintainability. The technique is illustrated and evaluated using industrial cases. 1. Introduction Over the last decade, we have come to the understanding that the challenging task of the development ...
Component Evolution in Product-Line Architectures
- In Proceedings of International Workshop on Component Based Software Engineering
, 1999
"... The results of a case study investigating the experiences of component-based software development in the context of a product-line architecture are presented. The case study involves two companies, i.e. Axis Communications AB and Securitas Larm AB that employ product-line architectures. The paper di ..."
Abstract
-
Cited by 6 (2 self)
- Add to MetaCart
The results of a case study investigating the experiences of component-based software development in the context of a product-line architecture are presented. The case study involves two companies, i.e. Axis Communications AB and Securitas Larm AB that employ product-line architectures. The paper discusses the differences between the academic and the industrial view on software components, the problems associated with using reusable components in product-line architectures identified in the case study and, finally, a cause analysis. 1 Introduction Reusable components have been a goal of the software engineering research community for several decades. Over the years, much research effort has been spent on achieving this goal, e.g. [Weck et al. 97] and [Weck et al. 98]. At least, two important lessons with respect to component-based software development have been learned over the years. First, opportunistic reuse of components does not work and any form of component reuse requires a ma...
Managing Feature Interaction by Documenting and Enforcing Dependencies in Software Product Lines
"... Abstract. Software product line engineering provides a systematic approach for the reuse of software assets in the production of similar software systems. For such it employs different variability modeling and realization approaches in the development of common assets that are extended and configure ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
(Show Context)
Abstract. Software product line engineering provides a systematic approach for the reuse of software assets in the production of similar software systems. For such it employs different variability modeling and realization approaches in the development of common assets that are extended and configured with different features. The result is usually generalized and complex implementations that may hide important dependencies and design decisions. Therefore, whenever software engineers need to extend the software product line assets, there may be dependencies in the code that, if not made explicit and adequately managed, can lead to feature interference. Feature interference happens when a combined set of features that extend a shared piece of code fail to behave as expected. Our experience in the development of YANCEES, a highly extensible and configurable publish/subscribe infrastructure product line, shows that the main sources of feature interference in this domain are the inadequate documentation and management of software dependencies. In this paper, we discuss those issues in detail, presenting the strategies adopted to manage them. Our approach employs a contextual plug-in framework that, through the explicit annotation and management of dependencies in the software product line assets, better supports software engineers in their extension and configuration.
Towards Intelligent Support for Managing Evolution of Configurable Software Product Families
- IN: PROCEEDINGS OF 11TH INTERNATIONAL WORKSHOP ON SOFTWARE CONFIGURATION MANAGEMENT (SCM-11), LNCS 2649SPRINGER
, 2003
"... Software product families are a means for increasing the efficiency of software development. We propose a conceptualisation for modelling the evolution and variability of configurable software product families. We describe a first prototype of an intelligent tool that allows modelling a software pr ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
(Show Context)
Software product families are a means for increasing the efficiency of software development. We propose a conceptualisation for modelling the evolution and variability of configurable software product families. We describe a first prototype of an intelligent tool that allows modelling a software product family on the basis of the conceptualisation and supports the user in interactively producing correct configurations with respect to the model. The implementation is based on an existing general purpose configurator and thus is not application domain specific. We use the Debian Familiar Linux package configuration task over many releases and package versions as an example. Preliminary results show that the conceptualisation can be used to model evolution of such a software product family relatively easily and the implementation performs acceptably.
Managing Variability in Software Product Lines
"... Software Product Lines are large systems intended for reuse in concrete products. As such these large systems provide reusable architecture and implementation that the individual products have in common. The differences between the product are left open. We refer to these open spots as variabilit ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
Software Product Lines are large systems intended for reuse in concrete products. As such these large systems provide reusable architecture and implementation that the individual products have in common. The differences between the product are left open. We refer to these open spots as variability points. In this article we provide a conceptual framework of terminology for the concept of variability and we discuss how variability can be managed in Software Product Lines.
Software Product Lines from Customer to Code
, 2000
"... The process of establishing a software product line and instantiating products from it is motivated, not only by technical reasons, but also by business reasons. The customer perspective reveals the importance of the basic function of the products and helps us distinguish between product lines and p ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
The process of establishing a software product line and instantiating products from it is motivated, not only by technical reasons, but also by business reasons. The customer perspective reveals the importance of the basic function of the products and helps us distinguish between product lines and product families. One single feature is never the only difference between two products, but instead we can identify products on different feature levels. When designing the product we identify that it is important to separate between conceptual components of the domain and factual components that are part of the solution. Product lines must eventually lead to implementation and source code. In order to achieve this, a wide range of implementation techniques is available. Which combination of techniques that is the most appropriate is very much dependent on if the product is part of a product line or a product family, and how the factual component relate to the other factual components. Hence, to be successful in developing software product lines requires the application of knowledge about both the customer and the code.
Managing Unanticipated Evolution of Software Architectures
- in ECOOP’99 Workshop on Architectural Evolution
, 1999
"... Few existing approaches towards architectural evolution deal with unanticipated evolution. This is an important restriction, since a lot of architectural changes are very difficult to anticipate. The reuse contract formalism has been designed specifically to deal with unanticipated software evolutio ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Few existing approaches towards architectural evolution deal with unanticipated evolution. This is an important restriction, since a lot of architectural changes are very difficult to anticipate. The reuse contract formalism has been designed specifically to deal with unanticipated software evolution, and has already proven its practical use in different domains. We claim that the reuse contract approach can be applied to the domain of software architectures, to manage unanticipated evolution of software architectures.
A study of architectural information foraging in software architecture documents
- In Working IEEE/IFIP Conference on Software Architecture (WICSA) and European Conference on Software Architecture (ECSA
, 2012
"... Abstract—When using Software Architecture documents (ADs), users typically “forage ” for information. However, it is little understood how they do this foraging or how to structure architecture documentation to assist them. We conducted a survey of two different groups of foragers, industry practiti ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
(Show Context)
Abstract—When using Software Architecture documents (ADs), users typically “forage ” for information. However, it is little understood how they do this foraging or how to structure architecture documentation to assist them. We conducted a survey of two different groups of foragers, industry practitioner and academic AD users, to investigate issues – types of forages, foraging sequences and styles- related to task-based architectural information foraging in software architecture documents. Our results show that there were different pre-conceived ideas of what to forage for prior to the search, but during foraging there was commonly foraged information. The different groups of foragers place different emphasis on information related to quality requirements, purpose of the system, use cases, physical view and process view. Foraging sequences starting with certain information were suggested to better support understanding of the described SA. These sequences typically followed the written order of the information as dictated by the AD producers. This reinforces the critical responsibility of AD producers to structure the architectural information for understanding. Diagrams, views and design decisions were most frequently cited as supporting understanding of the SA. The main hindrance was too much text and a lack of diagrams.
