1 / 15

OOD - Principles Design Class Diagrams

OOD - Principles Design Class Diagrams. Chapter 12. Domain Class vs. Design Class. Design Class: Things to Know. Attributes Elaborate attributes Methods Method types Method Signatures Instance Level & Class Level (attributes & methods). Elaborating Attributes.

lilak
Download Presentation

OOD - Principles Design Class Diagrams

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 visibilityattributeName: 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. Method Signatures visibilitymethodName(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 • Instance-Level • 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 • 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

More Related