Architectural Analysis (Brief Chapter)

Architectural Analysis (Brief Chapter)
2
Objectives: Architectural Analysis
 Explain the purpose of Architectural Analysis
and where it is performed in the lifecycle.
 Describe a representative architectural pattern
and set of analysis mechanisms, and how they
affect the architecture.
 Describe the rationale and considerations that
support the architectural decisions.
 Show how to read and interpret the results of
Architectural Analysis:
 Architectural layers and their relationships
 Key abstractions
 Analysis mechanisms
3
Architectural Analysis in Context
[Early
Elaboration
Iteration]
[Inception
Iteration (Optional)]
Define a Candidate
Architecture
Perform
Architectural
Synthesis
Analyze Behavior
Refine the
Architecture
Design
Components
Design the
Database
(Optional)
Architecture
Analysis Architect
4
Architectural Analysis Overview
Supplementary
Specification
Glossary
Use-Case Model
Architectural
Analysis
Design Model
Reference
Architecture
Deployment Model
Vision
Document
Software
Architecture Doc
Project-Specific
Guidelines
5
Architectural Analysis Steps
 Key Concepts
 Define the High-Level Organization of the
model
 Identify Analysis mechanisms
 Identify Key Abstractions
 Create Use-Case Realizations
 Checkpoints
6
Review: What Is Architecture: The “4+1 View” Model
Process View
Deployment View
Logical View
Use-Case View
Implementation View
End-user
Functionality
Programmers
Software management
Performance, scalability, throughput
System integrators
System topology, delivery,
installation, communication
System engineering
Analysts/Designers
Structure
7
 A package is a general-purpose mechanism
for organizing elements into groups.
 It is a model element that can contain other
model elements.
 A package can be used
 To organize the model under development.
 As a unit of configuration management.
Review: What Is a Package?
University
Artifacts
8
 Packages can be related to one another using a
dependency relationship.
 Dependency Implications
• Changes to the Supplier package may affect the
Client package.
• The Client package cannot be reused independently
because it depends on the Supplier package.
Package Relationships: Dependency
Client Package Supplier
Package
Dependency relationship
9
C
A
B
Hierarchy
should be
acyclic
A
B
C
A'
Circular dependencies make it impossible
to reuse one package without the other.
Avoiding Circular Dependencies
A
B
10
Architectural Analysis Steps
 Key Concepts
 Define the High-Level Organization of the
model
 Identify Analysis mechanisms
 Identify Key Abstractions
 Create Use-Case Realizations
 Checkpoints
11
Patterns and Frameworks
 Pattern
 Provides a common solution to a common problem
in a context
 Analysis/Design pattern
 Provides a solution to a narrowly-scoped technical
problem
 Provides a fragment of a solution, or a piece of the
puzzle
 Framework
 Defines the general approach to solving the
problem
 Provides a skeletal solution, whose
details may be Analysis/Design patterns
12
Structural Aspect Behavioral Aspect
What Is a Design Pattern?
 A design pattern is a solution to a common
design problem.
 Describes a common design problem
 Describes the solution to the problem
 Discusses the results and trade-offs of applying the
pattern
 Design patterns provide the capability to reuse
successful designs.
Parameterized
Collaboration
Pattern Name
Template
Parameters
13
What Is an Architectural Pattern?
 An architectural pattern expresses a fundamental
structural organization schema for software
systems. It provides a set of predefined
subsystems, specifies their responsibilities, and
includes rules and guidelines for organizing the
relationships between them – Buschman et al,
“Pattern-Oriented Software Architecture — A System of
Patterns”
 Layers
 Model-view-controller (M-V-C)
 Pipes and filters
 Blackboard
