OOD - Principles Design Class Diagrams Chapter 12

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

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

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

From Requirements (Analysis) to Design… Ch10 Ch11

Defining a Single Design Class

Domain Class vs. Design Class

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

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

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

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

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

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

A Design Class (coded in VB)

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

Designing a Design Class Diagram

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

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

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

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.

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

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

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

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.

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

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

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

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

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