CRC cards to support the development and maintenance of product configuration systems

Transcription

1 Int. J. Mass Customisation, Vol. X, No. Y, xxxx 1 CRC cards to support the development and maintenance of product configuration systems Anders Haug* Department of Entrepreneurship and Relationship Management University of Southern Denmark Engstien 1, 6000 Kolding, Denmark adg@sam.sdu.dk *Corresponding author Lars Hvam Department of Management Engineering Technical University of Denmark Produktionstorvet, Building Kgs. Lyngby, Denmark lhv@ipl.dtu.dk Abstract: This article presents a new definition of special Class, Responsibility and Collaboration (CRC) cards to be used for the development and maintenance of Product Configuration Systems (PCSs). CRC cards were introduced as an informal and user-friendly technique for teaching object-oriented modelling. These CRC cards are often applied in the early phases of a software development project to come up with design alternatives. In 1994, extended CRC cards, with the purpose of holding detailed descriptions of classes in structural diagrams, were incorporated into a procedure for the development and maintenance of PCSs. This procedure has since been applied in several configuration projects and further developed at the Centre for Product Modelling (CPM) at the Technical University of Denmark. However, the investigations of two companies that applies CRC cards to document the knowledge base of their PCSs showed that their CRC card layouts differ from the definitions by CPM in many respects. Therefore, this article proposes a new CRC card definition that incorporates the experiences from the studied cases together with other kinds of extensions. The proposed CRC-card definition improves the basis for the companies that take up the technique. Keywords: product configuration; CRC cards; object-oriented modelling; documentation of product configuration systems; mass customisation. Reference to this paper should be made as follows: Haug, A. and Hvam, L. (xxxx) CRC cards to support the development and maintenance of product configuration systems, Int. J. Mass Customisation, Vol. X, No. Y, pp Biographical notes: Anders Haug is an Assistant Professor at the Department of Entrepreneurship and Relationship Management at the University of Southern Denmark. His main research areas are information systems, knowledge management, knowledge representation and knowledge engineering. Haug has a PhD in Knowledge Representation and Management in the context of creating product configurators. He has produced a number of international publications that deal with the development of product Copyright 200x Inderscience Enterprises Ltd.

