semi合集-English.pdf - 第7731页

SEMI T12-0305 © SEMI 2004, 2005 10 9.6.2.1. 3 Behavior is also defined to complete the responsibility. Behavior is often repr esented by collaboration with outside of this class and state model. Collab oration re flects …

100%1 / 7923
SEMI T12-0305 © SEMI 2004, 2005 9
VALID
EXPIRED
EXPIRY
1
2
3
Figure 6
Expiry State
Table 2 Transition Definition Table of Expiry
# Previous State Trigger New State Actions Comments
1 (No state) Expiry object is created. VALID Watchdog is started.
2 VALID Subject has been expired. EXPIRED Registered special action is
carried out.
3 EXPIRED The action is started. (No state)
9.5 History — History is the concept to track what happens on Jigs and/or Implements and how they are used. A
few object classes are modeled to complete this capability.
9.6 HistoryBuffer — HistoryBuffer is tentative history information of a Jig or Implement on equipment. The
information is reported to Inventory periodically or at some milestones. When it is reported, the information is
cleared for new information.
9.6.1 HistoryBuffer Object — HistoryBuffer object represents buffer area of tentative history information of an
attachment on equipment. It is created at the time an attachment is created and destructed after the attachment is
removed. HistoryBuffer object is an instance of HistoryBuffer class defined later. This object is abbreviated as
“HistoryBuffer” in this document and often ‘object’ is omitted.
HistorBuffer
show
A
ttachment
showHistory
updateHistory
showReleaseCondition
setReleaseCondition
showState
destruct
Figure 7
HistoryBuffer Class
9.6.2 HistoryBuffer Class — HistoryBuffer Class defines its inherent data, behavior and services. This class is
illustrated as above for reference.
9.6.2.1 Responsibility of HistoryBuffer — This class is responsible for keeping temporary history information of Jig
or Implement on equipment and clear the information after it is reported to Inventory.
9.6.2.1.1 To complete the responsibility it accepts information what happens on an attachment or how it is used
including period or cycle. It also accepts inquiries. They are defined as services of HistoryBuffer in this
specification. Service names may be different from capabilities above.
9.6.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.
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.