Ralf Reussner - Birgit Vogel-Heuser Jan Keim

Jan Keim Institute for Program Structures and Data Organization, Karlsruhe Institute of Technology (KIT), Karlsruhe, Germany. Stephan Seifermann Institute for Program Structures and Data Organization, Karlsruhe Institute of Technology (KIT), Karlsruhe, Germany.

Introduction

Introducing Managed Software Evolution

Designing long-lived software didn't take the turn of the millennium into account, leading to a wide variety of problems. The second part of the book contains major chapters on knowledge-transferring software, starting with Chapter 5 on tacit knowledge in software development.

Fig. 1.1 Integration of the development and operation of hardware/software systems [Li+12]

The Nature of Software Evolution

Introduction
Software Systems

Application Domains
Scopes and Environments of Software Systems
Software Artefacts
Software Variants

Software Quality

Consistency
Correctness
Dependability
Performance
Usability
Maintainability

Software Evolution

Kinds of Software Change
Evolution Processes
Configuration Management

Our thinking about the nature of software development is largely independent of the application domains for software systems. In the following, we recall the main aspects of the quality of software systems and give examples.

Addressed Challenges

Tacit Knowledge
Design Decisions
Software Product Line Round-Trip Engineering
Maintaining Performance
Maintaining Security
Learning from Evolution for Evolution
Maintaining Correctness

One variant is related to the co-evolution of different systems perspective models. System knowledge is present in both specification artifacts and program code executed on the system.

Fig. 3.1 Design for future—addressed challenges

Introduction to Case Studies

Evolution of Long-Living Systems to an Industry 4.0 Case Study

Context includes the mechanical aspects of the system, such as pure mechanical components, sensors and actuators. Modularity, which is one of the key aspects to enable the development of software-intensive systems [PCW84], is still rarely fully utilized in aPS [Vog+17b].

Fig. 4.1 V-Model XT integrated into the life cycle of different disciplines in aPS distinguishing between project-independent activities (top) and project-related activities (bottom) [Vog+15c]

Introduction of the CoCoME Case Study

Platform Migration
Adding a Pick-Up Shop
Database Migration
Adding a Mobile App Client
Microservice Architecture
Container Virtualization
Adding Payment Methods

The frontend of the hybrid cloud-based variant of CoCoME uses Java Server Faces (JSF) to implement the user interface (Fig. 4.6). An adaptive evolution of the hybrid cloud-based variant of CoCoME is reflected in the Platform Migration, Microservice Architecture, and Container Virtualization scenarios due to evolving technology. In this adaptive evolution scenario, the functionality of CoCoME remains the same while the architectural paradigm of the system changes.

Fig. 4.4 Basic use cases of CoCoME [Her+08b]

Introduction of the PPU and xPPU Case Studies

Evolution Scenarios of the PPU
Incremental Evolution Scenarios
Evolution Scenarios of the xPPU

The crane now places the WPs directly on the conveyor belt, which transports the WPs to a slide mounted at the end of the conveyor belt. Scenario Sc13: Up to this scenario, crane positioning is done with digital position sensors. Black WPs cross both side ramps and transfer to the ramp at the end of the conveyor belt.

Fig. 4.15 Overview of the PPU and xPPU production chain

Industry 4.0 Case Study

Industry 4.0 Interface of the xPPU
Integration of CoCoME and xPPU to Form an Industry 4.0 Case Study4.0 Case Study

From the plant, information about the status of the plant or the execution of the operations is delivered to the user side. The production units of the plants use this list to carry out the appropriate operations [Bic+18]. A detailed description of the components of the industry 4.0 variant of CoCoME is given in the technical report [Bic+18].

Fig. 4.21 Overview of the concept of dynamic reconfiguration and generation of the Industry 4.0 interface [Bou+17a]

Knowledge Carrying Software

Tacit Knowledge in Software Evolution

Toward Identification and Extraction of Tacit Knowledge

We follow the hypothesis that the utilization of tacit knowledge allows the requirements for long-lasting systems to be kept consistent and complete throughout the system's life cycle. Both approaches share similar challenges: discovering, understanding and transforming users' tacit knowledge into explicit knowledge. Both approaches aim to improve the current set of requirements for a given problem and the understanding of the real users by continuously transforming tacit knowledge into explicit knowledge.

