SlideShare a Scribd company logo
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
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 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
THANK YOU
10/1/2016 107

More Related Content

Viewers also liked

Visual Basic –User Interface- V
Visual Basic –User Interface- VVisual Basic –User Interface- V
Visual Basic –User Interface- V
Sharbani Bhattacharya
 
Sharbani bhattacharya iitd
Sharbani bhattacharya iitdSharbani bhattacharya iitd
Sharbani bhattacharya iitd
Sharbani Bhattacharya
 
PHP programmimg
PHP programmimgPHP programmimg
PHP programmimg
Sharbani Bhattacharya
 
Javascript
JavascriptJavascript
How to Make Awesome SlideShares: Tips & Tricks
How to Make Awesome SlideShares: Tips & TricksHow to Make Awesome SlideShares: Tips & Tricks
How to Make Awesome SlideShares: Tips & Tricks
SlideShare
 
Getting Started With SlideShare
Getting Started With SlideShareGetting Started With SlideShare
Getting Started With SlideShare
SlideShare
 

Viewers also liked (6)

Visual Basic –User Interface- V
Visual Basic –User Interface- VVisual Basic –User Interface- V
Visual Basic –User Interface- V
 
Sharbani bhattacharya iitd
Sharbani bhattacharya iitdSharbani bhattacharya iitd
Sharbani bhattacharya iitd
 
PHP programmimg
PHP programmimgPHP programmimg
PHP programmimg
 
Javascript
JavascriptJavascript
Javascript
 
How to Make Awesome SlideShares: Tips & Tricks
How to Make Awesome SlideShares: Tips & TricksHow to Make Awesome SlideShares: Tips & Tricks
How to Make Awesome SlideShares: Tips & Tricks
 
Getting Started With SlideShare
Getting Started With SlideShareGetting Started With SlideShare
Getting Started With SlideShare
 

Similar to Sharbani Bhattacharya SE design & Implementation

System software design1
System software design1System software design1
System software design1
PrityRawat2
 
EFFECTIVE MODULAR DESIGN.pptx
EFFECTIVE MODULAR DESIGN.pptxEFFECTIVE MODULAR DESIGN.pptx
EFFECTIVE MODULAR DESIGN.pptx
DrTThendralCompSci
 
Fundamental design concepts
Fundamental design conceptsFundamental design concepts
Fundamental design concepts
srijavel
 
Software Design - SDLC Model
Software Design - SDLC ModelSoftware Design - SDLC Model
2.Modular Design.pptx
2.Modular Design.pptx2.Modular Design.pptx
2.Modular Design.pptx
REALGROUPS
 
Software design, software engineering
Software design, software engineeringSoftware design, software engineering
Software design, software engineering
Rupesh Vaishnav
 
SE UNIT-3.pdf
SE UNIT-3.pdfSE UNIT-3.pdf
SE UNIT-3.pdf
Dr. Radhey Shyam
 
Se 381 - lec 22 - 24 - 12 may15 - modularity - i - coupling
Se 381 - lec 22 - 24  - 12 may15 - modularity - i - couplingSe 381 - lec 22 - 24  - 12 may15 - modularity - i - coupling
Se 381 - lec 22 - 24 - 12 may15 - modularity - i - coupling
babak danyal
 
effective modular design.pptx
effective modular design.pptxeffective modular design.pptx
effective modular design.pptx
Dr.Shweta
 
Unit-III(Design).pptx
Unit-III(Design).pptxUnit-III(Design).pptx
Unit-III(Design).pptx
Fajar Baskoro
 
Software Eng S3 ( Software Design ).pptx
Software Eng S3 ( Software Design ).pptxSoftware Eng S3 ( Software Design ).pptx
Software Eng S3 ( Software Design ).pptx
gauriVarshney8
 
Se 381 - lec 23 - 28 - 12 may16 - modularity - ii - cohesion
Se 381 - lec 23 - 28 - 12 may16 - modularity - ii - cohesionSe 381 - lec 23 - 28 - 12 may16 - modularity - ii - cohesion
Se 381 - lec 23 - 28 - 12 may16 - modularity - ii - cohesion
babak danyal
 
SE2018_Lec 15_ Software Design
SE2018_Lec 15_ Software DesignSE2018_Lec 15_ Software Design
SE2018_Lec 15_ Software Design
Amr E. Mohamed
 
