Concept: Part
On this page:
Definition
A part is the main building block of a product. Inside KEchain, 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 subpart 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 subparts and properties an instantiated part will have, but not the values of these properties, nor the number of subparts, which depends on the quantity of the part model.
Although the number of subparts 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.
Quantity
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, KEchain is able to enforce these statements in the Product.
Overview of quantities
This is an overview of quantity options supported for part models:
Case  Quantity  KEchain autocreates:  User can add instances?  User can remove instances?  Examples 

1  0 or more  nothing  yes  yes  One engine can have 0 or more pistons (electric drive vehicle vs. fossil fuelpowered vehicle) 
2  1 or more  1 instance  yes  if # instances > 1  Humanpowered 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 subparts a given part can have, and their quantities. If an engineer wants to use a part during a project, KEchain will instantiate this part, i.e. create a "real" one. Instantiation of parts in KEchain is comparable to instantiation in the classical sense, i.e. instantiating an object from a class. In KEchain, 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 onebyone according to their part models until the actual product emerges.
In KEchain, 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, subparts and subsubparts 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.
Examples
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 

Office building > Room 

Room > Desk  IKEA: 