Linkage meta-modelling to support the development of design process ...

3 downloads 1204 Views 3MB Size Report
complex networks of interactions between heteroge- neous 'elements' such as designers, activities, and components. Approaches to support design process.
Proceedings of TMCE 2008 Symposium, April 21–25, 2008, Izmir, Turkey, edited by I. Horv´ath and Z. Rus´ak c Organizing Committee of TMCE 2008, ISBN 978-90-5155-044-3

LINKAGE META-MODELLING TO SUPPORT THE DEVELOPMENT OF DESIGN PROCESS IMPROVEMENT TOOLS David C. Wynn Engineering Design Centre University of Cambridge United Kingdom [email protected]

P. John Clarkson Engineering Design Centre University of Cambridge United Kingdom [email protected]

ABSTRACT Product development systems may be described as complex networks of interactions between heterogeneous ‘elements’ such as designers, activities, and components. Approaches to support design process improvement which take this view are based on the development and analysis of linkage models – i.e., representations of the elements and the relationships between them. This paper proposes that the development of such approaches can be facilitated by linkage meta-modelling, which we argue can substantially reduce the time and expertise required to implement new approaches in software. A linkage meta-model is defined as a formal, computable description of the elements allowed in a modelling framework, the constraints upon relationships between them and the views used to manipulate models. The linkage metamodelling approach was implemented in a matrixoriented software platform and illustrated by application to develop an implementation of the Contact and Channel modelling framework.

KEYWORDS Linkage meta-model, ontology specification language, complex design systems, P3 Signposting

munication between team members and the flows of information between design activities may all be described in this way. This paper introduces a linkage meta-modelling approach to describe such models in terms of the classes of element allowed, the constraints placed upon linkages between them and the multiple views used to visualise and manipulate the dataset. We propose that our approach can support research by reducing the effort required to develop software tools for modelling design systems as networks of dependencies. Many approaches to support design process improvement are based on this type of model. The paper proceeds as follows. In Section 2, the background and motivation of the research is discussed. Section 3 introduces the basis of the linkage meta-modelling approach. Section 4 discusses it in detail. Section 5 illustrates the approach by developing a linkage meta-model to implement the Contact and Channel product modelling framework proposed by Albers, et al. (2003). Section 6 briefly discusses the approach’s implementation in the P3 Signposting software. Section 7 reflects upon the strengths and limitations of the approach and indicates the main directions for further work. Section 8 concludes.

1. INTRODUCTION

2. BACKGROUND

The design and development of complex adaptive products, such as those found in the aerospace and automotive industries, may be modelled as a network of interactions between elements in different domains. For example, the structure of components and subsystems in a product, the network of com-

The motivation for this research arose from the development of a model-based method to support programme management in aerospace design. The method was developed through a case study in which eight months was spent on-site at a large U.K. aerospace company (Wynn, et al., 2005).

1037

The case study incorporated software development as an important aspect of the research methodology, undertaken to allow continuous evaluation of the emerging method through feedback to stakeholders and thereby to ensure the research direction was appropriate to industry requirements. Although this approach proved extremely helpful, the majority of research effort was ultimately expended in software development. Furthermore, the prototype tool never reached sufficient reliability for deployment; although functional and sufficient to demonstrate the concept of the support method, at the time the study was completed it could only operate as a demonstrator whose use was facilitated by the researcher.

the strongly-connected networks of elements which are often required to model such systems (see, e.g., Danilovic, Browning, 2007). This requirement focused the research on supporting the development of matrix-oriented modelling tools, rather than the flowchart-oriented tools which are more commonly available.

Following conclusion of the study, it was hypothesised that a configurable software platform could have significantly reduced the time spent programming and therefore allowed effort to be concentrated on the ‘research-oriented’ aspects of method development – such as observing current practice, clarifying requirements, and generating conceptual improvements to the proposed support method. Furthermore, it was believed that such a platform would have allowed development of a production-quality support tool suitable for deployment in the company. This led to the following research objective:

Design research typically aims to both understand and improve the design process (Blessing, et al., 1995). Blessing, et al. propose that this may be achieved through four main research phases: Criteria, in which the success criteria for the work are developed; Description I, in which a detailed understanding of the problem is formulated, perhaps through exploratory case studies; Prescription, in which theories and support methods are developed together with any computer tools; and Description II, in which the research results are validated against the original criteria, perhaps through additional case studies. The work presented in this paper aims to support the Prescription, i.e., method development stage of Blessing’s methodology.