Design concepts and principles
Design concepts and principlesDesign concepts and principles
Design concepts and principles
saurabhshertukde
 
Software design
Software designSoftware design
Software design
Naveen Sagayaselvaraj
 
System design process.pptx
System design process.pptxSystem design process.pptx
System design process.pptx
NajibMuhammad16
 
Software Engineering Unit 3 PPT Software Design
Software Engineering Unit 3 PPT Software DesignSoftware Engineering Unit 3 PPT Software Design
Software Engineering Unit 3 PPT Software Design
mayanksingh678141
 
Design concept -Software Engineering
Design concept -Software EngineeringDesign concept -Software Engineering
Design concept -Software Engineering
Varsha Ajith
 
Unit 2
Unit 2Unit 2
Coupling and cohesion
Coupling and cohesionCoupling and cohesion
Coupling and cohesion
Sutha31
 

Similar to Sharbani Bhattacharya SE design & Implementation (20)

System software design1
System software design1System software design1
System software design1
 
EFFECTIVE MODULAR DESIGN.pptx
EFFECTIVE MODULAR DESIGN.pptxEFFECTIVE MODULAR DESIGN.pptx
EFFECTIVE MODULAR DESIGN.pptx
 
Fundamental design concepts
Fundamental design conceptsFundamental design concepts
Fundamental design concepts
 
Software Design - SDLC Model
Software Design - SDLC ModelSoftware Design - SDLC Model
Software Design - SDLC Model
 
2.Modular Design.pptx
2.Modular Design.pptx2.Modular Design.pptx
2.Modular Design.pptx
 
Software design, software engineering
Software design, software engineeringSoftware design, software engineering
Software design, software engineering
 
SE UNIT-3.pdf
SE UNIT-3.pdfSE UNIT-3.pdf
SE UNIT-3.pdf
 
Se 381 - lec 22 - 24 - 12 may15 - modularity - i - coupling
Se 381 - lec 22 - 24  - 12 may15 - modularity - i - couplingSe 381 - lec 22 - 24  - 12 may15 - modularity - i - coupling
Se 381 - lec 22 - 24 - 12 may15 - modularity - i - coupling
 
effective modular design.pptx
effective modular design.pptxeffective modular design.pptx
effective modular design.pptx
 
Unit-III(Design).pptx
Unit-III(Design).pptxUnit-III(Design).pptx
Unit-III(Design).pptx
 
Software Eng S3 ( Software Design ).pptx
Software Eng S3 ( Software Design ).pptxSoftware Eng S3 ( Software Design ).pptx
Software Eng S3 ( Software Design ).pptx
 
Se 381 - lec 23 - 28 - 12 may16 - modularity - ii - cohesion
Se 381 - lec 23 - 28 - 12 may16 - modularity - ii - cohesionSe 381 - lec 23 - 28 - 12 may16 - modularity - ii - cohesion
Se 381 - lec 23 - 28 - 12 may16 - modularity - ii - cohesion
 
SE2018_Lec 15_ Software Design
SE2018_Lec 15_ Software DesignSE2018_Lec 15_ Software Design
SE2018_Lec 15_ Software Design
 
Design concepts and principles
Design concepts and principlesDesign concepts and principles
Design concepts and principles
 
Software design
Software designSoftware design
Software design
 
System design process.pptx
System design process.pptxSystem design process.pptx
System design process.pptx
 
Software Engineering Unit 3 PPT Software Design
Software Engineering Unit 3 PPT Software DesignSoftware Engineering Unit 3 PPT Software Design
Software Engineering Unit 3 PPT Software Design
 
Design concept -Software Engineering
Design concept -Software EngineeringDesign concept -Software Engineering
Design concept -Software Engineering
 
Unit 2
Unit 2Unit 2
Unit 2
 
Coupling and cohesion
Coupling and cohesionCoupling and cohesion
Coupling and cohesion
 

More from Sharbani Bhattacharya

Biometric authentication green apple computer learning
Biometric authentication green apple computer learningBiometric authentication green apple computer learning
Biometric authentication green apple computer learning
Sharbani Bhattacharya
 
Visual Basic User Interface-VI
Visual Basic User Interface-VIVisual Basic User Interface-VI
Visual Basic User Interface-VI
Sharbani Bhattacharya
 
Microsoft Front Page
Microsoft Front PageMicrosoft Front Page
Microsoft Front Page
Sharbani Bhattacharya
 
