Dependable software deployment

2011

Abstract Modern software systems are built by composing components drawn from large repositories, whose size and complexity is increasing at a very fast pace. A fundamental challenge for the maintainability and the scalability of such software systems is the ability to quickly identify the components that can or cannot be installed together: this is the co-installability problem, which is related to boolean satisfiability and is known to be algorithmically hard.

2014

Changes during a software products life cycle are inevitable. These changes can correct or enhance software functionality and/or reduce costs associated with the software product. However, changes can also introduce added risks and unknowns during a software products life cycle and can result in unpredictable software behavior. Software configuration management (SCM) is a part of configuration management (CM) which supports a complex framework for monitoring, managing, and controlling changes to a software products configuration during its life cycle. In this paper, we introduce the development of a relational metrics model as a possible means for better managing and controlling software configuration change during a software products life cycle from the SCM activities, software engineering measures, and any available CM metrics. This relational approach to managing changes within a software product life cycle will result in a more effective means of validating change configurations...

Deployment requirements describe the precise, desired configuration of a software system. They relate the system's non functional requirements to its architecture, providing a basis for making decisions about design trade-offs in terms of the resulting system's non functional properties. The purpose of this position paper is to propose a research direction towards developing an approach for reasoning about deployment decisions. Its main objective is to quantitatively evaluate and select between different potential architecture solutions in order to shorten customer time-to-value and increase satisfaction. In this paper we analyze the relationship between deployment requirements and non-functional properties, and discuss work in progress of developing a deployment-based methodology for evaluating software architecture.

Recently, the software industry has begun to adopt a product family approach. Support tools for tailoring configurable product families have been developed for some time for mechanical and electronics products. However, it is not clear that the modeling languages designed for these configurators are suitable for software product configuration. In this paper, we investigate this problem by modeling a Linux Familiar operating system distribution with a configuration modeling language aimed at representing the structure of physical products. Findings from this case study suggest that the language is largely suitable for software product configuration. However, some phenomena in the product strongly suggest that modeling them as functions, features or resources and optimality criteria familiar from the configuration domain would be useful. In addition, there is some evidence that deeper modeling of versions of components and reconfiguration knowledge, not usually covered by configuratio...

2005

Configuring large-scale software to meet different user requirements is a challenging process, since endusers do not know the technical details of the system in the first place. We present an automatic process to connect high-level user requirements with low-level system's configurations. The process takes into account different user preferences and expectations, making configuration easier and more user-centered. Since it reuses a software system's configuration mechanisms, the configuration process is transparent to the system development. Moreover, it is very easy to plug different reasoning frameworks into the configuration process. As a case study, we have reengineered the Mozilla Firefox web browser into a requirements-driven software system, without changing its source code.

Lecture Notes in Computer Science, 2000

The principle of modularisation is one of the main techniques that software designers use to tame the complexity of programming. A software project, however, is complex in many other areas than just programming. In this paper, we focus on one of these complex areas, namely software configuration management, and outline how modularisation is natural and powerful also in this context. The analysis is partly based on experiences from case studies where small-to medium-sized development projects are using a prototype tool that supports modular software configuration management. 1 Note that a Ragnarok component does not form a unit of separate deployment and should not be confused with 'component' as defined in e.g. COM or CORBA.

2001

One of the basic problems when developing component-based systems is that it is difficult to keep track of components and their interrelationships. This problem emerges already in the requirement phase, in which we want to identify and select the most appropriate components. Later, during the assembly and deployment process, or when upgrading components, the problem of components identification and dependency management becomes even more important. One way to maintain control over upgrades is to use component identification and dependency analysis. These are well known techniques for managing system configurations during development, but are rarely applied in managing run-time dependencies. Knowledge of the possible impacts of an update is important, since it can be used to limit the scope of testing and be a basis for evaluating the potential damage of the update. In this paper we analyse different types of dependencies and discuss how to identify and specify them, in analogy with Makefiles. The dependencies can be showed in a form of a dependency graph. The dependency graphs can also be used to facilitate maintenance by identifying differences between configurations, e.g., making it possible to recognise any deviations from a functioning reference configuration.

2012

The EDOS research project aims at contributing to the quality assurance of free software distributions. This is a major technical and engineering challenge, due to the size and complexity of these distributions (tens of thousands of software packages). We present here some of the challenges that we have tackled so far, and some of the advanced tools that are already available to the community as an outcome of the first year of work.

2010

The article proposes a model for the configuration management of open systems. The model aims at validation of configurations against given specifications. An extension of decision graphs is proposed to express specifications. The proposed model can be used by software developers to validate their own configurations across different versions of the components, or to validate configurations that include components by third parties. The model can also be used by end-users to validate compatibility among different configurations of the same application. The proposed model is first discussed in some application scenarios and then formally defined. Moreover, a type discipline is given to formally define validation of a configuration against a system specification.

Marmoset is a simple unix-based tool for creating and maintaining large systems built from reusable "modules". Marmoset provides unix commands for creating and editing modules, and for configuring modules so that they produce object code, libraries, or executables, as the case may be, from the component modules. A Marmoset module is implemented as a unix directory containing a number of files, some of which are supplied by the user, and others of which are generated automatically. For a given language, a user will supply a number of component files, including an "import" list of other modules which are required for this module to be configurable. The generated files might contain, among other things, external declarations and compiled code. The Marmoset link command automatically identifies all those modules imported directly or indirectly by the root module, and ensures (by reconfiguring if necessary) that all the output files are up to date. Should a particular version of a module be looked for, then the most relevant versions of the imported modules will be sought, and the most relevant versions of component files will be used. Marmoset significantly reduces the cost of software configuration, and thereby increases software reliability.