1. Based on the book by David William Brown
An Introduction to Object-Oriented Analysis Objects and UML in plain English. Chapter 12: Subsystems
Based on the book by
David William Brown
John Wiley & Sons, ISBN

2. Copyright 8 2002 Flying Kiwi Productions
All rights reserved.
This slide presentation is based on “An Introduction to Object-Oriented Analysis; Objects and UML in Plain English,” by David William Brown, Wiley, ISBN , “The Book.”
Permission is hereby granted to copy, modify or excerpt all or any part of this slide presentation, provided it is solely for use with courses, seminars or other presentations or productions where a copy of The Book is purchased by or for each and every participant or recipient.
An instructor guide is available from the publisher for such presentations.

3. Chapter 12: Subsystems 12.1. Dividing Up a Project.
12.2. How to Subdivide.
12.3. When to Subdivide.
12.4. Some Special Classes.
12.5. Comparison of Terms.
12.6. The Multilayer Model.

4. Chapter 12: Subsystems
12.1 Dividing Up a Project.

5. Chapter 12: Subsystems 12.1. Dividing Up a Project.
OOA is highly scalable
It can be used on projects
From very small, with 4 or 5 classes,
To huge, with hundreds of classes
But large projects are difficult to manage (in any paradigm)
Simply because of size and complexity.
The number of possible relationships
grows exponentially with the number of classes.

6. Chapter 12: Subsystems 12.1. Dividing Up a Project.
A large system with hundreds of boxes
on the diagram
Can be physically impossible to draw,
Let alone comprehend.
We need to reduce complexity.
One method is Subsystems,
Which are a form of encapsulation.

7. Chapter 12: Subsystems 12.1. Dividing Up a Project.
As we have defined it
Encapsulation is
hiding details and complexity
within a well-defined
published boundary.

8. Chapter 12: Subsystems 12.1. Dividing Up a Project.
To illustrate, here is a
class diagram for a
Human Resources system . . .

9. Chapter 12: Subsystems 12.1. Dividing Up a Project.* 1
Project
H.R. System * 1 * *
Unit of
Work
Activity * * *
Position
Assignment
Position * 1 * * 1 1 1 * 1 1
Employee * 1 * *
Credential * *
Enrolment *
Skill
Requirement 1 * * * 1 1
drives
Training
Source 1
Course * 1 * * * *
Skill * 1 *
Licence * * * * 1
Instructor
Course
Offering *

10. Chapter 12: Subsystems 12.1. Dividing Up a Project.
We can divide this diagram
into clusters of
related classes,
Such as the
Time-Reporting System . . .

11. Chapter 12: Subsystems 12.1. Dividing Up a Project.
Time
Reporting * 1
Project
H.R. System * 1 * *
Unit of
Work
Activity * * *
Position
Assignment
Position * 1 * * 1 1 1 * 1 1
Employee * 1 * *
Credential * *
Enrolment *
Skill
Requirement 1 * * * 1 1
drives
Training
Source 1
Course * 1 * * * *
Skill * 1 *
Licence * * * * 1
Instructor
Course
Offering *

12. Chapter 12: Subsystems 12.1. Dividing Up a Project.
And the
Administration System . . .

13. Chapter 12: Subsystems 12.1. Dividing Up a Project.* 1
Project
H.R. System
Administration
Subsystem * 1 * *
Unit of
Work
Activity * * *
Position
Assignment
Position * 1 * * 1 1 1 * 1 1
Employee * 1 * *
Credential * *
Enrolment *
Skill
Requirement 1 * * * 1 1
drives
Training
Source 1
Course * 1 * * * *
Skill * 1 *
Licence * * * * 1
Instructor
Course
Offering *

14. Chapter 12: Subsystems 12.1. Dividing Up a Project.
And the
Skills & Training System. . .

