A tutorial and review of object-oriented design of manufacturing software systems

Computers ind. EngngVol. 30, No. 4, pp. 781-798, 1996

Pergmon S036041352(96)00031-9

A TUTORIAL DESIGN

AND

REVIEW

OF MANUFACTURING

Copyright © 1996 Elsevier Science Ltd Printed in Great Britain. All rights reserved 0360-8352/96 $15.00+ 0.00

OF OBJECT-ORIENTED SOFTWARE

SYSTEMS

JOHN M. USHER Mississippi State University, Department of Industrial Engineering, P.O. Box 9542/125 McCain Bldg, Miss. State, MS 39762, U.S.A.

(Received 1 February 1996) Abstract--Object-oriented design represents a relatively new method of software system design that provides a means for the development of robust software systems. This approach is what software developers need to deal with the dynamic nature of the manufacturing organization and the processes contained within. This paper presents a tutorial which focuses on the application of object-oriented design and programming to manufacturing software development. This essay begins with an examination of object-oriented software design (OOD) and how it compares with traditional algorithmic design. The discussion reviews the major elements of an object-oriented system and discusses how these elements support the development of complex software systems using examples from manufacturing as support. This is followed by a discussion of the steps to use as one approach to object-oriented design. The paper concludes with a review of object-oriented manufacturing systems reported in the literature. Copyright © 1996 Elsevier Science Ltd

1. INTRODUCTION

The use of computers in industry has become commonplace. Manufacturers have come to rely on the data processing capabilities of computers to help them perform more efficiently in all areas of their business. There exists commercial software systems that can be applied to every area of a manufacturing enterprise, from purchasing and marketing to engineering and quality control. For those businesses committed to the philosophy of computer integrated manufacturing (CIM), there is a need to integrate these software systems and provide them with a single view of the enterprise, its current state, and mode of operation. These requirements for the manufacturer have resulted in the need for the development of complex software systems that can support the needs of, and provide the interoperability for, integration and data sharing. The most popular method for the design of software systems has been the "procedure-oriented" approach that employs algorithmic decomposition of the problem space. In recent years, there has been an increasing use of an alternative approach involving object-oriented decomposition. This paradigm of program design is better suited to the development of complex software systems and represents a viable alternative to the development of such systems in the area of manufacturing[l]. Many corporations are now investigating the applicability of object-oriented technology through the use of pilot projects [2]. The focus of this tutorial is on the use of object-oriented design and programming to build manufacturing software systems. This article begins with an examination of object-oriented software design and how it compares with traditional algorithmic design. The discussion reviews the major elements of an object-oriented system and discusses how these elements support the development of complex software systems using examples from manufacturing as support. This is followed by a discussion of the steps to use as one approach to object-oriented design. The paper concludes with a review of object-oriented manufacturing systems reported in the literature. 2. SOFTWARE DESIGN

The common approach used in the design of complex software systems is the divide-and-conquer approach. This method involves dividing a system up "into smaller problems in such a way that from solutions to the smaller problems we can easily construct a solution to the entire problem" [3]. This section compares the traditional and object-oriented approaches to design and then details the elements of an object-oriented design. 781

782

John M. Usher

2.1. Traditional structured design The traditional "top-down" structured design is one implementation of the divide-and-conquer approach. This method involves algorithmic decomposition of a system into modules that each represent a major step in the overall process. Following the definition of this basic sequence of tasks, each of these tasks is then further refined into a sequence of subtasks necessary to achieve each primary task. This process of stepwise refinement is continued until each step in the design has been expanded into enough detail that it can be expressed as a series of statements in the chosen programming language (i.e., FORTRAN, Pascal, etc.)[4]. Consider applying this approach to the design of a computer-aided process planning (CAPP) system. Tasks that must be accomplished include: define the part, select the operations to machine the features of the part, sequence those operations, etc. Each of these steps can then be further broken down into more detailed steps (see Fig. 1). The leaves of the resulting tree represent primitive functions that will be implemented in algorithmic form. The other elements in the tree perform their function making use of the algorithms in the lower levels of the hierarchy. For example, the portion of the system that defines a part will make use of algorithms developed which define a paws geometry. This specification of a part's geometry will require calls to lower-level functions which perform such functions as identifying the paws features and defining its dimensions. The top-down approach simplifies the design of the system by allowing the developers to focus on each part of the system one at a time. However, use of this approach requires that the developer completely specify the problem space and its decomposition prior to the coding of the system. Most programmers do not possess the discipline to completely specify the design and will most likely begin coding the system too early, resulting in an unstable design [5].

2.2. Object-oriented design An alternative approach to software design involves object-oriented decomposition. This method requires that the developer identify a set of system objects from the problem domain and express the operation of the system as the interaction between these objects. Instead of a system comprised of algorithms that carry out the individual steps of the process, the program is built around a set of object classes. Each object class models the behavior of an object in the real world. This behavior is defined by what an object is capable of doing. Asking an object to perform a specific function requires that it be sent a message instructing it to do so. Therefore, the software system operates

Plan

Define Part

Define Geometry

Identify Part Features

Select Operations

Define Topology

Define Dimensions

Check Part Integrity

""

...

Determine Part Profile

Determine Max. Diameter

Fig. 1. Algorithmic decomposition.

"'"

Sort Features

Object-oriented design: a tutorial and review

783

by allowing the objects of the system to pass messages to one another requesting that they perform certain functions. Considering the design of a CAPP system, object classes would be created to represent such entities as a part, its features, operations, tools, fixtures, part-profiles, etc. In an object-oriented system, the task of defining a part's geometry would not exist as an algorithm called by a higher level function, but as a series of messages issued by the part object to the object defined as features. The message define geometry would prompt the features object to identify the part features based on its knowledge of the data required to completely specify a particular feature. The features object would then send messages to create instances of the objects that represent the different features that make up the part (i.e., cylinders, cones, etc.). An example of this interchange of messages is shown in the network graph in Fig. 2 for the same planning system as given in Fig. 1. Note that the messages passed between objects correspond to the functions performed by the algorithms in the previous architecture. The difference is that these messages invoke functions that are part of (encapsulated within) the object class itself (a concept discussed later). The object-oriented approach to software design represents a different way of thinking about the problem domain. However, viewing the world as a collection of objects and its processes as the interaction of those objects is not a hard concept for individuals to grasp. This concept parallels the natural way in which we perceive the operation of systems around us, and forms the paradigm that is the basis for object-oriented design (OOD). Although the object-oriented approach may be a natural way to view systems, it seems that the longer one has been exposed to the traditional design approach the harder it may be to convert to this new method of design. 3. ELEMENTS OF AN OBJECT-ORIENTED SYSTEM

