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

TCS2411 Software Engineering2 Lecture Objectives zTo understand the significance of assessing the quality of design zTo describe the major factors and criteria in assessing the quality of software design zTo describe the concepts of coupling and cohesion in measuring software design

TCS2411 Software Engineering3 A Creative Process zSoftware design is a creative process, just like designing anything else zTo see a wrong design, we can check with the requirements in the analysis model zTo 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 Engineering4 Example of Wrong & Bad Design If you are designing a PC: zWrong design yThe resulting PC did not have a component specified in requirements, e.g. CD-ROM zBad design yThe resulting PC have an extremely fast CPU but extremely slow hard disk, which reduces the performance of the PC

TCS2411 Software Engineering5 Analysing Software Design zGenerally assess the structure of the design and the modules, evaluating the flexibility, modifiability, understanding and overall maintainability of the system zProject team should review the design model and improve it zMany factors are used, such as Coupling, Cohesion, Factoring, System Shape, etc.

TCS2411 Software Engineering6 Coupling z“The degree of interdependence between two modules” zWe aim to minimise coupling - to make modules as independent as possible zLow coupling can be achieve by: yeliminating unnecessary relationships yreducing the number of necessary relationships yeaseing the ‘tightness’ of necessary relationships

TCS2411 Software Engineering7 Types of Coupling zData coupling zStamp coupling zControl coupling zHybrid coupling zCommon coupling zContent coupling good bad

TCS2411 Software Engineering8 Data coupling zModules communicate by parameters zEach parameter is an elementary piece of data zEach parameter is necessary to the communication zNothing extra is needed Process Results Calculate Grade markgrade

TCS2411 Software Engineering9 Data coupling problems zToo many parameters - makes the interface difficult to understand and possible error to occur zTramp data - data ‘traveling’ across modules before being used

TCS2411 Software Engineering10 Stamp coupling zA composite data is passed between modules zInternal structure contains data not used zBundling - grouping of unrelated data into an artificial structure Process Results Update Grade recordupdated record

TCS2411 Software Engineering11 Control coupling zA module controls the logic of another module through the parameter zControlling module needs to know how the other module works - not flexible! Check record Display error Error code

TCS2411 Software Engineering12 Hybrid coupling zA subset of data used as control zExample: account numbers to zIf , send mail to area code of last 3 digit ( ) Main program Process account Data + code

TCS2411 Software Engineering13 Common coupling zUse of global data as communication between modules zDangers of yripple effect yinflexibility ydifficult to understand the use of data Process Results Update Grade record updated record Global data

TCS2411 Software Engineering14 Content coupling zA module refers to the inside of another module zBranch into another module zRefers to data within another module zChanges the internal workings of another module zMostly by low-level languages

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

TCS2411 Software Engineering16 Types of Cohesion zFunctional cohesion zSequential cohesion zCommunicational cohesion zProcedural cohesion zTemporal cohesion zLogical cohesion zCoincidental cohesion good bad

TCS2411 Software Engineering17 Functional cohesion zAll elements contribute to the execution of one and only one problem-related task zFocussed - strong, single-minded purpose zNo elements doing unrelated activities zExamples of functional cohesive modules: yCompute cosine of angle yRead transaction record yAssign seat to airline passenger

TCS2411 Software Engineering18 Sequential cohesion zElements are involved in activities such that output data from one activity becomes input data to the next zUsually has good coupling and is easily maintained zNot so readily reusable because activities that will not in general be useful together

TCS2411 Software Engineering19 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 Engineering20 Communicational Cohesion zElements contribute to activities that use the same input or output data zNot flexible, for example, if we need to focus on some activities and not the others zPossible links that cause activities to affect each other zBetter to split to functional cohesive ones

TCS2411 Software Engineering21 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 Engineering22 Procedural cohesion zElements are related only by sequence, otherwise the activities are unrelated zSimilar to sequential cohesion, except for the fact that elements are unrelated zCommonly found at the top of hierarchy, such as the main program module

TCS2411 Software Engineering23 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 Engineering24 Temporal cohesion zElements are involved in activities that are related in time zCommonly found in initialisation and termination modules zElements are basically unrelated, so the module will be difficult to reuse zGood practice is to initialise as late as possible and terminate as early as possible

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

TCS2411 Software Engineering26 Logical cohesion zElements contribute to activities of the same general category (type) zFor example, a report module, display module or I/O module zUsually have control coupling, since one of the activities will be selected

TCS2411 Software Engineering27 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 Engineering28 Coincidental cohesion zElements contribute to activities with no meaningful relationship to one another zSimilar to logical cohesion, except the activities may not even be the same type zMixture of activities - like ‘rojak’! zDifficult to understand and maintain, with strong possibilities of causing ‘side effects’ every time the module is modified

TCS2411 Software Engineering29 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 Engineering30 Determining Module Cohesion Doing one function only? Activities same category? Sequence important? Module related by? Sequence important? Functional Sequential Communicational Procedural Temporal Logical Coincidental Yes No DataNone Control Flow Yes No

TCS2411 Software Engineering31 Other Design Factors to Consider zFactoring: reduce module size, clarifying system,minimise duplication of code, separating work from management, creating useful modules, simplifying zSystem Shape (Structure) zRedundancy zFan-in/Fan-out zRestrictivity/Generality

TCS2411 Software Engineering32 References z“Software Engineering: A Practitioner’s Approach” 5th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001 z“Software Engineering” by Ian Sommerville, Addison-Wesley, 2001