15. Chapter 12: Subsystems 12.1. Dividing Up a Project.* 1
Project
H.R. System * 1 * *
Unit of
Work
Activity * * *
Position
Assignment
Position * 1 * * 1 1 1 * 1 1
Employee
Skills & Training
Subsystem * 1 * *
Credential * *
Enrolment *
Skill
Requirement 1 * * * 1 1
drives
Training
Source 1
Course * 1 * * * *
Skill * 1 *
Licence * * * * 1
Instructor
Course
Offering *

16. Chapter 12: Subsystems 12.1. Dividing Up a Project.
Of which the
Training part
can be viewed as
a sub-sub-system. . .

17. Chapter 12: Subsystems 12.1. Dividing Up a Project.* 1
Project
H.R. System * 1 * *
Unit of
Work
Activity * * *
Position
Assignment
Position * 1 * * 1 1 1 * 1 1
Employee * 1 * *
Training
Sub-sub-system
Credential * *
Enrolment *
Skill
Requirement 1 * * * 1 1
drives
Training
Source 1
Course * 1 * * * *
Skill * 1 *
Licence * * * * 1
Instructor
Course
Offering *

18. Chapter 12: Subsystems 12.1. Dividing Up a Project.
Note that while there are
many relationships
within each subsystem,
There are relatively few that
cross the boundaries.

19. Chapter 12: Subsystems 12.1. Dividing Up a Project.* 1
Project
H.R. System * 1 * *
Unit of
Work
Activity * * *
Position
Assignment 1 *
Position * 1 * * 1 1 1 * 1 1
Employee * 1 * *
Credential *
Enrolment *
Skill
Requirement
Training
Sub-sub-system 1 * * * 1 1
drives
Training
Source 1
Course * 1 * * *
Skill * 1 *
Licence * *
Skills & Training
Subsystem * * 1
Instructor
Course
Offering *

20. Chapter 12: Subsystems 12.1. Dividing Up a Project.
The Purpose of Subsystems
The human mind can handle only
“Seven  Three”
pieces of information
(Miller 1956,1975)

21. Chapter 12: Subsystems 12.1. Dividing Up a Project.
In other words,
There is a definite limit to the amount of complexity we can handle.
Models divided and encapsulated become
More understandable, and
Better communication tools.

22. Chapter 12: Subsystems 12.1. Dividing Up a Project.
Now we’ve seen what
subsystems are about,
Let’s look at how to go and do this . . .

23. 12.2 How to Subdivide. Chapter 12: Subsystems
12.1. Dividing Up a Project.
12.2 How to Subdivide.
12.3. When to Subdivide.
12.4. Some Special Classes.
12.5. Comparison of Terms.
12.6. The Multilayer Model.

24. Chapter 12: Subsystems
12.2 How to Subdivide.

25. Chapter 12: Subsystems 12.2. How to Subdivide.
Intuitively Obvious
Often the divisions are “obvious”,
But still check the other criteria on the next few slides . . .

26. Chapter 12: Subsystems 12.2. How to Subdivide.
Minimal Interactions and Dependencies
For a subsystem to be an identifiable unit or whole,
Relatively few connections should cross its boundaries.
These connections can be:
Associations from the Class Diagram,
Events passed from one state machine to another (Ch 10),
Messages passed to a class requesting a service,
Responsibilities borne by one class to another.

27. Chapter 12: Subsystems 12.2. How to Subdivide.
Functional Grouping
Our example showed subsystems for
Training
Skills & Training
Time Reporting
Personnel Administration
And so on.
Each exists to handle some
Business Function.

28. Chapter 12: Subsystems 12.2. How to Subdivide.
Functional Grouping
Sometimes the groupings will be by hardware/software function
e.g., Printing, GUI or Database subsystems.
Subsystems may also be set by things happening at a single
Geographical location,
Hardware platform.

29. 12.3 When to Subdivide. Chapter 12: Subsystems
12.1. Dividing Up a Project.
12.2. How to Subdivide.
12.3 When to Subdivide.
12.4. Some Special Classes.
12.5. Comparison of Terms.
12.6. The Multilayer Model.

