This chapter explains how to initialize and start the system. Initialization must deal with bringing up the architecture system code as well as initialization for preexisting instances.
MC-3020 supports dynamic and constant initialization of preexisting instances. Dynamic initialization is simple and flexible while constant initialization is a powerful optimization allowing for reduction in code space and increase in initializationspeed.
It is possible to define preexisting instance populations dynamically with action language and constantly with data definitions. Instance populations can be static, dynamic and/or read-only.
MC-3020 supports two methods of initialization, dynamic and constant. Both methods provide a means of creating and setting up the preexisting instances required for a system at bring-up time. Both methods provide a way of creating the preexisting instances, relating them one to another and setting the values of their attributes. Each method of initialization has advantages and disadvantages. Each method is useful in design situations that leverage the advantages. The following sections will describe each method of performing system initialization.
When specifying a system with xtUML models, the analyst is allowed to assume that there are preexisting instances of classes within the models. MC-3020 provides two methods for specifying these preexisting instances, the values of their attributes, and the relationships between them. This dynamic creation, linking and initialization of preexisting instances is described in the section called “Dynamic Initialization”.
The preexisting instances of xtUML classes can be created during system bring-up from the specifications provided by the analysts in the form of initialization functions. These preexisting instances are created before normal execution of the system is allowed to proceed. Thus, the xtUML models can assume that all the preexisting instances exist before any events are accepted.
Note that MC-3020 automatically creates a single instance for every assigner in the system. The analyst does not need to model or mark anything to make this happen.
In order to avoid confusion resulting from the following paragraphs as well as in future documentation, the following definitions will be used with respect to instance populations and preexisting instances:
static instance population: an instance population to which additions or deletions are never made during system execution (after initialization)
implicitly defined static instance population: the use of a static instance population for a class due to the absence of associated create/delete statements in model action language
explicitly defined static instance
population: the use of a static instance
population (no creates/deletes) for a class based on a
TagStaticInstancePopulation mark for that
class
dynamic instance population: an instance population to which additions and deletions may be made during system execution (after initialization)
implicitly defined dynamic instance population: the use of a dynamic instance population for a class based on the presence of associated create/delete statements in model action language
preexisting instances defined using executable statements: preexisting instances that are established at run time through the use of an executable initialization routine
dynamic initialization: preexisting instances that are established at run time through the use of an executable initialization routine (same aspreexisting instances defined using executable statements)
preexisting instances defined in data: preexisting instances which are established through the use of constant data (in the form of ANSI C initializers)
constant initialization: preexisting instances which are established through the use of constant data (in the form of ANSI C initializers) (same as preexisting instances defined in data)
read-only instance population: instance population that cannot be written
It is easy to see that many combinations of static/dynamic, read-only, implicit/explicit and preexisting can occur in normal system analysis.
In MC-3020 3.1 and beyond, preexisting instances can be defined in data for any normal modeling construct supported by MC-3020 For example, dynamic or constant initialization can be defined for:
simple 1-1 associations
simple 1-* associations
associatives (1-1, 1-*, *-*)
subtypes
supertypes
sub/supertypes
simple reflexive associations
simple 1-* reflexives
reflexive associatives
asymmetric reflexive associatives