Software Design & Implementation

Govt. Polytechnic(W)

Faridabad

Sr. Member IEEE

29th - 30th September 2016

• The design activity begins

when the requirements

document for the software to

be developed is available and

the architecture has been

designed.

• During design we further refine

the architecture.10/1/2016 2

The design process for software

systems often has two levels

• System Design or Top-level

design

• Detailed Design or Logic design

10/1/2016 3

• System design which defines the modules needed for the

system, and how the components interact with each

other.

• During system design a module view of the system is

developed, which should be consistent with the

component view created during architecture design.

10/1/2016 4

• The detailed design refines the system design, by

providing more description of the processing logic of

components and data structures. A design methodology

is a systematic approach to creating a design.

10/1/2016 5

A design methodology is a systematic approach to creating

a design by applying of a set of techniques and guidelines.

10/1/2016 6

Two common abstraction

mechanisms for software systems

are

• Functional Abstraction

• Data Abstraction

10/1/2016 7

A module is specified by the

function it performs.

Example-

A module to compute the log of

a value can be abstractly

represented by the function log.

10/1/2016 8

• Any entity in the real world provides some services to the

environment to which it belongs. Often the entities

provide some fixed predefined services.

• The case of data entities is similar. Certain operations are

required from a data object, depending on the object and

the environment in which it is used.

• Data abstraction supports this view. Data is not treated

simply as objects, but is treated as objects with some

predefined operations on them.

• The operations defined on a data object are the only

operations that can be performed on those objects.

10/1/2016 9

A system is considered modular if it

consists of discreet components so

that each component can be

implemented separately, and a

change to one component has

minimal impact on other

components.

10/1/2016 10

• System debugging

• System repair

• System building

10/1/2016 11

Isolating the system problem to a component is easier if the

system is modular.

10/1/2016 12

Changing a part of the system is easy as it affects few

other parts.

10/1/2016 13

A modular system can be easily built by "putting its

modules together.

10/1/2016 14

For modularity, each module needs to support a well

defined

abstraction and have a clear interface through which it can

interact with other modules.

10/1/2016 15

Modularity is where abstraction and partitioning come

together.

10/1/2016 16

A module is a logically separable part of a program. It is a

program unit that is discreet and identifiable with respect to

compiling and loading.

10/1/2016 17

Coupling between modules is the strength of

interconnections between modules or a measure of

interdependence among modules.

10/1/2016 18

• The more we must know about module A in order to

understand module B, the more closely connected A is to

B. "Highly coupled" modules are joined by strong

interconnections, while "loosely coupled" modules have

weak interconnections.

• Independent modules have no interconnections.

10/1/2016 19

• Coupling increases with the complexity and obscurity of

the interface between modules.

• Coupling is reduced if only the defined entry interface of

a module is used by other modules.

• Coupling would increase if a module is used by other

modules via an indirect and obscure interface, like

directly using the internals of a module or using shared

variables.

• The more complex each interface is, the higher will be

the degree of coupling.

10/1/2016 20

Interface

Complexity

Type of

Connectio

n

Type of

Communicati

on

Low Simple

obvious

To module

by name

Data

High Complicate

d Obscure

To internal

elements

Control

Hybrid

10/1/2016 21

Cohesion of a module represents how tightly bound the

internal elements of the module are to one another.

Cohesion of a module gives the designer an idea about

whether the different elements of a module belong together

in the same module.

10/1/2016 22

The greater the cohesion of each module in the system, the

lower the coupling between modules is.

• Cohesion of a module gives the designer an idea about

whether the different elements of a module belong

together in the same module.

10/1/2016 23

• Coincidental

• Logical

• Temporal

• Procedural

• Communicational

• Sequential

• Function

10/1/2016 24

Coincidental cohesion occurs when there is no meaningful

relationship among the elements of a module. Coincidental

cohesion can occur if an existing program is "modularized"

by chopping it into pieces and making different pieces

