1. OOD - Principles Design Class Diagrams
Chapter 12

2. Domain Class vs. Design Class

3. Design Class: Things to Know
Attributes
Elaborate attributes
Methods
Method types
Method Signatures
Instance Level & Class Level (attributes & methods)

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

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

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

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

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

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

10. A Design Class (coded in VB)

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

12. Fundamental Design Principles
Object Responsibility - objects are responsible for carrying out system processing
“Knowing” - attributes & associations
“Doing” - carrying out methods (i.e. doing what they are asked to do)

13. Fundamental Design Principles
Separation of Responsibilities - Separation of Concerns
Segregate classes into groups
Protection from Variations - parts of a system unlikely to change are separated (protected) from those that will surely change
e.g. Separate UI forms that are likely to change from application logic
e.g. Put DB connection & SQL statements that are likely to change in a separate classes from application logic
3-Layer Design

14. Fundamental Design Principles
Coupling - how closely related classes are linked (tightly or loosely coupled)
Two classes are tightly coupled if:
there are lots of associations with another class
there are lots of messages to another class
e.g. a customer object can access a Sale object  this coupling is necessary
e.g. a customer object can access a SaleItem object  this coupling is not
Cohesion – a measure of the focus or unity of purpose within a single class
A class has high cohesiveness if:
all of its responsibilities are consistent & make sense for purpose of the class
e.g. a customer object carries out responsibilities that naturally apply to customers
A class has low cohesiveness if:
its responsibilities are broad
e.g. a customer object requests a new order but also requests that inventory be updated.

15. Fundamental Design Principles
Indirection - an intermediate class should be placed between 2 classes to decouple them but still link them
e.g. Add a controller class between UI classes and problem domain classes