1. Software Design Fundamentals Design Principles
Slides from Dr. Dewan Tanvir Ahmed

2. Lecture Objectives
To understand the importance of design in developing quality software
To describe the translation from the requirements analysis model to the design model
To understand the principles that guide proper design of software 2 2

3. Lecture Objectives Design Principles Abstraction Modularity
Information Hiding
Cohesion
Coupling 3 3

4. Software Design Goal: General definition of design Engineering or Art?
“… the process of applying various techniques and principles for the purpose of defining a device, a process, or a system in sufficient detail to permit its physical realization.”
Goal:
To produce a model or representation that will later be built
Engineering or Art? 4 4

5. Software Design Model 5 Information model Functional Behavioral Other
requirements
Design
Code
Test
Data design
Architectural
design
Procedural
Program
modules
Integrated
& validated
software 5 5

6. Software design process6

7. Software architecture
The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design.
The output of this design process is a description of the software architecture. 7

9. General Design Guidelines
Exhibit a hierarchical organization that makes intelligent use of control among components
Logically partitioned into components that perform specific tasks and subtasks
Distinct representation of data and procedure
Lead to interfaces that reduce complexity
Derived using a repeatable method driven by information gathered during requirements 9 9

10. Data Design
The primary activity during data design is to select logical representations of data objects identified during the requirements definition and specification phase.
Transforms the information domain model created during the analysis into the data structures that will be required to implement SW.
Identify the program modules that operate upon the logical data structures
Data design leads to better program structure, effective modularity, & reduced complexity
First activity - most important(?)
Great impact on software quality 10 10

11. Data Specification Principles
Apply functional analysis principles to data
Identify all data structures and associated operations
Establish a data dictionary to define data & program design
Defer low-level data design decisions
Representation of data structure should only be known to modules with direct use of data within the structure
Develop a library of useful data structures
Language should support abstract data types 11 11

12. Architectural Design
Objective is to develop a modular program structure and represent the control relationships between modules
Combines program and data structure by defining interfaces that allows data to flow throughout the program
“Holistic view” of software 12 12

13. Design Principle - Abstraction
It is a means by which one can focus on the important aspects of a problem at a particular level without the hindrance of unnecessary or irrelevant and/or low-level detail.
Abstraction is especially essential in solving complex problems as it enables the problem solver to think in terms of conceptual ideas rather than in terms of their details. Abstraction can be expressed in different ways. [Jeff Kramer] 13

14. Abstraction in Software Engineering
Requirements Engineering - gather the critical aspects of the environment and required system while neglecting the irrelevant.
Goals
Assumptions
Constraints
Scope
Properties
Use Cases?
Requirements
Requirement Specification 14

15. Abstraction in Software Engineering?
Design - clearfy the software architecture and component functionalities which satisfy functional and non-functional requirements while avoiding unnecessary implementation constraints.
Goals
Assumptions
Constraints
Scope
Properties
Use Cases?
User Interface
Business Logic
Data Layer
Requirement Specification
Software Architecture 15

16. Design Principle - Modularity
What is Modularity (or Modularisation):
Decomposing large software into a number of smaller as independent as possible components, usually with the goal of placing different functionalities or responsibilities in different components.
A Component – the basic unit of modularisation (also called Modules) is
A method
A class
A package
Or other design element 16

17. Design Principle - Modularity
Easier to build, easier to change, easier to fix ... 17

18. Design Principle - Modularity
Why Modularity:
Software consists of thousands or millions of lines of code and the complexity can be easily be overwhelming. Modularity allows such complexity to be manageable for purposes of implementation and maintenance.
Where Modularity is needed:
Architectural Design:
Layered software architecture is an example of modularity
Independent Design:
Enable the ability to design different components in different ways. 18

19. Design Principle - Modularity
Where Modularity is needed:
Component Design:
Make sure each component has a single well-defined purpose or function, with few, clear connection (for example, by interfaces) with other components
Debugging:
Make bug finding easier as modularity allows bug finding to be with a particular component rather than the whole software
Testing:
Modularity makes it possible that the testing can be carried out in a piecemeal fashion – one component at a time. This is crucial important for testing of large and integrated software systems 19

