Tutorial Material BISM7255 Business Information Systems Analysis and Design Tutorial 1 – Use Case Diagrams BISM 7255 — Business Information Systems Analysis and Design Page 1 Knowledge Sheet for Use Case Diagrams 1 Definition Use Case Diagrams capture use cases and relationships among actors and the system; they describes the functional requirements of the system, the manner in which external operators interact at the system boundary, and the response of the system. (Source: https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/use-case- diagram/) 2 Model Notations 2.1 System (System Boundary) System can be understood as the context of the use case in which the use cases of specific actions are executed. System can be a class or a component which represents the entire application. The system is represented by one or more system frames (system boundaries), shown as a rectangle with its name and a set of Use Cases visually located inside this rectangle. Figure 1 Example of System Boundary (Source: https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/use-case- diagram/) 2.2 Actor An Actor is defined as a role outside of the corresponding use case system, and which interacts with the system within the context of the use case. The Actor represents roles, which may include human users who use the system, machines, external hardware, other systems or subsystems that access the system. For example, the role “Customer” represents any person being a customer of the bank. Figure 2 shows two different notations of an actor. An actor is usually drawn as a named stick figure, or alternatively as a class rectangle with the actor keyword. BISM 7255 — Business Information Systems Analysis and Design Page 2 Figure 2 Example of an Actor Generalization: A generalization is a taxonomic relationship between a more general classifier and a more specific classifier. The specific classifier (e.g., actor) inherits the features of the more general classifier (e.g., super actor). Actors can generalize other actors as shown in Figure 3. Figure 3 Example of an Actor and a Specialized Actor (Source: https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/use-case-diagram/ https://sparxsystems.com/resources/tutorials/uml2/use-case-diagram.html) 2.3 Use Case A Use Case is a UML modeling element that describes how a user of the proposed system interacts with the system to perform a discrete unit of work. A use case is illustrated as an ellipse containing the name of the use case. The name of the use case is typically formed by a verb and noun(s) whereby the object to be manipulated and the activity to be carried out are described in a clear and concise manner. Figure 4 Example of a Use Case (Source: https://sparxsystems.com/resources/user-guides/15.0/model-domains/uml-models.pdf https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/use-case-diagram/ https://www.sparxsystems.com/resources/tutorials/uml2/use-case-diagram.html ) BISM 7255 — Business Information Systems Analysis and Design Page 3 2.4 Use Case Relationships Use cases can also be reliant on one another. There are two types of relationships between different use cases – “Include” relationship and “Extend” relationship. 2.4.1 Include Relationship An “Include” relationship reflects that one Use Case includes the behavior of another. It represents a compulsory relationship and is therefore often referred to as “must- relationship”. Use cases may contain the functionality of another use case as part of their normal processing. It is assumed that any included use cases will be called every time the basic path is run. An “Include” relationship is illustrated by a dashed arrow with open point in the direction of the use case to be included. The key word <> is noted for the arrow. An actor must NOT necessarily be linked to the included use case. An example of this is to have the execution of the included use case Language> to be run as part of an including use case , as shown in Figure 5. Figure 4 Example of a Include Relationship (Source: https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/use-case- diagram/) 2.4.2 Extend Relationship An “Extend” relationship specifies that the behavior of a Use Case may be extended by the behavior of another (usually supplementary) Use Case; this is typically used in exceptional circumstances. An “Extend” relationship is indicated by connecting the use cases with a dashed arrow pointing from an extending Use Case towards the extended Use Case, at a specific point in the behavior flow identified within the element by an extension point. The arrow is labeled with the extend stereotype. Condition (mandatory): A use case is extended by another under a specific condition. The condition of the “Extend” is shown in a Note symbol attached to the corresponding arrow. Note that the condition MUST be specified in an <> relationship. Extension point (optional): The extension point is represented by a text string and shown in a Note symbol attached to the corresponding arrow, such as ‘on startup’ or ‘before connection is established’. BISM 7255 — Business Information Systems Analysis and Design Page 4 Figure 6 Example of an Extend Relationship (Source: https://www.sparxsystems.com/resources/tutorials/uml2/use-case-diagram.html https://sparxsystems.com/resources/user-guides/15.0/model-domains/uml-models.pdf https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/use-case-diagram/) 3 Model Creation Procedure 1) Identify actors, use cases, and relationships from a given business scenario. 2) Create a new project in Enterprise Architect. 3) Model the use case diagram in Enterprise Architect. Create Actors (role of users) of the system. Create use cases for each functional requirement identified. Structure the use cases. Determine the relationships between Actors and Use Cases. Determine any “Extend” and “Include” relationships. 4 Example of Use Case Diagram A customer wishes to withdraw money from an automatic teller with a bank card. The actor named customer plays this role and is the generalization for the own bank customer and third-party bank customer. The specialized actors communicate via the role of the customer with the identify card use case which proceeds equally for both types of customer. This use case contains the use case validate account and PIN, whereby the right of the customer to use the card is assessed. If an incorrect PIN has been repeatedly entered, the card is withdrawn. To model this, the use case identify card is extended by the use case impound card. This is executed only under the condition that the customer repeatedly entered the incorrect PIN. Both actors, own bank customers and third-party bank customers, communicate directly (and not via the role of customer) with the use case pay cash. This procedure varies between these two types of customer; i.e. the highest withdrawal amount and/or fees per transaction can vary. BISM 7255 — Business Information Systems Analysis and Design Page 5 5 Modeling of the Example Step by Step Step Action 1 Identify actors, use cases and relationships from the case description. 2 Create a new project and a use case diagram in EA: 1) Start Enterprise Architect. 2) Click on the icon in the upper-left corner, and click on the ‘New Project’ option. 3) Locate a suitable folder (H: drive) for your project, and give a distinctive name in the ‘File name’ field. 4) Click on the icon in the Browser window toolbar. When the Model Wizard window displays, you click on the ‘Diagram’ tab. 5) In the left hand column header, select ‘UML Behavioral’ and scroll down to ‘Use Case Diagrams’. 6) Select ‘Use Case’ à Tick ‘Create Package’ à Click on the ‘Create Diagram’ button. 3 Model Actors, System Boundary, Use Cases and the relationships among the Use Cases based on the example case description. Note: For detailed steps of creating a Use Case Diagram, please find the video in Blackboard ‘Tutorial 1 – Use Case Diagram Example Video’. 6 Final Example Model Figure 7 Example Model BISM 7255 — Business Information Systems Analysis and Design Page 6 7 Tips and Tricks A use case captures a functionality of the system, for example, “Place Order” indicates that the actor uses the system to place order(s). Note that “Eat Food” is NOT a use case because it is not a function of the system. The use case must be named in ‘verb–noun’ form. For the name of any actors and use cases, the first letter of each word should be capitalised, e.g., Place Order. A use case can be used by more than one actors. The actor represents roles, this means that it cannot be a person’s name. The automation boundary is compulsory as well as its name. The first letter of each word in the system name must be capitalized. In an “Extend” relationship, the condition MUST be specified in a Note symbol attached to the arrow. No order of appearance of described activities/services is shown. 8 In-Class Exercises 1) The Healthy Life Clinic, a provider of medical check-ups for Australia visa applicants, is automating their patient information system. The would-be system is expected to improve the Clinic’s service to customers. The business processes to be captured by the system are as follows. It is your task to create a Use Case diagram to document these functions. Patients are entered into the system by the front desk personnel. For first-time patients, the front desk personnel will collect and enter insurance and basic demographic information. For the regular patients, the front desk personnel will verify if the patients’ information is correct and update it if a change is required. The front desk staff then ensures that the patient has a chart in the electronic medical record system; and if not, a new medical record is created. The patient is then entered into a queue by the front desk staff to wait for a nurse who will collect a health story, weight, height, temperature, blood pressure, and any other relevant medical information, then update the patient’s medical record. Next, the patient is placed into the queue by the nurse to see a doctor. The first available doctor sees the patient, does the required medical check-up and update patient details if need it, and sends the patient to the checkout. The person at the checkout counter collects and records the payment for the services and provides a printed receipt for the service provided. 2) When a customer places a delivery order, a restaurant employee records the order in the system. The employee captures details such as customer name, address, phone number, and items ordered. After the order is recorded the customer can track its status. The employee needs to send the order information to different people with the option to print them. The order information is sent to the kitchen and the status is updated when the order is ready for delivery. When the order is prepared, the delivery person updates the status, delivers the order to the customer and collects payment. Upon arriving at the restaurant, the delivery person updates the order status and gives the payment to the restaurant manager. Each evening the restaurant manager reconciles the order tickets with the delivery payments. Then, he/she uses the data to update the goods sold and inventory files. BISM 7255 — Business Information Systems Analysis and Design Page 7 3) Customers place orders to the nursery by call. A sales representative takes the order, verifies the customer’s credit standing, determines whether the items are in stock, informs the customer if any special discounts are in effect, and communicates the total payment due. If the customer meets the credit requirement and he/she is satisfied with the availability of the item(s) and discounts, the order is entered into the system. If the customer is first-time customer, a new customer account is created. If a regular customer, the customer’s account is then updated, product inventory is adjusted, and ordered items are pulled from stock. If the items are not in stock, the salesperson updates sale item as on back order. Ordered items are then packed and shipped to the customer. Once a month, a billing statement is generated and sent to the customer. The customer has thirty days to remit the payment in full; otherwise, a 15% penalty is applied to the customer’s account. 9 References 1) https://www.sparxsystems.com/resources/tutorials/uml2/use-case-diagram.html 2) https://sparxsystems.com/resources/user-guides/15.0/model-domains/uml- models.pdf 3) https://www.sparxsystems.eu/resources/project-development-with-uml-and- ea/use-case-diagram/ 4) https://www.omg.org/spec/UML/2.5.1/PDF
