software design principles 7 th february, 2007 naveed arshad assistant professor lums...

Software Design Principles

7th February, 2007Naveed ArshadAssistant [email protected]

2 PITB-LUMS Advanced IT Skills Course

© Naveed Arshad 2

Agenda

Design PrinciplesAbstractionModularity Information Hiding CohesionCoupling


© Naveed Arshad 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.


© Naveed Arshad 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?


© Naveed Arshad 5


Everyday example


© Naveed Arshad 6


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]


© Naveed Arshad 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.


© Naveed Arshad 8

VTOL

Jet

Drone

Glider

Military

Space Shuttle

Helicopter

Turboprop

Airship


© Naveed Arshad 9

Types of Abstraction

Abstraction of appearance

Abstraction of structure

Abstraction of functionality

Abstraction of privilege

Abstraction of purpose


© Naveed Arshad 10

VTOL

Jet

Drone

Glider

Military

Space Shuttle

Helicopter

Turboprop

Airship

Exercise: Abstraction of Appearance?


© Naveed Arshad 11

VTOL

Jet

Drone

Glider

Military

Space Shuttle

Helicopter

Turboprop

Airship

Exercise: Abstraction of Structure?


© Naveed Arshad 12

VTOL

Jet

Drone

Glider

Military

Space Shuttle

Helicopter

Turboprop

Airship

Exercise: Abstraction of Functionality?


© Naveed Arshad 13

VTOL

Jet

Drone

Glider

Military

Space Shuttle

Helicopter

Turboprop

Airship

Exercise: Abstraction of Privilege?


© Naveed Arshad 14

VTOL

Jet

Drone

Glider

Military

Space Shuttle

Helicopter

Turboprop

Airship

Exercise: Abstraction of Purpose?


© Naveed Arshad 15

Levels of Abstraction

Abstraction layers e.g. Database


© Naveed Arshad 16

Levels of Abstraction

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


© Naveed Arshad 17

Where is Abstraction Used?

Abstraction is everywhere in Computer Science and Software Engineering


© Naveed Arshad 18

Abstraction in Software Engineering?

Requirements Engineering - gather the critical aspects of the environment and required system while neglecting the irrelevant.

Requirements

GoalsAssumptionsConstraints

ScopeProperties

Use Cases?

Requirement Specification


© Naveed Arshad 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.

GoalsAssumptionsConstraints

ScopeProperties

Use Cases?

User Interface

Business Logic

Data Layer

Software ArchitectureRequirement Specification


© Naveed Arshad 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


© Naveed Arshad 21

Design Principle - ModularityEveryday Example


© Naveed Arshad 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.


© Naveed Arshad 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


© Naveed Arshad 24

Design Principle - ModularityWhere 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


© Naveed Arshad 25

Design Principle - ModularityHow 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


© Naveed Arshad 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


© Naveed Arshad 27


Everyday example: Suppose you have to pay the bill of your newspaper

subscription to your hawker. You can give your bill in two ways.

1. Take out your wallet and give the wallet to the hawker so that he can take his bill’s amount out of your wallet.

2. Take out your wallet, ask the bill amount from the hawker and give him the asked amount.

Which option is better?


© Naveed Arshad 28

Design Principle – Information HidingWhy 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.


© Naveed Arshad 29


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


© Naveed Arshad 30

Design Principle – Coupling and CohesionWhat 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.


© Naveed Arshad 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.


© Naveed Arshad 32


Everyday Example


© Naveed Arshad 33


Everyday Example


© Naveed Arshad 34


Relationship between Coupling and Cohesion Coupling and cohesion are opposite sides in that

strong cohesion tends to create weak coupling and vice versa


© Naveed Arshad 35

Design Principle – Coupling and CohesionExamples of Coupling and Cohesion

High CouplingLow Cohesion

Low CouplingHigh Cohesion

Which one is better from a software design point of view and why?


© Naveed Arshad 37


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


© Naveed Arshad 38


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


© Naveed Arshad 39


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


© Naveed Arshad 40


The different degree of coupling in order

High Coupling

Low Coupling

Content Coupling

Common Coupling

Control Coupling

Sample Coupling

Data Coupling

Uncoupled


© Naveed Arshad 41


Types of Cohesion

Coincidental Cohesion Logical Cohesion Temporal Cohesion Procedural Cohesion Communication Cohesion Sequential Cohesion Functional Cohesion


© Naveed Arshad 42


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


© Naveed Arshad 43


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.


© Naveed Arshad 44


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)


© Naveed Arshad 45


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.


© Naveed Arshad 46


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.


© Naveed Arshad 47


The different degree of cohesion in order

High Cohesion

Low Cohesion

Functional

Sequential

Communication

Procedural

Temporal

Logical

Coincidental


© Naveed Arshad 48

References

To prepare these slides I have used notes and slides from these peopleXiao-Jun Zeng Jeff Kramer

software design principles 7 th february, 2007 naveed arshad assistant professor lums...

Documents

pitblums advanced

skills course naveed

database slide

cohesion coupling slide

jeff kramer slide

irrelevant details

software design principles

different items