Information Technology Reference
In-Depth Information
:Sale
:CashDesk
sale
complete: Boolean
total: Double
date: Date
Sale(Boolean,set(LineItem),Double,Date)
addLine(LineItem)
getLines( )
setComplete( )
total( )
getTotal( )
makeCashPay(Double amount,Double change)
*
1
1
mode: String
enableExpress( )
disableExpress( )
startSale( )
enterItem(Long code,Long qty)
fin is h Sale( )
cashPay(Double amount,Double change)
cardPay(Card)
1
*
*
*
1
line
CashDesk
1
0..1
sale
*
pay
*
1
1
Sale
complete: Boolean
total: Double
date: Date
mode: String
enableExpress( )
disableExpress( )
startSale( )
enterItem(Long code,Long qty)
fin is h Sale( )
cashPay(Double amount,Double change)
cardPay(Card)
:LineItem
barcode: Long
quantity: Long
subtotal: Double
LineItem(Long,Long)
setSubtotal(Double)
:Payment
1
line s
*
sales
*
*
*
1
0..1
pay
:CashPayment
amount: Double
change: Double
CashPayment(Double,Double)
getChange( )
:CardPayment
card: Card
CardPayment( )
*
Payment
1
line
1
LineItem
barcode: Long
quantity: Long
subtotal: Double
CashPa
y
ment
amount: Double
change: Double
CardPa
y
ment
card: Card
*
*
store
line s
:Store
1
:Product
barcode: Long
price. Double
amount: Long
update(Long)
clock
1
1
find(Long code)
addSale(Sale)
updateInventory(Long code,Long qty)}
getCatalog( )
1
*
:Clock
catalog
store
sales
Item
barcode: Long
price. Double
amount: Long
1
1
1
clock
Store
1
cat
*
connection
Clock
:Bank
issuer
card
1
1
*
1
:Card
conne
c
tion
issuer
card
1
authorize(Card c, Double amount)
Bank
Card
1
*
1
Fig. 8.
Class Diagram of Process Sale
Fig. 9.
Object Diagram of Process Sale
space of the component is the set of the object diagrams and the class diagram.
Fig. 8 shows the class diagram of use case
UC1
and Fig. 9 is an example of an
object diagram.
The execution of an invocation to an interface method changes from one
object diagram to another [14,23]. The behaviour of the use case components
(the methods used above) will be implemented in an
abstract class
,andtheused
methods and arguments indicate its abstract interface:
public abstract class
Cashdesk
implements
SalesHandlerInterface
{
protected boolean
exmode ;
public abstract void
enableExpress();
public abstract void
disableExpress()
public abstract void
startSale ();
public abstract void
enterItem(Barcode code ,
int
qty );
public abstract void
finishSale ();
public abstract void
cardPay(Card c );
public abstract void
cashPay(
double
a;
double
c);
}
Requirements Consistency.
Static consistency between methods in the dia-
grams and the functional specification, their types, and navigation paths must
be consistent. This step is usually done by some tools like a compiler, but is done
manually in the case study due to a lack of machine readable specifications.
Dynamic consistency ensures that the separately specified behavior in the se-
quence diagram, the state diagram and the trace are consistent. Informally, the
consistency must ensure that whenever the actors follow the interaction protocol
defined by the sequence diagram, the interactions will not be blocked by the sys-
tem, i.e. no deadlock should occur. Formally speaking, this requires that the traces
are accepted by the state machine defined by the state diagram. Also, the sequence
diagram should completely define the set of traces that can be accepted by the state
diagram. While, the sequence diagrams specifies the traces in a denotational man-
ner, the state diagram describes the flow of control in an operational semantics and
Search WWH ::
Custom Search