A decoupled design approach for complex systems under lackofknowledge uncertainty Abstract   This paper introduces a special approach for the design of complex systems in early development stages accounting for lackofknowledge uncertainty. As complex systems have to be broken down into their components by a decoupling methodology, the presented work regards socalled boxshaped solution spaces as subsets of the total set of permissible designs not violating any design constraints. Hereby, the design variables are decoupled and their design intervals are maximized. Then, each aspect related to the corresponding interval can be studied independently in a subsequent development step by different stakeholders (design groups or designers). Especially in early design phases, the consideration of uncertainty is crucial; this is not so much related to aleatoric uncertainty as probability functions are often unavailable. More important and more difficult to handle is epistemic uncertainty, i.e. lackofknowledge uncertainty. Here, uncertainties which occur later in the development and the facts that the current design stage does not include smaller design features and that the available models represent only coarsely the later designs are important.  This paper complements prior work by providing a complete methodology for relevant uncertainties. This includes uncertainties in controllable design variables as well as in uncontrollable parameters all captured by interval arithmetic. Furthermore, it extends existing worstcase approaches by bestcase approaches. The user can now base design decisions on (a) a deterministic solution space without consideration of lackofknowledge uncertainties, (b) the same with consideration of uncertainties in uncontrollable parameters only or controllable variables only, or (c) the most complete approach where uncertainties in both controllable variables and uncontrollable parameters are considered. The corresponding scenarios are exemplified via examples from automotive engineering (design for crashworthiness).

Managing designtime uncertainty Any software system is the accumulated result of many design decisions taken by its developers. During the course of development, however, developers are often uncertain about how to make these decisions. This uncertainty reflects lack of knowledge about the design of the system, rather than about the environment in which the system is intended to operate. It is therefore called designtime uncertainty, and is different from environmental uncertainty 1. Addressing environmental uncertainty requires using strategies such as selfadaptation 2, which result in fully functional software systems, capable of operating under uncertain conditions, i.e., uncertaintyaware software. In contrast, designtime uncertainty (henceforth, also simply uncertainty) cannot be coded away. Rather, it must be tackled as part of the process of software development, i.e., using uncertaintyaware software development methodologies.   Existing methodologies, languages and tools assume that their inputs do not contain any uncertainty. Thus, uncertainty is rendered an undesirable characteristic that developers should either avoid or remove altogether before resuming their work. This results in either costly delays or potentially premature  and therefore risky  resolutions of uncertainty as developers make provisional decisions and attempt to keep track of them in case they need to be undone. We present an alternative strategy: the explicit management of design time uncertainty as part of the course of software development 3.   Specifically, we build on previously published work for encoding alternative design decisions in partial models which can subsequently be used for tasks such as reasoning, refinement and transformation 4. These techniques had been implemented as partial model operators in MuMmint, an interactive modelling tool 5. We combine these point solutions into a coherent, toolsupported methodology for tackling designtime uncertainty. This combination allows deferring the resolution of uncertainty for as long as necessary while the development work can continue.   To create a coherent methodology, we must address some fundamental questions, such as: What does it mean to tackle uncertainty? How does it get added to software artifacts? When does it get removed? To gain a more detailed understanding of how uncertainty is manifested and manipulated at different stages, as well as the different inputs, outputs, pre and postconditions of partial model operators, we developed the DesignTime Uncertainty Management (DeTUM) model, shown in Fig. 1. The DeTUM model consists of three stages: During the Articulation stage, uncertainty increases as developers encode alternative designs in partial models. During the Deferral stage, the goal is to avoid making premature decisions, while still being able to make use of software engineering techniques. To do that, developers use partial models as primary development artifacts in combination with techniques that are appropriately lifted so that they are applicable to partial models. During this stage the degree of uncertainty in the model remains unchanged. During the Resolution stage, the degree of uncertainty in the partial model is reduced to reflect newly acquired information. The ultimate result is a model without any uncertainty. The DeTUM model allows us to to contextualize the various partial modelling operators and identify gaps through lessons learned from nontrivial scenarios.   This work makes the following contributions: (a) the DeTUM model; (b) the mapping of various partial model operators to the DeTUM model; (c) based on the above, a methodology for managing designtime uncertainty, and (d) a validation of the usability and effectiveness of the methodology based on two nontrivial uncertainty management scenarios.