Mastering OOAD - Instructor Notes

Objectives: Identify Design Elements

• Define the purpose of Identify Design Elements
and demonstrate where in the lifecycle it is
ITSS SOFTWARE DEVELOPMENT
performed
4. IDENTIFY DESIGN ELEMENTS • Analyze interactions of analysis classes and
identify Design Model elements => Design
Nguyen Thi Thu Trang
classes
trangntt@soict.hust.edu.vn

Some slides extracted from IBM coursewares

1 2

Identify Design Elements in Context Identify Design Elements Overview

[Early
Elaboration [Inception
Iteration] Iteration (Optional)]

Define a Candidate Perform

Architecture Architectural
Synthesis
Software Project Specific
Architecture Guidelines
Document
Supplementary
Analyze Behavior Specifications
Identify Design (Optional)
Elements Architect Refine the
Architecture Identify
Design
Design Design the
Elements
Components Database

Design Model

Analysis Model

3 4

Page 1
Module 7 - Identify Design Elements 1
Mastering OOAD - Instructor Notes

From Analysis Classes to Design Elements

Analysis Classes Design Elements
Identifying Design Classes
<<boundary>> • An analysis class maps directly
to a design class if:
• It is a simple class
<<control>>
<<subsystem>>
Subsystem • It represents a single logical abstraction
• More complex analysis classes may
<<entity>> • Split into multiple classes
• Become a package
• Become a subsystem (discussed later)
<<boundary>>
• Any combination …
<<subsystem>>
Subsystem

Many-to-Many Mapping
5 6

Review: Class and Package Group Design Classes in Packages

• What is a class? • You
can base your packaging criteria on a
• A description of a set of objects that share the same number of different factors, including:
responsibilities, relationships, operations, attributes, and • Configuration units
semantics Class Name • Allocation of resources among development teams
• Reflect the user types
• What is a package? • Represent the existing products Package C

• A general purpose mechanism for organizing elements and services the system uses
Package B
into groups
Package A
• A model element which can contain other model
elements
Package
Name

7 8

Page 2
Module 7 - Identify Design Elements 2
Mastering OOAD - Instructor Notes

Packaging Tips: Boundary Classes Packaging Tips:

If it is likely the system interface
will undergo considerable
changes
Boundary classes placed in
separate packages
If it is unlikely the system
interface will undergo
considerable changes
Boundary classes packaged
with functionally related classes
Functionally Related Classes
• Criteria for determining if classes are functionally
related:
• Changes in one class' behavior and/or structure
necessitate changes in another class
• Removal of one class impacts the other class
• Two objects interact with a large number of messages
or have a complex intercommunication
• A boundary class can be functionally related to a
particular entity class if the function of the boundary
class is to present the entity class
• Two classes interact with, or are affected by changes in
the same actor

9 10

Packaging Tips: Package Dependencies: Package Element Visibility

Functionally Related Classes (continued) PackageA
• Criteria
for determining if classes are functionally A
+ Class A1
related (continued): + Class A2

• Two classes have relationships between each other

+ Class A3
• One class creates instances of another class
• Criteria
for determining when two classes should B Only public classes
can be referenced
NOT be placed in the same package: PackageB
outside of the
• Two classes that are related to different actors should owning package
Public visibility + Class B1
not be placed in the same package
- Class B2
• An optional and a mandatory class should not be placed Private visibility
in the same package

OO Principle: Encapsulation

11 12

Page 3
Module 7 - Identify Design Elements 3
Mastering OOAD - Instructor Notes

Package Coupling: Tips

Example: Registration Package
• Packages should not be A B

cross-coupled
X MainStudentForm MainRegistrarForm

1 1
A
Upper 0..1 0..1
• Packages in lower layers Layer <<boundary>> <<boundary>>
should not be dependent
upon packages in upper X X
RegisterForCoursesForm CloseRegistrationForm

Lower
layers Layer
B
1
1 1
<<control>> <<control>>
RegistrationController CloseRegistrationController
• In general, dependencies
C
should not skip layers

X = Coupling violation

13 14

Example: University Artifacts Package: Example: University Artifacts Package:

Generalization Associations
<<entity>>
<<entity>> Schedule
Student 1 0..*

<<entity>> <<entity>> 0..* 0..*

Student ScheduleOfferingInfo

primaryCourses alternateCourses
0..2
<<entity>> 0..4
<<entity>> <<entity>>
FulltimeStudent ParttimeStudent
PrimaryScheduleOfferingInfo <<entity>> instructor <<entity>> <<entity>> 0..*
Professor CourseOffering Course
0..*
0..1 0..* 0..* 1
Prerequisites
0..*
1
CourseOfferingList

15 16

Page 4
Module 7 - Identify Design Elements 4
Mastering OOAD - Instructor Notes

Example: External System Interfaces

Package
<<Interface>> <<Interface>>
IBillingSystem ICourseCatalogSystem

17

Page 5
Module 7 - Identify Design Elements 5