Software Engineering 2003 Jyrki Nummenmaa 1 INSTALLATIONS Software installation accommodates software to a target environment. Elements to be set up during installation may include: –Executables –Libraries –Help files / Manuals –Documentation –Application configuration files –System configuration files (like Windows registry) –Data files for the executable –Database

Software Engineering 2003 Jyrki Nummenmaa 2 SYSTEM INSTALLATION Installation of a complete information system may, additionally, include e.g. –Hardware installations, –Training, –Organisational changes

Software Engineering 2003 Jyrki Nummenmaa 3 Installation types Commissioning means first-time installation of software. Upgrading means replacing a version of the software with a later (and hopefully better) version. Downgrading means replacing a version with an older version. Uninstallation means removing the software altogether from the system.

Software Engineering 2003 Jyrki Nummenmaa 4 Installation method examples Makefile –Designer of installation writes a file, which describes the files in the installation, the dependencies between files (E.g. file A needs files B and C etc.) and how to make files (E.g. make file A by gcc –g –o A B C) –The make program studies, which files are not up-to-date and makes them. Installation wizard –A program, which – possibly interactively – runs the installation. –E.g. InstallShield for Windows.

Software Engineering 2003 Jyrki Nummenmaa 5 What is a good installation like? The installed software works ”normally”. The installation does not affect the functionality of software, which has been installed earlier. (The installation should not create version incompatibilities in the configuration.) Creates minimal disruption to the environment and the all software in the system. Avoids selfish use of resources. Does not change the environment unnecessarily.

Software Engineering 2003 Jyrki Nummenmaa 6 Further requirements for good installations Trace of what was done. Possibility to stop the installation and recover earlier state. Provide documentations, which explains the changes made in the system. This documentation should be available also before the actual installation starts.

Software Engineering 2003 Jyrki Nummenmaa 7 Minimal disruption and unselfish resource usage Other software should continue to function. Avoid interrupts because of e.g. system reboots. Even simultaneous installations should be possible. Do not change general configuration files in a way that effects other software. Make minimal changes to the system. Use disk space and other resources sparingly. Respect the technical and political policies of the environment. Do not leave unnecessary things behind (temp files etc.).

Software Engineering 2003 Jyrki Nummenmaa 8 Options Different types of media: HTTP, ftp, CD, etc… Setup options (and it should be possible to change them later): –functionalities –languages –visual effects –etc.

Software Engineering 2003 Jyrki Nummenmaa 9 Minimum disruption to the usage of the system Minimize the time when the system can not be used (downtime, passive time). Some critical systems do not tolerate downtime at all. –It may be necessary to use a backup system when installing. For instance, when installing software to the mobile phone, it should be possible to use the phone for e.g. receiving incoming calls.

Software Engineering 2003 Jyrki Nummenmaa 10 Preparing the installation Study the requirements – they may contain requirements for installation or other relevant information. The success of the installation depends largely on how the software has been built. Conclusion: The installation requirements should be taken into account when making the software – not only when the installation procedures are built and the software already exists! Particular difficulties are ahead, if we are making a large distributed system – then pay Test the installation procedures carefully.

Software Engineering 2003 Jyrki Nummenmaa 11 Scheduling an installation Prepare for troubles: reserve extra time. Avoid disruption for users. Choose a quiet time. Inform in advance. Prepare for failure (backups!).

Software Engineering 2003 Jyrki Nummenmaa 12 Dynamic installation An installation is dynamic, if some parts of the system are being installed (typically upgraded) as the other parts of the system continue to function. In particular, dynamic installation does not tolerate a reboot of a device. A reboot would be most inappropriate in the mobile phone example. For mobile phones (and most other embedded systems), a dynamic automatic installation is desired.

