Overview Base Unit Block & Circuit Diagrams Handset Block & Circuit Diagrams Summary
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS
15
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS 08-Jul-19 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN 1 of 15 Relating Use Case
Transcript of UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS
08-Jul-19 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN 1 of 15
Relating Use Case
Use Cases Fig. 3.1
User Interface
Sale Payment
Logging ... Database Access ...
application
logic layer
other layers or
components
minor focus
explore how to connect to
other layers
primary focus
of case studies
explore how to
design objects
secondary
focus
08-Jul-19 2 of 15 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
Use Cases Fig. 3.2
Iteration 1
Iteration 2
Iteration 3
Introduces just those
analysis and design
skills related to
iteration one.
Additional analysis and
design skills introduced.Likewise.
08-Jul-19 3 of 15 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
Next Gen POS – Case Study 1 • A computerized application used to record sales
and handle payments
• Typically used in a retail store
• Includes both hardware components such as _____ and software components
• Interfaces to several external systems such as ____
• Must be fault tolerant, e.g. if an external service is temporarily unavailable
• Must support multiple and varied client-side terminals and interfaces
• Flexibility and customization to cater to business rules of different prospective clients
4 of 15 08-Jul-19 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
Monopoly Game – Case Study 2
• An example that shows OOAD can be applied to different problems
• The game will run as a simulation
• One person starts the game and indicates the number of simulated players
• The game runs to completion, presenting a trace of the activity during the simulated player turns.
5 of 15 08-Jul-19 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
6 of 15
Inception • Inception is not the requirements phase
• Initial short step to establish a common vision and a basic scope for the project
• A number of questions need to be explored: – What is the vision and business case for this project?
– Is it feasible?
– Buy and/or build?
– Rough estimate of cost.
– Should we proceed or stop?
• The intent is to establish some initial common vision for the objectives of the project, determine if it is feasible and decide if it is worth some serious investigation in elaboration.
08-Jul-19 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
7 of 15
What artifacts may start in inception?
• Vision and business case – Describes high-level goals and constraints.
• Use Case model – Describes functional requirements
• Supplementary specification – Describes other requirements
• Glossary – Key domain terminology
• Risk list and Risk Management Plan – Describes business, technical, resource and schedule risks and
ideas for their mitigation or response.
08-Jul-19 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
8 of 15
What artifacts may start in inception?
• Prototypes and proof-of-concepts
• Iteration plan – Describes what to do in the first elaboration iteration
• Phase Plan & Software development Plan – Guess for elaboration phase duration. Tools, people,
education and other resources.
• Development Case – Description of the customized UP steps and artifacts for this
project.
• Artifacts will be partially completed in this phase and will be refined in later iterations.
08-Jul-19 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
9 of 15
Introduction to Requirements
• Requirements are system capabilities and conditions to which the system must conform.
• Functional requirements
– Features and capabilities.
– Recorded in the Use Case model (see next), and in the systems features list of the Vision artifact.
• Non-functional (or quality requirements)
– Usability (Help, documentation, …), Reliability (Frequency of failure, recoverability, …), Performance (Response times, availability, …), Supportability (Adaptability, maintainability, …)
– Recorded in the Use Case model or in the Supplementary Specifications artifact.
• The nature of UP supports changing requirements.
08-Jul-19 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
Requirements Artifacts
• Use Case Model
• Supplementary Specification
• Glossary
• Vision
• Business Rules
10 of 15 08-Jul-19 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
Evolutionary Requirements
• UP embraces change in requirements as a fundamental driver on projects.
• This is at the heart of waterfall vs iterative & evolutionary thinking
11 of 15 08-Jul-19 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
Goal: Process sales
Cashier
Customer
POS System
Checkout Service
Goal: Buy items
Enterprise Selling Things
Sales Tax
Agency
Goal: Collect
taxes on sales Sales Activity
System
Goal: Analyze sales
and performance data
08-Jul-19 12 of 15 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
Sample UP Artifacts
Use Case Diagram NextGen POS
Manage Users
. . .
Cashier
System
Administrator
actor
use case
communicationsystem boundary
Payment
Authorization
Service
«actor»
Tax Calculator
«actor»
Accounting
System
alternate
notation for
a computer
system actor
«actor»
HR System
Cash In
«actor»
Sales Activity
System
Manage Security
Analyze Activity
Customer
Manager
Process Sale
Handle Returns
08-Jul-19 13 of 15 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
NextGen
Process Sale
. . .
Cashier
Show computer system actors
with an alternate notation to
human actors.
primary actors on
the left
supporting actors
on the right
For a use case context
diagram, limit the use cases to
user-goal level use cases.
«actor»
Payment
Authorization
Service
08-Jul-19 14 of 15 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
Use Case Diagram
NextGen
Process Sale
«system»
Payment
Authorization
Service...
«actor»
Payment
Authorization
Service
Some UML alternatives to
illustrate external actors that are
other computer systems.
The class box style can be used
for any actor, computer or
human. Using it for computer
actors provides visual
distinction.
Payment
Authorization
Service
08-Jul-19 15 of 15 CS8592 OBJECT ORIENTED ANALYSIS AND
DESIGN
Use Case Diagram
