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 0471371378

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 0471371378, “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.

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.

Chapter 12: Subsystems 12.1 Dividing Up a Project.

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.

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.

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.

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

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 *

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 . . .

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 *

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

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 *

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

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 *

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

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 *

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.

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 *

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)

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.

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 . . .

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.

Chapter 12: Subsystems 12.2 How to Subdivide.

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 . . .

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.

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.

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.

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.

Chapter 12: Subsystems 12.3 When to Subdivide.

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.

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.

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 . . .

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?

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 *

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 . . .

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? . . .

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.

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.

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

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.

Chapter 12: Subsystems 12.4 Some Special Classes.

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.

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.

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.

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 . . .)

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

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.

Chapter 12: Subsystems 12.5 Comparison of Terms.

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.

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.

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.

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.

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.

Chapter 12: Subsystems 12.6 The Multilayer Model.

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.”

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.

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.”

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

End of Chapter 12

End of Chapter 12

End of Chapter 12

End of Chapter 12