Dynamic constraint
handling in mass
customization systems
AREA: Computer Engineering
AUTHORS: Johan Kåhlman & Josef Spånberger SUPERVISOR:Jasmin Jakupovic
JÖNKÖPING August 2020
Postadress: Besöksadress: Telefon:
This exam work has been carried out at the School of Engineering in Jönköping in the subject area Computer Engineering. The authors take full responsibility for opinions, conclusions and findings presented.
Examiner: Tuwe Löfström Supervisor: Jasmin Jakupovic Scope: 15 hp
Abstract
Purpose: The purpose of this study is to develop an architecture for a Mass Customization
information system that allows for product customization restrictions being dynamically expressed through the database.
Method: A study evaluating an artifact made using Design Science Research. The evaluation
was made using both a quantitative and a qualitative method.
Findings: Building upon a literature review to establish a knowledge base, an artifact was
created using React and Node.js to build a web application combined with a Neo4j graph database. The artifact allows for products and their inherent restrictions to be dynamically added and modified through constraints defined in their data. This data can be used in the web application to assemble and customize components, where the constraints can be enforced by the web application in real time without any modification to the application.
The artifact can enforce all constraints that were intended and it was considered as a better overall solution for handling constraints compared to the currently used solution by Divid, a market leading company in the usage of Mass Customization systems with constraint handling in the context of ventilation systems.
Implications: The results implicate that the usage of graph database systems in Mass
Customization systems holds great promise, specifically as a new way to handle constraints between components dynamically.
Limitations: The results from the expert panel only reflects the opinions of Divid and might
not be true for other companies interested in this area. The artifact solution was successful in its purpose to illustrate the concept of dynamic constraint handling. However, it is still unclear if the system holds up in a professional context with more complex rules and heavy demands on performance.
Sammanfattning
Syfte: Syftet med denna studie är att utveckla en arkitektur för ett informationssystem inom
Mass Customization som gör det möjligt att anpassa produktbegränsningar dynamiskt genom databasen.
Metod: En studie som utvärderar en artefakt som är skapad med hjälp av Design Science
Research. Utvärderingen utfördes med både en kvantitativ och en kvalitativ metod.
Resultat: En litteraturöversikt gjordes för att bygga upp en kunskapsbas och utifrån denna
skapades en artefakt med hjälp av React och Node.js för att bygga en webbapplikation kombinerat med en Neo4j-grafdatabas. Artefakten gör det möjligt för produkter och deras begränsningar att dynamiskt läggas till och ändras genom begränsningar som definieras i deras data. Denna data kan användas i webbapplikationen för att skapa och anpassa komponenter, där begränsningarna kan verkställas av webbapplikationen i realtid utan någon ändring av applikationen.
Artefakten kan upprätthålla alla avsedda begränsningar och det betraktades som en bättre övergripande lösning för hantering av begränsningar jämfört med den nuvarande använda lösningen av Divid, ett marknadsledande företag inom användning av Mass Customization system med begränsningshantering inom ventilationssystem.
Implikationer: Resultaten indikerar att användningen av grafdatabassystem inom Mass
Customization har stor potential, specifikt som ett nytt sätt att hantera begränsningar mellan komponenter dynamiskt.
Begränsningar: Resultaten från expertpanelen reflekterar endast Divids åsikter vilket inte
behöver överensstämma med andra företags åsikter som har intresse av det behandlade området. Artefaktlösningen var framgångsrik i dess syfte att illustrera begreppet dynamisk begränsningshantering. Det är emellertid fortfarande oklart hur systemet fungerar i en professionell kontext med mer komplexa regler och högre krav på prestanda.
Contents
Abstract ... i
Sammanfattning ... ii
Contents ... iii
1
Introduction ... 1
1.1 BACKGROUND ... 1 1.2 PROBLEM STATEMENT ... 11.3 PURPOSE AND RESEARCH QUESTIONS ... 2
1.4 SCOPE AND LIMITATIONS ... 2
1.5 OUTLINE ... 2
2
Method and implementation ... 3
2.1 LINK BETWEEN METHOD AND RESEARCH QUESTIONS ... 3
2.2 WORK PROCESS ... 3
2.3 APPROACH ... 4
2.4 DESIGN ... 4
2.4.1 Design of research process ... 4
2.4.2 Design of experimental simulation ... 5
2.5 DATA COLLECTION ... 6
2.5.1 Information gathering ... 6
2.5.2 Experimental simulation ... 6
2.5.3 Expert survey ... 6
2.6 DATA ANALYSIS ... 7
2.6.1 Analysis of experimental simulation ... 7
2.6.2 Analysis of expert survey ... 7
2.7 CREDIBILITY ... 7
3
Theoretical background ... 9
3.1 LINK BETWEEN RESEARCH QUESTIONS AND THEORY ... 9
3.2 MASS CUSTOMIZATION ... 9
3.2.1 Mass Customization Information Systems ... 9
3.3 RELATIONAL DATABASE SYSTEMS ... 10
3.4 ACTIVE DATABASE MANAGEMENT SYSTEMS... 10
3.6 RELATED WORK ... 11
4
Findings ... 11
4.1 PROPOSITION OF ARTIFACTS ... 12
4.2 CHOOSING ONE ARTIFACT ... 12
4.3 ARCHITECTURE OF CHOSEN ARTIFACT ... 12
4.3.1 Overview ... 13
4.3.2 Database schema ... 14
4.3.3 Dynamic constraint handling ... 15
4.3.4 The use of Cypher queries ... 16
4.4 RESULTS OF EXPERIMENTAL SIMULATION ... 16
4.5 RESULTS OF EXPERT SURVEY ... 17
4.5.1 Binary questions ... 17
4.5.2 Comments and remarks ... 17
5
Analysis ... 18
5.1 ANALYSIS OF EXPERIMENTAL SIMULATION ... 18
Part 1. ... 18
Part 2. ... 18
5.2 ANALYSIS OF EXPERT SURVEY... 19
6
Discussion and Conclusions ... 21
6.1 RESULT... 21
6.2 IMPLICATIONS ... 21
6.3 LIMITATIONS ... 21
6.4 CONCLUSION AND RECOMMENDATIONS ... 22
6.5 FURTHER RESEARCH ... 22
References ... 23
Appendices ... 25
Expert Survey ... 25
1
Introduction
1.1 Background
When creating a ventilation system many factors play a part in its design, such as the size of the building and the rooms, the number of people expected to inhabit it, the air temperature, the humidity in the area and the difference in climate between the seasons. These are just a few of all the factors which makes the design of a ventilation system a complicated affair with the need for a wide range of different products. A ventilation system is built up by different types of components such as air intakes, heat exchangers and air filters, all of which comes in great variety to suit a system’s individual needs.
To meet the demands of specialized products for their customers, the ventilation industry among other industries utilize the concept of Mass Customization. Mass Customization (MC) is a hybrid of the pre-industrial craft era and todays industrial mass production [1]. The aim of MC is to provide customized products at near mass production cost, not pure custom products but products with enough variety of options available to fit a customer’s need [1]. A core part of a successful MC system is that of the interaction between customer and manufacturer [2]. This is often achieved by using an interactive information system where a catalogue of products and options are available to the customer to customize their product, this information is then used by the manufacturer to create their product.
This thesis is done in collaboration together with Divid AB [3] situated in Jönköping. Divid is a software company developing a range of product selection programs and product configurators for the sale of customized products. These programs are developed for companies in the ventilation industry and allow them to work with their customers to develop and manufacture a customized ventilation system that fit their customer’s need.
The aim of this study is to develop a solution for the ability to define constraints on customization of products through a database system.
1.2 Problem statement
The product of Divid’s mass customization systems is a set of interconnected components forming a ventilation system made to satisfy a customer’s specific needs. The individual components are subject to customization as is the number of components and their placement in the system.
The customization which can be made on a component, is constrained by a set of predefined options. These options cover different attributes on components such as “Size” or “Effect”. There are circumstances which put additional constraints on which options that can be chosen for a component depending on certain factors. These are the three categories of additional constraints which can limit the options available on a component:
- Intra-component constraints: Constraints that limit an option from being viable due to one or many other options being chosen or not chosen on the same component. - Inter-component constraints: Constraints that limit an option from being viable due
to the configuration of the system, depending on factors such as what other components there are in certain positions and how they are configured.
- Intra- and inter-component constraints: Constraints that limits an option due to a combination of the intra- and inter-component factors.
These limitations of options must be clear to the user of the program and be enforced by the logic of the software. Today, Divid uses passive storage in a relational database system to store the information of all different types of components, their attributes and set of options. This information is accessed through an application program with a user-interface when constructing a new ventilation system.
The constraint of only being able to choose from the predefined number of options is achieved by only being able to choose from the options available in the database. The intra-component constraints are dynamically enforced by the application program, by parsing and interpreting information from the database it limits the options available in the user-interface. The more complicated inter-component constraints, however, cannot be represented as information in the database in Divid’s current implementation. Each constraint must be specifically programmed into the user-interface application.
Divid wants a solution where both intra- and inter-component constraints are expressed through the database. This to enable that new components and their constraints could be added into their MC systems without the need to update and rebuild their user-interface applications.
1.3 Purpose and research questions
The purpose of this study is to develop an architecture for mass customization information system that involves inter-connected components and their constraints. The architecture should allow for product customization restrictions being dynamically expressed through the database. To achieve this purpose the following research questions have been formulated:
- What type of database system is well suited to model interconnected customizable products?
- How can the architecture of a mass customization system be constructed so that constraints of available options can be dynamically expressed through a database?
1.4 Scope and limitations
This study is based on the need of a specific company with its own prerequisites. As such, the narrowing down of possible solutions is made with this specific need in mind. We use the solution to the problem that is best in our estimation in the specific context. Rather than focusing on what is the theoretically best possible solution we have focused on finding and implementing a good and working solution. As such, the results should be of high relevance to anyone interested in developing a system that deals with MC with interconnected objects.
1.5 Outline
The following report contains the following: Chapter 2 describes the method used and steps taken in order to answer the research questions. Chapter 3 discusses the theoretical frameworks used as foundation in order to produce a solution. Chapter 4 covers the empirical evidence that was collected in to produce and validate the solution. In Chapter 5 the results and evaluation are analyzed. Finally, the report is concluded by a discussion and conclusion of the whole study in chapter 6.
2 Method and implementation
2.1 Link between method and research questions
Design Science Research (DSR) is chosen as the method for this study as its core principles are to create and evaluate a purposeful artifact (in this case an implementation of a system) intended to solve an unsolved problem [4]. The first research question is answered by investigating different types of database systems by conducting a literature review. The second research question is answered by investigating different architecture designs and choosing one to implement and then evaluate its utility as a satisfactory solution.
2.2 Work process
There is a great variety of proposed methods with different workflows for conducting DSR [5]. The method used in this study is based on the proposed method and workflow by Dresch in “Design Science Research: A Method for Science and Technology Advancement” [5]. This method consists of twelve steps, which are shown in Figure 1 and are explained below.
1. Identification of the problem. The problem is studied so that it is clearly understood, well defined and its relevance is justified for further research. This step formalizes the research questions.
2. Awareness of the problem. The second step of the study is to create a broader awareness of the problem. More information is gathered about the context of the problem and its causes. 3. Systematic Literature Review. In conjunction with the second step a literature review is performed to consult studies of similar problems. During this stage, the requirements of the artifact to be developed are also considered.
4. Identification of the artifacts and configuration of the classes of problems. Similar problems gathered in the literature review are used to learn about similar solutions and lessons learned in previous studies, this helps define the contribution of this study’s artifact. At this stage, the requirements for a satisfactory solution is also defined.
5. Proposition of artifacts to solve a specific problem. In the fifth step, artifacts are proposed derived from the requirements and knowledge learned in the previous steps that could offer a satisfactory solution to the problem.
6. Design of the selected artifact. In this step one of the proposed artifacts is chosen and its design is further developed. During this stage, the expected performance is clearly stated for its eventual evaluation.
7. Development of the artifact. After the design is completed the development of the artifact is performed.
8. Evaluation of the artifact. The artifact is evaluated towards the requirements previously defined in step 4. The evaluation method for this is an Experimental simulation [4] to test its functionality. If the artifact fails to meet the requirements step, 6 and 7 will be repeated. When the requirements have been met an expert survey is performed to establish its utility in a real-world business setting.
9. Clarification of learning achieved. The learning achieved during the research process is clarified.
10. Conclusions. The results of the study and the decisions made during the research are specified. The limitations of the study are also presented and propositions for further studies. 11. Generalization for a class of problems. The artifact’s solution and the knowledge acquired is generalized for a certain class of problems.
12. Communication of the results. The report is finalized and uploaded to Jönköping University’s publications archive DiVA [6].
Figure 1, The study's work processes.
2.3 Approach
In this study, both quantitative and qualitative empirical data are used. The experimental simulation relies on a test protocol with pass or fail scenarios while the expert survey conducted includes questions and comments which is interpreted qualitatively.
2.4 Design
2.4.1 Design of research process
This study is designed to adhere to the seven guidelines for DSR brought forward by Hevner et al. [4] see Table 1 below.
A viable artifact is produced which solves a relevant business problem for Divid (design as an artifact, problem relevance). The utility of this artifact is demonstrated through evaluation methods and its research contribution are evident from the lack of a solution in the literature (design evaluation, research contribution). As mentioned above, this study applies a rigorous method in the development and evaluation of the artifact (research rigor). The search for an effective artifact design is utilized by understanding the environment of the problem and investigating the knowledge base around it (design as a search process). The results of this study are communicated in a manner to reach a broader audience than just the technology oriented (communication of research).
Table 1, Guidelines for DSR, based on Hevner et al. [4].
2.4.2 Design of experimental simulation
What follows is a detailed explanation of the possible types of constraints that should be able to be defined by the artifact, a description of the test protocol and the six set of constraints constructed to test all these types.
As stated in the problem description there are three types of additional constraints other than the constraint of predefined options; intra-component constraints, inter-component
constraints and a mix of intra- and inter-component constraints.
An intra-component constraint can limit an option from being a viable option due to one or many other options being chosen or not chosen on the same component.
An inter-component constraint can limit an option from being a viable option by:
- An interconnected component of a certain product type being or not being in a specified position relative to the constrained component.
- An interconnected component of a certain product type and configuration being or not being in a specified position relative to the constrained component.
The specified position includes number of steps from the constrained component and if the interconnected component is before, after or in either direction.
From this, these constraints can be generalized into the following: - Option X is not allowed if [condition]
- Option X is only allowed if [condition] Where conditions may be the following:
- Single expression conditions:
o X, e.g. Option O is chosen, product Y is at position P
- Multiple expression conditions: o X and Y,
o X or Y,
And the expressions may define: - Intra-component conditions:
o Attribute A has option O - Inter-component conditions:
o Product Y is at position P
o Product Y with Option Oat position P - Intra- and inter-component conditions combined
o e.g. Attribute A has option O and Product Y is at position P
And the positions may be:
- X number of steps after the constrained component
- X number of steps before the constrained component - X number of steps in either direction of the component
These are the 6 constraints that are tested in the experimental simulation in order to test all possible types of constraints:
1. Airfilter Height is not allowed to be “25cm” if its Width is “75cm” 2. Duct size is only allowed to be “75x75cm” if its Length is “2m” or “3m”
3. Duct size is not allowed to be “25x25cm” if it is connected to a Duct of any other size 4. Fan Grille is not allowed to be “Has not grille” if there is a filter one step after it 5. Fan Size is not allowed to be “75x75x20cm” if its Effect is “100W” and there is a filter
three steps before it
6. Fan effect is only allowed to be “300W” if there is a Duct and Airfilter any number of steps behind it or its Size is “75x75x20cm”
The experiment is executed using a test protocol divided into two parts. In part one, Cypher queries are described that are to be entered into the database for the insertion of three new products and their constraints. In part two, these products are assembled into a ventilation system using the artifact. The second part of the protocol features 39 detailed instructions of actions to be performed and the expected result of the actions. During each step, each action and result is manually performed and monitored. The actual result is compared with the expected result and each step is graded with a pass or fail.
Test Step Test Procedure Expected Result Pass / Fail
12. Open up the “Width” list and choose option “75cm”, then open “Height” list
Option “25cm” is disabled and appears in red text.
Table 2, Example from protocol. See Appendices for fully conducted protocol.
2.5 Data collection
2.5.1 Information gathering
To gain an understanding of the context of the problem a literature review is conducted about Mass Customization (MC) as a concept and previous research about MC information systems. Different types of database systems are also researched for the propositions of artifacts later in the study.
2.5.2 Experimental simulation
An experimental simulation [4] is conducted on the artifact where it is executed with artificial data to test its functionality. A test protocol is used with instructions of actions to be performed and the expected result for each action. The result of the experiment using the protocol is used to evaluate if the artifact is functioning correctly.
2.5.3 Expert survey
An expert survey is administered together with Divid. A panel of six expert programmers, working in the company, is assembled. They receive a full presentation containing the artifact
solution and examples from the experimental simulation as well as how the current system solves the same tasks. The panel is then individually given an “Expert Survey” (see Appendices) containing four questions:
1. “Do you think that the artifact provides a solution that makes it easier to implement constraints between components compared to the current system?”
2. “Do you think that the artifact provides a solution that makes it easier to change existing constraints between components compared to the current system? “
3. “Which of the solutions do you think will be the most time efficient to use for Divid in the future?”
4. “Which of the solutions do you think is the best overall solution for handling constraints?”
The researchers make sure to point out to the panel that a truthful answer will be the most useful for the research and that it will not matter for the completion of the study which answers are given.
2.6 Data analysis
2.6.1 Analysis of experimental simulation
The five requirements that the artifact must adhere to and what is the subject of analysis are: - 1. Only predefined options are available to be chosen in the user-interface application. - 2. The intra- and inter-component constraints limits the intended options and only the
intended options from being chosen in the user-interface application.
- 3. If an already chosen option becomes subject to an intra- or inter-component constraint, i.e. it is no longer an available option, the user-interface application must make this apparent to the user and undo the selection of the option.
- 4. After removing a component that limited options on other components through inter-component constraints, those options must become available for selection again. - 5. Adding new intra- and inter-component constraints does not involve changing or
adding code to the user-interface application.
The test protocol is designed to invoke the behavior of the artifact where it will be made apparent if the requirements are met. The recorded behavior of the artifact is analyzed and compared to the expected behavior. If the artifact fails to adhere to any of the requirements it is deemed to be non-functioning.
2.6.2 Analysis of expert survey
The survey was originally constructed to be subject of quantitative analysis which explains the focus on questions with clearly defined alternatives. After careful consideration this was changed late in the process in favor of a qualitative approach. This enables more interpretation of the results but without trying to generalize them to any population. Since the expert panel was appointed by Divid themselves as the most appropriate representatives for their company's opinion, the authors perceive the results speaks about the artifact’s utility without involving quantitative calculations. As the intended method for analysis was changed late in the process, the qualitative analysis is done without a framework which lowers its validity.
2.7 Credibility
The choices made in this study are the result of an actual need stated by a market leading company. Early in the process there were plans to try to formulate a more comparative study between two different pre-defined solutions, roughly connected to the problem, in order to fulfil the research demands of a thesis. In discussion with Divid and JTH representatives this was
changed in favor of DSR. The focus of DSR is to produce an artifact of actual value in a real-world context which has been the focus during the research process. The theoretical frameworks mentioned were discovered during the research process, in the quest of finding a good solution to the problem.
Considering that the solution is not a full-fledged replacement for Divid’s current system, the methods for data collection and evaluation were not obvious. In order to be relevant for both Divid and a broader audience, the decision was made to include both an experimental simulation as well as an expert survey.
3
Theoretical background
3.1 Link between research questions and theory
In order to answer the first research question, a foundation of relevant concepts and technologies are explored in this chapter. With the exploration of the available technologies, a subset of these are used in order to propose an architecture for the second research question.
3.2 Mass Customization
Mass customization (MC) is a concept to produce customized products through flexible processes in large volumes and at low costs [7]. It combines the custom products of craft manufacturing with methods of mass production to achieve low costs. The name of this concept was coined in the book ‘‘Future Perfect’’ [8] in 1987 and its boundaries has been delineated into two issues [9]:
(1) the basic nature of customization
(2) the means for achieving customization at or near mass production cost
The first issue about the nature of customization concerns the distinction between variety and customization in providing a customer with a product specifically designed to fit their needs. Customization is distinct from variety and requires the involvement of the customer to specify the product as opposed to the customer choosing a product from a large selection of varieties [9].
The second issue is how to achieve the “mass” in mass customization. A means for achieving customization at or near mass production cost is to employ modularity. The way of using modularity is to manufacture part of the product in volume as standard modules with product customization achieved through combination with other modules. This allows the modules used to create a custom product to be fabricated using mass production with low-cost [10].
3.2.1 Mass Customization Information Systems
The success of MC for a company is highly determined by the efficiency of the information transfer from customer to company [11]. The following activities has been proposed to establish a customer-manufacturer communication link [2]:
- Defining a catalogue of options to be offered to customers - Collecting and storing information on customer choices - Transferring data from retailer to manufacturers
- Translating customer choices into product design features and manufacturing processes.
These activities are facilitated by an information system that allows an interaction between customer and manufacturer. The information system establishes an interface where the customer designs its customized product using the predefined catalogue of the options available [7].
The following are a number of requirements that have been proposed for an effective MC information system: [7]
- Collaborative product development: The information system should help to deliver a product based on the individual customers demands by providing an open, friendly, and flexible system.
- Elicit knowledge about clients: The information system should transform the customer’s demands and needs to knowledge. This can then be used to create new solutions and products for the organization.
- Virtual enterprise environment: The user should be able to access the information system at any time and wherever they are.
3.3 Relational Database Systems
Relational databases are the most widely used solution for storing data in the corporate world [12, 13]. The data in a relational database is structured into tables of relating data with columns and rows. Each column within a table/relation must have a unique name. Each row in a table has a unique id, which is the primary key. This makes the unique id identifiable and ensures every row in the table/relation to be unique. As a row in turn can be split into the columns the table contains, each value of data is uniquely identifiable [12, 13].
In order to connect different tables with each other, a column in one table may contain what is known as a foreign key, referring to a primary key in another table [13].
Relational databases are not designed to handle multiple values for an attribute. It is recommended to create a new entity in such cases and store the multiple instances inside this new entity. Multivalued attributes would slow down searching in the database as well as pose questions about the meaning of what the data represents [13].
In order to retrieve data from the relational database, a language known as Structured Query Language (SQL) is often used. SQL is more declarative than the most common programming languages, meaning that the user specifies the result that is wanted but not the procedure how to get this result [12].
3.4 Active Database Management Systems
An Active Database Management System (ADBMS) is a database with the ability to act automatically to events happening either inside or outside the database [14]. A traditional passive database system only serves as a data container, where operations such as inserting, updating, deleting, etc. are executed by requests by a user or application program [14]. An ADBMS does not only function as a container of data but can also replace program logic embedded in the application that is using the database and perform operations on its data independently [15].
On a conceptual level, the ability of the database to act reactively is achieved through Event-Condition-Action (ECA) rules. As the name suggests, ECA rules are made up by three components: an event that describes a situation where the rule might become active, a condition defining if it should become active and an action to be carried out if the condition is true. The implementation of ECA rules is most commonly done by triggers [16]. Triggers can perform a number of actions when activated including [12]:
- Cancel transactions.
- Changing the content of the database. - Executing stored procedures.
- Communicate with external programs.
There are several benefits of using an ADBMS some of which are: ECA rules can be used to ensure integrity constraints [14]. Business rules concerning data can also be applied and adjusted directly where it is stored without modifying the application accessing the data [15]. This allows for the rules implemented in the database to be reused if a new user application would be developed [15]. However, care needs to be taken when introducing ECA rules into a database as rules may trigger other rules and infinite rule triggering might arise [17].
3.5 Graph Database Systems
Graph database systems focuses on nodes and what connects these nodes (edges/relationships). A common usage is the links between humans in a social network where the edges represents relationships. While these types of graphs could be stored in a relational database, the queries required could end up being both complicated to write and slow to run [12]. The relationships between the objects are in graph databases as important as the object themselves. The nodes and edges can in turn hold properties [18].
With the use of the Cypher query language, it is possible to traverse the graph in a declarative manner [18]. The graph database makes it possible to do localized operations in the form of traversals without processing unrelated data which is not possible using SQL. In a graph database every node stores its own index of everything that is connected to it [19].
3.6 Related Work
While no study has been found with a similar design and purpose, Frutos and Borenstein [7] built a MC information system with a relational database as an example and a recommendation for how companies can serve customers in a MC environment. They do not, however, specify how to handle constraints dynamically.
4 Findings
4.1 Proposition of artifacts
In the process of the literary review to answer the first research question, different database solutions were considered for solving the problem.
A system with a relational database was first considered and explored. While this could have theoretically worked, the modelling of a flow chart in a relational database would not be intuitive, as the positions of components relative to each other must be represented with some sort of order. For a specific component in the system to point out other components in the system, relative to its own position, would not be straight forward.
A graph database was deemed perfectly intuitive for modelling interconnected components. The query language Cypher makes it simple to write queries to add new connections and components into a system. The type of queries involved to query an interconnected system would also be simple to express using a graph database. Neo4j offers index free adjacency, which makes it fast and effective to query since you can search for nodes adjacent to each other without the use of indexes and it only looks at relevant data. While the most common use cases of graph databases involve massive data sets in giant networks, the relative ease of traversing a graph was considered a perfect fit for creating the artifact solution with a lot of potential for innovation.
As the purpose was to handle constraints through the database without changing the user application, two different possibilities were explored. The constraints could either be expressed in the database using triggers and stored procedures or they could be expressed as data and be interpreted by the user application.
Proposition:
• A web application with an active database enforcing constraints
• A web application interpreting and enforcing constraints stored as data in a passive database
Both options could be constructed either with a relational database or a graph database.
4.2 Choosing one artifact
While a lot of consideration was taken to develop a system with relational databases, what ultimately showed most potential was graph databases. The biggest advantage of a graph database is the ability to traverse the graph/system using localized operations.
Using an active database was investigated but it was found that it could more easily produce unexpected behavior [17] and would be more complicated to update and implement. Instead it was decided that the artifact should store the constraints as data with interpretation and enforcing done within the web application.
4.3 Architecture of chosen artifact
The focus of the artifact is to illustrate a way to handle constraints dynamically in a mass customization system. The concept itself would not require an implementation to be demonstrated. However, an application was created to validate that it works. In this process tools were chosen that were familiar to the developers through experience. The concept itself could have been illustrated just as well using other development frameworks.
Divid’s current solution involves several different components. One of them is a npm-package called “promaster-sdk” [20] to evaluate possible combinations of attributes within a component. If the combination of all attributes is valid, the system will pass the check and be
allowed to be created. Instead of developing a new form of validation for possible combinations of attributes, this tool currently used by Divid was considered and ultimately chosen. This was both to save time in development and so that the solution would be more familiar to Divid. Considering the evaluation of attributes are simply a form of check and not the focus for the artifact solution, the tool was considered a good solution.
The development of the artifact has been influenced by continuous feedback from Divid. The feedback has been used to produce a system that is relevant and familiar for Divid, for example by using the “promaster-sdk” library. Even though some adaptation to the specific context has been made the core concept of handling constraints dynamically between components in a mass customization system has remained intact.
4.3.1 Overview
The artifact is built up by three separate applications communicating with each other using the HTTP (see Figure 2).
Figure 2, Overview of system architecture.
The web application provides the user interface and is implemented using the React JavaScript library. This application is used to assemble a ventilation system using the data stored in the database application. It receives and stores new data in the database through communication with the web server application. The user interface is of a simple design but contains what is needed to assemble a ventilation system from customized products (see Figure 3). In the user interface it is possible to create a new system or load an existing one and add to it customized components that can be connected to other components in the same system. The customization of components is done using drop down lists containing products and their available options for each attribute.
Figure 3, User Interface.
The web server application is a Node.js application and works as the bridge between the user application and database. It exposes a web API to which the user application sends http-requests when it wants to store or fetch data. The server stores and fetches data from the
database using the Neo4j JavaScript driver. The driver allows the web server to send queries and receive back data from the database through the HTTP.
The database application is a Neo4j graph database management system that is used as the persistent storage for the artifact. For developmental purposes it is run locally using the official docker image for Neo4j enterprise edition.
4.3.2 Database schema
As stated in 3.2.1 by Da Silveira et al. [2], a successful MC information system needs to define a catalogue of options and store information on customer choices. The storage of the catalogue of options in done as in the entity relation diagram shown in Figure 4.
Figure 4, Catalogue of options schema.
The catalogue of options in this case are the products that are subject to customization with their attributes and the options of those attributes.
Products, attributes, and options are all stored as nodes in the database. The product nodes have relationships with attribute nodes and the attributes also have relationships with the option nodes. The properties “value”, “propertyFilter” and “filterQuery” on option nodes are used for the handling of constraints and will be explained further down.
The storage of customer choices which in this case are ventilation systems of interconnected components is done as shown in Figure 5.
Figure 5, Customer choices schema.
An assembled system is stored with one system node, a component node for each component in the system and a configuration node for each option chosen during customization. The system node has a relationship to every component node contained in its system. The component nodes have relationships with other component nodes and with configuration nodes. The configuration nodes store the choices made for a component’s attributes by storing the attribute´s name and the value and description of the option chosen.
4.3.3 Dynamic constraint handling
Dynamic constraint handling is achieved by defining the constraints on an option as a property filter string in its “propertyFilter” property, and by storing a Cypher query in its “filterQuery” property that is used to query the database about information relevant to its possible inter-component constraints (see Figure 6). This information is then used to continuously validate if options are valid and disabling them in the user-interface if they are not.
Figure 6, Example of option data.
The validation and defining of constraints are done by implementing property filters using the promaster-sdk/property library [20]. A property filter is a string describing what combination of key-value pairs are valid for an option. A key in this context is either a name of an attribute on the same component as the constrained option, or a key related to the naming of an inter-component constraint. A value is either the value of an option chosen on the same inter-component or a value of information about the system. As an example the property filter “Size=3&NextIsFilter!=1” describes that an option is valid if the attribute “Size” on the same component has the value 3 and that the next component in the system is not a filter.
An option is validated by comparing its property filter against a property value set, which is a string describing a set of key-value pairs of the same types described in the property filter. It contains both intra- and inter-component key-value pairs. The intra-component pairs represent the current configuration of the component’s other attributes and the inter-component pairs represent other information about the system it is in. The intra-inter-component pairs are derived from the choices that has been made in the user-interface. The inter-component pairs are derived from what results are returned when executing the Cypher queries contained in the filterQuery properties of the component’s options. The queries are executed when connections are made or removed to other components.
The comparison is done using the PropertyFilter.isValid function in the promaster-sdk/property library. The function has two parameters, one for a property filter andonefor a property value set and returns either true or false. For example, if we use the property filter “Size=3&NextIsFilter!=1” and the two property value sets “Size=3;NextIsFilter=0” and “Size=3;NextIsFilter=1”, the first set would return true but the second false. This would be because the property filter states that “Size” has to be 3 and “NextIsFilter” cannot be 1, in the first set we can see that both of the values of “Size” and “NextIsFilter” have allowed values but in the second set “NextIsFilter” is 1 and therefore it would return false.
The options for a component are validated this way each time an option is chosen on it or a connection is made or removed. The return value of true or false are then used to disable or enable options in the user-interface by making them unable to be chosen and changing the font color of the option from black to red. If an option was chosen and became invalid it is also removed as a chosen option.
4.3.4 The use of Cypher queries
The Cypher queries stored in filterQuery properties allows for inter-component constraints to be defined as key-value pairs in a property filter. Their function is to probe the system the component is in and return the values relevant to an inter-component constraint.
Executing a filterQuery returns one or more key-value pairs where a key corresponds to a key defined in the property filter’s key-value pairs. What the value represents is decided by the query. In Figure 6 an inter-constraint has been defined that depends on if the component after the constrained option’s component is a filter. This requires that the user-application has the information what the next component is and is solved by executing the option’s filterQuery and using the information that is returned. The query in this example looks for a match where the component after the option’s component is a filter, if it finds one it will return the description of the inter-constraint and the value 1 and if it does not it will the value 0. This information is then used to construct the property value set that will be evaluated against the property filter. Another example of what an inter-component constraint can define and what information a filterQuery can return is shown in Figure 7. Here the inter-component constraint define that the option is only allowed if there is a duct and a filter somewhere in the system behind the constrained option’s component. The query searches for matches of ducts and filters behind the component and returns the number of each it finds.
Figure 7, Example of option data.
4.4 Results of experimental simulation
To test the functionality of the artifact an experimental simulation was conducted. The experiment was performed several times during the development of the artifact in order to identify unintended behavior and bugs in the artifact. Once the artifact successfully passed every step of the protocol it was repeated three times to ensure the validity of the result. The experiments were performed using a test protocol (see Appendices) designed to test a set of six constraints during an assembly of a ventilation system. A test step received a “pass” grade when the actual behavior matched the expected behavior described in the protocol.
Test step Grade Test step Grade
1. Pass 21. Pass 2. Pass 22. Pass 3. Pass 23. Pass 4. Pass 24. Pass 5. Pass 25. Pass 6. Pass 26. Pass 7. Pass 27. Pass 8. Pass 28. Pass 9. Pass 29. Pass 10. Pass 30. Pass 11. Pass 31. Pass 12. Pass 32. Pass 13. Pass 33. Pass 14. Pass 34. Pass 15. Pass 35. Pass
16. Pass 36. Pass
17. Pass 37. Pass
18. Pass 38. Pass
19. Pass 39. Pass
20. Pass
Table 3, Final results of the experimental simulation.
4.5 Results of expert survey
A presentation of the artifact was given to six programmers from Divid. They were given a full presentation of how the artifact was built as well as a comparison with the currently used system. After the presentation, each programmer was given a survey containing the questions specified in 2.5.3. It was specified to pick one of the options for each question. Even though this instruction was given, many of the programmers gave neutral answers which was not intended. 4.5.1 Binary questions
“Do you think that the artifact provides a solution that makes it easier to implement constraints between components compared to the current system?”
“Yes”: 4 “No”: 2 Undecided: 0
“Do you think that the artifact provides a solution that makes it easier to change existing constraints between components compared to the current system?”
“Yes”: 4 “No”: 2 Undecided: 0
“Which of the solutions do you think will be the most time efficient to use for Divid in the future?”
“Artifact solution”: 2 “Current solution”: 1 Undecided: 3
“Which of the solutions do you think is the best overall solution for handling constraints?” “Artifact solution”: 4
“Current solution”: 0 Undecided: 2
4.5.2 Comments and remarks
The current solution is more time efficient in the short term as it is fully implemented and familiar, but the artifact solution would likely be more time efficient to maintain in the long run. The current solution is tailored to fit the specific needs of the customer. Perhaps the artifact solution would be easier to understand for customers to use themselves and it could be an overarching system to use for all existing customers which would be an advantage.
The artifact would probably not be able to fully replace the current system which handles very complex/diverse rules that can arise. Perhaps a combination of the current system and the artifact solution would be optimal. The artifact solution would likely reduce the code base a great deal and would likely be easier for customers to understand and implement by themselves which would lower maintenance for developers.
The panel also raised questions about the performance of the system in a complete system with a full set of constraints as well as how easy it would be to implement more complex constraints than the ones demonstrated.
5
Analysis
The goal of this study is to find a dynamic solution when dealing with constraints between components in a mass customization system. This has been accomplished by following the Design Science Research method, producing an artifact to illustrate the concepts explored. To validate the artifact, the findings are analyzed below.
5.1 Analysis of experimental simulation
This analysis of the experimental simulation focuses on explaining how the expected behavior of the protocol relates to the requirements set for the artifact in section 2.6.1. It also explains how each type of constraint that is defined in section 2.4.3 is tested by the six constraints included in the experiment. This is done to evaluate if the artifact adheres to its purpose and requirements.
Part 1.
The first part of the experiment was related to requirement 5. In this part new data about products and their intra- and inter-components constraints were inserted into the initially empty database of the artifact without any change to the user interface application. This requirement was met as the added constraints behaved as intended in part two.
Part 2.
The second part of the experiment tested the other four requirements stated in section 2.6.1 by assembling a ventilation system with the previously inserted data using the artifact’s user application. What follows is the analysis of the artifact’s behavior during this part of the experiment, it is divided into the steps corresponding to each of the six constraints defined in 2.4.3.
Steps 1-7, Constraint 2:
These steps illustrated that the artifact can handle an intra-component constraint where an option is only allowed if one or another option is chosen. This was demonstrated by that the option “75x75cm” on the attribute “Size” was only allowed when either option “2m” or “3m” on the attribute “Length” were chosen. We saw also that requirements 1 and 2 were met by that the only options that were available were the predefined ones, and that constraint limited the intended option and only the intended option when it was expected to do so.
Steps 8-13, Constraint 1:
These steps illustrated that the artifact can also handle an intra-component constraint where an option is not allowed if another option is chosen. This was demonstrated by that the option “25cm” on the attribute “Height” only became unavailable when the option “75cm” on the attribute “Width” was chosen. Requirements 1 and 2 were also met again and would be for all the rest of the constraints tested, and so will not be brought up again in the analysis.
Steps 14-24, Constraint 3:
These steps illustrated that the artifact can handle an inter-component constraint where an option is not allowed dependent on if it has a connection to, in either direction, a specific product with a certain option not chosen. This was demonstrated by that the option “25x25cm” was only made unavailable when it was connected to a “Duct” that did not have the same option chosen. Requirement 3 was also met as when the selected option was unselected, and the user were made aware of this through an alert when the option became unavailable through a new connection.
Steps 25-29, Constraint 5:
These steps illustrated that the artifact can handle a constraint that is a mix of intra- and inter-component factors. What was shown was that an option was not allowed if a certain option was chosen on the same component and a component of a specific type, was connected a specified
number of steps before. This was demonstrated by that the option “75x75x20cm” on the attribute “size” was not available when the option “100W” of the attribute “Effect” was chosen and there was a connection to a filter, three steps before. Requirement 3 was met again during these steps.
Steps 30-33, Constraint 4:
These steps illustrated that the artifact can handle an inter-component constraint where an option is not allowed if there is a connection to a component of a specific product type one step behind it. Demonstrated by that the “Has not grille” option on the attribute “Grille” was only made unavailable when a connection was made to a component of product type “Airfilter” and not from it. Requirement 3 was shown to be met again and so was requirement 4, as after removing the connection to the Airfilter it was shown that the constrained option had been made available again.
Steps 34-39, Constraint 6:
These steps illustrated an example of a constraint that is a mix of intra- and inter-component constraints. In this case we can see that the artifact can handle a constraint that ensures that an option is only available to be chosen if there are two components, each of a specified product type, any number of steps behind it, or if a certain option is chosen on the same component. Demonstrated by that the option “300W” on the attribute “Effect” was only available when the component had a connection where both a “Duct” and an “Airfilter” was behind it or it had the option “75x75x20cm” on the attribute “Size” chosen.
The experimental simulation showed that the artifact can handle a large variation of constraints of customizable products, and that it can accomplish it dynamically though data stored in the database without any changes made to the user application.
5.2 Analysis of expert survey
As mentioned in 2.6.2, the survey was originally constructed to be subject of quantitative analysis which explains the closed-ended questions in the survey. Even though the validity of this analysis is limited, it should be considered as a complement to 5.1. Since the artifact was developed in collaboration with Divid, their opinion about its utility is highly relevant. Even considering the limitations of the survey itself and the ad hoc qualitative analysis, the authors argue that it still captures the opinions of Divid as a whole.
“Do you think that the artifact provides a solution that makes it easier to implement constraints between components compared to the current system?”
“Yes”: 4 “No”: 2 Undecided: 0
As a majority of the expert panel thinks that it would be easier to implement constraints using the artifact, this indicates that the concept holds potential for Divid. As mentioned in 4.5.2 there could be the potential for customers to more easily understand the way the artifact solution implements constraints which means that they might be able to implement them themselves which would free up time for the programmers working at Divid.
“Do you think that the artifact provides a solution that makes it easier to change existing constraints between components compared to the current system?”
“Yes”: 4 “No”: 2 Undecided: 0
This question held the exact same results as the first, indicating that they might have not been significantly different from each other. Once again though, a majority of the expert panel deemed the artifact solution as an easier way to change existing constraints.
“Which of the solutions do you think will be the most time efficient to use for Divid in the future?”
“Artifact solution”: 2 “Current solution”: 1 Undecided: 3
The third question had the most diverse answers and the majority of the panel was undecided. As discussed in 4.5.2 comments about this question was made as you would have to take into account the time it would take to switch to a new system which would likely be considerable, making the question hard to answer. Once it had been implemented though, it would have the potential to be easier to maintain with a reduced code base and it might be easier to implement as an overarching system between customers.
“Which of the solutions do you think is the best overall solution for handling constraints?” “Artifact solution”: 4
“Current solution”: 0 Undecided: 2
The last question showed the most promise as a majority of the panel preferred the artifact and none of the programmers preferred the existing solution. Even though the panel had many questions, comments and remarks as mentioned in 4.5.2, this question captures the essence of what the survey wanted to answer: if the concept illustrated in the artifact solution is a good way to handle constraints. Considering the results of the question, according to Divid, it likely is.
6 Discussion and Conclusions
6.1 Result
The design of the artifact solves the issue of product customization restrictions in mass customization involving inter-connected components. It allows for products and their inherent restrictions being dynamically added and modified through constraints defined in their data. This data can be interpreted and enforced by the user web application in real time without any modification on the application, including inter-component constraints. The core of this design is to define constraints of a product's options as key-value pairs of allowed combinations, the use of database queries for retrieving inter-component information and storing both as data on the restricted options.
In the artifact’s current design, the validation of inter-component constraints requires communication with the database and cannot be handled by the user-application itself. It must first communicate with the server application, which must query the database and then send back the result for the client application to be able to validate options. This could be a problem since the communication could create unwanted response times for the user. In a further iteration, some sort of query language could be developed that could be internally used by the client application so that it could probe the system itself when inter-component constraints are involved.
The purpose of this study was to develop an architecture with dynamic handling of constraints for a mass customization system with inter-connected components. This purpose has been fulfilled due to producing an artifact that could pass the specified test protocol and was considered a better overall system for handling constraints than the currently used system by a market leading company.
The first research question was answered through a literature review which resulted in a knowledge base used to produce an artifact which answered the second research question. The fact that the artifact passed the test protocol shows that it can enforce all the type of constraints that it was intended to handle. It also showed that constraints can be added dynamically as all the information needed to enforce them are stored as data and thus can be added and altered without any changes to software.
The results from the expert survey showed great promise as three of the four questions got a majority of the panel in favor of the artifact. The questions from the panel about the system’s performance when handling a massive number of queries as well as how more complex constraints could be implemented could not be answered by the authors. It is likely that the system could handle these conditions, but there is none concrete evidence in this study to support those claims. This study’s aim was not to produce a full-fledged replacement system for Divid’s currently used system, it was simply to illustrate the potential in using a graph database as an intuitive way to handle inter-component constraints.
6.2 Implications
The results implicate that the usage of graph database systems in mass customization systems holds great promise, specifically as a new way to handle constraints dynamically between components.
6.3 Limitations
The results from the expert panel, shown in 4.5, only reflects the opinions of Divid and might not be true for other companies interested in this area. However, it should be noted that Divid is a market leading company. The panel of developers were selected specifically by Divid to evaluate the artifact. As such, the opinions stated should be valid for Divid as a whole and should therefore hold some relevance for other companies interested in this concept.
The fact that multiple participants checked both options in some of the questions showed that it was not clearly communicated how they should fill in the survey. This was also likely due to the limited time for the panel to make up their mind about the artifact and perhaps also inadequate information given by the authors. Likewise, the authors failed to clearly communicate the purpose of the study to the panel, as some of the programmers expected the artifact to be more of a full replacement of the current system and was thus skeptical of its usability. Considering the programmers reluctance to answer with one of the clearly defined options, the approach of binary questions with only two alternatives was clearly not the best approach. A survey with open-ended questions would have likely given more valuable data for analysis.
The artifact solution was developed to illustrate how the concept of constraints could be handled dynamically in the context of a mass customization system. As remarked by the expert panel, it is unknown how this implementation could handle a large number of queries in a real-world setting. The goal of this study was to illustrate the concept, which was successful, but it has not demonstrated how it would work in a professional context.
6.4 Conclusion and recommendations
The artifact solution was developed upon the knowledge base gathered from the literature review where the goal was to find a suitable way to model interconnected customizable products. The graph database was considered most suitable and was chosen as the basis of the constructed artifact. The goal of the artifact was to have constraints of available options be dynamically expressed through the database.
As shown in 5.1, dynamically expressing constraints of available options was achieved by defining constraints as data in the form of key-value pairs and storing Cypher queries for retrieving data concerning inter-component constraints. This resulted in that constraints can be defined in the database and be enforced by the user application without any modification to the software. The use of a graph database with stored queries allows for versatile expressions of restrictions on options, where constraints may refer to factors such as the configuration of other components or the placement of components in the same system.
As shown in 5.2, the expert panel of Divid saw potential in the developed artifact. Specifically, the majority of the panel preferred the artifact solution on three of the four questions.
While the artifact is considered a success as it fulfilled its purpose to illustrate a new way of handling constraints dynamically through the database, the utility of this concept in a real-world setting is still unclear. As such, the authors urge companies using mass customization systems with the need of dynamic constraint handling to develop larger scale frameworks and systems in order to realize the potential of the concept shown in this study. As discussed in 6.1, an improvement that should be explored in this realization is to have an internal query language in the client application probe the system automatically when inter-component constraints are involved, in order to raise performance.
6.5 Further research
A relevant study would be to focus on the performance of a graph database in a large system where a massive number of localized queries are executed, rather than to illustrate the concept itself as this study has done.
References
[1] Fralix, M. T. (2001). From mass production to mass customization. Journal of Textile and Apparel, Technology and Management, 1 (2), 1-7.
[2] Da Silveira, G., Borenstein, D., & Fogliatto, F. S. (2001). Mass customization: Literature review and research directions. International Journal of Production Economics, 72 (1), 1-13. [3] Divid (2020). Divid – Selection Software Experts. Hämtad 2020-08-20 från
https://divid.se/
[4] Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information systems research. MIS Quarterly, 28 (1), 75-105.
[5] Dresch, A. (2015). Design Science Research A Method for Science and Technology Advancement. Cham: Springer International Publishing.
[6] Jönköping University. (2020). Publikationer. Hämtad 2020-08-20 från https://hj.diva-portal.org/
[7] Frutos, J. D., & Borenstein, D. (2004). A framework to support customer–company interaction in mass customization environments. Computers in Industry, 54 (2), 115-135. [8] S.M. Davis (1987). Future Perfect. Reading, MA: Addison-Wesley.
[9] Duray, R., Ward, P. T., Milligan, G. W., & Berry, W., L. (2000). Approaches to mass customization: configurations and empirical validation. Journal of Operations Management, 18 (6), 605-625.
[10] Pine II, B. J., Victor, B., & Boynton, A. C. (1993). Making mass customization work. Harvard Business Review, September-October, 108-116.
[11] Turowski, K. (2002). Agent-based e-commerce in case of mass customization. International Journal of Prodiction Economics, 75 (1-2), 69-81.
[12] Padron-McCarthy, T., & Risch, T. (2018). Databasteknik. Lund: Studentlitteratur.
[13] Harrington, J. L. (2016). Relational Database Design and Implementation. Amsterdam, Netherlands: Morgan Kaufmann.
[14] Paton, N. W., & Díaz, O. (1999). Active database systems. ACM Computing Surveys, 31(1), 63-103.
[15] Amin, M., Maseleno, A., Perumal, E., Vidhyavathi, R, & Lakshmanaprabu, S.K. (2018). Active Database System Approach and Rule Based in the Development of Academic Information System. International Journal of Engineering and Technology, 7 (2.26), 95-101. [16] Rabuzin, K., Maleković, M., & Lovrencic, A. (2007, September 12-14). The Theory of Active Databases vs. The SQL Standard. The Proceedings of 18th International Conference on Information and Intelligent Systems, Varaždin, Croatia.
[17] Medina-Marín, J., Pérez-Lechuga, G., & Li, X. (2009, November 13-15). ECA rule analysis in a Distributed Active Database. 2009 International Conference on Computer Technology and Development, Kota Kinabalu, Malaysia.
[18] Batra, S., & Tyagi, C. (2012). Comparative analysis of relational and graph databases. International Journal of Soft Computing and Engineering, 2 (2), 509-512.
[19] Miller, J. J. (2013, March 23-24). Graph database applications and concepts with Neo4j. Proceedings of the Southern Association for Information Systems Conference, Atlanta, GA, USA.
[20] Github. (2020). @promaster-sdk/property - Property values and filtering. Hämtad
2020-08-20 från
Appendices
Expert Survey Name:Do you think that the artifact provides a solution that makes it easier to implement constraints between components compared to the current system?
☐Yes ☐No
Do you think that the artifact provides a solution that makes it easier to change existing constraints between components compared to the current system?
☐Yes ☐No
Which of the solutions do you think will be the most time efficient to use for Divid in the future? ☐Artifact solution
☐Current solution
Which of the solutions do you think is the best overall solution for handling constraints? ☐Artifact solution
☐Current solution
