Chapter 11: Object-Oriented Design: Principles

1
Chapter 11 Object-Oriented Design Principles
2
Learning Objectives

• Explain the purpose and objectives of
  object-oriented design
• Develop component diagrams and deployment
  diagrams
• Develop design class diagrams
• Use CRC cards to define class responsibilities
  and collaborations
• Explain the fundamental principles of
  object-oriented design

3
Overview

• This chapter is thorough explanation of how to
  design simple systems
• Architectural design is used to define the
  structure and configuration of the new system
• Good object-oriented design is based on
  fundamental design principles
• Design classes are a fundamental element in
  systems design
• Class-Responsibility-Collaboration (CRC) cards
  are useful for designing simple systems

4
Object-Oriented DesignThe Bridge Between
Analysis and Programming

• Bridge between users requirements and new
  systems programming
• Object-oriented design is process by which
  detailed object-oriented models are built
• Programmers use design to write code and test new
  system
• User interface, network, controls, security, and
  database require design tasks and models

5
Overview of Object-Oriented Programs

• Set of objects that cooperate to accomplish
  result
• Object contains program logic and necessary
  attributes in a single unit
• Objects send each other messages and collaborate
  to support functions of main program
• OO systems designer provides detail for
  programmers
• Design class diagrams, interaction diagrams, and
  some state machine diagrams

6
Object-Oriented Three-Layer Program
7
Object-Oriented Design Processes and Models

• Diagrams developed for analysis/requirements
• Use case diagrams, use case descriptions and
  activity diagrams, domain model class diagrams,
  and system sequence diagrams
• Diagrams developed for design
• Component diagrams and Deployment diagrams
• Interaction diagrams and package diagrams
• Design class diagrams

8
Design Models with Their Respective Input Models
9
Object-Oriented Architectural Design

• Desktop system
• Enterprise-level system
• Network or client/server system
• Internet based system

10
Differences between network and Internet systems
11
Component Diagrams and Architectural Design

• Component Diagram
• Shows overall system architecture.
• Identifies the logical, reusable, and
  transportable components in the system.
• API is the set of all public methods available in
  the component
• Ports and Sockets define the interface
• Frameset notation to extend UML notation
• Used to describe web components

12
Component Diagram Notation
13
Two-layer Architectural Design of an Internet
System
14
Three-layer Architectural Design of an Internet
system
15
Sample Web Services Design
16
Deployment Diagrams

• Deployment diagram shows the placement of various
  physical nodes (components) across different
  location
• Node is a physical component
• Artifact is an executable module
• Artifacts are components after they have been
  compiled into executables

17
Sample Deployment Diagram of an Internet System
18
Component Diagram Example
19
Fundamental Principles of Object-oriented
Detailed Design

• Design class diagrams and detailed sequence
  diagrams
• Use each other as inputs and are developed in
  parallel
• Sequence diagrams define the interactions between
  objects in order to execute a use case.
• Interactions are called messages
• Correspond to method calls in programming
  language
• Design Classes show attributes and method
  signatures

20
Sample Sequence Diagram
21
Sample Design Class
22
Sample Java Class Definition
23
Object-oriented Design Process
24
Design Class Symbols

• UML does not distinguish between design class
  notation and domain model notation
• Domain model class diagram shows conceptual
  classes in users work environment
• Design class diagram specifically defines
  software classes
• UML uses stereotype notation to categorize a
  model element by its characteristics

25
Standard Stereotypes Found in Design Models
26
Standard Design Classes

• Entity design identifier for problem domain
  class
• Persistent class exists after system is shut
  down
• Control mediates between boundary and entity
  classes, between the view layer and domain layer
• Boundary designed to live on systems
  automation boundary, touched by users
• User interface and windows classes
• Data access retrieves data from and sends data
  to database

27
Notation Used to Define a Design Class
28
Design Class Notation

• Name class name and stereotype information
• Attribute visibility (private or public)
  attribute name, type-expression, initial-value,
  property
• Method signature information needed to invoke
  (or call) the method
• Method visibility, method name, type-expression
  (return parameter), method parameter list
  (incoming arguments)?
• Overloaded method method with same name but two
  or more different parameter lists
• Class-level method method associated with class
  instead of each object (static or shared method),
  denoted by an underline

29
Design Class Definitions

• Overloaded method a method with one name but
  different parameter lists
• Class-level method a method associated with the
  class rather than an object
• Class-level attribute an attribute that
  contains the same value for all objects
• Overridden method a method in a subclass that
  overrides the parents method
• Abstract class a class that is never
  instantiated
• Concrete class a normal class with objects

30
Sample Class Diagram with Design Classes and
Inheritance
31
What is a CRC Card?

• What?

• Card

• The class name
• Class responsibilities
• Names of other classes that the class will
  collaborate with to fulfill its responsibilities

32
Why Is CRC Card Useful?

• Gives people a good feel for how aspects of the
  program will work together.
• Allowing people to propose and test changes to
  the design rapidly (all you have to do is make
  new cards)
• Focus on responsibilities as opposed to
  attributes

33
Detailed Design with CRC cards

• Class-Responsibility-Collaboration
• Design process
• Select a single use case
• Identify class with primary responsibility
• Identify other classes that collaborate with
  primary class (become requests for service to
  other classes)?
• Identify responsibilities within each class
  (these become methods)?

34
CRC Card Notation
35
CRC Card Set for Process new order
36
Developing the First-cut Design Class Diagram

• Elaborate the attributes
• Visibility, Type cast, Initial values
• Navigation Visibility
• Ability to reference the methods of another
  object

37
Navigation Visibility
38
Navigation Visibility Guidelines

• One-to-many with superior to subordinate. The
  visibility goes from the superior to the
  subordinate
• Mandatory relationships for existence. Visibility
  goes from independent to dependent
• Object needs information from another object.
  Visibility goes to object with the information
• Navigational arrows may be bidirectional

39
First Cut Class Diagram for RMO
40
Updated Design Class Diagram withVisibility and
Methods
41
Some Fundamental Design Principles

• Encapsulation each object is self-contained
  unit that includes data and methods that access
  data
• Object reuse designers often reuse same classes
  for windows components
• Information hiding data associated with object
  is not visible to outside world

42
Some Fundamental Design Principles (continued)

• Coupling qualitative measure of how closely
  classes in a design class diagram are linked
• Number of navigation arrows in design class
  diagram or messages in a sequence diagram
• Loosely coupled system is easier to understand
  and maintain
• Cohesion qualitative measure of consistency of
  functions within a single class
• Separation of responsibility divide low
  cohesive class into several highly cohesive
  classes
• Highly cohesive system is easier to understand
  and maintain and reuse is more likely

43
Some Fundamental Design Principles (continued)?

• Protection from variations parts of a system
  that are unlikely to change are segregated from
  those that will
• Indirection an intermediate class is placed
  between two classes to decouple them but still
  link them
• Object responsibility Objects are responsible
  for system processing
• Responsibilities include knowing and doing

44
Summary

• Object-oriented design is the bridge between user
  requirements (in analysis models) and final
  system (constructed in programming language)?
• Systems design is driven by use cases, design
  class diagrams, and CRC Cards
• Domain class diagrams are transformed into design
  class diagram

45
Summary (continued)?

• Object-oriented design principles must be applied
• Encapsulation data fields are placed in classes
  along with methods to process that data
• Low coupling connectivity between classes
• High cohesion nature of an individual class
• Protection from variations parts of a system
  that are unlikely to change are segregated from
  those that will
• Indirection an intermediate class is placed
  between two classes to decouple them but still
  link them
• Three-layer design is used because maintainable