Visual Basic User Interface-III
Visual Basic User Interface-IIIVisual Basic User Interface-III
Visual Basic User Interface-III
Sharbani Bhattacharya
 
Visual Basic User Interface -IV
Visual Basic User Interface -IVVisual Basic User Interface -IV
Visual Basic User Interface -IV
Sharbani Bhattacharya
 
Requirement Analysis & Specification sharbani bhattacharya
Requirement Analysis & Specification sharbani bhattacharyaRequirement Analysis & Specification sharbani bhattacharya
Requirement Analysis & Specification sharbani bhattacharya
Sharbani Bhattacharya
 
Estimation sharbani bhattacharya
Estimation sharbani bhattacharyaEstimation sharbani bhattacharya
Estimation sharbani bhattacharya
Sharbani Bhattacharya
 
Sharbani bhattacharya Visual Basic User Interface-ii
Sharbani bhattacharya  Visual Basic User Interface-iiSharbani bhattacharya  Visual Basic User Interface-ii
Sharbani bhattacharya Visual Basic User Interface-ii
Sharbani Bhattacharya
 
Sharbani Bhattacharya VB User Interface1
Sharbani Bhattacharya VB User Interface1Sharbani Bhattacharya VB User Interface1
Sharbani Bhattacharya VB User Interface1
Sharbani Bhattacharya
 
Sharbani bhattacharya VB Structures
Sharbani bhattacharya VB StructuresSharbani bhattacharya VB Structures
Sharbani bhattacharya VB Structures
Sharbani Bhattacharya
 
Software Metrics & Measurement-Sharbani Bhattacharya
Software Metrics & Measurement-Sharbani BhattacharyaSoftware Metrics & Measurement-Sharbani Bhattacharya
Software Metrics & Measurement-Sharbani Bhattacharya
Sharbani Bhattacharya
 
Slcm sharbani bhattacharya
Slcm sharbani bhattacharyaSlcm sharbani bhattacharya
Slcm sharbani bhattacharya
Sharbani Bhattacharya
 
SE Introduction sharbani bhattacharya
SE Introduction sharbani bhattacharyaSE Introduction sharbani bhattacharya
SE Introduction sharbani bhattacharya
Sharbani Bhattacharya
 
Sharbani bhattacharya Macromedia-flash
Sharbani bhattacharya Macromedia-flashSharbani bhattacharya Macromedia-flash
Sharbani bhattacharya Macromedia-flash
Sharbani Bhattacharya
 
Sharbani bhattacharya Visual Basic
Sharbani bhattacharya Visual BasicSharbani bhattacharya Visual Basic
Sharbani bhattacharya Visual Basic
Sharbani Bhattacharya
 
Sharbani bhattacharya gyanodya 2014
Sharbani bhattacharya gyanodya 2014Sharbani bhattacharya gyanodya 2014
Sharbani bhattacharya gyanodya 2014
Sharbani Bhattacharya
 
Sharbani bhattacharya sacta 2014
Sharbani bhattacharya sacta 2014Sharbani bhattacharya sacta 2014
Sharbani bhattacharya sacta 2014
Sharbani Bhattacharya
 
Sharbani bhattacharya flash
Sharbani bhattacharya flashSharbani bhattacharya flash
Sharbani bhattacharya flash
Sharbani Bhattacharya
 
Sharbani bhattacharya kazan russia
Sharbani bhattacharya kazan russiaSharbani bhattacharya kazan russia
Sharbani bhattacharya kazan russia
Sharbani Bhattacharya
 
E Learning Addon In Pedagogy
E Learning Addon In PedagogyE Learning Addon In Pedagogy
E Learning Addon In Pedagogy
Sharbani Bhattacharya
 

More from Sharbani Bhattacharya (20)

Biometric authentication green apple computer learning
Biometric authentication green apple computer learningBiometric authentication green apple computer learning
Biometric authentication green apple computer learning
 
Visual Basic User Interface-VI
Visual Basic User Interface-VIVisual Basic User Interface-VI
Visual Basic User Interface-VI
 
Microsoft Front Page
Microsoft Front PageMicrosoft Front Page
Microsoft Front Page
 
Visual Basic User Interface-III
Visual Basic User Interface-IIIVisual Basic User Interface-III
Visual Basic User Interface-III
 
Visual Basic User Interface -IV
Visual Basic User Interface -IVVisual Basic User Interface -IV
Visual Basic User Interface -IV
 
