Product Family Modeling

Architecture

To provide model builders with techniques for constructing architectures with multiple variants, used for modeling product families or building models with different variants for simulation and target emulation.

All ObjecTime model developers

All Versions

Products often have variations for different markets and so on. This technical note describes two approaches to this common configuration problem.

In the first approach, you build a single model with subclasses for each different configuration. Then, at run time your model incarnates the appropriate subclasses as it initializes. The second approach is to use libraries such as RCS or SCCS. In that approach, you put variants of your classes in separate libraries and you configure a family by choosing the libraries from which to merge your classes. Let's look at each approach in turn and consider how each one handles variants. As an example, suppose you have an actor class which encapsulates the state machine for handling a communicatoin protocol. Your product has two variants, one which handles the EZ protocol while the other handles the CMPLX protocol.

In the first approach, you'd have all the variants in one update. So, you'd have the Communication class and its two subclasses, EZComm and CMPLXComm (not necessarily in one update). These could all be part of a single update, or separated into different parts kept in a version control library. Only the parts necessary to create create a particular variant need be brought into an update to compile or execute that variant. Somewhere in your model you will have an actor, call it CommSubsystem, which contains an optional, Communication class reference named "Communication". If the model is your EZ protocol variant, then your CommSubsystem actor's initial transition will incarnate Communication as the type EZComm using something like:

  RPL: frame incarnate: Communication of: EZComm
  C++: frame.incarnate(Communication, EZComm);

This shows how the CommSubsystem actor incarnates the proper subclass. However, how does it know which variant should be created? If this is a MicroRTS executable, the variant could be specified by a parameter on the command line which starts up the executable. Another way is to have different top-level actors in your model each with a configuration list specifying which subclasses to create in various places in the model. That configuration list could be hard-coded in an initial transition as messages to be sent to places in the model that need to know which variants to incarnate. You can also hold the configuration list in a data class. Then, you compile whichever top-level actor corresponds to the particular configuration you want. You can also use ObjecTime's packages to hold the various variants so that they are easy to find in a library or in the model browser.

In the second approach you use different libraries to hold the various class variants making up your model. Then, you go through a specific configuration step to build the model corresponding to the particular configuration you want. For example, you would still have a CommSubsystem actor and it would still contain a Communication actor class reference. Now, you'll have two separate SCCS or RCS libraries each holding a different actor names Communication. The first library would hold the EZ variant while the second would hold the CMPLX variant. Note that both variants are named Communication. Then you merge in the specific variant you want and it replaces the Communication actor class in your update.

One drawback to the second approach is that there is no common superclass for the EZ and CMPLX variants and so it is difficult to capture any commonality. If you need to change something common to both variants, you have to modify both classes separately whereas the first approach allows you to simply modify the superclass.

None

None