## 4 Concept Development
### Data Model for Toolchains  
Toolchains are divided into process steps, referred to as activities (see Figure 3). An activity is characterized by the fact that one (or more) outputs (documents, models, events, etc.) result from this activity. A basic distinction is made between product-neutral and product-specific toolchains. Product-neutral toolchains describe a process for handling a task without particular products being assigned to the respective process steps. Figure 3: Conceptual representation of a BIMSWARM toolchain with contained activities, sequence flow, data flow, data objects, and start and end nodes. In the case of product-specific toolchains, particular products (as described in Section 4.1) are assigned to the individual process steps. Only product-specific toolchains can be executed, whereby product-neutral toolchains serve as templates. The latter describes the processes and can be used as a starting point for configuring product-specific toolchains by assigning products to each activity. The graphical notation and the data model of a toolchain (see Figure 2) are based on the BPMN notation. Input data and output data of the activities are defined as data objects. Based on the business process modeling according to BPMN, a toolchain also starts at a start node and ends at an end node. Other toolchains can be referenced at the start and end nodes. Furthermore, activities can run in parallel (Branch-Merge) or certain paths of the toolchain can only be executed under certain conditions (Fork-Join). Criteria for the executability of a toolchain are as follows: (1) Every activity in the toolchain has a product assigned to it. (2) The process flow is complete (consistent start to end, referring to BPMN modeling guidelines) and does not include endless loops. (3) The toolchain is completely configured, i.e., the CDE location is specified and necessary API information (e.g., BCF) is available. However, non-executable toolchains can be used to model abstract BIM use cases. The data model of the toolchain is defined according to the schematic diagram in Figure 2 and depicted in Figure 4. It provides the classes Toolchain, ToolchainMetadata, and ToolchainItem for toolchain modeling, and its subclasses ActivityItem, StartItem, EndItem, ForkItem, and JoinItem for the specific items (Figure 4, blue boxes). Moreover, the class ProductVersion is referenced from the product data model (see Figure 2) for the relation from an ActivityItem to a ProductVersion (Figure 4, green boxes). For the integration of the Toolchain and ActivityItem to the openCDE-compliant information container, the model contains the classes Container, Content, and FormatType (Figure 4, yellow boxes). To check the compatibility in the toolchain, the import or export FormatType are retrieved from the product and are attached to the respective Contents. This compatibility check then verifies the data flow (incompatible, compatible with restrictions or conversions, or fully compatible) and highlights the individual sections of the toolchain according to a color coding. Figure 4: Toolchain UML data model providing toolchain and process flow objects (blue), data flow objects (yellow), and product information objects (green) and their relations. The star character (*) is used as part of a multiplicity specification to represent an unlimited upper bound. The process for creating an ActivityItem in Composer must procedurally specify the following information: (1) name (free text); (2) activity (a characteristic referenced by input and output); (3) PTG via the productTypeReference attribute; (4) product reference to specific product version referring to the productReference attribute. Abstract use cases thus indicate work states on the way to an executable toolchain, where some information is still missing and needs to be added so that finally an execution becomes possible. However, abstract use cases can still be shared with other users of the platform.