Rules and Standards

CAA V5 StartUp Consistency and Data Compatibility

Managing StartUp evolutions between releases to ensure upward data compatibility
Technical Article

Abstract

This article explains how you can modify the StartUps stored in the StartUp catalogs while ensuring that documents relying on these catalogs remain legible.


Why Managing StartUp Compatibility?

When moving from a CATIA release to another one, you legitimately expect that upward data compatibility be ensured. When working with features, this upward data compatibility is easy to obtain if you understand the feature underlying mechanisms, and if you follow basic feature compatibility rules.

The CATIA Feature Modeler relies on the prototype/instance paradigm. The first instance, called the StartUp, provides its derived instances with their basic type and behaviors. To make it possible to share StartUps between documents, and also for memory size and performance reasons, StartUps are stored in catalogs. If StartUp catalogs do no change from a CATIA release to a next one, the upward compatibility is automatically ensured. In addition, if they are modified in the next release, some simple consistency rules to apply when modifying them ensure that a document relying on, or created using, these catalogs in a previous CATIA release can be read in a next one. In other words, ensuring StartUp catalog consistency ensures upward document/feature compatibility.

To do this, the rules to follow and apply when modifying StartUps and StartUp catalogs are classified into:

These rules are checked when creating or modifying a StartUp catalog thanks to the StartUp catalog compiler/checker available before delivery. If a given StartUp catalog doesn't match one of these rules, the corresponding .feat file is not generated.

Some applications do not manage StartUp catalogs, and create their StartUps on the fly when they create their containers. These applications manage themselves the upward compatibility of their data.

This article uses the following notation: V5Rn and V5Rp designate two releases of CATIA, where p is greater than n.

[Top]

Modifying StartUp Structure

The structure of a StartUp can be modified according to the following rules:

  1. Adding an attribute in V5Rp is possible.
    This is possible thanks to the CATIA Feature Modeler dynamicity. Applications written for V5Rn will go on running without taking care of the new attribute. In V5Rp, the synchronization mechanism automatically adds the attribute to any instance that has not it. If this attribute is accessed, it is valued using the StartUp attribute value, if this value exists. The application must either provide a default value that is suitable with its process, or values the attribute when accessing it on the instance
  2. Deleting an attribute in V5Rp is also possible.
    This is possible again thanks to the CATIA Feature Modeler dynamicity. If the attribute were overridden on the instance, it then becomes autonomous from the one of the StartUp, and everything happens as if this attribute were added on the instance in V5Rp. If the attribute were not overridden on the instance, it then disappears from the instance when the instance is read. The application must then be consistent: deleting an attribute from a StartUp in a catalog implies removing the code that accesses this attribute from the application
  3. Moving an attribute from a StartUp to one of its base StartUps is possible.
    Since the StartUp from which the attribute is removed derives from the StartUp to which it is moved, this attribute will remain visible because it becomes inherited. This makes it possible to share this attribute by several StartUps. The application must check that the attribute value remains consistent with the values it could have on the initial StartUps and must generate the appropriate access keys
  4. If you want to modify the type of an attribute, the new type must be compatible from the inheritance standpoint.
  5. You can't modify the sp_XX facet of an attribute of a StartUp.
    This modification cannot be dynamically propagated to the instance for which this attribute is local.

[Top]

Modifying StartUp Hierarchy

  1. You can't delete a StartUp.
    The links wouldn't be restored, even if the StartUp attributes were assigned to its parent StartUp. In addition, any instance of the StartUp would loose all the behaviors associated with this StartUp
  2. You can insert a new StartUp in the catalog StartUp hierarchy.
    This is equivalent to locally adding attributes and enriches the behaviors of the instances in V5Rp
  3. You can change the name of a StartUp.
    The key to retrieve it is its type
  4. You can't add a StartUp into a catalog if a StartUp with the same type exists in one of the prerequisite catalogs
  5. You can't move a StartUp from one catalog to another one, even if links exist between these catalogs.

[Top]

Modifying StartUp Catalogs

If a catalog existed in V5Rn, you cannot, in V5Rp:

  1. Change its name or its UID
  2. Cut it up into several catalogs, because the links when retrieving a StartUp would not be solved
  3. Cut it up into several sub containers, for the same reason.

[Top]


In Short

To ensure upward data compatibility with features relying on StartUp catalogs while modifying these catalogs, rules should be observed that deal with StartUp structure, hierarchy, and catalogs.

Top


History

Version: 1 [Mar 2000] Document created
[Top]

Copyright © 2000, Dassault Systèmes. All rights reserved.