CLASS AND METHOD DESIGN

SESSION 8

SUBJECT MATTER EXPERT

D1526 – Syaeful Karim, Ir.,
MComp.
SUB TOPICS

 Object Design Activities

 Constrains and Contracs
 Method Specification
 Verifying and Validating Class and Method Design
ACKNOWLEDGEMENT

These slides have been adapted from:

Denis, Wixom, Tegarden. (2021). Systems Analysisi and

Design : An Object-Oriented Approach with UML. 6 th. edition
ISBN: 978-1-119-55991-7

Chapter 8
LEARNING OBJECTIVES

At the end of this lecture, students are able to:

LO1: Identify the basic concept of advance topic in Object Oriented

Analysis and Design
LO2 : Use the knowledge to develop documentation for object oriented
software analysis and design using Unified Modelling Language
LO3 : Analyze any problem in any software application and find out the
alternative solutions using object oriented analysis and design
approach
INTRODUCTION

Review the characteristics of object orientation

Present useful criteria for evaluating a design
Present design activities for classes and methods
 Present the concept of constraints & contracts to define object
collaboration
Discuss how to specify methods to augment method design
Caution:
• Class & method design must precede coding
• While classes are specified in some detail, jumping into coding
without first designing them may be disastrous
CHARACTERISTICS OF OOSAD

Classes
• Instantiated classes are objects
• Classes are defined with attributes, states & methods
• Classes communicate through messages
Encapsulation & information hiding
• Combine data and operations into a single object
• Reveal only how to make use of an object to other objects
• Key to reusability
Polymorphism & dynamic binding
Inheritance
POLYMORPHISM & DYNAMIC BINDING

Polymorphism
• The ability to take on several different forms
• Same message triggers different methods in different objects
Dynamic binding
• Methods—the specific method used is selected at run time
• Attributes—data type is chosen at run time
• Implementation of dynamic binding is language specific
Decisions made at run time may induce run-time errors
Need to ensure semantic consistency
POLYMORPHISM EXAMPLE
INHERITANCE

 Permits reuse of existing classes with extensions for new attributes

or operations
Types
• Single inheritance -- one parent class
• Multiple inheritance -- multiple parent classes (not supported by all
programming languages)
• Redefinition of methods and/or attributes
Not supported by all programming languages
May cause inheritance conflict
Designers must know what the chosen programming language
supports
INHERITANCE CONFLICTS

An attribute or method in a sub-class with

the same name as an attribute or method in
the super class

Cause is poor classification of sub-classes:

• Generalization semantics are violated, or
• Encapsulation and information hiding
principle is violated

May also occur in cases of multiple

inheritance
DESIGN CRITERIA

A set of metrics to evaluate the design

Coupling—refers to the degree of the closeness of the relationship
between classes

Cohesion—refers to the degree to which attributes and methods of a

class support a single object

Connascence—refers to the degree of interdependency between

objects
COUPLING

Close coupling means that changes in one part of the design may
require changes in another part

Types
• Interaction coupling measured through message passing
• Inheritance coupling deals with the inheritance hierarchy of classes
Minimize interaction coupling by restricting messages (Law of
Demeter)

Minimize inheritance coupling by using inheritance to support only

generalization/specialization and the principle of substitutability
LAW OF DEMETER

Messages should be sent only by an object:

to itself

to objects contained in attributes of itself or a superclass

to an object that is passed as a parameter to the method

to an object that is created by the method

to an object that is stored in a global variable

TYPES OF INTERACTION COUPLING
COHESION

A cohesive class, object or method refers to a single thing

Types
• Method cohesion
Does a method perform more than one operation?
Performing more than one operation is more difficult to understand
and implement
• Class cohesion
Do the attributes and methods represent a single object?
Classes should not mix class roles, domains or objects
• Generalization/specialization cohesion
Classes in a hierarchy should show “a-kind-of” relationship, not
associations or aggregations
TYPES OF METHOD COHESION
TYPES OF CLASS COHESION
CONNASCENCE

 Classes are so interdependent that a change in one necessitates a change

