Object-oriented Representation Of Manufacturing Systems .

3y ago
45 Views
2 Downloads
1.20 MB
11 Pages
Last View : 15d ago
Last Download : 3m ago
Upload by : Brady Himes
Transcription

18Object-oriented representation ofmanufacturing systems: State ofthe art and perspectivesAnna BartolottaPolitecnico di Milanop.zza Leonardo da Vinci 3220133 Milano, ITALYTel. 39-2-2399-2726 Fax: 39-2-2399-2700E-mail: bartolot@mail.ecopro.polimi.itMarco GarettiPolitecnico di Milanop.zza Leonardo da Vinci 3220133 Milano, ITALYTel. 39-2-2399-4760 Fax: 39-2-2399-2700E-mail: garetti@mail.ecopro.polimi.itAbstractThe object-oriented representation of manufacturing systems appears to be apromising way to encompass the limits of more traditional tools that have beenused in the past for the modelling of manufacturing systems. The paper comparestraditional modelling techniques to the approach of object-oriented modelling andreviews the state of the art of the object-oriented applications developed within themanufacturing context. As a conclusion, guidelines for the development of acomprehensive object-oriented representation of manufacturing systems areoutlined.KeywordsManufacturing systems engineering, modelling of manufacturing systems, objectoriented modellingAdvances in Production Management Systems 1998 IFIP. Published by Chapman & HallN. Okino. H. Tarnura & S. Fujii (Eds.)

1961Part Four Integration in Manufacturing and Production ManagementINTRODUCTIONTraditional approaches to manufacturing systems design are not weIl suited to dealwith today's dynamic environment where system elements are continuously beingsubjected to replacement and rearrangement due to rapid changes in product designand product mix and fast advances in manufacturing technology.Today no integrated design framework is available to support the design ofmanufacturing systems, a situation that stands in evident contrast to that of thedesign of modem manufactured products, where the computer-aided technologies(CAD/CAM) provide a software integrated environment where to carry out thedesign process. This is true in spite of wealth of published researches on toolssupporting specific problems in manufacturing systems design.This paper is part of a research project aiming to study a Manufacturing SystemsEngineering Workbench (Garetti and Bartolotta, 1995), i.e. a software environmentin which tools supporting the design of manufacturing systems could be integratedin a common framework.A corner stone in such kind of approach could be provided by a structuredrepresentation of the domain of manufacturing systems, i.e. a unifying abstractionenabling the management of all relevant information and knowledge associatedwith the process of manufacturing systems design. Upon such a framework, acomprehensive and consistent manufacturing systems database could beconstructed to integrate all the design tools to be included in the manufacturingsystem engineering workbench. This way the designer should deal only with onecentral, generalised model of manufacturing systems, while on the other hand alldesign tools should operate on this central model.Once made the one-time effort to insert all data related to a specific manufacturingsystem, further advantages could be derived if the database were updated in such away as to maintain the exact correspondence and accuracy of the data as themanufacturing system evolves, supporting the manufacturing engineer in theredesigning activities.The objective of this paper is the identification of the guidelines that could beusefully employed in the ideation of such a representation environment formanufacturing systems. The objective is addressed by the analysis of existingmodelling methodologies, in particular object-oriented methodologies, andapplications ofthe object-oriented approach to the manufacturing context.2REVIEW OF CURRENT MODELLING TOOLSThe traditional methods of systems analysis can be classified as either 'functionaldecomposition' oriented or 'data' oriented. In the functional decomposition method,a system is functionally decomposed using functions and processes as elementarybuilding blocks: therefore system entities are passive data stores, manipulated byactivities and procedures (see for example the IDEFo approach). The data oriented