Applying the object-oriented paradigm to software design results in the development of an object model of the real world system. This model forms the basis for the implementation of the system in software and encompasses the principles of abstraction, encapsulation, modularity, and hierarchy. These elements arc an essential part of an object-oriented model, and without any one of these elements the model could no longer be called object-oriented. In the discussion which follows, each of these elements is presented with reference to our manufacturing example.

Determine

Sort

~

I _1_

Fig. 2. Object-oriented decomposition and mes~ging.

I

784

John M. Usher

3.1. Abstraction

An abstraction can be defined as "a simplified description, or specification, of a system that emphasizes some of the system's details or properties while suppressing others" [6]. Abstraction is one way in which humans deal with complexity. We choose to ignore some of the details and instead generalize about the system and its operation. This results in an abstraction that is dependent upon the perspective of the user. In object-oriented design, abstraction arises in the definition of the object classes that make up a system. These objects must possess and reflect the essential behavior and attributes of the real world objects. This behavior is embodied in the operations that can be performed upon an object, and in how an object reacts to messages sent by client objects (where a client object is defined as any object that uses the resources of another object). Therefore, a developer will define a set of classes that best represents their abstraction of the real world objects within the system. Each resulting class represents a set of real world objects that share a common structure and behavior [1]. Once the classes of a system are defined, an actual system object is created by declaring it to be an instance of a particular class type. For example, in the C + + language a specific instance of the part object class would be defined as: part part_ 1 ; / / D e f i n e s part_ 1 as an instance of the part object class Consider the definition of an object class to represent a part within a CAPP system. One view of real world parts, from the planning perspective, would include the features they possess, the geometry of those features, their relationship, and characteristics (e.g., surface finish, tolerances, etc.). To model this view of a part, a developer would create an object class representing these characteristics and the operations that express the behavior of the part. For rotational parts, a single part might be defined in terms of such data as its name, number, description, material, and the features that make up its volume (see Fig. 3). Some of these descriptive characteristics (i.e., name and number) can be represented using typed variables such as strings (character arrays), real numbers (float), or integers. Other descriptive characteristics (such as the features of the part) might actually be represented as other objects within the system, and pointers to these other objects are stored as members of our part object for directly linking these entities to our part. These types of relationships between objects are further defined in the discussion on hierarchy in Section 3.4. In abstraction, a system object is defined not only by the things it knows about itself (i.e., its internal state or characteristics), but also in terms of the things it can do (i.e., its operations or behaviors). Therefore, in programming terms, the objects of the system must encompass both the data concerning the object (the data members) and the functions which describe its behavior (the methods). The data members were defined above for our part object, but the functions which

f Data Members

class rotational_part

char Pa~_name[]; char Part_number[]; char Material_code[]; form_feature *if_pointers; float Overall_length;

Abstraction

float Max_diameter; float Surface_finish; void define_featuresO {;} void check_partO {;} void define_profilesO {;}

J

Methods

} %=_

Fig. 3. Abstraction of a rotational part.

Object-oriented design: a tutorial and review

785

the object must perform need to be included. These may comprise such functions as: defining the features, checking the validity of the defined part, and determining the machining profiles from the feature relationships. These functions are shown in Fig. 3 as the methods (also known as member functions): define_features(), check_part(), define_profilesO. So the object class, part, shown in Fig. 3, contains both data members representing the characteristics of the object and methods representing the behavior of the object. This demonstrates the second major element of object-oriented programming (OOP) known as encapsulation.

3.2. Encapsulation Unlike traditional programming approaches where the data structures of the system are defined separate from the functions that operate on the data, object-oriented systems combine the data and their related functions to form the object classes of the system. This binding of the data members with an associated set of procedures (called member functions) used to manipulate the data is referred to as encapsulation [7] (see Fig. 4). Once the abstraction of the system objects is completed, a developer can begin work on the implementation of this abstraction. When implementing an abstraction, in addition to determining a method of representing the data members and methods that characterize each object and its behavior, a developer must also define the visibility of each object to other client objects. This concept of visibility extends the definition of encapsulation to include "the process of hiding all of the details of an object that do not contribute to its essential characteristics" [1]. The idea is to create a system composed of objects that are available for use by client objects without requiring that the clients understand the details of the implementation of each object's data members and methods in order to use them. This is analogous to permitting a person (the client object) to drive a car (the server object) without having to understand all the details about what makes a car go (combustion engines, transmissions, etc.). This concept of limited visibility permits the development of a system where no part of the system is dependent upon the internal details of any other part. For example, if we were to change the engine used to propel the car, this would not affect the clients use of the object. Achieving this independence between objects is a fundamental requirement for the development of stable and maintainable complex software systems [8]. To implement the concept of visibility within encapsulation, each object must have two components: an interface and an implementation. The interface of an object class pertains to the outside view it offers to potential client objects concerning its attributes and behavior. This view encompasses what data members and methods are available for use, as well as, the exchange format

Object Attributes Name Size > Data Members Shape Material

bject Class

.

IData Members | Name / Size Miii~]t Functi°ns

Object Behavior Run Select >Member Function., Make Test

J

J

Fig. 4. Encapsulation.

J

786

John M. U s h e r

class rotational_part { // Data members: Private: form_features *ff_ptr[];// profile *prof_ptr[]; // int num of features; int num_of_profiles; float total length; // float max diameter; // float min_diameter; // Public: char part_name[]; // char part_number[]; char material_code[]; //

Pointers to form features Pointers to profiles Overall length of part Max diameter of all external features Min diameter of all internal features Description of part Code identifying the material

// Methods: Private: // Check for dimensional consistency int check_part(); // Sort features within each profile void sort(); void find_min_diameter( void findmax_diameter( Public: / / Constructor rotational_part(); / / Print part attributes void print(); void define features(); / / Define part features from geometry void define_profiles(); // Cluster features to form profiles

); Fig. 5. C + + class definition illustrating element visibility.

