COINS Library 1.1

(Verschil tussen bewerkingen)
Versie op 25 apr 2014 07:23
Peter Willems (Overleg | bijdragen)
Amount property type
← Previous diff
Huidige versie
Peter Willems (Overleg | bijdragen)
Supertype hierarchy
Regel 39: Regel 39:
=== Supertype hierarchy === === Supertype hierarchy ===
-A <tt>[[CataloguePart_Class|Catalogue Part]]</tt> may reference another <tt>[[CataloguePart_Class|CataloguePart]]</tt> as its supertype. This modelling construct introduces (single) inheritance into a catalogue part library. The supertype semantics allow both property type as well as property value inheritance.+A <tt><big>[[Cbim:CataloguePart_1.1_Class|Catalogue Part]]</big></tt> may reference another <tt><big>[[Cbim:CataloguePart_1.1_Class|Catalogue Part]]</big></tt> as its supertype. This modelling construct introduces (single) inheritance into a catalogue part library. The supertype semantics allow both property type as well as property value inheritance.
[[Afbeelding:ConcreteBeamCataloguePart.png|frame|center|''Figure 6: A COINS Navigator screen grab of the specification of a concrete beam catalogue part founded on a beam catalogue part as its supertype.'']][[Afbeelding:ConcreteBeamCataloguePart_UML.png|frame|center|''Figure 7: A UML instance diagram of the specification of a concrete beam catalogue part founded on a beam catalogue part as its supertype. To simplify the diagram the property value boxes plus connecting relation links are substituted by a mock link annotated with the property value'']] [[Afbeelding:ConcreteBeamCataloguePart.png|frame|center|''Figure 6: A COINS Navigator screen grab of the specification of a concrete beam catalogue part founded on a beam catalogue part as its supertype.'']][[Afbeelding:ConcreteBeamCataloguePart_UML.png|frame|center|''Figure 7: A UML instance diagram of the specification of a concrete beam catalogue part founded on a beam catalogue part as its supertype. To simplify the diagram the property value boxes plus connecting relation links are substituted by a mock link annotated with the property value'']]

Huidige versie

A COINS Library is a universal designation for a model that complies with the COINS standard but that can be utilized beyond a specific project scope. Typical applications are:

  • Catalogue part library
    A set of catalogue part descriptions that can be reused in various projects.
  • Property types set
    Set of standard property types.
  • Templates
    Global information structure of a specific product type, e.g. bridge template, highway template, office template, etc.
  • All COINS models that are imported in a sub-model hierarchy
    especially practical in large project (various sections of a railway project that are tendered to various contractors) or to organize variant elaborated designs.

The remainder of this article will focus on the various ways to set up a catalogue part library.

Inhoud

Catalogue Part Library

A catalogue part library contains a set of catalogue part objects which collectively may structure a type hierarchy and/or decomposition structure.

Figure 1: A UML class diagram of the CataloguePart class and its direct relations with neighbouring classes.
Figure 1: A UML class diagram of the CataloguePart class and its direct relations with neighbouring classes.

The catalogue part object class has a rich set of relation types that is able to support complex hierarchical information structures. The next paragraphs will give a walk through of the various modelling constructs.

Properties

Specifying properties is probably the most basic modelling construct for catalogue part objects. The CBIM schema distinguishes Property Types and Property Values, where a Property Value always references a Property Type.
Take for example a beam catalogue part with dimensional properties length, width and height.

Figure 2: A COINS Navigator screen grab of the specification of a beam catalogue part with three dimensional properties.
Figure 2: A COINS Navigator screen grab of the specification of a beam catalogue part with three dimensional properties.
Figure 3: A SketchUp screen grab of the 3D representation of a beam catalogue part with three dimensional properties.
Figure 3: A SketchUp screen grab of the 3D representation of a beam catalogue part with three dimensional properties.
Figure 4: A UML instance diagram of a beam catalogue part with three dimensional properties.
Figure 4: A UML instance diagram of a beam catalogue part with three dimensional properties.

Amount property type

A special kind of property is the amount property. An amount object keeps the amount of a certain catalogue part with regard to an assembly object. Such an assembly object could be a physical object node in the object tree. To compile a bill of quantities most catalogue parts will be counted piecewise. For this reason the CataloguePart class is a subclass of the PropertyType class. The amount property is in that case identical to the catalogue part itself. But in other cases it could be that the quantity of a catalogue part is measured by its length or area or volume or mass, etc. One of the properties of the catalogue part is then selected as the amount property.

Figure 5: The iron wire catalogue part specification (left) promotes ist length property as amount property. When this catalogue part is used (right) this property determines the quantity of the iron wire catalogue part.
Figure 5: The iron wire catalogue part specification (left) promotes ist length property as amount property. When this catalogue part is used (right) this property determines the quantity of the iron wire catalogue part.

Complex property

Simple properties are single valued. A complex property however may handle a set of properties.
Complex property values are part of the reference framework Functional Specifying.
A typical example of a complex property is material. A specific material will contain a set of standard properties (e.g. density, melting point) which are universal for all materials and a set of specific properties that only occur for a certain group of materials (e.g. yield strength). Complex property values are stored in catalogue part objects and will generally form a family using the supertype construct.

