semi合集-English.pdf - 第1682页

SEMI E39-0703 © SEMI 1995, 2003 24 APPENDIX 1 NOTICE : The material in this appendix is an official part of SE MI E39 and was approved by full letter ballot procedures on March 16 and April 21, 2000 by the Japanese Regio…

SEMI E39-0703 © SEMI 1995, 2003 23

13 Applications

13.1 This section provides examples of applications of

object services.

13.2 Get All of an Object’s Attributes — In the most

straight-forward case, GetAttr is used to get all of the

current attribute values of a single target object known

to the provider of the GetAttr service. The object

specifier is omitted, and the object type is set to the type

of the target object. To get all of the object’s attributes,

both the attribute filter and the names of requested

attributes are also omitted.

13.3 Determine All Objects of a Specific Type and with

Specific Characteristics — To determine subordinate

objects with specific characteristics, such as of type

“Module” with an identifier ObjID starting with

“ABC”, set object type to “Module”. In the attribute

filter, set the attribute name to “ObjID”, set the attribute

value to “ABC*”, and set the qualifying relationship to

“is equal to” (or omit it).

13.4 Determine Specific Attributes of a Specific Object

Instance — To determine the current value of certain

attributes of a specific object, set the object type

appropriately. Either set the list of ObjID to a list

containing the one identifier of the target instance, or

alternatively, in the attribute filter, set the attribute

name to “ObjID”, set the attribute value to the

identifier, and set the qualifying relationship to “is

equal to” (or omit it).

13.5 Determine Types of Subordinate Objects — To

determine all object types that are owned by another

object, the GetType service is used with the single

parameter of the object specifier of the owner. The

service provider returns an error of “Unknown object

type” if it has no types of owned objects.

13.6 Determine Names of Attributes of Subordinate

Objects — To determine the names of the attributes of

specific objects owned by the service provider, the

GetAttrName service is used with two parameters: the

object specifier of the owner and a list of the types of

the target objects. The service provided returns an error

of “Unknown object type” if it has no types of owned

objects.

14 Requirements for Compliance

14.1 Object Services are common to all service

resources that define public objects with operations for

getting (reading) and setting (writing) attribute values

and for getting object types and attribute names for

objects. Object services provide common definitions

for public objects and object services that may be

incorporated into these service resources, thereby

avoiding unnecessary duplication.

14.2 Fundamental Requirements — All objects

compliant to any part of OSS shall be subtypes of the

top object. That is, they shall inherit (provide) the

ObjType and ObjID attributes as described in Section

8.2.

14.2.1 They shall provide documentation of their

public attributes in the form of an Object Attribute

Definition table as described in Section 5.2.

14.2.2 They shall also provide the services GetAttr and

SetAttr as defined in Section 11.5. Support for an

owner’s object specifier and filter are not required for

fundamental compliance with OSS. If the service user

provides parameters for scope or filter in its request,

they may be ignored by the service provider. However,

they shall not cause errors in the response due to their

presence.

14.3 Additional Capabilities

14.3.1 Filters — Support for attribute filters in GetAttr

and SetAttr requests is an optional capability.

14.3.2 Owner Objects — All owner objects

(aggregates, containers, and supervisors) shall support

both scope and filters for the GetAttr and SetAttr

services, as defined in Sections 9.3, 11.2, and 11.3.

14.3.2.1 In addition, they shall provide the service

GetType as defined in Section 11.6, with support for

wild characters in the specification of object types.

14.3.3 Multiple Inheritance Hierarchy  Inheriting

objects shall identify inherited objects with an

inheritance expression in the object specifier.

SEMI E39-0703 © SEMI 1995, 2003 24

APPENDIX 1

NOTICE: The material in this appendix is an official part of SEMI E39 and was approved by full letter ballot procedures on

March 16 and April 21, 2000 by the Japanese Regional Standards Committee.

A1-1 Overview of Object Terminology

A1-1.1 This section provides an introduction to the

basic terminology for object models.

A1-1.2 A model is an abstraction of a problem, a real-

world phenomena, things, etc. for the purpose of

understanding it. A model typically is a simplification

that omits nonessential details. Examples: architectural

scale models, behavioral state models.

A1-1.3 An object is an entity (concept, abstraction, or

“real world” thing) with a particular behavior and with

associated properties (information, or attributes). An