required for their use. The implementation of a class encompasses the data structures and functions constructed to produce the desired behavior of the class expressed by the methods. As an example of visibility consider the definition of the rotationalpart class shown in Fig. 5. In the C + + object-oriented language, the keyword public is used to denote the data members and methods that form the portion of the class interface that identifies the viable messages that can be sent to instances of this object class from other objects within the system. The private components of a class are not accessible by other objects and are reserved for internal use to support public functions. A third keyword, protected, can be used to define visibility relationships between classes and subclasses in an inheritance hierarchy (a topic discussed later). So, given the class definition of Fig. 5, values of the private data members total_length, max_diameter, and min_diameter cannot be read by any other object, but are available for use by the methods within the rotationalpart class. Therefore, the interface to the rotationalpart class will only permit client objects to issue the messages listed in Table 1. Since the implementation of the methods and the contents of the private data members are not visible or accessible to other objects, this hides the details of an object's implementation and creation. Also, the private methods listed within a class are bound to that class and cannot be used by objects of any other class (however, a means of sharing them is possible using the C + + friend declaration for certain methods). Objects created from the same class share the same behavior (methods), but each object will have its own distinct characteristics. This means that each time an object of a particular class is instantiated, a new set of data members is created for storing the attributes of the new object. So, if two instances of the rotational_part class were instantiated as part l and part_2, the C + + Table 1. Interface for rotational-part object class defined in Fig. 4 Message

Permits a client object to:

part_name part_number material_code print() rotational_part 0 define featuresO define_profilesO

request the name of the part request the part number of the part request the material code of the part request the printing of its attribute data create an instance a rotational part object request that the features which comprise the part be defined request part profiles be defined from the available features

Object-oriented design: a tutorial and review

787

