Software Design and Architecture - T.Y. Computer 2024-2025 PDF

This document is for private circulation only, For T. Y. Computer 2024-25 CCEW students. Subject: Software Design and Architecture PLEASE refer TO ALL REFERENCES plus Study Material CIRCULATED. Feel free to use additional web sites/searches for understanding if required.  ACKNOWL...

This document is for private circulation only, For T. Y. Computer 2024-25 CCEW students. Subject: Software Design and Architecture PLEASE refer TO ALL REFERENCES plus Study Material CIRCULATED. Feel free to use additional web sites/searches for understanding if required.  ACKNOWLEDGEMENT This presentation contains pictures, contents taken from multiple sources, authors and sites. We would like to appreciate and thank the authors, artists and do not claim any of following work to be ours, but it has been compiled here to use for academic purpose only.  Use Case Diagram – Scope / Topics Use Case Diagram – Concepts, Notations, Examples - Actors and Use cases: association - System boundary - Generalization among the actors - Relationships among the use cases: : extension point generalization - Use case specification / template - Modeling the context of a system - Modeling the requirements of a system  Use Case Diagram Ref: Grady Booch, James Rumbaugh, Ivar Jacobson, 'The Unified Modeling Language User Guide', Pearson Education, (2nd edition)(2008). Chapters : 17. Use cases 18. Use case diagrams Use Case Diagram Use cases of Wheel Tyre Use cases for Document Editor  The importance of requirements Project Failures Incomplete requirements Lack of user involvement Lack of resources Unrealistic expectations Lack of executive support Changing requirements Lack of planning Didn't need it any Incomplete requirements are the primary longer reason that projects fail! The Standish Group, "The CHAOS Report (1994) "  Use case modelling Use case modelling is a form of requirements engineering Use case modelling proceeds as follows: – Find the system boundary – Find actors – Find use cases Use case specification Scenarios It lets us identify the system boundary, who or what uses the system, and what functions the system should offer  What are requirements? Requirements - “A specification of what should be implemented”: – What behaviour the system should offer – A specific property of the system – A constraint on the system The SRS consists of: – Requirements model comprising functional and non-functional requirements – Use case model comprising actors and use cases  What are use cases A technique for capturing functional requirements of systems and systems-of-systems. First described in 1987 by Jacobson According to Bittner and Spence, "Use cases, stated simply, allow -description of sequences of events that, taken together, lead to a system doing something useful/significant“.  What are use cases? A use case is something an actor needs the system to do. It is a “case of use” of the system by a specific actor Use cases are always started by an actor – The primary actor triggers the use case – Zero or more secondary actors interact with the use case in some way Use cases are always written from the point of view of the actors PlaceOrder GetStatusOnOrder Requirements (Customer)  Identifying use cases Start with the list of actors that interact with the system When identifying use cases ask: – What functions will a specific actor want from the system? – Does the system store and retrieve information? If so, which actors trigger this behaviour? – Are any actors notified when the system changes state? – Are there any external events that affect the system? What notifies the system about those events?  KEY Concepts in use cases DEFINING SYSTEM BOUNDARY ACTORS and specializations – Human, roles, subsystems, external entities INCLUDE EXTEND USECASES – Abstract versus concrete Notation System boundary  The use case diagram Mail Order System use case diagram Mail Order System subject name communication relationship system boundary Place Order Ship Cancel Order Product ShippingCompany Check Order Customer Status Send actor Catalogue use case Dispatcher  What are actors? An actor is anything that interacts directly with the system – Actors identify who or what uses the system and so indicate where the system boundary lies Actors are external to the system An Actor specifies a role that some external entity adopts when interacting with the system «actor» Customer Customer  Identifying Actors When identifying actors ask: – Who or what uses the system? – What roles do they play in the interaction? – Who installs the system? – Who starts and shuts down the system? – Who maintains the system? – What other systems use this system? – Who gets and provides information to the system? – Does anything happen at a fixed time? Time  Why use cases Vehicle to capture requirements – And INVOLVE USERS Vehicle for validations and Vehicle for testing Vehicle to identify classes, Sequence diagram. i. e. Design Vehicle for project allocation too, managing iterations.. HENCE one of Best Practice is USE CASE DRIVEN APPROACH  What are use cases Not They are not internal functionality They are not functions They are not single line messages They are not overview kind Not isolated DO NOT CAPTURE NONFUNCTIONAL REQUIREMENTS USECASE DIAGRAMS DO NOT DEPICT SEQUENCE generally Internal versus external functionality  Use Case- Characteristics Describe how the system shall be used by an actor to achieve a particular goal. Hence use cases should have narration too. Single goal/things that happen in reaching the goal. HAVE TO BE NAMED in PRESENT TENSE VERB PHRASE IN ACTIVE VOICE. One aspect of system without assumptions about implementation-specific , design specific. Be at the appropriate level of detail. Use cases treat the system as a black box.  Use case specification use case name Use case: PaySalesTax use case identifier ID: 1 brief description Brief description: Pay Sales Tax to the Tax Authority at the end of the business quarter. the actors involved in the Primary actors: use case Time Secondary actors: TaxAuthority the system state before Preconditions: the use case can begin 1. It is the end of the business quarter. Main flow: implicit time actor the actual steps of the use 1. The use case starts when it is the end of the business quarter. case 2. The system determines the amount of Sales Tax owed to the Tax Authority. 3. The system sends an electronic payment to the Tax Authority. the system state when the Postconditions: use case has finished 1. The Tax Authority receives the correct amount of Sales Tax. alternative flows Alternative flows: None.  Methodology - Process Find Actors Find Use Cases Organize the Model Prioritize Use Cases Describe Use Cases Refactor the Model  Use Case- Types Business Use case System Use Case  When to use use case analysis Use cases describe system behaviour from the point of view of one or more actors. They are the best choice when: – The system is dominated by functional requirements – The system has many types of user to which it delivers different functionality – The system has many interfaces Use cases are designed to capture functional requirements. They are a poor choice when: – The system is dominated by non-functional requirements – The system has few users – The system has few interfaces 1a. If client clicks "Open Orders" link Client views open orders 1b. If client clicks "View history" link Client views history  Few mistake scenarios Tricks and Tips  ACKNOWLEDGEMENT This presentation contains pictures, contents taken from multiple sources, authors and sites. We would like to appreciate and thank the authors, artists and do not claim any of above work to be ours, but it has been compiled here to use for academic purpose only.