semi合集-English.pdf - 第7732页

SEMI T12-0305 © SEMI 2004, 2005 11 9.7.2.1. 1 To complete the responsibility it accepts adoption/re set of attachment histor y, updating re quests and inquiry. They are de fined as services of HistoryDB i n this specifi …

100%1 / 7923
SEMI T12-0305 © SEMI 2004, 2005 10
9.6.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. Because this class has
explicit state, it defines following states and state model by state chart and transition definition table.
9.6.2.1.3.1 Empty — No history information is accumulated.
9.6.2.1.3.2 Buffered — Some history information are accumulated and they are not reported.
EMPTY BUFFERED
HISTORYBUFFER
1
2
4
3
Figure 8
HistoryBuffer State
Table 3 Transition Definition Table of HistoryBuffer State
# Previous State Trigger New State Actions Comments
1 (No state) A Secondment has been
created.
EMPTY
2 EMPTY History information is put. BUFFERED The information has to be
reported at some moment.
3 BUFFERED History information is
reported and buffer area is
cleared.
EMPTY The information has to be
reported before it is cleared.
4 EMPTY Corresponding Attachment
has been removed.
(No state)
9.7 History Data Base — HistoryDB is an interface of whole history information for application.
9.7.1 History Data Base object — History Data Base object keeps history data of all Jigs and Implements in a
Inventory. History Data Base object is an instance of History Data Base class defined later. There is just one
History Data Base object corresponding to a Inventory. This object is abbreviated as “HistoryDB” in this document
and often ‘object’ is omitted.
HistoryDB
update
reset
adopt
disown
listRecord
showHistor
y
Figure 9
HistoryDB Class
9.7.2 History Data Base Class — HistoryDB Class defines its inherent data, behavior and services. This class
manages history of all Jigs and Implements in an Inventory. This class is illustrated as above for reference.
9.7.2.1 Responsibility of HistoryDB — This class is responsible for managing and organizing history information
for all Jigs and/or Implements registered in an Inventory.
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.