Page 126 -

AGENT-ORIENTED INFORMATION SYSTEMS ANALYSIS AND DESIGN 111
Figure 7.9 Partial Class Diagram for Store Front

CartForm ShoppingCart
CustomerProfiler
<<Text>> itemCount : integer itemCount : integer
<<Text>> qty[0..*] : integer tax : currency On-line
<<Text>> currentTotal : currency taxRate : float Catalogue
total : currency
0..* <<Checkbox>> selectItem[0..*] totWeight : single
<<Submit>> Checkout shippingCost : currency
CustomerProfileCard <<Submit>> AddItem qty[0..*] : integer 0..*
<<Submit>> Confirm subTotals[0..*] : currency
customerid : long <<Button>> Cancel itemCount() notification() MediaItem
customerName : string <<Button>>Recalculate calculateTotals() id : long
firstName :string getCart() calculateQty() itemNbr : string
middleName : string computeWeight() itemTitle : string
address : string buildItemTable() getLineItem() inform() itemBarCode : OLE
writeTableRow()
tel : string initializeReport() itemPicture : OLE
e-mail : string updateItems() Plans : category :string
dob : date loadCartForm() initialize refuse genre : string
profession : string updateCartForm() selectItem propose description : string
succeded
addItem
salary : integer killCartForm() checkout removeItem editor : string
maritalStatus : string 0..* cancel confirm publisher : string
familyComp[0..1] : integer CustomerData logout failure date : date
internetPref[0..10] : boolean 1 ItemLine 0..* verifyCC unitPrice : currency
entertPref[0..10]:string not_understood weight : single
getIdentDetails
hobbies[0..5] : string 0..*
comments : string id : long 0..* ItemDetail 1
qty : integer
creditcard# : integer allowsSubs :boolean
prevPurchase[[0..*] [0..*]]
: string weight() DVD Book Video ... CD CDrom
prevPurchPrice[[0..*] [0..*]] cost()
: integer
is sent to Shopping Cart, which must respond before a given timeout (for network security and
integrity reasons). The response may refuse to provide a proposal, submit a proposal, or express
miscomprehension. The diamond symbol with an “X” indicates an “exclusive or” decision. If a
proposal is offered, Customer has a choice of either accepting or canceling the proposal.
At the lowest level, we use plan diagrams (Kinny and Georgeff, 1996) to specify the internal
processing of atomic actors. Each identified plan is specified as a plan diagram, which is denoted
by a rectangular box. The lower section, the plan graph, is a state transition diagram. However,
plan graphs are not just descriptions of system behavior developed during design. Rather, they
are directly executable prescriptions of how a BDI (belief-desire-intention) agent should behave
(execute identified plans) in order to achieve a goal or respond to an event.
The initial transition of the plan diagram is labeled with an activation event (Press checkout
button) and activation condition ([checkout button activated]), which determine when and in what
context the plan should be activated. Transitions from a state automatically occur when exiting
the state and no event is associated (e.g., when exiting Fields Checking) or when the associated
event occurs (e.g., Press cancel button), provided in all cases that the associated condition is true
(e.g., [Mandatory fields filled]). When the transition occurs, any associated action is performed
(e.g., verifyCC()).
The elements of the plan graph are three types of node: start states, end states, and inter-
nal states; and one type of directed edge: transitions. Start states are denoted by small filled
circles. End states may be pass-or-fail states, denoted respectively by a small target or a small
no-entry sign. Internal states may be passive or active. Passive states have no substructure and
are denoted by a small open circle. Active states have an associated activity and are denoted by
rectangular boxes with rounded corners. An important feature of plan diagrams is their notion
of failure. Failure can occur when an action upon a transition fails, when an explicit transition