Develop an approach and configurable software platform to reduce the effort of implementing linkage-based modelling tools. In this context, a linkage-based modelling tool is viewed as any software which allows users to construct models based on elements in a domain and the networks of linkages between them. We view all such models as linkage models and the modelling languages on which they are based as linkage modelling frameworks. The objective is of general interest because many researchers are concerned with developing and analysing these types of model – for instance, Browning, Ramasesh, (2007) identified over 400 publications relevant to activity network models of design alone.1 This paper introduces the approach which was developed to meet the above objective. Although our method could be applied to support the development of linkage modelling approaches in any domain, we concentrate on complex design systems and particularly the need to visualise and manipulate 1 Other types of model which are common in engineering but which we do not consider in this paper include heuristic, statistical and formal mathematical models.

1038

2.1. Developing model-based methods for design process improvement This section discusses the process of developing model-based methods and thereby argues that supporting the development of modelling tools can result in more effective improvement methods.

Within the Prescription stage, developing a modelbased method typically includes the following activities: • Identifying the objectives of the approach and relevant stakeholders. • Eliciting general knowledge to understand key factors governing the domain to be modelled in the context of the objectives. • Developing a modelling framework and support approach. • Implementing a software tool to allow manipulation of models. • Eliciting system knowledge from domain experts and developing a coherent mental model. • Constructing a formal or semi-formal representation of this model. • Analysing the representation to identify and/or evaluate possible improvements. In practice, this usually involves significant and disordered iteration as the method is refined during development (Figure 1). For example, elicitation of specific domain knowledge often leads to refine-

David C. Wynn, P. John Clarkson

Figure 1 Developing a model-based method to support design process improvement can be a highly iterative process in which software development forms a major component of total effort expended (Wynn, 2007)

ments in the general domain understanding, necessitating changes to the modelling framework. The premise of this paper is that one of the most time-consuming aspects of this cycle is software development. Furthermore, although many analysis algorithms used by support methods (such as Monte-Carlo simulation) are relatively straightforward to implement, developing the robust user interfaces needed to manipulate and visualise large models requires expert knowledge and software development skills which many researchers may not possess. Supporting this aspect of method development would allow effort to be focused on other phases of the process, thereby enabling more refinement iterations and ultimately resulting in more appropriate support methods. Furthermore, reducing the cost and expertise required for software development would allow approaches, once developed, to be more easily customised to better support specific application domains. For instance, the flexibility to create additional data fields in a process modelling tool would often add significantly to its potential to support future research. Although commonplace in mainstream software development, such flexibility is often not incorporated in research tools due to the development overhead it incurs.

2.2. Related work Our approach of viewing design systems as networks of elements and designing support systems through an iterative process of in-situ refinement is similar to that taken by Subrahmanian, et al. (1997) in developing the n-dim information modelling infrastructure. Similarly, Pavkovic, et al. (2002) propose an

object-oriented approach for modelling the relation network between elements and show how the structure of this network can be visualised in a Dependency Structure Matrix (DSM). Kremer, (1997) proposes a meta-language to constrain the relationships between elements in a linkage model. These publications focus primarily on knowledge representation and do not discuss how models can be processed to provide alternative perspectives for visualisation and manipulation. As outlined below, this is necessary to manage the large data sets required for modelling complex systems and is an important aspect of our approach. As a formal description of an information domain, the approach proposed in this paper is also related to ontology specification languages such as Ontolingua (Gruber, 1993) and OWL (Bechhofer, et al., 2004). Similarly, our software platform is related to ontology modelling tools such as Prot´eg´e-2000 (Noy, et al., 2000). Corcho, G´omez-P´erez, (2000) review these approaches, noting the different expressive capabilities of each and how this is related to their intended applications, with particular emphasis on automatic inferencing. The objective of the research presented here is to reduce the effort involved in developing interactive modelling tools. Therefore, the expressiveness of our approach was developed to facilitate user interface development instead of the automated reasoning about a knowledge base which is the objective of much ontology modelling research. The Design Structure Matrix (DSM) proposed by Steward, (1981) is another approach which has been applied to model the network of dependencies in complex design systems. The DSM is a square ma-

LINKAGE META-MODELLING TO SUPPORT THE DEVELOPMENT OF DESIGN

1039

