Professional Documents
Culture Documents
Activity Diagram For Make Order Request: Use Case Description
Activity Diagram For Make Order Request: Use Case Description
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
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.
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.
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|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