Design time and Run time Chris, Andrea, Martina, Henry, Antonio, Ole, Philippe, Hartmut, Anne, Jeff, Felix, Sebastian, Kurt

What distinctions between design time and run time? What about systems that design systems? Some designs need to be done prior to run time – The first set of decisions – When you’re setting general requirements, criteria, e.g. for safety – There is always some constraint on the design space that can be specified up front

Paola said: everything that can (must??) be done statically should be done statically. – Maybe change that to “everything that must be done statically should be done statically”. – Things that I think are not going to change vs. things that I think will change – can we distinguish them at design time? – Maybe not – we just can’t anticipate what we’re going to need to adapt. How about: everything that can be done at run time should be done at run time – Ex. Different sorting algorithms are appropriate under different conditions of resources. Design choices can become outmoded. Design choices can get locked in prematurely. Don’t let that happen; you can’t predict the future. This is not just data size dependent; it depends also on system architecture and resources. – In this case you should wait for run time to see what are the characteristics of the system on which you’re running, and then configure the system at run time – Sort of like don’t hardcode; use parameters Do we need design time?

How to completely avoid design? – Invent a universal computing machine that can run an arbitrary program – Oops, someone already did that We don’t know how to write a program that can write an arbitrary program So we can simply write a program to do that – Chris Landauer promised to do this, and will give a demo tomorrow

Design decisions. Choices about what should and should not be variable about runtime. This is an engineering decision that depends on requirements, costs, anticipation of environment(s) in which system might run, etc. Requirements and capabilities. What do I want my system to be able to do? What will the user possibly want the system to be able to do? (Expected runtime knowledge) – E.g. Want to ensure that X happens before Y, or some other constraint Beliefs about the environment in which the system will be situated – What is the corridor/envelope for which I’m designing (I may not know exactly; take your best guess) – What is the range of environments in which I anticipate that my system will find itself (this relates to robustness): workload, user goals, etc. – What is a model of the world in which your system will be situated? – Defining the universe of the things that you can a) control and b) observe (those that are potentially relevant and not unduly costly) What things are good to do at design time?

Maybe design time is slower timescale – Takes time to check/verify/synthesize – Takes time to effect adaptation Ex of what you might specify at design time – This system should sort correctly – it should run efficiently based on the resources available at runtime – It should make use of the best known algorithms (but “best” implies goals, which may not be known until run time)

Runtime adaptation allows you to delay some decisions – good if you’re not sure you know what you want A runtime advantage – the designer doesn’t know all of the goals; – doesn’t know all of the operational costs; – the user may do a lot of the goal specification; – other information may only become available at run time (system architecture, for example) What’s different today? – We used to assume that programs were not long-lived – Human coders more expensive – impact on relative cost of design What’s good about runtime?

What models are most appropriate at design time and run time? – Are any models that are inappropriate for one or the other? – If it takes too long for runtime, then do it at design time – Costly argues more for design time – If I only run a model once, then maybe just design time (throw-away code, or at least you anticipate not running it many times) What connections or shared information might there be (between design and run time)? – Design time goals should be made available to run time. Can check whether goals are being met, or whether assumptions made at design time are met; if not try to adapt or launch a re-design; give design time better model of environment. – Instantiation of design time boundaries/constraints/parameters Need for new formalisms and tools to support the type of design models that are necessary for engineering adaptive systems – How to specify boundaries, constraints, envelopes, requirements/capabilities – Software that augments itself by finding new modules that it can load dynamically; these need metadata that provide hints or models that allow you to predict how well it would serve the requirements Evolution is re-design that happens parallel to runtime – here distinctions between design time and run time blur especially

Note: we didn’t really cover decision making….