trix which lists the elements in a domain as row and column headings, and linkages between those elements as marks placed in the cell linking the source element (in the column) to the sink element (in the row). The Multiple Domain Mapping Matrix (MDMM) extends this concept by coupling multiple DSMs, each representing a different domain, with additional non-square matrices. These represent the linkages between elements in two different domains. For instance, Danilovic, Browning, (2007) discuss the application of MDMMs to explore the architecture of design processes by modelling the linkages across domains including components, activities and people. They argue that key benefits of this approach include improved traceability of connections between domains and the possibility for crossverification of models by considering matrices independently and in combination. Eichinger, et al. (2006) discuss how consideration of indirect linkages in an MDMM model (e.g., a linkage between two task elements via the information element they require and produce) can be used to identify dependencies between domains which might be overlooked. MDMM modelling and analyses have recently been implemented in a number of software tools such as LOOMEO/MOFLEPS (Maurer, et al., 2005). These matrix models provide a concise visualisation of strongly-connected networks of interdependencies. They can easily be customised to model any set of domains by adding more matrices, and linkages between elements may be qualified to any level of detail by replacing the binary marks in matrix cells by sets of properties. Due to this flexibility and suitability for visualising the dense dependency networks found in many aspects of complex design systems, the matrix visualisation forms the basis of our approach. However, with respect to the wide range of possible linkage modelling applications matrix models have two limitations which this research aims to address. Firstly, the number of cells in a matrix increases with the product of the number of elements in the two domains which are mapped; matrices are thus cumbersome for large models and especially those in which connectivity tends to increases in linear proportion with the number of elements. Wynn, (2007) observed that this occurs when modelling processes using task precedence models such as PERT – large process models can be simultaneously too stronglyconnected for visualisation in a flowchart and too sparse for effective representation in a matrix.

1040

This tends to arise because processes, like many other aspects of design systems, are deliberately partitioned in order to manage the complexity within; there are thus relatively few linkages across levels of the hierarchy (e.g., limited information flow between tasks conducted by personnel working on different sites of an organisation; limited parametric interdependence between components in different modules of a product; or the decomposition of a process such that each designer is only responsible for a small subset of tasks). Although the need for hierarchical decomposition of matrix models to address this issue has been recently discussed by a number of authors (see, e.g., Lindemann et al., 2007), a generallyapplicable cross-domain solution has not yet been identified. One approach to addressing this problem is to view a model as an abstract data structure which is manipulated indirectly via multiple visualisations – each of which is designed to perform specific manipulation tasks and which are all used in combination to manage the model. Thus, for instance, a matrix to manipulate the strongly-connected network of communication between members of a team could be complemented by tree views to indicate which members were part of which team, which teams were responsible for which components, and which team members were expert in which design tools. Secondly, many matrix models do not enforce logical constraints upon which elements can be linked to which other elements. For instance, a process modeller might wish to constrain their model such that personnel could only collaborate on tasks if they worked on the same site, or such that a generationtype task must always be followed by an evaluationtype task. Although such constraints limit the generality of a modelling approach, when applied to specific cases they can be useful to ensure that a conceptual framework of a given domain is consistently applied across a model. A specific case where constraints are necessary to enforce the correctness of a model is discussed in Section 5.1. The linkage meta-modelling language presented in Sections 3, 4 and 5 aims to address these limitations by enabling customisation of a matrix-oriented multiple-view modelling environment for specific applications, thereby addressing the research objective stated at the beginning of this section. Discussion of the approach focuses on how the elements allowed in a model, the constraints between these elements and the multiple views are defined. Due to

David C. Wynn, P. John Clarkson

space limitations, the software which was developed to implement the approach is not discussed in detail.

3. APPROACH OVERVIEW This section discusses the basis of the linkage metamodelling approach prior to describing its components in more detail. To recap, in the context of this paper a linkage metamodel is defined as a formal, computable “model of a linkage model”. A linkage meta-model expresses a linkage modelling framework by constraining the elements and linkages which are allowed in model instances. It also forms the basis for configuring the views used by the modelling environment to represent this data. Linkage meta-models are based on the observation that all linkage modelling frameworks may be expressed as labelled digraphs, as can the data structures underlying matrix and tree views. These views may therefore be expressed as topological transformations of a model instance. The approach is thus based on the concept that each view in a modelling application is derived from perspectives of the model. Perspectives may be viewed as algorithms which transform the digraph structure of elements and linkages in a model in order to obtain another digraph, typically comprising a subset of the elements and linkages in the original. For instance, a tree perspective operates upon a model to generate a tree-structured digraph. This is then used as the basis of a view which converts the abstract data structure into an interactive user interface component. Perspectives are specified in terms of rulesets which govern the behaviour of simple recursive algorithms.

4. LINKAGE META-MODELS In overview, linkage meta-models consist of classes, properties, relations, constraints, perspectives and views. Figure 2 illustrates the relationships between these six components and illustrates the ModelView-Controller architecture of the approach. Each component is introduced below prior to an example which illustrates application of the approach.

4.1. Classes The definition of classes, properties and relations in our approach is similar to that of other languages used to describe a domain, such as the ontology specification languages reviewed in Section 2.2. In brief, classes are formal descriptions of the types of element which can be modelled in a given framework.

Figure 2 The relationships between the linkage metamodel definition, a system model, perspective definitions and views

For example, the Applied Signposting Model defines classes entitled Task, Parameter and Resource (and many more – over 26 in total). Classes may be hierarchically defined such that they inherit properties and relations from their super-classes.