14
Example: Layers
Application
Presentation
Session
Transport
Network
Data Link
Physical
Layer 7
Layer 6
Layer 5
Layer 4
Layer 3
Layer 2
Layer 1
Provides miscellaneous protocols for common activities
Structure information and attaches semantics
Provides dialog control and synchronization facilities
Breaks messages into packets and guarantees delivery
Selects a route from send to receiver
Detects and corrects errors in bit sequences
Transmits bits: velocity, bit-code, connection, etc.
15
Modeling Architectural Layers
 Architectural layers can be modeled using
stereotyped packages.
 <<layer>> stereotype
Package Name
<<layer>>
16
Class
<<stereotypename>>
What Are Stereotypes?
 Stereotypes define a new model element in
terms of another model element.
 Sometimes you need to introduce new things
that speak the language of your domain and
look like primitive building blocks.
Stereotype
17
Example: High-Level Organization of the Model
Application
<<layer>>
Business Services
<<layer>>
18
Architectural Analysis Steps
 Key Concepts
 Define the High-Level Organization of the
model
 Identify Analysis mechanisms
 Identify Key Abstractions
 Create Use-Case Realizations
 Checkpoints
19
Architect
Supplementary
Specification
Use-Case Model
Mechanisms
M e c h a n i s m s
COTS Products
Databases
IPC Technology, etc.
“realized by client
classes using”
“responsible for”
“constrained by”
Required
Functionality
itacyFnoult
Implementation
Environment
trevnoEmin
What Are Architectural Mechanisms?
20
Architectural Mechanisms: Three Categories
 Architectural Mechanism Categories
 Analysis mechanisms (conceptual)
 Design mechanisms (concrete)
 Implementation mechanisms (actual)
21
Why Use Analysis Mechanisms?
Oh no! I found a group of classes that
has persistent data. How am I
supposed to design these things if I
don’t even know what database we are
going to be using?
That is why we have a persistence
analysis mechanism. We don’t
know enough yet, so we can
bookmark it and come back to it
later.
Analysis mechanisms are used during analysis to reduce the
complexity of analysis and to improve its consistency by providing
designers with a shorthand representation for complex behavior.
22
Sample Analysis Mechanisms
 Persistency
 Communication (IPC and RPC)
 Message routing
 Distribution
 Transaction management
 Process control and synchronization (resource
contention)
 Information exchange, format conversion
 Security
 Error detection / handling / reporting
 Redundancy
 Legacy Interface
23
Examples of Analysis Mechanism Characteristics
 Persistency mechanism
 Granularity
 Volume
 Duration
 Access mechanism
 Access frequency (creation/deletion, update, read)
 Reliability
 Inter-process Communication mechanism
 Latency
 Synchronicity
 Message size
 Protocol
24
Example: Analysis Mechanism Characteristics (continued)
 Legacy interface mechanism
 Latency
 Duration
 Access mechanism
 Access frequency
 Security mechanism
 Data granularity
 User granularity
 Security rules
 Privilege types
 Others
25
 Collect all analysis
mechanisms in a list
 Draw a map of classes
to analysis mechanisms
 Identify characteristics
of analysis mechanisms
 Model using
collaborations
Describing Analysis Mechanisms
Classes
Parsing
Authentication
Communication
Persistency
Analysis
Mechanisms
Flight
Aircraft
Mission
Schedule
Route
Load
26
Example: Course Registration Analysis Mechanisms
Security
Legacy Interface
Persistence
Distribution
27
Architectural Analysis Steps
 Key Concepts
 Define the High-Level Organization of the
model
 Identify Analysis mechanisms
 Identify Key Abstractions
 Create Use-Case Realizations
 Checkpoints
28
What Are Key Abstractions?
 A key abstraction is a concept, normally
uncovered in Requirements, that the
system must be able to handle
 Sources for key abstractions
 Domain knowledge
 Requirements
 Glossary
 Domain Model, or the Business
Model (if one exists)
29
Defining Key Abstractions
 Define analysis classes
 Model analysis classes and relationships
on class diagrams
 Include a brief description of
an analysis class
 Map analysis classes to