modules.

Example - If a module is created to save duplicate code by

combining some part of code that occurs at many different

places, that module is likely to have coincidental cohesion.

10/1/2016 25

• A module has logical cohesion if there is some logical

relationship between the elements of a module, and the

elements perform functions that fall in the same logical

class.

Example of this kind of cohesion is a module that performs

all the inputs or all the outputs. In such a situation, if we

want to input or output a particular record, we have to

somehow convey this to the module.

10/1/2016 26

• Temporal cohesion is the same as logical cohesion,

except that the elements are also related in time and are

executed together.

• Modules that perform activities like "initialization," "clean-

up," and "termination" are usually temporally bound.

10/1/2016 27

A procedurally cohesive module contains elements that

belong to a common procedural unit.

For example, a loop or a sequence of decision statements

in a module may be combined to form a separate module.

Procedurally cohesive modules often occur when modular

structure is determined from some form of flowchart.

10/1/2016 28

A module with communicational cohesion has elements

that are related by a reference to the same input or output

data. That is, in a communicational bound module, the

elements are together because they operate on the same

input or output data.

• Example is- "print and punch record."

10/1/2016 29

When the elements are together in a module because the

output of one forms the input to another, we get sequential

cohesion

• If we have a sequence of elements in which the output of

one forms the input to another, sequential cohesion does

not provide any guidelines on how to combine them into

modules. a sequentially bound module may contain

several functions or parts of different functions.

10/1/2016 30

Functional cohesion is the strongest cohesion. In a

functionally bound module, all the elements of the module

are related to performing a single function.

• Example- Functions like "compute square root" and "sort

the array" are clear examples of functionally cohesive

modules.

10/1/2016 31

10/1/2016 32

• The interface of the module -all data items, their types,

and whether they are for input and/or output.

• The abstract behavior of the module what the module

does by specifying the module's functionality or its

input/output behavior.

• All other modules used by the module being specified—

this information is quite useful in maintaining and

understanding the design.

10/1/2016 33

• _________between modules is the strength of

interconnections between modules.

• A module has _________ if there is some logical

relationship between the elements of a module.

• software systems often has two levels _________

and_______

• ______.

10/1/2016 34

• Coupling between modules is the strength of

interconnections between modules.

• A module has logical cohesion if there is some logical

relationship between the elements of a module.

• Software systems often has two levels system design

and detail design.

10/1/2016 35

• Is each of the functional requirements taken into account?

• Are there analyses to demonstrate that performance requirements can be met?

• Are all assumptions explicitly stated, and are they acceptable?

• Are there any limitations or constraints on the design beyond those in the requirements?

• Are external specifications of each module completely specified?

• Have exceptional conditions been handled?

• Are all the data formats consistent with the requirements?

• Are the operator and user interfaces properly addressed?

• Is the design modular, and does it conform to local standards?

• Are the sizes of data structures estimated? Are provisions made to guard against overflow?

10/1/2016 36

Size is always a product metric of interest, as size is the

single most influential factor deciding the cost of the

project. As the actual size of the project is known only when

the project ends, at early stages the project size is only an

estimate.

10/1/2016 37

• Network Metrics

• Stability Metrics

• Information flow metrics

10/1/2016 38

Network metrics for design focus on the structure chart

(mostly the call graph component of the structure chart)

and define some metrics of how "good" the structure or

network is in an effort to quantify the complexity of the call

graph.

10/1/2016 39

Stability of a design is a metric that tries to quantify the

resistance of a design to the potential ripple effects that are

caused by changes in modules. The higher the stability of a

program design, the better the maintainability of the

program.

10/1/2016 40

The information flow metrics attempt to define the

complexity in terms of the total information flowing through

a module.

The intra module complexity is approximated by the size of

the module in lines of code

10/1/2016 41

The inter module complexity of a module depends on the

total information flowing in the module (inflow) and the total

information flowing out of the module (outflow).