4.2. Properties Properties define the data fields such as ‘Name’ and ‘Description’ whose values qualify each instance of a class (i.e., each element in a model). Each property has a specific type, e.g. single-line-string, boolean, etc., which is used by the implementing software to determine how data is collected, validated and stored.

4.3. Relations and constraints Relations define linkages in the same way that classes define elements. Taken together, relations and constraints define how instances of a class can be linked to instances of other classes and thereby constrain the network of linkages which the modeller can create between elements in a model. Each relation has the following attributes: • Source and sink classes. Each relation allows instances of one class (source) to be connected

LINKAGE META-MODELLING TO SUPPORT THE DEVELOPMENT OF DESIGN

1041

to instances of another (sink) via directional linkages. • Description. A relation may be assigned a bidirectional name and icon. For example, if the description of a parent-child relation is specified as “is child of”, then the reverse description might be specified as “is parent of”. • Symmetry. A relation which links instances A to instances B of the same class may be optionally specified as symmetric. When a symmetric linkage A♦B is added or removed by the user of the modelling software, the converse linkage B♦A is automatically updated to maintain symmetry. Symmetic relations are used to describe linkages which are non-directional, such as the physical connectivity of components in a mechanism. • Cardinality. The cardinality of a relation can be specified, i.e., the minimum and maximum numbers of sink elements allowed per source element. A relation may constrain linkages to have direct or indirect scope. Direct relations provide ‘slots’ in each instance of the source class in which new instances of the sink class may be created. Indirect relations allow the source element to refer to sink elements defined elsewhere in the model. With the exception of a single root element, every element must be a sink of exactly one direct linkage and may be a sink of any number of indirect linkages. The root element cannot be a sink of any direct linkage, and represents the model itself. In the context of this paper, a linkage model is therefore structured as a tree of elements connected to their children by direct linkages. The elements in this tree may be interconnected by a network of indirect linkages. Namespace constraints may optionally be specified for any indirect relation. A namespace constraint determines which instances of the source class may be connected to which instances of the sink class. When the modeller attempts to create a linkage between a given source and sink element, the linkage perspective is executed in the context of the source to identify the subset of parameters which satisfies the constraint and ensure the sink is a member of this set. Namespace constraints are specified using either tree perspectives or linkage perspectives, which are described in Section 4.4 below. If no namespace constraint is specified for a particular relation, any instance of the source class may be connected to any instance of the sink class that exists in the model.

1042

4.4. Perspectives The algorithms used to generate tree perspectives and linkage perspectives are the core components of the visualisations and constraints in the approach. Each of the two algorithms operates in similar fashion by recursively processing the graph structure of a model instance, according to a set of rules which are part of the linkage meta-model definition. A perspective algorithm begins by examining a specific element in the model; this is the context of the perspective. A tree perspective used to generate a view might be attached to the root element of the model; the algorithm then considers all data in the model. In contrast, a linkage perspective used to specify an indirect relation’s namespace constraint might be attached to the context of the source element; in other words, the sink elements which may be connected are contingent upon the source element’s location in the model digraph. This will be illustrated in Section 5.2. The operation of a particular perspective algorithm is governed by rules which define its configuration. In overview, each rule incorporates a pattern which is compared against the element currently being examined by the algorithm. Any rules which match the current element are then executed in turn. After execution, rules may specify that the algorithm should recurse over one or more of the current element’s relations. The algorithm thus traverses a relation which connects two adjacent nodes and then attempts to reapply each rule. The perspective for recursion may be different from the current perspective, allowing the treatment of an element to be dependent on the route by which it was reached. The operation of the tree- and linkage perspective algorithms is outlined in more detail below prior to discussing their application to generate views. Tree perspectives Rules in a tree perspective specify only that a node should, or should not, be created in the tree to represent the current element under attention. Whenever a new tree node is created, it appears as a child of the last new node. As the focus of the perspective algorithm traverses the model digraph, certain nodes are thus selected and added to the appropriate place in the tree structure. Although this appears limited, it is possible to construct a wide range of trees by carefully specifying the order in which the perspective algorithm traverses the graph. An example of the

David C. Wynn, P. John Clarkson

