1,721,267 research outputs found

    Open Architectures and Software Evolution: the case of Software Ecosystems

    No full text
    Software systems are increasingly constructed on top of a software platform by adding and composing components that more often than not are developed by external actors. Those platforms project into software systems their own architecture and concepts and impose constraints, this strongly influences how components are developed and/or integrated. It is generally recognized that software architectures play a keyrole in managing software ecosystems and their evolution. While commercially there is an undeniable and increasing interest in software ecosystems, e.g., the Apple's iOS, Google's Android, Amazon.com, research in this domain is still in its infancy. This paper analyses, from the software architecture perspective, the state-of-the-art in software ecosystems and highlights future research directions from a technical point of view. © 2014 IEEE

    Towards a Graphical Tool for Refining User to System Requirements

    No full text
    AbstractInformal and abstract user requirement specifications are usually complemented by formal and detailed system requirement specifications. While user requirements provide a high level description of what services the system is expected to provide, system requirements provide a more technical specification of how that services should be provided by the system. One of the relevant problems that arise during the Requirement Engineering process is the result of failing to make a clear transition between different levels of requirements description.Goal of this paper is to introduce a graphical tool for requirements refinement which guides software architects while moving from user requirements to (architec-tural-level) system requirements. The tool makes use of a previous work that gives a simple but expressive graphical formalism, based on UML2.0 Sequence Diagrams, for specifying temporal properties

    A model-driven approach to detect faults in FOSS systems

    No full text
    Free and Open-Source Software (FOSS) Linux distributions are among the most complex modern software systems. They are made of thousands of components (software packages) evolving rapidly without centralized coordination. The upgrade of FOSS systems is managed by meta-installers, which solve package dependencies and conflicts and lead the system to a new system configuration by installing or removing packages. Current tools are able to predict a very limited set of upgrade faults before deployment, and this leaves a wide range of faults unpredicted. In this paper, we focus on faults that remain unpredicted, for example, missing packages, packages that are not properly installed, and missing services, with the aim of providing a solution for them. Specifically, in this paper, we propose a model-driven approach and supporting tools to prevent specific classes of system configuration faults before performing the real upgrade. Once the system configuration is represented as a model, the configuration model is evaluated by means of queries, each devoted to discover a specific class of faults. The approach is intrinsically extensible so that user communities can add new queries when new classes of faults are identified. The approach has been validated by executing the fault detector on configuration models in which faults have been intentionally injected and by analyzing produced results

    A generated property specification language for resilient multirobot missions

    No full text
    Abstract: The use of robots is gaining considerable traction in several domains, since they are capable of assisting and replacing humans for everyday tasks. To harvest the full potential of robots, it must be possible to define missions for robots that are domain-specific, resilient, and collaborative. Currently, robot vendors provide low-level APIs to program such missions, making mission definition a task-specific and error-prone activity. There is a need for quick definition of new missions, by users that lack programming expertise, such as farmers and emergency workers. In this paper, we extend the existing FLYAQ platform to support the high-level specification of adaptive and highly-resilient missions. We present an extensible specification language that allows users to declaratively specify domain-specific constraints as properties of missions, thus complementing the existing FLYAQ mission language. This permits to move at runtime, the actual generation of low-level operations to satisfy the declaratively specified mission. We show how this specification language can be automatically generated from a domain-specific FLYAQ mission language by using the generative ProMoBox approach. Next, we show how mission goals are achieved taking mission properties into account, and how missions may change due to unexpected circumstances

    Why and how to balance alignment and diversity of requirements engineering practices in automotive

    No full text
    In large-scale automotive companies, various requirements engineering (RE) practices are used across teams. RE practices manifest in Requirements Information Models (RIM) that define what concepts and information should be captured for requirements. Collaboration of practitioners from different parts of an organization is required to define a suitable RIM that balances support for diverse practices in individual teams with the alignment needed for a shared view and team support on system level. There exists no guidance for this challenging task. This paper presents a mixed methods study to examine the role of RIMs in balancing alignment and diversity of RE practices in four automotive companies. Our analysis is based on data from systems engineering tools, 11 semi-structured interviews, and a survey to validate findings and suggestions. We found that balancing alignment and diversity of RE practices is important to consider when defining RIMs. We further investigated enablers for this balance and actions that practitioners take to achieve it. From these factors, we derived and evaluated recommendations for managing RIMs in practice that take into account the lifecycle of requirements and allow for diverse practices across sub-disciplines in early development, while enforcing alignment of requirements that are close to release
    corecore