University of Science, VNU-HCM

Faculty of Information Technology

Dynamic Analysis
Assoc. Prof. TRAN Minh Triet
Department of Software Engineering

Software Analysis and Design

 Reference

“Mastering Object-Oriented Analysis and Design with UML 2.0”

IBM Software Group

2
 Use-Case Realization

Use-Case Model Design Model

Use Case Use-Case Realization

Communication
Sequence Diagrams
Diagrams

Use Case Class Diagrams

3
 Analysis Classes: A First Step Toward Executables

Use Cases Analysis Design Source Exec

Classes Elements Code

Use-Case Analysis
4
 Find Classes from Use-Case Behavior

 The complete behavior of a use case has to be distributed to

analysis classes

5
 What Is an Analysis Class?

<<boundary>> <<entity>>

System System
boundary information

<<control>> <<boundary>>

System
Use-case
boundary
behavior
coordination <<entity>>

System
information

6
 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

Analysis class stereotype

Environment dependent.

7
 The Role of a Boundary Class

<<control>>
<<boundary>> <<boundary>>
Actor 1 Actor 2

<<entity>> <<entity>>

Model interaction between the system and its environment.

8
 Example: Finding Boundary Classes

 One boundary class per actor/use case pair

Student Register for Courses Course Catalog

RegisterForCoursesForm CourseCatalogSystem

9
 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

Concentrate on the responsibilities, not the details!

10
 What Is an Entity Class?

 Key abstractions of the system

Analysis
class
stereotype
Business-Domain
Use Case Model

Architectural Analysis
Abstractions Glossary

Environment independent.
11
 The Role of an Entity Class

<<control>>
<<boundary>> <<boundary>>
Actor 1 Actor 2

<<entity>> <<entity>>

Store and manage information in the system.

12
 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

13
 Example: Candidate Entity Classes

 Register for Courses (Create Schedule)

CourseOffering Schedule

Student

14
 What Is a Control Class?

 Use-case behavior coordinator


More complex use cases generally require one or more control
cases

Use Case Analysis class

stereotype

Use-case dependent. Environment independent.

15
 The Role of a Control Class

<<control>>
<<boundary>> <<boundary>>
Actor 1 Actor 2

<<entity>> <<entity>>

Coordinate the use-case behavior.

16
 Example: Finding Control Classes

 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

Student Register for Courses Course Catalog

System

RegistrationController

17
 Example: Summary: Analysis Classes

Student Register for Courses Course Catalog

System

Use-Case Model

Design Model

RegisterForCoursesForm CourseCatalogSystem Student Schedule

CourseOffering RegistrationController

18
 Distribute Use-Case Behavior to Classes

 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 Realization

Communication
Sequence Diagrams
Diagrams

Use Case
Class Diagrams
19
 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

20
 Guidelines: Allocating Responsibilities to Classes

 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

21
 Anatomy of Sequence Diagrams

Client Object Supplier Object

:Client Message :Supplier

Object Lifeline
Reflexive Message
1: PerformResponsibility

Event Occurrence 1.1: PerformAnother

Execution Responsibility
Occurrence

Hierarchical Message
Numbering
ref
Interaction Occurrence

22
 Example: Sequence Diagram

: RegisterForCoursesForm : RegistrationController : CourseCatalogSystem : Course Catalog

: Student

1: // create schedule( )
2: // get course offerings( )
Create a new 3: // get course offerings(forSemester)
schedule
4: // get course offerings( )

A list of the available 5: // display course offerings( )

course offerings for this
semester are displayed

A blank schedule
is displayed for the 6: // display blank schedule( )
students to select
offerings

ref Select Offerings

ref Submit Schedule

23
 Anatomy of Communication Diagrams

Client Object Link Supplier Object

:Client :Supplier

PerformResponsibility

Message

24
 Example: Communication Diagram

5: // display course offerings( )

6: // display blank schedule( )

: Course Catalog
4: // get course offerings( )
: RegisterForCoursesForm
: CourseCatalogSystem

2: // get course offerings( )

3: // get course offerings(forSemester)

1: // create schedule( )

: RegistrationController

: Student

25
 One Interaction Diagram: Not Good Enough

Basic Flow
Alternate Flow 1 Alternate Flow 2 Alternate Flow 3

AF3
AF1

AF2
Alternate Flow 4 Alternate Flow 5 Alternate Flow n

26
 Communication Diagrams vs. Sequence Diagrams

Communication Diagrams Sequence Diagrams

 Show relationships in addition  Show the explicit sequence of
to interactions messages
 Better for visualizing patterns  Better for visualizing overall
of collaboration flow
 Better for visualizing all of the  Better for real-time
effects on a given object specifications and for complex
 Easier to use for scenarios
brainstorming sessions

27