BUS606: Operations and Supply Chain Management

Abstract models on the meso-level provide conceptual frameworks for understanding how meso-level process flows, or models of them, relate to the design's progression. In contrast to other categories of meso-level model, they do not specify or analyse tasks in detail.

Some abstract models conceptualise the design process as a series of tasks that transition in a progressive way between the different types of information or knowledge that are used as a design is created. Many of these are informed by the early work of Hubka, Andreasen, and others who showed how a mechanical design can be described as a structure of information that cuts across different "domains". Overviews of the product-focused aspects of this work can be found in Buur, Andreasen, Eder, and Hubka. Applying these concepts to the design process, Theory of Domains contends that designers consider an emerging mechanical design from four perspectives or domains: (1) a process of transformations effected by the product in use; (2) functions that provide those transformations; (3) organs which provide physical effects required for functions, through interaction between parts; and (4) physical parts themselves. The theory states that designers establish these domains in the sequence listed above, noting that stepping back and forth between them is also likely. Within each domain, a design is described by multiple product models that can each be categorised on a two-dimensional grid: abstract vs. concrete, and simple (undetailed) vs. total (detailed) (Fig. 10). Micro-level procedural models such as those reviewed in Sect. 3.1 can be seen as either assisting work within a domain or guiding transitions between domains.

Related to the theory of domains, Grabowski et al. develop the Universal Design Theory (UDT) based on the concept of design working spaces (DWSs). Each DWS is bounded by constraints that determine how it fits into a higher level system, and comprises the design's elements and relationships that are developed through four stages, namely requirements, functions, physical principles, and parts. The design process is seen as a series of operations in which a solution is progressively developed within its DWS by stepwise moves that can be categorised on three dimensions. The first dimension is concretisation vs. abstraction. For example, concretisation might move a solution state from functions to structures, while abstraction might move it in the opposite direction. On the second dimension, detailing vs. combination, a problem is decomposed into subproblems with their own DWSs, or subsolutions are combined into higher level solutions. On the third dimension, variation refers to searching for alternative solutions on the same level of abstraction, while its counterpart, limitation, refers to adding constraints that reduce the solution space. Grabowski et al. also emphasise the importance of guiding the process from one step to the next.

Finally, characteristics-properties modelling/property-driven development (CPM/PDD) was developed to provide a theoretical framework for integrating computer tools into the design process and vice versa. CPM/PDD states that a design comprises characteristics, which are set by designers, and properties, which describe the design's resulting behaviours. A design process is presented as a collection of synthesis tasks, which determine or create characteristics from desired properties, and analysis tasks, which determine properties from characteristics. The model suggests that tasks are also influenced by external conditions, such as load cases, and can be supported through prescriptive methods such as those discussed in the previous sections. Key features of design that the model aims to encompass include: how the process is driven by the difference between desired and real properties; how the product definition becomes more complete over time as more characteristics are created and their values determined; how partial solutions can be integrated into an emerging design; and how iterations may be caused by conflicts, e.g., when multiple synthesis tasks affect the same properties.