necessary analysis
mechanisms
30
Example: Key Abstractions
Professor Student
Schedule
CourseCatalog CourseOffering Course
31
Architectural Analysis Steps
 Key Concepts
 Define the High-Level Organization of the
model
 Identify Analysis mechanisms
 Identify Key Abstractions
 Create Use-Case Realizations
 Checkpoints
32
Review: What is a Use-Case Realization?
Use Case Class Diagrams
Communication
Diagrams
Use-Case Model Design Model
Use Case Use-Case Realization
Sequence
Diagrams
33
The Value of Use-Case Realizations
 Provides traceability from Analysis and Design
back to Requirements
 The Architect creates the Use-Case Realization
Use Case
Analysis & Design
(Design Model)
Requirements
(Use-Case Model)
Use-Case
realization
34
Exercise: Architectural Analysis
 Given the following:
 Some results from the
Requirements discipline:
• Problem statement
• Use-Case Model main diagram
• Glossary
 Some architectural decisions:
(Logical View, Architectural Analysis)
• The upper-level architectural
layers and their dependencies
35
Exercise: Architectural Analysis (continued)
 Identify the following:
 The key abstractions
36
Exercise: Architectural Analysis (continued)
 Produce the following:
 Class diagram containing the key
abstractions
 Class diagram containing the
upper-level architectural layers
and their dependencies
37
Use Case Analysis
38
Objectives: Use-Case Analysis
 Explain the purpose of Use-Case
Analysis and where in the lifecycle it is
performed
 Identify the classes which perform a usecase
flow of events
 Distribute the use-case behavior to those
classes, identifying responsibilities of the
classes
 Develop Use-Case Realizations that
model the collaborations between
instances of the identified classes
39
Use-Case Analysis in Context
[Early
Elaboration
Iteration]
[Inception
Iteration (Optional)]
Define a Candidate
Architecture
Perform
Architectural
Synthesis
Analyze Behavior
Refine the
Architecture
Design
Components
Design the
Database
(Optional)
Use-Case
Designer Analysis
40
Use-Case Analysis Overview
Supplementary
Specifications
Glossary
Use-Case
Analysis
Project Specific
Guidelines
Use-Case Realization
Analysis Model
Use-Case Model Analysis Classes
Software
Architecture
Document
41
Use-Case Analysis Steps
 Supplement the Use-Case Description
 For each Use-Case Realization
 Find Classes from Use-Case Behavior
 Distribute Use-Case Behavior to Classes
 For each resulting analysis class
 Describe Responsibilities
 Describe Attributes and Associations
 Qualify Analysis Mechanisms
 Unify Analysis Classes
 Checkpoints
42
Use-Case Analysis Steps
 Supplement the Use-Case Description
 For each Use-Case Realization
 Find Classes from Use-Case Behavior
 Distribute Use-Case Behavior to Classes
 For each resulting analysis class
 Describe Responsibilities
 Describe Attributes and Associations
 Qualify Analysis Mechanisms
 Unify Analysis Classes
 Checkpoints
43
• The system
displays a list
of course
offerings.
• The system
retrieves and
displays a list of
current course
offerings from the
course catalog
legacy database.
Supplement the Use-Case Description
44
Use-Case Analysis Steps
 Supplement the Use-Case Description
 For each Use-Case Realization
 Find Classes from Use-Case Behavior
 Distribute Use-Case Behavior to Classes
 For each resulting analysis class
 Describe Responsibilities
 Describe Attributes and Associations
 Qualify Analysis Mechanisms
 Unify Analysis Classes
 Checkpoints
45
 An abstraction
 Describes a group of objects with common:
 Properties (attributes)
 Behavior (operations)
 Relationships
 Semantics Class Name
