1. OOD - Principles Design Class Diagrams
Chapter 12

2. Outline Design Class Design Class Diagram Elabrorate Attrbutes
Elaborate Methods
Design Class Diagram
Add a Controller Class
Add Navigation Visibility

3. OOD: Object-Oriented Design
Specify objects to carry out each use case
Use Case Name:
"Update Student"

4. Analysis to Design to Implementation: Model Flow
Ch 4
Ch 12
Ch 3
Ch 13
Ch 5

5. From Requirements (Analysis) to Design…
Ch10
Ch11

6. Defining a Single Design Class

7. Domain Class vs. Design Class

8. Design Class: Things to Know
Elaborate attributes
Define Method types
Write Method Signatures
Understand the difference between Attributes & Methods
Instance Level
Class Level

9. Elaborating Attributes
visibility attributeName: dataType {property}
Visibility
Public or Private
Data type
Numbers: integer, double
Text: string
True/False: boolean
Dates: dateTime
Property
key

10. Method Types 3 Method types Constructor methods Accessor methods
Get
Set
Processing methods

11. visibility methodName(parameterList) : returnType
Method Signatures
visibility methodName(parameterList) : returnType
Visibility
Public or Private
Method name
Verb phrase
Parameter List
Inputs
Return Type
Output
Typical data type: integer, string, etc
Object (e.g. Student)
Collection of objects: StudentArray

12. Instance-Level vs. Class-Level Attributes & Methods
Pertains to an individual object/instance
Attribute  name
Method  getName(), calcGPA()
Class-Level
Does not pertain to an individual object/instance
Attribute  tuitionPerHour
Method  findAboveHours()
-tuitionPerHour: integer

13. Exercise Design a Design Class for: Vehicle Attributes Method
Primary Key
Instance attribute
Class Attribute
Method
Constructor method
Instance Method
Accessor methods (2)
Processing method
Class Method

14. A Design Class (coded in VB)

15. Design Class Diagram Overridden Method How many attributes are
there in a
MailOrder object?

16. Designing a Design Class Diagram

17. Review – let’s understand this Use Case before continuing
Use Case Description
“Process New Order”

18. Review – let’s understand this model before continuing
Domain Class Diagram

19. Steps: Initial Design Class Diagram
Select a Use Case: “Process New Order”
Add Domain Classes
See pre-conditions & post-conditions for ideas
Elaborate Attributes: visibility, data types

20. Steps: Initial Design Class Diagram
Add a "Controller" class
Switchboard between the View & Domain Layer; a collection point for incoming messages. Include one per use case.

21. Steps: Initial Design Class Diagram
Add Navigation Visibility
(def) the ability of one object to interact with another
1 to Many Association
1  *
Mandatory Associations
IndepDependent
Needs info
Sender Receiver
Rules

22. Steps: Initial Design Class Diagram
Add Methods (we will see this in Ch 13 - Sequence Diagrams)
That is, Behavior!

23. Fundamental Design Principles
Object Responsibility
Separation of Responsibilities
Protection from Variations
Indirection
Coupling - low
Cohesion - high

24. Fundamental Design Principles
Object Responsibility
A design principle that states objects are responsible for carrying out system processing
Responsibilities include:
“Knowing”
Objects know about their attribute values.
Objects know about other objects (associations)
“Doing”
Objects know how to carry out methods, do what they are asked to do.

25. Fundamental Design Principles
Separation of Responsibilities
i.e. Separation of Concerns
Segregate classes into groups based on primary focus of the classes
Basis for multi-layer design – view, domain, data access

26. Fundamental Design Principles
Protection from Variations
A design principle that states parts of a system unlikely to change are separated (protected) from those that will surely change
Example:
Separate UI forms that are likely to change from application logic
Put DB connection and SQL statements that are likely to change in a separate classes from application logic

27. Fundamental Design Principles
Indirection
A design principle that states an intermediate class is placed between two classes to decouple them but still link them
Example:
Add a controller class between UI classes and problem domain classes

28. Fundamental Design Principles
Coupling
A quantitative measure of how closely related classes are linked (tightly or loosely coupled)
Goal: Low Coupling
Two classes are tightly coupled if:
there are lots of associations with another class
there are lots of messages to another class
Example:
A Customer object can access a Sale object  this coupling is necessary
A Customer object can access a SaleItem object  this coupling is unnecessary because only a Sale object should access a SaleItem

29. Fundamental Design Principles
Cohesion
A quantitative measure of the focus or unity of purpose within a single class (high or low cohesiveness)
Goal: High Cohesion
A class has high cohesiveness if:
all of its responsibilities are consistent and make sense for purpose of the class
Example:
A customer objects carries out responsibilities that naturally apply to customers
A class has low cohesiveness if:
its responsibilities are broad