10/1/2016 42

The inflow of a module is the total number of abstract data

elements flowing in the module (i.e., whose values are

used by the module)

10/1/2016 43

The outflow is the total number of abstract data elements

that are flowing out of the module i.e., whose values are

defined by this module and used by other modules.

10/1/2016 44

• The module design complexity, Dc is defined as

Dc =size * (inflow * outflow)2

• The term (inflow * outflow) refers to the total number of

combinations of input source and output destination.

10/1/2016 45

10/1/2016 46

Object Oriented Design consists of the following sequence

of steps

• Produce the class diagram

• Produce the dynamic model and use it to define

operations on classes

• Produce the functional model and use it to define

operations on classes

• Identify internal classes and operations

• Optimize and package

10/1/2016 47

• Dynamic Modeling

• Functional Modeling

10/1/2016 48

• The dynamic model of a system aims to specify how the

state of various objects changes when events occur. An

event is something that happens at some time instance.

• For an object, an event is essentially a request for an

operation. An event typically is an occurrence of

something and has no time duration associated with it.

• Each event has an initiator and a responder.

• Events can be internal to the system, in which case the

event initiator and the event responder are both within

the system.

10/1/2016 49

• A functional model of a system specifies how the output

values are computed in the system from the input values,

without considering the control aspects of the

computation.

• This represents the functional view of the system—the

mapping from inputs to outputs and the various steps

involved in the mapping.

10/1/2016 50

• The classes identified so far are the ones that come from

the problem domain.

• The methods identified on the objects are the ones

needed to satisfy all the interactions with the environment

and the user and to support the desired functionality.

10/1/2016 51

• Adding Redundant Associations

• Saving Derived Attributes

• Use of Generic Types

• Adjustment of Inheritance

10/1/2016 52

As design of classes is the central issue in OOD and the

major output of any OOD methodology is the class

definition, these metrics focus on evaluating classes.

• Weighted Methods per Class (WMC)

• Depth of Inheritance Tree (DIT)

• Number of Children (NOC)

• Coupling Between Classes (CBC)

• Response for a Class (RFC)

• Lack of Cohesion in Methods (LCOM)

10/1/2016 53

Suppose a class C has methods Mi,M2,...,Mn defined on it.

Let the complexity of the method Mi be Ci . As a method is

like a regular function or procedure, any complexity metric

that is applicable for functions can be used to define

Ci(e.g., estimated size, interface complexity, and data flow

complexity).

WMC gives the total number of methods in the class.

WMC = 𝑖=0𝑖=𝑛𝐶𝑖

10/1/2016 54

• The DIT of a class C in an inheritance hierarchy is the

depth from the root class in the inheritance tree. In other

words, it is the length of the shortest path from the root of

the tree to the node representing C or the number of

ancestors C has.

• In case of multiple inheritance, the DIT metric is the

maximum length from a root to C.

10/1/2016 55

The number of children (NOC) metric value of a class C is

the number of immediate subclasses of C. This metric can

be used to evaluate the degree of reuse, as a higher NOC

number reflects reuse of the definitions in the superclass by

a larger number of subclasses.

10/1/2016 56

• Couphng between classes (CBC) is a metric that tries to

quantify coupling that exists between classes.

• The CBC value for a class C is the total number of other

classes to which the class is coupled. Two classes are

considered coupled if methods of one class use methods

or instance variables defined in the other class.

10/1/2016 57

Response for a class (RFC) tries to quantify this by

capturing the total number of methods that can be invoked

from an object of this class.

• The RFC value for a class C is the cardinality of the

response set for a class. The response set of a class C is

the set of all methods that can be invoked if a message is

sent to an object of this class.

• This includes all the methods of C and of other classes to

which any method of C sends a message.

10/1/2016 58

• For classes, cohesion captures how closely bound are the

different methods of the class.

• One way to quantify this is given by the LCOM metric