Attributes
Operations
Review: Class
Professor
name
ProfessorId : UniqueId
create()
save()
delete()
change()
46
Review: Use-Case Realization
Use Case Class Diagrams
Communication
Diagrams
Use-Case Model Design Model
Use Case Use-Case Realization
Sequence
Diagrams
47
Use Cases Analysis
Classes
Source
Code
Design Exec
Elements
Use-Case Analysis
U s e - C a s e A n a l y s i s
Analysis Classes: A First Step Toward Executables
48
Find Classes from Use-Case Behavior
 The complete behavior of a use case has to
be distributed to analysis classes
49
What Is an Analysis Class?
System
boundary
Use-case
behavior
coordination
System
information
<<boundary>>
<<control>>
<<entity>>
System
information
<<entity>>
System
boundary
<<boundary>>
50
Environment dependent.
Analysis class stereotype
A n a l y s i s c l a s t e r e o t y p e
What Is a Boundary Class?
 Intermediates between the interface and
something outside the system
 Several Types
 User interface classes
 System interface classes
 Device interface classes
 One boundary class per actor/use-case pair
51
Model interaction between the system and its environment.
The Role of a Boundary Class
Actor 1
<<boundary>>
<<control>>
<<boundary>>
<<entity>> <<entity>>
Actor 2
52
Student Register for Courses Course Catalog
Example: Finding Boundary Classes
 One boundary class per actor/use case pair
RegisterForCoursesForm CourseCatalogSystem
53
Concentrate on the responsibilities, not the details!
Guidelines: Boundary Class
 User Interface Classes
 Concentrate on what information is presented to
the user
 Do NOT concentrate on the UI details
 System and Device Interface Classes
 Concentrate on what protocols must be defined
 Do NOT concentrate on how the protocols will
be implemented
54
Glossary
Business-Domain
Model
Environment independent.
Analysis class
stereotype
Use Case
Architectural Analysis
Abstractions
What Is an Entity Class?
 Key abstractions of the system
55
Store and manage information in the system.
The Role of an Entity Class
Actor 1
<<boundary>>
<<control>>
<<boundary>>
<<entity>> <<entity>>
Actor 2
56
Example: Finding Entity Classes
 Use use-case flow of events as input
 Key abstractions of the use case
 Traditional, filtering nouns approach
 Underline noun clauses in the use-case flow of
events
 Remove redundant candidates
 Remove vague candidates
 Remove actors (out of scope)
 Remove implementation constructs
 Remove attributes (save for later)
 Remove operations
57
Example: Candidate Entity Classes
 Register for Courses (Create Schedule)
Student
CourseOffering Schedule
58
Use Case
Use-case dependent. Environment independent.
Analysis class
stereotype
What Is a Control Class?
 Use-case behavior coordinator
 More complex use cases generally require one
or more control cases
59
The Role of a Control Class
Coordinate the use-case behavior.
Actor 1
<<boundary>>
<<control>>
<<boundary>>
<<entity>> <<entity>>
Actor 2
60
Student
 In general, identify one control class per
use case.
 As analysis continues, a complex use case’s
control class may evolve into more than one
class
Course Catalog
System
Register for Courses
Example: Finding Control Classes
RegistrationController
61
Student Course Catalog
System
Register for Courses
Use-Case Model
Design Model
Example: Summary: Analysis Classes
RegisterForCoursesForm CourseCatalogSystem Student Schedule
CourseOffering RegistrationController
62
Use-Case Analysis Steps
 Supplement the Use-Case Descriptions
 For each Use-Case Realization
 Find Classes from Use-Case Behavior
 Distribute Use-Case Behavior to Classes
 For each resulting analysis class
 Describe Responsibilities
 Describe Attributes and Associations
 Qualify Analysis Mechanisms
 Unify Analysis Classes
 Checkpoints
63
 For each use-case flow of events:
 Identify analysis classes
 Allocate use-case responsibilities to analysis
classes
 Model analysis class interactions in Interaction