Requirement Analysis & Specification sharbani bhattacharya
Requirement Analysis & Specification sharbani bhattacharyaRequirement Analysis & Specification sharbani bhattacharya
Requirement Analysis & Specification sharbani bhattacharya
 
Estimation sharbani bhattacharya
Estimation sharbani bhattacharyaEstimation sharbani bhattacharya
Estimation sharbani bhattacharya
 
Sharbani bhattacharya Visual Basic User Interface-ii
Sharbani bhattacharya  Visual Basic User Interface-iiSharbani bhattacharya  Visual Basic User Interface-ii
Sharbani bhattacharya Visual Basic User Interface-ii
 
Sharbani Bhattacharya VB User Interface1
Sharbani Bhattacharya VB User Interface1Sharbani Bhattacharya VB User Interface1
Sharbani Bhattacharya VB User Interface1
 
Sharbani bhattacharya VB Structures
Sharbani bhattacharya VB StructuresSharbani bhattacharya VB Structures
Sharbani bhattacharya VB Structures
 
Software Metrics & Measurement-Sharbani Bhattacharya
Software Metrics & Measurement-Sharbani BhattacharyaSoftware Metrics & Measurement-Sharbani Bhattacharya
Software Metrics & Measurement-Sharbani Bhattacharya
 
Slcm sharbani bhattacharya
Slcm sharbani bhattacharyaSlcm sharbani bhattacharya
Slcm sharbani bhattacharya
 
SE Introduction sharbani bhattacharya
SE Introduction sharbani bhattacharyaSE Introduction sharbani bhattacharya
SE Introduction sharbani bhattacharya
 
Sharbani bhattacharya Macromedia-flash
Sharbani bhattacharya Macromedia-flashSharbani bhattacharya Macromedia-flash
Sharbani bhattacharya Macromedia-flash
 
Sharbani bhattacharya Visual Basic
Sharbani bhattacharya Visual BasicSharbani bhattacharya Visual Basic
Sharbani bhattacharya Visual Basic
 
Sharbani bhattacharya gyanodya 2014
Sharbani bhattacharya gyanodya 2014Sharbani bhattacharya gyanodya 2014
Sharbani bhattacharya gyanodya 2014
 
Sharbani bhattacharya sacta 2014
Sharbani bhattacharya sacta 2014Sharbani bhattacharya sacta 2014
Sharbani bhattacharya sacta 2014
 
Sharbani bhattacharya flash
Sharbani bhattacharya flashSharbani bhattacharya flash
Sharbani bhattacharya flash
 
Sharbani bhattacharya kazan russia
Sharbani bhattacharya kazan russiaSharbani bhattacharya kazan russia
Sharbani bhattacharya kazan russia
 
E Learning Addon In Pedagogy
E Learning Addon In PedagogyE Learning Addon In Pedagogy
E Learning Addon In Pedagogy
 

Recently uploaded

Introduction to AI Safety (public presentation).pptx
Introduction to AI Safety (public presentation).pptxIntroduction to AI Safety (public presentation).pptx
Introduction to AI Safety (public presentation).pptx
MiscAnnoy1
 
CompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURS
CompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURSCompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURS
CompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURS
RamonNovais6
 
Literature Review Basics and Understanding Reference Management.pptx
Literature Review Basics and Understanding Reference Management.pptxLiterature Review Basics and Understanding Reference Management.pptx
Literature Review Basics and Understanding Reference Management.pptx
Dr Ramhari Poudyal
 
ISPM 15 Heat Treated Wood Stamps and why your shipping must have one
ISPM 15 Heat Treated Wood Stamps and why your shipping must have oneISPM 15 Heat Treated Wood Stamps and why your shipping must have one
ISPM 15 Heat Treated Wood Stamps and why your shipping must have one
Las Vegas Warehouse
 
NATURAL DEEP EUTECTIC SOLVENTS AS ANTI-FREEZING AGENT
NATURAL DEEP EUTECTIC SOLVENTS AS ANTI-FREEZING AGENTNATURAL DEEP EUTECTIC SOLVENTS AS ANTI-FREEZING AGENT
NATURAL DEEP EUTECTIC SOLVENTS AS ANTI-FREEZING AGENT
Addu25809
 
Harnessing WebAssembly for Real-time Stateless Streaming Pipelines
Harnessing WebAssembly for Real-time Stateless Streaming PipelinesHarnessing WebAssembly for Real-time Stateless Streaming Pipelines
Harnessing WebAssembly for Real-time Stateless Streaming Pipelines
Christina Lin
 
