semi合集-English.pdf - 第2302页

SEMI E81-0600 © 1999, 2 000 39 • Exceptions — An IDL specification for reporting user-defined, framew ork-related error conditions. • Published Events — T he name of the event structure that must be placed on an event ch…

Table 1 Object State Definitions and Query Table Example

State Definition Query for State Via

ENGINE RUNNING In this state, the automobile's engine is running. boolean isEngineRunning ( );

sent to instance of Automobile.

Returns true.

Table 2 Object State Transition Table Example

Current State Trigger New State Action

ENGINE STOPPED turn ignition key to right ENGINE RUNNING tachometer indicates positive RPM

ENGINE RUNNING turn ignition key to left ENGINE STOPPED tachometer indicates zero RPM

LIGHTS OFF turn light switch on LIGHTS ON driving at night is enabled

LIGHTS ON turn light switch off LIGHTS OFF driving at night disabled

7.4.4 Textual Specification Language

7.4.4.1 The textual notations used to specify the

framework in this specification, include the following:

• Interface Definition Language (IDL).

• Interface Definition Format.

7.4.4.2 Interface Definition Language (IDL)

7.4.4.2.1 Specifications of CIM Framework

components are composed mainly of interfaces. The

specifics of each interface, while also represented in the

UML-based Component Information Model, are

rigorously specified using OMG IDL. The IDL for CIM

Framework interfaces shall be complete and consistent

as verified by automated IDL compilers. The IDL

portion of SEMI specifications will be available in a

text file format to facilitate such validation and use with

IDL compiler technologies.

7.4.4.2.2 This explanation of IDL is addressed to its

use as a rigorous specification tool. The considerations

of mapping the specifications to an implementation

infrastructure are addressed in SEMI E96.

7.4.4.2.3 Common Object Broker Architecture

(CORBA) [CORBA][CIMArch] defines the architecture

which enables and regulates interoperability between

objects and applications across heterogeneous

languages and computer boundaries. In all Object

Management Group (OMG) specifications, services are

defined as object interfaces expressed in the OMG's

IDL. CORBA standards define IDL and its mapping to

implementation languages (for example, C, C++,

Smalltalk, and Java).

7.4.4.2.4 IDL is a compilable language that describes

the operations that are specified for an interface. The

notation is independent of the language in which the

methods that implement an interface’s operations are

written. This goal is achieved by mapping between the

IDL syntax and whatever language is used to implement

client and server objects. Because IDL is designed

purely for interface specification, it omits the flow

control and operator constructs of an implementation

language. Object classes can implement an interface

differently as long as their behavior conforms to the

interface specification.

7.4.4.2.5 IDL obeys the same lexical rules as C, while

introducing a number of keywords specific to a

distributed system. As IDL is mapped to object-oriented

languages, new constructs will appear. A brief

discourse on some of the keywords and concepts used

in this specification follows. In the examples, words in

italics are user supplied, others are IDL-defined

keywords.

7.4.4.3 Interface Specification Format

7.4.4.3.1 The OMG defines an object’s interface as “a

listing of the operations and attributes that an object

provides. This includes the signatures of the operations,

and the types of the attributes. An interface

specification ideally includes the semantics as well”

[OMA]. The CIM Framework Specification builds

upon this definition to provide additional semantic

information for an interface. These semantics are

captured in an interface description. This section

describes the format of an interface. Each description of

an interface follows this format. The format includes

the following:

• Name — The capitalized noun following the word

“Interface:”

• Inherited Interface — The capitalized noun after

the words “Inherited Interface:”

• Description — A definition of the interface giving

its form and function.

• Exceptions — An IDL specification for reporting

user-defined, framework-related error conditions.

• Published Events — The name of the event

structure that must be placed on an event channel.

The event structure identifies the event through a

subject field. The subject is composed of the

component and interface issuing the event and data

describing the event, and filterable and non-

filterable information. Events are defined at the

interface level; neither posting services nor

subscribers are identified. Thus, events are not tied

to specific services and may be the result of an

internal (to the component) computation.

• Provided Services — A list of publicly available

services provided by this interface. In other words,

a list of non-private, named operations. Each is

given by a description in comment form (i.e.,

/*....*/) followed by its representation in the IDL

syntax.

• Contracted Services — A table of framework

services provided by other interfaces that are being

used by public and/or private services in this

interface. These methods must be available in order

for the documented interface to provide its

described services. Changes to contracted services

may result in changes to the behavior of the

interface making use of these services.