diagrams
Use Case
Distribute Use-Case Behavior to Classes
Class Diagrams
Communication
Sequence Diagrams
Diagrams
Use-Case Realization
64
Guidelines: Allocating Responsibilities to Classes
 Use analysis class stereotypes as a guide
 Boundary Classes
• Behavior that involves communication with
an actor
 Entity Classes
• Behavior that involves the data encapsulated
within the abstraction
 Control Classes
• Behavior specific to a use case or part of a
very important flow of events
65
Guidelines: Allocating Responsibilities to Classes (cont.)
 Who has the data needed to perform the
responsibility?
 If one class has the data, put the responsibility with
the data
 If multiple classes have the data:
• Put the responsibility with one class and add a
relationship to the other
• Create a new class, put the responsibility in the
new class, and add relationships to classes
needed to perform the responsibility
• Put the responsibility in the control class, and add
relationships to classes needed to perform the
responsibility
66
The Anatomy of Sequence Diagrams
1: PerformResponsibility
Client Object Supplier Object
:Client Message :Supplier
Execution
Occurrence
Reflexive Message
Object Lifeline
1.1: PerformAnother
Responsibility
Hierarchical Message
Numbering
ref Interaction Occurrence
Event Occurrence
67
Example: Sequence Diagram
: Student
: RegisterForCoursesForm : RegistrationController : CourseCatalogSystem : Course Catalog
A list of the available
course offerings for this
semester are displayed
Create a new
schedule
1: // create schedule( )
5: // display course offerings( )
2: // get course offerings( )
3: // get course offerings(forSemester)
6: // display blank schedule( )
A blank schedule
is displayed for the
students to select
offerings
4: // get course offerings( )
Select Offerings
Submit Schedule
ref
ref
68
Sequence Diagram in POS
: Register : S a le
makePayment(cashTendered)
makePayment(cashTendered)
create(cashTendered) : Payment
a n activation box show ing
the focus of control
69
PerformResponsibility
Client Object Supplier Object
Message
Link
:Client :Supplier
The Anatomy of Communication Diagrams
70
Example: Communication Diagram
: Student
: RegisterForCoursesForm
: RegistrationController
: CourseCatalogSystem
5: // display course offerings( )
6: // display blank schedule( )
1: // create schedule( )
2: // get course offerings( )
3: // get course offerings(forSemester)
4: // get course offerings( )
: Course Catalog
71
Communication Diagram in POS
1: makePayment(cashTendered)
1.1: create(cashTendered)
: Register :S a le
:Payment
makePayment(cashTendered)
creation indicated with a
"create" message
direction of message
first message
instance
first internal message
link line
parameter
72
Alternate Flow 4 Alternate Flow 5 Alternate Flow n
Alternate Flow 1 Alternate Flow 2 Alternate Flow 3
AF1
AF2
AF3
Basic Flow
One Interaction Diagram Is Not Good Enough
73
Communication Diagrams vs. Sequence Diagrams
 Show the explicit
sequence of messages
 Better for visualizing
overall flow
 Better for real-time
specifications and for
complex scenarios
 Show relationships in
addition to interactions
 Better for visualizing
patterns of collaboration
 Better for visualizing all
of the effects on a given
object
 Easier to use for
brainstorming sessions
Communication Sequence Diagrams
Diagrams
74
Use-Case Analysis Steps
 Supplement the Use-Case Descriptions
 For each Use-Case Realization
 Find Classes from Use-Case Behavior
 Distribute Use-Case Behavior to Classes
 For each resulting analysis class
 Describe Responsibilities
 Describe Attributes and Associations
 Qualify Analysis Mechanisms
 Unify Analysis Classes
 Checkpoints
75
// PerformResponsibility
:Client :Supplier
Supplier
//
PerformResponsibility
Interaction Diagram
Class Diagram
Describe Responsibilities
 What are responsibilities?
 How do I find them?