LCOM - |P| - |g|,if \P\ > \Q\ 0 otherwise

• If there are n methods in a class C, then there are n(n - 1)

pairs, and LOOMis the number of pairs that are non cohesive

minus the number of pairs that are cohesive.

• The larger the number of cohesive methods, the more

cohesive the class will be, and the LOOM metric will be lower.

A high LCOM value may indicate that the methods are trying

to do different things and operate on different data entities,

which may suggest that the class supports multiple

abstractions, rather than one abstraction.10/1/2016 59

• ____________________is metrics of OOD.

• The _____________of a system aims to specify how the

state of various objects changes when events occur.

• The term _____________refers to the total number of

combinations of input source and output destination.

10/1/2016 60

• Weighted Methods per Class is metrics of OOD.

• The dynamic model of a system aims to specify how the

state of various objects changes when events occur.

• The term (inflow * outflow) refers to the total number of

combinations of input source and output destination.

10/1/2016 61

• Common Coding Errors

• Structured Programming

• Information Hiding

• Programming Practices

10/1/2016 62

• Memory Leaks

• Freeing an Already Freed Resource

• NULL Dereferencing

• Lack of Unique Addresses

• Synchronization Errors

• Array Index Out of Bounds

• Arithmetic exceptions

• Off by One

• Enumerated data types

• Illegal use of &; instead of &&

• String handling errors

• Buffer overflow

10/1/2016 63

• Structured programming is often regarded as "goto-less"

programming. Although extensive use of gotos is

certainly not

• desirable, structured programs can be written with the

use of gotos.

• A program has a static structure as well as a dynamic

structure. The static structure is the structure of the

text of the program, which is usually just a linear

organization of statements of the program.

• The dynamic structure of the program is the

sequence of statements executed during the

execution of the program.

10/1/2016 64

Information hiding can reduce the coupling between

modules and make the system more maintainable.

Information hiding is also an effective tool for managing the

complexity of developing software—by using information

hiding we have separated the concern of managing the

data from the concernof using the data to produce some

desired results.

10/1/2016 65

• Control Constructs

• Gotos

• Information Hiding

• User-Defined Types

• Nesting

• Module Size

• Module Interface

• Side Effects

• Robustness

• Switch case v^ith default

10/1/2016 66

• Naming Conventions

• Files

• Statements

• Commenting and Layout

10/1/2016 67

• Package names should be in lower case (e.g.,

mypackage, edu.iitk.maths)

• Type names should be nouns and should start with

uppercase (e.g.,

• Day, DateOfBirth, EventHandler)

• Variable names should be nouns starting with lower case

(e.g., name,

• amount)

• Constant names should be all uppercase (e.g., PI,

MAXJTERATIONS)

10/1/2016 68

• Method names should be verbs starting with lowercase (e.g., getValue())

• Private class variables should have the _ suffix (e.g., "private intvalue_").(Some standards will require this to be a prefix.)

• Variables with a large scope should have long names; variables with a small scope can have short names; loop iterators should be named i, j ,k, etc.

• The prefix is should be used for boolean variables and methods to avoid confusion (e.g., isStatus should be used instead of status); negative boolean variable names (e.g., isNotCorrect) should be avoided.

• The term compute can be used for methods where something is being computed; the term find can be used where something is being looked up (e.g., computeMean(), findMin().)

• Exception classes should be suffixed with Exception (e.g., OutOfBound- Exception.)

10/1/2016 69

• Java source files should have the extension .Java—this

is enforced by most compilers and tools.

• Each file should contain one outer class and the class

nam should be same as the file name.

• Line length should be limited to less than 80 columns an

special characters should be avoided. If the line is longer,

it should be continued and the continuation should be

made very clear.

10/1/2016 70

• Variables should be initialized where declared, and they should be declared in the smallest possible scope.

• Declare related variables together in a common statement Unrelated variables should not be declared in the same statement.

• Class variables should never be declared public.

• Use only loop control statements in a for loop.

