![handle-Student- Data() {
Static Struct Student-data[10000];
Store-student-data();
Search-Student-data();
Print-all-students();
};
Communicational Cohesion
Function A
Function B
Function C
Communicational
Access same data](https://image.slidesharecdn.com/desingmethodology-i-241021111046-d928f09a/85/software-_Desing_Methodology-partI-pptx-pdf-41-320.jpg)
software _Desing_Methodology-partI.pptx.pdf
- 1. 1 Software Design - I
- 2. What is Achieved during design phase? • Transformation of SRS document to Design document: – A form easily implementable in some programming language. SRS Document Design Activities Design Documents
- 3. Items Designed During Design Phase • Module structure, • Control relationship among the modules – call relationship or invocation relationship • Interface among different modules, – data items exchanged among different modules, • Data structures of individual modules, • algorithms for individual modules.
- 4. Module • A module consists of: – several functions – associated data structures. Data Functions D1 .. D2 .. D3 .. F1 .. F2 .. F3 .. F4 .. F5 ..
- 6. Iterative Nature of Design • Good software designs: – Seldom arrived through a single step procedure: – But through a series of steps and iterations.
- 7. Stages in Design • Design activities are usually classified into two stages: – Preliminary (or high-level) design – Detailed design. • Meaning and scope of the two stages: – vary considerably from one methodology to another.
- 8. High-level design • Identify: – modules – control relationships among modules – interfaces among modules. d1 d2 d3 d1 d4
- 9. High-level design • The outcome of high-level design: –program structure, also called software architecture.
- 10. High-level Design • Several notations are available to represent high-level design: – Usually a tree-like diagram called structure chart is used. – Other notations: •Jackson diagram or Warnier-Orr diagram can also be used. d1 d2 d3 d1 d4
- 11. Detailed design • For each module, design for it: – data structure – algorithms • Outcome of detailed design: – module specification.
- 12. A fundamental question • How to distinguish between good and bad designs? – Unless we know what a good software design is: •we can not possibly design one.
- 13. Good and bad designs •There is no unique way to design a software. •Even while using the same design methodology: –different engineers can arrive at very different designs. •Need to determine which is a better design.
- 14. What Is a Good Software Design? • Should implement all functionalities of the system correctly. • Should be easily understandable. • Should be efficient. • Should be easily amenable to change, – i.e. easily maintainable.
- 15. What Is Good Software Design? • Understandability of a design is a major issue: – Largely determines goodness of a design: – a design that is easy to understand: •also easy to maintain and change.
- 16. What Is a Good Software Design? • Unless a design is easy to understand, – Tremendous effort needed to maintain it – We already know that about 60% effort is spent in maintenance. • If the software is not easy to understand: – maintenance effort would increase many times.
- 17. How to Improve Understandability? • Use consistent and meaningful names – for various design components, • Design solution should consist of: – A set of well decomposed modules (modularity), • Different modules should be neatly arranged in a hierarchy: – A tree-like diagram. – Called Layering
- 18. Modularity • Modularity is a fundamental attributes of any good design. – Decomposition of a problem into a clean set of modules: – Modules are almost independent of each other – Based on divide and conquer principle.
- 19. Modularity • If modules are independent: – Each module can be understood separately, •reduces complexity greatly. – To understand why this is so, •remember that it is very difficult to break a bunch of sticks but very easy to break the sticks individually.
- 21. :Source Bad design may look like this…
- 22. Modularity • In technical terms, modules should display: – high cohesion – low coupling. • We next discuss: – cohesion and coupling.
- 23. Modularity • Arrangement of modules in a hierarchy ensures: – Low fan-out – Abstraction
- 24. Coupling: Degree of dependence among components No dependencies Loosely coupled-some dependencies Highly coupled-many dependencies High coupling makes modifying parts of the system difficult, e.g., modifying a component affects all the components to which the component is connected. Source: Pfleeger, S., Software Engineering Theory and Practice. Prentice Hall, 2001.
- 25. Cohesion and Coupling • Cohesion is a measure of: – functional strength of a module. – A cohesive module performs a single task or function. • Coupling between two modules: – A measure of the degree of interdependence or interaction between the two modules.
- 26. Cohesion and Coupling • A module having high cohesion and low coupling: – Called functionally independent of other modules: • A functionally independent module needs very little help from other modules and therefore has minimal interaction with other modules.
- 27. Advantages of Functional Independence • Better understandability • Complexity of design is reduced, • Different modules easily understood in isolation: – Modules are independent No dependencies Highly coupled-many dependencies
- 28. Why Functional Independence is Advantageous? • Functional independence reduces error propagation. – degree of interaction between modules is low. – an error existing in one module does not directly affect other modules. • Also: Reuse of modules is possible. No dependencies
- 29. Reuse: An Advantage of Functional Independence • A functionally independent module: – can be easily taken out and reused in a different program. • each module does some well-defined and precise function • the interfaces of a module with other modules is simple and minimal.
- 30. Measuring Functional Independence • Unfortunately, there are no ways: – to quantitatively measure the degree of cohesion and coupling: – At least classification of different kinds of cohesion and coupling: • will give us some idea regarding the degree of cohesiveness of a module.
- 31. Classification of Cohesiveness • Classification can have scope for ambiguity: – yet gives us some idea about cohesiveness of a module. • By examining the type of cohesion exhibited by a module: – we can roughly tell whether it displays high cohesion or low cohesion.
- 33. Coincidental cohesion • The module performs a set of tasks: – which relate to each other very loosely, if at all. •That is, the module contains a random collection of functions. •functions have been put in the module out of pure coincidence without any thought or design.
- 34. Module AAA{ Print-inventory(); Register-Student(); Issue-Book(); }; Coincidental Cohesion - example
- 35. Logical cohesion • All elements of the module perform similar operations: – e.g. error handling, data input, data output, etc. • An example of logical cohesion: – a set of print functions to generate an output report arranged into a single module.
- 36. module print{ void print-grades(student-file){ …} void print-certificates(student-file){…} void print-salary(teacher-file){…} } Logical Cohesion
- 37. Temporal cohesion • The module contains functions so that: – all the functions must be executed in the same time span. • Example: – The set of functions responsible for • initialization, • start-up, shut-down of some process, etc.
- 39. Procedural cohesion • The set of functions of the module: – all part of a procedure (algorithm) – certain sequence of steps have to be carried out in a certain order for achieving an objective, •e.g. the algorithm for decoding a message.
- 40. Communicational cohesion • All functions of the module: – Reference or update the same data structure, • Example: – The set of functions defined on an array or a stack.
- 41. handle-Student- Data() { Static Struct Student-data[10000]; Store-student-data(); Search-Student-data(); Print-all-students(); }; Communicational Cohesion Function A Function B Function C Communicational Access same data
- 42. Sequential cohesion • Elements of a module form different parts of a sequence, – output from one element of the sequence is input to the next. – Example: sort search display
- 43. Functional cohesion • Different elements of a module cooperate: – to achieve a single function, – e.g. managing an employee's pay-roll. • When a module displays functional cohesion, – we can describe the function using a single sentence.
- 44. Determining Cohesiveness • Write down a sentence to describe the function of the module – If the sentence is compound, • it has a sequential or communicational cohesion. – If it has words like “first”, “next”, “after”, “then”, etc. • it has sequential or temporal cohesion. – If it has words like initialize, • it probably has temporal cohesion.
- 45. Thank You!!