messages that could be sent by a client object to retrieve and write out the names of each actual part would be expressed: cout (( part 1.part name (( part_2.part_name This allows each of the objects within the system to have its own identity but express a similar behavior. The result of using encapsulation in design is the creation of system classes which hide the details of the implementation of an object's behavior and offer an interface for access to the object. This element of the design produces software systems that permit program changes to be made with limited effort. The ability to change the representation of an abstraction without disturbing any of its client objects is a major benefit of encapsulation.

3.3. Modularity The third element of object-oriented design is modularity. This is the "property of a system that has been decomposed into a set of cohesive and loosely coupled* modules" [1]. In a programmed system, the modules are the separately compiled files. For large complex software systems, there will be many modules. The creation of modules is necessary in order to manage the complexity of the code. In the design phase, it is necessary that the contents of these modules be defined. For traditional structured design, modules arise from the grouping of subprograms, using the criteria of coupling and cohesion [1]. In object-oriented design, the decision becomes how to physically group object classes based on the design's logical structure. Therefore in object-oriented systems, the object classes form the logical structure and the abstractions of these classes implemented in the modules produce the physical architecture of the system. The goal of modularization is to produce a physical design that reduces costs through the structuring of modules that can be separately developed and maintained. If the contents of one module are not independent of the other modules, then changes to that module will require making changes to all the other affected modules and then recompiling each of these modules. This results in more effort and cost than is necessary for the maintenance of a system. Therefore, modularization supports the concept of creating a system that is maintainable, easy to extend, and contains reusable components (i.e., modules).

3. 4. Hierarchy The last major element of object-oriented design deals with the hierarchy that results from the ordering of the abstractions that are created in the process of modeling the system. The two types of hierarchies that result from this ordering are the composition ("part-of') and inheritance ("type-of') hierarchies. A composition hierarchy defines a structural relationship between object classes. One well-known example of a composition hierarchy is a product structure diagram (a.k.a. bill of materials). An abstraction of such a diagram could be expressed graphically as shown in Fig. 6 and textually (C + + code) as given in Fig. 7. This representation states that an end-product is composed of some combination of one or more components and other sub-assemblies. As shown in the code of Fig. 7, a composition hierarchy is implemented by embedding objects (such as component and assembly) within other objects. This method defines the relationship that the embedded objects are "part-of' another object. This definition matches our view of the structural relationships shown in Fig. 6. Recall that a class defines the abstraction of an object in terms of its attributes and behavior. If one object is related to another by the fact that they share common attributes and behavior, then a hierarchy can be created with the base class representing those common class elements and the derived classes defining those elements distinct to each object type. This results in an inheritance hierarchy where one or more derived classes inherit the characteristics and behavior of a base class while maintaining distinct characteristics and behaviors of itself within its own class. The derived classes are said to be objects that are a "type-of' the base class object. *Cohesiveness relates to the logical grouping of program units (be it subprograms or classes), and coupling refers to the dependencies between the modules created.

788

John M. Usher

. . .

Fig. 6. Composition hierarchy for product structure.

For example, it is possible to define a machined part in terms of an assembly of form features that comprise its volume. These features might include cylinders, cones, fillets, threads, chamfers, grooves, etc. Each of these distinct features are a "type-of' form feature. Therefore, by identifying all the attributes these features have in common, an inheritance hierarchy can be constructed consisting of the base classform_feature and the derived classes cylinder, cone,fillet, etc. (see Figs 8 and 9). The base class defines those data members and methods shared by all the different features. As shown in the code in Fig. 9, the cylinder class is defined as a derived class of the base class form_feature. Therefore, cylinder inherits all the public and protected* elements of the base class. These include fields such as location (external/internal), position, tolerances, and surface finish. In addition, the cylinder class modifies and complements the base class definitions by declaring the additional data members, length and diameter, and the additional method, define(). These fields and methods represent those elements that distinguish a cylinder from other types of form features. A fundamental step within process planning is that of selecting the operations to produce the part features. Therefore, in the definition of the form feature class above, the method select operationO was identified as a method common to all form features. However, the behavior, and therefore the implementation of this functionality, will not be the same for each feature type. Thus, it is necessary that this method be defined in each of the derived classes as well, representing the difference in the method of operation selection for each type of form feature (i.e., cylinder, cone, etc.).

class end_product { private: component *com_ptr; // Pointers to component parts assembly *asm_ptr; // Pointers to subassemblies char name[15]; int batch_size; int num_components; int num_subassemblies; void define(void); public: void process_planning(void); void assembly_planning(void); }; Fig. 7. C + + class definition illustrating a composition hierarchy. *Class elements defined as protected are only visible to the derived classes of the class defining those elements.

Object-oriented design: a tutorial and review

Cylinder ~)

I

Fillet .)

(

Cone

~

I

789

L Chamfer

( Groove

Radial "~

oovoj

(~ Axial "~

Fig. 8. Inheritance hierarchy for form features.

Note that the select_operationO function is a public method within the interface for the base class form_feature. Therefore, due to the inheritance of the base class methods by the derived classes, a user (i.e., client object) knows that it can send this message to any type of form feature and expect it to determine an operation appropriate for its production based on the current attribute values of that feature. For example, given that a series of form features have been defined within the rotational_part object using the form feature pointers ff_ptr[i], then when there is a need to select the operation for the second form feature a client object can issue the general message ff_ptr[2].select_operationO. The system then will determine at run-time the type of form feature (based on the pointer type) the client object is referring to and then call the appropriate method (for that type of form feature) from the specific class (i.e., cylinder, cone, etc.). This functionality of object-oriented programming is called polymorphism, meaning that a method of the same name is shared within an inheritance hierarchy, but the behavior is different within each class. Therefore, each object is able to respond to the same message in its own unique way. Polymorphism is "perhaps the most powerful feature of object-oriented programming languages next to their support for abstraction, and it is what distinguishes object-oriented programming from more traditional programming with abstract data types" [1]. With polymorphism it is possible for a client object to use the interface of the base type to access the derived types without knowing the specific details of the derived types. This results in a system that can be easily extended to add new derived types. Since the client objects make use of the base class interface, adding a new derived class is simply a matter of implementing the methods of the base class within the new derived class based on the desired behavior of the derived class. Since the client already knows how to use the base class methods, it can immediately make use of the new types. So, to add a new form feature (e.g., groove) to our process planning system, we would only need to create a new derived class under the form_feature class and implement those behaviors for the new class. Inheritance provides several additional advantages. First, the use of inheritance permits developers to build complex data types without repeating a lot of code. By making use of existing libraries of objects, a programmer can reuse code. If the attributes or behavior of an object from the library does not exactly match the programmers requirements, they can create a new object class that will inherit from an existing object class and then add the different characteristics and behaviors to the new derived class while maintaining the consistency of the base class interface.

790

John M. Usher

class form_feature { protected: char name[15]; char type[15]; // cone, fillet, chamfer . . . . char process[8]; char location[15]; // External or internal? float position; // Location dimensioning float pos_pos_tol; // & tolerancing float neg_pos_tol; float surface finish; // Overall finish geometric_tol g_tol[]; // Geometric tolerances char operation[][]; int num_operations; public: form_feature(); // Constructor char* select_process(); virtual void select_operation(); virtual void print(); }; class cylinder : public form_feature { private: float length; // Geometric dimensioning float pos_len_tol; // & tolerancing float neg len_tol; float diameter; float pos diam_tol; float neg_diam_tol; void define(); public: // Constructor cylinder(); void select_operation(); void print(); ]; class cone : public form_feature { private: // Geometric dimensioning float length; // & tolerancing float pos_len_tol; float neg_len_tol; float major_diameter; float pos_major diam_tol; float neg_major_diam_tol; float minor_diameter; float pos_minor_diam_tol; float neg_minor_diam_tol; void define(); public: cone(); // Constructor void select_operation(); void print(); ]; Fig. 9. C + + implementation of an inheritance hierarchy of part features.

This extensibility is possible with object-oriented languages since an object class encapsulates both the data members and methods in its definition. Another advantage of inheritance is that once the user interface is defined and working (as in the case of commercial object libraries or code from other projects), any changes to the object can be isolated to the newly created derived types. So, if any errors occur, it will be the result of the new code of the derived types that were recently created. Therefore, the use of hierarchies created from inheritance and composition permits the reuse of old code without introducing new bugs, and results in faster and more efficient programming and reductions in the cost of development [1, 5].

3.5. Summary Abstraction, encapsulation, modularity, and hierarchy represent the four principal elements of object-oriented design. These elements work synergistically to create a robust maintainable

Object-oriented design: a tutorial and review

791

software system. Some benefits of using the object-oriented approach over the traditional approach for the design of complex systems include [1]: object-oriented decomposition results in smaller systems, object-oriented systems are more flexible in terms of making changes and handling the evolution of the system over time, • object-oriented systems are designed to evolve incrementally from smaller systems making it easier to create and maintain larger and more complex systems, and • object-oriented decomposition results in reusable modules that can be applied to the development of other systems reducing future development efforts. It is these benefits that have given object-oriented techniques the attention they deserve.

•

•

4. APPLICABILITY OF AN OBJECT-ORIENTED DESIGN

Not all applications require the use of object-oriented design (OOD) techniques. The best applications for OOD are those complex systems that are likely to change over time. These qualifications account for a majority of the software programming projects performed in the industrial sector. Due to the drive to change business practices to remain competitive, and the fact that industrial processes are dynamic and constantly in flux (due to changes in parts, plans, operations, machinery, and technology), the application of OOD to manufacturing software development represents a viable means for the development of robust programs that can be affordably maintained. The types of applications where OOD is viewed as not being as worthwhile are those systems developed for one time use, without a need for long-term ongoing service. This type of programming is common for many engineers who write a program to solve a particular type of problem. However, if OOD and OOP were used to write these programs, then the objects resulting from these programs could probably be reused reducing the effort required for the development of similar systems in the future. Other areas where object-oriented programming is not applicable includes the development of low-level routines like device drivers where execution is time critical. Such routines are better developed using lower level languages (i.e., assembly) where the programmer has better control of the number of CPU cycles required to perform each function.

5. IMPLEMENTING AN OBJECT-ORIENTED DESIGN

One approach to the design of software systems using the object-oriented paradigm employs the following five steps [5]: 1. 2. 3. 4. 5.

object discovery object assembly system construction system extension object reuse

The first step in the process, object discovery, is concerned with determining the objects that can be used to represent the system and its operation. These objects represent the real-world objects of the system the developer is trying to model in the program. One source for identifying potential objects is from a written description of the system prepared by someone (i.e., project engineer, developer) who understands the intended workings of the system, its requirements and constraints, and the terminology involved. The nouns in this description represent possible objects (i.e., part, machine, tool, etc.) and the verbs represent the methods performed by those objects (i.e., select machine, sequence operations, etc.). A second method of identifying objects involves first creating a list of[5]: • the data elements that supply the information needed by the system, • the events to which the system must respond,

John M. U s h e r

792

Table 2. Partial list of data elements of a process planning system

Cylinder Identification number or name Location Dimensions (length, diameter) Surface finish Tolerances (location, dimensions, etc.) Operations Cone Identification number or name Location Dimensions (length, major-diameter, minor-diameter) Surface finish Tolerances (location, dimensions, etc.) Operations Groove Identification number or name Location Dimensions (width, depth) Surface finish Tolerances (location, dimensions, etc.) Operations

• the functionality required of the system, and • any obvious objects which are a part of the system (i.e., windows, lists, etc.). From this list, it is possible to identify and group related data elements into object types. Also, the general behavior of the system defined by the events must be supported by the identified objects. This behavior of the objects and the resulting system events must satisfy the functionality as defined in the list above. Using either, or both, of these two approaches provides a means for identifying a set of objects from which to begin coding. The definition of these objects and their behavior may change as the implementation progresses. While in the object discovery phase, the developer must be on the lookout for aspects of the system that are duplicated and/or reused by various objects within the system. These signs point out the possible need for object hierarchies (inheritance and composition, respectively). For example, consider the inheritance hierarchy presented previously for form features. Using a list of the data elements for each of the form features one can see that they share many common elements (Table 2). These common elements can be grouped to form a parent object class from which each specific form feature object inherits these attributes (Table 3). The major concern in this phase of the process is defining the gross objects within the system and their interaction. The details on the behavior of each object is not important at this stage of the development. It is also important that the objects do not become too complex. This complexity becomes evident when an object type is applied to a new situation. If it is difficult to use, this indicates that the object class is specific to a certain problem. When this occurs, it may indicate a need to break the object into multiple smaller objects making use of object hierarchies. For example, if we were to try and create a single object class to recognize all possible features, then this object class would contain too many data members and special case methods for such functions Table 3. Recognized inheritance hierarchy for form features

Form-feature Identification number/name Location Surface finish Tolerances --location --dimensions ---etc. Operation

I

Cylinder Dimensions --length ----diameter

I Taper Dimensions --length --major-diameter --minor-diameter

I

Groove Dimensions --width --depth

Object-oriented design: a tutorial and review

793

as operation selection. This complexity would be reduced if an inheritance hierarchy composed of several object classes were created as shown in Table 3. The next phase, object assembly, involves the development of the details of the object types. One means for identifying the additional data members and functions needed in an object class is to develop test programs for each object type created [5]. Once the creation of the individual objects and their methods is complete, the third phase in the development project is begun. In this phase, the overall system is constructed based on the stated design requirements. At this time in the development of the program, the need for additional object types and new functionality of the existing objects may become apparent. Usually by the time the first completed system is put into use, it is time to begin evaluating the design and ensuring that the system sufficiently solves the problem and meets the needs of the user. Due to the dynamic nature of systems in the manufacturing environment, the system or specific details about the system might have changed during the software development cycle. It is at this time, and also during later updates, that a system goes through the extension phase of development. During this phase, the initial design is tested in terms of robustness of the object types and their implementation. If extensions (adding methods) and modifications (changing an object's behavior) to the system are simple, then the initial object design was successful. However, difficulty in extending and modifying the system indicates that object definitions might have been too specific or complex to permit their reuse or extension. Also, if changing the behavior of an object affects other parts of the system, then the modularity (providing independence) of the object classes was not supported by the initial design. All is not lost though, since it is at this time that developers can realize the problems and redesign the objects to better reflect current and possible future needs. The result is an improved design capable of supporting changes in the future. The last phase, object reuse, occurs both when developing new systems or extending currently implemented systems. The reuse of existing object classes in new programs further tests the robustness of the object classes and demonstrates the usefulness of OOD by reducing the energy required in new development efforts. The collection of object libraries that a company accumulates represents resources available for use in future development efforts. One major difference in the implementation of object-oriented programs using OOD, as compared with procedural programs based on structured design, is that the developer does not have to completely understand the problem before coding begins. In fact, object-oriented design and object-oriented languages support the concept and provide the mechanisms that let a system's objects grow as the developer's understanding of the system and its operation grows. As Entsminger [5] states, the development effort in OOD is analogous to the idea of "growing" your objects from the time you begin thinking about them on through to their maturity as you continue to reuse them. 6. OBJECT-ORIENTED DESIGN IN MANUFACTURING

In the last few years, object oriented design has been applied to many areas of manufacturing software development. The discussion which follows will briefly outline a sample of these systems focusing on the areas: product modeling and design, process planning, manufacturing system modeling and simulation, planning and control, and manufacturing databases. 6. I. Product modeling and design

Product modeling and design have become popular applications for object-oriented design and programming [9-15]. The object-oriented paradigm represents an intuitive means of specifying a product model in terms of a set of object classes that permit the use of inheritance and composition to represent the true hierarchy of information concerning a product and its components. One example is the object-oriented product model developed by Zhang et al. [12]. Their model classifies the information required to model a product into a hierarchy composed of six object classes: product, subassembly, part, CSG tree, solid, and feature. In designing their system, they were concerned with the completeness of the information, that the data and knowledge be encapsulated, and that the data be accessible to the different applications within each of the departments of the business enterprise. Each object class contains general information on the

794

John M. Usher

properties of the object, a description of the components of the object, and its relationship to other objects. The authors illustrate the use of their product model in an application of the system to process planning. LeBlanc and Fadel [13] investigated the use of an object-oriented paradigm for the development of a product model. However, their interests lie in the use of this model in the engineering analysis phase of the design process. Using OOP as an alternative means for data representation they explored the data decomposition techniques for providing different views of the design based on the perspective of the user within the various departments of a manufacturing enterprise. At Babcock & Wilcox, an automated mechanical design system is used in the design of boiler products [14]. This system takes input from a user concerning a design and performs the needed calculations to arrive at the design parameters required to satisfy the constraints and criteria of the design. This process simplifies the design task, but is unable to handle designs that deviate too far from the norm. Such designs require that a programmer make changes to the design software adding both cost and time to the product cycle. To overcome this problem, Meerbaum et al. [14] made use of object-oriented programming to develop an "Object-Centered Modeling System" that operates like a spreadsheet. This system takes advantage of the object-oriented paradigm, making use of properties such as inheritance and the capability to easily extend the system through the creation of new object types. The new system then allows the designer to reconfignre the product, modify the design rules, and override the results without the need for a programmer. This approach results in both time and cost savings in the design process. An important phase in product/process design is the conceptual design phase. Kusiak et al. [15] use an object-oriented approach for the development of a system that supports conceptual design. The authors selected the object-oriented paradigm for implementing the system because they believe it simulates the way in which a designer thinks during the conceptual design phase of product development. Their system implements a modeling mechanism for conceptual design where, based on the designers definition of the requirements and functionality, the system applies production rules to guide the synthesis of the design [15]. Coinciding with product modeling is the use of an object-oriented approach for the identification and classification of machinable part features. Hummel [16] makes use of an object hierarchy to represent the taxonomy of form features for machined parts. This taxonomy illustrates the relationship between features and permits the assignment of procedural algorithms to a corresponding class for use by objects of that class and all subclasses that inherit from that class. This results in a modular system that is easy to modify and extend for use in various manufacturing systems such as process planning systems. 6.2. Process planning

The application of the object-oriented paradigm to process planning is a logical means for representing the real-world components within a manufacturing system. The use of this approach in the development of computer-aided process planning (CAPP) systems is reported in the literature for several systems of varying application. In terms of specific applications, Lee et al. [17] develop a system that combines OOP and rule-base techniques for planning the manufacture of progressive dies. Their use of objects seems to focus mainly on its benefits as an improved data structure with no discussion of the functions (methods) defined within the object classes. Srinivasan et al. [18] discusses the use of an object-oriented approach for the design and development of a process planning system for electronic assemblies. They also developed two other non-OOP systems for the same application each making use of a different knowledge-based approach to inferencing: forward chaining and backward chaining. Based on their comparison, they found that objects are a more suitable means of representing the diversified knowledge in a CAPP system, and that the object-oriented system solves the problem more efficiently. At an abstract level, Sheu and Kashyap [19, 20] propose an object-oriented data model as the basis for the development of a framework of object-oriented knowledge bases to represent parts and process operators for use in planning. Likewise, Krause et al. [21] discusses the proposed use of objects for representing features in part design and using a rule-based approach to transform

Object-oriented design: a tutorial and review

795

these design features into manufacturing features for use in planning. The authors briefly mention the use of objects for representing processes and operations, but provide no examples or discussion of other objects or the relationships between objects. Sanii and Davis [22] present an object-oriented planner (DiCAPP) whose planning functions are distributed in a hierarchical fashion based on the time-horizon of their applicability. The DiCAPP system focuses on prismatic parts and makes use of objects for representing part features, fixtures, machines, operations, and tools. However, no details are provided concerning the structure of these classes. Also, when describing a part for planning, tolerancing appears to be absent from consideration. Feghhi et al. [23], employ an object-oriented approach to the design and implementation of a system for part design and process planning. Using the Smalltalk language, objects are used in the definition of class hierarchies for part features and manufacturing processes. A process plan is generated through the examination of rules using backward chaining to reason from the finished part state to the raw material state. This same system was then extended to integrate the design, planning, and inspection functions for prismatic parts [24]. However, in place of the rule-based approach, case-based reasoning is used for planning. This approach makes use of past planning experiences to plan for new parts. The major thrust of these reported studies appears to be on their use of objects as an improved data structure. Usher [25] expands on this premise through the development of a planning system whose object-oriented design and implementation more fully utilizes the capabilities of the OOP paradigm focusing on both the definition and interaction of the system objects. The methods used for implementing the planning functions differs from other strategies making better use of encapsulation and polymorphism. This results in more efficient use of the process knowledge in planning. 6.3. Manufacturing systems modeling and simulation

As in product modeling, the abstraction of the real-world components that comprise a manufacturing system into object classes represents a robust method for modeling these systems for use in design, analysis, and simulation. Examples of such systems are outlined below. Modeling integrated manufacturing systems is a complex task. In Mize et al. [26], an approach for the modeling of CIM systems using object-oriented techniques is presented. Use of this approach provides improvements over traditional modeling methods due to the advantages of OOD mentioned earlier. The authors designate a model definition as composed of three types of object classes: physical objects, information objects, and control/decision objects. This separation of the system objects "allows the system modeler to think of these elements independently during model development.., providing a more natural modeling environment" [26]. The definition of a product model would require that a user declare specific system objects based on three different object class types provided. These primitive object classes are stored in system libraries and can be extended to produce new refined primitive objects that better represent a company's needs. Gaafar and Bedworth [27] introduce the object-oriented paradigm as a fertile means for the development of a unified manufacturing model. They propose the use of a single model to represent the entire manufacturing system. Such a model provides a framework for the development of the system objects needed to address the specific activities that take place within the overall system. This permits a developer to add functionality to the overall system incrementally as the system evolves and matures. They demonstrate their approach through the development of a process planning system which is extended to incorporate a design component. In addition to modeling, the use of the object-oriented paradigm has become a popular basis for the development of simulation languages. SmartSim is one such simulation environment designed to be used by manufacturing engineers as a tool to aid in the design of manufacturing systems [28]. As opposed to other simulation languages, SmartSim's design aims at reducing the complexity of constructing a simulation model. The system makes use of object classes to represent the various entities within the manufacturing environment (i.e., part, workstation, conveyor, etc.). The characteristics of the real-world instances of these object classes are recorded in the data members of the objects for use in the simulation. If the characteristics of an object to be modeled do not quite fit those of a defined class, then the

796

John M. Usher

user is able to create a new subclass that refines the behavior of its parent object overriding the necessary data members and methods of its parent. A model is constructed interactively using a menu driven system where the user selects the objects (represented by icons) which represent the system elements. These elements are arranged on the screen defining the routing of entities through the system. Animation and statistical analysis are available for use in verification of the resulting model. SmartSim, represents only one approach to the use of objects in simulation. Thomasma et al. presents a brief survey of several object-based simulation languages [29]. 6.4. Planning and control

Systems development related to planning and control has found object-oriented applications in the manufacturing-related areas of management planning [30], quality planning [31], production planning [32], scheduling [33], and control [34, 35]. The integrated management planning system (OBJIMPS) developed by Norrie et al., incorporates process planning, cell grouping, scheduling, and simulation in a single user interactive system [30]. The implementation of OBJIMPS makes use of object classes to represent the physical objects addressed by the system as well as the management objects used for supervision planning. Based on the user's commands, the system operates by passing messages between client objects requesting the completion of specific tasks required to reach the desired goal. The knowledge used to perform these tasks is encapsulated within the objects themselves. Therefore, embedded within each object class are the facts and rules pertaining to that object. In essence, each system object has its own embedded expert system providing a highly specialized knowledge source with the ability to make use of this knowledge internally and share it as needed. Also, the objects within an inheritance hierarchy will be able to make use of the knowledge embedded in parent objects of that hierarchy. This approach to embedding planning knowledge directly within each object is shared by Usher [25] in the development the process planning system, IOOPP. In the area of quality management, Bird [31] proposes the use of an object-oriented expert system to take a proactive stand on manufacturing quality management. The author has developed an expert system using an object-based architecture that is to be used for implementing quality management methods such as quality function deployment (QFD) and quality planning. Using this approach, the proposed systems aim to reduce the complexity in applying these quality management methods by transferring the knowledge from the human to the computer. Implementation of these methods requires the use of multiple knowledge bases which are easily integrated when using the object-based architecture [31]. Also, Bird states that since the resulting systems are object-based, it is possible for them to be incorporated directly into larger object-based distributed manufacturing systems. The development of a control architecture for manufacturing cells is proposed by Lee and Sen [34]. They make use of an object-oriented approach in the design of a two-layer cell control architecture whose tasks include: scheduling jobs, machines and other resources, monitoring job progress and resource utilization, and detecting and reacting to process abnormalities. The control architecture is composed of two layers. The inner layer, termed the intelligent cell object, contains the generic cell control knowledge needed to supervise a cell. The purpose of this layer is to provide a cell-independent knowledge core that can be used in the control of any cell within the manufacturing facility. Therefore, any changes in these routines can easily be transmitted to all cells for immediate system-wide update. The intelligent support shell makes up the outer layer bearing the identity of a particular cell, its constituents, capabilities, and limitations. This includes the cell specific databases, control knowledge, and communication routines. Both layers are implemented using object hierarchies making use of inheritance. The authors point out that their use of objects provides a unified, consistent, and efficient method for representing knowledge for manufacturing control. In the area of machine control, Kramer experimented with the use of software objects to generate NC programs [35]. His prototype system represents possible common cutting geometries as objects. Each of these objects specifies the requirements in terms of NC code to generate their shape. Use

Object-oriented design: a tutorial and review

797

of his system involves a user selecting the objects and placing them on a blank representing the removal of material volumes by machining. Once the final geometry is defined, the NC code is generated based on the code fragments aggregated from each individual object. 6.5. Manufacturing databases

Some believe that current data base management systems based on network, hierarchical, and relational structures lack the capability to handle the complex requirements imposed by a computer integrated manufacturing system [36]. To address this weakness some researchers have begun exploring the application of object-oriented databases to the manufacturing domain [36-38]. Ahluwalia and Ping [36] explore the use of an object-oriented data model to support the development of a manufacturing data base. Their system focuses on providing a mechanism for representing data concerning the part, operations, facilities (machine tools, cutting tools, fixtures, etc.), and machinability. Chung and Fischer illustrate the application of an object-oriented database system, ORION, to the manufacturing domain by focusing on its use for the management of a bill of materials (BOM) [38]. Composite hierarchies are used to implement the bill of material encapsulating methods for such tasks as displaying the component data, changing a part's attributes as well as, adding and deleting parts from the BOM structure. Other functions associated with these classes include those which make use of the data for the purpose of carrying out calculations used in material requirements planning and inventory control. 6.6. S u m m a r y

In addition to those applications discussed above, a wide variety of additional applications can be found in [39]. These applications include such areas as concurrent engineering, computer-aided design, robotics, and flexible manufacturing. The variety of these applications indicates the widespread interest in the use of the object-oriented paradigm in the many areas relating to manufacturing. These systems represent only the beginning of what will be a strong presence of OOD and OOP in the development of manufacturing software systems. 7. CONCLUSIONS The object-oriented approach to software design represents an improved method for the design and programming of software systems. Due to the complex and dynamic nature of manufacturing applications, the advantages offered by the object-oriented paradigm results in a software design that will serve the needs of the current process and be adaptable to changes in the future. If manufacturers in the future are to create and integrate autonomous manufacturing systems, then the use of object-oriented design techniques and object-oriented programming languages represents a crucial element to the success of their effort. Editor's Note--This article serves as a tutorial for those who would like to understand the focus of the object_oriented paradigm in comparison with traditional program design and its effectivenesson potential software projects.

REFERENCES 1. 2. 3. 4. 5. 6. 7.

G. Booch. Object-Oriented Design with Applications. Benjamin/Cummings(1991). S. Cummings.Gearing up for the object-oriented express. Corporate Computing, 285-287 (1992). A. V. Aho, J. E. Hopcroftand J. D. Ullman. Data Structures and Algorithms. Addison-Wesley,Reading,MA (1983). E. Glinert. Introduction to Computer Science Using Pascal. Prentice-Hall,New York (1983). G. Entaminger. The Tao of Objects. M&T Books (1990). M. Shaw. Abstraction techniquesin modern programminglanguages. IEEE Software 1, 10 (1984). R. S. Wienerand L. J. Pinson.An Introduction to Object-Oriented Programming and C + +. Addison-Wesley,Reading, MA (1988). 8. D. Ingalh. The Smalltalk-76 Programming System Design and Implementation. Proc. of the Fifth Annual ACM Symposium on Principles of Programming Languages, ACM, pp. 9-13 (1978). 9. T. Muamfa.An objectorientedapproach to the designand configurationof manufacturingdata/knowledgebase. Proc. of lnt. Conf. on Object-Oriented Manufacturing Systems, pp. 104-109 (1992). 10. J. M. Usher. An object-orientedapproach to product modeling. Computers Ind. Engng 25, 557-560 (1993). 11. S. Imamura, T. Kojima, H. Sckiguchiand K. Inoue. A study on the object oriented product model--representation of geometry and dimension. Ann. CIRP 37, 127-130 (1988).

798

John M. Usher

12. Y. Zhang, P. Gu and D. H. Norrie. Object-oriented product model for integrated manufacturing. Proc. oflnt. Conf. on Object-Oriented Manufacturing Systems pp. 90-97 (1992). 13. A. R. LeBlanc and G. M. Fadel. Design data storage and extraction using objects. Concurrent Engng. Res. Appl. 1, 31-38 (1993). 14. M.I. Meerbaum, T. J. Capozzi and F. Agnilar. Object-oriented programming for flexible, automated mechanical design. Proc. of the 1987 ASME Int. Computers in Engineering Conf., Vol. l, pp. 137-141 (1987). 15. A. Kusiak, E. Szczerbicki and R. Vujosevic. Intelligent design synthesis: an object-oriented approach. Int. J. Prod. Res. 29, 1291-1308 (1991). 16. K. E. Hummel. Coupling rule-based and object-oriented programming for the classification of machine features. Proc. of the (1989) ASME Int. Computers in Eng. Conf., Vol. 1, pp. 409-418 (1989). 17. I. B. H. Lee, B. S. t i m and A. Y. C. Nee. Knowledge-based process planning systems for the manufacture of progressive dies. Int. J. Prod. Res. 31, 251-278 (1993). 18. K. Srinivasan and E. T. Sanii. AI-based process planning for electronic assembly, l i e Trans. 23, 127-137 (1991). 19. P. Sheu and R. L. Kashyap. Object-based process planning in automatic manufacturing environments. Proc. Int. Conf. on Robotics and Automation. 435-550 (1987). 20. P. Sheu and R. L. Kashyap. Object-based knowledge bases in automatic manufacturing environments. Int. J. Adv. Manufacturing Technol. 3, 39-52 (1988). 21. F.-L. Krause, A. Ulbrich and F. H. Vosgerau. Featured based approach for the integration of design and process planning systems. Product Modeling for Computer-Aided Design and Manufacturing (Edited by Turner et al.), pp. 285-298. Elsevier, Amsterdam (1991). 22. E. Sanii and R. Davis. CAPP in a hierarchically controlled manufacturing environment. Intelligent Manufacturing Structure, Control, and Integration, Fol I of Proceedings of Manufacturing International 90. ASME (1990). 23. S. J. Feghhi, M. Marefat and R. L. Kashyap. An object-oriented kernel for an integrated design and process planning system. 27th ACM/IEEE Design Automation Conf., 437--443 (1990). 24. M. Marefat. Object-oriented intelligent computer-integrated design, process planning, and inspection. Computer 26, 54--65 (1993). 25. J. M. Usher. An object-orientedapproach to feature-based process planning. Design and Implementation oflntelligent Manufacturing Systems (Edited by M. Jamshidi and H. Parsaei), Prentice-Hall, New York (1995). 26. J. H. Mize, H. C. Bhuskute, D. B. Pratt and M. Kamath. Modeling of integrated manufacturing systems using an object-oriented approach, liE Trans. 24, 14-26 (1992). 27. I. Gaafar and D. D. l~'dworth. Manufacturing integration using the object-oriented methodology. 2nd Industrial Engineering Research Conf. Proc., 817--821 (1993). 28. O. M. Ulgen and T. Thomasma. SmartSim: an object-oriented simulation program generator for manufacturing systems. Int. J, Prod. Res. 28, 1713-1730 (1990). 29. T. Thomasma, Y. Mao and O. M. Ulgen. Manufacturing simulation in smalltalk. Proc. of (1990) Western Simulation Multicanference, SCS, 93-97 (1990). 30. D. H. Norrie, O. R. Fauvel and B. R. Graines. Object-oriented management planning systems for advanced manufacturing, Int. J. Computer Integrated Manufacturing 3, 373-378 (1990). 31. S. Bird. Object-oriented expert system architectures for manufacturing quality management. J. Manufacturing Systems 11, 50-60 (1992). 32. H. Ulrich and W. Durig. Object-oriented realization of planning tools for production planning and control. Proc. of the Int. Conf. on Object-Oriented Manufacturing Systems, 158-167 (1992). 33. M. Orel and C. James. The intelligent scheduling and planning system (ISAPS). Prac. of the Int. Conf. on Object-Oriented Manufacturing Systems, 352-357 (1992). 34. K. H. Lee and S. Sen. A two-layer object-oriented approach for intelligent manufacturing cell control. Proc. of the 2nd Industrial Engineering Res. Conf., 212-216 (1993). 35. W. Kramer. Object-oriented NC programming with CAD/CAM. Proc. of AutoFact, 24/1-24/8 (1989). 36. R. S. Ahluwalia and J. Ping. Manufacturing knowledge representation using an object oriented data model. Proc. of the CAD~CAM Robotics and Factories of the Future '90, Vol. 1: Concurrent Engineering (Edited by S. N. Dwivedi et al.), pp. 130-135 (1990). 37. S. Y. Su. An objeet-oriented semantic association model (OSAM*). Artificial Intelligence: Manufacturing Theory and Practice (Edited by S. T. Kumara et al.), pp. 463-494 (1989). 38. Chung, Y. and G. W. Fischer. Illustration of objeet-oriented databases for the structure of a bill of materials. Computers in Industry 19, 257-270 (1992). 39. Proc. of lnt. Conf. on Object-Oriented Manufacturing Systems (1992).