Engine Lubrication performance System.pdf
Engine Lubrication performance System.pdfEngine Lubrication performance System.pdf
Engine Lubrication performance System.pdf
mamamaam477
 
Understanding Inductive Bias in Machine Learning
Understanding Inductive Bias in Machine LearningUnderstanding Inductive Bias in Machine Learning
Understanding Inductive Bias in Machine Learning
SUTEJAS
 
一比一原版(CalArts毕业证)加利福尼亚艺术学院毕业证如何办理
一比一原版(CalArts毕业证)加利福尼亚艺术学院毕业证如何办理一比一原版(CalArts毕业证)加利福尼亚艺术学院毕业证如何办理
一比一原版(CalArts毕业证)加利福尼亚艺术学院毕业证如何办理
ecqow
 
Hematology Analyzer Machine - Complete Blood Count
Hematology Analyzer Machine - Complete Blood CountHematology Analyzer Machine - Complete Blood Count
Hematology Analyzer Machine - Complete Blood Count
shahdabdulbaset
 
22CYT12-Unit-V-E Waste and its Management.ppt
22CYT12-Unit-V-E Waste and its Management.ppt22CYT12-Unit-V-E Waste and its Management.ppt
22CYT12-Unit-V-E Waste and its Management.ppt
KrishnaveniKrishnara1
 
BRAIN TUMOR DETECTION for seminar ppt.pdf
BRAIN TUMOR DETECTION for seminar ppt.pdfBRAIN TUMOR DETECTION for seminar ppt.pdf
BRAIN TUMOR DETECTION for seminar ppt.pdf
LAXMAREDDY22
 
Advanced control scheme of doubly fed induction generator for wind turbine us...
Advanced control scheme of doubly fed induction generator for wind turbine us...Advanced control scheme of doubly fed induction generator for wind turbine us...
Advanced control scheme of doubly fed induction generator for wind turbine us...
IJECEIAES
 
spirit beverages ppt without graphics.pptx
spirit beverages ppt without graphics.pptxspirit beverages ppt without graphics.pptx
spirit beverages ppt without graphics.pptx
Madan Karki
 
132/33KV substation case study Presentation
132/33KV substation case study Presentation132/33KV substation case study Presentation
132/33KV substation case study Presentation
kandramariana6
 
2008 BUILDING CONSTRUCTION Illustrated - Ching Chapter 02 The Building.pdf
2008 BUILDING CONSTRUCTION Illustrated - Ching Chapter 02 The Building.pdf2008 BUILDING CONSTRUCTION Illustrated - Ching Chapter 02 The Building.pdf
2008 BUILDING CONSTRUCTION Illustrated - Ching Chapter 02 The Building.pdf
Yasser Mahgoub
 
john krisinger-the science and history of the alcoholic beverage.pptx
john krisinger-the science and history of the alcoholic beverage.pptxjohn krisinger-the science and history of the alcoholic beverage.pptx
john krisinger-the science and history of the alcoholic beverage.pptx
Madan Karki
 
gray level transformation unit 3(image processing))
gray level transformation unit 3(image processing))gray level transformation unit 3(image processing))
gray level transformation unit 3(image processing))
shivani5543
 
Textile Chemical Processing and Dyeing.pdf
Textile Chemical Processing and Dyeing.pdfTextile Chemical Processing and Dyeing.pdf
Textile Chemical Processing and Dyeing.pdf
NazakatAliKhoso2
 
The Python for beginners. This is an advance computer language.
The Python for beginners. This is an advance computer language.The Python for beginners. This is an advance computer language.
The Python for beginners. This is an advance computer language.
sachin chaurasia
 

Recently uploaded (20)

Introduction to AI Safety (public presentation).pptx
Introduction to AI Safety (public presentation).pptxIntroduction to AI Safety (public presentation).pptx
Introduction to AI Safety (public presentation).pptx
 
CompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURS
CompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURSCompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURS
CompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURS
 
Literature Review Basics and Understanding Reference Management.pptx
Literature Review Basics and Understanding Reference Management.pptxLiterature Review Basics and Understanding Reference Management.pptx
Literature Review Basics and Understanding Reference Management.pptx
 
