1. Software Design Principles 7th February, 2007
Naveed Arshad
Assistant Professor
LUMS

2. Agenda Design Principles Abstraction Modularity Information Hiding
Cohesion
Coupling

3. 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.

4. Design Principle - Abstraction (cont’d)
Hiding Low Level Details
Where the details are coming from in the first place?
How to hide details?
What are details?
How to extract important information from a mess of information?

5. Design Principle - Abstraction
Everyday example

6. Design Principle - Abstraction
Abstraction is a central topic both in CS and in SE. It is a cognitive means according to which, in order to overcome complexity at a specific stage of a problem solving situation, we concentrate on the essential features of our subject of thought, and ignore irrelevant details.
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]

7. Abstraction – Why do we need it?
Our mind can work with only 7(+/-) 2 items at one time.
If we are given a long list of items we abstract out commonalities between different items and put these items into various categories.

8. Jet
Drone
VTOL
Military
Space Shuttle
Glider
Turboprop
Helicopter
Airship

9. Types of Abstraction Abstraction of appearance
Abstraction of structure  
Abstraction of functionality  
Abstraction of privilege  
Abstraction of purpose

10. Exercise: Abstraction of Appearance?
Jet
Drone
VTOL
Military
Space Shuttle
Glider
Turboprop
Helicopter
Airship

11. Exercise: Abstraction of Structure?
Jet
Drone
VTOL
Military
Space Shuttle
Glider
Turboprop
Helicopter
Airship

12. Exercise: Abstraction of Functionality?
Jet
Drone
VTOL
Military
Space Shuttle
Glider
Turboprop
Helicopter
Airship

13. Exercise: Abstraction of Privilege?
Jet
Drone
VTOL
Military
Space Shuttle
Glider
Turboprop
Helicopter
Airship

14. Exercise: Abstraction of Purpose?
Jet
Drone
VTOL
Military
Space Shuttle
Glider
Turboprop
Helicopter
Airship

15. Levels of Abstraction
Abstraction layers
e.g. Database

16. Levels of Abstraction
Describe this device in at least four different ways of abstraction? Describe the context, meaning and purpose of these abstraction?

17. Where is Abstraction Used?
Abstraction is everywhere in Computer Science and Software Engineering

18. 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

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

20. 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

21. Design Principle - Modularity
Everyday Example

22. 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.

23. 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
Make bug fixed easier as correction to a single component will not produce “knock-on” effects
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

24. 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

25. Design Principle - Modularity
How to achieve modularity: Hierarchical decomposition design with the different level of abstraction:
Decompose the components with clearly defined input and output and well identified purpose
Decompose the components from higher more abstract level to lower more detailed level
Minimise the interactions between components
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

26. 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

27. 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?

28. 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.

29. 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

30. 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.

31. 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.

32. Design Principle – Coupling and Cohesion
Everyday Example

33. Design Principle – Coupling and Cohesion
Everyday Example

34. 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

35. 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?

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

37. Design Principle – Coupling and Cohesion
Types of Coupling
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
Common Coupling (i.e., shared or global data)
Several components sharing the same or global data cause strong coupling between the components via data

38. Design Principle – Coupling and Cohesion
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. This is a relatively strong couple as a fault in one component may be caused by another
Sample Coupling
This is the case where entire data structures are passed to the called component but only some individual fields are used

39. Design Principle – Coupling and Cohesion
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 and supported by Java
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

40. Design Principle – Coupling and Cohesion
The different degree of coupling in order
High Coupling
Content Coupling
Common Coupling
Control Coupling
Sample Coupling
Data Coupling
Uncoupled
Low Coupling

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

42. Design Principle – Coupling and Cohesion
Types of Cohesion
Coincidental Cohesion
The worst degree of cohesion in which unrelated functions, processes, or data are put into a same component coincidently
such as order book, watch TV, walk dog, go shopping.
This leads the component without well defined purpose
Logical Cohesion
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

43. Design Principle – Coupling and Cohesion
Types of Cohesion
Temporal Cohesion
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
such as: put out milk bottle, put out cat; turn off TV; brush teeth. They’re all part of an end-of-day routine.
These activities are unrelated to one another except that they’re carried out at a particular time.
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.

44. Design Principle – Coupling and Cohesion
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)

45. Design Principle – Coupling and Cohesion
Types of Cohesion
Sequential Cohesion
Certain cohesion in which the output from one part of a component is input to the next part
such as: clear car body; fill in holes in car; sand car body; apply primer
This group of four activities can not be summed up as a single function (purpose), which means the component is not functionally cohesive (as they are not constructed to a well defined function or purpose). If adding one more step ”put final coat”, we would have a functionally cohesive component called REPAINT CAR.

46. Design Principle – Coupling and Cohesion
Types of Cohesion
Functional Cohesion
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.
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.

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

48. References
To prepare these slides I have used notes and slides from these people
Xiao-Jun Zeng
Jeff Kramer