Equipment & Systems

What You Will Learn With This Use Case

This use case is intended to illustrate how to extend an existing schematic application "CATfct" file with new StartUp classes. Please refer to Creating StartUp Objects use case for more information.

[Top]

The CAASchAppExtendCATfct Use Case

CAASchAppExtendCATfct is a use case of the CAASchPlatformModeler.edu framework that illustrates the procedures to extend "base feature" schematic application classes and their attributes.

[Top]

What Does CAASchAppExtendCATfct Do

The sample takes an input ".CATfct" file, created by CAASchAppCreateCATfct use case, containing the schematic StartUp objects Connector, Connection, FuncPart, FuncString, etc. (shown in light blue in the diagram below). It then adds new sample schematic application subclasses (shown in orange in the diagram below) to the FuncPart class, adds the attribute to the existing Connector class, and saves all the modification in the new file to a directory specified by the user.

Fig.1: Class hierarchy defined in the output CATfct file.

[Top]

How to Launch CAASchAppExtendCATfct

To launch CAASchAppExtendCATfct, you will need to set up the build time environment, then compile CAASchAppExtendCATfct along with its prerequisites, set up the run time environment, and then execute the sample. This is fully described in the referenced article [1]. When launching the use case, you must pass the following arguments:

• CAASCHEDUApp.CATfct - the entire pathname, name and extension (.CATfct) of the input file, created by (is an output from) CAASchAppCreateCATfct use case
• CAASCHEDUAppExtend.CATfct - the entire pathname, name and extension (.CATfct) of the file to be generated by CAASchAppExtendCATfct.

[Top]

Where to Find the CAASchAppExtendCATfct Code

CAASchAppExtendCATfct code is located in the CAASchAppExtendCATfct.m use case module of the CAASchPlatformModeler.edu framework:

where InstallRootDirectory is the root directory of your CAA V5 installation. The name of the source file is CAASchAppExtendCATfctMain.cpp.

Additional prerequisite code is located in the CAASchAppUtilities.m  module of the same framework.

[Top]

Step-by-Step

There are 3 logical steps in CAASchAppExtendCATfct:

1. Prolog
2. Add new subclasses and attributes 
3. Epilog

[Top]

Prolog

In this use case, we open an input "CATfct" that already has schematic StartUp objects that further subclasses are to be derived from.  Initializing the environment involves the following:

• Creating a session, namely "CAASchExtendCATfctMain_Session". This is fully described in the referenced article [2].
• Deleting any existing output file from previous execution of this sample.
• Declaring the user client ID and using that in opening the "CATfct" document using the method ::UpgradeCatalog, which allows the catalog to be upgraded. This method returns a CATICatalog pointer to the opened StartUp document.

CATUnicodeString uClientId (SCHEDUAppClientID);
rc = ::UpgradeCatalog(&uCATFctToLoad, &piCatalog, &uClientId);
  

[Top]

Adding new subclasses and attributes

Method CAAExtendBaseFeatureSU is the main method that creates new subclasses and attributes for the sample application. The code can be divided into the following steps:

• Initializing a StartUp list

  CATListPtrCATBaseUnknown *pCAASUList = new CATListPtrCATBaseUnknown();

  This list will contain a pointer to CATBaseUnknown for each created StartUp.

• Initializing StartUp class, super class, and name lists

  ...
  CATListValCATUnicodeString CAALUClass;
  CATListValCATUnicodeString CAALUSuperClass;
  CATListValCATUnicodeString CAALUName;
  //               class                              SuperClass 
  CAALUClass.Append(SCHEDUClass_Compressor);      CAALUSuperClass.Append(SCHEDUClass_FuncPart);
  ...
  CAALUName.Append(SCHEDUName_Compressor);
  ...
    

  Three CATUnicodeString lists are created: the first for the StartUp class names, the second for the StartUp superclass names, and the third for the StartUp names. The indices of a given StartUp is the same in these three lists. The CATUnicodeString classes are initiliazed in CAASchAppClassNames.h, located in the PrivateInterfaces folder of CAASchPlatformModeler.edu framework.

• Creating the StartUps

  This step is fully described in CAASchAppCreateCATfct use case.

• Cleaning-up

  The pointers in the StartUp list are released and set to NULL, and the list itself is deleted.

• Adding Attribute to one of the new StartUps

  CATBaseUnknown *pBUStartUp = NULL;
  CATUnicodeString uClassCntr (SCHEDUClass_Connector);
  if (SUCCEEDED(iCatalog->RetrieveSU (&pBUStartUp,&uClassCntr,
      "CATISpecObject")) && pBUStartUp)
  {
    CATISpecObject_var spSpecSU;
    spSpecSU = pBUStartUp;
    ...
    CATISpecAttribute *piSpecAttr = NULL;
    if (!!spSpecSU)
    {
      piSpecAttr = spSpecSU->AddAttribute (
          SCHEDUATTR_Connector_ToOtherCntr, tk_specobject); 
  	...
    }
    ...
    

  First, CATICatalog::RetrieveSU method is called to retrieve a CATBaseUnknown pointer to the Connector StartUp object, given the Connector class name. A CATISpecObject pointer is found for the Connector object and CATISpectObject::AddArttribute method is called to add a tk_specobject attribute. The attribute name is initialized in CAASchAppClassNames.h, located in the PrivateInterfaces folder of CAASchPlatformModeler.edu framework.

[Top]

Epilog

The following steps conclude the use case:

• Saving the modified/upgraded StartUp catalog "CATfct" by calling the SaveCatalog global function.

  rc = ::SaveCatalog (&piCatalog,&uCATFctToOutput);

• Deleting the created session "CAASchExtendCATfctMain_Session". This is described in the referenced article [2].

[Top]

In Short

This use case has demonstrated how to define new subclasses and attributes for a typical schematic application.

[Top]

References

History

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