Model Example

This chapter introduces an example Model that is used to illustrate correct CDL semantics and syntax.

This chapter covers the following topics:

The House Model and its Window Submodel

The parent Model is House and its child (referenced) Model is Window. The figure below shows structure diagrams of the House and the Window Models. The House Model contains a Total for Material, a Color Feature with the Options Black and White, and References to the Window Model for three FrontWindows and three SideWindows. The References each have a Position and a Size Property. The FrontWindows have Position = Front and the SideWindows have Position = Side. There are two small and one large Window in both positions, determined by the Size Property being set to small and large, respectively.

The Window Model contains two Components, Frame and Glass. The Frame Component contains numerous Features including Border, Color (with the Options White, Black, and Silver), and Finish (with the Options Matte and Glossy). The Glass Component contains several Features including Tint (with the Options Clear and Dark).

Example House Model

the picture is described in the document text

Example House Model shows the Model House as the parent Model, and a Model called Window is its child (referenced) Model. The Window Model contains a Frame Component and a Glass Component, and both Components have various types of Feature nodes.

Example Explicit Statements

For a description and general information about explicit statements, see Explicit Statements.

An example configuration rule calculates the size of glass to be put into a window frame for each Window instance. The glass is to be inserted into the Frame 1/2 inch at each side. To capture such a rule, you enter a name, such as WindowGlassSize, a description, and then associate the rule with the Window Model.

Example Explicit Statement in CDL shows the definition of WindowGlassSize written in CDL.

Example Explicit Statement in CDL

CONTRIBUTE Frame.Width - 2 * Frame.Border + 2 * 0.5
TO Glass.Width; 
CONTRIBUTE Frame.Height - 2 * Frame.Border + 2 * 0.5
TO Glass.Height;

Two statements explicitly express two Contributes to relationships between the value of the Frame’s dimensions and the glass to determine the required glass size. A semi-colon indicates the end of each statement and the whole rule definition.

Example Iterator Statements

For a description and general information about iterators, see Iterator Statements.

An example configuration rule constrains the window frame color so that for some colors, the finish is glossy. An iterator lets you define a rule that selects the glossy finish based on a Property.

In Example Iterator Statement in CDL, the variable &color refers to all the Options of the Feature Color, in the Frame Component of the Window Model. The rule selects a glossy finish when one of those colors is selected AND the Property RequiresGlossyFinish is true.

Example Iterator Statement in CDL

CONSTRAIN &color IMPLIES Frame.Finish.Glossy
FOR ALL &color IN OptionsOf(Frame.Color)
WHERE &color.Property ("RequiresGlossyFinish") = "True";

The reference to a particular Property value allows the constraining relation to be applied to a subset of the Color Options without explicitly naming the specific color. During validation, every node in Color is checked for a Property RequiresGlossyFinish. The result is that the rule iterates over all the children of Color, and for each color with the Property value set to true, the rule constrains the finish to Glossy.

The advantage of using an iterator statement is that if you add another color to the Frame Model, the rule definition does not have to be modified. Iterator statements significantly reduce the development and maintenance cost of the Model. With proper planning, the complete set of constraints could stay constant while the Model structure evolves over numerous publications.

For alternative rule definitions with similar intent, see CDL Flexibility.

CDL Flexibility

CDL flexibly supports many ways of writing the same or similar rules. This section presents the following topics:

Incremental Rules

CDL provides the flexibility to express complex rules as a series of incremental rules or those incremental rules as the subexpressions of a single, rolled up rule. Incremental Rules and Their Equivalent As a Rolled Up Rule shows two rule anatomies that express the same behavior.

Incremental Rules and Their Equivalent As a Rolled Up Rule

Incremental rules of a complex Numeric Rule.

CONTRIBUTE Frame.Width TO Glass.Width; 
CONSUMES 2* Frame.Border FROM Glass.Width; 
CONTRIBUTE 2 * 0.5 TO Glass.Width;

Rolled up complex Numeric Rule express the same behavior as the incremental rules.

CONTRIBUTE Frame.Width - (2 * Frame.Border) TO Glass.Width;

Alternative Rule Designs

As with Oracle Configurator, generally, CDL provides flexibility to express similar rule intent in various ways. Consider Example Iterator Statement in CDL, which could be designed differently, as shown in Alternative Rule Designs With Equivalent Rule Intent.

Alternative Rule Designs With Equivalent Rule Intent

To select a glossy finish for every Option of the Feature Color, make the Boolean Property RequiresGlossyFinish imply a glossy finish.

CONSTRAIN &color.Property("RequiresGlossyFinish") IMPLIES Frame.Finish.Glossy
FOR ALL &color IN OptionsOf(Frame.Color)

In this rule, logic generation executes the rule on every RequiresGlossyFinish Property in the Options of the frame’s Color Feature. Alternatively, you could write a WHERE clause that limits the rule to only those Options of the frame’s Color Feature whose RequiresGlossyFinish Property equals true, as shown in Example Iterator Statement in CDL.

Limiting the logic generation to the condition expressed in the WHERE clause is equivalent to applying a filter before execution, which usually results in better performance. When a rule iterates over a large number of options or combinations (for example, a Cartesian product), the WHERE clause does not necessarily improve performance.

Alternative Rule Design with Narrowed Conditions

In Alternative Rule Designs With Equivalent Rule Intent, the rule binds Frame.Finish.Glossy to true at startup, merely because Property RequiresGlossyFinish exists. A different approach might be to add a Special Property that limits the Options over which the rule iterates to those that alone should have a glossy finish.

CONSTRAIN &color IMPLIES Frame.Finish.Glossy
FOR ALL &color IN OptionsOf(Frame.Color)
WHERE &color.Property ("Special") = "True"
AND &color.Property("RequiresGlossyFinish") = "True";

Here, the variable &color refers to all the Options of the Feature Color, in the Frame Component of the Window Model. All Options in the Feature Color have the Special Property and this rule only iterates over those colors that are identified by &color.Property("Special")= "True". Of that subset of colors, the rule selects a glossy finish when one of those colors is selected AND the Property RequiresGlossyFinish is true.

Alternative Rule Design using AllTrue function shows the same rule intent as Alternative Rule Design with Narrowed Conditions using the AllTrue function.

Alternative Rule Design using AllTrue function

CONSTRAIN AllTrue (&color, &color.Property ("RequiresGlossyFinish")) 
IMPLIES Frame.Finish.Glossy
FOR ALL &color IN OptionsOf(Frame.Color)
WHERE &color.Property ("Special") = "True";