definition and operation of a tree perspective is given in Section 5.2. Linkage perspectives Linkage perspectives are defined in the same way as tree perspectives. However, instead of building a tree of nodes the algorithm creates a (flat) list – each time a node is created it is appended to the end of this list. As discussed above, linkage perspectives are used to specify the namespace constraints of indirect relations. They are also used by tabulation views, which apply the algorithm to every column element in the tabulation to obtain a list of all row elements which are linked in the context of that view. Configurators A configurator consists of a set of named fields which are created by perspective algorithms to qualify each node in the digraph they create. The configurator associated with a node is then processed by the code which renders each type of view. This reads the values of fields from the configurator to determine how each node is rendered. For instance, tree views allow nodes in a tree to be highlighted using a given color. When each node is rendered, the view looks for a configurator field entitled FILL COLOR of type Color. If the field exists for that node the color is set appropriately; otherwise, the node is not highlighted. The field could be created, for example, by binding a color property of the element represented by that node in the tree. Alternative views could then bind different properties and thereby highlight different aspects of the model.

4.5. Views The perspective algorithms introduced above form the basis of tree and tabulation views in the user interface: Tree views Tree views are defined by a tree perspective and a node renderer. This is a software component which uses any configurators created by the perspective definition to assign any special display properties to each node. Hierarchical tabulation views Tabulation views are constructed from five components: a source tree perspective defining the column headings; a sink tree perspective defining the row headings; a linkage perspective, which defines which

source elements are linked to each sink element in the tabulation and creates configurators to describe how each linkage should be rendered; and a linkage renderer, a software component which performs the rendering. Finally, a linkage factory determines how the model is modified when the user clicks an unpopulated cell in the tabulation. When applied to a specific source and sink element – i.e., the elements represented by the row and column headings for the tabulation cell which the user clicked – the linkage factory identifies a chain of elements and relations which could be created to link those elements. The chain of elements and relations is then created by the software, and when the view is subsequently updated the new linkage is identified by the tabulation’s linkage perspective and will become visible. Mouse-clicks on cells which are already populated by the tabulation’s linkage perspective are not handled by the linkage factory. Instead, a configurator field entitled LINKAGE ELEMENT is created by the linkage perspective at the time the tabulation is created. This is consulted by the user interface code to identify those elements which lie on the path connecting the source and sink elements in the context of the tabulation. According to the selection tool in use, the properties of these elements are then presented in a dialog for manipulation, or the elements are deleted in order to remove the linkage.

5. EXAMPLE In this section, the Contact and Channel Model (C&CM) developed by Albers, et al. (2003) is used as a case study to illustrate linkage meta-model definition. The C&CM framework was selected for discussion because its structure is relatively straightforward to explain, includes elements in multiple domains, and requires consideration of constraints on indirect relations. It therefore illustrates most features of the approach. In overview, the C&CM is a modelling framework which conceptualises products as collections of Components which have Surfaces. Each surface is linked to one or more surfaces of the same component via a Channel and Support Structure (CSS). For example, the bottom surface of a beam under vertical compression transfers force to the top surface via a CSS. The framework assumes that the function of a mechanism may be described in terms of CSSs and Working Surface Pairs (WSPs). Each WSP connects the surfaces of two adjacent components to transfer force, fluid, energy etc. An example C&CM of a

LINKAGE META-MODELLING TO SUPPORT THE DEVELOPMENT OF DESIGN

1043

hairdryer is shown in Figure 3 (Adapted from Alink, 2005).

Figure 3 Conceptualisation of a hairdryer in the Contact and Channel Model (Adapted from Alink, 2005)

The linkage meta-model developed to represent this framework is discussed in Sections 5.1 and 5.2 below, supported by a formalised description in the appendix.

type of the CSS. The WSP class is identical except that the instances of class Surface are constrained for selection from the set of all Components’ surfaces. Thus, in this linkage meta-model a WSP differs from a CSS only in that the former may link two surfaces from different components while the latter must link two surfaces common to a single component. When creating a CSS or WSP, the user is prompted to select one of the two concrete subclasses to indicate whether directionality is meaningful to that particular linkage. The class structure for the C&CM is summarised as a UML-style class diagram in Figure 4. While this diagram provides an intuitive overview, it is insufficient to fully express the linkage meta-model since it does not indicate the namespace constraints upon the CSS♦Surface and WSP♦Surface linkages. The complete definition of classes, properties and relations in the C&CM linkage meta-model is tabulated in the appendix. This allows C&CM models to be formally represented as a directed graph of instance data. A section of the digraph for the hairdryer model is shown in Figure 5.

5.1. Classes, properties & relations The C&CM linkage meta-model comprises five classes which represent each main concept in the framework: the C&CM itself; Components; Surfaces; CSSs; and WSPs. Since the Channel and Support Structures and Working Surface Pairs may be either directional (such as airflow in the hairdryer) or non-directional (such as structural support), the latter two classes are defined as abstract and each has two concrete sub-classes. Finally, a Linkage type class is included to allow qualification of the way in which CSSs and WSPs link pairs of surfaces. There are thus a total of 10 classes in the linkage meta-model. In overview, the Component class has one direct relation entitled Surfaces, which may contain 1..N instances of class Surface, and one direct relation entitled CSSs containing 0..N CSS instances. Similarly, the abstract CSS class has one indirect relation entitled Surface (source) and one entitled Surface (sink), each containing exactly one instance of class Surface. This relation is constrained such that the surfaces must be selected from the linkage perspective entitled T 2– which identifies those surfaces which are defined by the CSS’s parent component’s Surfaces relation. The CSS class also includes an indirect relation entitled Linkage type which indicates the

