Initialization functions provide the analyst a means to specify preexisting instances for production bring-up. They also serves to set up test scenarios. Domain functions also can be activated/deactivated with marking. Through marking, specific initialization functions can be chosen for system bring-up while others are marked (or erased as the case may be) as not to be translated.

Marking a function for initialization does not change the function. The function remains available for invocation by any of the action semantics that could normally call it. If more than one function is tagged as an initialization function, each will be invoked. The order of invocation is alphabetical by function name.

Identify a function in the component to be used as the an initialization function by invoking the following rule file function in the domain.mark marking file.

Where the input parameters are:

.invoke MarkInitializationFunction( "*", "CreateAndPopulate" )
.invoke MarkInitializationFunction( "SeatHeater", "test" )
        

Initialization objects represent an obsolete means for the analyst to specify preexisting instances for production bring-up. All of the functionality of the obsolete TagInitializationObject is now provided in functions which can be activated/deactivated and marked for initialization. Use functions instead of initialization objects. See MarkInitializationFunction.

MC-3020 can be directed to skip code generation for classes marked with the MarkExcludeObjectFromCodeGen invocation. Combined with selective marking of initialization functions, class exclusion allows for a simple method of providing multiple bring-up scenarios. Exclude a class from code generation by marking it thusly:

Where the input parameters are:

.invoke MarkExcludeObjectFromCodeGen( "*", "TST_OBJ" )
.invoke MarkExcludeObjectFromCodeGen( "MicrowaveOven", "Test" )
        

To indicate to the model compiler that all classes in a specified subsystem should be excluded from implementation code generation, use the following invocation (one for each excluded subsystem):

Where the input parameters are:

.invoke MarkExcludeSubsystemFromCodeGen( "*", "MyVerifierUnitTests" )
.invoke MarkExcludeSubsystemFromCodeGen( "GPS", "UI" )
        

To indicate to the model compiler that the semantic action of a function should not be translated, mark the function with the MarkFunctionTranslationOff marking function. This is useful for selectively disabling functions used to set up test scenarios. This is also key for disabling initialization functions after preexisting instances have been created and saved in XML data.

Where the input parameters are:

.invoke MarkFunctionTranslationOff( "*", "CreateRelateInit" )
.invoke MarkFunctionTranslationOff( "Test", "TestScenarioFive" )
        

To instruct the model compiler to generate state transition tracing information, invoke the following rule file function:

Where the input parameters are:

.invoke MarkStateTransitionTracingOn( "*" )
.invoke MarkStateTransitionTracingOn( "Location" )
        

To instruct the model compiler to generate tracing information at the action language statement level, invoke the following rule file function:

Where the input parameters are:

.invoke MarkActionStatementTracingOn( "*" )
        

It is possible to develop xtUML models that incorrectly attempt to use instance reference variables that are empty (null). This can occur under several sets of circumstances. For example, selection across a conditional relationship chain may return an empty instance reference or empty instance reference set. Using such a reference without testing for empty can lead to an invalid operation. (MC-3020 does not enforce relationship conditionality at model compilation time.) It is possible to build models that attempt to send events to empty instance references, or relate or unrelate (link/unlink) instance when one or both references are empty.

MC-3020 provides a markable debug option for detecting and potentially recovering from such empty ``handle'' references. To steer the model compiler into generating debug code that detects the use of empty instance references and instance set references (handles), invoke the following rule file function:

Where the input parameters are:

.invoke MarkEmptyHandleDetectionOn( "*" )
        

MC-3020 will generate detection code and invoke a macro when an improper handle usage is detected. The macro defaults to invocation of a user callout function, UserEmptyHandleDetectedCallout. The body of this callout function can be (re)defined by the user.

At times it is necessary to carefully study the generated code. This may be the case when enhancing or extending the default functionality of MC-3020. Under such circumstances, it may be desirable to see the code in its unoptimized format. Note that MC-3020 has several optimizations that eliminate unused code. During design, sometimes it is desirable to see what this unused code looks like. Using MarkFirstPassOptimizationsOff(), it is possible to force MC-3020 to generate the code in its unoptimized form.

Where the input parameters are:

.invoke MarkFirstPassOptimizationsOff( "ship" )
        

MC-3020 will generate all code, even if it is not expected to be executed during normal operation.

Additional marking adjustments are available in the domain.mark marking file. Marking options that manipulate the style and appearance of the generated code and that control optimizations can be enabled. See documentation in the marking file for these detailed options.

Marking commands for these aesthetic purposes include: