lec 27 [use case diagrams]
TRANSCRIPT
![Page 1: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/1.jpg)
Object Oriented Design & Analysis - Introduction
![Page 2: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/2.jpg)
Overview of Key Concepts
• Object & Classes
• Abstraction, encapsulation, and interface
• Introduction to UML
![Page 3: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/3.jpg)
Objects & Classes
• An object is anything that a system is interested in
• Objects have attributes and behavior
• A class is a blueprint for creating objects having the same set of attributes and behavior
• Characteristics of OO Systems– Abstraction
– Encapsulation
– Interface
![Page 4: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/4.jpg)
Abstraction, Encapsulation, and Interface
• ABSTRACTION = what an object is/ what an object does– Example: ATM device
• Dispenses cash to valid customer• Reports current balance of a customer• Allows fund transfer from one account to another
• ENCAPSULATION = how an object does what it does– Example: ATM device
• How it connects to the bank’s database to verify balance• How it counts currency to dispense
• INTERFACE = how the clients of an object talk to it– Example: ATM device
• The slot for inserting the ATM card• The buttons for the users to specify their options
![Page 5: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/5.jpg)
EXERCISE
• What is the abstraction of a car?
• What is encapsulated?
• What is the interface?
![Page 6: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/6.jpg)
More Formally
• Abstraction = externally visible behavior of an object
• Encapsulation = the internal data structure and implementation that gives rise to the externally visible behavior of an object
• Interface = set of public functions of a class
![Page 7: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/7.jpg)
The Unified Modeling Language (UML)
• What is modeling?– Understanding, visualizing, specifying, and documenting
the requirements of a software system and the way we plan to fulfill them
– The UML provides a rich notation for visualizing our models. This includes a number of key diagrams, such as:• Use case diagrams, to illustrate user interaction with the system
• Class diagram, to illustrate logical structure
• Component diagrams, to illustrate physical structure of the software
• Sequence diagrams, to illustrate behavior of various collaborating classes in a part of the system
![Page 8: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/8.jpg)
Benefits of Visual Modeling
• System requirements can be communicated clearly.
• Models capture the software design unambiguously
• Flaws in architecture and inconsistencies in design can be detected early and more easily
• Unnecessary details are hidden when appropriate, making the handling of complexity easier
• Computerized tools for visual modeling can be used to automate many tasks of analysis and design
• The full specification of UML can be downloaded from the OMG website: www.omg.org
![Page 9: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/9.jpg)
UML Diagrams
• Activity diagram• Use case diagram• Class diagram• Object diagram• State machine diagram• Sequence diagram• Communication diagram• Component diagram• Deployment diagram• Package diagram• Composite structure diagram• Timing diagram• Interaction overview diagram
![Page 10: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/10.jpg)
UML Tools
• IBM Rational: Rational Rose, Rational Software Architect
• Borland: Together Software Architect
• Sparx Systems: Enterprise Architect
• Sybase: PowerDesigner
• Microsoft: Visio
![Page 11: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/11.jpg)
Software Development Life Cycle
• Requirement determination
• Analysis (problem domain)
• Design (solution domain)
• Implementation
• Deployment
![Page 12: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/12.jpg)
Requirement Determination
• Activity diagram
• Actors and use cases
• Use case diagram
• Use case specification
![Page 13: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/13.jpg)
Activity diagram
• Used for modeling– A business process
– Logic for single use case
– Logic for a business rule
• Particularly useful in the early stages of requirements determination to visualize and document our understanding of the overall process of the system. They can also be used to elaborate specific aspects of the workflow in more detail further.
• The activity diagram emphasize the flow of control from one activity to another activity.
![Page 14: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/14.jpg)
Activity digram
Customer places purchase order
Debit customer’s bank account
Place an order on the stock exchange
Deal executed on the stock exchange
Payment to the stock exchange
Delivery of shares (demat) directly to customer’s account
Refund balance amount, if any, to the customer
![Page 15: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/15.jpg)
Customer places/ modifies an order
Stores department dispatches the goods
Ask the customer to modify the order
Accounts department sends the invoice
Customer receives the goods
Customer receives the invoice
Customer makes the payment
![Page 16: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/16.jpg)
Customer Sales Stores Accounts
Customer places/ modifies an order
Ask the customer to modify the order
Customer receives the goods
Customer receives the invoice
Customer makes the payment
Stores department dispatches the goods
Accounts department sends the invoice
Accounts Dept issues receipt for payment
![Page 17: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/17.jpg)
Actors
• Anyone/ anything that interacts with a system is an actor
• Types of actors:
– Human actors (users of the system)
– External applications
– External devices
![Page 18: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/18.jpg)
Use cases
• Functionality provided by the system
• Consist of a series of steps which collectively add value to the user of the system
• Examples– Issue a book to a member
– Receive a book back from a member
– Query the current location of a book
– Maintain member’s information
– Maintain book’s information
![Page 19: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/19.jpg)
Identifying use cases for a system
• What are the tasks of each actor?
• Will any actor create, store, change, remove, or read the information?
• Will any actor need to inform the system about the sudden, external changes?
• Does any actor need to informed about certain occurrences in the system?
• What use cases will support and maintain the system?
• Can all functional requirements be performed by the use cases?
![Page 20: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/20.jpg)
Use case diagram
• Graphical view of some or all of the actors, use cases, and their interactions identified for a system. Each system typically has a main use case diagram, which is a picture of the system boundary (actor) and the major functionality by the system (use cases). Other use case diagrams may be created as needed.
![Page 21: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/21.jpg)
Use case diagrams
![Page 22: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/22.jpg)
Use case diagrams
![Page 23: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/23.jpg)
Generalization of Actors
![Page 24: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/24.jpg)
Generalization of use cases
![Page 25: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/25.jpg)
The Include Relationship
![Page 26: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/26.jpg)
The Include Relationship
![Page 27: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/27.jpg)
Variations in a Use Case
![Page 28: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/28.jpg)
The Extend relationship
![Page 29: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/29.jpg)
Use case specification
• Description of the desired behavior of a use case• Should describe what the system should do, rather than how it will
do it• The specification for a use case should be documented to clearly
describe the events needed to achieve the required behavior of the use case. The use case specification should be written in terms of what the system is supposed to do, not how the system does it. The specifications should include:– When and how the use case starts and ends– What interaction the use case has with the actors– What data is needed by the use case– The normal sequence of events for the use case– The description of alternate or exceptional flows
![Page 30: Lec 27 [use case diagrams]](https://reader034.vdocuments.net/reader034/viewer/2022052400/55a5bb351a28abde368b45e6/html5/thumbnails/30.jpg)
Thank you