Object-oriented representation of manufacturing systems197methods, on the other hand, concentrate on system data structure, makingextensive use of data tlow diagrams and entity/relationship concepts.In the recent few years a third approach, the object-oriented (0-0) approach, bothfor systems analysis and design, has been emerging. There is no doubt that theconcepts of 0-0 approach are fundamentally different from traditional structuredmethods and require a different way of thinking (Booch, 1994).As known, the fundamental construct of this approach is the object, wh ichcombines both data structure and behaviour in a single entity. The state of anobject is captured in its attributes, while the behaviour is encapsulated through themethods (or operations). An object can communicate with other objects throughmessages, which constitute its public interface to the other objects.An object is either a class or an instance of a class. The 0-0 approach embodiestwo important concepts:encapsulation is the separation of the external aspects of an object, which areaccessible to other objects, from the internal details, which are hidden fromother objects;inheritance allows the reuse of the structure and behaviour of a class in thedefinition of new classes.It is now widely recognised that the object-oriented (0-0) paradigm provides anexcellent approach to manage and express complex systems. The 0-0 approachpresents characteristics that make it particularly suitable to meet the requirementsfor the representation of manufacturing systems: in fact, unlike classical(functional) design, the object-oriented paradigm decomposes a system dealingwith the classes of objects the system manipulates, not the functions the systemperforms. Therefore the definition of objects remain independent of the systemfunctions being mode lied. Only a relatively small number of changes will beneeded as a consequence of the introduction of a new object to an existing system,in contrast with the functional-based approach, where a large part or even thewhole model may need to be altered to cater for such a change.Furthermore, it seems that all manufacturing functions can benefit from the objectoriented approach, thanks to the strong affmity between the manufacturing contextand object-orientation (Nof, 1994). In fact, for each kind of key objectives of atypical manufacturing enterprise there is a strong analogy in object-orientation; forexample, both focus on objects (parts in manufacturing) and both are based onmethods to define operations and services (processes and manufacturing services).Finally, the concepts of encapsulation and inheritance provide the object-orientedapproach with characteristics of tlexibility, realistic view, extensibility andreusability, all characteristics necessary for the representation of manufacturingsystems.3REVIEW OF OBJECT-ORIENTED METHODOLOGIESUnfortunately the interest in the new object-oriented approach, has led to manymethodologies, resulting in a proliferation of definitions, interpretations and non-

198Part FourIntegration in Manufacturing and Production Managementstandardised concepts; this is particularly evident in the software engineering area,where the object-oriented approach finds a lot of applications.The following paragraphs provide a literature review of the 0-0 approach. Inparticular, in § 3.1 three of the most known methodologies used in the area ofsoftware engineering will be briefly described, while in § 3.2 some of the fewapplications of 0-0 approach already emerged into the manufacturing context willbe critically reviewed.3.1 Object-oriented methodologiesOOSA (Shlaer and Mellor, 1988) divides systems development into 00 analysisand design.00 analysis is described in three steps:- information modelling: the focus is on abstracting the conceptual entities in theproblem domain in terms of objects and attributes. The associations that existbetween the entities are formalised as relationships that are based on thepolicies, rules and physicallaws that prevail in the real world;- state modelling: this step concerns the behaviour of objects and relationshipsover time. State models are used to formalise the life cycles of both objects andrelationships. The state models, wh ich consist of state transition diagrams andtables, communicate with each other by means of events. State models aredefined by multi-Iayers of state transition diagrams to make the model ofcommunication orderly and understandable.- process modelling: the actions of the state models, which contain all requiredprocessing, are dissected into fundamental and reusable processes and areexpressed by an enhanced form of the traditional data flow diagram. Theprocesses so derived can be converted directly into operations of objectoriented design.Four distinct diagrams are used in the design phase:- class diagram, wh ich shows the extern al view of a single class;- inheritance diagram, which shows the inheritance relationships betweenclasses;- dependency class, which depicts the client-server (invocation) and friendrelationships that hold between classes;- class structure chart, showing the internal structure of the code of theoperations of the class.Another 0-0 methodology is due to Booch (Booch, 1994): while designing acomplex system, he views the system itself considering multiple perspectives:namely, the logical and physical structure, and the static and dynamic semantics.Both dimensions are necessary to specify the structure and behaviour of an objectoriented system. For each dimension, Booch defines a number of diagrams,denoting a view of a system model:

Object-oriented representation ofmanufacturing systems----199class diagram, used to show the existence of classes and therr relationships inthe logical design of a system; a single class diagram represents a view of theclass structure of a system;object diagram, used to show the existence of objects and therr relationship inthe logical design of a system; a single object diagram is typically used torepresent a scenario;module diagram, used to show the allocation of classes and objects to modulesin the physical design of a system: a single module diagram represents a viewofthe module architecture ofa system;process diagram, used to show the allocation of processes to processors in thephysical design of a system: a single process diagram represent a view of theprocess architecture of a system;state transition diagram, used to show the state space of an instance of a givenclass, the events that cause a transition from one state to another, and theactions that result from a change of state;interaction diagram, used to trace the execution of a scenario in the samecontext as an object diagram.The Object Modelling Technique (OMT) (Rumbaugh, 1991) distinguishes amongthree kind ofmodels:- object model, describing the static structure of objects in a system and therrrelationships. The object model consists of object diagrams, a certain kind ofER models, which describe the association and the relationships among objects;- dynamic model, describing the interactions among objects in the system andhence the control aspects of a system. This dynamic part for every class isdescribed in state diagrams and to identify events, states and transition firstevent flow diagrams are drawn;- functional model, describing the data transformation of a system. This is donewith dataflow diagrams.The three kinds of models separate a system into orthogonal views that can berepresented and manipulated within a uniform notation. The three different modelsare cross-linked (a complete description of a system requires all three models) buteach model can be examined and understood by itselfto a large extent.None of the existing 0-0 methodologies has really achieved the status of being awidely recognised standard comparable to some of the conventionalmethodologies. Furthermore, the proliferation of methodologies used to refer toessentially similar and basic functional capabilities leads to be suspicious about thereal necessity of adopting a methodology in order to take advantage of the objectoriented approach. In addition, when these methodologies (specific to the area ofsoftware engineering) are considered for use within the context of manufacturingsystems analysis, it becomes clear that there are certain features that need to becatered for (Wu, 1995).

