Week 3.1 Software Modelling PDF

Week 3.1: Software Modelling (Part 1) Building Usable Software 2023-2024 What does UML include? Use What You Need. Probably You Don’t Need Everything. Use Case Diagram Visually represent the interactions between...

Week 3.1: Software Modelling (Part 1) Building Usable Software 2023-2024 What does UML include? Use What You Need. Probably You Don’t Need Everything. Use Case Diagram Visually represent the interactions between actors (users or external systems) and a system. Used to define, understand, and communicate the functional requirements of a system. Goal Help users (developers, designers, customers, etc.) understand the system functionality from a user’s perspective. Gathering and documenting functional requirements. Communicate and discuss system functionality with different stakeholders. Drive implementation & generate test cases against the specified requirements. Use Case: Elements Actors: Internal or external users that interact with the system (e.g., human, organization, machine or other external system.) Use cases: Actions or functions the system needs to perform to meet its goals (FR). 1. Relationships: Connections/interactions between users and use cases (dependencies, generalizations, and associations). 2. System boundary: Box around the use cases/separate use cases (internal) from the actors (external). How can we identify the key elements of a use case diagram? FR can guide us in identifying the actors, use cases, and relationships. How to find actors? Roles played by people (system’s users). Also could be other systems. What role do they play? Who provides information to the system? (inputs) Who receives information from the system? (outputs) Actors could be: Principal users Secondary (External hardware, other systems, …) Interacts with use case (system function). Named by noun. Note: Actors are roles played by people (one person may play multiple roles). Actors may also be another system. Actors and use cases each have names. How to find use cases? Start with the list of actors and consider What do they need from the system (i.e. what use cases there are that have value for them) Any other interactions they expect to interact with the system (i.e. which use cases they might take part in for someone’s else benefit) Use cases Named by verb + Noun (or Noun Phrase). Each Actor must be linked to a use case, while some use cases may not be linked to actors. Exercise: CoffeeApp 1. (start) Customer start app on his phone and logs in. 2. Customer picks preferred store. 3. Customer enters coffee choice. 4. App asks if “he would like anything else.” 5. Customer selects “checkout.” 6. App asks for payment. 7. Customer enters credit card number. 8. App validates the order. 9. Once done, App sends the order to the POS machine at the preferred store and leaves a confirmation message in the customer’s email inbox (end). Exercise: Coffee App 1. (start) Customer start app on his phone and logs in. Login 2. Customer picks preferred store. 3. Customer enters coffee choice. Pick 4. App asks if “he would like anything else.” store Validate 5. Customer selects “checkout”. Place Login 6. App asks for payment. order Validate 7. Customer enters credit card number. order App 8. App validates the order. Pay for 9. Once done, App sends the order to the POS order machine at the preferred store and leaves a Pick up confirmation message in the customer’s email order inbox (end). Exercise: CoffeeApp The system boundary is optional. Use cases are inside the system. Actors are outside the system. Which relationships to use? Use for optional or alternatives on normal behaviour, declaring your extension points in the base use case (optional). Use to show uses, complementary functionalities, and logical dependencies, or avoid repetition when you are repeating yourself in two or more separate use cases (must). Use when you are describing a variation on normal behaviour, or inheritance relations. Verify password Log in Display login error Relation: Model optional system behaviour and conditions. Extending a use case may add behaviour to the base use case, but… The extended use case is meaningful on its own as it is independent of the main use case. Option 1 selected Pay by Note: Dotted line. The tip of the paypal arrowhead points to the base use Select case from the child use case. payment option Pay by Library Option 2 selected credit/debit member Invalid card Login password Alternative/options: Library member has a fine to pay. High level  Low level S/he can select two options(PayPal or credit/debit card) Relation: Child use case must be done to complete parent use case. Put common event flows into a use case and then include it into the behaviour of the (base) use case to avoid repetitive descriptions. is used to: Simplify large use cases by splitting them into several use cases. Represent common parts of the behaviours of other use cases. Note: Depicted with a directed arrow having a dotted line. The tip of the Parent use case Child use case arrowhead points to the child use case from the parent use case. Common functionality Relation: Generalization The parent-child relationship between use cases. The child use case inherits behaviour and meaning from the parent use case. The child may add or override parent behaviour (enhancement of the parent use case). Note: Directed arrow with a triangle arrowhead. The child use case is connected at the base of the arrow. The tip of the arrow is connected to the parent use case. Both actor and use case may be generalized.  Activity: / Apply Place Request order discount Search a book Customer Student Update delivery address Enroll in Enroll in Order UoB Canvas product Student Order Pay Perform product order Security heck Admin Request Int. Student catalog Tips: Use Case Diagram Use case diagram Tips: Use Case Diagram Always structure and organize the use case diagram from the perspective of actors. Use cases should start off simple and at the highest view possible. Only then can they be refined and detailed further. Use case diagrams are based upon functionality and thus should focus on the "what" and not the "how". UML tools https://app.diagrams.net/ https://www.lucidchart.com/pages/ https://staruml.io/ Use Case Specification Use Case Specification Detailing the steps and interactions required to implement a specific use case. Describe in detail the interactions between users and the system using a graphical model and structured text. It has two elements: Actors: A person, system, or organization that interacts with the system. Scenarios (Flow of events): Structure form of user story. A specific sequence of actions and interactions between actors. It captures the FUNCTIONAL requirements. A USE CASE typically includes the following information Name: The name of the use case. Description: A brief description of the role and purpose of the use case. Actors: Identify the actors involved in the use case (users, external systems or entities that interact with the system. Preconditions: Conditions that must be true for the use case to being. Starting point for the scenarios. Flow of events: Describe the primary sequence of steps that occur during the execution of the use case. Find the core scenario. The flows can include a basic flow (main scenario), alternative flows, and sub-flows. Key scenarios: A textual description of the most important or frequently discussed scenarios. Special Requirements: A textual description that collects all of the requirements of the use case that are not considered in the use-case model, but that must be taken care of during design or implementation (for example, non-functional requirements). Post-conditions: A textual description that defines a constraint on the system when the use case ends. Alternate flows: Variations or exceptions that may occur during the execution of the use case. Each alternate flow represents a different scenario. Template: Use Case Specification Each Use Case shown in a diagram should be accompanied by a textual specification. Example: Use Case Specification Name: Borrow a copy of book Actors:…. Description:…. Precondition 1. the BookBorrower is a member of the library 2. the BookBorrower has not got more than the permitted number of books on loan Flow of events 1. the use case starts when the BookBorrower attempts to borrow a book 2. the librarian checks it is ok to borrow a book 3. If …… (indicate an alternative path of action) Post-conditions 1. the system has updated the number of books the BookBorrower has on loan Alternate flows …. Exercise: SmartBank Read the SmartBank description, and draw 2 use case diagrams: 1) The first diagram should depict your entire system; 2) The second diagram should explain a critical/complicated process of the system e.g. deposit and transfer money. Exercise: SmartBank Tips: Use Case Diagram Class diagram