Thank you for downloading designing software product lines with uml from use cases to pattern based software architectures. Maybe you have knowledge that, people have look hundreds times for their chosen books like this designing software product lines with uml from use cases to pattern based software architectures, but end up in malicious downloads. Rather than reading a good book with a cup of tea in the afternoon, instead they cope with some infectious virus inside their desktop computer.

Designing Software Product Lines With Uml From Use Cases To Pattern Based Software Architectures

Software engineering in the automotive domain faces outstanding challenges in terms of quality, cost, and functional complexity. To ensure process and product excellence, Bosch Gasoline Systems (GS) introduced a process improvement program based on Capability Maturity Model Integration (CMMI) and adopted the product line approach (PLA). Business strategies for software products, software sharing with customers, and common solutions for diesel and gasoline engine control software are inputs for the product line architecture. The steps towards the PLA started with an evaluation project followed by an evolutionary rollout. The lack of suitable mechanisms and tools for some crucial nonfunctional requirements is a major drawback for introducing the PLA. Nevertheless, GS considers it the only systematic approach to dealing with current and future challenges.

Introducing PLA at Bosch Gasoline systems: Experiences and practices

Context: Software Product Lines (SPL) evolve when there are changes in the requirements, product structure or the technology being used. Different approaches have been proposed for managing SPL assets and some also address how evolution affects these assets. Existing mapping studies have focused on specific aspects of SPL evolution, but there is no cohesive body of work that gives an overview of the area as a whole. Objective: The goals of this work are to review the characteristics of the approaches reported as supporting SPL evolution, and to synthesize the evidence provided by primary studies about the nature of their processes, as well as how they are reported and validated. Method: We conducted a systematic literature review, considering six research questions formulated to evaluate evolution approaches for SPL. We considered journal, conference and workshop papers published up until March 2017 in leading digital libraries for computer science. Results: After a thorough analysis of the papers retrieved from the digital libraries, we ended up with a set of 60 primary studies. Feature models are widely used to represent SPLs, so feature evolution is frequently addressed. Other assets are less frequently addressed. The area has matured over time: papers presenting more rigorous work are becoming more common. The processes used to support SPL evolution are systematic, but with a low level of automation. Conclusions: Our research shows that there is no consensus about SPL formalization, what assets can evolve, nor how and when these evolve. Case studies are quite popular, but few industrial-sized case studies are publicly available. Also, few of the proposed techniques offer tool support. We believe that the SPL community needs to work together to improve the state of the art, creating methods and tools that support SPL evolution in a more comparable manner.

Software product line evolution: A systematic literature review

To keep the software development for vehicles cost efficient, software components are reused for different variants as well as for succeeding generations. Furthermore, cost reductions are achieved by software sharing between the Original Equipment Manufacturer (OEM) and the suppliers. However, as a consequence of the blackboxed view caused by software sharing, no common detailed software product line architecture specification for the Electronic Control Unit (ECU) software exists, as it would be required for analyzing the quality of the product line architecture, planning changes on the product line architecture, checking the compliance between the product architecture and the product line architecture, and therefore, avoiding architecture erosion. Thus, after several product generations, software erosion is growing steadily, resulting in an increasing effort of reusing software components, and planning of further development. Here, we propose an approach for repairing an eroded software consisting of a set of product architectures by applying strategies for recovery and discovery of the product line architecture. Furthermore, we give a methodology for a long-term manageable, plannable, and reuseable software product line architecture for automotive software systems.

From product architectures to a managed automotive software product line architecture

Migrating a family of software systems from ad-hoc development approaches such as `clone-and-own' towards software product lines (SPL) is a challenging task. Software architecture recovery techniques can play a crucial role in such a migration. However, it is to date still unclear how these techniques, which have been mostly developed for single system architecture recovery in mind, can be utilized in an SPL context most effectively. In this paper, we present a mapping study examining 35 research articles with the purpose of discussing the current state of the art in applying software architecture recovery techniques for SPL and identifying potential research gaps in this area. The results provide evidence that currently used approaches do not seem to consider the potential architectural degradation that might exist in the family of systems to be migrated. Moreover, it is hard to generalize across empirical studies as currently it seems difficult to compare and benchmark the approaches applied for software product line architecture (SPLA) extraction/reconstruction.

A mapping study of software architecture recovery for software product lines

Most automobile manufacturers maintain many vehicle types to keep a successful position on the market. Through the further development all vehicle types gain a diverse amount of new functionality. Additional features have to be supported by the car’s software. For time efficient accomplishment, usually the existing electronic control unit (ECU) code is extended.

Mastering Erosion of Software Architecture in Automotive Software Product Lines

Applications provided by software intensive systems in an Internet of Things environment offer new business opportunities from the industry.
An application describes the expected behavior of the software system. Thereby, the steps of a business process (e.g., event booking) are determined using objects from the Internet of Things environment at run-time. The system behavior is determined at run-time and described as a composition of software components based on service descriptions. These software systems can be developed as so-called dynamic adaptive systems. Therefore, developers define a structure based on software components of the system for an application from the system context at design-time. Then, the selection of software components instances by the system takes place at run-time. However, an Internet of Things environment changes its state constantly over life time and thus, the required structure of a software system can not be defined at design-time. Hence, applications of a dynamic adaptive system must be determined at run-time.
In this paper, we introduce our vision of an emergent platform as an architecture for the development of a dynamic adaptive system. Such a system is capable of determining an application and compose a service based process that fulfills this application at run-time.
Furthermore, we provide two Internet of Things scenarios and describe challenges on the basis of the scenarios which need to be tackled to enable the implementation of our architecture.

/pdf/dynamic-adaptive-system-composition-driven-by-emergence-in-edc0ybzpcl.pdf

Dynamic adaptive system composition driven By emergence in an IoT based environment: Architecture and challenges

Nowadays, automotive software complexity is handled by using tool-based and model-driven development approaches. Thus, multiple tools and specialized Architecture Description Languages (ADLs) are used at different stages of the development process. This has led to process and tooling gap between these languages. This paper aims to introduce a solution for the integration problem that exists between tool chains used in the automotive domain. The main goal of this solution is to find an effective semi-automated method that can be used to create model transformation between different automotive ADLs. Our solution provides a refinement to the current approaches of model matching and automated model transformation in order to make them more applicable in the case of complex meta-models. Furthermore, it introduce an iterative algorithm for finding correspondence element between tow meta-models.

https://www.actapress.com/PaperInfo.aspx?paperId=456117

Model transformation for domain specific architecture languages in the automotive software development

/pdf/a-catalog-based-platform-for-integrated-development-of-47qv0nd8we.pdf

Arthur Strasser

Papers

Mastering Erosion of Software Architecture in Automotive Software Product Lines

From product architectures to a managed automotive software product line architecture

Dynamic adaptive system composition driven By emergence in an IoT based environment: Architecture and challenges

Model transformation for domain specific architecture languages in the automotive software development

A Catalog-based Platform for Integrated Development of Simulation Models