1.

Activity Diagram for Make Order Request

Use case name: Make Order Request

Summary: Customer enters an order request to purchase items from the online shopping system. The
customer’s credit card is checked for sufficient credit to pay for the requested catalog items.

Actor: Customer

Precondition: The customer has selected one or more catalog items.

Main sequence:

1. Customer provides order request and customer account Id to pay for purchase.

2. System retrieves customer account information, including the customer’s credit card details.

3. System checks the customer’s credit card for the purchase amount and, if approved, creates a credit
card purchase authorization number.

4. System creates a delivery order containing order details, customer Id, and credit card authorization
number.

5. System confirms approval of purchase and displays order information to customer.

Alternative sequences:

Step 2: If customer does not have account, the system creates an account.

Step 3: If the customer’s credit card request is denied, the system prompts the customer to enter a
different credit card number. The customer can either enter a different credit card number or cancel the
order.

Post condition: System has created a delivery order for the customer.

Activity Diagram for Make Order Request

1|Page
 2. Major elements of simple domain model diagram and its components

2|Page
 3. Communication Diagram
As an example of using a communication diagram to depict the objects that participate in a use
case, consider the View Alarms use case from the Emergency Monitoring System case study
(Figure 9.1), in which a Monitoring Operator views out-standing alarms. The communication
diagram for this simple use case consists of only two objects: a user interaction object and a
service object. The user interaction object is called Operator Interaction. The service object is
called Alarm Service.
The communication diagram for this use case depicts the user interaction object, Operator
Interaction, making a request to the service object, Alarm Service and receiving a response.

3|Page
 4. Sequence diagram for online library management system use case
the sequence diagram shows the order of messages sent sequentially from the top to the bottom of
the diagram, numbering the messages is not essential. In the following example, however, the
messages on the sequence diagram are numbered to show their correspondence to the
communication diagram.

The sequence diagram below shows how the objects in the online library management system
interact with each other to perform the function ‘Create New Library User Account’.

4|Page
 5. State chart Diagram
Consider an example, shown in below, of a partial state chart for an automated teller machine. The
initial state of the ATM state chart is Idle. Consider the scenario consisting of the customer inserting the
card into the ATM, entering the PIN, and then selecting cash withdrawal. When the Card Inserted event
arrives, the ATM state chart transitions from the Idle state to the Waiting for PIN state, during which
time the ATM is waiting for the customer to input the PIN. When the PIN Entered event arrives, the ATM
transitions to the Validating PIN state. In this state the bank system determines whether the customer-
entered PIN matches the stored PIN for this card, and whether the ATM card has been reported lost or
stolen. Assuming that the card and PIN validation is successful (event Valid PIN), the ATM transitions
into Waiting for Customer Choice state.

It is possible to have more than one transition out of a state, with each transition caused by a different
event. Consider the alternative transitions that could result from PIN validation. It shows three possible
state transitions out of the Validating PIN state. If the two PIN numbers match, the ATM makes the Valid
PIN.

5|Page
 6. Examples of a Software System Context Class Diagram from External Classes.

An example of a software system context class diagram is shown below, which shows the external
classes to which the Banking System has to interface. The external classes are determined directly
from the static model of the problem domain as described previously. Furthermore, the external
classes are categorized by stereotype, as described next.

In this example, three of these I/O devices are categorized as external device classes: the Card
Reader, the Receipt Printer, and the Cash Dispenser. The ATM Customer Keypad/Display external
class is categorized as an external user class because it is a standard I/O device. The Operator
external class is also categorized as an external user class for the same reason. Because there is one
instance of each of these external classes for each ATM and there are many ATMs, there is a one-to-
many association between each external class and the Banking System. The software system context
class diagram in which external classes are depicted using stereotypes below. Depicting the external
class stereotype explicitly on the software system context class diagram visually describes the role

6|Page
 played by each external class of the system. Thus, it is immediately obvious which classes represent
external output devices and which classes represent external users.

7. Major elements of UML use case diagram Use case Model

7|Page
 8. The  Pizza  Ordering  System Scenario

The  Pizza  Ordering  System  allows  the  user  of  a  web  browser  to  order  
pizza  for  home  delivery.    To  place  an  order,  a  shopper  searches  to  find  
items  to  purchase,  adds  items  one  at  a  time  to  a  shopping  cart,  and  
possibly  searches  again  for  more  items.      
When  all  items  have  been  chosen,  the  shopper  provides  a  delivery  
address.    If  not  paying  with  cash,  the  shopper  also  provides  credit  card  
information.  
thesystem  has  an  option  for  shoppers  to  register  with  the  pizza  shop.  They  can  then
save  their  name  and  address  information,  so  that  they  do not  have  to  enter  this
informa7on  every  time  that  they  place  an  order.    
Develop a use case  diagram,  for  a  use  case  for  placing  an  order,  PlaceOrder.    
The  use  case  should  show  a  relationship  to  two  previously  specified  use  
cases,  Identify Customer,  which  allows  a  user  to  register  and  log  in,  and  
PaybyCredit,  which  models  credit  card  payments.  

8|Page
9|Page