ISPM 15 Heat Treated Wood Stamps and why your shipping must have one
ISPM 15 Heat Treated Wood Stamps and why your shipping must have oneISPM 15 Heat Treated Wood Stamps and why your shipping must have one
ISPM 15 Heat Treated Wood Stamps and why your shipping must have one
 
NATURAL DEEP EUTECTIC SOLVENTS AS ANTI-FREEZING AGENT
NATURAL DEEP EUTECTIC SOLVENTS AS ANTI-FREEZING AGENTNATURAL DEEP EUTECTIC SOLVENTS AS ANTI-FREEZING AGENT
NATURAL DEEP EUTECTIC SOLVENTS AS ANTI-FREEZING AGENT
 
Harnessing WebAssembly for Real-time Stateless Streaming Pipelines
Harnessing WebAssembly for Real-time Stateless Streaming PipelinesHarnessing WebAssembly for Real-time Stateless Streaming Pipelines
Harnessing WebAssembly for Real-time Stateless Streaming Pipelines
 
Engine Lubrication performance System.pdf
Engine Lubrication performance System.pdfEngine Lubrication performance System.pdf
Engine Lubrication performance System.pdf
 
Understanding Inductive Bias in Machine Learning
Understanding Inductive Bias in Machine LearningUnderstanding Inductive Bias in Machine Learning
Understanding Inductive Bias in Machine Learning
 
一比一原版(CalArts毕业证)加利福尼亚艺术学院毕业证如何办理
一比一原版(CalArts毕业证)加利福尼亚艺术学院毕业证如何办理一比一原版(CalArts毕业证)加利福尼亚艺术学院毕业证如何办理
一比一原版(CalArts毕业证)加利福尼亚艺术学院毕业证如何办理
 
Hematology Analyzer Machine - Complete Blood Count
Hematology Analyzer Machine - Complete Blood CountHematology Analyzer Machine - Complete Blood Count
Hematology Analyzer Machine - Complete Blood Count
 
22CYT12-Unit-V-E Waste and its Management.ppt
22CYT12-Unit-V-E Waste and its Management.ppt22CYT12-Unit-V-E Waste and its Management.ppt
22CYT12-Unit-V-E Waste and its Management.ppt
 
BRAIN TUMOR DETECTION for seminar ppt.pdf
BRAIN TUMOR DETECTION for seminar ppt.pdfBRAIN TUMOR DETECTION for seminar ppt.pdf
BRAIN TUMOR DETECTION for seminar ppt.pdf
 
Advanced control scheme of doubly fed induction generator for wind turbine us...
Advanced control scheme of doubly fed induction generator for wind turbine us...Advanced control scheme of doubly fed induction generator for wind turbine us...
Advanced control scheme of doubly fed induction generator for wind turbine us...
 
spirit beverages ppt without graphics.pptx
spirit beverages ppt without graphics.pptxspirit beverages ppt without graphics.pptx
spirit beverages ppt without graphics.pptx
 
132/33KV substation case study Presentation
132/33KV substation case study Presentation132/33KV substation case study Presentation
132/33KV substation case study Presentation
 
2008 BUILDING CONSTRUCTION Illustrated - Ching Chapter 02 The Building.pdf
2008 BUILDING CONSTRUCTION Illustrated - Ching Chapter 02 The Building.pdf2008 BUILDING CONSTRUCTION Illustrated - Ching Chapter 02 The Building.pdf
2008 BUILDING CONSTRUCTION Illustrated - Ching Chapter 02 The Building.pdf
 
john krisinger-the science and history of the alcoholic beverage.pptx
john krisinger-the science and history of the alcoholic beverage.pptxjohn krisinger-the science and history of the alcoholic beverage.pptx
john krisinger-the science and history of the alcoholic beverage.pptx
 
gray level transformation unit 3(image processing))
gray level transformation unit 3(image processing))gray level transformation unit 3(image processing))
gray level transformation unit 3(image processing))
 
Textile Chemical Processing and Dyeing.pdf
Textile Chemical Processing and Dyeing.pdfTextile Chemical Processing and Dyeing.pdf
Textile Chemical Processing and Dyeing.pdf
 
The Python for beginners. This is an advance computer language.
The Python for beginners. This is an advance computer language.The Python for beginners. This is an advance computer language.
The Python for beginners. This is an advance computer language.
 

