Software Analysis and Design
Module 8: Class and Method Design
10/7/2024 Faculty of Computer Science 1
Objectives
❖ Become familiar with coupling, cohesion, and connascence.
❖ Be able to specify, restructure, and optimize object designs.
❖ Be able to identify the reuse of predefined classes, libraries,
frameworks, and components.
❖ Be able to specify constraints and contracts.
❖ Be able to create a method specification.
10/7/2024 Faculty of Computer Science 2
Content
❖ Characteristics of object orientation
❖ Design Criteria
❖ Object design activities
❖ Constraints and contracts
❖ Method specification
10/7/2024 Faculty of Computer Science 3
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
10/7/2024 Faculty of Computer Science 4
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
10/7/2024 Faculty of Computer Science 5
Polymorphism Example
10/7/2024 Faculty of Computer Science 6
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
10/7/2024 Faculty of Computer Science 7
Inheritance Conflicts
❖ Permits reuse of existing classes with extensions for new
attributes or operations
❖ 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
10/7/2024 Faculty of Computer Science 8
Content
❖ Characteristics of object orientation
❖ Design Criteria
❖ Object design activities
❖ Constraints and contracts
❖ Method specification
10/7/2024 Faculty of Computer Science 9
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
10/7/2024 Faculty of Computer Science 10
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
10/7/2024 Faculty of Computer Science 11
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
10/7/2024 Faculty of Computer Science 12
Types of Interaction Coupling
10/7/2024 Faculty of Computer Science 13
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
10/7/2024 Faculty of Computer Science 14
Types of Method Cohesion
10/7/2024 Faculty of Computer Science 15
Types of Class Cohesion
10/7/2024 Faculty of Computer Science 16
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
10/7/2024 Faculty of Computer Science 17
Types of Connascence
10/7/2024 Faculty of Computer Science 18
Content
❖ Characteristics of object orientation
❖ Design Criteria
❖ Object design activities
❖ Constraints and contracts
❖ Method specification
10/7/2024 Faculty of Computer Science 19
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
10/7/2024 Faculty of Computer Science 20
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
10/7/2024 Faculty of Computer Science 21
Adding Specifications
❖ 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
10/7/2024 Faculty of Computer Science 22
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
10/7/2024 Faculty of Computer Science 23
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
10/7/2024 Faculty of Computer Science 24
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
10/7/2024 Faculty of Computer Science 25
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
10/7/2024 Faculty of Computer Science 26
Content
❖ Characteristics of object orientation
❖ Design Criteria
❖ Object design activities
❖ Constraints and contracts
❖ Method specification
10/7/2024 Faculty of Computer Science 27
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
10/7/2024 Faculty of Computer Science 28
Constraint Types
❖ 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
10/7/2024 Faculty of Computer Science 29
Sample Contract Form
10/7/2024 Faculty of Computer Science 30
Content
❖ Characteristics of object orientation
❖ Design Criteria
❖ Object design activities
❖ Constraints and contracts
❖ Method specification
10/7/2024 Faculty of Computer Science 31
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)
10/7/2024 Faculty of Computer Science 32
Method Specification Form
10/7/2024 Faculty of Computer Science 33
Algorithm Specification
❖ Algorithm specifications can be written in Structured English or some type of
formal language.
❖ Structured English is simply a formal way of writing instructions that describe the steps of a
process: uses short sentences that clearly describe exactly what work is performed on what
data.
❖ UML’s activity diagram can be useful for algorithm specification of a complex method
10/7/2024 Faculty of Computer Science 34
Algorithm Specification: Example
10/7/2024 Faculty of Computer Science 35
Algorithm Specification: Example
10/7/2024 Faculty of Computer Science 36
Summary
❖ 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
10/7/2024 Faculty of Computer Science 37
Q&A
10/7/2024 Faculty of Computer Science 38