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

Software Design Fundamentals

Design Principles

Slides from Dr. Dewan Tanvir Ahmed

Lecture ObjectivesTo understand the importance of design in

developing quality softwareTo describe the translation from the requirements

analysis model to the design modelTo understand the principles that guide proper design

of software

2

Lecture ObjectivesDesign Principles

• Abstraction• Modularity• Information Hiding • Cohesion• Coupling

3

Software DesignGeneral definition of design

“… 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

Software Design Model

Information model

Functional model

Behavioral model

Other requirements

Design

Code

Test

Data design

Architectural design

Procedural design

Programmodules

Integrated& validated

software

5

Software design process

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

6

Software architectureThe 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

General Design GuidelinesExhibit a hierarchical organization that makes

intelligent use of control among componentsLogically partitioned into components that perform

specific tasks and subtasksDistinct representation of data and procedureLead to interfaces that reduce complexityDerived using a repeatable method driven by

information gathered during requirements

9

Data Design

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

The primary activity during data design is to select logical representations of data objects identified during the requirements definition and specification phase.

10

Data Specification Principles

Apply functional analysis principles to data Identify all data structures and associated

operationsEstablish a data dictionary to define data &

program designDefer low-level data design decisionsRepresentation of data structure should only be

known to modules with direct use of data within the structure

Develop a library of useful data structuresLanguage should support abstract data types

11

Architectural DesignObjective 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

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

Abstraction in Software EngineeringRequirements Engineering - gather the critical

aspects of the environment and required system while neglecting the irrelevant.

Requirements

Requirement Specification

GoalsAssumptionsConstraintsScopePropertiesUse Cases?

14

Abstraction in Software Engineering?

Design - clearfy the software architecture and component functionalities which satisfy functional and non-functional requirements while avoiding unnecessary implementation constraints.

GoalsAssumptions

ConstraintsScope

PropertiesUse Cases?

User Interface

Business Logic

Data Layer

Software ArchitectureRequirement Specification

15

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 methodA classA packageOr other design element

16


Easier to build, easier to change, easier to fix ...

17


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


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


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

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

Design Principle – Information HidingHow to achieve modularity: Apply information hiding principle and approach

What is the information hidingIn 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

Design Principle – Information Hiding

23


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?

24

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.

25


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

Dr. Dewan Tanvir Ahmed

Characteristics of Good Design

Component independence High cohesion

Low coupling

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


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.


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


Everyday Example

31


32


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

strong cohesion tends to create weak coupling and vice versa

33


Examples of Coupling and Cohesion

High CouplingLow Cohesion

Low CouplingHigh Cohesion

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

34


Types of coupling:• Content coupling• Common coupling• Control coupling• Stamp coupling• Data coupling

35

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

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

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

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

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

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

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.

ImprovementThe print routine takes the customer name, address, and billing

information as an argument.

42

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

Design Principle – Coupling

The different degree of coupling in order

Content Coupling

Common Coupling

Control Coupling

Stamp Coupling

Data Coupling

Uncoupled

44

High Coupling

Loose

Low

Design Principle – Coupling

Types of Cohesion• Coincidental Cohesion• Logical Cohesion• Temporal Cohesion• Procedural Cohesion• Communication Cohesion• Sequential Cohesion• Functional Cohesion

45


The different degree of cohesion in order

High Cohesion

Low Cohesion

Functional

Sequential

Communication

Procedural

Temporal

Logical

Coincidental

46

Design Principle – Types of CohesionCoincidental 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

Design Principle – Types of CohesionLogical 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

Design Principle – Types of CohesionLogical 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/ImprovementA 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

Design Principle – Types of CohesionTemporal 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

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

Design Principle – Types of CohesionCommunicational 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

Design Principle – Types of CohesionCommunicational 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

Design Principle – Types of CohesionSequential 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

Design Principle – Types of CohesionFunctional 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


Examples of Cohesion-1

Function AFunction

BFunction

D

FunctionC

Function E

CoincidentalParts unrelated

Function A

Function A’

Function A’’

logic

LogicalSimilar functions

Time t0

Time t0 + X

Time t0 + 2X

TemporalRelated by time

Function A

Function B

Function C

Procedural Related by order of functions


Examples of Cohesion-2

Function A part 1

Function A part 2

Function A part 3

FunctionalSequential with complete, related functions

Function A

Function B

Function C

CommunicationalAccess same data

Function A

Function B

Function C

SequentialOutput of one is input to another

Design Principle – CohesionConclusion 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

SoftwarearchitectureSoftware

architecture

SubsystemdecompositionSubsystem

decomposition

SubsystemdependenciesSubsystem

dependencies

Subsysteminterfaces

Subsysteminterfaces

module or classdecomposition

module or classdecomposition

module or classdependencies

module or classdependencies

module or classinterfaces

module or classinterfaces

AlgorithmsAlgorithms

Data structuresData structures

Low-Level(detailed)

design

High-Level(abstract)

design

59

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


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


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

Submit SRS by next week!

Documents

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