20. Design Principle - Modularity
Where Modularity is needed:
Independent Implementation and Development :
Make possible to distribute large software development into each individual in a team of people as far as the interface between components are clear and few.
Summary:
In conclusion, modular based design are useful for each phase of software development, from design, implementation, test, to maintenance.
The reason behind this is that the as much as possible independence between the different components allows that the software tasks can be done separately to overcome high complexity in software development.
So modularity is one of the key principles in software design 20

21. Design Principle - Modularity
Balance component size and complexity
The small size components will require a lot of connections between them in total although less complexity in each component
The large size components will require less connections in total but more complexity in each component
Therefore, a balance of component size is required 21

22. Design Principle – Information Hiding
How to achieve modularity:
Apply information hiding principle and approach
What is the information hiding
In modularisation context:
Components hides the internal details and processing from one another
In more general context:
grouping and packaging the elements and internal details of an abstraction (a component, an abstract data type, a class or a object etc ) and making those details inaccessible
Also called data hiding or encapsulation 22

23. Design Principle – Information Hiding23

24. Design Principle – Information Hiding
Everyday example:
Suppose you have to pay the bill of your newspaper subscription to your hawker. You can give your bill in two ways.
Take out your wallet and give the wallet to the hawker so that he can take his bill’s amount out of your wallet.
Take out your wallet, ask the bill amount from the hawker and give him the asked amount.
Which option is better? 24

25. Design Principle – Information Hiding
Why information hiding in design: each component hides a design decision from the others to achieve
Changeability
If a design decision is changed, such as a data structure, changes are confined to as few components as possible whereas the design as a whole can remain intact
Independent development
Enable independent development as far as the interfaces between components are simple and well defined. Also access methods are often simpler than access data
Comprehensibility
For design, debug, testing and maintenance, it is vital to understand each component independently of others. Information hiding improves our understanding by eliminating confusing from unrelated functions and data. 25

26. Design Principle – Information Hiding
How to achieve information hiding
Apply the information hiding principle in design
Aiming at the end of the design process, any data structure or file is accessed only via certain well-defined specific methods (interfaces)
Separation of interface and implementation
Separating interface and implementation involves defining a component by specifying a public interface, separate from (or hid) the details of how the component is realized.
Choose programming languages support Information hiding
Such as Java, C++, C#, Visual Basic, .Net 26

27. Characteristics of Good Design
Component independence
High cohesion
Low coupling
Dr. Dewan Tanvir Ahmed

28. Design Principle – Coupling and Cohesion
What are Coupling
Coupling is a term to describe the interactions between components. The lower coupling, the less interaction (i.e., the more independence ) between components
Design Principle: Minimise Coupling
Coupling connections cause dependencies between components, which in turn, have an impact on system qualities such as maintainability (a modification of a components may require modifications to its connected components) or testability (a fault in one components may cause a failure in a completely different, connected components). Thus, a common design principle is to minimize coupling. 28

29. Coupling: Degree of dependence among components
No dependencies
Loosely coupled-some 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.
Highly coupled-many dependencies
Dr. Dewan Tanvir Ahmed

30. Design Principle – Coupling and Cohesion
What are Cohesion
Cohesion is a term to describe the interactions within components. The more cohesive a component, the more related the internal parts of the component to each other and to its whole purpose
Design Principle: Maximise Cohesion
A low cohesive design element has been assigned many unrelated responsibilities. Consequently, the design element is more difficult to understand and therefore also harder to maintain and reuse. Design elements with low cohesion should be considered for refactoring, for instance, by extracting parts of the functionality to separate classes with clearly defined responsibilities. 30

31. Design Principle – Coupling and Cohesion
Everyday Example 31

32. Design Principle – Coupling and Cohesion32

33. Design Principle – Coupling and Cohesion
Relationship between Coupling and Cohesion
Coupling and cohesion are opposite sides in that strong cohesion tends to create weak coupling and vice versa 33

34. Design Principle – Coupling and Cohesion
Examples of Coupling and Cohesion
High Coupling
Low Cohesion
Low Coupling
High Cohesion
Which one is better from a software design point of view and why? 34

35. Design Principle – Coupling and Cohesion
Types of coupling:
Content coupling
Common coupling
Control coupling
Stamp coupling
Data coupling 35

