Embed Size (px)
Citation preview
February 3, 2019 Sam Siewert
SE310Analysis and Design of Software
Systems
Lecture 5 – More in Depth Use Cases and Class Diagramming - Analysis
Before we Move on …Quiz #1 on Canvas
Big Systems: SpaceX Falcon Heavyspacex-starlink-satellites.htmlStarman Live – SpaceX WebcastStarman by David Bowie, (Soft Landing)Test Flight
Project Proposals - Discussion? Updates?
Architecture Styles and Patterns
Next, We’ll look at Analysis Methods to Support Class Diagramming, Use Cases and How to Trace to Requirements
Often the Challenge is “Where do I start?” more so than how do I Enter/Edit the diagrams Sam Siewert 2
Don’t Panic
More than One Way to Proceed with UML …
No Absolutely Right or Wrong Approach
Balance of Behavioral and Structural Analysis (Models) with Details Deferred for Design
Class / Object Models Unique to UML
Activity and Interaction Overview (Objects from Classes) are Useful for High Level Behavior
Sam Siewert 3
Domain Models – Use Case Details
Sam Siewert 4
Start Here! https://www.modelio.org/
OMG UML 2.5 Standard
Structural Diagrams• Start with Class Diagram and CRC• Then Object Diagram• Package and Deployment
Behavioral Diagrams• Start with Use Case Diagram• Interaction Sequence Diagram after
Class and Object Done• Add State Machine and Activity
Diagrams for concurrency and statefulness
Helpful Validation and Verification Features for Design
• Integrated Models• Checklists – Completeness• CPP and Java Code Generation
USE Modelio 3.7 SD as your DESIGN TOOL
UML is Universal Modeling Language [OMG, UML.org]Use to Support Requirements Analysis
CRC – Class Responsibility Collaborator
Create a Set of Index Cards with Proposed Classes, Responsibilities for the Class and Collaborators (has an Association)
Useful Step Prior to Class Diagram and Class Definitions
Not Officially Part of UML, but Useful Supporting Method Sam Siewert 5
http://www.uml.org.cn/umlapplication/pdf/crcmodeling.pdf
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-6
Key Takeaway Points
• A use case is a business process; it begins with an actor, ends with the actor, and accomplishes a business task for the actor.
• Use cases are derived from requirements and satisfy the requirements.
• Planning the development and deployment of use cases and subsystems to meet the customer’s business needs and priorities.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-7
AcquiringRequirements
Software architecture
Deriving Use Cases in the Methodology Context
Deriving Use Cases from Requirements
Allocating Use Cases & Subsystemsto Iterations
Business goals& needs
Current situation
Preliminary requirements
Abstract & high level use cases, use case diagrams
Use case-iteration allocation matrix
(a) Planning Phasecontrol flow data flow control flow & data flow
(b) Iterative Phase – activities during each iteration
Actor-System Interaction Modeling
Domain Modeling
AccommodatingRequirements Change
Behavior Modeling &Responsibility Assignment
Deriving Design ClassDiagram
Test Driven Development, Integration, & Deployment
Customer feedback
Iteration use cases
Domain model
Expanded use cases & UI design
Behavior models
Design class diagram
Domain model
Use case-iteration allocation matrix
Producing an Architecture Design
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-8
Verify the Use Cases Identified
• Verify the use cases identified using use case definition:(1) Is it a business process? y/n(2) Is it initiated by an actor? y/n(3) Does it end with the actor? y/n(4) Does it accomplish something useful for the actor?
y/n• All the answers to above questions must be “y.”
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-9
What Is an Actor?• An actor denotes a business role played by (and on
behalf of) a set of business entities or stakeholders.• Actors are not part of the system.• Actors interact with the system.• Actors are often human beings but can also be a piece
of hardware, a system, or another component of the system.
• Actors initiate use cases, which accomplish business tasks for the respective actors.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-10
Use Case Diagram: Notion and Notation
A use case is a business process that begins with an actor, ends with the actor, and accomplishes a business task useful for the actor.
Use case
It indicates that the actor uses the use case.Association between actors and use cases
It encloses the use cases and shows the capabilities of the system.
System Boundary
An actor is a role played by and on behalf of a set of business entities or stakeholders that are external to the system and interact with the system.
Actor
NotationMeaningNotion
use case name
system name
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-11
Advanced Notions and Notations
Pointing from including use case to included use case.
It indicates that one use case includes another use case as part of its business process.
Inclusion
Pointing from extension use case to extended use case.
It indicates that one use case can optionally continue the process of another use case.
Extension
Pointing from specialized use case to generalized use case.
It indicates that one use case is more general/ specialized than the other.
InheritanceNotationMeaningNotion
<<extend>>
<<include>>
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-12
Use Case Diagram: Library Example
Checkout Document
Return Document
Search for Document
Library System
Patron
actoruse case
system boundary
system name
association
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-13
Simplify with Use of Inheritance
Startup
ShutdownAdmin
Library System
Checkout a Document
Patron Return a Document
An admin can alsocheckout and returna document. But apatron cannotstart or shutdown thesystem.
Inheritance: It statesthat an Admin IS-APatron.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-14
Simplify with Use of Inheritance
Login
Logout
SAMS/Search Program
SAMSEnd User
SAMSAdmin
SAMSStaff
This is OK. Login
Logout
SAMS/Search Program
SAMSEnd User
SAMSAdmin
SAMSStaff Better
Study-Abroad Management System
Kung, Ref., P. 179, Example 7.4
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-15
Guidelines for Use Case Diagram
• Avoid showing – many use cases in one diagram (see next slide)– many use case diagrams each containing only one
use case– overly complex use case diagrams– unnecessary relationships between use cases
• Use several diagrams to show groups of closely related use cases:
• show only use cases and actors that are relevant• provide a meaningful name for the system/subsystem
that implements group of use cases
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-16
Guidelines for Use Case Diagram
• Use inheritance to simplify the diagram by reducing the number of actor-use case links.
• Give a meaningful name for the system/subsystem that contains the use cases. The name may serve as the package or module name in design/implementation.
• Actor-use case relationships are always association relationships.
• Only use cases and their relationships can be shown within the system boundary.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-17
Use Case Diagram
Log In
Log Out
Start Up
SAMS
SAMSEnd User
SAMSStaff User
SAMSAdmin
Add Program
Delete Program
Edit Program
Create User
Delete User
Update User
Search for Programs
Display ProgramDetail
Apply OnlineShutdown
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-18
Create User
Delete User
Update User
SAMS/User Mgmt
SAMSAdmin
Add Program
Delete Program
Edit Program
SAMS/Program Mgmt
SAMSStaff
Search for Programs
Display ProgramDetail
Apply Online
SAMS/End User
SAMSEnd User
Start Up
Shutdown
Login
Logout
SAMS/Authentication
SAMSEnd User
SAMSAdmin
SAMSStaff
Software engineeringprinciple applied:• separation of
concerns• divide and conquer
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-19
What Should Be In and Out?
Add Program
Delete Program
Edit Program
SAMS/Program Mgmt
SAMSStaff
Login
Login
Add Program
Delete Program
Edit Program
SAMS/Program Mgmt
SAMSStaff
Login
Login
Add Program
Delete Program
Edit Program
SAMS/Program Mgmt
SAMSStaff
Login
Login
DB
Add Program
Delete Program
Edit Program
SAMS/Program Mgmt
SAMSStaff
Login
Login
Hacker
Only use cases and their relationships are allowed in the boundary.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-20
Applying Agile Principles1. Work closely with customer and users to understand
their business processes and priorities, and help them identify their real needs.
2. The team members should work together to identify use cases, actors and subsystems, and specify the use case scopes.
3. Requirements evolve but the timescale is fixed.4. Focus on frequent delivery of small increments,
each deploys only a couple of use cases.5. Do not attempt to derive an optimal set of use cases.
Good enough is enough.
Tying Use Case Back to RequirementsCreate Traceability – Rn is Described by Use-Casen
Kung says Prioritize Requirements … “Desirements”
Sam Siewert 21
Help Distinguish Requirement Priority Based on Use and Use Case Based on Requirements Weight
Drive Next Steps and Focus for Walk-throughs and Inspections based on Highest Column Scores or Perhaps Adjust Weightings
Note on Requirements:• Kung suggests prioritization• Fits for “want”, but not “need’• Could be market specific• Alternatively weight UC
Alternative UC WeightingIf Requirement priorities are “must” only, weight UC insteadE.g. to “To sell our RAID system to enterprise customers, the product must have a disaster recovery feature”– However, the product can be sold to SMB (Small to Medium Business)
without DR features– Is DR a Use Case or a Requirement? R5 = asynchronous mirrored writes– E.g. UC6 is DR, UC4 is Local Content Delivery– Drop R5 Iff UC6 and UC4 irrelevant - i.e. UC1, 2, 3, 5 for SMB– UC4, UC6 for enterprise
Sam Siewert 22
UC1 UC2 UC3 UC4 UC5 UC6 scoreweight 3 3 1 1 2 1R1 X X 6R2 X 2R3 X 3R4 X X 4R5 X X 2R6 X X 5
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-23
Usefulness of the Traceability Matrix
• It highlights which use cases relate to which requirements, and vice versa.
• It shows the priorities of the requirements and use cases.
• Projects should focus on timely delivery of high-priority use cases.
• It is useful for use case based acceptance testing – high-priority use cases should be tested first.
Agile with Use Cases
Create Backlog – Attack Highest Priority Use Cases First
Schedule Scrums Around Use Cases
Synchronize with SQA on Use Case Acceptance Testing
Simple – Easy to Share with Customer
Sam Siewert 24
Work with Customer – Use Case Inspection or Walk-through
Team – Walk-throughs and Division of Labor, Planning and Backlog
Refinement of Requirements
Frequent Delivery of Small Increments (Use Case Design, Construction, Coding)
What the System Includes and Does not (Boundary)
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
9-25
AcquiringRequirements
Software architecture
OIM in the Methodology Context
Deriving Use Cases from Requirements
Allocating Use Cases & Subsystemsto Iterations
Business goals& needs
Current situation
Preliminary requirements
Abstract & high level use cases, use case diagrams
Use case-iteration allocation matrix
(a) Planning Phasecontrol flow data flow control flow & data flow
(b) Iterative Phase – activities during each iteration
Actor-System Interaction Modeling
Domain Modeling
AccommodatingRequirements Change
Behavior Modeling &Responsibility Assignment
Deriving Design ClassDiagram
Test Driven Development, Integration, & Deployment
Customer feedback
Iteration use cases
Domain model
Expanded use cases & UI design
Behavior models
Design class diagram
Domain model
Use case-iteration allocation matrix
Producing an Architecture Design
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
9-26
Actor-System Interaction & Object Interaction
• Foreground processing of use case.
• Acquiring actor input and actor action.
• Displaying system responses.
• Background processing of use case by objects.
• Designing high-level algorithms to process actor requests.
• Producing system responses.
Actor-system interactionObject interaction
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
9-27
Object Interaction Modeling Steps
(1) Collecting info about business
processes
(3) Constructing scenario tables
(5) Review and inspection
business processes
info.
scenario descriptions
sequencediagrams
feedback, if any
(2) Describing scenarios
(4) Constructing sequence diagrams
expanded use cases for current iteration
scenario tables
design sequencediagrams
domain model, design class
diagram from last iteration
to deriving adesign class
diagram (chapter 11)
