TCS2411 Software Engineering1 Improving the Design “Can the design be better?”

TCS2411 Software Engineering 1

Improving the Design

“Can the design be better?”


Lecture Objectives

To understand the significance of assessing the quality of design

To describe the major factors and criteria in assessing the quality of software design

To describe the concepts of coupling and cohesion in measuring software design


A Creative ProcessSoftware design is a creative process,

just like designing anything elseTo see a wrong design, we can check

with the requirements in the analysis model

To see a bad design, we need to assess the design model and analyse the components, whether the performance can be improved by changing the modules or the interfaces


Example of Wrong & Bad Design

If you are designing a PC:Wrong design

The resulting PC did not have a component specified in requirements, e.g. CD-ROM

Bad design The resulting PC have an extremely fast

CPU but extremely slow hard disk, which reduces the performance of the PC


Analysing Software Design

Generally assess the structure of the design and the modules, evaluating the flexibility, modifiability, understanding and overall maintainability of the system

Project team should review the design model and improve it

Many factors are used, such as Coupling, Cohesion, Factoring, System Shape, etc.


Coupling

“The degree of interdependence between two modules”

We aim to minimise coupling - to make modules as independent as possible

Low coupling can be achieve by: eliminating unnecessary relationships reducing the number of necessary

relationships easeing the ‘tightness’ of necessary

relationships


Types of Coupling

Data couplingStamp couplingControl couplingHybrid couplingCommon couplingContent coupling

good

bad


Data coupling

Modules communicate by parameters

Each parameter is an elementary piece of data

Each parameter is necessary to the communication

Nothing extra is needed

ProcessResults

CalculateGrade

mark grade


Data coupling problems

Too many parameters - makes the interface difficult to understand and possible error to occur

Tramp data - data ‘traveling’ across modules before being used


Stamp coupling

A composite data is passed between modules

Internal structure contains data not used

Bundling - grouping of unrelated data into an artificial structure

ProcessResults

UpdateGrade

record updated record


Control coupling

A module controls the logic of another module through the parameter

Controlling module needs to know how the other module works - not flexible!

Checkrecord

Displayerror

Error code


Hybrid coupling

A subset of data used as control

Example: account numbers 00001 to 99999

If 90000 - 90999, send mail to area code of last 3 digit (000 - 999)

Mainprogram

Processaccount

Data + code


Common coupling

Use of global data as communication between modules

Dangers of ripple effect inflexibility difficult to

understand the use of data

ProcessResults

UpdateGrade

record

updated record

Global data


Content coupling

A module refers to the inside of another module

Branch into another moduleRefers to data within another

moduleChanges the internal

workings of another moduleMostly by low-level

languages


Cohesion“The measure of the strength of functional

relatedness of elements within a module” Elements: instructions, groups of instructions,

data definition, call of another moduleWe aim for strongly cohesive modulesEverything in module should be related to

one another - focus on the taskStrong cohesion will reduce relations

between modules - minimise coupling


Types of Cohesion

Functional cohesionSequential cohesionCommunicational

cohesionProcedural cohesionTemporal cohesionLogical cohesionCoincidental cohesion

good

bad


Functional cohesion

All elements contribute to the execution of one and only one problem-related task

Focussed - strong, single-minded purposeNo elements doing unrelated activitiesExamples of functional cohesive modules:

Compute cosine of angle Read transaction record Assign seat to airline passenger


Sequential cohesion

Elements are involved in activities such that output data from one activity becomes input data to the next

Usually has good coupling and is easily maintained

Not so readily reusable because activities that will not in general be useful together


Example of Sequential Cohesion

module format and cross-validate record

use raw record format raw record cross-validate fields in raw record return formatted cross-validated

recordend module


Communicational Cohesion

Elements contribute to activities that use the same input or output data

Not flexible, for example, if we need to focus on some activities and not the others

Possible links that cause activities to affect each other

Better to split to functional cohesive ones


Example of Communicational Cohesion

module determine customer details use customer account no find customer name find customer loan balance return customer name, loan balanceend module


Procedural cohesion

Elements are related only by sequence, otherwise the activities are unrelated

Similar to sequential cohesion, except for the fact that elements are unrelated

Commonly found at the top of hierarchy, such as the main program module


Example of Procedural Cohesion

module write read and edit something use out record write out record read in record pad numeric fields with zeros return in recordend module


Temporal cohesion

Elements are involved in activities that are related in time

Commonly found in initialisation and termination modules

Elements are basically unrelated, so the module will be difficult to reuse

Good practice is to initialise as late as possible and terminate as early as possible


Example of Temporal Cohesion

module initialise set counter to 0 open student file clear error message variable initialise arrayend module


Logical cohesion

Elements contribute to activities of the same general category (type)

For example, a report module, display module or I/O module

Usually have control coupling, since one of the activities will be selected


Example of Logical Cohesion

module display record use record-type, record if record-type is student then display student record else if record-type is staff then display staff recordend module


Coincidental cohesion

Elements contribute to activities with no meaningful relationship to one another

Similar to logical cohesion, except the activities may not even be the same type

Mixture of activities - like ‘rojak’!Difficult to understand and maintain, with

strong possibilities of causing ‘side effects’ every time the module is modified


Example of Coincidental Cohesion

module miscellaneous functions use customer record display customer record calculate total sales read transaction record return transaction recordend module


Determining Module Cohesion

Doing onefunction

only?

Activitiessame category?

Sequenceimportant?

Modulerelated

by?

Sequenceimportant?

Functional

Sequential

Communicational

Procedural Temporal

Logical

Coincidental

Yes

No

Data None

Control Flow

Yes

Yes

Yes

No

No

No


Other Design Factors to Consider

Factoring: reduce module size, clarifying system,minimise duplication of code, separating work from management, creating useful modules, simplifying

System Shape (Structure)RedundancyFan-in/Fan-outRestrictivity/Generality


References

“Software Engineering: A Practitioner’s Approach” 5th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001

“Software Engineering” by Ian Sommerville, Addison-Wesley, 2001

Documents

TCS2411 Software Engineering1 Improving the Design “Can the design be better?”