MC-3020 Model Compiler
FAQ

Enumeration support in ANSI C is very weak. Name spacing is absent.

Consider

  enum rock
  {
    red = 1
  };
  enum stone
  {
    red = 2
  };
  ...
  material_color = red;
  

Another weakness lies in the lack of control over the storage allocated to variables declared to be of enumerated type. In resource constrained environments (say an 8-bit micro), we would like our enums to take up something less than an integer of storage.

(From the MC-3020 UG:) Based upon information modeled in BridgePoint Model Builder, MC-3020 automatically generates source code frameworks for bridge and transform implementation. These skeleton files will actually compile as generated. The user is saved from delving into generated code to divine interfaces required for these boundary functions. Kind and helpful comments are provided to guide insertion of bridge and transform implementation code.

Generated xform and bridge header files are under the context and control of the translation engine. Skeleton implementation files (skel/XXX_xform.c) are provided as a convenience for the user. These provide correct method signatures, requisite include files, etc. The user ``inserts implementation code here''.

Note that BridgePoint Generator has some translation idiosynchracies when multiple arguments are passed on a bridge or transformer interface. The order of arguments in the generated code is non-deterministic. Bridge and transformer interface frameworks provide a level of indirection between the code generator and the server code.

Bridge and transformer skeletons are best used as hooks, call outs, to the realized domain. Thus providing the indirection between generated code and hand written or purchased code.

Yes.

Synchronous Services are supported as of BridgePoint Model Builder version 5.0. MC-3020 supports these synchronous services and recommends that inter-domain bridging use this mechanism.

BridgePoint Model Builder provides a model auditor. It is available from the file menu on the Subsystem Component Diagram. This audit function will parse the model identifying syntax errors, unparsed actions, relationships that have not been formalized and several other problems and dangerous modeling practices. It is not capable of catching every minute anomaly, but it does provide a good check. Often, a problem manifested during translation could have been detected (more cheaply) by a model audit.

Be sure to run a model audit before submitting a problem report against the model compiler.

No. Initialization by definition is processing. Therefore, initialization objects need to be active (capable of processing).

MC-3020 generates initialization code for the target system from action language defined in each initialization object. The system bring up code invokes these initialization state actions. The sequencing of initialization objects is not predictable. Ordering of state actions within each initialization object is also unpredictable. This unpredictability is rooted in the data base access methods of the BridgePoint tool. No explicit ordering can be assumed in the general case of select many ...

We recommend an approach hereby dubbed ``Omnipotent Domain Initialization'' (ODInit). ODInit crowns one domain as sovereign over the others in regard to initialization. The Omnipotent Domain is all powerful when sequencing initialization activities. In terms of initialization sequencing requirements among all domains, the Omnipotent Domain must be all knowing. The (truly omniscient) system architect (not software architect) must make this so.

ODInit is accomplished with a single initialization object for the entire system. The action in this object's state machine will initialize its own domain and make bridge invocations into the subordinate domains. The subordinate domains will each provide one to many bridge interfaces (synchronous services) to serve the Omnipotent Domain.

The ODInit approach keeps the specification of initialization sequencing and processing in the OOA where it belongs.

Sequencing of initialization of the domains is an analysis issue. Since it falls outside of any single domain, it transcends the jurisdiction of the domain analysts. The architecture can distinguish only ``system'' (architecture) from ``application'' and therefore sees very little if any boundary between domains. The system will initialize itself before the application. The application needs to sequence itself. All sequencing info should be captured (and modeled) by the system architect(s) (not the software architects).

Consider that much of the sequencing of initialization can occur after ``initialization''. Get the domains up and breathing with pre-existing instances, then start launching events and bridging with your buddies to get everybody coherent. Perhaps the amount of ``populating and relating instances'' is small compared to the ``coordinating and sync'ing with other domains''. We recommend going thin in your initialization object and fat on application models for as much as you can.

The developer might try to imagine initialization using a pre-populated data base of the OOA or by flash memory instantiation. Our init object approach should not greatly deviate from this concept. Avoid the trap of performing application processing in init objects.

The autosampler example model is intentionally small and simple. (Even so, it nicely models a real world device.) Generating code for the autosampler is an ideal first step in exploring MC-3020. The Quick Start given in the users guide holds the hand of the novice during an initial drive of the model compiler.

The autosampler model is set up to get just a bit farther. With a little bridge wiring, the generated code can perform more functions.

See example model with two OOA domains plus two realized domains on the download page on the ROX web site.

Actually, nothing goes into system/user/source unless placed there by the user. MC-3020 will generate a makefile for this code and link everything it finds there. Beyond that, it is off limits to the model compiler.

The build environment is designed to be easily modified. The design approach exhibits an intention to avoid anticipating and mandating any rigid strategy in compilation/link/locate land. MC-3020 opted for flexible and modifiable. Makefiles are generated from archetypes. A link script is generated. Both can be tailored. The link script is very easy to augment. It already supports various linking/locating tool environments.

Consider establishing a strategy of building realized domains somewhat independently. You could use other languages and tools if you desired. You could even go so far as to build a library module of your realized code. Use the bridge skeletons as indirection hooks as described above. Change the link_sys script generator to link in realized ``libraries''.

To go further, modify the makefile generation to suit requirements. A modification to support subdirectories under system/user/source would be minor. However, it would be better to go get the user code from a directory outside the system node. Again, this would require only a change to the link_sys generator.

If an error message refers to R207 (relationship 207 in the MC-3020 meta model), it means that the model being translated has an unformalized relationship. This sort of error can be captured with an OOA audit in BridgePoint Model Builder.