1044

Figure 4 Representation of the C&CM class structure as a UML-style class diagram

5.2. Perspectives and views The digraph depicted in Figure 5 reflects the data structure used to represent the hairdryer. Concrete views of this data are required to manipulate and interpret the model. Four such views were developed for the C&CM modelling application: three tree views indicating the component breakdown of the product, the working surface pairs, and the linkage

David C. Wynn, P. John Clarkson

Figure 5 Section of the hairdryer dataset as stored within the software

types respectively; and a tabulation view to provide the main input screen of the modelling tool. The tree views are defined by the three tree perspectives T 5, T 7 and T 8 respectively. The tabulation view is based on the T 1 tree perspective for both row and column headers, the L1linkage perspective and the SurfaceSurface linkage factory. The definitions of these five perspectives and of the linkage factory are tabulated in the appendix. Figure 6 (top) illustrates the definition of the tree perspective T 2 using the same notation as the appendix. This example comprises two perspective definitions entitled T 2 and T 4. It is used in the example to specify the constraint “Channel and Support Structures must comprise Surfaces within the same Component”. Consider executing this algorithm in the context of the element CSS – Transform 240v-12v shown in Figure 5. The algorithm begins by attempting to match the context element to the MATCH ELEMENT column for each of the two rules of T 2 (Step 1 of Figure 6, bottom). Since the context element is of class CSS, the first rule is matched and executed. This specifies that a node should not be created in the tree to represent the element. It then instructs the algorithm to apply the T 2 perspective to all elements which include the context element as a sink of the relation CSSs (the italicised text indicates this is a “recurse over sources” operation, rather than a “recurse over sinks” operation). Since the CSSs relation links

Figure 6 The definition (top) and operation (bottom) of a tree perspective. In the bottom diagram, the grey fill indicates the change in context at each step of the algorithm (see notation key in Figure 5)

a Component to a CSS, when recursion occurs the context element will be re-focused on a Component and the second rule will be matched and executed (Step 2). This specifies that a node should be added to the tree to represent that Component, then will recurse over each of the component’s Surfaces using the perspective T 4 (Steps 3a and 3b). This will then add a node to the tree as a child of the previous node to be added – in this case as a child of the Surface’s parent Component.

6. SOFTWARE IMPLEMENTATION The linkage meta-modelling approach was implemented in the P3 Signposting software platform (Wynn, 2007). Due to space constraints a full description of the implementation is not possible in this paper. In overview, the software provides a graphical configurator allowing development of meta-model definitions. These may then be saved as template files. When the end-user (i.e., domain modeller) wishes to create a model, they are prompted to select one of the templates which then determines the modelling framework and thus the user interface of the tool. A template was created for the C&CM meta-model discussed above. A screenshot from the resulting modelling tool is shown in Figure 7, illustrating the components tree and matrix visualisations of the hairdryer model.

LINKAGE META-MODELLING TO SUPPORT THE DEVELOPMENT OF DESIGN

1045

Figure 7 P3 Signposting configured for Contact and Channel modelling, illustrating the hairdryer dataset. Red marks within the clear boxes along the leading diagonal of the matrix indicate Channel and Support Structures (within components); yellow marks within the dark background indicate Working Surface Pairs (between components)

7. DISCUSSION To recap, the research reported in this paper was motivated by the need to reduce the effort required to implement linkage-based modelling tools, and thereby to support the development of design process improvement methods. The paper was particularly concerned with matrix-based modelling tools, since these are well-suited to visualise the stronglyconnected dependency networks required to model complex design systems such as products and processes. Two requirements were identified for a configurable matrix-based modelling tool: the need for multiple views of a model in order to allow large data sets to be developed; and the need to enforce constraints upon the network of relations allowed in a model. This paper has shown how these requirements can be

1046

addressed by defining matrix views as perspectives of a more general digraph data structure or linkage model which is constrained in terms of which elements can be linked to which other elements. Sections 4 and 5 showed how both perspectives and constraints can be specified in terms of rules which determine how recursive algorithms operate upon the linkage model. The combination of element class definitions, constraints and view definitions was termed a linkage meta-model. To illustrate the effort required to construct a linkage meta-model, the example discussed in Section 5 was developed by the author in around 2 hours – significantly less than the time which would be required to develop an equivalent tool using a conventional programming language. This configuration was subsequently used by Keller,

