101,725 research outputs found
Adaptive development and maintenance of user-centric software systems
A software system cannot be developed without considering the various facets of its environment. Stakeholders – including the users that play a central role – have their needs, expectations, and perceptions of a system. Organisational and technical aspects of the environment are constantly changing. The ability to adapt a software system and its requirements to its environment throughout its
full lifecycle is of paramount importance in a constantly changing environment. The continuous involvement of users is as important as the constant evaluation of the system and the observation of evolving environments. We present a methodology for adaptive software systems development and
maintenance. We draw upon a diverse range of accepted methods including participatory design, software architecture, and evolutionary design. Our focus is on user-centred software systems
MORPH: A Reference Architecture for Configuration and Behaviour Self-Adaptation
An architectural approach to self-adaptive systems involves runtime change of
system configuration (i.e., the system's components, their bindings and
operational parameters) and behaviour update (i.e., component orchestration).
Thus, dynamic reconfiguration and discrete event control theory are at the
heart of architectural adaptation. Although controlling configuration and
behaviour at runtime has been discussed and applied to architectural
adaptation, architectures for self-adaptive systems often compound these two
aspects reducing the potential for adaptability. In this paper we propose a
reference architecture that allows for coordinated yet transparent and
independent adaptation of system configuration and behaviour
Towards a Framework for Managing Inconsistencies in Systems of Systems
The growth in the complexity of software systems has led to a proliferation of systems that have been created independently to provide specific functions, such as activity tracking, household energy management or personal nutrition assistance. The runtime composition of these individual systems into Systems of Systems (SoSs) enables support for more sophisticated functionality that cannot be provided by individual constituent systems on their own. However, in order to realize the benefits of these functionalities it is necessary to address a number of challenges associated with SoSs, including, but not limited to, operational and managerial independence, geographic distribution of participating systems, evolutionary development, and emergent conflicting behavior that can occur due interactions between the requirements of the participating systems. In this paper, we present a framework for conflict management in SoSs. The management of conflicting requirements involves four steps, namely (a) overlap detection, (b) conflict identification, (c) conflict diagnosis, and (d) conflict resolution based on the use of a utility function. The framework uses a Monitor-Analyze-Plan- Execute- Knowledge (MAPE-K) architectural pattern. In order to illustrate the work, we use an example SoS ecosystem designed to support food security at different levels of granularity
Pattern Reification as the Basis for Description-Driven Systems
One of the main factors driving object-oriented software development for
information systems is the requirement for systems to be tolerant to change. To
address this issue in designing systems, this paper proposes a pattern-based,
object-oriented, description-driven system (DDS) architecture as an extension
to the standard UML four-layer meta-model. A DDS architecture is proposed in
which aspects of both static and dynamic systems behavior can be captured via
descriptive models and meta-models. The proposed architecture embodies four
main elements - firstly, the adoption of a multi-layered meta-modeling
architecture and reflective meta-level architecture, secondly the
identification of four data modeling relationships that can be made explicit
such that they can be modified dynamically, thirdly the identification of five
design patterns which have emerged from practice and have proved essential in
providing reusable building blocks for data management, and fourthly the
encoding of the structural properties of the five design patterns by means of
one fundamental pattern, the Graph pattern. A practical example of this
philosophy, the CRISTAL project, is used to demonstrate the use of
description-driven data objects to handle system evolution.Comment: 20 pages, 10 figure
Some Findings Concerning Requirements in Agile Methodologies
gile methods have appeared as an attractive alternative to conventional methodologies. These methods try to reduce the time to market and, indirectly, the cost of the product through flexible development and deep customer involvement. The processes related to requirements have been extensively studied in literature, in most cases in the frame of conventional methods. However, conclusions of conventional methodologies could not be necessarily valid for Agile; in some issues, conventional and Agile processes are radically different. As recent surveys report, inadequate project requirements is one of the most conflictive issues in agile approaches and better understanding about this is needed. This paper describes some findings concerning requirements activities in a project developed under an agile methodology. The project intended to evolve an existing product and, therefore, some background information was available. The major difficulties encountered were related to non-functional needs and management of requirements dependencies
Contract Aware Components, 10 years after
The notion of contract aware components has been published roughly ten years
ago and is now becoming mainstream in several fields where the usage of
software components is seen as critical. The goal of this paper is to survey
domains such as Embedded Systems or Service Oriented Architecture where the
notion of contract aware components has been influential. For each of these
domains we briefly describe what has been done with this idea and we discuss
the remaining challenges.Comment: In Proceedings WCSI 2010, arXiv:1010.233
- …