Sharbani Bhattacharya SE design & Implementation

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 refine10/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

• 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

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
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
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 int
value_").(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

Sharbani Bhattacharya SE design & Implementation

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (6)

Similar to Sharbani Bhattacharya SE design & Implementation

Similar to Sharbani Bhattacharya SE design & Implementation (20)

More from Sharbani Bhattacharya

More from Sharbani Bhattacharya (20)

Recently uploaded

Recently uploaded (20)

Sharbani Bhattacharya SE design & Implementation