76
Example: View of Participating Classes (VOPC) Class Diagram
RegistrationController
// get course offerings()
<<control>>
CourseCatalogSystem
// get course offerings()
<<boundary>>
RegisterForCoursesForm
// display course offerings()
// display blank schedule()
// create schedule()
<<boundary>>
77
Use-Case Analysis Steps
 Supplement the Use-Case Descriptions
 For each Use-Case Realization
 Find Classes from Use-Case Behavior
 Distribute Use-Case Behavior to Classes
 For each resulting analysis class
 Describe Responsibilities
 Describe Attributes and Associations
 Qualify Analysis Mechanisms
 Unify Analysis Classes
 Checkpoints
78
ClassName
<<stereotype>>
Attribute : Type = InitValue
Attribute : Type = InitValue
Attribute : Type = InitValue
attribute
In analysis, do not spend time on attribute signatures.
Review: What Is an Attribute?
CourseOffering
number : String = "100"
startTime : Time
endTime : Time
days : Enum
numStudents : Int
<<entity>>
79
Finding Attributes
 Properties/characteristics of identified
classes
 Information retained by identified classes
 “Nouns” that did not become classes
 Information whose value is the important thing
 Information that is uniquely "owned” by an
object
 Information that has no behavior
80
Review: What Is an Association?
The semantic relationship between two or
more classifiers that specifies connections
among their instances
 A structural relationship, specifying that objects
of one thing are connected to objects of another
Course
<<entity>>
Student
<<entity>>
Schedule
<<entity>>
81
PerformResponsibility
Link
Association
Communication Diagram
Class Diagram
0..
*
0..
*
Client Supplier
:Client :Supplier
Client Supplier
PerformResponsibility()
Relationship for every link!
Finding Relationships
82
Review: What Is Aggregation?
 A special form of association that models a
whole-part relationship between an
aggregate (the whole) and its parts
Whole/aggregate Part
0..* 0..2 CourseOffering
<<entity>>
Schedule
<<entity>>
Student
<<entity>>
11 0..*
83
When in doubt, use association.
 If two objects are tightly bound by a whole-part
relationship
 The relationship is an aggregation.
 If two objects are usually considered as
independent, although they are often linked
 The relationship is an association.
Association or Aggregation?
Car Door
1 0..2,4
Car Door
1 0..2,4
84
What Are Roles?
 The “face” that a class plays in the
association
Role Name
CourseOffering
<<entity>>
Professor
<<entity>>
Instructor Department
<<entity>>
Department Head
Course
<<entity>>
Prerequisites
85
What Does Multiplicity Mean?
 Multiplicity answers two questions:
 Is the association mandatory or optional?
 What is the minimum and maximum number of
instances that can be linked to one instance?
Course
<<entity>>
Prerequisites 0..3
0..*
CourseOffering
<<entity>> 0..* 1
86
CourseOffering
<<entity>>
Schedule
<<entity>>
primaryCourses
alternateCourses
Multiple associations must reflect multiple roles.
Example: Multiple Associations
CourseOffering
<<entity>>
Schedule
<<entity>> add student to
remove student from
87
Example: Finding Relationships
RegisterForCoursesForm
<<boundary>>
CourseOffering
<<entity>>
Schedule
<<entity>>
0..*
primaryCourses
0..4
Student
<<entity>>
1 0..*
RegistrationController
<<control>>
1 1
0..1
currentSchedule
0..1
88
Use-Case Analysis Steps
 Supplement the Use-Case Descriptions
 For each Use-Case Realization
 Find Classes from Use-Case Behavior
 Distribute Use-Case Behavior to Classes
 For each resulting analysis class
 Describe Responsibilities
 Describe Attributes and Associations
 Qualify Analysis Mechanisms
 Unify Analysis Classes
 Checkpoints