36. Types of Coupling
1. Content Coupling (i.e., modifying data within another component)
Allowing one component to modify another component data.
This is very strong coupling as a fault in one component may be caused by another
One component references contents of another
Example:
Component directly modifies another’s data
Component modifies another’s code, e.g., jumps into the middle of a routine 36

37. Types of Coupling
1. Content Coupling (i.e., modifying data within another component)
Example:
Part of program handles lookup for customer.
When customer not found, component adds customer by directly modifying the contents of the data structure containing customer data.
Improvement:
When customer not found, component calls the AddCustomer() method that is responsible for maintaining customer data. 37

38. Types of Coupling 2. Common Coupling (i.e., shared or global data)
Several components sharing the same or global data cause strong coupling between the components via data
Two components share data
Global data structures
Common blocks
Usually a poor design choice because
Lack of clear responsibility for the data
Reduces readability
Difficult to determine all the components that affect a data element (reduces maintainability)
Difficult to reuse components
Reduces ability to control data accesses 38

39. Types of Coupling 2. Common Coupling (i.e., shared or global data)
Process control component maintains current data about state of operation. Gets data from multiple sources. Supplies data to multiple sinks.
Each source process writes directly to global data store. Each sink process reads directly from global data store.
Improvement
Data manager component is responsible for data in data store. Processes send data to and request data from data manager. 39

40. Types of Coupling
Control Coupling (i.e., a method call with a parameter that is a switch)
Passing parameters to control the activity of another component and allowing one component to control another component behaviour.
Component passes control parameters to coupled components.
May be either good or bad, depending on situation.
Bad when component must be aware of internal structure and logic of another module
Good if parameters allow factoring and reuse of functionality 40

41. Types of Coupling Stamp Coupling
This is the case where entire data structures are passed to the called component but only some individual fields are used, or
Component passes a data structure to another component that does not have access to the entire structure.
Requires second component to know how to manipulate the data structure (e.g., needs to know about implementation)
May be necessary due to efficiency factors: this is a choice made by insightful designer, not lazy programmer. 41

42. Types of Coupling Stamp Coupling
Example: The print routine of the customer billing accepts a customer data structure as an argument, parses it, and prints the name, address, and billing information.
Improvement
The print routine takes the customer name, address, and billing information as an argument. 42

43. Types of Coupling Data Coupling
Pass pure data parameters into another component. Often used interaction between components. This is a weak couple and leaves less room for errors
Pass a series stream of data to another component without any transfer of control between components. This is the weakest coupling.
Conclusion
Strong coupling increases dependency and complexity, decreases transparency of components, and leave more room for errors
Weak coupling between components is desired as it increases the modularity, is easy to manage, and reduces errors 43

44. Design Principle – Coupling
The different degree of coupling in order
High Coupling
Content Coupling
Common Coupling
Control Coupling
Stamp Coupling
Data Coupling
Uncoupled
Loose
Low 44

45. Design Principle – Coupling
Types of Cohesion
Coincidental Cohesion
Logical Cohesion
Temporal Cohesion
Procedural Cohesion
Communication Cohesion
Sequential Cohesion
Functional Cohesion 45

46. Design Principle – Coupling and Cohesion
The different degree of cohesion in order
High Cohesion
Functional
Sequential
Communication
Procedural
Temporal
Logical
Coincidental
Low Cohesion 46

47. Design Principle – Types of Cohesion
Coincidental Cohesion
The worst degree of cohesion in which unrelated functions, processes, or data are put into a same component coincidently
Parts of the component are only related by their location in source code
This leads the component without well defined purpose
Example:
Print next line
Reverse string of characters in second argument
Add 7 to 5th argument
Convert 4th argument to float 47

48. Design Principle – Types of Cohesion
Logical Cohesion
Elements of component are related logically and not functionally.
Several logically related elements are in the same component and one of the elements is selected by the client component.
The second worst degree of cohesion where several logically related functions or data elements are placed in the same component
such as all output functions to screen, to printer, to fax machine, and to database are placed together
but without taking into account the different purposes 48

49. Design Principle – Types of Cohesion
Logical Cohesion
Example: A component reads inputs from tape, disk, and network. All the code for these functions are in the same component. Operations are related, but the functions are significantly different.
Solution/Improvement
A device component has a read operation that is overridden by sub-class components. The tape sub-class reads from tape. The disk sub-class reads from disk. The network sub-class reads from the network. 49

