When running in a multi-tasking/threading environment the user can cause the generated code for xtUML classes to run in different tasks/threads. This mappings is accomplished using the MarkClassToTask marking function. Note that mapping tightly coupled classes (where some classes frequently access instance data of the other classes) to different tasks can aggravate data synchronization issues. Map closely coupled classes to the same task.

To map a class or set of classes to a particular task number:

Where the input parameters are:

.// NOTES:
.// (1) To map a specific class, use "" for "ss_name"
.//     and provide the class key letters in "class_key_letters".
.// (2) To map all classes in the subsystem to the given task, provide
.//     the subsystem name for "ss_name" and "*" for the "class_key_letters".
.// (3) To mark all classes in the component as mapped to a task, use "*"
.//     for "ss_name" and "class_key_letters".
.//
.invoke MarkClassToTask( "", "", "MP", 1 )
.invoke MarkClassToTask( "GPS", "TRACKING", "*", 3 )
.invoke MarkClassToTask( "*", "*", "*", 0 )
        

MC-3020 has limited the use of memory allocation. For memory constrained systems it is convenient to limit the number of instances of a class that can exist at any one time. The following rule file function invocation will define that maximum number of instances that will ever be allocated for the given class.

Where the input parameters are:

.invoke MarkObjectExtentSize( "myDomain", "FRODO", 20 )
        

Early in the development cycle it may not be clear what the maximum number of instances of particular classes may be. MC-3020 provides a way to establish a default extent size to be used for all classes that do not explicitly define the maximum.

Where the input parameters are:

.invoke MarkSystemObjectDefaultExtentSize( 24 )
        

Version 3.1 of MC-3020 supports defining preexisting instances in data. This saves the time and space overhead of initialization objects. Mark all classes that have instances pre-defined in data.

Use this mark to enable the generation of ANSI C structure initializers to pre-populate instance collections from supplied XML data. There is no harm in marking a class as having preexisting instances in data even if it does not. Such marking will have the effect of making the class eligible for population by preexisting instances defined in data. All classes so marked will query for the existence of preexisting instances and will populate with them when defined.

Where the input parameters are:

.invoke MarkPEIsDefinedInData( "", "", "DOG" )
.invoke MarkPEIsDefinedInData( "Lab", "VET", "*" )
.invoke MarkPEIsDefinedInData( "*", "*", "*" )
        

Static instance populations are those instance populations to which additions or deletions are never made during system execution. By marking a class as having a static instance population, error messages will be generated if action language tries to create or delete instances of the marked class.

Use this mark to mark a population as having a fixed and unchanging population of instances.

Where the input parameters are:

.invoke MarkStaticInstancePopulation( "", "", "EXP" )
.invoke MarkStaticInstancePopulation( "Imaging", "OCR", "*" )
.invoke MarkStaticInstancePopulation( "*", "*", "*" )
        

Read only classes are those classes which cannot be dynamically written or related. By marking a class as read-only, error messages will be generated if action language tries to write or relate instances of the marked class.

Use this mark to mark a class as having a read-only instances.

Where the input parameters are:

.invoke MarkReadOnly( "", "", "BBALL" )
.invoke MarkReadOnly( "ODMS", "CAB", "*" )
.invoke MarkReadOnly( "*", "*", "*" )
        

Persistent classes retain the values of their attributes across power cycles. This includes the current state of active state machines. Newly created and updated classes are "backed up" to non-volatile storage. At system start-up time, any classes stored in non-volatile storage are restored before other application initialization occurs. Individual classes can be marked to be persistent.

Use this mark to mark a class as persistent.

Where the input parameters are:

.// To mark as persistent a specific class, use "" for "component" and 
.// "ss_name" and provide the class key letters in "class_key_letters".
.invoke MarkPersistentClass( "", "", "MP" )

.// To mark all classes in the subsystem as persistent, provide
.// the component name, the subsystem name for "ss_name" and "*" for
.// the "class_key_letters".
.invoke MarkPersistentClass( "GPS", "TRACKING", "*" )

.// To mark all classes in the component as persistent, use "*"
.// for "component", "ss_name" and "class_key_letters".
.invoke MarkPersistentClass( "*", "*", "*" )

.// To mark as non-persistent a specific class that had previously
./  been marked as persistent, use "" for "component" and "ss_name" and
.// provide the class key letters in "class_key_letters".
.invoke MarkNonPersistentClass( "", "", "ASN" )
        

As of version 4.2 of BridgePoint Builder it is possible to translate the AL contained in bridge and operation descriptions. This conveniently allows testing generated/compiled code in the same way it is tested on the BridgePoint Verifier. Operation (transformer) AL is translated unless marked off; Bridge descriptions are always translated and simply added to the skeletons.

As of version 3.1 of MC-3020, the TagTransformerGeneration is obsolete and does nothing functional other than generate a message.

This mark formerly (before version MC-3020 3.1) enabled the generation of ANSI C source code from Action Language (AL) embedded in the descriptions of named operation(s). AL is always translated unless marked off with the command MarkClassOperationTranslationOff.

To disable the translation of AL in class (or instance) based operations, use the following marking command.

Where the input parameters are:

.invoke MarkClassOperationTranslationOff( "", "T", "Cooking_Initializing" )
        

MC-3020 has trace capabilities that are controlled primarily at the system and component level. However, often this granularity of control is not fine enough. It can be desirable to trace only a few classes or to omit tracing from a few "uninteresting" or "noisy" classes that clog the trace log with too much information. The marks documented in this section allow trace control on a class by class basis.

To disable or enable tracing of a specific class, use the following marking commands:

Where the input parameters are:

.invoke MarkClassTraceOff( "Tracking", "TrackPoint" )
        

.invoke MarkClassTraceOn( "Tracking", "TrackLog" )