ENTITIES IN THE OBJECT-ORIENTED DESIGN PROCESS MODEL

INTERNATIONAL DESIGN CONFERENCE - DESIGN 2000 Dubrovnik, May 23-26, 2000. ENTITIES IN THE OBJECT-ORIENTED DESIGN PROCESS MODEL N. Pavković, D. Marjanović Keywords: object oriented methodology, design process modeling Abstract: The development of a computer-based framework that could enable the use of different partial design process models in an integrated manner is presented. The object-oriented methodology is used, because it provides a better modelling capabilities than the other programming techniques. Every occurrence, relation and other real-world 'things' from the domain of the design process are attempted to be modelled as objects. The basic structural, relational and behavioural entities of the design process model are proposed and discussed. A matrix form is used to record the binary dependence relations between objects that constitute a framework. The proposed framework should be used as an open toolbox. The use of UML as an implementation environment is also discussed. 1. Introduction None of the design theories which are used today, like e.g. descriptive, prescriptive, general, and axiomatic design theories, is alone capable, to describe and to formalize the whole design process and to make possible a complete computer support of this process [Vajna, 1999.]. Keeping this in mind, the research efforts in this project are directed towards development a framework that could enable the use of different partial models in an integrated manner. We assume that the object-oriented methodologies can provide more appropriate and flexible ways of software system modelling than the other techniques. The design process is here viewed as a sequence of transitions from an initial state of data, constraints and goals to a final state, the description of the designed mechanical artefact. These transitions are allocated to individual participants or teams, and individual or integrated computational tools or models. A design process may no longer be viewed as a static institutionalized structure, but rather as a dynamic network that is constructed in real-time as design goals, needs, priorities, and resources evolve [Wallace, 1999]. In the framework of an integrated CAD environment, the designer should work with an open toolbox, enabling him to create his own classes and partial models of the design process according to his current needs. The goal is to develop a framework for modelling the design process independently of design phase and a class of design task. Object-oriented analysis begins with an examination of the real-world 'things' that are part of the problem to be solved. These things (which we will call objects or entities) are characterized individually in terms of their attributes (transient state information) and behaviour (functional process information). In object-oriented terms, we discover and describe the classes involved in the problem domain. In parallel to these individual characterizations, we also model the links or collaborations between the problem domain's objects (and therefore our solution's classes). Object-oriented design then turns from modelling the problem domain towards modelling the implementation domain. 29

2. The proposed set of entities in the object-oriented design process model In the proposed approach, every occurrence, kind of action, set of information, relation and other realworld 'things' from the domain of the design process, are attempted to be modelled as objects. In the presented research phase, the considerations are limited to recognition of basic entities and their attributes, while the necessary operations are only denoted. The collaboration processes between objects and classes will be modelled in the next phase. Proposed design process model is conceived to be developed as an open toolbox with packages of classes and objects. In such an environment the designer should mainly use the existing classes as templates and building blocks. According to [Booch et al., 1999] the object is a concrete manifestation of an abstraction; an entity with a well defined boundary and identity that encapsulates state and behaviour. The proposed object-oriented design process model is built upon following set of entities (objects): Basic structural elements: design parameter; design parameter container; action; design task; product information object; designer (as an actor in the process) Elements for describing the relations between entities: relations between objects, recorded in matrix form (a package of classes); design constraints; design decision rules Behavioural and control elements: elements to support the control of design process flow; process description & management elements (a package of classes); data transfer protocols for communication with software tools that are in use in a particular design environment Architectural elements: databases; programming tools; CAD packages; computational tools A brief description of each entity is given as follows. 2.1 Basic structural elements 2.1.1 Design parameter Design parameter is a basic unit of information about product being designed. Design parameter is recorded as a variable whose value represents a single fact. Considering a design process as a process of information transformation, the basic unit of information, or a single fact can be represented as a design variable. In other words the basic entity in any form of product description (or design activity) is a variable, often named a design parameter or design attribute. Design parameters can be modelled as objects or as object attributes. If a particular parameter needs only name, type and value to form a complete description, it can be modelled as an object attribute. Considering the iterative nature of the design process, the need for the value status of a design parameter can be recognised. Therefore, a parameter that requires a value status or some additional attribute to be completely described, should be modelled as an object. The set of design parameter attributes is proposed as follows: name, type, multiplicity, value, value status, physical unit, hyperlink to knowledge base Parameter type is one of: numerical, textual, Boolean The parameter value status is one of: determined, but can be changed; determined and fixed; assumed single value; value assumed in discrete or continuous interval The notion of value status can be particularly useful in iterative processes, where it enables the development of improved algorithms for solving such problems [Eppinger, 1994]. 30