30. Chapter 12: Subsystems
12.3 When to Subdivide.

31. Chapter 12: Subsystems 12.3. When to Subdivide.
Before you begin
Based on knowledge of users’ business
Systems Request document
Your first encounter with the problem
Your experience allied with your users’ view of the problem
Completion of Requirements Analysis
Pause at this point to check
Maybe reuse a subsystem from an earlier project.

32. Chapter 12: Subsystems 12.3. When to Subdivide.
The Class Diagram
Associations show interactions
and highlight collaborations
The Class Diagram is a powerful tool for finding subsystems
Drawing a “fence” around a subsystem is easy, productive, and above all graphic.
Observe guidelines about “minimal interactions and dependencies.”
Works well at the whiteboard
Trying things out and erasing to try again.

33. Chapter 12: Subsystems 12.3. When to Subdivide.
During Behavior Analysis
As you search for operations/services/methods
Using Use Cases, STDs, Responsibilities etc.
You will see groups of functions that belong together.
Completion of Analysis
A final check.
And at this stage an important use for subsystems . . .

34. Chapter 12: Subsystems 12.3. When to Subdivide.
On the next slide, take a good look at
the Skills and Training subsystem.
Who is this system recording skills data about?

35. Chapter 12: Subsystems 12.1. Dividing Up a Project.* 1
Project
H.R. System * 1 * *
Unit of
Work
Activity * * *
Position
Assignment
Employee
Position * 1 * * 1 1 1 * 1 1
Employee * 1 * *
Credential *
Enrolment *
Skill
Requirement
Training
Sub-sub-system 1 * * * 1 1
drives
Training
Source 1
Course * 1 * * * *
Skill * 1 *
Licence * *
Skills & Training
Subsystem * * 1
Instructor
Course
Offering *

36. Chapter 12: Subsystems 12.3. When to Subdivide.
It’s keeping data about
The Employees, of course.
So the Skills & Training subsystem wouldn’t work too well if there were no Employee data available.
So this means the Employee class must be built with or before the Skills & Training classes.
But not only that . . .

37. Chapter 12: Subsystems 12.3. When to Subdivide.
The link from Position to Skill Requirement
shows that
The Position and Position Assignment data must be in place for the Skills & Training system to work.
So the Employee class and the Admin subsystem
need to be built ahead of the Skills & Training.
But what about
Position 
Skill
Requirement
Time Reporting? . . .

38. Chapter 12: Subsystems 12.3. When to Subdivide.
Time Reporting could be built before or after
the other subsystems,
Except that it requires the Employee class to be in place.

39. Chapter 12: Subsystems 12.3. When to Subdivide.
So we are saying that
By inspecting the models, especially the Class Diagram,
you will see that certain classes or subsystems must be in place
before the others can function.
This determines the development sequence of the subsystems,
and the Class Diagram can be a useful tool
for discussion, understanding and decision-making
with the users.

40. Chapter 12: Subsystems 12.3. When to Subdivide.
But some classes can be a little tricky . . .

41. 12.4 Some Special Classes. Chapter 12: Subsystems
12.1. Dividing Up a Project.
12.2. How to Subdivide.
12.3. When to Subdivide.
12.4 Some Special Classes.
12.5. Comparison of Terms.
12.6. The Multilayer Model.

42. Chapter 12: Subsystems
12.4 Some Special Classes.

43. Chapter 12: Subsystems 12.4. Some Special Classes.
Classes that appear in several subsystems
Employee is the classic example.
Almost every project will need Employee data.
Let’s say that in your modeling, you discover and design an Employee class,
But the HR model already has one,
So you negotiate with the HR people,
And add the things you need
to their existing class.