• State Model — See Section 7.4.3.5 for details.

7.4.4.3.2 If no Provided Services are defined for a

particular category, then “No public interfaces” will

appear after the category identifier. If no Exceptions,

Published Events, Contracted Services, or Dynamic

Model are provided, then the word “None” will appear.

State Transition Tables occur only in conjunction with

Dynamic Models.

7.4.4.4 Interface Specification Example

7.4.4.4.1 Table 3 provides a complete illustration of

IDL and CIM Framework interface specification format

usage within this specification. Words in italics are

user-supplied, others are either IDL or CIM

Framework-defined keywords.

8 Conformance to CIM Fram ework Domain

Specifications

8.1 The objective of the CIM Framework is to speed

the creation, use and improvement of a manufacturing

execution system for a semiconductor wafer fabrication

factory by enabling the integration of disparate

components into a cohesive system. The CIM

Framework achieves this objective by specifying a

domain model for MES components. MES component

suppliers use the specification to help establish the

boundaries and interfaces of their components.

Component customers first use the specification to

assess the capabilities of individual components and

then to facilitate the integration of components into a

working system.

8.2 The CIM Framework increases the value of the

MES components by enhancing their qualities of

interoperability, substitutability and extensibility.

• Interoperability is the ability of components to

work together through compatible interfaces.

• Substitutability implies the option to swap one

component with another because they support the

same interfaces.

• Extensibility means the planned capability to add

functionality to a component, again by leveraging

the support for predefined interface specifications.

8.3 Given both the scope and objectives of the CIM

Framework, conformance to the Framework can not be

reduced to a simple “yes or no” proposition. Rather,

component customers must assess component

conformance on a case-by-case basis. Potential buyers

assess conformance in terms of how well a component

supplier demonstrates use of the CIM Framework

specification to enable rapid component integration.

8.4 With this background, here then are factors for

consumers to consider in assessing MES components

and for suppliers to comprehend when building

components. These factors form the basis for

communication between buyers and sellers of

components regarding conformance to the CIM

Framework specifications.

Table 3 Interface Specification Example

/* Comments are set between slashes and asterisks */

Interface: FrameworkObject2

Inherited Interface: FrameworkObject1

Description: The example defines the interface for FrameworkObject2, which inherits from FrameworkObject1.

Exceptions:

/* The following portrays the syntax used to describe exceptions for this interface. ObjectType and instanceName specify an

object instance (supplementary information) returned with the exception. */

exception ExceptionName { ObjectType instanceName };

Published Events: NamedEvent

Provided Services:

/* The following defines the read/write methods for AttributeName1. */

ObjectType getAttributeName1 ();

void setAttributeName1 (in ObjectType parameterName);

/* The following defines a method for readonly AttributeName2 */

ObjectType getAttributeName2 ();

/* The following says operationName1 is a local operation returning an object of the class ObjectTypeReturned. */

ObjectTypeReturned operationName1 ();

/* The following says operationName2 is a local operation returning an object of the class ObjectTypeReturned with an

argument instanceName of the object type ObjectType. In addition, there is an operation-specific exception, E, that may be

raised by this operation. */

ObjectTypeReturned operationName2 (in ObjectType instanceName)

raises (E);

The type definitions follow the following format:

/* Type Declarations: */

/* The following specifies (types) the ObjectType for the named datatype. */

typedef ObjectType datatype ;

/* The following specifies a sequence (collection) of ObjectType for ObjectTypeSequence. */

typedef sequence<ObjectType> ObjectTypeSequence ;

• CIM Framework component packaging:

Component suppliers must explain how their

component is packaged relative to the

corresponding CIM Framework component(s).

Note, however, that suppliers may choose to

provide multiple CIM Framework components as

an integrated package. In this case the complete

package can be assessed relative to the

combination of services provided by the combined

set of CIM Framework components. Obviously, a

consumer must also assess the benefits of the

integrated component relative to the reduction in

the ability to substitute components within the

integrated package.

• CIM Framework objects and interfaces:

Component suppliers must describe how their

objects and methods support the CIM Framework

component interfaces. This includes describing the

object methods available in comparison to the

interfaces specified in the CIM Framework. Note

that this interface specification question

encompasses specific operations, the operations’

arguments, the exceptions returned, and the events

published.

• Object behavior: Component suppliers must

document object behavior so component

consumers can understand the purpose and

consequences of specific methods. The CIM

Framework specifies behavioral semantics for

components using a variety of representations such

as state models, information models showing

relationships, interaction models, and text-based