A part is the main building block of a product. Inside KE-chain, a part can be split into two categories: part model and part instance. A part model represents the definition of the structure of a part instance and is found in the data model. Each part model can have an arbitrary number of properties. Furthermore, part models can be nested under one another: a part model can have sub-part models or a "parent" part model can have "child" part models. From a part model, a part instance can be instantiated in the explorer. This happens during work on an operational project. Before starting such a project, it is already known what part models the data model will have. The part model "knows" what sub-parts and properties an instantiated part will have, but not the values of these properties, nor the number of sub-parts, which depends on the quantity of the part model.
Although the number of sub-parts in a part instance is not known beforehand and can vary, lower and upper bounds for this number can be defined by setting a quantity for the part model with respect to ts parent part model.
The quantity of a part model defines upper and lower bounds for the number of parts instantiated from this model that can be associated to a single instance of its parent part model. The concept is very similar to multiplicity in UML class diagramming. Through the concept of quantity, it becomes possible to make formal definitions in the product model of statements like "A table will have 4 legs" and "A vehicle will have 1 or more wheels". Subsequently, KE-chain is able to enforce these statements in the Product.
Overview of quantities
This is an overview of quantity options supported for part models:
User can add instances?
User can remove instances?
|1||0 or more||nothing||yes||yes||One engine can have 0 or more pistons (electric drive vehicle vs. fossil fuel-powered vehicle)|
|2||1 or more||1 instance||yes||if # instances > 1||Human-powered vehicles can have 1 or more wheels (unicycle, bicycle, etc.)|
|3||Exactly 1||1 instance||no||no||One bicycle must have Exactly 1 handlebars|
|4||0 or 1||nothing||if # instances = 0||if # instances = 1||One chair can have 0 or 1 backrests (stool vs regular chair)|
Relation between part models and part instances
The structure of each part is laid out in its part model. This part model defines what properties and sub-parts a given part can have, and their quantities. If an engineer wants to use a part during a project, KE-chain will instantiate this part, i.e. create a "real" one. Instantiation of parts in KE-chain is comparable to instantiation in the classical sense, i.e. instantiating an object from a class. In KE-chain, a part instance is a representation of a real product. At the start of a part instance, the structure of the product model is already known. This means that it is known beforehand what part models and properties the data model will have, but not how many there will be and the property values. During project execution, the parts in the product model are instantiated one-by-one according to their part models until the actual product emerges.
In KE-chain, part instantiation logic is as follows:
- Part instances are instantiated based on a part model.
- All part instances together (with their properties and structure) form the product
Relation to product
A product is built up out of a number of parts, usually large. Parts are hierarchical (nested), i.e. parts can have properties, sub-parts and sub-sub-parts and so on. The figure below gives an idea of the position of parts within a product. It was taken from http://en.wikipedia.org/wiki/Product_structure_modeling.
The following table shows the difference between parts and part models by listing some examples of part models and the parts that could be instantiated from them.
|Part model||Part (instance)|
|Office building > Room|
|Room > Desk|