2.1.2 Design parameter container (DPC) Design parameter container (DPC) is an organized warehouse (repository) for design parameters. DPC contains all design parameters modelled as objects, as also the operations for maintenance of its structure and for access control. Engineering data structures are often more complex than those in business problems. When modelling the design world with objects, we assume that there will be many situations in which the same parameter will be the attribute of objects that belongs to the independent or loosely dependent classes. Even if those attributes could be set as public for the whole model, they still can have different values in particular objects. The value of every such shared parameter must be unique in time and design space, so it must be written outside the scope of the objects that must share its value. Following this requirement, the DPC can be seen as a pool of data shared among several objects that don t belong to the same class hierarchy. Data stored in DPC are design parameters modelled as objects. This data collection is hierarchically structured and categorized, to ease the operations of searching, retrieving and other manipulations in the case of the large number of parameters stored. Every parameter has the unique name and storage address. Assuming that every parameter belongs to only one group or category, the structure of DPC can be realised and managed in a relational database, but the better solution would be an object database. In the process of the development of a new product, the DPC can be filled with parameters as the design evolves. For variant and adaptive design tasks, the DPC of previous designs can be used as a template, which can be modified and upgraded. The proposed data structure is not intended to be a replacement for a complete product data model. We are only emphasizing the necessity of managing the values of parameters shared among distinct classes and objects at one common place, (in one pool) in a universal manner. When the design is completed, the DPC contains only the subset of the information set about the product being designed. 2.1.3 Product information object A product information object is a concrete abstraction of a set of information about product being designed. This object can represent a computer-stored information or some other kind of information storage. The information set can be form functional or physical domain. Product information object can be very complex in structure because it can contain other objects or references to other objects in design process model. The examples of product information objects could be: 3D CAD model, 2D CAD drawing, bill of materials, product assembly structure, I/O set of any calculation, etc. Product information objects undergo the most of the operations in the design process. At the end of the design process, the set of the product information objects forms the complete information collection about the product being designed. 2.1.4 Action An action is an effort made to realize a specific result. An action is an executable atomic operation that results in a change in state of the system or the return of information. Actions mainly operate on product information objects. Actions should be modelled as objects in order to be used as elements in building the description of the design process flow. 2.1.5 Design task A design task is here defined as a set (or a sequence) of actions performed on a set of a product information objects. The design task goal is to reach a required state of all the objects that are in scope of a particular task. Usually, the design task represents the process of solving a subproblem, or a part of a decomposed structure of a product design process. The main attributes of a design task should be: the references to a set of objects that are in scope of a particular task; the desired goal state of those objects; I/O parameters, resources, available services and terms. 31

2.2 Relations between entities In the presented approach, the relations between objects are also viewed as objects. Therefore the proposed design process model should contain special classes to represent and manipulate the relations between basic structural and other more complex entities. When analyzing different information models we can find some variations in classification of relations. In the proposed model we will rely on four types of relations, according to the authors of Unified Modeling Language: dependency; generalization; association and realization, [Booch et al., 1999]. 2.2.1 Design relation matrix Dependency relations between objects are of special interest in developing the structure of the proposed model. The idea developed in this model is to use the matrix form for representing sets of dependency relations between objects of similar classes, as also between objects of different classes. In matrix form, a mark in a cell indicates that a relation exist between elements of corresponding row and column. Recording the existence of the relations in a matrix form gives us a survey of dependencies between large sets of objects in a relatively compact form. Such views of a model structure can be of great significance in planning the sequence of actions in the design process. One of the disadvantages of the matrix representation is in fact that the mark in matrix cell indicates only the existence of the relation, telling us nothing about the relation properties. However, this problem could be partially solved with the following additions: classifying the marks, and adding the meaning to every particular mark writing a pointer in a matrix cell which points to the full description of a relation There are some principal questions that should be answered in this phase of considerations: The relations between which classes of objects (entities) should be represented in a matrix form? Can we extend the matrix form to represent relations that are not only binary? To answer this problem we can consider a matrix in figure 1, which contains all basic structural entities. Every X mark in this matrix indicates that it should be useful to record the relations between such a combination of objects. DP DPC A DT PIO D design parameters DP x design parameter container DPC actions A design tasks DT x x x product information objects PIO x x x x designers D x x Figure 1. Combinations of relations between basic structural entities Only some of the most significant combinations from the above matrix are emphasized and discussed in the rest of this chapter. 2.2.2 Design structure matrix The significant combination from matrix shown in figure 1 is the relation between design tasks, usually referred as "design structure matrix". The design tasks to be performed are each represented by an identically labelled row and column of the matrix. The marked elements within each row identify which other tasks must contribute information for proper completion of the design. Tasks in the matrix may be resequenced, which helps to identify cyclical and acyclical tasks. The researchers who have contributed to this kind of design process modelling observe that is a feasible proposition to construct this type of matrix, even for relatively complex design processes with more than 100 tasks. 32