Figure 6: Complex values will generally form a family tree that is structured according the supertype relation.
Figure 6: Complex values will generally form a family tree that is structured according the supertype relation.

A property type definition can be defined complex by setting its value domain index to complex value and by selecting a so called template. The template will form the root of all selectable values of this property type.

Figure 7: Setting the template for all selectable complex values for this property type. A template further down the family tree will restrict the set of selectable values.
Figure 7: Setting the template for all selectable complex values for this property type. A template further down the family tree will restrict the set of selectable values.

If the root of the family tree (here Material) is selected as template all descendant complex values in the family tree are qualified for value selection. If for example Steel is assigned as template only descendant values of Steel will appear in the selection box of selectable values.

Figure 8: Setting the actual value offers a choice between all selectable complex values which share the template as a common root.
Figure 8: Setting the actual value offers a choice between all selectable complex values which share the template as a common root.
Figure 9: Instance diagram showing the data structure of catalogue part Beam that specifies a material complex property value Concrete. The PropertyValue class is extended in the reference frame Functional Specifying with the complexValue functional property.
Figure 9: Instance diagram showing the data structure of catalogue part Beam that specifies a material complex property value Concrete. The PropertyValue class is extended in the reference frame Functional Specifying with the complexValue functional property.

Supertype hierarchy

A Catalogue Part may reference another Catalogue Part as its supertype. This modelling construct introduces (single) inheritance into a catalogue part library. The supertype semantics allow both property type as well as property value inheritance.

Figure 6: A COINS Navigator screen grab of the specification of a concrete beam catalogue part founded on a beam catalogue part as its supertype.
Figure 6: A COINS Navigator screen grab of the specification of a concrete beam catalogue part founded on a beam catalogue part as its supertype.
Figure 7: A UML instance diagram of the specification of a concrete beam catalogue part founded on a beam catalogue part as its supertype. To simplify the diagram the property value boxes plus connecting relation links are substituted by a mock link annotated with the property value
Figure 7: A UML instance diagram of the specification of a concrete beam catalogue part founded on a beam catalogue part as its supertype. To simplify the diagram the property value boxes plus connecting relation links are substituted by a mock link annotated with the property value

Figure 6 and 7 show an example where a catalogue part Concrete Beam inherits from a catalogue part Beam both property types and associated property values. Because the inherited property values cannot be overwritten the Navigator represents these rows dimmed. The semantics are that the subtype catalogue part is also a supertype catalogue part (it belongs to the same category), overwriting a property value would violate this condition.
The material property is not inherited and its value may freely be chosen (although the naming of the catalogue part seems to restrict this freedom).

If the supertype catalogue part specifies a property type without giving it a value (value attribute of the property value object is empty) the semantics are that subtype catalogue parts are free to give it a value (or not: delegating this degree of freedom further down the type hierarchy).

Figure 8: COINS Navigator screen grabs of the specification of a concrete beam catalogue part founded on a beam catalogue part as its supertype. The length property is not valued by the supertype and can be specified by the subtype.
Figure 8: COINS Navigator screen grabs of the specification of a concrete beam catalogue part founded on a beam catalogue part as its supertype. The length property is not valued by the supertype and can be specified by the subtype.
Figure 10: UML instance diagram of the specification of a concrete beam catalogue part founded on a beam catalogue part as its supertype. The length property is not valued by the supertype and can be specified by the subtype.
Figure 10: UML instance diagram of the specification of a concrete beam catalogue part founded on a beam catalogue part as its supertype. The length property is not valued by the supertype and can be specified by the subtype.

This modelling construct facilitates the specification of catalogue part families, in this example a family of beams with different lengths.

Figure 11: SketchUp representation of three beam catalogue parts of different lengths founded on a generic beam catalogue part as its supertype. The length property is not valued by the supertype and can be specified by the subtypes.
Figure 11: SketchUp representation of three beam catalogue parts of different lengths founded on a generic beam catalogue part as its supertype. The length property is not valued by the supertype and can be specified by the subtypes.

Assembly hierarchy

The catalogue part data-structure facilitates also a modelling construct to build assembly hierarchies (decomposition). The basic approach is that a new catalogue part can be specified by combining already available catalogue (sub)parts. For example a portal can be composed from two column parts and a beam part.

Figure 12: UML instance diagram of a portal catalogue part that is composed from a column catalogue part (twice) and a beam catalogue part. Locators position the subparts at the right location and orientation.
Figure 12: UML instance diagram of a portal catalogue part that is composed from a column catalogue part (twice) and a beam catalogue part. Locators position the subparts at the right location and orientation.
Figure 13: SketchUp representation of multiple instances of an assembly catalogue part
Figure 13: SketchUp representation of multiple instances of an assembly catalogue part
Afkomstig van CoinsWiki NL, de Vrije Encyclopedie. "http://www.coinsweb.nl/wiki/index.php/COINS_Library_1.1"
Personal tools