Software Engineering 2003 Jyrki Nummenmaa 13 When is a dynamic installation possible? / 1 There is some work done on Software Replacable Units ie. SWRUs) The following conditions say when SWRUs can be independently replaced. S1. Each SWRU must encapsulate its internal state and not allow direct access to its state from outside. S2. No SWRU is allowed to directly reference the state of a shared component. –continues in the next slide...

Software Engineering 2003 Jyrki Nummenmaa 14 When is a dynamic installation possible? / 2 S3. The SWRUs may only discuss through explicite message exchange. In particular, they may not share variables. S4. Each SWRU must have an independent control of its execution and it should be possible to execute them independently (e.g. in a separate computer if message exchange uses networking). The conditions S1-S4 ensure that running down one component does not create problems for the others. The conditions S1-S3 are quite close to the principles of encapsulation in OO programming.

Software Engineering 2003 Jyrki Nummenmaa 15 When is a dynamic installation possible? / 2 S5. Each SWRU must support dynamic installation. There must be a possibility to store the internal state (like the contents of required variables) and to restore this state. ’ S6. A SWRU is able to inform the message passing system on when its non-availability starts and end. S7. The message passing system can buffer messages for non-available components.

Software Engineering 2003 Jyrki Nummenmaa 16 Why S5-S7? S5 and S7 enable the possibility to run-down and restart SWRUs. S6 enable the system to function, when some component is not accessible.

Software Engineering 2003 Jyrki Nummenmaa 17 Automatic installation example Automatic installation is such that it includes no user intervention. nA user follows news from a mobile phone. nThe news contain a video clip packed in a way, which the mobile phone can not unpack. There is a need to install a new component for unpacking the video (or upgrade some old component). nThe telephone locates and downloads installation material for the component. nThe component is installed. 1.The user views the video clip.

Software Engineering 2003 Jyrki Nummenmaa 18 Need for automatic installation? In ordinary PCs the programs, which install automatically are most typically –viruses, or –applets run in a web browser. PCs are probably not the most important target environment for automatic installation. The applets are just copied and run in a standard and limited environment, which makes the installation non-interesting. Also, we won’t discuss installation of viruses, although their makers have solved a number of problems related with automatic installation.

Software Engineering 2003 Jyrki Nummenmaa 19 Automatically installing program vs. a virus In fact, some people tend to define viruses as programs, which install automatically. There is no problem to define a virus without this property: –A computer virus is a program, which multiplies itself by attaching it’s program code into other executable files in such a way that when the file is executed, also the program code of the virus is executed.” There are other applications to automatic installation than writing viruses.

Software Engineering 2003 Jyrki Nummenmaa 20 From dynamic installation into an automatic installation. InstallComponents(C,A) installs dynamically. To automate the installation, it is necessary to use version information to ensure that we create a new installation without version incompatibilities.

Software Engineering 2003 Jyrki Nummenmaa 21 Using version information Automatic installations need version information. Version information can be used to check if the new components are compatible with each other and existing components. Version information may also be used to compute global installation requirements, if we know the configuration and the desired installation. In general, the configuraion may have fixed version, ie. it may contain components whose versions are not be changed.

Software Engineering 2003 Jyrki Nummenmaa 22 Version compatibility example (In compatibility matrix M, 1 means compatible, 0 not) C1.V1C1.V2C1.V3C2.V1C3.V3C3.V4C4.V3C4.V4 C1.V C1.V C1.V C2.V C3.V C3.V C4.V C4.V Assume we have a configuration A={C1.V1, C2.V1,C3.V3} and we want to get C={C3.V4, C4.V4}. What are the implications?

Software Engineering 2003 Jyrki Nummenmaa 23 When is an automatic installation possible? An automatic installation is also a dynamic installations, so those requirements must be fulfilled. V1. The components to be upgraded need to contain a version number. A standard way to ask the component for its version number is also needed. V2. It is possible to inquire the version numbers from the components using message passing. V3. All version compatibility information is known. –Also the environment (devices and their drivers) are modeled as components, even though their automatic installation may not be possible.