A B C D E F G H I J K L B C A K L J F I E D H G A X B serial B C X C X A X paralel D X X X K X X E X X X L X X X X F X X J X X X X X coupled G X X F X X tasks H X X X X I X X X I X X X E X X X J X X X X X D X X X K X X H X X X X L X X X X G X X Figure 2. The design structure matrix before and after resequencing [Eppinger et al., 1994] Several algorithms for resequencing the design tasks are developed [Eppinger et al., 1994], [Rogers et al., 1996]. Such algorithms should be implemented as operations in the design structure matrix class. The primary role of the design structure matrix as a class in a proposed model is to be a tool for determining the execution sequence of the design tasks. 2.2.3 Design parameter matrix This matrix can be conceived as a design structure matrix on a parameter level. Dependency relationships recorded in this matrix, should be the basis for creating the design structure matrix. Design parameter matrix can be decomposed to a set of submatrices in a case of a large number of parameters. All the parameters that appear in the matrix must be stored in the design parameter container in order to be managed in a unique way. 2.2.4 Other relations in matrix form Among other combinations of relations from figure 1, the "action - product information object" relation can also be of a particular interest for planning and controlling the design process. Such a matrix should record the set of actions that should be performed on a particular product information object. An activity-issue matrix is presented in [Blessing, 1993], where it has been used for capturing and recording the design rationale. Various association relations could also be recorded in a matrix form, e.g. designer-task, designer-product information object, etc. An open issue to be explored is the extension of a matrix representation for relations that are not only binary. 2.2.5 Design constraints and design decision rules These are the relations between design parameters, recorded in a form of equations or sets of if-then rules. Design constraints and decision rules are the essential entities for controlling and evaluating the design process propagation. These objects can stand alone, can be connected to control elements, or can be a part of product information objects. 2.3 Behavioral and control elements This set of entities has a role to model and manage the design process flow. The design process is represented with design plan graphically represented as a network of nodes (a graph). The connections between nodes represent the information flow and/or the preplanned execution paths. To execute a node means to perform the associated operations. The nodes of a design plan are objects, created in a process of generating a plan and stored in the object database. Operations performed in the plan nodes should be various software tools that operate on product information objects. Connections (relations) between plan nodes are recorded in adjacency matrix. Nodes and relations should be classified in order to implement different behaviours. Templates of such objects are stored in object database, to be at disposal in the process of generating a design plan. In the processes of generating and executing a design plan, a full access to all basic structural entities must be provided. A more detailed description of modelling the design constraints and rules, design plan nodes and design plan execution is given in [Pavković, Marjanović, 1999, 2000]. 33

3. The implementation of the proposed model The presented research phase includes only the analysis of the structural and behavioural elements. The techniques of object oriented modelling and design have been intensively explored in last ten years, and it seems that they finally reached a high level of maturity. These days such techniques are dominated by the Unified Modeling Language (UML), which is going to be a standard modelling language for object-oriented development. Therefore, the UML is chosen to be an implementation environment for the proposed design process model. Besides going to be a standard, such a choice has some other benefits: All members of a development team use a common language. Confusion over terminology and requirements is averted. Transition between planning and programming is shortened due to a clearer understanding between designers and implementers. 4. Conclusion The proposed object structure is still a scaled prototype model. A lot of work remains to be done: refining the proposed structure, establishing class packages and hierarchies defining and designing attribute sets and operations in classes defining use cases, defining and diagramming collaborations between objects designing main system operations that have the threads of control developing interfaces to commercial object and relational databases The benefits of object oriented methodology and UML raises new challenges. Using UML, a distributed design community can easily collaborate in developing the design process model. Maybe that could enable initiating the process of creating a theoretical framework for integrated computer design process support that will be widely accepted in a design community. Acknowledgements The paper presents a preliminary report of the Project No. 120-015, sponsored by the Croatian Ministry of Science and Technology. References Blessing L., "A Process-Based Approach to Computer Supported Engineering Design", Proceedings of International Conference on Engineering Design ICED 93, Vol. 3., pp. 1393-1400, WDK, Heurista, 1993. Booch G., Rumbaugh J., Jacobson I., Unified Modeling Language User Guide, Reading, Addison Wesley, 1999 Eppinger S. D., Whitney D. E., Smith R. P., Gebala D. A., "A Model-Based Method for Organizing Tasks in Product Development", Research in Engineering Design, Vol. 6, No. 1, 1994., pp. 1-13 Pavković N., Marjanović D., Structuring a Designers Workbench with Object Oriented Design Plans, Proceedings of the 12th Int. Conf. on Engineering Design ICED 99, WDK, Vol. 3, 1999, pp. 1401-1406 Pavković N., Marjanović D., Considering an object-oriented approach to design process planning, International Journal of Technology Management, 2000., (to appear) Rogers J. L., McCulley C. M., Bloebaum C. L., "Integrating a Genetic Algotithm into a Knowledge-Based System for Ordering Complex Design Processes", NASA Technical Memorandum 110247, 1996. Vajna S., Burchardt C., Richter A., Organizing Integrated Product Development With Network Structures, Proceedings of the 12th Int. Conf. on Engineering Design ICED 99, WDK, Vol. 1, 1999., pp. 393-396 Wallace D. R., Abrahamson S. M., Borland N. P., Design process Elicitation Through the Evaluation of Integrated Model Structures, Proceedings of DETC 99, 1999., ASME Design Engineering Technical Conf. Neven Pavković, M.Sc. University of Zagreb, Faculty of Mech. Engineering & Naval Arch., Design Department 10000 ZAGREB, I. Lučića 5, CROATIA Tel: +385 1 6168 545, + 385 6168 369, e-mail: neven.pavkovic@fsb.hr 34