CF パッケージの用語集

LN application classes serve as intermediary between relational LN tables and object-oriented configuration classes.

A Session in LN where data is stored assigned to classes and which is used in the Configurator package.

A class has associated data linked to it like: name, birthday.

. A persion has data allocated to 's age.

be used to calculate Pietje Puk's age, by

In the object browser you can view and maintain the Configurator data and the converted LN data in an explorer-like way.

In the Configurator framework you can define the way in which the object browser reflects the data.

An open folder and closed folder icon can be used by a configuration view component of type view category.

An application can be used by a configuration view component of type configuration class.

特徴: 基本色

特徴オプション: 赤、緑、または青

As an example of an option package consider the feature "edition". This feature has two predefined options standard and luxury. In addition to these two features, the features sunroof and air-conditioning exist. Both features have two predefined values: yes and no. An option package can now be defined to state that a luxury edition implies the inclusion of both sunroof and air-conditioning. On the other hand, another option package can be used to define that a standard edition has no sunroof and no air-conditioning. Formally this can be expressed by two option packages X and Y.

X: (edition, luxury) -> {(sunroof, yes), (air-conditioning, yes)} Y: (edition, standard) -> {(sunroof, no), (air-conditioning, no)}

Option packages come in two different types: Commercial, Technical. These types only influence the way option packages are used. Commercial packages are visible to the user because they carry commercial semantics. Technical option packages only have technical use, and therefore, these options are not presented on the user interface.

An option package can now be defined to state that a luxury edition implies the inclusion of both sunroof and air-conditioning. On the other hand, another option package can be used to define that a standard edition has no sunroof and no air-conditioning. Formally, this can be expressed by the two option packages X and Y.

X: (edition, luxury) -> {(sunroof, yes), (air-conditioning, yes)} Y: (edition, standard) -> {(sunroof, no), (air-conditioning, no)}

Option packages come in two different types: Commercial, and Technical. These types only influence the way option packages are used. Commercial packages are visible to the user because they carry commercial semantics. Technical option packages only have technical use, and, therefore, these options are not presented on the user interface.

Only features that have the domain list can have options. All features that have another type of domain have option values.

In the figure above you see the user interface components and their relations (called user interface component relationships).

A component of the user interface dialog. Each component has its own characteristics. There are components that only influence the layout of the user interface dialog (For example form, tabbed dialog, form tab and frame) and components that are able to handle data (text box, drop down list box and option button).

As an example see the figure below. The components Form Tab 1, Form Tab 2, and Form Tab 3 are children of the parent Form. The components Frame 1 and Frame 2 are children of the parent Form Tab 1. And so on.

In the example above you see the user interface components and their relations (called user interface component relationships).

An example is the BOM-relation which cannot exist on its own. The life of a BOM-relation depends on the life of an item to which it is related. If the item is deleted all the BOM-relations are deleted as well.

For instance, the class Volvo has a relation with three other classes namely the dependent classes Volvo truck, Volvo van and Volvo family car. The relation type between Volvo and the types could be for instance "One of the car types of Volvo".

You can inherit classes related to the class Volvo (for instance the class Color) to the classes Volvo truck and Volvo family car. As a result, these both classes have a relationship type called for instance 'Color options'. So the objects within the class family car do have a relation with the objects in the class color for instance Red, Blue.

For instance an engineering view uses features which are not used in the marketing view. To limit the number of features and options that can be inherited from the engineering view to the marketing view you must specify an inheritance filter.

Application of inheritance relationships between classes result into super-classes and sub-classes. The derived class is the sub-class. The original class is known a super-class.

A class can have data linked to it, for example Name and Date of Birth. A class can also have associated application logic linked to it. For example, Age can be calculated from today's date and Date of Birth.

A configuration event is identified with an configuration event identification.

The menu is made up out of configuration view components. The hierarchy between these configuration view components is defined by the configuration view component relationships.

The dialog consist of user interface components. The hierarchy between these user interface components is defined by the user interface component relationships.

As an example see the figure below. The components Demonstration, Line Structure, and Parameters are children of the parent Main Menu. The component Demonstration Dialog is a child of the parent Demonstration. Because this is a configuration view component of type configuration class which represents an application this is also the lowest level of the menu structure.

Each user can have multiple roles, and each role can relate to multiple users. However, a user can be active (logged-on) in only one role at the time.

One application is the translation of the customer requirements into the product structure of the variant. The configuration constraints indicate which components and operations will be used in a specific product variant.

Explanation of each part its function:

Condition part

A condition part is a Boolean expression that expresses under which circumstances options have to be included, excluded or selected. The condition part checks a feature against a certain option value.

Inclusion part

The inclusion part is that part of a configuration constraint rule that expresses which options should have been selected. If this is not true, the configuration constraint is said to be violated.

Exclusion part

The exclusion part is that part of a configuration constraint rule that expresses which options should not have been selected. If this is not true, the configuration constraint is said to be violated.

Selection part

The selection part is that part of a configuration constraint rule that expresses which options will be selected. This configuration constraint can not be violated because option selection will be enforced. In other words, the options will be set as defined.

The general format of the if-then statement is: IF <condition part> THEN INCLUDE <inclusion part> EXCLUDE <exclusion part> SELECT <selection part>

有効性管理では、参照日と発効日および失効日が照合されます。参照日が発効日より後の場合、構成エンティティは有効です。 参照日が失効日より後の場合、構成エンティティは有効でなくなります。

If the resource value is limited to a certain interval by means of minimum and maximum features, LN checks if a supplying feature does not exceed the maximum resource value and a consuming feature does not exceed the minimum value.

有効性管理では、参照日と失効日が照合されます。参照日が失効日より後の場合、構成エンティティは有効でなくなります。

有効性管理では、参照日と発効日が照合されます。参照日が発効日より後の場合、構成エンティティは有効です。

変更オーダは、オプションベースまたは日付ベースにできます。変更オーダが日付ベースの場合、失効日/発効日と参照日の組み合わせにより、変更オーダが有効かどうかが決まります。

オプションベースの変更オーダは、オプション値の観点で条件を表現するために使用されます。たとえば、特定のシリアル番号に到達したときに変更オーダが有効になったり、特定のシリアル番号で変更オーダを有効にしたりします。

A change order can be option based or date based. When the change order is date based, the expiry and/or effective date, in combination with a reference date, determine the validity of the change order.

Almost every entity modeled in the Configurator has an effective date and an expiry date that defines the entity's validity period. If a reference date is specified, you can check whether the entity is valid.

If the effective date is B and the reference date is C, the entity in Configurator is not valid.

If the expiry date is B and the reference date is C, the entity in Configurator is valid in the interval (C <-> B).