Specifiation of Libraries
This document is addressed to procurers of GDL libraries. Its intentions should be considered both in contracted and in in-house situations.
2. Defining Requirements
The complexity of the library part should be carefully considered: a very sophisticated object is also very difficult to use. An element can be a composite of smaller parts, which will reduce the number of parameters and/or the size of the library part. A large library part's modeling process can be very slow. The number of parameters is limited to 512.
The abstraction level of the same library part can vary depending on its different representation forms. A sophisticated 2D symbol can sometimes be used as a simple 3D model. These types of decisions must be made before the other phases of specification.
First of all, the purpose and the function of the library part must be clear. Therefore, all parameters must be designed together with their hierarchy, to give a perfect overview of the library part's function: the level of abstraction, features, 2D/3D representation, and the section and elevation shape. The most basic question is: what is this library part used for?
The parametrizing logic must be reflected in the arrangement of the parameters: groups of parameters should be created and the connection between them must be defined clearly (later implemented in the Parameter Script). To accomplish this, links between different parameters must be carefully analyzed.
Detailed specification drawings must be prepared
before the creation of a new library is started.
Specification drawings must contain every version of each unique library part:
- They must be drawn in different scales if the 2D/3D models will change depending on the scale.
- Independent versions must be drawn for windows/doors, both with and without composite parts (sidelights, transoms, wall joints).
- They should contain plan symbol, elevation and section view in a consistent way.
- All parameter names and all fixed sizes must be shown on each drawing.
- For further modifications, even for fixed sizes, use a variable on the drawing and in the scripts. To avoid unexpected situations, an additional or internal parameter can be made for all attributes (e.g., pen or fill number) that may be changed from one version to the other.
- The drawings must always show the model, as it should appear. To avoid misunderstanding, sketches that are less detailed than the required result cannot be accepted.
The specification drawing must contain everything that is important for the client. The programmer will not complete what is not shown on specification drawings. Therefore, good communication is needed between client and programmer to avoid having to make serious modifications in an advanced phase of the library development.
Usually, it is impossible to define the clear specification for a never seen functionality in advance. Prototypes are a good solution for both the customer and the developer to communicate the requirements and the specification. To represent the requests and the possible solutions in an advanced form, a prototype should be created for one or more basic elements of the library.
Prototypes must be checked very carefully by the customer. They should contain all parameters, options and features of the final library part. Very often, this is not possible in an early stage of the development, so library parts must be prepared to easily handle modifications. For this reason, a library part should never be considered as an ultimate solution for the client's requests.