Improving the Design Can the design be better

Improving the Design “Can the design be better? ” TCS 2411 Software Engineering 1

Lecture Objectives z. To understand the significance of assessing the quality of design z. To describe the major factors and criteria in assessing the quality of software design z. To describe the concepts of coupling and cohesion in measuring software design TCS 2411 Software Engineering 2

A Creative Process z. Software design is a creative process, just like designing anything else z. To see a wrong design, we can check with the requirements in the analysis model z. 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 TCS 2411 Software Engineering 3

Example of Wrong & Bad Design If you are designing a PC: z. Wrong design y. The resulting PC did not have a component specified in requirements, e. g. CD-ROM z. Bad design y. The resulting PC have an extremely fast CPU but extremely slow hard disk, which reduces the performance of the PC TCS 2411 Software Engineering 4

Analysing Software Design z. Generally assess the structure of the design and the modules, evaluating the flexibility, modifiability, understanding and overall maintainability of the system z. Project team should review the design model and improve it z. Many factors are used, such as Coupling, Cohesion, Factoring, System Shape, etc. TCS 2411 Software Engineering 5

Coupling z“The degree of interdependence between two modules” z. We aim to minimise coupling - to make modules as independent as possible z. Low coupling can be achieve by: yeliminating unnecessary relationships yreducing the number of necessary relationships yeaseing the ‘tightness’ of necessary TCS 2411 Software Engineering relationships 6

Types of Coupling z. Data coupling z. Stamp coupling z. Control coupling z. Hybrid coupling z. Common coupling z. Content coupling TCS 2411 Software Engineering good bad 7

Data coupling z. Modules communicate by parameters z. Each parameter is an elementary piece of data z. Each parameter is necessary to the communication z. Nothing extra is needed TCS 2411 Software Engineering Process Results mark grade Calculate Grade 8

Data coupling problems z. Too many parameters - makes the interface difficult to understand possible error to occur z. Tramp data - data ‘traveling’ across modules before being used TCS 2411 Software Engineering 9

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

Control coupling z. A module controls the logic of another module through the parameter z. Controlling module needs to know how the other module works - not flexible! TCS 2411 Software Engineering Check record Error code Display error 11

Hybrid coupling z. A subset of data used as control z. Example: account numbers 00001 to 99999 z. If 90000 - 90999, send mail to area code of last 3 digit (000 - 999) TCS 2411 Software Engineering Main program Data + code Process account 12

Common coupling z. Use of global data as communication between modules z. Dangers of yripple effect yinflexibility ydifficult to understand the use of data TCS 2411 Software Engineering Process Results Global data record updated record Update Grade 13

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

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

Types of Cohesion z. Functional cohesion z. Sequential cohesion z. Communicational cohesion z. Procedural cohesion z. Temporal cohesion z. Logical cohesion z. Coincidental cohesion TCS 2411 Software Engineering good bad 16

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

Sequential cohesion z. Elements are involved in activities such that output data from one activity becomes input data to the next z. Usually has good coupling and is easily maintained z. Not so readily reusable because activities that will not in general be useful together TCS 2411 Software Engineering 18

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 TCS 2411 Software Engineering 19

Communicational Cohesion z. Elements contribute to activities that use the same input or output data z. Not flexible, for example, if we need to focus on some activities and not the others z. Possible links that cause activities to affect each other z. Better to split to functional cohesive ones TCS 2411 Software Engineering 20

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 TCS 2411 Software Engineering 21

Procedural cohesion z. Elements are related only by sequence, otherwise the activities are unrelated z. Similar to sequential cohesion, except for the fact that elements are unrelated z. Commonly found at the top of hierarchy, such as the main program module TCS 2411 Software Engineering 22

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 TCS 2411 Software Engineering 23

Temporal cohesion z. Elements are involved in activities that are related in time z. Commonly found in initialisation and termination modules z. Elements are basically unrelated, so the module will be difficult to reuse z. Good practice is to initialise as late as possible and terminate as early as possible TCS 2411 Software Engineering 24

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

Logical cohesion z. Elements contribute to activities of the same general category (type) z. For example, a report module, display module or I/O module z. Usually have control coupling, since one of the activities will be selected TCS 2411 Software Engineering 26

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 TCS 2411 Software Engineering 27

Coincidental cohesion z. Elements contribute to activities with no meaningful relationship to one another z. Similar to logical cohesion, except the activities may not even be the same type z. Mixture of activities - like ‘rojak’! z. Difficult to understand maintain, with strong possibilities of causing ‘side effects’ every time the module is modified TCS 2411 Software Engineering 28

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

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

Other Design Factors to Consider z. Factoring: reduce module size, clarifying system, minimise duplication of code, separating work from management, creating useful modules, simplifying z. System Shape (Structure) z. Redundancy z. Fan-in/Fan-out z. Restrictivity/Generality TCS 2411 Software Engineering 31

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