object type (class) refers to a group of objects that have

common (1) properties (but not specific values), (2)

behavior, (3) relationships with other objects, and (4)

semantics (public interfaces). The term “object” may be

used either to refer to a type of object or to a particular

instance of an object type.

The notation used for

diagrams of objects used in this document is described

in Section A1-2.

A1-1.4 An object model is a static graphic model of

objects to show structure — the identity of objects, their

attributes and operations, and their relationships with

one another.

A1-1.5 An instance of an object is an instantiation of

an object type. For example, a specific installation of

equipment is an instance of the object type

“Equipment.”

A1-1.6 Objects have items of associated information

called attributes. For example, for an object

“Equipment,” attributes of interest include the

manufacturer, model, serial number, and a logical user-

assigned name (nickname). Attributes used to uniquely

identify a particular instance of an object type is called

an identifier. An object may have more than one

identifier. Also, a set of more than one attribute may be

used as an identifier. In the example of “Equipment,”

name could be used as an identifier, and the

combination of manufacturer and serial number also

could be an identifier.

A1-1.7 Objects have operations that may be applied to

or by an object type. Operations are functions or

transformations that are either performed by, or on, an

object. Operations of interest to Object Services are

“get (read) attributes,” “set (write) attributes,” and “get

8 The term “object” is used by some authors to only refer to

instances and by other authors as a synonym for object type.

type.” A service provides a service user with an

interface to the functionality of the operation.

A1-1.8 A high-level model may show a particular type

of object with certain operations, while a more detailed

model shows that a second type of object actually

performs one or more of the operations on the first

object. As an example, a model might show a process

program object with the operation “delete,” to show

that the “delete” operation is inherently associated with

the process program. A more detailed model might

show that a “process program manager” actually

performs the operation of deleting a process program.

A1-1.9 A method is an implementation of an operation

(e.g., the software code that performs the operation).

Figure A1-1

Object Type and Instance

Figure A1-2

Example of Object Type and Instance

A1-2 Object Modeling Technique (OMT)

Notation

A1-2.1 The material contained in this section is

provided as a reference for auxiliary information.

A1-2.1.1 Object Modeling Technique (OMT) is a

graphical notation for models of objects that is useful

for analyzing a wide variety of problems, in all phases

of software design and development, and in preparing

documentation. OMT was developed by Rumbaugh,

Blaha, et al., in Object Modeling and Design, Prentice

adopted by different standards to describe requirements

in terms of objects and relationships between objects.

The purpose of this document is to provide a

description of OMT notation as a reference for such

SEMI standards and other SEMI documents.

A1-2.2 Basic Notation — Figure A1-1 illustrates

notation for object type, showing object type, object

attributes, object operations, object instance, and the

relationship between an object type and instance. Figure

A1-2 provides an example.

A1-2.2.1 Object types in OMT are shown as rectangles.

The rectangle may be further subdivided into two or

three parts. The object type always appears at the top.

Object attributes are shown in a second part of the

rectangle. Operations are shown in a third part of the

rectangle. High-level models often omit the operations

section and sometimes omit the attributes section.

A1-2.2.2 The name of an attribute may be followed by

additional details, such as data type and initial value.

A1-2.2.3 Instances of objects are shown as rounded

rectangles. The instantiation relationship is shown by a

dotted arrow from an instance of an object type to the

type.

A1-2-2.4 The example for an object type “Equipment”

is shown in Figure A1-2; here “Etch01” is a specific

real-world installation of type “Equipment.”

A1-2.3 Associations — An association describes a set

of potential bi-directional relationships between

instances of objects. An association uses a formal

structure and semantics.

A1-2.3.1 An association shows a specific multiplicity

at both ends of the relationship. For example, a single

factory manufacturing system may be associated with

many equipment (one-to-many). Possible multiplicities

of association types are shown in Figure A1-3.

Figure A1-3

Multiplicities of Associations

A1-2.3.2 Figure A1-4 shows an example of a one-to-

one relationship. The name of the association (using a

verb) appears above the line connecting a pair of

objects and describes the relationship that the object to

the left (or above) has to the object to the right (or

below).

Figure A1-4

Association of Objects

A1-2.3.3 The name of the role of each object within

the relationship may be placed beneath the line and near

that object. Role names are nouns. In the example

above, the roles might be “supervisor” and

“subordinate.” Role names are optional.