Content

1. Overview
IT4490 – ITSS SOFTWARE DEVELOPMENT
2. Analysis classes
3. ARCHITECTURAL DESIGN
3. Distribute Use-Case Behavior to
Classes
4. Analysis class diagram

2
Some slides extracted from IBM coursewares

1 2

Review: Software Architectural Design process Architectural Design Overview

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

software requirements
• Main items
Architectural
Supplementary
• a top-level structure of the software and the software Design
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

3 4

1
 5 6

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.

5 6

7 8

Analysis Classes: A First Step Toward Executables

Review: Class
• An abstraction
• 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

7 8

2
 9 10

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

9 10

11 12

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

<<entity>> <<entity>>

Analysis class stereotype

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

11 12

3
 13 14

Example in Course Registration CS: Finding

Boundary Classes
Guidelines: Boundary Classes
• One boundary class per actor/use case pair • User Interface Classes
• Concentrate on what information is presented to the
user
Student Register for Courses
• 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!

13 14

15 16

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.

15 16

4
 17 18

Example in Course Registration CS: Finding

Guidelines: Entity Classes Entity Classes
• Use use-case flow of events as input • For “Register For Course” use case, there are some
• Key abstractions of the use case candidate entity classes:
• 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

17 18

19 20

3.3. Control Classes The Role of Control Classes

◆Provide coordinating behavior in the system
<<control>>
◆model 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.

19 20

5
 21 22

Guidelines: Control Classes Example in Course Registration CS: Finding

Control Classes
◆In general, identify one control class per use case.
◆The system can perform some use cases without • For “Register for Course” use case:
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. Student Register for Course
◆More 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.

21 22

23 24

Course Registration CS Summary: Content

Analysis Classes
1. Overview
Student Register for Courses 2. Analysis classes
Use-Case Model
3. Distribute Use-Case Behavior to
Analysis Model
Classes
4. Analysis class diagram

23 24

6
 25 26

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

25 26

27 28

3.1. Allocating Responsibilities to Classes (2) 3.2. Interaction Diagrams

• Who has the data needed to perform the • Generic term that applies to several diagrams
responsibility?
• If one class has the data, put the responsibility with
that emphasize object interactions
the data • Sequence Diagram
• If multiple classes have the data: • Communication Diagram
• Put the responsibility with one class and add a
• Specialized Variants
relationship to the other
• Timing Diagram
• Create a new class, put the responsibility in the
new class, and add relationships to classes • Interaction Overview Diagram
needed to perform the responsibility
• Put the responsibility in the control class, and
add relationships to classes needed to perform
the responsibility

27 28

7
 29 30

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

◆Sequence 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
◆Communication Diagram combined into logic sequence
• Structural view of messaging
objects

Interaction Overview
Communication Diagrams
Diagrams

29 30

31 32

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. Message
:Client :Supplier
• The diagram shows:
• The objects participating in the interaction. Object Lifeline
Reflexive Message
1: PerformResponsibility
• The sequence of messages exchanged.

Execution Event Occurrence 1.1: PerformAnother

Responsibility
Occurrence

Hierarchical Message
Numbering
Sequence Diagram ref
Interaction Occurrence

31 32

8
 33 34

Exercise: Course Registration CS 3.2.2. Communication Diagram

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

Communication Diagrams

33 34

35 36

The Anatomy of Communication

Exercise: Course Registration CS
Diagrams
• Draw a communication diagram for “Register for course”
Client Object Link Supplier Object
use case

:Client :Supplier

PerformResponsibility

Message

35 36

9
 37 38

One Interaction Diagram May Be Not 3.2.3. Sequence and Communication Diagram
Good Enough Comparison
Basic Flow
Alternate Flow 1 Alternate Flow 2 Alternate Flow 3
• Similarities
• 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

37 38

39 40

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

39 40

10
 41 42

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!
41 42

43 44

Unify Analysis Classes

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

43 44

11
 45 46

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?

45 46

12