David C. Wynn, P. John Clarkson

et al. (2007) to model a robot arm mechanism and thereby explore the utility of the C&CM approach to support the prediction of engineering change propagation. The example thus provides a preliminary indication that the linkage meta-modelling approach can be used to quickly develop tools which are reliable and user-friendly enough for application. However, additional applications in which the author was less directly involved would be required to evaluate the approach. We are currently refining and debugging the software with the aim to conduct such an evaluation. The example modelling application is relatively simple with only one matrix view – and thus could easily be constructed in a spreadsheet application. However, even in this simple case constructing a linkage meta-model provides significant benefit over using a general-purpose modelling tool. By enforcing the logical constraints of the modelling framework, the C&CM implementation allows models to be developed by individuals who are unfamiliar with the nuances of the framework. It also provides an interface which is robust enough for potential application by industry users. Additionally, if the meta-model were extended to encompass hierarchical component structures – which would support the modelling of more complex products – the resulting models would be far more difficult to represent using a conventional matrix-based tool. This example illustrates that the potential value of the meta-modelling approach increases with the complexity of the framework it is used to implement.

7.1. Limitations The perspective algorithms incorporated in the approach are well-suited to developing modelling tools with relatively simple views and constraints. However, these algorithms are not sufficient to generate all perspectives which could be envisaged. For instance, they do not allow conditional processing of the model to develop views which consider the values of element properties. Another issue is that perspective definitions are extremely sensitive to the classes and relations defined in the meta-model. Initial experience with the system has shown that several configurations of classes and relations can often appear feasible to implement a modelling framework, and that problems in the selected configuration typically become evident through the expenditure of significant effort in developing perspectives. Resolving such issues requires the class and relation definitions to be

updated and consequently the perspectives to be redefined again. While this iterative process is manageable with relatively simple frameworks, designing the implementation of more complex modelling approaches with many classes, relations and views is likely to be extremely challenging. In practice, it is often necessary to update the metamodel definition when model data has already been entered into the system – for instance, when new requirements for a modelling framework are identified through the elicitation of specific domain knowledge. Although it is currently possible to add new properties, classes and relations to a meta-model without disturbing existing data, more complex modifications (such as the introduction of hierarchical structures to a previously flat domain) result in loss of data. More sophisticated approaches to refactor existing modelling frameworks are needed to resolve this issue. Modelling is often conducted in a distributed environment by a number of domain experts who are each familiar with a subset of the product, process or organisation being modelled. It would thus be useful to extend the software tool to provide a distributed application based on a shared database. The current implementation of P3 Signposting does support storage of a SQL relational database. However, since this creates the database schema dynamically and updates it following changes to the meta-model definition, it is not clear how to implement the synchronisation which would be required for distributed development of models and meta-models. Finally, the approach has been developed in the context of complex adaptive design, where the network of relationships between elements can usually be considered relatively static since the product, process and organisational architectures remain similar across projects. However, design systems which incorporate significant innovation would be difficult to model in this way, since the structure of elements and relationships is more dynamic. An open research issue is thus to investigate how the linkage modelling considered in this paper can be applied to dynamic networks.

7.2. Future work We plan to extend this research in three directions. Firstly, the approach will be extended to incorporate hierarchical network views of model data. The data structures underlying hierarchical network views may be defined using the components of the approach discussed in this paper – in particular, a hi-

LINKAGE META-MODELLING TO SUPPORT THE DEVELOPMENT OF DESIGN

1047

erarchical network may be viewed as the combination of a tree perspective responsible for generating the hierarchy of nodes in the network and a linkage perspective for generating the edges which fan out of each node. However, at the time of writing this still requires implementation in software. Secondly, we plan to define linkage meta-models to implement a range of modelling frameworks suitable for modelling the product and process domains of engineering design processes – such as IDEF models and DSM models. This will provide a ‘framework library’ which will allow modellers to select the most appropriate approach to address their specific requirements and provide a means to extend these common approaches by modifying their templates. Thirdly, we will implement a range of linkage analysis algorithms – such as partitioning and clustering of elements, and discrete-event and time-stepping process simulations – for application to digraphs generated through meta-model transformations. This will allow these generic algorithms to be applied to models which are customised to better support specific applications. For instance, this would allow process modellers who wished to apply a particular simulation approach to base their analyses on the modelling language they considered most appropriate to their domain.