Foundations

The approaches address the two main challenges as described in Sect.3.1: identification and extraction of tacit knowledge, as well as disclosure of deviations in requirements. Gigerenzer [Gig08] uses the comparison of a native speaker who - while they can find a sentence to be grammatically correct - they are usually unable to verbalize the underlying grammar; he calls this gut feeling and uses the term interchangeably with intuition and hunch [Gig08]. He develops the concept of tacit knowledge in action by noting that practitioners continuously make decisions in the course of their daily work, such as assessing situations or quality criteria, without paying attention to the decision-making process.

Tacit Knowledge During Design Time

Security in Requirement Documents
Modelling of Security Knowledge
Identification and Extraction of Tacit Security Knowledge
Tacit Security Knowledge Examples

In the security requirements assessment process, use cases will be classified with respect to the enriched security knowledge through heuristic findings. The user enters an identification number and a pin" the pin will be identified as security-related, we infer through the existing linguistic dependency between the pin and the identification number that both are security-related. Ten of the iTrust use cases were selected as initial security knowledge for elicitation requirements.

Table 5.1 Publications considered for the creation of ontology [Gär+14]

Tacit Knowledge During Run Time

Usage Knowledge in Software Evolution
Modelling of Knowledge
Identification and Extraction of Tacit Usage Knowledge
Tacit Usage Knowledge Examples

Second, in the case of tacit knowledge detection, a request for more qualitative feedback is placed. Polanyi states that there is a fluctuating link between the two of them, which ultimately ends in a bold, established relationship - the tacit knowledge. The distal term defines the results of an action - the consequence or outcome, depending on the observation.

Fig. 5.2 A taxonomy of feedback provided by the end users of a mobile application

Related Work

Measurements for person-related information rely heavily on splitting both the test and training data for the individual classifiers. This could be why the person-related information models might underperform the application-related information. Our approach presented in Section 5.4 reflects the core idea of the approach presented by Damevski et al.

Conclusion

Summary
Outlook
Further Reading

In particular, creating a traceability link between these claim sources still poses a challenge in the exploration of tacit usage knowledge. However, a delay results in the problem that traceability must be guaranteed; that is, user feedback must be clearly allocated to an interaction. The images or other third-party material in this chapter are included in the chapter's Creative Commons license, unless otherwise indicated in a credit line for the material.

Continuous Design Decision Support

Introduction

Challenges for a Continuous Design Decision Support
Solution Approaches for Design Decision Challenges
Structure of This Chapter

The knowledge of the developers about the design decisions they make is called decision knowledge. This means that the documentation of decision knowledge is important to prevent knowledge evaporation [Cap+16]. Developers must reflect prior decision knowledge during decision making so that the design decisions are consistent with each other.

Foundations

It uses extractive and abstract summaries to support the transition from naturalistic to rational knowledge documentation. In addition, it identifies relevant decision knowledge based on traceability links to support consistent decision making. Section 6.3 presents the approach that supports design pattern decision making using a pattern catalog and documenting such decision knowledge.

Using a Design Pattern Catalogue to Make Design DecisionsDecisions

Motivation for Using a Pattern Catalogue
Decision-Making Process Using a Pattern Catalogue
Application to the Case Study

Details of the sample catalog and the decision-making process are presented in Durdik's dissertation [Dur14]. This includes presenting a catalog of patterns and activities that make design decisions clear. Objective A high-level description of the objective of the pattern or the problem that can be solved using the pattern.

Table 6.1 Information about a pattern stored in the pattern catalogue [Dur14]

Integrating Design Decision Models with Program Code

Integrating Architecture Models with Code
Design Decisions, Rationale, and Patterns in the IAL

Mapping between decision knowledge expressed in the IAL and Java program code (c) must be designed in the context of the MIC. The component type is represented as a Java type declaration with the name of the component type and the suffix Model. In summary, coding addresses the challenge of the consistency between architectural knowledge and the program code.

Fig. 6.6 An excerpt of the CoCoME architecture in PCM after the evolution scenario

Continuous Management of Decision Knowledge

Integrating Design Decisions into CSE
Decision Knowledge Triggers

