object-oriented software modeling of a flexible manufacturing system

Journal oj Intelligent and Robotic Systems 3: 147-165, 1990. 147 ~' {990 Kluwer Academic Publishers. Printed in the Netherlands'.

Object-Oriented Software Modeling of a Flexible Manufacturing System

SADASHIV ADIGA and MILIND G A D R E Department o] lndustrial Engineering and Operations Research, Universi O' o/' Calflbrnia at Berkeley, Berkeley, CA 94720, U.S.A.

(Received: 24 January 1989; revised: 4 September [989)

Abstract. Flexible Manufacturing Systems play an important role in improving our manufacturing productivity. Simulation is emerging as a popular tool in modeling FMS for analyzing its performance in the area of production planning/scheduling. In this paper, we illustrate how to model a Flexible Manu- facturing System in the object-oriented paradigm using an example. We present a systemtic approach to the design of object-oriented programming systems based on a combination of data modeling and event analysis techniques.

An entity relationship approach is used as the basis for an initial decomposition of the system into objecls. The design is refined by an analysis of the events the objects participate in, The design is implemented in Objective-C. Finally~ we describe ways in which this model of an FMS can be extended to explore popular research questions in production planning and scheduling.

Key words. Object-oriented design, entity-relationship approach, object-oriented programming, conceptual design, flexible manufacturing systems, discrete event simulation.

1. Introduction

The Flexible Manufacturing System (FMS) is an integral part of the revolution in

automated production. As noted by Suri and Whitney (1984), in most FMSs the

production capacity is under utilized, largely due to the complex nature of the system

and difficulty of shop-floor supervisors to predict its behavior. This often leads to

poor resource-allocation decisions and unintentional part-mixes which create

resource contention problems (Young and Rossi, 1988). Hence the topic of produc-

tion planning and scheduling has attracted much attention from the industrial

engineering and operation research communities. Analytical and simulation models

are among the common research tools used to analyze the problems.

Analytical models represent the quantities and relationships as mathematical vari-

ables and expressions. These are then mathematically manipulated to obtain the

desired performance. Simulation models take the same input data as the real system

and transform them into output similar to that produced by the real system. It is

accomplished by explicitly representing the time series of events which determine the

behavior of the system. Most modern manufacturing systems are too complex to

allow realistic models to be evaluated mathematically and these models have to be

studied by means of simulation (Law, 1986). Limitations of analytical models in

148 SADASHIV ADIGA AND MILIND GADRE

solving problems in production scheduling are discussed by McKay et al. (1988). A simulation model enables detailed representation of the characteristics of an FMS such as machine behavior, job routing, control and dispatching rules etc. Hence, the predictions of performance made by such models are potentially very accurate

(Buzacott, 1985). Software modeling is a key activity in building simulation models. In this paper, we

shall describe an approach to model a typical FMS in the object oriented paradigm. OOP is considered one of the most promising software technologies today by many professionals in AI and software engineering (Ramamoorthy and Sheu, 1988). OOP allows one to model systems such as an FMS with much accuracy and flexibility. Here, our emphasis will be on the modeling methodology and its translation into software using OOP. The FMS chosen is relatively simple in nature but has the

essential components to illustrate important concepts. We shall demonstrate how to identify the objects and their functional specifications from the description of the FMS and related assumptions. Finally, we shall show a software implementation of a few objects based on the derived specifications.

2. Object Oriented Programming (OOP)

In this section, we briefly review some of the important concepts in OOP. Object- Oriented Programming Systems (OOPS) view the world as a collection of discrete objects which act and react in a common environment by exchanging messages. Some of the features of current OOPS were also seen in early simulation systems such as

SIMULA (Dahl and Nygaard, 1966) and Artificial Intelligence systems that used frames (Minsky, 1975). But many of the current implementations are based on the concepts made popular by the programming environment Smalltalk (Goldberg and

Robson, 1983). For a more detailed discussion on OOP, readers may refer to Gold- berg and Robson (1983), Cox (1987) or Pascoe (1986).

Objects and Classes: An object is a bundle of data along with procedures to access

and modify that data. A key point is that the data is private to the object and can be manipulated only via the procedures that are provided as part of the object. The data are stored in instance variables and the procedures are called methods. Instance

variables can be pointers to other objects. Each object is an instance of its respective class. A class is a means of defining an object in terms of its abstract type. 'Class' is a static concept, an element of program text (Meyer, 1988, p. 94). 'Object' is a dynamic concept which occupies space in computer memory. A software object can represent either a physical or a conceptual object.

Inheritance is a powerful concept. Classes are organized into hierarchies in which a class that is subordinate to another automatically inherits all its superior's instance variables and methods. A class may be subordinate to more than one class and a class may have more than one subclass. The objects that are instances of a subclass recognize all the messages and instance variables of their superclass as well as new ones. For example, the class 'Benz' is a subclass of class 'automobile'. It inherits

OBJECT-ORIENTED SOFTWARE MODELING OF AN FMS 149

properties such as wheels, transmission, and so on. In addition, it has its own properties such as diesel-engine, etc. This concept permits the addition of complexity and functionality to simple objects as neccessary by creating and main- taining subclasses of existing object classes. It also minimizes data specification and redundancy.

Messages are the sole means for the objects to communicate with each other. A message to an object only requests the execution of a procedure not the procedure for execution. A message invokes a method (i.e. a procedure) in the receiving object to produce required behavior. Implementation of the method is a prerogative of the object receiving the message.

Use of the object-oriented paradigm has the potential for many unique advantages not available through other options. Some of them are listed below:

(a) Representing machines, workers, parts etc. as individual objects allows a natural one to one correspondence between real-life objects and software objects. It makes the software conceptually simpler to understand.

(b) The concept of classes allows us to represent interactions in multiple levels of abstractions. For example, this should potentially allow us to perform simulation of, say, an entire factory or a manufacturing cell in the factory with relative ease.

(c) Simulation of complete systems leads to large-scale software development. Object-oriented approach has the potential to reduce life-cycle costs through reusability of software objects, better maintainability and extendibility (Meyer, 1987).

(d) Different objects can accept the same message but respond differently. This concept is called polymorphism. It allows to associate the objects that experi- ence a similar event such as the end of production etc. through the same message.

3. Flexible Manufacturing System (FMS)

An FMS is an integrated system of production equipment or workstations linked together by automated material handling systems, and computer control. An FMS is capable of producing a variety of discrete parts with minimal human intervention. While the workstations are usually CNC machines, they may be any equipment for fabrication, assembly or treatment of materials. Examples are machine tools, washing, heat treating machines, grinding, sheet metal working, plastics handling, assembly, and inspection tools.

Because of the use of automated equipment, setup times are small and transpor- tation times between machines are negligible. Its ability to sequence parts randomly and respond quickly to changes in demand allows an FMS to fill the gap between transfer lines and job shops. FMSs are essentially useful for batch processing. Use of an FMS may lead to many benefits. While these have been discussed in other sources

150

Finished Parts t

SADASHIV ADIGA AND MILIND GADRE

Raw Materials

(D

Fig. I. A simple FMS.

(Talavage and Hannam, 1988), two improvements from a production perspective are:

(a) reduction in work in process (WIP) and the inventory of finished parts

(b) reduction in the economic order quantity (EQQ) the parts produced.

Planning for these improvements often involves software design in the form of simulation or a software implementation. In the following sections we shall discuss how to apply OOP concepts to represent an FMS to help one analyze it from a production

scheduler's perspective. Figure 1 shows a typical FMS. Through OOP concepts can be applied to model

very complex systems, a relatively simple FMS is chosen to highlight the modeling methodology without the overhead of the complexity of the example. The FMS consists of six machines linked by an Automated Guided Vehicle (AGV). Each machine will have an associated queue of parts awaiting processing. The parts are classified using a group technology (GT) system (Kusiak, 1985; Ham et al., 1985). The parts in queue are first sorted by group. Within a group the parts are sorted by their individual part numbers. This leads to a nested queue structure. Supply of raw material is not considered as a constraint, and all parts start with the same raw casting. Tools are not considered scarce resources and tool failures are not considered. Similarly, machine failures are not considered. As a result, the possible states a machine can be in are: 'Busy', 'Idle' and 'InSetup'. Parts follow a 'RouteSheet'. Routsheets describe the sequence of operations and the machines on which the operations are to be carried for the respective parts.

OBJECT-ORIENTED SOFTWARE MODELING OF AN FMS 15 l

4. Designing Object Oriented Software Systems

The process of decomposing a system into objects based on data and communication requirements of the objects has come to be known as object-oriented design. Meyer (1987) defines object-oriented design as a technique which, unlike classical (functional) design, bases the modular decomposition of a software system on the classes of objects the system manipulates not on the functions the system performs. The focus on data encapsulation in objects rules out utility of functional decomposition approaches such as SADT (Ross, 1977). Inadequacy of the functional decomposition approaches to specify object-oriented systems is discussed in detail by Booch (1986) and Meyer (1988).

A heuristic procedure was suggested by Booch (1983). The procedure is to construct a list of key nouns and noun phrases from the original textual statement of requirements. While this may serve as an initial set to start with, it may be affected by the noise created by the inevitable existence of nouns that may be completely irrelevant to the actual entities required. It also does not address the issue of relationships between objects. Though identification of class objects is an important activity in object-oriented design, we also need to identify the data elements and the relevant procedures that reflect the nature of the object.

Useful simulation models of manufacturing systems have to represent and manipu- late large amounts of data. This led us to investigate data-drive approach to help us capture all the data completely in a non-redundant manner. Since we did not want to reinvent the methodologies, we selected the Entity-Relationship (ER) approach to data modeling (Chen, 1976) as the starting point in our design.

ER modeling is a popular approach for representing conceptual design in data base systems. It is described in almost all of the popular text books on the design of data base systems. In addition to the focus on entities in the system and their attributes, it also allows us to capture the interrelationships resulting in a schema. But an ER model has to be analyzed with special attention to map it to an object framework. Also, it has to be supplemented with a mechanism to capture the time- dependent and sequential communication through the exchange of messages that takes place in a dynamic system such as an FMS. Hence, we suggest the following methodology:

The methodology consists of the following steps:

Step 1: Study user views and requirements and use the Entity-Relationship (ER) approach (Chen, 1976; Hawryszkiewycz, 1984) to model the system.

Step 2: Identify objects and their instance variables from the ER diagram. Step 3: Identify important or key events in which the objects participate and draw

message flow diagrams (MFDs) (Glassy and Adiga, 1989) for each event. Step 4: Use MFDs to identify the interactions between objects and message sequences.

More objects and instance variables may be identified, some may be dis- carded, and some may be merged. Make a complete list of all the required objects, instance variables, messages and methods and compile lists of functional specifications for the objects and their interactions.


Step 5: Implement the derived specifications in an object oriented computer programming language of one's choice.

It is important to note that Steps 1 through 4 may have to be followed iteratively to

refine the design to an acceptable level.

5. Mocleling the FMS

We will follow the five steps outlined above to model the FMS shown in Figure I. The related assumptions have been explained earlier.

Step 1: ER Diagram The Entity-Relationship (ER) model was first introduced by Chen (1976). The ER approach is well suited for modeling the nature of entities and the basic associations among entities. However, it cannot capture dynamic inter-relationships. For the modeling of dynamic relationships between entities and objects we have to resort to the message flow diagrams (shown later). Some of the important concepts of ER are given below (Hawryszkiewycz, 1984; Potter and Trueblood, 1988):

entities:

relationships:

attributes:

entity sets:

Distinct (physical) objects within a user enterprise or an event about

which information is to be stored. Meaningful interactions between the entities. Represented by a

diamond in ER. Describe the entities and]or the relationships between them. The stored information is viewed as a collection of values for the attributes. Entities with the same attributes fall into the same entity set. Rep-

resented by rectangles in ER.

Consider one of the machines in the FMS. It is a physical object and is a candidate for representation as an entity. The information that is associated with any machine is (following our description and assumptions): the name of the machine, the group it is setup for and the state it is in (whether 'BUSY', ' IDLE' or ' INSETUP') . Hence, for each combination of the three values we will have a distinct machine. Any of these machines is an entity. All such machines can be grouped into an entity set called 'Machine' which has the attributes: name, setupGroup, and state. Similarly, we can have another entity set called 'Part ' with its own attributes: idNumber and state. Each Part is associated with a 'Route sheet' which lists the sequence of machines the part has to visit and the time it will spend at each machine. The set of route sheets map into an entity set 'RouteSheet'. The relationship between part and Routesheets can be represented in the ER approach by the descriptor 'Follows'. Similarly each Part

'Belongs To' a Group. Following the description of the FMS presented above and the related assump-

tions, an ER model of the system is shown in Figure 2. Now we can move on

to Step 2.


Fig. 2. ER model of our FMS.

Step 2." Identify Objects and Instance Variables form ER Diagram It is important to consider the entities as abstract but meaningful 'things' that exist in the user enterprise. Another point to remember is that only those relationships that

have attributes can be considered candidates to be mapped into objects. These concepts will become clear with the following examples. In our methodology, physical objects, events and relationships are candidates for mapping into software objects. The attributes are transformed directly into instance variables. While a one-one relationship between physical and software objects can be visualized immediately, the mapping of events or relationships to software objects is usually not so straight-

forward. It may be influenced by the user's view of the system. This, however, is a characteristic of the ER approach itself (Hawryszkiewycz, 1984). We find that distinct entity sets map directly into distinct object classes. The objects (instances of the class) represent the entities. For example the entity set 'Machine' maps into an object class 'Machine'. A specific machine with properties: name = 'CNC_Lathe', setup- Group = aGroup; state = ' IDLE' is an entity and will be represented by an instance of class 'Machine'.


If we are performing discrete event simulation with 'next event time advance' (Law

and Kelton, I982) approach, we need an object that functions as an event calender. This is simply a stack of future events ordered by their event activation times. When the simulation clock is advanced to the next activation time, the corresponding object

is informed. The Timer increments the simulation clock to the next event activation time (called 'wakeUpTime') and sends a 'wakeUp' message to the corresponding

object. The benefits of polymorphism are evident here. Timer needs to send a single message - 'wakeUp' - regardless of the nature of the receiver object. The receiver can

respond to it in its own unique manner. We face a potential problem with the entity set 'Queue'. There is a 1 : 1 relation

between Machine and Queue. Queue has only one attribute 'noOfParts'. Can Queue be an attribute of Machine? The answer may be obtained by asking the question - 'can a queue exist independently of any machine?'. The answer is 'yes' - we can have queues of parts awaiting shipment that are not associated with any machine. Queue needs to exist as a distinct entity set. This means we obtain a distinct object class

'Queue'. The Scheduler entities require some explanation. Based on the current state of the

system the Manager has to make decisions regarding setup changes and scheduling production on idle machines. Heuristics and queue disciplines are stored in scheduler objects. These prioritize parts for production based on which the Manager makes decisions. A Scheduler object is an implementation of knowledge base in the object oriented paradigm. Scheduler object is an example of a software object representing

a conceptual object. There are two complex relationships: 'Produces' and 'SetUp'. Let us look at

'Produces' first. It is a 4-ary relationship and can be decomposed following established guidelines (Hawryszkiewycz, 1984) into the diagram shown in Figure 3. SetsUp is remodeled in Figure 4. From these figures we can consider both ProductionTask and SetupTask as strong candidates for mapping into objects (even though the attributes

I Ma~h'~ I

Fig. 3. Reconstructing relationship 'Produces'.


Machine

Fig. 4. Reconstructing relationship 'SetUp'.

have not yet been identified). The final structure for thse objects will be finalized once we draw the message flows. While the ER approach is very useful for modeling structural aspects of entities and objects, it is unable to effectively represent dynamic interactions. For such interactions we use the message flow diagrams to supplement the data model resulting from an ER analysis.

A partial list of objects identified thus far and their instance variables:

(a) Timer (i) currentTime

(ii) endTime (time the simulation should stop) (iii) list of future events ordered by their activation times.

(b) Machine (i) name

state (BUSY/IDLE/INSETUP) setupGroup (the group it is set up for) id of associated Queue

(ii) (iii) (iv)

(c) Part (i) id number

(ii) belongToGroup (iii) state (WAITING/PROCESS) (iv) id of associated RouteSheet

(d) Queue (i) name (example: finishedLots)

(ii) List of Lot's sorted by group and then by id number (nested structure)

(e) Scheduler (i) rule (example: " F I F O " ) . .

(f) Group (i) groupNumber

(ii) setupTime

156 SADASHIV ADIGA AND MIL1ND GADRE

Step 3: Important Events and Message Flow Diagrams The following events can be identified for our FMS:

(i) start production on a particular parts at a particular machine, (ii) end production on a particular part at a particular machine,

(iii) start performing a setup on a machine, (iv) end performing a setup on a machine.

Let us analyze the production steps. Starting production is a decision made by

Manager and takes the form of assigning resources (machines, parts) to perform a task (i.e. a production operation). When we start production, it is for a part at a particular machine. It lasts for a particular duration: once processing is done, the part is removed from the machine and added to the next queue. The machine goes idle. The task is finished and need not be tracked any longer. Hence, an instance of Production- Task is temporary object. Once finished it may be freed from memory.

Message Flow Diagrams (Glassey and Adiga, 1989) are used to illustrate the interactions between the objects. A message flow diagram (MFD) is simply a net- work where nodes represent objects and the arcs connecting them represent messages. The arcs (messages) are numbered sequentially to show the order in which the

messages are sent. 'ProductionTask' sends messages as shown in the message flow diagram in

figure 5. The first message is from Manger creating an instance of 'ProductionTask'

at: aMachina

3. duraticnOfStep: nextStep

tep

,6. w~kdMeUpln: procDuration 5. startPrcduction

Fig. 5. Message flow diagram showing the event - startProduction.


Fig. 6,

Tim• 1. wakeUp

Message flow diagram showing the event - endProduction.

for a particular Part at a particular Machine. Duration of the processing step is stored in the RouteSheet linked to the part. Hence, ProductionTask queries aPart for the duration. The object "aPart", in turn queries its RouteSheet, gets the information and returns the processing duration for the step to ProductionTask. Then the newly created instance of ProductionTask sends 'startProduction' messages to a part and a WorkStation. These respond by altering their respective states (the machine will go from IDLE to BUSY). The next message 'wakeMeUpln : procDura- tion' is to the Timer. Timer responds by adding the object to its event calendar. Its position in this calendar is according to its 'wakeUpTime' which is calculated as follows:

wakeUpTime = currentTime + procDuration

When the wakeUpTime for this object is reached, Timer will send it a 'wakeUp' message. The ProductionTask instance will respond by sending 'endProduction' message to the machine and part. These will alter their states appropriately. An 'endProduction' message to Manger is also sent. Figure 6 shows the message flows for endProduction. Manager will respond by writing to statistical files and moving the part to the next queue. According to user definitions, other functions may be executed. The SetupTask will behave similarly.

Objects identified in this step and their instance variables are:

(a)

(b)

ProductionTask (i) id of Part to be processed

(ii) id of Machine to be used (iii) processing duration.

SetupTask (i) id of Machine to be setup

(ii) setup duration


Step 4: Functional Specifications We identified the instance variables required to support the data needs of the objects in Step 2. Now we shall look at the methods required to be provided in the objects to respond to messages representing the interactions between objects participating in important events. From Figure 5 we get the following list of methods. Below each

method we list the functionality to be provided by the receiver objects.

(a) Manager to ProductionTask - 'createFor: aPart at: aMachine' (i) set instance variables to aMachine and aPart

(ii) obtain processing time from aPart (iii) send 'startProduction' message to aMachine and aPart (iv) 'wakeMeUpln: duration' message to Timer

(b) ProductionTask to aPart - 'durationOfNextStep' (i) query associated RouteSheet for processing duration for next step

(ii) return value

(c) ProductionTask to aPart - 'startProduction'

(i) change state to 'OPERATION'

(d) ProductionTask to aMachine - 'startProduction'

(i) change state to 'BUSY' (ii) if original state is not ' IDLE' and setupGroup is not correct:

return error messages

(e) ProductionTask to Timer - 'wakeMeUpIn: procDuration' (i) compute wakeUpTime = currentTime + procDuration

(ii) add ProductionTask to event stack in proper order sorted by

wakeUpTime

(f) aPart to RouteSheet - 'durationOfStep: nextStep' (i) return processing duration for specified step

From Figure 6 we get the following specifications for the messages:

(a) Timer to ProductionTask - 'wakeUp' (i) send 'endProduction' messages to aMachine, aPart andManager

(ii) free self

(b) ProductionTask to aPart - 'endProduction' (i) change state to 'WAITING'

(c) ProductionTask to aMachine - 'endProduction' (i) change state to ' IDLE'

(d) ProductionTask to Manager - 'endProduction' (i) do data collection if required, write messages on terminal for

user's information (ii) move aPart to the queue at its next processing step

(iii) other user requirements

OBJECT-ORIENTED SOFTWARE MODELING OF AN FMS

Table I. A partial summary of message flows

159

SenderObject ReceiverObject Messages

Manager ProductionTask

Timer ProductionTask

ProductionTask Part

Machine

Timer Manager

Part RouteSheet

Table It. Partial list of object specifications

Object Name Instance Variables Methods

Machine name state setupGroup assocQueue

createFor: aPart at: aMachine

wakeUp

durationOfNextStep startProduction endProduction startProduction endProduction wakeMeUpln: procDuration endProduction

durationOfStep: aStep

ProductionTask procPart procMachine prodDuration

createName: linkTo: startProduction startSetupForGroup: endProduction endSetup

createFor: at: wakeUp

This information is summarized in Table I. Messages appear as methods in the receiver objects, The information in Table l can be combined with the instance variable information from the preceding steps to obtain specification sheets for each object. This is illustrated in Table II for two objects: Machine and ProductionTask.

Step 5: Implementation

Programming in the OOP paradigm consists of implementing all the objects and tying them together in a main program in the correct sequence necessary to produce the required system level behavior. Once complete set of specifications is obtained, it can be implemented in an OOP language of one's choice. A survey of OOP languages can be found in Stefik and Bobrow (1986) and Rettig et al. (1989). The language we selected is Objective-C from Stepstone Corporation, Sandy Hook, CT. One of the reasons is that this enables us to borrow a significant amount of code from a library of software objects called BLOCS/M (Berkeley Library of Objects for Control and Simulation/Manufacturing) (Glassy and Adiga, 1989). BLOCS/M is a product of research in the Industrial Engineering and Operations Research (IEOR) Department at the University of California at Berkeley.

The source code for two objects - Machine and ProductionTask - is shown in the Appendix. One corresponds to a physical object. The other is a conceptual object


representing the implementation of a resource allocation decision and involves two events: start and end production. A detailed discussion of programming conventions is beyond the scope of this paper. Readers are referred to Cox (1987) and the Objective-C Reference Manual (Stepstone Corporation, 1988) for further information.

6. Extending the Model

An important decision to be made on the shop-floor is when a workstation completes processing of a part. It is one that answers the question - which parts should be processed next? This is known as the production dispatching decision. It can be implemented by simply following the sequence of communications that take place on the shop-floor in enforcing a rule, for example, FIFO (First in First Out). The Scheduler has the responsibility to implement the sequence of messages.

The following scenario follows in accordance with the orginal description of the FMS. The FMS is set up for a particular group of parts. One of the machines has just finished processing a part from that group. The Manager object has to schedule production of another part. Manager does it by asking the scheduler to do it with the aid of the machine that requires a part. The scheduler object checks the queue lengths of all the sub-queues at the machine associated with the group (remember the need for a nested queue structure). It then selects a part from the sub-queue with the longest length using FIFO. Decisions regarding setups can be made using another Scheduler object. This will make its decisions based on (perhaps) the number of parts of each type produced versus the number required, due dates and so on. One can extend and customize the model by replacing the Scheduler object with an object that contains the logic of one's choice without disturbing the structure of the other objects, and other events. Properly used, the object-oriented approach will allow plug-compatibility between objects in the system software. We believe that our approach is one step in that direction.

Similarly, to include the phenomena of machine breakdowns, the workstation objects can be replaced by ones that have additional states corresponding to machine failures. The machine failures can be automatically triggered simply by a generator that places failure events in the timer following a failure time distribution.

7. Summary and Conclusion

Simulation through software modeling is an important activity in planning the production capacities and schedules of an FMS. An object-oriented modeling approach allows us to build a model to help simulate an FMS in an accurate manner. We have described a data-driven design approach that we have found useful in designing object-oriented software for the simulation of manufacturing systems.

The approach is based on a combination of Entity-Relationship model and message flow diagrams. This approach allows us to identify system objects and capture


relevant data and procedures. We do not believe that this is the last word in object-

oriented design. It is a simple, and practical approach which has the potential to be

mechanized to make the resulting software less errorprone. We believe that the design approach described by us is general enough to be used in the modeling of systems other than Flexible Manufacturing Systems.

Appendix

The source code for two objects - Machine and Production Task - is presented here. While we will explain as much of the code as possible, some features are characteristic

Objective-C and the reader will need to refer to the appropriate manuals (Stepstone Corp, 1988). The naming conventions and programming style followed is from the Berkeley Library of Objects for Control and Simulation/Manufacturing (BLOCS/M). Some code is also borrowed. Some important points follow.

Naming Convention." Class names begin with an upper case letter. Objects (which are nothing but instances of some class) have names beginning with a lower case letter. For example the class is 'Machine' and the instance is "aMachine'.

timer Global instance of class Timer.

manager Global instance of class Manager. Object The superclass of all superclasses. Defined in Object-C,

id New variable type defined in Object-C for variables that store the id's of objects.

self Type id reserved name in Objective-C. Points to object we are working on. super Type id reserved name in Objective-C Points to immediate super class. // Signifies that the rest of the line is for user comments. = : Signifies the end of class definition.

Remember." We have the benefits of inheritance. If an instance variable and/or method is not found in receiver object, Objective-C will search its super classes for it. Hence if the reader finds a method or instance variable being used that is not defined

in the following lines of code, he or she may assume it exists in one of the superclasses.

Class d~ffinitions are clone as follows:

= MyClassName: SuperClassName (Message Groups) (

/ /define instance variables

J OurMsgGrp The name of our message group.

Primitive One of the message groups defined in Objective-C.

Methods are divided into two O,pes:

�9 Those available ONLY WHEN an instance is being created. These are called 'Factory Methods'.

162 SADASHIV ADIGA AND MIL1ND GADRE

�9 Those available ONLY AFTER an object is created. These are called "instance Methods. Factory methods are identified by a ' + ' and instance methods are identified by a ' - ' . For example:

- ( long) currentTime {return currentTime;}

The " - " signifies that it is an instance method. The '(long)' is the type of the return value (default - if urtspecified - is type id). 'currentTime' is the name of the method, The functionality is defined within the '{ . . .} ' . Every method has to return one and only one value. The default is that the method return the id of the object it is part of.

Message Syntax:

[receiverObject messageName: (an optional set of arguments)];

DEFIN IT ION OF CLASS 'MACHINE '

//This is the definition of Machine class based on the functionality derived from ourdesign methodology

/ett~** Authors: Sadashiv Ad;ga and Milind Gadre Date: Jan 6, 1989 The naming convention and the programming and commenting style are from BLOCS/M

Name: Machine Super Class: Object Purpose: Generic machine object to simulate a simple FMS

#define IDLE 0 #define BUSY 1 #define INSETUP 2

= Machine : Object (OurMsgGrp, Primitive) {

unsigned state; char* name; id assocQueue,

setupGroup; }

/ / the instance variable to keep track of the state /.I the machine name /! id of the associated queue / / id of the group it is setup for

//Factory Methods

+ createNarne: [char ")aName linkTo: (id)aQueue { //create method specifies the name and id of queue

self = [super new];

name = aName; state = IDLE; setupGroup = nil;

assocQueue = aQueue;

/ /use superdass method "new" to create a new instance. //(this method defined in "Object" by Objective-C) l/assign value to instance variable "name" //set state # at this stage it is not setup for any group. "nil" is a //reserved name in Objective-C for the null object. II associated queue


return self; / / r e t u r n id of serf

I I Instance Methods

- startProduction // i f not specified, default return is of type (id) {

if (state != IDLE) printf("~nStartProduction ERROR at Machine = %s~nktMachine not IDLE're', name);

else state = BUSY;

return self; }

- startSetupForGroup: (id)aGroup {

if (state != IDLE) printf("~nStartSetup ERROR at Machine = %s~\tMachine not IDLE-~', name);

else {

state = INSETUP; setupGmup = aGroup;

} return self;

}

- endPmduction {

if (state != BUSY) pdntf("~nEndProduction ERROR at Machine = %s\n\tMachine not BUSY~n", name);

else state = IDLE;

return self;

}

- endSetup {

if (state != INSETUP) printf("~EndSetup ERROR at Machine = %s\n\tMachine net in INSETUP~', name);

else state = IDLE;

return self;

//Instance Methods to return vafues of instance variables E Note that a method can have the same name as an instance variable

- (unsigned) state {return state;} - (id) setupGroup {return setupGmup;} - (id) assocQueue {return assocQueue;} - (char *) name {return name:}

=: 1! End of class definition


DEFINITION OF CLASS 'PRODUCTIONTASK'

Authors: Sadashiv Acliga and Mnind Gadre Date: Jan 6, 1989 The naming convention and the programming and commenting style from BLOCS/M

Name: ProductionTask Super Class: Object Purpose: Task object to implement a production scheduling decision by Manager

o*o***~t

extern id manager, timer; //define global objects

= ProductionTask : Object (OurMsgGrp, Primitive) {

id procMachine, It id of machine at which task is to be created procPart; / / id of part for which task is created

long procDuration; //duration of operation )

//Factory Method

+ createFor: (id)aPart at: (id)aMachine {

self = [super new]; procMachine = aMachine; procPart = apart; pmcDuration = [pmcPart durationOfNextStep]; //query part for duration of step [timer wakeMeUpln: pmcDuration]; # inform timer of duration of task

[pmcMachine startProduction]; //send off "startPmduction" [procPart startPmduction]; //messages

return self; }

/! Instance Methods

- wakeUp {

[pmcMachine endPmduction]; [procPart endPmduction]; [manager endProduction];

[self free]; //once all the endPmduction messages have been sent out, free self //"free" is not defined in ProductionTask - it is defined in the superclass Object

return self; }

- (long) procDuration {return duration;) - (id) procMachine {return machine;] - (id) procPart {return part;}

=: I I End of class definition

References

Adiga, S., Software modeling of manufacturing system - a case. for an object-oriented approach, Ann. Operations Res. 1989.

Booch, Grady, Object-oriented development, IEEE Trans. Software Engineering, SE 12:2, 211-221 (Feb 1986).


Buzacott, J.A., Modeling manufacturing systems, Robotics and Camputer Integrated ,?vlanul~lcturing 2:1, 25-32 (1985).

Chen, P.P., The entity-relationship model: toward a unified view of data, ACM Trans. Database Systems 1:1, 9-36 (1976).

Cox, Brad. J., Oh~eel-Oriented Programming: An Evolutiona~T Approach, Addison Wesley, Reading. MA, 1987.

Dhal, O.J. and Nygaard, K.. SIMULA: an Algol-based simulation languagc, Communi. A CM 9, 671-678 (1966).

Glassey, C.R. and Adiga, S., Conceptual design of a software object library for simulation of semi- conductor manufacturing systems, J. Oh/eet-Oriented Programming, Nov/Dec 1989.

Goldberg, A. and Robson, D., Smalltalk-80: The Language and its Imph, mentation, Addison-Wesley, Reading, MA, 1983.

Ham, 1., Hitomi, K. and Yoshida, T., Group Technology." Applications to Pro~hu'tion Management. Kluwer- Nijhoff Publishers, 1985.

Hawryszkiewycz, I.T., Database AnaO'sis and Design, Science Research Associates, Inc., 1984. Kusiak, A., The part families problem in flexible manufacturing systems, FMS: operations research models

and applications, Ann. Operations Res. (eds. K.E. Stecke and R. Suri) 3, 279-300 (1985). Law, Averill, M. and Kelton, W. David, Simulation Modeling and Analysis, McGraw-Hill, New York,

1982. McKay, Kenneth N., Sagyeni, F.R. and Buzacott, J.A., Job-shop scheduling theory: what is relevant'?

hTtel~/~u'es, 18:4, 84-90 (July Aug 1988). Meyer, Bertrand, Reusability: the case for object-oriented design, IEEE S~l?ware, March 1987, pp 50 64. Minsky, Marvin, A Framework for Representing Knowledge, in The Psychology ~[ Computer Vision,

(ed. P. Winston), McGraw-Hill, New York, 1975. Pascoe, Geoffrey A., Elements of object-oriented programming, BYTE, August 1986~pp. 139-144 Potter, Walter D. and Trueblood, Robert P., Traditional, Semantic and hyper-semantic approaches to data

modeling, IEEE Computer, June 1988, pp. 53-63. Ramamoorthy, C.V. and Sheu, P,C., Object-oriented systems. IEEE Expert, Fall 1988, pp. 9-15. Rettig, M., Morgan, T., Jacobs, J., and Wimberly, D., Object-oriented programming in AI: new choices.

AI Expert, Jan 1989, pp. 53 69. Ross, D., Structured analysis (SA): a language for communicating Ideas, IEEE Transactions on S~![h~'are

Engineering, SE-3:I, January 1977. Stefik, M. and Bobrow, D.G., Object-oriented programming: thcmes and variations, AI Magazine, winter

1985, pp. 40-62. Stepstone Corporation, Sandy Hook, CT, Ohjeetive-C Relerenee Manual, 1988. Suri, R. and Whitney, C.K., Decision support requirements in flexible manufacturing, J. Mam~l~wturing

Systems 3:1, 61-69 (1984), Talavage, Joseph and Hannam, Roger G.. Flexihh, Manu/~u'turing Systems in Practice." Applications, Design

and Simulation, Marcel Dekker Inc., 1988. Young, Robert, E. and Rossi, M.A., Toward knowledge-based control of flexible manufacturing-systems,

lIE Trans. 20:I, 36-43 (March I988).

object-oriented software modeling of a flexible manufacturing system

Documents