ConfigModeler
High-Level Product-Modeling Environments

Product-configuration systems usually provide graphical user interfaces for product modeling, that is, for describing the configurable aspects of a product. This is fine as long as you offer only a few relatively simple products. But it does not scale well if your products are more complex or if you have many products and product components on offer. Many of your products are based on similar concepts. With the usual modeling interfaces you have to implement these concepts over and over again for each product, wich is both tedious and error-prone, and frequently leads to inconsistent configurators.

High-Level Language

Basic architecture of ConfigModeler

ConfigModeler uses a high-level language tailored to your business and provides an integrated development environment (IDE) for creating and maintaining product models conveniently. This allows you to use the concepts behind your products directly in your product models. These high-level models are then translated automatically into the format required by your configuration system.

With ConfigModeler you avoid repetitive work and mistakes, your models are easier to understand and to maintain, even by non-technical users, and your configurators will be more consistent. Furthermore, since models are (human-readable) text, you can use a plethora of modern tools working on text files.

An Example

The following example is based on a configurator from one of our customers using ConfigModeler, but has been simplified for explanation purposes.

Application Domain

Switches and Cards

Assume you are offering switches for telecommunication backbones. A carrier-grade network switch has multiple slots, which can be equipped with cards. A card provides network interfaces, called ports.

Transceivers

Transceivers convert the electrical signals from ports into the optical signals used in glass fibers and back.

While all products follow this basic structure, there are various restrictions for components to fit together, for example:

  • A transceiver can be attached to a port only if it adheres to the same interface standard. Similarly each slot only supports certain card types.
  • Some components have specific geometry restrictions. For example, a larger card may require a larger slot or two adjacent slots.
  • Most components consume some amount of electrical power and consequently they have some heat emission. Therefore appropriate power supply and fans must be provided.

Low-Level Modeling

class C12345 extends Card {
  property slot_type = "long"

  optional property port1: SFP_plus_transceiver
  ...
  optional property port8: SFP_plus_transceiver
  optional property port9: SFP_transceiver
  ...
  optional property port24: SFP_transceiver

  computed property power_consumption =
    35 + port1.power_consumption
       + ...
       + port24.power_consumption
}

With the modeling capabilities of a standard configuration system, which has no understanding of the application domain, one would have to describe products in terms of generic concepts such as classes, objects, and properties. A particular card providing 8 ports for transceivers of type "SFP" and 16 ports for transceivers of type "SFP+" might be described as in the attached box.

This language is hypothetical and used here for explanatory purposes only. With many product-configuration systems this information would have to be entered by lots of clicking in a graphical user interface. But notice that webXcerpt provides textual languages on this level for the SAP Variant Configurator and for PROS Cameleon CPQ.

High-Level Modeling

card C12345 [long] {
  ports  8 * SFP+
  ports 16 * SFP

  power 35 W
}

With ConfigModeler the same card could simply be described in a high-level modeling language for this kind of products. This makes use of the fact that modeling language, IDE, and translation support the following problem-domain concepts:

  • Cards as specific product types and ports as specific properties.
  • Slot sizes. For example, a "long" card might fit only into a "long" slot.
  • Series of ports. Since many cards provide multiple identical ports, there is a short-hand notation for this case.
  • A special syntax for transceiver interfaces, allowing to use "SFP+" as an identifier.
  • Power consumption. The translator knows that the total power consumption of a card is computed as the sum of the card's own consumption and the consumption of the transceivers plugged into its ports. So there is no need to specify a formula for the total power consumption in each card.

Benefits and Features

From the example it should be clear that with ConfigModeler

In the following two sections you find

General Benefits of Textual Editing

Textual comparison of two model versions

Certain operations on text files are provided by standard editors and other tools and do not even require these tools to have any understanding of the modeling language. Of course, these operations are also supported by the ConfigModeler IDE.

  • You can perform full-text searches over the entire set of product models or over specific parts of it. The search is not restricted to a particular object type (such as business values, configuration rules, pricing rules, etc.). Regular expressions can be used for powerful matching.
  • You can apply many changes across multiple models as search-and-replace operations. For example, you might want to replace a technical term by a more appropriate one in all your products.
  • You can copy and paste arbitrary parts of your models when needed. Similarly you can move parts of your models around.
  • To understand the difference between the models of two similar products or between two versions of the model for one product, you can use a "diff tool" for textual comparison of models. When models have diverged, the comparison tool can also help to merge them back into a unified representation.
  • You can manage versions of models with mainstream version-control systems such as Git or Subversion. Different modelers can even perform their own local changes on the model and let the version control-system merge these changes later.
  • Incomplete and inconsistent models can be represented easily. This is particularly helpful for representing intermediate states during larger changes to the model.
  • You can add comments on each aspect of a model. Parts of a model can even be disabled easily by marking them as comments. Task tags such as "TODO" or "FIXME" can be used to mark places in the code where more work is required.

