0% found this document useful (0 votes)
9 views15 pages

03 1-UseCaseAnalysis

Uploaded by

Thẩm Phong
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views15 pages

03 1-UseCaseAnalysis

Uploaded by

Thẩm Phong
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

1 2

A big picture of Business Application System V-model


Need
Business Application System
Manual
IT System operations

BA Software
Hardware
Equipments Architecture
Network

Detailed

1 2

3 4

Procedural (e.g. C): Function, Procedure message


Object-Oriented (e.g. Java): Class (, Subsystem)

:A
Software :B a1(5)

+a1(int) behavior
class B { class A { /operation
A a = new A(); - attr1;
Component - attr2;
+b(){ - attr3;
a.a1(5); - attr4;
}
+a1(int i){
sub-
} //tính tiền trong ví
component
method //tính tiền trong tài khoản…
//trả về tổng số tiền
}

3 4

1
5 6

Analysis and Design Overview Analysis and Design Are Not Top-Down or Bottom-Up
Analysis and Design

Top
Design Model Down Subsystems
Use-Case Model Analysis and
Design

Use Cases Analysis Classes


Architecture (Define a
Document Bottom middle level)
Glossary Up
Supplementary
Specification
Design Classes
Data Model

5 6

Content
1. Overview
ITSS SOFTWARE DEVELOPMENT/SOFTWARE DESIGN AND CONSTRUCTION
2. Analysis classes
3. USE CASE ANALYSIS
3. Distribute Use-Case Behavior to
Nguyen Thi Thu Trang Classes
[email protected] 4. Analysis class diagram

Some slides extracted from IBM coursewares 8

7 8

2
9

Review: Software Architectural Design process Use case analysis Overview


• Purpose: “to provide a design for the software
that implements and can be verified against the
requirements” Glossary
Project Specific
Guidelines
Software
Architecture
Use-Case Realization

• Software architecture is designed from the Document

software requirements
• Main items
Use case
Supplementary
• a top-level structure of the software and the software Analysis
Specifications Analysis Model
components which constructs the software
• a top-level design for the interfaces external to the
software and between the software components
• a top-level design for the database
Use-Case Model Analysis Classes

9 10

11 12

Supplement the Use-Case Specification Content

1. Overview
2. Analysis classes
3. Distribute Use-Case Behavior to
Classes
• The system • The system retrieves
4. Analysis class diagram
displays a list and displays a list of
of courses. current courses from
the course catalog
legacy database.

11 12

3
13 14

Analysis Classes: A First Step Toward Executables


Review: Class
• Anabstraction
• Describes a group of objects with common:
• Properties (attributes)
• Behavior (operations)
• Relationships
Class Name Professor
• Semantics
name
Attributes ProfessorId : UniqueId

create()
Operations save() Use Cases Analysis Design Source Exec
delete()
change()
Classes Elements Code

Use-Case Analysis

13 14

15 16

Find Classes from Use-Case Behavior Types of Analysis Classes


<<boundary>> <<entity>>
• The complete behavior of a use case has to be distributed
to analysis classes System
System
boundary information

<<control>> <<boundary>>

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

System
information

15 16

4
17 18

2.1. Boundary Classes The Role of a Boundary Class


• Intermediate between the interface and something outside
the system <<control>>
<<boundary>> <<boundary>>
• Several Types Actor 1 Actor 2
• User interface classes
• System interface classes
• Device interface classes

• One boundary class per actor/use-case pair (typical)


<<entity>> <<entity>>

Analysis class stereotype


Model interaction between the system and its environment.
Environment dependent.

17 18

19 20

Example in AIMS: Finding Boundary Classes


for UC “Place order” and “Pay order” Guidelines: Boundary Classes
• Find boundary classes per actor/use case pair • User Interface Classes
• Typical one • 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!

19 20

5
21 22

2.2. Entity Classes The Role of Entity Classes


• Key abstractions of the system
<<control>>
<<boundary>> <<boundary>>
Analysis class Actor 1 Actor 2
stereotype

Business-Domain
Use Case Model

<<entity>> <<entity>>

Glossary
Store and manage information in the system.
Environment independent.

21 22

23 24

Example in AIMS: Finding Entity Classes for UC


Guidelines: Entity Classes “Place order” and “Pay order”
• Use use-case flow of events as input • Find candidate entity classes
• 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

23 24

6
25 26

3.3. Control Classes The Role of Control Classes


uProvide coordinating behavior in the system
<<control>>
umodel control behavior specific to one or more use <<boundary>> <<boundary>>
cases Actor 1 Actor 2

<<entity>> <<entity>>

Use Case Analysis class


stereotype
Coordinate the use-case behavior.
Use-case dependent. Environment independent.

25 26

27 28

Guidelines: Control Classes Example in AIMS: Finding Control Classes for


UC “Place order” and “Pay order”
uIn general, identify one control class per use case.
uThe system can perform some use cases without • One control class per use case (typical)
control classes by using just entity and boundary
classes.
• This is particularly true for use cases that involve only the
simple manipulation of stored information.
uMore complex use cases generally require one or more
control classes to coordinate the behavior of other
objects in the system.
• Examples of control classes include transaction managers,
resource coordinators, and error handlers.

27 28

7
29 30

Course AIMS Summary: Analysis Classes


Content

1. Overview
Use-Case Model
Customer Place order 2. Analysis classes
3. Distribute Use-Case Behavior to
Analysis Model
Classes
4. Analysis class diagram

29 30

31 32

3. Distribute Use-Case Behavior to Classes 3.1. Allocating Responsibilities to Classes


• For each use-case flow of events: • Use analysis class stereotypes as a guide
• Identify analysis classes • Boundary Classes
• Allocate use-case responsibilities to analysis classes
• Behavior that involves communication with an actor
• Model analysis class interactions in Interaction
• Entity Classes
diagrams
Use-Case Realization • Behavior that involves the data encapsulated within
the abstraction
• Control Classes
Communication
Sequence Diagrams • Behavior specific to a use case or part of a very
Diagrams important flow of events

Use Case
Class Diagrams

31 32

8
33 34

Responsibilities for the Entity classes (1) (2)


• (0) If one class has the data, put the
responsibility with the data
• If multiple classes have the data:
• (1) Put the responsibility with one class and
add a relationship to the other
• (2) Create a new class, put the responsibility in
the new class, and add relationships to
classes needed to perform the responsibility
• (3) Put the responsibility in the control class,
and add relationships to classes needed to
perform the responsibility

33 34

35 36

(3) 3.2. Interaction Diagrams


• Genericterm that applies to several diagrams
that emphasize object interactions
• Sequence Diagram
• Communication Diagram
• Specialized Variants
• Timing Diagram
• Interaction Overview Diagram

35 36

9
37 38

3.2. Interaction Diagrams (2) 3.2. Interaction Diagrams (3)


uSequence Diagram • Timing Diagram
• Time oriented view of object • Time constraint view of messages
interaction involved in an interaction
Timing Diagrams
Sequence Diagrams
• Interaction Overview Diagram
• High level view of interaction sets
uCommunication Diagram combined into logic sequence
• Structural view of messaging
objects

Interaction Overview
Communication Diagrams
Diagrams

37 38

39 40

The Anatomy of Sequence Diagrams


3.2.1. Sequence Diagram
• A sequence diagram is an interaction diagram that Client Object Supplier Object
emphasizes the time ordering of messages.
:Client Message :Supplier
• The diagram shows:
• The objects participating in the interaction. Object Lifeline
Reflexive Message
• The sequence of messages exchanged. 1: PerformResponsibility

Execution
Event Occurrence 1.1: PerformAnother
Responsibility
Occurrence

Hierarchical Message
Numbering
Sequence Diagram ref
Interaction Occurrence

39 40

10
41 @NGUYỄN Thị Thu Trang, [email protected] 42

message
Sequence Diagram Contents: Messages
a:A
a1(5)
:B :RegisterForCoursesForm :RegistrationController SWTSU Catalog :
CourseCatalogSystem
: Student : Course Catalog
What can a do?
+a1(int)
+a2() behavior 1: create schedule( )
class B { class A { /operation
A a = new A();
- attr1;
+b(){ - attr2; 2: get course offerings( )
a.a1(5); - attr3; 3: get course offerings(for Semester)
} - attr4;
4: get course offerings( )
}
+a1(int i){ 5: display course offerings( )
//tính tiền trong ví
method
//trả về tổng số tiền 6: display blank schedule( )
Message
}
= implementation of Reflexive
}
operation/behavior Messages
How can a do?

41 42

@NGUYỄN Thị Thu Trang, [email protected] 43 @NGUYỄN Thị Thu Trang, [email protected] 44

Messages in interation diagrams Synchronized vs. asynchronized messages


• Operation vs. Method? • Synchronous message
• Caller must wait until the message is done (e.g. invoking a subroutine)
• Call function vs. Send message
• Asynchronous message
• Caller can continue processing and doesn’t have to wait for a response

• Why sending messages? • Better responsiveness and reduces the temporal coupling but is harder
to debug.
• E.g. in multithreaded applications and in message-oriented middleware.
:CourseRegistrationController :SubjectInfo
: SubjectInfo
SubjectInfo
getSubjectPrerequisites()
getSubjectPrerequisites()

43 44

11
45 46

Exercise: AIMS 3.2.2. Communication Diagram


• A communication diagram emphasizes the
• Draw a sequence diagram for “Place order” use case
organization of the objects that participate in an
interaction.
• The communication diagram shows:
• The objects participating in the interaction.
• Links between the objects.
• Messages passed between the objects.

Communication Diagrams

45 46

47 48

The Anatomy of Communication


Diagrams Exercise: AIMS
• Draw a communication diagram for “Place order” use
Client Object Link Supplier Object
case

:Client :Supplier

PerformResponsibility

Message

47 48

12
49 50

One Interaction Diagram May Be Not 3.2.3. Sequence and Communication Diagram
Good Enough Comparison
Basic Flow • Similarities
Alternate Flow 1 Alternate Flow 2 Alternate Flow 3
• Semantically equivalent
• Can convert one diagram to the other without losing any
AF3 information
AF1 • Model the dynamic aspects of a system
AF2 • Model a use-case scenario
Alternate Flow 4 Alternate Flow 5 Alternate Flow n

49 50

51 52

3.2.3. Sequence and Communication Diagram Content


Comparison (2)
Sequence Communication 1. Overview
diagrams diagrams
§ Show the explicit § Show relationships in 2. Analysis classes
sequence of messages addition to interactions
§ Show execution § Better for visualizing 3. Distribute Use-Case Behavior to
occurrence patterns of communication Classes
§ Better for visualizing § Better for visualizing all of
overall flow the effects on a given object 4. Analysis class diagram
§ Better for real-time § Easier to use for
specifications and for brainstorming sessions
complex scenarios

51 52

13
53 54

Describe Responsibilities Finding Relationships


Communication Diagram
• What are responsibilities? PerformResponsibility
• How do I find them? :Client :Supplier

Interaction Diagram
Link
:Client :Supplier
Client Supplier
// PerformResponsibility
Class Diagram
Client 0..* 0..* Supplier
Class Diagram
PerformResponsibility()
Supplier
Association
// PerformResponsibility
Relationship for every link!
53 54

55 56

Unify Analysis Classes


Reviewpoints: Analysis Classes
RegisterFor Course
Catalog
RegisterFor Registration • Are the classes reasonable?
CoursesForm CoursesForm Controller
Registration
System
• Does the name of each class clearly reflect
Controller
the role it plays?
Register for
Student Student
• Does the class represent a single well-
Courses Course
Offering
Schedule
Course
Offering
defined abstraction?
• Are all responsibilities functionally coupled?
Course
Course
• Does the class offer the required behavior?
CloseRegistration Catalog Schedule
Form Catalog
System
System

Close CloseRegistration • Are all specific requirements on the class


Registration Billing
Controller
System CloseRegistration Student addressed?
Controller
Billing
Course CloseRegistration
System
Offering Form
Schedule

55 56

14
57 58

Review points: Message Design Question?


• Have all the main and/or sub-flows been
handled, including exceptional cases?
• Have all the required objects been found?
• Have all behaviors been unambiguously
distributed to the participating objects?
• Have behaviors been distributed to the right
objects?
• Where there are several Interaction diagrams,
are their relationships clear and consistent?

57 58

15

You might also like