89
Review: Why Use Analysis Mechanisms?
Oh no! I found a group of classes that
has persistent data. How am I
supposed to design these things if I
don’t even know what database we are
going to be using?
That is why we have a persistence
analysis mechanism. We don’t
know enough yet, so we can
bookmark it and come back to it
later.
Analysis mechanisms are used during analysis to reduce the
complexity of analysis and to improve its consistency by providing
designers with a shorthand representation for complex behavior.
90
Describing Analysis Mechanisms
 Collect all analysis mechanisms in a list
 Draw a map of the client classes to the
analysis mechanisms
 Identify characteristics of the analysis
mechanisms
91
Analysis Class
Analysis Mechanism(s)
Student
Schedule
CourseOffering
Course
RegistrationController
Persistency, Security
Persistency, Legacy Interface
Persistency, Legacy Interface
Distribution
Persistency, Security
Example: Describing Analysis Mechanisms
 Analysis class to analysis mechanism map
92
Example: Describing Analysis Mechanisms (continued)
 Analysis mechanism characteristics
 Persistency for Schedule class:
 Granularity: 1 to 10 Kbytes per product
 Volume: up to 2,000 schedules
 Access frequency
• Create: 500 per day
• Read: 2,000 access per hour
• Update: 1,000 per day
• Delete: 50 per day
 Other characteristics
93
Use-Case Analysis Steps
 Supplement the Use-Case Descriptions
 For each Use-Case Realization
 Find Classes from Use-Case Behavior
 Distribute Use-Case Behavior to Classes
 For each resulting analysis class
 Describe Responsibilities
 Describe Attributes and Associations
 Qualify Analysis Mechanisms
 Unify Analysis Classes
 Checkpoints
94
Use-Case Analysis Steps
 Supplement the Use-Case Descriptions
 For each Use-Case Realization
 Find Classes from Use-Case Behavior
 Distribute Use-Case Behavior to Classes
 For each resulting analysis class
 Describe Responsibilities
 Describe Attributes and Associations
 Qualify Analysis Mechanisms
 Unify Analysis Classes
 Checkpoints
95
Unify Analysis Classes
Register for
Courses
Close
Registration
Student
Course
Offering
Course
Offering
CloseRegistration Student
Controller
Registration
Controller
CloseRegistration
Form
Course
Catalog
System
Schedule
Course
Catalog
System
Course
Offering
Schedule
Registration
Controller
Student
CloseRegistration
Controller
Schedule
Course
Catalog
System
Billing
System
RegisterFor
CoursesForm
RegisterFor
CoursesForm
Billing
CloseRegistration System
Form
96
Design Model
Analysis Classes
Evaluate Your Results
Supplementary
Specification
Glossary
Use-Case Model
97
Use-Case Analysis Steps
 Supplement the Use-Case Descriptions
 For each Use-Case Realization
 Find Classes from Use-Case Behavior
 Distribute Use-Case Behavior to Classes
 For each resulting analysis class
 Describe Responsibilities
 Describe Attributes and Associations
 Qualify Analysis Mechanisms
 Unify Analysis Classes
 Checkpoints
98
Checkpoints: Analysis Classes
 Are the classes reasonable?
 Does the name of each class
clearly reflect the role it plays?
 Does the class represent a single
well-defined abstraction?
 Are all attributes and
responsibilities functionally
coupled?
 Does the class offer the required
behavior?
 Are all specific requirements on
the class addressed?
99
Checkpoints: Use-Case Realizations
 Have all the main and/or sub-flows
been handled, including exceptional
cases?
 Have all the required objects been
found?
 Has all behavior been unambiguously
distributed to the participating objects?
 Has behavior been distributed to the
right objects?
 Where there are several Interaction
diagrams, are their relationships clear
and consistent?
100
Review: Use-Case Analysis
 What is the purpose of Use-Case Analysis?
 What is a Use-Case Realization?
 What is an analysis class? Name and
describe the three analysis stereotypes.
 Describe some considerations
when allocating responsibilities
to analysis classes.
 What two questions does multiplicity
answer?