Similarly, developers can document decision knowledge in a commit message or in the ITS. Decision-making knowledge is stored within the ITS and linked to the task of the function (Figure 6.13). Imagine that the execution of the Bitcoin payment function task has been completed and the decision knowledge is documented, as shown in Figure 6.13.

Figure 6.12 shows a state diagram of decision knowledge in CSE. The labels of the transitions indicate the type of CSE practice (start or finish) that developers perform

Related Work

Documentation Consistent with External Decision KnowledgeKnowledge
Documentation of Decision Knowledge Consistent with Architecture and Codewith Architecture and Code
Non-intrusive Documentation of Decision Knowledge

The decision knowledge for using the adapter cartridge (see section 6.3.3) is also accessible. The ConDec approach enables the informal documentation of decision knowledge and integrates mining techniques into the day-to-day work of the developers instead of applying them afterwards. The ConDec approach does not address such undocumented tasks, but supports developers to make tacit decision knowledge explicit.

Conclusion

Unlike Rastkar and Murphy, the ConDec approach creates summaries between closing practices to encourage developers to document important decision knowledge. Tool support will be evaluated in CSE projects that are part of a practical course at the university. In addition, we will explain how to preserve the knowledge so that it remains useful and how to access the relevant parts of the knowledge.

Model-Based Round-Trip Engineering and Testing of Evolving Software Product

Foundations

Model-Based Software Development and Testing
Model-Based Product-Line Engineering and Testing
Product-Line Round-Trip Engineering and Artefact Co-evolution

Software Product Line Engineering (SPLE) is an emerging methodology successfully used in various industrial application domains [Wei08]. For example, Figure 7.1a illustrates a possible development scenario for the xPPU product line: the xPPU core initially comprises a stack with several slides for sorting WPs according to their types, as well as a crane and a stamp. Software Versions. A set of software versions includes version implementations, specified as (plain) C code, as well as corresponding test model versions, specified as (plain) STATECHART models, each associated with a specific product configuration in the product line.

Evolution

Evolution of Software Variants
Evolution of Software Product Lines
Evolution of Model-Based Testing Artefacts

Figure 7.1b summarizes the evolution steps of the xPPU product line considered in the following examples. Specifically, the new behavior would be added to the existing variants v1 and v2 of the xPPU product line, while variant v3 would remain without error handling. Here the additional cross-tree constraint Sorting ⇒Dark has been added to limit the set of valid configurations of the xPPU product line.

Fig. 7.8 Test model of variant 2 in version 2. (a) Test model. (b) Code

Co-evolution

Co-evolution of Software Product Lines and Product VariantsVariants
Co-evolution of Software Product Lines and Model-Based Testing Artefactsand Model-Based Testing Artefacts
Co-evolution of Product Variants and Test Artefacts

Table7.1 shows a minimal set of test cases required for complete test coverage of the 175% test model, as shown in Fig.7.14b. Given a set of N 100% models/code artifacts corresponding to the different versions of the same model/code variant, N-way merging results in a 125%. Given a set of N 100% models/code corresponding to the different variants of the same model/code version, N-way fusion results in a 150% representation.

Fig. 7.16 Incremental N-way merging of software variants

Conclusion

Similarly, the impact of manual removals of test cases from SPL test suites on test coverage can be investigated on the 175% test model. For example, if test casetc2 is removed from the SPL test suite, as shown in Table 7.1, test goalt0 is no longer covered by any version of all variants containing this goal. Therefore, precise techniques for reverse-engineering (or learning) variant/version information from the existing artifacts is a crucial open question for future research.

Performance Analysis Strategies for Software Variants and Versions

Analysis Strategies for Software Variants

Sample-Based Analysis of Software Variants
Family-Based Test-Suite Generation for Software VariantsVariants
Family-Based Analysis of Software Variants

However, the accuracy of the predicted data obviously depends on the quality of the performance measurement data available for the sample set. Considering variant 13 of the PPU (cf. the test model variant in Fig. 8.4), the behavior corresponding to test caseT1 remains the same (and can therefore be reused to test this variant as well). 8.5 150% test model of the pick-and-place unit Table 8.2 Test models for variants of the pick-and-place unit.