2 2 A. Haug and L. Hvam configurators, representation of complex industrial knowledge and sharing of product information. Additionally, he has worked as a consultant on a number of configuration projects. He teaches information systems, product configuration and product information management. Lars Hvam is a Professor at the Technical University of Denmark and Head of the Centre for Product Modelling ( He has worked as a consultant in the area of manufacturing management and has a PhD in engineering on the application of product modelling. Over the last 14 years, Hvam has conducted research within the area of product configuration system design. In addition, he worked for six months at the Agility Forum in the USA. Hvam teaches the courses Product Configuration and Manufacturing and Material Management at the Technical University of Denmark. At the Centre for Product Modelling, his main research area is mass customisation with a focus on the development and implementation of product configuration systems. 1 Introduction This article presents a new definition of special Class, Responsibility and Collaboration (CRC) cards to be used in the development and maintenance of Product Configuration Systems (PCSs). PCSs support the manufacturing paradigm of mass customisation (Pine et al., 1993). A PCS can be defined as a product-oriented expert system that allows users to specify products by selecting components and properties under the restriction of valid combinations. The use of PCSs can produce benefits such as shorter lead times, the reduction of resources that are needed to produce specifications and fewer errors in specifications (Forza and Salvador, 2002; Forza et al., 2005; Riis, 2003; Hvam, 2004; Hvam et al., 2008). The development of a PCS entails a relocation of knowledge from domain experts to a software system. One of the greatest challenges in a configuration project concerns the representation of domain knowledge (Sabin and Weigel, 1998; Hansen et al., 2003; Edwards and Ladeby, 2005). To visualise and capture domain knowledge, various diagrams can be used to create graphical models. A structural diagram (such as a class diagram) can provide a good overview of a model, but can easily become confusing if too much information is included. To avoid this information overflow, structural models can be extended by special CRC cards, on which more detailed information can be placed. Experience shows that if a PCS of a certain size is undocumented, it can be extremely difficult to maintain (Edwards et al., 2005). CRC cards can be useful for documenting the knowledge in a PCS, as CRC cards can easily hold comprehensible descriptions of what is in a PCS compared to the modelling environment of many PCSs. Having such external descriptions of the implemented knowledge can ease the tasks of updating knowledge bases and tracking errors. Based on the CRC card definitions of a procedure for the development and maintenance of PCSs from the Centre for Product Modelling (CPM) at the Technical University of Denmark, several companies have applied CRC cards for documenting their PCSs (Hvam, 2004; Hvam et al., 2008). The CRC card definition of CPM provides a general layout that can be adapted by individual companies according to their

3 CRC cards to support the development and maintenance of product configuration 3 specific needs. However, the fact of having only a general definition of CRC cards can represent a problem if this standard layout is applied uncritically, as this holds the risks of having redundant information in the documentation and neglecting to document important aspects. At CPM, it has been an ambition for some years to create a software-based documentation system to support the development and maintenance of PCSs. Documentation systems that support only parts of the CPM procedure have been created (Hvam and Malis, 2001), but the ambition is to create a system that offers much more complete support. Therefore, CPM is currently involved in a project that concerns the creation of such a system. For a documentation system to fulfil the needs of different companies, the existing CRC card definitions have to be extended, e.g., by the fields for management of changes. The new CRC card definition that is presented in this article aims to provide an improved basis for the companies that apply CRC cards in their PCS projects and is, furthermore, an important input to the project at CPM that concerns the creation of a software system to support the development and maintenance of PCSs. This article is an extended version of Haug and Hvam (2006a). The article is organised as follows. In Section 2, the original CRC cards are briefly described. Next, Section 3 describes a frequently applied procedure for the development of PCSs, where the use of special CRC cards together with two types of structural diagrams is prescribed. In Section 4, studies of two companies who applied CRC cards to document the knowledge base of their PCSs are presented. Next, in Section 5, a new definition of CRC cards to support the development and maintenance of PCSs is proposed. Section 6 describes the experience from the creation of a prototype that includes parts of the new CRC card definition. The article ends with a conclusion in Section 7. 2 The original CRC cards The CRC card technique was invented by Cunningham in the late 1980s (Fowler, 2005) and originally presented in Beck and Cunningham (1989), where it was described as a way of teaching the object-oriented way of thought. A CRC card consists of the Class name with two columns for Responsibilities and Collaborators, as seen in Figure 1. In brief, responsibilities are short sentences that summarise the things that an object from a class should do, while collaborators are the other classes with which the class should work (Fowler, 2005). Figure 1 The original CRC cards ClassName Responsibilities... Collaborators... Source: Redrawn from Beck and Cunningham (1989)

4 4 A. Haug and L. Hvam CRC cards can be a valuable technology for coming up with object-oriented designs, as moving the class cards around allows the exploration of interactions between classes. Although CRC cards are not part of the Unified Modelling Language (UML), they are a popular technique among skilled object designers (Fowler, 2005). CRC cards are often used in role playing sessions, which can be organised according to different principles (Fowler, 2005; Bellin and Simone, 1997; Bennet et al., 2002). 3 The CPM procedure Hvam (1994) presented a procedure for building PCSs, which has since been applied in several projects and further developed at CPM. The CPM procedure consists of seven phases: 1 process analysis 2 product analysis 3 object-oriented analysis 4 object-oriented design 5 programming 6 implementation 7 maintenance. The CPM procedure proposes the use of three main techniques for modelling the knowledge to be included in a PCS: 1 Product Variant Masters (PVMs) 2 class diagrams 3 extended CRC cards. In the product analysis phase, PVMs are prescribed for describing the product assortment, while in the object-oriented phases, the contents of the PVM models can be further formalised and specified by using class diagrams. As opposed to the normal use of CRC cards, namely, its application in the early phases of a software project to learn or explore interactions between classes, the CPM procedure proposes the use of special CRC cards to hold detailed descriptions of classes in the structural diagrams, i.e., PVMs and class diagrams. In the following sections, PVMs and class diagrams are briefly described, after which the CRC cards in the CPM procedure are presented. 3.1 Product variant masters In Figure 2, an example of a PVM model that is based on the notation formalism defined in Haug and Hvam (2006b) is shown. The left side of the model describes the part-of structure (corresponding to aggregation), while the right side of the model displays the kind-of structure (corresponding to generalisation). Beneath the classes, their attributes and constraints are displayed. The dotted arrow indicates that the Width of the SideSticker class is dependent on constraint 5 of the class Body.

5 CRC cards to support the development and maintenance of product configuration 5 PVMs are normally drawn by using software such as Microsoft Visio and Excel and elaborated in the modelling sessions of domain experts and knowledge engineers (Hvam et al., 2008). Figure 2 An example of a PVM model (see online version for colours) Toy car 1 1 Chassis Length {210, 220 mm} Width {88 mm} Colour {Black, Grey} Weight {g} 1: Weight = * (Length 190) BodyAssembly Sport 1 8 0,2 Body Colour {Red, White, Black} Material {Plast1, Plast2} Length {212, 222 mm} Width {90 mm} Weight {g} 2: Length = Chassis.Length -2 3: IF Colour = White THEN Material = Plast2 4: Weight = * (Length 194) 5: IF Length = 212 THEN SideSticker.Width 45 Screw SideSticker Picture {Fire, Wave} Height { mm} Width { mm} Station Golf 3.2 Class diagrams The class diagram is one of the 13 diagrams of UML 2.0. UML is a modelling language with a formal syntax that was defined by the Object Management Group (OMG) (OMG, 2005). The class diagram is the most widely applied UML diagram and describes the objects in a system together with the various kinds of static relationships among them (Fowler, 2005). In Figure 3, the class diagram notation and the most commonly used relationship types are displayed. Figure 3 The class diagram notation

6 6 A. Haug and L. Hvam The CPM procedure prescribes the use of a subselection of class diagram relationships, including association, aggregation and generalisation (Hvam et al., 2008). The basic argument for the inclusion of both PVMs and class diagrams in the CPM procedure is that PVMs seem to be more user-friendly, which may be beneficial in the modelling tasks that involve domain experts with limited modelling skills. On the other hand, class diagrams are richer and more formalised, which makes these better suited for describing what should be implemented in a PCS (Hvam et al., 2008). 3.3 CRC cards for the development of PCSs As mentioned, the CPM procedure proposes the use of extended CRC cards to hold detailed information about classes in order to enhance the clarity of the PVM and class diagram models. Hvam (1994) extends the original CRC cards (as defined by Beck and Cunningham (1989)) with fields to describe superclasses/ subclasses (generalisation-specialisation relationships) and superparts/subparts (wholepart relationships). Furthermore, Responsibilities and Collaborations were subdivided into two sections called Knows and Does, which are basically other names for attributes and methods. Later, Hvam and Riis (1999) presented a revised definition of the CRC cards to be used in PCS projects. Compared to Hvam (1994), the proposed definition included the addition of these fields: Author, Date, Sketch and Object mission. This CRC card definition is seen in Figure 4. Figure 4 The CPM CRC cards Source: Redrawn from Hvam and Riis (1999)

7 CRC cards to support the development and maintenance of product configuration 7 The CRC cards were further evolved by Hvam et al. (2003), where the field Object mission was renamed Responsibilities and the caption Responsibilities, renamed to Know/Does. In the latest CRC card definition from CPM (Hvam et al., 2008), the field Version is included and the fields Knows and Does are replaced by Attributes, System methods and Product methods, where the latter is divided into Internal methods and External methods. This CRC card definition is seen in Figure 5. Figure 5 The latest CRC card definition by CPM Source: Hvam et al. (2008) On the CRC card in Figure 5, the methods fields are intended to hold information about both the methods and what in other contexts is referred to as constraints (Fowler, 2005; OMG, 2005) or ( production) rules (Stumptner, 1997; Sabin and Weigel, 1998). Product methods concern the knowledge about products and their life phase properties, while System methods concern the software aspects of a PCS. Internal methods concern the internal structure, functions and properties of a class, while External methods concern relationships with others classes, e.g., a rule that affects some attribute in another class (Hvam et al., 2008).

8 8 A. Haug and L. Hvam 3.4 The application of CRC cards according to the CPM procedure To illustrate how CRC cards can be used to hold information about classes and hereby enhance the clarity of structural diagrams, in Figure 6, the PVM model from Figure 2 has been extended by CRC cards (only the most relevant CRC card fields are shown). In the current example, moving information from a PVM to CRC cards may be a superfluous action because the model is not very extensive. However, in cases where PVMs or class diagrams consist of hundreds of classes, this kind of action can significantly improve the clarity of the models that are represented in PVMs and class diagrams. Also, the maintenance of the models can be eased by moving class information to CRC cards, since this allows changes to be done within individual CRC cards, as opposed to having to change a big structural representation. The downside is, obviously, that the model representation is spread across several documents. Figure 6 The PVM and matching CRC cards (see online version for colours) Toy car 1 1 Subparts: Chassis BodyAssembly Superparts: Toy car Chassis BodyAssembly 1 8 0,2 Class: Toy car Class: Chassis Attributes Length {210, 220 mm} Width {88 mm} Colour {Black, Grey} Weight {g} Body Screw SideSticker Constraints 1: Weight = * (Length 190) Class: BodyAssembly Superparts: Toy car Subparts: Body Screw SideSticker Sport Station Golf Superparts: BodyAssembly Class: Body Subclasses: Sport Station Golf Attributes Colour {Red, White, Black} Material {Plast1, Plast2} Length {212, 222 mm} Width {90 mm} Weight {g} Constraints 2: Length = Chassis.Length -2 3: IF Colour = White THEN Material = Plast2 4: Weight = * (Length 194) 5: IF Length = 212 THEN SideSticker.Width 45 Superparts BodyAssembly Class: Screw Class: SideSticker Superparts BodyAssembly Attributes Picture {Fire, Wave} Height { mm} Width { mm} Superclasses: Body Sketch/Picture Superclasses: Body Sketch/Picture Superclasses: Body Sketch/Picture Class: Sport Class: Station Class: Golf

9 CRC cards to support the development and maintenance of product configuration 9 4 Case studies The ways in which the companies GEA Niro A/S (Niro) and American Power Conversion A/S (APC) applied CRC cards have been investigated by the authors. The two companies were chosen because of their relatively structured procedures for using CRC cards as documentation of the knowledge in their PCSs. The investigations were carried out during 2005 and 2006 through several interviews and by analysing the documentation that was produced by the companies. 4.1 The approach of Niro Niro is a company with a leading market position within the area of industrial drying technology. Niro is a part of the GEA Process Engineering Division, which is represented in more than 50 countries and retains a total of about 3200 employees. In Denmark, Niro employs more than 400 people. Niro s products can be characterised as highly individualised, meaning that much time was spent on the creation of product specifications. Niro s PCS project focuses on the quotation process and aims to: reduce lead times reduce the resources that are spent on making quotations optimise product design formalise product knowledge to keep this in the organisation. At the moment, the PCS only supports some products, but more are to be included. Niro applies CRC cards to document the knowledge base of its PCS, which includes thousands of attributes and rules that are spread across several product families. The CPM procedure formed the basis for the development of its PCS, but compared to the definitions by CPM, its CRC cards have been modified to reflect the modelling environment of its standard configuration software (Oracle Configurator), include fields for the management of changes and allow a division of domain knowledge. Niro had implemented Lotus Notes Release 5 throughout the company as a standard application, where it was chosen to base their documentation on this application, using Notes templates as CRC cards. Besides CRC card templates, the Lotus Notes application provides a hierarchical list of the classes, which can be used to navigate between cards. The CRC card layout with five collapsed folders is seen in Figure 7 (a dummy class). On Niro s CRC cards their knowledge is divided into the categories of product, price and text knowledge. This division means that different kinds of domain experts can access the cards from different places and hereby avoid mixing their information. The three kinds of knowledge are all subdivided into attributes and rules. The CRC cards in the documentation system are connected by hyperlinks. For instance, if an attribute from an external class is part of a rule in a CRC card, the CRC card of the external class can be reached by clicking on the specific attribute. The rules of the PCS are formulated on a higher level of abstraction in the CRC cards, as these are aimed at domain experts.

10 10 A. Haug and L. Hvam Figure 7 The CRC card layout of Niro (see online version for colours) The implemented cards can be modified later, which means that some of the elements of a CRC card might be implemented, while others are waiting to be implemented. To differentiate between the elements of different states in the CRC cards, different colours are applied. 4.2 The approach of APC APC produces data centre infrastructure, such as uninterruptible power supplies, battery racks, power distribution units, cooling equipment, etc. APC has sales offices throughout the world and manufacturing facilities in several countries, including one in Denmark, where a configuration team of around 30 persons is placed. This team is responsible for the development and maintenance of APC s PCSs. These PCSs are used worldwide and support the elaboration of quotations and manufacturing specifications. APC s use of configuration technology has led to significant benefits, e.g., the reductions of lead times from weeks to hours. APC s PCSs include thousands of attributes and rules, which are documented in CRC cards. Like Niro, APC uses Lotus Notes to administer their CRC cards. Although the CPM procedure formed the basis for the development of their PCSs, the CRC card layout of APC differs much from the CPM definitions. The modifications of APC reflect their products and the modelling environment of the standard configuration software (CinCom Knowledge Builder). Furthermore, the fields and functionality for the management of changes are included in the CRC cards of APC. APC s CRC cards fall into three categories: 1 product (product descriptions) 2 life cycle (descriptions of the life cycle of the product) 3 specification (descriptions of the documents throughout the life phases of the products). Besides using CRC cards to describe product-related knowledge, APC also applies CRC cards to describe change requests. The state of a CRC card and the rights of the users determine who can make changes to the card. APC s CRC cards are primarily used by domain experts, for which reason the rules from the PCSs are formulated on a higher level of abstraction in the CRC cards.

11 CRC cards to support the development and maintenance of product configuration 11 The CRC cards contain the following top-level information: Title, Version, Category, Sub-Category, Requested Go Live Date and Phase. The CRC cards further contain the fields: Class Description Domain Expert (product responsible) Link to other CRC cards Sketch/Picture Knows (i.e., attributes) and Collaborations Rules and Collaborations (rules are divided into configuration and selection rules) SKUs (stock keeping units)/parts (variants and subparts with and without product codes) Edit History (who created different versions of the card). From the CRC cards, it is possible to request acknowledgement from a domain expert, search for CRC cards that are linked to the current solution and get help to fill out the CRC card. 5 Definition of a new CRC card layout In spite of the fact that the CPM procedure formed the basis of the PCS projects at both Niro and APC, their CRC card layouts differ much from the CPM definitions. One of the main differences is the way they organise their rules/constraints, methods and attributes (in this article, this is referred to henceforth as class knowledge). Another main difference is that the CRC cards of Niro and APC, as opposed to the layout of CPM, include fields for change management. For a new CRC card definition, an important requirement is that this definition is applicable in as many cases as possible. However, based on the investigations of only two companies, it does not seem possible to define a standard CRC card layout that will support the needs of all companies without including fields that would only be used in some cases. As CRC cards with many unused fields tend to be confusing, the idea of the CRC card definition that is proposed in this article starts with a large selection of fields, where only the relevant ones are included in the CRC card layout that is applied in a particular case. The primary purpose of the CRC cards that are proposed in this article is that these are used to describe the knowledge base of a PCS in a manner which is comprehensible to relevant domain experts. This kind of use corresponds to CPM definitions and the way in which the two investigated companies applied CRC cards. 5.1 The basic layout of the new CRC cards The proposed CRC card layout consists of some top-level information together with six types of folders, as shown in Figure 8. A one-page layout with expandable/collapsible folders is chosen, as this, contrary to a multipage layout, allows information from any two folders to be shown on the screen simultaneously.

12 12 A. Haug and L. Hvam In the top-level section, the Status field tells whether the class that is represented by a CRC card has been implemented in the knowledge base of the PCS or not. The Change requests field is intended as a field which tells whether there are changes to be implemented in the current card, i.e., yes or no. A card, therefore, can have the status implemented, although unhandled change requests have emerged since the implementation of the class. Figure 8 The basic layout Class: Status: Change requests: Version: Basic information Relationships Sketch/Picture Knowledge group Knowledge group N Change requests Change history As mentioned, Niro groups its knowledge into product, price and text knowledge, while APC divides their rules into configuration rules and selection rules and their parts, into parts with and without an SKU number. To support these and other possible groupings, it has been chosen not to pregroup this kind of information in the proposed layout, but to indicate that this is to be defined in the specific project. This is illustrated by naming the folders Knowledge group 1-N, where these should be renamed according to the preferences in specific projects. 5.2 Basic information The Basic information folder holds information about the creator of a CRC card, who is responsible for the card and who is responsible for the product or component that is represented by the class. In this folder, the main responsibilities of the current class can also be described. In Figure 9, the fields within the Basic information folder are shown. Figure 9 The Basic information folder Class: Status: Change requests: Version: Basic information Created by: Date: Card responsible: Product responsible: Responsibilities: Relationships Sketch/Picture Knowledge group Knowledge group N Change requests Change history

13 CRC cards to support the development and maintenance of product configuration 13 Besides the fields that are shown in Figure 9, it would in some cases be relevant to include fields that describe the external systems that a class uses/provides information from/to. 5.3 Relationship types The CPM-defined CRC cards only include information about two relationship types, namely, generalisation and aggregation, where, in this context, the latter is used without differentiation between the two types of aggregation, aggregation and composition. The difference between the two types of aggregation is that in a composition relationship, a part instance is included in, at most, one composite at a time, where the composite object is responsible for the creation and destruction of its parts, while a part instance of an aggregation relationship can be included in more composites and continues to exist if its composite class is destroyed (OMG, 2005; Fowler, 2005). Since the definition of a composition relationship corresponds to the perception of a product that is composed of parts, this type of aggregation is applied in the current CRC card definition. A class diagram can also include other relationship types. In the CPM procedure (Hvam et al., 2008), a third kind of relationship is applied, namely, association. Consequently, this relationship type is included in the new CRC card layout. Also, the dependency relationship is included in the new definition as this can be useful for displaying that a constraint in one class affects another class. Based on these observations, a basic layout for the Relationships folder is defined, as shown in Figure 10. Here, multiplicities can be stated in brackets following the relationship classes. If any of the included relationship types are not included in the models of a specific case, these should obviously be left out. Figure 10 The Relationships folder Relationships Composition Generalisation Association Superparts: Superclasses: Classes: Subparts: Subclasses: Dependency Sources: Clients: The CPM procedure is not the only approach towards the development of PCSs. Another approach is provided by Felfernig et al. (2000; 2001). This approach prescribes the use of class diagrams, while it does not include CRC cards. The included class diagram relationships of this approach are generalisation, aggregation, association and dependency. Furthermore, these relationships are extended by the use of stereotypes, which is a UML concept that allows an introduction of new model elements based on existing elements (OMG, 2005). Felfernig et al. (2001) defined the stereotyped associations (incompatible and is_connected) and the stereotyped dependencies (requires, produces and consumes). When CRC cards are applied together with class diagrams that include stereotyped relationships, then either the stereotype should be stated behind the class names in the relationship fields or the CRC card layout should be extended by additional relationship fields for different types of stereotyped relationships.

14 14 A. Haug and L. Hvam If PVMs or class diagrams are applied together with the CRC cards, it is, in principle, not necessary to describe these relationships in the CRC cards as well. However, stating relationships in the CRC cards opens the possibility of navigating between CRC cards without using structural representations. 5.4 Sketch/Picture An example of the use of the Sketch/Picture field is shown in Figure 11. In the example, the Sketch/Picture field is used to describe the topological variance of subclasses (shown on the left) and the placement of different measure attributes (on the right). Figure 11 The Sketch/Picture folder Sketch/Picture Width Height Type 1 Type 2 Type 3 Depth 5.5 Knowledge groups Having defined that class knowledge should be grouped according to the requirements of a specific situation, the next task is to decide how class knowledge should be subdivided. The CRC cards of Niro and APC include a division of class knowledge into attributes and rules, while the CPM definition divides class knowledge into attributes and methods. In the definitions that are provided by this article, the concepts from UML are applied in order to conform to a widespread standard. UML defines methods and constraints as two very different concepts. UML defines constraint as an assertion that indicates that a condition or restriction must be satisfied by a correct design, which can be expressed by using any formalism as long as it is placed within braces ({}). A method is defined as the implementation of an operation, which is a behavioural feature that specifies the name, type, parameters and constraints for invoking an associated behaviour (OMG, 2005). For instance, a piece of code that retrieves data from another system is a method, while an expression that restricts a combination of two specific components is a constraint. The class diagram models and PVM models often also include notes which, in a product configuration context, consist of information that should not necessarily be implemented in the PCS knowledge base, but still needs to be communicated to the ones who implement the models in the PCS software. Based on these observations, the knowledge group folder is divided into attributes, constraints, methods and notes. As mentioned, in cases where other concepts or terms are used in the modelling environment of a PCS, the field names could be changed according to preferences. The basic content of a knowledge group is shown in Figure 12. Here, it should be noticed that the attributes from other classes (collaborators) are qualified by class and underlined, as they are intended to be hyperlinks in a software-supported environment. This makes the Collaborators field from the existing CRC card layout superfluous, unless the field is used for other purposes than describing collaborating classes.

15 CRC cards to support the development and maintenance of product configuration 15 Figure 12 The Knowledge group folder (see online version for colours) Knowledge group 1 Attributes Constraints Methods Notes Length {210, 220, 230 mm} [Integer] Width {88; 90; 92 mm} [Integer] 1: Length = Body.Length + 4 2: Type2 -> Body.Sport or Body.Station CalcArea () : Length * Width The thickness of the chassis is 3 mm. The chassis colour is black. The layout in Figure 12 basically lets the users formulate any kind of information within the fields. However, in some cases, it might be better to specify what information is needed to ensure that adequate and relevant information is documented. Therefore, the four fields in Figure 12 can be subdivided, as shown in the example in Figure 13. Here, the Inherited field is included to tell if an attribute, constraint or method originates from another class, which can be useful information when making changes. Figure 13 The Product knowledge folder (see online version for colours) Product knowledge Attributes Constraints Methods Name Values Unit Type Length 210; 220; 230 mm [Integer] Width 88; 90; 92 mm [Integer] Name Description 1 1: Length = Body.Length : Type2 -> Body.Sport or Body.Station Name Description CalcArea () CalcArea () : Length * Width Inherited Inherited Inherited Comments Comments Comments Notes The thickness of the chassis is 3 mm. The chassis colour is black. The constraints can also be represented by using tables or decision trees, as illustrated in Figure 14. Figure 14 Tables and decision trees Name Description Inherited Comments 1 Length Width ; ; Table representation Constraints 2 Chassis? Type1 Type2 Type3 Body.Type1 Body.Type2 Body.Type3 Body.Type4 Decision tree representation Besides the fields that are shown in this section, other fields could, in some contexts, also be relevant for inclusion in the Knowledge group folders, such as: implemented (code implemented in the PCS, preferably imported from the PCS) external systems collaborations (external interfaced systems, e.g., an Enterprise Resource Planning (ERP) system) name in external system (name of the field in an interfaced system).

16 16 A. Haug and L. Hvam 5.6 Handling of change requests The CPM definition of CRC cards does not include the fields for the management of changes besides a version number, while the CRC cards of the two investigated companies do. As described, Niro uses a different colour of text to indicate a requested change, while APC creates a new CRC card, which acts as a change request. While the Niro approach seems to include some risk of errors, the APC approach, on the other hand, seems a bit elaborate. A new concept for handling changes in CRC cards is, therefore, defined in this article. Until now, the CRC card definition that is proposed in this article does not require real software development and could more or less be handled by, e.g., Microsoft Word templates. The proposed concept for dealing with change requests, however, requires some software development in order to function efficiently. The basic idea is that it should be possible to click on a field in a CRC card that is to be changed and then select an appropriate action, i.e., modify, delete or add. After this, a change request, where additional change information can be stated, should automatically be created. The three kinds of change requests are illustrated in an example in Figure 15, where it should be possible to sort and filter these. Figure 15 Change requests (see online version for colours) Change requests Change ID Version Requested by Date Action Status Assigned to Completed by Date Folder 1245 W. Haug 11/11 05 Modify Pending K. Larsen Product knowledge Exist. line Constraints 2 2: Type2 -> Body.Sport or Body.Station New line Constraints 2 2: Type2 -> Body.Sport or Body.Golf 1246 V.1.1 W. Haug 14/11 05 Delete Implem. K. Larsen V. Jensen 15/11 05 Product knowledge Exist. line Methods CalcArea () Length * Width 1247 V.1.2 W. Haug 17/11 05 Add Implem. K. Larsen K. Larsen 18/11 05 Product knowledge New line Methods CalcVol () Length * Width * W. Haug 18/11 05 Add Pending K. Larsen Product knowledge 5.7 Change history Finally, the Change history folder is defined as a list of the history of versions, as shown in Figure 16. Figure 16 The Change history folder Change history Version V.1.0 V.1.1 V.1.2 Versioning Created by W. Haug V. Jensen K. Larsen Date 1/ / /11 05 Comments 5.8 Application of the new CRC card definition As mentioned, the proposed layout should not be perceived as a fixed layout, but as a definition that can be adapted to support a specific configuration project. A simple procedure for the definition of the basic layout of the CRC cards to be applied in a specific project could be to:

17 CRC cards to support the development and maintenance of product configuration 17 1 categorise the information that is included in the PVM or class diagram models that should be extended by CRC cards 2 decide which of these categories should be represented in the CRC cards and which categories should only be included in the structural diagrams 3 decide which fields to include in the CRC cards (the fields defined in this article can be used as a basis) 4 create a CRC card template that includes all of the selected fields. 6 A prototype that includes the new CRC card definition As part of the CPM project of creating a documentation system that supports the development and maintenance of PCSs, an initial prototype was developed in This prototype had the purpose of testing the definitions of the modelling techniques for a documentation system that were produced by Haug and Hvam (2006b). The paper by Haug and Hvam (2006b) included the redefinitions of PVMs and class diagrams, while the CRC cards in the prototype were based on the definitions that are presented in this article. The prototype includes three views: the PVM view, the class diagram view and the CRC card view. The CRC card view consists of a chosen CRC card together with a hierarchical list for navigating between CRC cards. In the prototype, CRC cards can also be accessed by double-clicking on the classes in the PVM view and the class diagram view. In Figure 17, a screenshot from the CRC card view of the prototype is shown. Due to time constraints on the development phase, the Change request and Change history folders were not included in the prototype. Also, the Notes field of the Knowledge group folder was not included, because it was added to the definition later. Because of time constraints and since the main purpose of the prototype was to test the definition of the included modelling techniques, the prototype did not include many of the functionalities that are needed for it to be applied in real configuration projects, such as multi-user access, versioning and the import/export features. Due to these shortages, the prototype has not been tested by being applied in real configuration projects. The tests that have been carried out so far concerns typing in models from existing projects. When disregarding the nonimplemented parts of the current CRC card definition, these tests have not revealed any shortcomings of this definition. In the prototype, the information that is created in the PVM and class diagram models is automatically shown in the CRC card view, for which reason the task of retyping information from PVMs and/or class diagrams in the CRC cards is eliminated. Also, the overview and navigation that the hierarchical list provides makes the use of the CRC cards much less elaborate than if using, e.g., Microsoft Word. However, it would be of great importance that a later version of the documentation system includes the change management part of the CRC card definition of this article.

18 18 A. Haug and L. Hvam Figure 17 The CRC card view in the prototype of a PCS documentation system (see online version for colours) 7 Conclusions In this article, a new definition of special CRC cards to support the development and maintenance of PCSs was presented. The studies of two companies showed that CRC cards can be a valuable technique to support the development and maintenance of PCSs. The studies also showed that the current CRC card definition from CPM differs in many respects from the way in which CRC cards are applied in practice. The experience gained from the studies and additional extensions were incorporated into a new definition of a CRC card layout. The proposed new CRC card layout consists of top-level information together with six groups of class information. One of these groups, called the Knowledge group, is to be renamed and have multiple instances according to the preferences of a specific company. For instance, in the case of one of the investigated companies, the group would have the instances Product knowledge, Price knowledge and Text knowledge. The new CRC card definition hereby offers a flexible basis that supports to a great extent the divisions of information of the CRC cards that are applied by the two investigated companies. Compared to the existing CRC card definitions from CPM, the new layout includes several new fields, e.g., additional relationship types, and new fields for the organisation of information about the attributes, constraints and methods. Another main extension of

19 CRC cards to support the development and maintenance of product configuration 19 the CRC card layout concerns the inclusion of fields for handling change requests. As opposed to the other fields of the new CRC card definition, the change request fields require some software development in order to function efficiently. By incorporating the experience gained from studying two companies into a new definition of CRC cards to support the development and maintenance of PCSs, an improved basis for other companies that are taking up the technique in configuration projects has been provided. The use of the new definition could produce possible benefits, such as minimising redundant information and avoiding the neglect of the relevant aspects in the PCS documentation. The new CRC card definition also constitutes an improved basis for the realisation of the ambition of CPM to create a documentation system to support the development and maintenance of PCSs. References Beck, K. and Cunningham, W.A. (1989) A laboratory for teaching object-oriented thinking, SIGPLAN Notices, Vol. 24, No. 10, pp.1 6. Bellin, D. and Simone, S.S. (1997) The CRC Card Book, Reading, MA: Addison-Wesley. Bennet, S., McRobb, S. and Farmer, R. (2002) Object-Oriented Systems Analysis and Design Using UML, 2nd ed., Glasgow: McGraw-Hill. Edwards, K., Hvam, L., Pedersen, J.L., Møldrup, M. and Møller, N. (2005) Udvikling og implementering af konfigureringssystemer: Økonomi, Teknologi og Organisation [Development and implementation of configuration systems: Economy, Technology and Organisation], Final Report from Research Project, Lyngby, Denmark: Department of Manufacturing Engineering and Management, Technical University of Denmark. Edwards, K. and Ladeby, K. (2005) Framework for assessing configuration readiness, Proceedings of the MCPC 2005, Hong Kong, September. Felfernig, A., Friedrich, G. and Jannach, D. (2000) UML as domain specific language for the construction of knowledge based configurations systems, International Journal on Software Engineering and Knowledge Engineering, Vol. 10, No. 4, pp Felfernig, A., Friedrich, G. and Jannach, D. (2001) Conceptual modeling for configuration of mass-customizable products, Artificial Intelligence in Engineering, Vol. 15, No. 2, pp Forza, C. and Salvador, F. (2002) Managing for variety in the order acquisition and fulfilment process: the contribution of product configuration systems, International Journal of Production Economics, Vol. 76, pp Forza, C., Trentin, A. and Salvador, F. (2005) Product information management for mass customization: the case of kitting, Proceedings of the MCPC 2005, Hong Kong, September. Fowler, M. (2005) UML Distilled, 3rd ed., Boston, MA: Addison-Wesley. Hansen, B., Riis, J. and Hvam, L. (2003) Specification process reengineering: concepts and experiences from Danish industry, Proceedings of the 10th ISPE international Conference on Concurrent Engineering: Research and Applications, Madeira, Portugal, July. Haug, A. and Hvam, L. (2006a) CRC-cards for the development and maintenance of product configuration systems, Customer Interaction and Customer Integration, Series on Business Informatics and Application Systems, Vol. 2, pp Haug, A. and Hvam, L. (2006b) The modelling techniques of a documentation system that supports the development and maintenance of product configuration systems, Customer Interaction and Customer Integration, Series on Business Informatics and Application Systems, Vol. 2, pp

20 20 A. Haug and L. Hvam Hvam, L. (1994) Application of product modelling seen from a work preparation viewpoint, (Trans.) PhD thesis, Lyngby, Denmark: Department of Industrial Management and Engineering, Technical University of Denmark. Hvam, L. (2004) A multi-perspective approach for the design of product configuration systems an evaluation of industry applications, Proceedings of the International Conference on Economic, Technical and Organisational Aspects of Product Configuration Systems, Lyngby, Denmark, June. Hvam, L. and Malis, M. (2001) A knowledge based documentation tool for configuration projects, Proceedings of the World Congress on Mass Customization and Personalization, Hong Kong, 1 2 October. Hvam, L. and Riis, J. (1999) CRC cards for product modeling, Proceedings of the 4th Annual International Conference on Industrial Engineering Theory, San Antonio, Texas, November. Hvam, L., Mortensen, N.H. and Riis, J. (2008) Product Customization, Berlin, Heidelberg: Springer-Verlag. Hvam, L., Riis, J. and Hansen, B.L. (2003) CRC-cards for product modelling, Computers in Industry, Vol. 50, No. 1, pp OMG (2005) Unified Modeling Language: Superstructure (Version 2.0: Formal/ ), Pine, B.J., Victor, B. and Boynton, A.C. (1993) Making mass customization work, Harvard Business Review, Vol. 71, No. 5, pp Riis, J. (2003) Fremgangsmåde for opbygning, implementering og vedligeholdelse af produktmodeller med fokus på konfigureringssystemer [Procedure for building, implementing and maintaining product models with focus on configuration systems], PhD thesis, Lyngby, Denmark: Department of Manufacturing Engineering and Management, Technical University of Denmark. Sabin, D. and Weigel, R. (1998) Product configuration frameworks a survey, IEEE Intelligent Systems & Their Applications, Vol. 13, No. 4, pp Stumptner, M. (1997) An overview of knowledge-based configuration, AI Communications, Vol. 10, No. 2, pp