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

TCS2411 Software Engineering 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 TCS2411 Software Engineering

TCS2411 Software Engineering A Creative Process Software design is a creative process, just like designing anything else To 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 TCS2411 Software Engineering

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 TCS2411 Software Engineering

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. TCS2411 Software Engineering

TCS2411 Software Engineering 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 TCS2411 Software Engineering

TCS2411 Software Engineering Types of Coupling Data coupling Stamp coupling Control coupling Hybrid coupling Common coupling Content coupling good bad TCS2411 Software Engineering

TCS2411 Software Engineering 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 Process Results mark grade Calculate Grade TCS2411 Software Engineering

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 TCS2411 Software Engineering

TCS2411 Software Engineering Stamp coupling A composite data is passed between modules Internal structure contains data not used Bundling - grouping of unrelated data into an artificial structure Process Results record updated record Update Grade TCS2411 Software Engineering

TCS2411 Software Engineering 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! Check record Error code Display error TCS2411 Software Engineering

TCS2411 Software Engineering 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) Main program Data + code Process account TCS2411 Software Engineering

TCS2411 Software Engineering Common coupling Use of global data as communication between modules Dangers of ripple effect inflexibility difficult to understand the use of data Process Results Global data updated record Update Grade record TCS2411 Software Engineering

TCS2411 Software Engineering Content coupling A module refers to the inside of another module Branch into another module Refers to data within another module Changes the internal workings of another module Mostly by low-level languages TCS2411 Software Engineering

TCS2411 Software Engineering Cohesion “The measure of the strength of functional relatedness of elements within a module” Elements: instructions, groups of instructions, data definition, call of another module We aim for strongly cohesive modules Everything in module should be related to one another - focus on the task Strong cohesion will reduce relations between modules - minimise coupling TCS2411 Software Engineering

TCS2411 Software Engineering Types of Cohesion Functional cohesion Sequential cohesion Communicational cohesion Procedural cohesion Temporal cohesion Logical cohesion Coincidental cohesion good bad TCS2411 Software Engineering

TCS2411 Software Engineering Functional cohesion All elements contribute to the execution of one and only one problem-related task Focussed - strong, single-minded purpose No elements doing unrelated activities Examples of functional cohesive modules: Compute cosine of angle Read transaction record Assign seat to airline passenger TCS2411 Software Engineering

TCS2411 Software Engineering 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 TCS2411 Software Engineering

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 record end module TCS2411 Software Engineering

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 TCS2411 Software Engineering

Example of Communicational Cohesion module determine customer details use customer account no find customer name find customer loan balance return customer name, loan balance end module TCS2411 Software Engineering

TCS2411 Software Engineering 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 TCS2411 Software Engineering

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 record end module TCS2411 Software Engineering

TCS2411 Software Engineering 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 TCS2411 Software Engineering

Example of Temporal Cohesion module initialise set counter to 0 open student file clear error message variable initialise array end module TCS2411 Software Engineering

TCS2411 Software Engineering 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 TCS2411 Software Engineering

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 record end module TCS2411 Software Engineering

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 TCS2411 Software Engineering

Example of Coincidental Cohesion module miscellaneous functions use customer record display customer record calculate total sales read transaction record return transaction record end module TCS2411 Software Engineering

Determining Module Cohesion Doing one function only? Yes Functional Coincidental Sequential No Yes No Sequence important? Module related by? Activities same category? Data None Yes No Control Flow Logical Communicational Sequence important? No Yes Temporal Procedural TCS2411 Software Engineering

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) Redundancy Fan-in/Fan-out Restrictivity/Generality TCS2411 Software Engineering

TCS2411 Software Engineering 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 TCS2411 Software Engineering