• Loop variables should be initialized immediately before the loop.

• Avoid the use of break and continue in a loop.

• Avoid the use of do ... while construct.

• Avoid complex conditional expressions—introduce temporary boolean variables instead.

• Avoid executable statements in conditionals.10/1/2016 71

Comments are textual statements that are meant for the

program reader to aid the understanding of code. The

purpose of comments is not to explain in English the logic

of the program—if the logic is so complex that it requires

comments to explain it, it is better to rewrite and simplify

the code instead.

10/1/2016 72

• In general, comments should explain what the code is doing or

why the code is there, so that the code can become almost

standalone for understanding the system.

• Comments should generally be provided for blocks of code,

and in many cases, only comments for the modules need to

be provided.

• Providing comments for modules is most useful, as modules

form the unit of testing, compiling, verification and

modification.

• Comments for a module are often called prologue for the

module, which describes the functionality and the purpose of

the module, its public interface and how the module is to be

used, parameters of the interface, assumptions it makes about

the parameters, and any side eff"ects it has.10/1/2016 73

• Single line comments for a block of code should be

aligned with the code they are meant for.

• There should be comments for all major variables

explaining what they represent.

• A block of comments should be preceded by a blank

comment line with just "/*" and ended with a line

containing just "*/".

• Trailing comments after statements should be short, on

the same line, and shifted far enough to separate them

from statements.

10/1/2016 74

Layout guidelines focus on how a program should be

indented, how it should use blank lines, white spaces, etc.

to make it more easily readable. Indentation guidelines are

sometimes provided for each type of programming

construct.

10/1/2016 75

• Incremental Coding Process

• Test Driven Development

• Pair Programming

• Source Code Control and Build

• Make changes to file(s)

• Update a local copy

• Get Reports

10/1/2016 76

Refactoring is defined as a change made to the internal

structure of software to make it easier to understand and

cheaper to modify without changing its observable

behavior.

10/1/2016 77

Refactoring causes

• Reduced coupling

• Increased cohesion

• Better adherence to open-closed principle (for 0 0

systems)

10/1/2016 78

• Duplicate Code

• Long Method

• Long Class

• Long Parameter List

• Switch Statements

• Speculative Generality

• Too Much Communication Between Objects

• Message Chaining

10/1/2016 79

To mitigate this risk, the two golden rules are

• Refactor in small steps

• Have test scripts available to test existing functionality

10/1/2016 80

• Improving Methods

• Improving Classes

• Improve Hierarchies

10/1/2016 81

• Extract Method

• Add/Remove Parameter.

10/1/2016 82

• Move Method

• Move Field

• Extract Class

• Replace Data Value with Object

10/1/2016 83

• Replace Conditional with Polymorphism

• Pull up Field/Method

10/1/2016 84

• Do data definitions exploit the typing capabilities of the language?

• Do all the pointers point to some object? (Are there any "dangling pointers"?)

• Are the pointers set to NULL where needed?

• Are pointers being checked for NULL when being used?

• Are all the array indexes within bound?

• Are indexes properly initialized?

• Are all the branch conditions correct (not too weak, not too strong)?

• Will a loop always terminate (no infinite loops)?

• Is the loop termination condition correct?

• Is the number of loop executions "off by one" ?

• Where applicable, are the divisors tested for zero?

• Are imported data tested for validity?

• Do actual and formal interface parameters match?

• Are all variables used? Are all output variables assigned?

• Can statements placed in the loop be placed outside the loop?

• Are the labels unreferenced?

• Will the requirements of execution time be met?

• Are the local coding standards met?

10/1/2016 85

• Reuse

• Configuration management

• Host-target development

10/1/2016 86

Most modern software is constructed by reusing existing

components or systems. When you are developing

software, you should make as much use as possible of

existing code.

10/1/2016 87

• The abstraction level

• The object level

• The component level

• The system level

10/1/2016 88