Sharbani Bhattacharya SE design & Implementation

  • 1. Software Design & Implementation Govt. Polytechnic(W) Faridabad Sr. Member IEEE 29th - 30th September 2016
  • 2. •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
  • 3. 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
  • 4. • 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
  • 5. • 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
  • 6. A design methodology is a systematic approach to creating a design by applying of a set of techniques and guidelines. 10/1/2016 6
  • 7. Two common abstraction mechanisms for software systems are • Functional Abstraction • Data Abstraction 10/1/2016 7
  • 8. 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
  • 9. • 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
  • 10. 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
  • 11. • System debugging • System repair • System building 10/1/2016 11
  • 12. Isolating the system problem to a component is easier if the system is modular. 10/1/2016 12
  • 13. Changing a part of the system is easy as it affects few other parts. 10/1/2016 13
  • 14. A modular system can be easily built by "putting its modules together. 10/1/2016 14
  • 15. 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
  • 16. Modularity is where abstraction and partitioning come together. 10/1/2016 16
  • 17. 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
  • 18. Coupling between modules is the strength of interconnections between modules or a measure of interdependence among modules. 10/1/2016 18
  • 19. • 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
  • 20. • 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. • Coincidental • Logical • Temporal • Procedural • Communicational • Sequential • Function 10/1/2016 24
  • 25. 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
  • 26. • 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
  • 27. • 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
  • 28. 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
  • 29. 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
  • 30. 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
  • 31. 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
  • 33. • 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
  • 34. • _________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
  • 35. • 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
  • 36. • 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
  • 37. 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
  • 38. • Network Metrics • Stability Metrics • Information flow metrics 10/1/2016 38
  • 39. 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
  • 40. 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
  • 41. 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
  • 42. 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
  • 43. 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
  • 44. 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
  • 45. • 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
  • 47. 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
  • 48. • Dynamic Modeling • Functional Modeling 10/1/2016 48
  • 49. • 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
  • 50. • 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
  • 51. • 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
  • 52. • Adding Redundant Associations • Saving Derived Attributes • Use of Generic Types • Adjustment of Inheritance 10/1/2016 52
  • 53. 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
  • 54. 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
  • 55. • 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
  • 56. 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
  • 57. • 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
  • 58. 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
  • 59. • 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
  • 60. • ____________________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
  • 61. • 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
  • 62. • Common Coding Errors • Structured Programming • Information Hiding • Programming Practices 10/1/2016 62
  • 63. • 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
  • 64. • 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
  • 65. 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
  • 66. • 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
  • 67. • Naming Conventions • Files • Statements • Commenting and Layout 10/1/2016 67
  • 68. • 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
  • 69. • 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
  • 70. • 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
  • 71. • 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
  • 72. 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
  • 73. • 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
  • 74. • 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
  • 75. 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
  • 76. • 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
  • 77. 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
  • 78. Refactoring causes • Reduced coupling • Increased cohesion • Better adherence to open-closed principle (for 0 0 systems) 10/1/2016 78
  • 79. • Duplicate Code • Long Method • Long Class • Long Parameter List • Switch Statements • Speculative Generality • Too Much Communication Between Objects • Message Chaining 10/1/2016 79
  • 80. 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
  • 81. • Improving Methods • Improving Classes • Improve Hierarchies 10/1/2016 81
  • 82. • Extract Method • Add/Remove Parameter. 10/1/2016 82
  • 83. • Move Method • Move Field • Extract Class • Replace Data Value with Object 10/1/2016 83
  • 84. • Replace Conditional with Polymorphism • Pull up Field/Method 10/1/2016 84
  • 85. • 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
  • 86. • Reuse • Configuration management • Host-target development 10/1/2016 86
  • 87. 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
  • 88. • The abstraction level • The object level • The component level • The system level 10/1/2016 88
  • 89. • 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
  • 90. 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
  • 91. • 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
  • 92. • 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
  • 93. • 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
  • 94. • Version management • System integration • Problem tracking 10/1/2016 94
  • 95. 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
  • 96. 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
  • 97. 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
  • 98. • 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
  • 99. • 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
  • 100. • The hardware and software requirements of a component • The availability requirements of the system • Component communications 10/1/2016 100
  • 101. 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
  • 102. 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
  • 103. 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
  • 104. • 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
  • 105. • 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
  • 106. • Software Engineering by Somerville • Software Engineering-Pressman • Software Engineering- Pankaj Jalote • Software Engineering Tutorial Point • Software Engineering Wikipedia 10/1/2016 106