This step is also demoed with this video :

(ongoing...)

Step 0i : Modules copy

This step 0i deals with modules copy.

Indeed, once a family of modules has been created, for example FB_LatAcc :

Basicaly, this function enables to copy all versions of a family of modules according to this figure :

Capitalized versions needs a remote storage capability and enables to maintain traceability between modules (see step 6).

As a result, copy process of a family of module only deals with the user versions as shown on the drawing, and capitalized versions will not be taken into account.

As Copy is pushed, it appears the interface :

(Table on the right deals with the potential impact of the copy on assemblies, it is explained step 1f)

Suppose that user wants to copy FB_LatAcc to FB_LatAcc_copy, then :

As we can see :

• • only user versions have been copied

  • origin version has been emptied because capitalized versions can not be handled

  • string of characters (copy) has been added at the beginning of each comment

Moreover, if the prefix of the module is changed, the potential outputs of the module having this prefix are changed in the library.

As an example, if FB_LatAcc is copied to newPref_LatAcc_copy, then FB_ outputs are renamed into newPref_ output :

For example, if FB_LatAcc_copy is copied to newPref_LatAcc_copy :

we can see that for example output FB_output has been turned into newPref_output :

Of course, the copy functionality is still valid for architecture and assembly.

Moreover, see step 1f for possible impact of a copy on assemblies.

At this stage, main functionalities on MODULES have been explained :

Step 1 is dedicated to ASSEMBLIES.

Before that, Validity feature of a module is explained next step 0j.

Published with MATLAB® R2013a