in the other

Good programming practice should:

• Minimize overall connascence; however, when combined with
encapsulation boundaries, you should:

 Minimize across encapsulation boundaries (less interdependence

between or among classes)

Maximize within encapsulation boundary (greater interdependence

within a class)

• A sub-class should never directly access any hidden attribute or method

of a super class
TYPES OF CONNASCENCE
OBJECT DESIGN ACTIVITIES

An extension of analysis & evolution activities

Expand the descriptions of partitions, layers & classes by:
• Adding specifications to the current model
• Identifying opportunities to reuse classes that already exist
• Restructuring the design
• Optimize the design
• Map the problem domain classes into a programming
language
ADDING SPECIFICATIONS

Review the current set of analysis models

• All classes included are both sufficient and necessary to solve
the problem
• No missing attributes or methods
• No extra or unused attributes or methods
• No missing or extra classes
Examine the visibility of classes
• Private—not visible
• Public—visible to other classes
• Protected—visible only to members of the same super class
ADDING SPECIFICATIONS (CONT.)

Decide on method signatures:

• Name of the method
• Parameters or arguments to pass
• Type of value(s) to be returned
Define constraints that must be preserved by the objects
• Preconditions, post-conditions, & invariants
• Decide how to handle constraint violations
IDENTIFY OPPORTUNITIES FOR REUSE

 Design patterns—groupings of classes that help solve a commonly

occurring problem

 Framework—a set of implemented classes that form the basis of

an application

Class libraries—also a set of implemented classes, but more

general in nature than a framework

 Components—self-contained classes used as plug-ins to provide

specific functionality

Choice of approaches depends on the layer

RESTRUCTURING THE DESIGN

Factoring—separating aspects from a class to simplify the design

Normalization—aids in identifying missing classes
Assure all inheritance relationships support only
generalization/specialization semantics
OPTIMIZING THE DESIGN

Balance understandability with efficiency

Methods:
• Review access paths between objects
• Review all attributes of each class
• Review direct (number of messages sent by a method) and
indirect fan-out (number of messages by methods that are
induced by other methods)
• Consider execution order of statements in often-used methods
• Avoid re-computation by creating derived attributes and
triggers
• Consider combining classes that form a one-to-one association
MAPPING PROBLEM-DOMAIN CLASSES

 Factor out multiple inheritance if using a language that supports

only single inheritance

Factor out all inheritance if the language does not support

inheritance

Avoid implementing an object-oriented design in non-object

languages
CONSTRAINTS AND CONTRACTS

A contract is a set of constraints & guarantees

• If the requestor (client) meets the constraints, the responder
(server) will guarantee certain behavior
Constraints must therefore be unambiguous
• Contracts document message passing between objects
• A contract is created for each visible method in a class
• Should contain enough information for the programmer to
understand what the method is supposed to do
Constraint types
• Precondition—must be true before the method executes
• Post-condition—must be true after the method finishes
• Invariant—must always be true for all instances of a class
SAMPLE CONTRACT FORM
METHOD SPECIFICATION

Documentation details for each method

• Allows programmers to code each method
Must be explicit and clear
No formal standards exist, but information should include:
• General information (e.g., method name, class name, etc.)
• Events—anything that triggers a method (e.g., mouse click)
• Message passing including values passed into a method and
those returned from the method
• Algorithm specifications
• Other applicable information (e.g., calculations, procedure
calls)
METHOD SPECIFICATION FORM
SUMMARY

Basic Characteristics of Object Orientation (review)

Design Criteria—coupling, cohesion & connascence
Object Design Activities
Constraints and Contracts
Method Specification
REFERENCES

Denis, Wixom, Tegarden. (2021). Systems Analysisi and

Design : An Object-Oriented Approach with UML. 6 th.

edition
ISBN: 978-1-119-55991-7