Note that use of bridge objects is discouraged as of version 5.0 of BridgePoint Model Builder. Synchronous services are available to provide cleaner bridging.

Provide an attribute of the bridge object with the same name as the state name representing the synchronously callable routine. This attribute is the return value for this bridge service. In your action language, set this attribute; it will be returned to the invoking domain (realized or OOA).

Color each event to be given more than default (0) priority by editing the event.clr coloring file for the domain receiving the event. Provide:

  TagPriorityEvent( "label", value )
  

MC-3020 version 1.3 and after translates action language in bridge and transformer descriptions. Putting ACTION_SPECIFICATION: TRUE in a comment at the beginning of the bridge or transformer description will enable this code generation.

Bridges and transformers are treated alike in much of of MC-3020. For example, skeleton implementation files are generated for each. (See Bridge/Transform Skeleton Generation in the Users Guide.) Both serve as hooks into the the outside world from within the OOA domain. However, description translation has some differences.

When translating the description of a transformer (tagged with ACTION_SPECIFICATION: TRUE), MC-3020 will generate a file into the appropriate gen/source directory (instead of the skeleton directory). When translating the description of a bridge (tagged appropriately), MC-3020 generates translated action language into the same skeleton files (source code frameworks) that are generated when not tagged.

The reason these are treated differently is because of a perceived difference in usefulness. To ROX, translated transformers seem to carry natural value in the production environment. However, translated bridges seem to have value only during ``simulation'' style testing (stubbing out domains).

Note that if ACTION_SPECIFICATION: FALSE is encountered in a bridge or transformer description that the action language will not be translated.

First pass translation collects statistics used to conservatively estimate the number of container nodes (containoids) required by the system.

There are three different uses for instance containoids: class extents, association extents and selection extents. Selection extents govern the total size of transient instance reference set variables in the actions. This represents values in the variable type inst_ref_set. The required number of containoids for each flavor is summed to provide the upper limit to total containers.

#define SYS_MAX_CONTAINERS \
    ( SYS_MAX_OBJECT_EXTENT + SYS_MAX_RELATIONSHIP_EXTENT + SYS_MAX_TRANSIENT_EXTENT )

SYS_MAX_OBJECT_EXTENT is a sum of all of the extent counts across all the domains of the system, which are sums of the class extents in each domain. Each class extent is allocated to be the system default for class extents, a colored value of the system default or the colored value for the specific class.

Selection extents are calculated by multiplying the largest number of selects that can occur in any action by the largest extent of any class. Thus allowing for the worst case action to select the largest class extent each time. This value is set in SYS_MAX_TRANSIENT_EXTENT.

transient containers = ( max selects ) * ( largest class extent )

Relationship extents are allowed to be as big as they would need to be if all instances on the MANY side were always participating. This value is set in SYS_MAX_RELATIONSHIP_EXTENT.

association containoids = ( number of MANYs ) * ( largest class extent )

The following colors govern these extent sizes:

See the proper sections in the MC-3020 Users Guide for details on these coloring parameters.

Relationship extents refer to the sets of instances participating in a relationship with multiplicity MANY. Sets built from linked lists are used to optimize traversal of relationships with multiplicity MANY. For example, in the following model, A 1---R1---* B, object B does not need an extent set; it simply needs a single pointer reference to the A instance. The A instance however does need a set of instance references. Such a set uses "containoids" to collect the B instances related to the A instance. MC-3020 calculates the worst case (biggest possible) relationship extent.

The extent can be colored to be smaller than the worst case maximum using TagMaximumRelationshipExtentSize. TagObjectExtentSize will also have an effect on the calculated total.

If no extent size coloring is supplied, MC-3020 will calculate a worst case for a model of a higher number of containers. MC-3020 will see R1 and allow for all possible instances of B to participate with instances of A. (This is the most important point!)

Another way to understand how MC-3020 calculates this maximum is as follows:

This sum across all domains in the system will be the SYS_MAX_RELATIONSHIP_EXTENT.

ROX has researched the selection process and provided substantial optimization in MC-3020. During the first pass of translation, selection statements are identified of the form 'select any [inst_ref] from instances of [key_letters] where [where clause]' when the where clause is checking for equality of the identifier. Such selection statements represent a common pattern seen in many applications. (You may see reference in the archetypes to "special where" clauses.)

MC-3020 optimizes these selections for code space by consolidating the searching into subroutines. This consolidation eliminates redundancy in the generated code. In addition, these selection functions allow some embedded processors to use internal registers more efficiently, thus improving speed. (Such speed-ups have been experienced with 8051 and 80C167 family processors using Tasking brand C compilers.)

For future feature enhancement and for flexibility of customization, hooks into these scanning routines are provided at the archetype and generated code level. These hooks ease the task of providing application specific collection search code. Binary searching and hashing have been considered for certain applications. However, off-the-shelf MC-3020 does not supply this application specific search support.

Research performed on MC-3020 shows that collections need to be substantial (hundreds or thousands) before customizations to the selection algorithms provide real application reward. The simple algorithms provided are tight and fast even though very simple.

When an object is synchronously created (with a create object instance command, any identifying attribute of type unique_ID will simply get the address of the instance. This certainly relies on the single data address space nature of this architecture.

The algorithm for determining the form of a unique_ID is internal to the model compiler. Any analysis assumptions made about such are made at analyst peril!

LegOS (necessarily) provides a stripped down version of the C string libraries. strncat and strncpy are not defined by LegOS. However, strcat and strcpy are. Change the archetype sys_mechs.arc to use these simpler (although more dangerous) versions of string functions.

Note that in version 3.0 of MC-3020, the string library function calls have been eliminated. Native C is used throughout.