Software Engineering 2003 Jyrki Nummenmaa 24 Where to use automatic installation? Embedded systems: phones, cars, espresso machines, ball point pens (some slight exaggeration here for the current situation, but in the future many more devices will contain software…) Normal interaction with these devices does not contain discussions on installation. The user may not even know that the device contains software. In particular mobile devices may need new installations to adjust to changing environment.

Software Engineering 2003 Jyrki Nummenmaa 25 Safety in automatic installation Usually we need a device connected to a communication network. The system must be able to identify safe installation sources. Standard cryptographic methods may be used. For instance, accept only material digitally signed by someone of a limited set of companies.

Software Engineering 2003 Jyrki Nummenmaa 26 Dynamic installation: InstallComponents(A,C) Input: a)Configuration A fulfilling conditions V1-V3 and S1-S7 b)A set C containing the new versions of components required to install into A. Output: The installation is to produce a configuration A’, which includes the desired new versions of the components. Method: 1.If some components in C have versions in configuration A, shut them down. The components inform the message passing sytem that they are not available. [S1-S7] 2.Copy the component versions in C to the system. 3.Start up the new components. The new components inform the system about their availability. [S5-S7] 4.Optionally remove the shut-down components from the system.

Software Engineering 2003 Jyrki Nummenmaa 27 Cascading installation Input: a)A version-compatible configuration A of software S fulfilling conditions V1-V3 and S1-S6 b)The set C of new components (or new versions of them) Output A modified version-compatible configuration. Proseduuri: 1.D ← C. 2.InstallComponents(A, D) 3.If the new configuration contains a component, which requires the installation of some components version X, then D ← {X} and go to Step 2.

Software Engineering 2003 Jyrki Nummenmaa 28 Evaluation of CascadingInstall Cascading may remove one of the items in C! Cascading may not terminate. Cascading does not recognize a situation, where it is impossible to find the desired installation. We generally want to avoid further installations.

Software Engineering 2003 Jyrki Nummenmaa 29 Cascading installation example Assume that the version information is in matrix M given in these slides, A={C1.V1,C2.V1,C3.V3} and we want to install C={C3.V4, C4.V4}. A possible installation sequence 1: {C3.V4, C4.V4} -> {C1.V2}. A possible installation sequence 2: {C3.V4, C4.V4} -> {C3.V3}. A possible installation sequence 3: {C3.V4, C4.V4} -> {C1.V3}-> {C1.V1}-> {C1.V3}->...

Software Engineering 2003 Jyrki Nummenmaa 30 Pre-computing the desired installation Input: a)A version-compatible configuration A of software S fulfilling conditions V1-V3 and S1-S6 b)The set C of new components (or new versions of them) Output: A version compatible configuration A’ containing C. Method: 1.Using A and C, compute such a set D of component versions that CD and when the component versions in D are installed into A, we get a version-compatible configuration. If such set D does not exist, stop the installation. 2.InstallaComponents(D).

Software Engineering 2003 Jyrki Nummenmaa 31 How to form the component- version set for installation? We may require D to be of minimum size. –Assume version compatibility information M, A={C1.V1,C2.V1,C3.V3} and we want to install C={C3.V4, C4.V4}. Now D={C3.V4, C4.V4,C1.V2}. We may also require D to containe as recent versions as possible. –This requirement may turn out to be problematic.

Software Engineering 2003 Jyrki Nummenmaa 32 Precomputing the desired installation D If there are few available versions, then it may be possible to check all possibilities exhaustively and find a suitable set D with minimal size (or find out that such a set does not exist). Othewise smarter computational methods are required and they are not discussed here.

Software Engineering 2003 Jyrki Nummenmaa 33 Conclusions At the moment, existing software mostly does not fulfill S1-S6 ja V1-V3. Also runtime environments need some improvements to enable automatic installation. The future will require better installations and also automatic installations.