8. CONCLUSIONS This paper has discussed an approach to configure a general-purpose software platform to implement a range of linkage-based modelling frameworks. It was proposed that this linkage meta-modelling approach can support the development of model-based process improvement tools by reducing the effort expended in software development. The approach is based on viewing linkage models as labelled digraphs, and linkage modelling frameworks as the constraints upon classes of element allowed in a model together with the relationships which are allowed between elements. Recursive algorithms can be defined to identify subsets of this information, and these can form the basis of multiple views which are presented to the user. These views allow a complex network of relations to be presented in a simplified form suitable for visualisation and manipulation. The approach was implemented in the P3 Signposting software. Configuration of this software to develop a product modelling tool illustrated the application of the linkage meta-modelling approach. Although the approach currently supports matrix-

1048

oriented modelling methods only, we aim to extend it to incorporate the network visualisations used by many popular modelling approaches.

ACKNOWLEDGEMENTS The authors wish to acknowledge Seena Nair’s contribution to the P3 Signposting software.

REFERENCES Albers, A., Matthiesen, S., Ohmer, M., 2003, “An Innovative New Basic Model in Design Methodology for Analysis and Synthesis of Technical Systems”, ICED’03, Stockholm. Alink, T., 2005, “The contact and channel model in the change prediction method”, Diploma thesis, Universit¨at Karlsruhe. Bechhofer, S., van Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D. L., Patel-Schneider, P. F., Stein, L. A., 2004, “OWL web ontology language reference”, World Wide Web Consortium (W3C). Blessing, L. T. M., Chakrabarti, A., Wallace, K. M., 1995, “A design research methodology”, ICED’95, Prague, Czech Republic, pp 50-55. Browning, T. R., Ramasesh, R. V., 2007, “A survey of activity network-based process models for managing product development projects”. Production and Operations Management, 16(2), pp 217-240. Corcho, O., G´omez-P´erez, A., 2000, “A Roadmap to Ontology Specification Languages”, in Dieng, R. and Corby, O. (Eds.), Knowledge Engineering and Knowledge Management: Methods, Models and Tools, Springer, pp. 80-96. Danilovic, M., Browning, T. R., 2007, “Managing Complex Product Development Projects with Design Structure Matrices and Domain Mapping Matrices”, International Journal of Project Management. Eichinger, M., Maurer, M., Pulm, U., Lindemann, U., 2006, “Extending Design Structure Matrices and Domain Mapping Matrices by Multiple Design Structure Matrices”, Proceedings of ESDA 2006. Gruber, T. R., 1993, “A Translation Approach to Portable Ontology Specifications”, Knowledge Acquisition, 5(2), pp. 199-220. Keller, R., Alink, T., Pfeifer, C., Eckert, C. M., Clarkson, P. J., Albers, A., 2007, “Product models in

David C. Wynn, P. John Clarkson

design: a combined use of two models to assess change risks”, ICED’07, Paris, France, pp. 673674. Kremer, R., 1997, “Constraint graphs: A concept map meta-language”, Ph.D. thesis, University of Calgary. Lindemann, U., Danilovic, M., Deubzer, F., Maurer, M., Kreimeyer, M., eds., 2007, “Proceedings of the 9th International DSM Conference”, Munich, 16-18 October 2007. Maurer, M., Boesch, N.-O., Sheng, G., Tzonev, B., 2005, “A tool for modeling flexible product structures: MOFLEPS”, in Proceedings of ICED’05, Paris. Noy, N. F., Fergerson, R. W., Musen, M. A., 2000, “The knowledge model of Prot´eg´e-2000: Combining interoperability and flexibility”, in Dieng, R. and Corby, O. (Eds.), Knowledge Engineering and Knowledge Management: Methods, Models and Tools, Springer, pp. 17-32.

Pavkovic N., Bojcetic N., Marjanovic D., 2002, “Modelling the Relation Network in the Integrated Product and Design Process Model”, Design 2002, Dubrovnik, May 14 – 17. Steward, D. V., 1981, “The design structure system: a method for managing the design of complex systems”, IEEE Transactions on Engineering Management, 28(3), pp. 71-74. Subrahmanian, E., Reich, Y., Konda, S.L., Dutoit, A, Cunningham, D., Patrick, R., Thomas, M., Westerberg, A. W., 1997, “The n-dim Approach to Creating Design Support Systems”, Proceedings of ASME DETC 1997, Sacramento, California. Wynn, D. C., Clarkson, P. J., Eckert, C. M., 2005, “A model-based approach to improve planning practice in collaborative aerospace design”, Proceedings of IDETC/CIE 2005 ASME 2005, Long Beach, California, USA. DETC2005-85297. Wynn, D. C., 2007, “Model-Based Approaches to Support Process Improvement in Complex Product Development”, Ph.D. thesis, University of Cambridge.

APPENDIX: DEFINITION OF THE C&CM LINKAGE META-MODEL

LINKAGE META-MODELLING TO SUPPORT THE DEVELOPMENT OF DESIGN

1049

1050

David C. Wynn, P. John Clarkson

Suggest Documents