50. Design Principle – Types of Cohesion
Temporal Cohesion
Elements of a component are related by timing.
Very weak cohesion in which functions or processes are put into a same component only because they have to be carried out at about the same time
These activities are unrelated to one another except that they’re carried out at a particular time.
Example:
A system initialization routine: this routine contains all of the code for initializing all of the parts of the system. Lots of different activities occur, all at init time.
Improvement:
A system initialization routine sends an initialization message to each component.
Each component initializes itself at component instantiation time. 50

51. Design Principle – Types of Cohesion
Procedural Cohesion
Weak cohesion in which functions or processes are put into a same component only because they happen in a certain order
such as: enter data; check data, and calculation
They are related by order of execution rather than by any single problem- related function. 51

52. Design Principle – Types of Cohesion
Communicational Cohesion
Module performs a series of actions related by a sequence of steps to be followed by the product and all actions are performed on the same data
Update record in database and send it to the printer.
database.Update (record).
record.Print(). 52

53. Design Principle – Types of Cohesion
Communicational Cohesion
Relative weak cohesion in which functions or processes are put into a same component because they act on the same data
such as find title of book; find price of book; find author of book; find publisher of book; find published date of book. These four activities are related because they all work on the same data – book
The weakness is that it is narrow on one side (book) and arbitrarily broad on the other (find title, price, author, publisher, date etc) depending on the number of functions in the component. This could lead to duplication or redundant of functions (think about “book” is changed to PC, then all “find” functions needed to be recoded)
Dr. Dewan Tanvir Ahmed 53

54. Design Principle – Types of Cohesion
Sequential Cohesion
Certain cohesion in which the output from one part of a component is input to the next part
The output of one component is the input to another.
Occurs naturally in functional programming languages
Good situation 54

55. Design Principle – Types of Cohesion
Functional Cohesion
Every essential element to a single computation is contained in the component.
Best cohesion in which every processing element is essential to the performance of a single function, and all essential elements are contained in one component.
The functionally cohesive component performs the function for which it is designed, and only performs that function and nothing else.
Ideal solution 55

56. Examples of Cohesion-1 Dr. Dewan Tanvir Ahmed Function A Coincidental
Time t0
Time t0 + X
Time t0 + 2X
Function A
Function A
Function A’
Function A’’
Function B
Function C
logic
Function D
Function E
Coincidental
Parts unrelated
Logical
Similar functions
Temporal
Related by time
Function A
Function B
Function C
Procedural Related by order of functions
Dr. Dewan Tanvir Ahmed

57. Examples of Cohesion-2 Dr. Dewan Tanvir Ahmed Communicational
Function A
Function B
Function C
Function A
Function B
Function C
Communicational
Access same data
Sequential
Output of one is input to another
Function A part 1
Function A part 2
Function A part 3
Functional
Sequential with complete, related functions
Dr. Dewan Tanvir Ahmed

58. Design Principle – Cohesion
Conclusion
Cohesion is the measure of the functional relatedness of elements (instructions, data definitions, etc.) within a single component. In a good design, the cohesion of every component is high. Together with coupling, cohesion is one of the good measures of the quality of a design. 58

59. High-Level (abstract) design Low-Level (detailed) design
Software
architecture
Subsystem
decomposition
dependencies
interfaces
module or class
Algorithms
Data structures
High-Level
(abstract)
design
Low-Level
(detailed)
design 59

60. Some Desirable Design Attributes
Hierarchical: A good design should be organized into a well-designed hierarchy of components.
Modular: Separate distinct concerns (data and processing) into distinct containers (i.e., subsystems, modules, and/or classes). Hide implementation details and provide clean, simple interfaces for each container. 60

61. Some Desirable Design Attributes
Independent: Group similar things together; limit the amount of “special knowledge” that unrelated components may share. If you change your mind about something, the impact will be localized. 61

62. Some Desirable Design Attributes
Simple Interfaces: Endless flexibility adds complexity. Complex interfaces mean:
hard to understand by users and developers (e.g., Unix man page syndrome)
many possible variations of use
inconvenient to change interface in order to eliminate “bad options”.
You can get away with “flexible interfaces” in a low-level localized setting, but the larger the scale, the simpler the interface should be. 62

63. Submit SRS by next week!