200Part Four Integration in Manufacturing and Production Management3.2 Object-oriented methodologiesIn literature, we can found some attempts to apply the 0-0 approach within themanufacturing context. A literature review shows that these attempts don't follownecessarily a precise existing methodology (with its notation and graphicaldiagrams), but they use only the basic principles ofthe object-oriented orientation.This leads to inherent difficulties in formally evaluating these candidatemethodologies on a common basis, because of major differences in theirunderlying philosophies and their consideration of only some aspects. In thefollowing paragraph, a few examples of these attempts will be described andanalysed.Typically the object-oriented approach to describe manufacturing systems has beenmainly used to build simulation models. The objective is the development ofsoftware modules that can be combined by the designer to build a simulationmodel.Shewchuck and Chang (1991) present a hierarchical structure of object classes,consisting of three class Iibraries. These classes can be classified into two broadcategories. The first category, to which the base classes and the simulation supportclasses belong, contains objects providing the software functions which allow thebackground simulation processing tasks, such as time advance, event triggering,entity creation, list processing, etc. to be performed. The second category, themanufacturing systems simulation (MSS) c

Object-oriented representation of manufacturing systems: State of the art and perspectives . in which tools supporting the design of manufacturing systems could be integrated in a common framework. A corner stone in such kind of approach could be provided by a structured representation of the domain of manufacturing systems, i.e. a unifying .

Related Documents:

Object Class: Independent Protection Layer Object: Safety Instrumented Function SIF-101 Compressor S/D Object: SIF-129 Tower feed S/D Event Data Diagnostics Bypasses Failures Incidences Activations Object Oriented - Functional Safety Object: PSV-134 Tower Object: LT-101 Object Class: Device Object: XS-145 Object: XV-137 Object: PSV-134 Object .

method dispatch in different object-oriented programming languages. We also include an appendix on object-oriented programming languages, in which we consider the distinction between object-based and object-oriented programming languages and the evolution and notation and process of object-oriented analysis and design, start with Chapters 5 and 6;

object-oriented programming language is based on a kind of old object-oriented programming language. For example, though C language is an object-oriented programming language, it still retains the pointer which is complex but has strong function. But C# improved this problem. C# is a kind of pure object-oriented language.

Reusability, CK Metric, Object - Oriented. 1. INTRODUCTION Object oriented systems continue to share a major portion of software development and customer base for these systems is on the rise. This is because there are many advantages in taking the object oriented concept. The weakness though is that most object oriented systems tend to be .

Object built-in type, 9 Object constructor, 32 Object.create() method, 70 Object.defineProperties() method, 43–44 Object.defineProperty() method, 39–41, 52 Object.freeze() method, 47, 61 Object.getOwnPropertyDescriptor() method, 44 Object.getPrototypeOf() method, 55 Object.isExtensible() method, 45, 46 Object.isFrozen() method, 47 Object.isSealed() method, 46

2 Database System Concepts 8.3 Silberschatz, Korth and Sudarshan Object-Oriented Data Model! Loosely speaking, an object corresponds to an entity in the E- R model.! The object-oriented paradigm is based on encapsulating code and data related to an object into single unit.! The object-oriented data model is a logical data model (like

as object–oriented design. Object–oriented development approaches are best suited to projects that will imply systems using emerging object technologies to construct, manage, and assemble those objects into useful computer applications. Object oriented design is the continuation of object-oriented analysis,

The Trading and Investment Strategies Interactive Qualifying Project is an in depth examination of the methods and strategies used on investable markets in order to gain long-lasting investing experience.