Home   :   Matrix Language   :   Model Examples   :   Windows WiX Installer

Windows WiX Installer Model

Introduction

Most applications for the Windows platform need to be installed before they can be run. When an application file is downloaded and saved on a computer it usually has an extension of ".msi". A MSI file contains the executable, auxiliary files and configuration information that updates the Windows registry to handle the running application.

A relatively easy way to construct a MSI installer file is provided by the WiX (Windows Installer XML) toolset .

The Matrix Windows WiX Installer model describes and generates a XML file which is processed by the WiX toolset to produce a MSI Windows Installer package that will deploy an application. This example generates the actual XML file for the Matrix Model Compiler (Learning Edition) and demonstrates non-code Model Compiler generation. Matrix is available as a free download .

Overview

Windows installer packages can be very complex. The Windows WiX Installer model explained here describes just a simple subset of WiX elements. Not only does Microsoft employ WiX to install its own software it is also commonly used by many other companies. The WiX Toolset is free from Microsoft.

WiX provides a level of abstraction above what would otherwise be required to write a MSI installer package which would typically involve many low-level function calls. The Windows WiX Installer model raises the abstraction level again, admittedly not by a great deal. In other words, it models WiX elements very closely but does show how the XML tags relate.

Model Walkthrough

The Domain Bridge Diagram (DBD) shows the Matrix Installer domain. The model is presented here as an isolated domain or rather as a stand-alone model but normally it would form a low lying architectural domain of a Software Architecture meta model or Model Compiler that is designed to target the Windows platform.

Realm:Analysis_Of_Application

The Entity Relationship Diagram (ERD) shows the relationships between the various entities in the system. 

For the Matrix Installer domain, all the entities correspond to WiX XML elements and all relationships are described by the rather bland but true term of "Includes".

The WiX XML file is very hierarchical. By following the relationship directions it can easily be seen which elements are at the top of the hierarchy and which are at the bottom and which are in between.

Reflexive relationships on both the Directory and Feature entities indicate that their object instances can be embedded within themselves. For example, a Directory can be created at installation time that contains other Directories. Reflexive relationships also indicate that events are to be sent from objects of an entity to objects of the same entity in asynchronous models or recursive process includes are to be used in synchronous models.

The notation used by the diagrams below is based on Shlaer-Mellor Method notation (similar to UML) . To see the full size ERD, click on the diagram.

Domain:Matrix_Installer

The Windows WiX Installer model is an asynchronous model and as such presents certain problems that arise out of the fact that the Matrix language is inherently concurrent but what is required is to sequentialise all text generation for output to a single file.

A pattern that can be seen in the collection of STDs below is that of a state that asks many objects in another entity to do something via events. In this case write text out to a file. Obviously, the order in which the text is output from the objects can be important and so a mechanism must be found to control the normally concurrent aspect of the modeling technique.

It can be seen in the Matrix model code (but not shown here) that extra attributes all called "Processed" and extra relationships called "Writing" are included to sequentialise the operation of the model. Eventually, a pattern statement will be developed to automatically instrument these extra attributes and relationships which will hide the their implementation from the developer. This technique is also found in asynchronously written Model Compilers.

It is sometimes acceptable for a state to fire-and-forget events at a whole bunch of objects where the order happens to be irrelevant. In most cases the order is important. A greater problem is caused by the order of event processing which is inherently indeterminable. During processing, events may be intermixed with previously generated events in situations where the order of event handling is crucial.

On the STD picture below, click once to get an expanded view of the diagram. Clicking again will reveal the same diagram again but this time annotated to show the source of actual events and their destination among the collaborating entity STDs. An event based notation is used .

Domain State Transition Diagrams

Matrix Model

There are three different versions of the Windows WiX Installer model. The Matrix model, test scenario and generated source code files are available on GitHub:

• Windows_Wix_Installer - The asynchronous Matrix Windows WiX Installer model which splits functionality among several state machines .

• Prof_Asyn_Windows_Wix_Installer - The professional edition asynchronous model which uses process include statements to arrange the model's code in several files according to entity .

• Prof_Sync_Windows_Wix_Installer - The professional edition synchronous model that uses one event, one STD and process include statements some of which are invoked recursively .

Populating the model with configuration data (M0 Real World Objects) by hand can be labourious. However, a Domain Specific Language (DSL) could be created as part of a separate application to greatly ease this process.

Expected Output

All three versions of the model produce the identical XML WiX source file (.wxs). The file runs to over 6,000 lines .