Finally, and perhaps most importantly, a textual representation makes it much easier to communicate about models. You can easily add (parts of) a model to an e-mail or a presentation slide. And if you wish, you can even print it out.

ConfigModeler IDE Features

IDE for the high-level DSL: outline, error marker, content assist, tooltip

A high-level language does not only allow for concise models, but it also allows the IDE to provide more informed support for the modeler. For our example domain the IDE can

  • report an error if the modeler erroneously wants to attach ports to a component type not supporting ports, such as a rack, or if an invalid transceiver type has been assigned to a port,
  • suggest modelers to add ports and power information when they are modeling a card and suggests a set of transceiver types for a port declaration,
  • provide the modeler with the list of "long" cards as a tooltip for the declaration of a "long" slot, and provide navigation to any of these cards,
  • generate a standard visualization for a card based on its size and ports.

Integrating ConfigModeler

ConfigModeler is only used for modeling products, not during the actual configuration process. The translated models are handed over to your configuration system. End users of your configuration system will therefore not interact with ConfigModeler when configuring products. It is not even necessary to have ConfigModeler running at that time.

Another issue is that you might already have several product models in place. These models might follow certain modeling conventions (e.g., conventions for naming identifiers or preferred approaches if there are multiple ways to model certain aspects) and use a library of utility code. ConfigModeler's translation process can be adapted so that the generated models adhere to your conventions and fit seamlessly into your existing framework.

As an added bonus, the translation process can also be adapted to changes in your configuration system (version upgrades, changes to the utility library, or even replacing the configuration system with a completely different system from another vendor). ConfigModeler can greatly simplify the migration process, often requiring no changes at all to your high-level models.

ConfigModeler is implemented as a set of plugins for the Eclipse IDE based on the Xtext language development tool, the Eclipse Modeling Framework (EMF), and the Xtend programming language. This does not only allow Java programmers to make use of their Eclipse experience, but even allows to integrate ConfigModeler with the Java IDE, which you may use for implementing your utility code.

webXcerpt has implemented variations of ConfigModeler for several customers. We have particular experience with the target configuration systems SAP LO-VC/IPC (using VClipse), PROS Cameleon CPQ, and openCPQ, but models for other configuration systems can be generated as well.

Presentations

The presentations below have been given at various conferences of the SAP Configuration Workgroup (CWG). As they are by now a few years old, they might not precisely describe the current state of the tools. However, the basic ideas remain the same.

We did not yet publicly present the high-level product modeling environment we built for PROS Cameleon CPQ for a customer. Please contact us in case you are interested.

Domain-Specific Languages for Product Modeling

Configuration Workgroup (CWG) European Conference, Cologne, May 2011

This presentation introduces the idea of creating an Eclipse-based IDE for the SAP Variant Configurator which supports product modeling on different levels of abstraction (ConfigModeler and VClipse).

Building Your Own IDE

Configuration Workgroup (CWG) European Conference, Berlin, May 2012

This presentation compares product modeling with programming and applies ideas from Model-Driven Software Development to product modeling. It shows how to extend VClipse to create new product-modeling functionality. Furthermore, it discusses aspects of building a ConfigModeler-like high-level product-modeling environment.

Test-Driven Product Modeling

Configuration Workgroup (CWG) European Conference, Berlin, May 2012

Test-driven product modeling is a methodology of product modeling which leads to quick development of high-quality product models. Automatizable test case(s) are written before the product model is implemented. Subsequently the product model is modified until no test cases fail. With subsequent refactoring steps the design and implementation is improved.

With an integration of the ConfigScan test engine into ConfigModeler and VClipse test-driven product modeling will become feasible.

Our Offer

webXcerpt provides consulting and custom development related to ConfigModeler. Here are some examples of what we can do for you:

Please contact us to discuss what we can do for you or just for a demonstration of ConfigModeler.