• At this level, you don’t reuse software directly but rather

use knowledge of successful abstractions in the design of

your software.

• Design patterns and architectural patterns are ways of

representing abstract knowledge for reuse.

10/1/2016 89

At this level, you directly reuse objects from a library rather

than writing the code yourself. To implement this type of

reuse, you have to find appropriate libraries and discover if

the objects and methods offer the functionality that you

need.

• Example, if you need to process mail messages in a Java

program, you may use objects and methods from a Java

Mail library.

10/1/2016 90

• Components are collections of objects and object classes

that operate together to provide related functions and

services. You often have to adapt and extend the

component by adding some code of your own.

• Example-

• This is a set of general object classes that implement

event handling, display management, etc. You add

connections to the data to be displayed and write code to

define specific display details such as screen layout and

colors.

10/1/2016 91

• At this level, you reuse entire application systems. This

usually involves some kind of configuration of these

systems. This may be done by adding and modifying

code (if you are reusing a software product line) or by

using the system’s own configuration interface.

• Most commercial systems are now built in this way where

generic COTS (commercial off-the-shelf) systems are

adapted and reused. Sometimes this approach may

involve reusing several different systems and integrating

these to create a new system.

10/1/2016 92

• During the development process, many different versions

of each software component are created. If you don’t

keep track of these versions in a configuration

management system, you are liable to include the wrong

versions of these components in your system.

10/1/2016 93

• Version management

• System integration

• Problem tracking

10/1/2016 94

Version management, where support is provided to keep

track of the different versions of software components.

Version management systems include facilities to

coordinate development by several programmers. They

stop one developer overwriting code that has been

submitted to the system by someone else.

10/1/2016 95

System integration, where support is provided to help

developers define what versions of components are used

to create each version of a system. This description is then

used to build a system automatically by compiling and

linking the required components.

10/1/2016 96

Problem tracking, where support is provided to allow users

to report bugs and other problems, and to allow all

developers to see who is working on these problems and

when they are fixed.

10/1/2016 97

• Production software does not usually execute on the

same computer as the software development

environment. Rather, you develop it on one computer

(the host system) and execute it on a separate computer

(the

• target system).

• The host and target systems are sometimes of the same

type but, often they are completely different.

10/1/2016 98

• An integrated compiler and syntax-directed editing

system that allows you to create, edit, and compile code.

• A language debugging system.

• Graphical editing tools, such as tools to edit UML models.

• Testing tools, such as JUnit (Massol, 2003) that can

automatically run a set of tests on a new version of a

program.

• Project support tools that help you organize the code for

different development projects.

10/1/2016 99

• The hardware and software requirements of a component

• The availability requirements of the system

• Component communications

10/1/2016 100

If a component is designed for a specific hardware

architecture, or relies on some other software system, it

must obviously be deployed on a platform that provides the

required hardware and software support.

10/1/2016 101

High-availability systems may require components to be

deployed on more than one platform. This means that, in

the event of platform failure, an alternative implementation

of the component is available.

10/1/2016 102

If there is a high level of communications traffic between

components, it usually makes sense to deploy them on the

same platform or on platforms that are physically close to

one other. This reduces communications latency, the delay

between the time a message is sent by one component

and received by another.

10/1/2016 103

• Fundamental _______________are Version

management, System Integration and Problem Tracking.

• The dynamic _________of the program is the sequence

of statements executed during the execution of the

program.

• Refactoring causes reduced________.

10/1/2016 104

• Fundamental configuration management are Version

management, System Integration and Problem Tracking.

• The dynamic structure of the program is the sequence of

statements executed during the execution of the

program.

• Refactoring causes reduced coupling.

10/1/2016 105

• Software Engineering by Somerville

• Software Engineering-Pressman

• Software Engineering- Pankaj Jalote

• Software Engineering Tutorial Point

• Software Engineering Wikipedia

10/1/2016 106

THANK YOU

10/1/2016 107