Harnessing rCOS for Tool Support—The CoCoME Experience - Formal Methods and Hybrid Real-Time Systems - page 97

(a) If by cash, the cashier enters the amount received from the customer, and
the system records the cash payment amount and calculates the change.
The cashier gives the change to the customer.
(b) If the customer chooses to pay by a credit card, the cashier enters the
card information (manually or by the card reader). The system sends
the credit payment to the bank for authorization . The payment can only
be made if a positive authorization reply is received.
The inventory of the sold items is updated and the completed sale is logged
in the store .
7. The customer leaves with the items they purchased at the end of the process.

There are exceptional courses of interactions. For example, the entered bar code
is not known in the system, the customer does not have enough money for a
cash payment, or the authorization reply is negative. Systems need to provide
means of handling these exception cases, such as canceling the sale or changing
to another way of paying for the sale. At the requirements level, we capture these
exceptional conditions as preconditions.
Other use cases include UC2 : Order products , that orders products from the
supplier; UC3 : Manage inventory , that includes changing the amount of an
item (after receiving deliveries from the product supplier), changing the price
of a product, and adding a new product, and deleting a new product; UC4 :
Produce monthly reports on sales that is to show the reports of all sales in the
last 30 days and information of profit and loss; and UC5 : Produce stock reports ,
that produces the reports on stock items.

3.2 Development of POST with rCOS

There has been a wide view that object-oriented and component-based design
should be bottom up. We in fact take a use-case driven, incremental and iterative
Rational Unified Development Process [18].

The Sketch of the Development Process. In each iteration, a number of use
cases are captured, modeled and analysed at the requirements stage. Each use
case is modeled as a contract of a component that provides services to the actors
of the use case. The fields of the contract declare the domain objects involved
in the realization of the use case. The classes of these objects are organized
as a class diagram representing the structural view of the data and objects of
the components. The contracts should be analyzed and the consistency of the
contracts should be checked.
The contracts of the use case components are then designed and organised into
bigger components to form the component-based architecture for the application
software components with identified object-oriented interfaces .Wecallthisstep
the logical design of the iteration. This involves object-oriented refinement of
each use case component, identifies interactions among objects in different com-
ponents, and composes components (i.e. use cases) by simple connectors. The
resulting model is the logical component model .