44. Chapter 12: Subsystems 12.4. Some Special Classes.
Classes that appear in several subsystems
During modeling, the users will often come up with a class
that already exists in another model.
You must compare your definition, attributes and behaviors,
which reflect the needs of your project,
against the existing ones.

45. Chapter 12: Subsystems 12.4. Some Special Classes.
Classes on the Boundaries
Classes whose relationships or message links cross the boundary.
These decisions are not critical,
But can cause heated discussion!
Don’t get into a big argument.
Make a decision and move on.

46. Chapter 12: Subsystems 12.4. Some Special Classes.
Classes on the Boundaries
Look for the subsystem to which this class has more relationship &/or message links.
Logically and intuitively, which subsystem (or set of users) does this class appear to belong to?
Which subsystem has to be built first?
Can it be built without this class?
Judgment call, by team consensus (I can live with it . . .)

47. Chapter 12: Subsystems 12.4. Some Special Classes.
And now some discussion of word usage . . .

48. 12.5 Comparison of Terms. Chapter 12: Subsystems
12.1. Dividing Up a Project.
12.2. How to Subdivide.
12.3. When to Subdivide.
12.4. Some Special Classes.
12.5 Comparison of Terms.
12.6. The Multilayer Model.

49. Chapter 12: Subsystems
12.5 Comparison of Terms.

50. Chapter 12: Subsystems 12.5. Comparison of Terms.
Subjects - Coad & Yourdon
Definition:
“A mechanism for guiding a reader through a large and complex model.”
Subjects (i.e. subsystems) are strictly a means to an end,
They give an overview of a complex model.
They are useful to both technical people (developers) and users.

51. Chapter 12: Subsystems 12.5. Comparison of Terms.
Rebecca Wirfs-Brock
makes an important observation:
“Subsystem boundaries disappear at execution time.”
i.e., they do not show in the program code,
Only in the Analysis and Design models.

52. Chapter 12: Subsystems 12.5. Comparison of Terms.
Shlaer & Mellor
They use the term “Domain”
By which they really mean “senior subsystems”
And which focuses on:
Problem domain,
Software Architecture domain
GUI domain
Operating system domain
etc.
Firesmith(1993) considers the term “domain” possibly misleading and confusing.

53. Chapter 12: Subsystems 12.5. Comparison of Terms.
Donald Firesmith
Prefers the term “subassemblies”
Since they are components out of which the larger system is assembled.

54. 12.6 The Multilayer Model. Chapter 12: Subsystems
12.1. Dividing Up a Project.
12.2. How to Subdivide.
12.3. When to Subdivide.
12.4. Some Special Classes.
12.5. Comparison of Terms.
12.6 The Multilayer Model.

55. Chapter 12: Subsystems
12.6 The Multilayer Model.

56. Chapter 12: Subsystems 12.5. Comparison of Terms.
Layers - Coad & Yourdon
Subsystems are a “vertical” sectioning of a model.
Think of this as standing above the model, reaching down with a knife held vertical to cut out each subsystem.
If you run your “knife” horizontally through the model,
You divide it into
“layers.”

57. Chapter 12: Subsystems 12.5. Comparison of Terms.
Layers - Coad & Yourdon
Think of layers as transparencies,
With part of your model on each,
So you can lay them on the model selectively,
one of top of another
To show different parts of the model together.

58. Chapter 12: Subsystems 12.5. Comparison of Terms.
Layers - Coad & Yourdon
Definition:
Webster: “One thickness lying over or under another.”
Coad & Yourdon: “One level of detail, containing the results of a particular part of the Object-Oriented Analysis process, and it adds information to the other layers.”

59. Chapter 12: Subsystems 12.5. Comparison of Terms.
The 5 Layers
Coad & Yourdon
Subject/Subsystem layer
Class Diagram layer
Structure layer (Subclasses & Aggregations)
Attribute layer
Service/Operation/Behavior layer

60. End of Chapter 12

61. End of Chapter 12

62. End of Chapter 12

63. End of Chapter 12