semi合集-English.pdf - 第7733页

SEMI T12-0305 © SEMI 2004, 2005 12 9.9.1 Inventory Obje ct — The inv entory is treated as Inventory obj ect in most part of this specification. It may be written sometimes as “Inventory” for shor t but it must be st arte…

100%1 / 7923
SEMI T12-0305 © SEMI 2004, 2005 11
9.7.2.1.1 To complete the responsibility it accepts adoption/reset of attachment history, updating requests and
inquiry. They are defined as services of HistoryDB in this specification. Service names may be different from
capabilities above.
9.7.2.1.2 Inherent data is used to complete the responsibility. The data is also referred to as attributes and they have
to be defined in some way. This document doesn’t define attributes directly with attribute definition table shown in
some SEMI standard documents but defines them indirectly as service parameters.
9.7.2.1.3 Behavior is also defined to complete the responsibility. Behavior is often represented by collaboration
with outside of this class and state model. Collaboration reflects a part of associations of this class with others.
Collaboration works by asking services defined on accompanying object which is the other end of association on
class diagram. State model is representation of the other part of behavior of this class. However it has to be defined
if this class has explicit state, state model is not defined here because this class is stateless.
9.8 HistoryRecord — HistoryRecord is a record for each Attachment registered in Inventory.
9.8.1 HistoryRecord object — HistoryRecord object keeps history data of a certain Jig or Implement.
HistoryRecord object is an instance of HistoryRecord class defined later. HistoryRecord objects are aggregated by a
HistoryDB object. This object is abbreviated as “HistoryRecord” in this document and often ‘object’ is omitted.
HistoryRecord
fluctuate
addEvent
listEvents
showEvent
showHistory
destruct
Figure 10
HistoryRecord Class
9.8.2 HistoryRecord Class — HistoryRecord Class defines its inherent data, behavior and services. This class
manages history of a Jig or Implement belonging to a HistoryDB. This class is illustrated as above for reference.
9.8.2.1 Responsibility of HistoryRecord — This class is responsible to hold and organize history information for a
Jig or Implement belonging to a HistoryDB.
9.8.2.1.1 To complete the responsibility it accepts removal of a HistoryRecord, adding events or increment
time/duration requests and inquiry. They are defined as services of HistoryRecord in this specification. Service
names may be different from above capabilities.
9.8.2.1.2 Inherent data is used to complete the responsibility. The data is also referred to as attributes and they have
to be defined in some way. This document doesn’t define attributes directly with attribute definition table shown in
some SEMI standard documents but defines them indirectly as service parameters.
9.8.2.1.3 Behavior is also defined to complete the responsibility. Behavior is often represented by collaboration
with outside of this class and state model. Collaboration reflects a part of associations of this class with others.
Collaboration works by asking services defined on accompanying object which is the other end of association on
class diagram. State model is representation of the other part of behavior of this class. However it has to be defined
if this class has explicit state, state model is not defined here because this class is stateless.
9.9 Inventory — There is an Inventory to track or manage all such attachments as jigs and Implements in a factory.
The inventory may be decomposed into a couple of sub-inventories for jigs and implements respectively. Or it may
be divided into a few sub-inventories by type or category for convenience of managing people. Even if so an
inventory of a type of attachments used for specific type of equipment is required to be seen as one whole inventory
by inventory user. Because inventory is a logical matter rather than a physical one, some of the attachments can be
shared by another inventory for different types of equipment and both inventories can be managed without any
confusion.
SEMI T12-0305 © SEMI 2004, 2005 12
9.9.1 Inventory Object — The inventory is treated as Inventory object in most part of this specification. It may be
written sometimes as “Inventory” for short but it must be started with the capital letter ‘I’. Inventory object is an
instance of Inventory Class which is defined later. Tracking system has just one Inventory object.
Inventory
update
install
uninstall
showNamespace
changeNamespace
listUp
showData
Figure 11
Inventory Class
9.9.2 Inventory Class — Inventory Class defines its inherent data, behavior and services. This class manages all
Jigs and Implements in certain area. The area here may not be always special but may be logical in equipment type,
attachment type, supplier or nay combination of such category. This class is illustrated as above for reference.
9.9.2.1 Responsibility of Inventory — This class is responsible for managing and organizing registered Jigs and/or
Implements.
9.9.2.1.1 To complete the responsibility it accepts registration/unregistration of attachments, updating requests and
inquiry. They are defined as services of Inventory in this specification. Service names may be different from above
capabilities.
9.9.2.1.2 Inherent data is used to complete the responsibility. The data is also referred to as attributes and they have
to be defined in some way. This document doesn’t define attributes directly with attribute definition table shown in
some SEMI standard documents but defines them indirectly as service parameters.
9.9.2.1.3 Behavior is also defined to complete the responsibility. Behavior is often represented by collaboration
with outside of this class and state model. Collaboration reflects a part of associations of this class with others.
Collaboration works by asking services defined on accompanying object which is the other end of association on
class diagram. State model is representation of the other part of behavior of this class. However it has to be defined
if this class has explicit state, state model is not defined here because this class is stateless.
9.10 Invoice — Invoice is a set of information for such attachment as Jig or an Implement which is to be
transported to equipment. The information set is sent to the equipment before or after actual attachment has arrived.
If there is something wrong with the attachment or the information on the equipment, equipment ask for new one.
When another attachment or information has arrives, the equipment checks it again.
9.10.1 Invoice Object — Invoice object is created at the time a set of invoice information has received at
equipment. If the equipment has more than one load port for the attachment, port ID may be specified in the
information set. If port ID is not specified, destination port must be anonymous. If more than one attachment IDs or
Load Ports are specified, they are candidate but they are not ordering information nor correspondence between a
couple of sets. However there must be correspondent between attachments and histories. This object is removed at
the time all information has been verified regardless of the result. Invoice object is an instance of Invoice class
defined later. This object is abbreviated as “Invoice” in this document and often ‘object’ is omitted.
SEMI T12-0305 © SEMI 2004, 2005 13
Invoice
showId
showAttachments
showTypes
showLoadPorts
showHistory
Figure 12
Invoice Class
9.10.2 Invoice Class — Invoice Class defines its inherent data, behavior and services. This class provides
information about Jig or Implement to be tracked on equipment. This class is illustrated as above for reference.
9.10.2.1 Responsibility of Invoice — This class is responsible for holding and organizing invoice information as
well as verification. This object verifies physical attachments with invoice information at the time this object has
been created with unverified attachments on equipment or new physical attachment arrives.
9.10.2.1.1 To complete the responsibility it accepts inquiries of inherent information. They are defined as services
of Invoice in this specification. Service names may be different from above capabilities.
9.10.2.1.2 Inherent data is used to complete the responsibility. The data is also referred to as attributes and they
have to be defined in some way. This document doesn’t define attributes directly with attribute definition table
shown in some SEMI standard documents but defines them indirectly as service parameters.
9.10.2.1.3 Behavior is also defined to complete the responsibility. Behavior is often represented by collaboration
with outside of this class and state model. Collaboration reflects a part of associations of this class with others.
Collaboration works by asking services defined on accompanying object which is the other end of association on
class diagram. State model is representation of the other part of behavior of this class. However it has to be defined
if this class has explicit state, state model is not defined here because this class is stateless.
9.11 JitMachine — JitMachine is a piece of equipment with full tracking capability of Jigs and/or Implements.
JitMachie collaborate with Inventory so that the inventory fulfills its responsibility.
9.11.1 JitMachine Object — JitMachine object represents a piece of equipment which completes responsibility for
tracking such attachments as Jigs and/or Implements on equipment. It verifies passed attachments whether they are
right ones to be used on the equipment or not even if they are expected type or compatible. It also let the inventory
know that certain attachments have arrived at the equipment or left for the inventory. JitMachine object is an
instance of JitMachine class defined later. This object is abbreviated as “JitMachi” in this document and often
‘object’ is omitted.
JitMachine
showId
showName
showType
recieveInvoice
showAttachments
showExceptions
Figure 13
JitMachine Class
9.11.2 JitMachine Class — JitMachine Class defines its inherent data, behavior and services. This class is
illustrated as above for reference.