Department of Computer Application (MCA)

MCA-203- Software Engineering & UML {UNIT-II} 1

Department of Computer Application

MCA-203- Software Engineering & UML

UNIT-II
Software Design: Abstraction, Modularity, Software Architecture, Cohesion & Coupling, Various
Design Concepts and notations, Development of Detailed Design & Creation of Software Design,
Document – Dataflow Oriented design, Designing for reuse, Programming standards.

SOFTWARE DESIGN: DESIGN PRINCIPLES

Design principles:
Software design principles are concerned with providing means to handle the complexity of the design process
effectively. Effectively managing the complexity will not only reduce the effort needed for design but can also
reduce the scope of introducing errors during design.

Following are the principles of Software Design

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 2

Problem Partitioning
For small problem, we can handle the entire problem at once but for the significant problem, divide the problems
and conquer the problem it means to divide the problem into smaller pieces so that each piece can be captured
separately.

For software design, the goal is to divide the problem into manageable pieces.

Benefits of Problem Partitioning

1. Software is easy to understand.
2. Software becomes simple.
3. Software is easy to test.
4. The software is easy to modify.
5. Software is easy to maintain.
6. Software is easy to expand.

These pieces cannot be entirely independent of each other as they together form the system. They have to
cooperate and communicate to solve the problem. This communication adds complexity.

Note: As the number of partition increases = Cost of partition and complexity increases

Abstraction (Hide Irrelevant data):

An abstraction is a tool that enables a designer to consider a component at an abstract level without bothering
about the internal details of the implementation. Abstraction can be used for existing element as well as the
component being designed.

Abstraction simply means to hide the details to reduce complexity and increase efficiency or quality. Different
levels of Abstraction are necessary and must be applied at each stage of the design process so that any error that
is present can be removed to increase the efficiency of the software solution and to refine the software solution.
The solution should be described in broad ways that cover a wide range of different things at a higher level of
abstraction and a more detailed description of a solution of software should be given at the lower level of
abstraction.

Here, there are two common abstraction mechanisms.

1. Functional Abstraction
2. Data Abstraction

Functional Abstraction
i. A module is specified by the method it performs.
ii. The details of the algorithm to accomplish the functions are not visible to the user of the function.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 3

Functional abstraction forms the basis for Function oriented design approaches.

Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction forms the basis for Object
Oriented design approaches.

Modularity (subdivide the system):

Modularity specifies to the division of software into separate modules which are differently named and addressed
and are integrated later in to obtain the completely functional software. It is the only property that allows a
program to be intellectually manageable. Single large programs are difficult to understand and read due to many
reference variables, control paths, global variables, etc.

Modularity simply means dividing the system or project into smaller parts to reduce the complexity of the system
or project. In the same way, modularity in design means subdividing a system into smaller parts so that these
parts can be created independently and then use these parts in different systems to perform different functions. It
is necessary to divide the software into components known as modules because nowadays, there are different
software available like Monolithic software that is hard to grasp for software engineers. So, modularity in design
has now become a trend and is also important. If the system contains fewer components, then it would mean the
system is complex which requires a lot of effort (cost) but if we can divide the system into components then the
cost would be small.

The desirable properties of a modular system are:

o Each module is a well-defined system that can be used with other applications.
o Each module has single specified objectives.
o Modules can be separately compiled and saved in the library.
o Modules should be easier to use than to build.
o Modules are simpler from outside than inside.

Advantages of Modularity

There are several advantages of Modularity

o It allows large programs to be written by several or different people

o It encourages the creation of commonly used routines to be placed in the library and used by other programs.
o It simplifies the overlay procedure of loading a large program into main storage.
o It provides more checkpoints to measure progress.
o It provides a framework for complete testing, more accessible to test
o It produced the well designed and more readable program.

Disadvantages of Modularity
Virendra Kumar Tiwari |
 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 4

There are several disadvantages of Modularity.

o Execution time maybe, but not certainly, longer

o Storage size perhaps, but is not certain, increased.
o Compilation and loading time may be longer.
o Inter-module communication problems may be increased.
o More linkage required, run-time may be longer, more source lines must be written, and more documentation has
to be done.

Modular Design

Modular design reduces the design complexity and results in easier and faster implementation by allowing parallel
development of various parts of a system. We discuss a different section of modular design in detail in this section:

1. Functional Independence: Functional independence is achieved by developing functions that perform only
one kind of task and do not excessively interact with other modules. Independence is important because it makes
implementation more accessible and faster. The independent modules are easier to maintain, test, and reduce error
propagation and can be reused in other programs as well. Thus, functional independence is a good design feature
which ensures software quality.

It is measured using two criteria:

o Cohesion: It measures the relative function strength of a module.

o Coupling: It measures the relative interdependence among modules.

2. Information hiding: The fundamental of Information hiding suggests that modules can be characterized by
the design decisions that protect from the others, i.e., In other words, modules should be specified that data include
within a module is inaccessible to other modules that do not need for such information.

The use of information hiding as design criteria for modular system provides the most significant benefits when
modifications are required during testing's and later during software maintenance. This is because as most data
and procedures are hidden from other parts of the software, inadvertent errors introduced during modifications
are less likely to propagate to different locations within the software.

Strategy of Design
A good system design strategy is to organize the program modules in such a method that are easy to develop and
latter too, change. Structured design methods help developers to deal with the size and complexity of programs.
Analysts generate instructions for the developers about how code should be composed and how pieces of code
should fit together to form a program.

To design a system, there are two possible approaches:

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 5

1. Top-down Approach.
2. Bottom-up Approach.

1. Top-down Approach: This approach starts with the identification of the main components and then
decomposing them into their more detailed sub-components.

2. Bottom-up Approach: A bottom-up approach begins with the lower details and moves towards up the hierarchy, as
shown in fig. This approach is suitable in the case of an existing system.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 6

COHESION & COUPLING

Cohesion:
Cohesion is the indication of the relationship within module. It is a concept of intra-module. Cohesion has many types, but
usually high cohesion is good for software.

Coupling:
Coupling is also the indication of the relationships between modules. It is the concept of Inter-module. Coupling has also
many types, but usually low coupling is good for software.

Module Coupling
In software engineering, the coupling is the degree of interdependence between software modules. Two modules
that are tightly coupled are strongly dependent on each other. However, two modules that are loosely coupled are
not dependent on each other. Uncoupled modules have no interdependence at all within them.

The various types of coupling techniques are shown in fig:

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 7

A good design is the one that has low coupling. Coupling is measured by the number of relations between
the modules. That is, the coupling increases as the number of calls between modules increase or the amount of
shared data is large. Thus, it can be said that a design with high coupling will have more errors.

Types of Module Coupling

1. No Direct Coupling: There is no direct coupling between M1 and M2.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 8

In this case, modules are subordinates to different modules. Therefore, no direct coupling.

2. Data Coupling: When data of one module is passed to another module, this is called data coupling.

3. Stamp Coupling: Two modules are stamp coupled if they communicate using composite data items such as structure,
objects, etc. When the module passes non-global data structure or entire structure to another module, they are said to be
stamp coupled. For example, passing structure variable in C or object in C++ language to a module.

4. Control Coupling: Control Coupling exists between two modules if data from one module is used to direct the structure
of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an externally imposed data format,
communication protocols, or device interface. This is related to communication to external tools and devices.

6. Common Coupling: Two modules are commonly coupled if they share information through some global data items.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 9

7. Content Coupling: Content Coupling exists between two modules if they share code, e.g., a branch from one module
into another module.

Module Cohesion
In computer programming, cohesion defines to the degree to which the elements of a module belong together.
Thus, cohesion measures the strength of relationships between pieces of functionality within a given module. For
example, in highly cohesive systems, functionality is strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high cohesion" or "low cohesion."

Types of Modules Cohesion

1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a module cooperate to
achieve a single function.
2. Sequential Cohesion: A module is said to possess sequential cohesion if the element of a module forms the
components of the sequence, where the output from one component of the sequence is input to the next.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 10

3. Communicational Cohesion: A module is said to have communicational cohesion, if all tasks of the module refer
to or update the same data structure, e.g., the set of functions defined on an array or a stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of the module is all parts
of a procedure in which sequence of steps has to be carried out for achieving a goal, e.g., the algorithm for decoding
a message.
5. Temporal Cohesion: When a module includes functions that are associated by the fact that all the methods must
be executed in the same time, the module is said to exhibit temporal cohesion.
6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the module perform a similar
operation. For example, Error handling, data input and data output, etc.
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a set of tasks that are
associated with each other very loosely, if at all.

Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also called Inter-Module Cohesion is also called Intra-Module Binding.

Binding.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 11

Coupling shows the relationships Cohesion shows the relationship within the module.
between modules.

Coupling shows the relative Cohesion shows the module's relative functional strength.
independence between the modules.

While creating, you should aim for While creating you should aim for high cohesion, i.e., a
low coupling, i.e., dependency cohesive component/ module focuses on a single function
among modules should be less. (i.e., single-mindedness) with little interaction with other
modules of the system.

In coupling, modules are linked to In cohesion, the module focuses on a single thing.
the other modules.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 12

Various Design Concepts and notations

Once the requirements document for the software to be developed is available, the software design phase begins.
While the requirement specification activity deals entirely with the problem domain, design is the first phase of
transforming the problem into a solution. In the design phase, the customer and business requirements and
technical considerations all come together to formulate a product or a system.
The design process comprises a set of principles, concepts and practices, which allow a software engineer to
model the system or product that is to be built. This model, known as design model, is assessed for quality and
reviewed before a code is generated and tests are conducted. The design model provides details about software
data structures, architecture, interfaces and components which are required to implement the system. This
chapter discusses the design elements that are required to develop a software design model. It also discusses the
design patterns and various software design notations used to represent a software design.
Basic of Software Design
Software design is a phase in software engineering, in which a blueprint is developed to serve as a base for
constructing the software system. IEEE defines software design as ‘both a process of defining, the architecture,
components, interfaces, and other characteristics of a system or component and the result of that process.’
In the design phase, many critical and strategic decisions are made to achieve the desired functionality and
quality of the system. These decisions are taken into account to successfully develop the software and carry out
its maintenance in a way that the quality of the end product is improved.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 13

Principles of Software Design

Developing design is a cumbersome process as most expansive errors are often introduced in this phase.
Moreover, if these errors get unnoticed till later phases, it becomes more difficult to correct them. Therefore, a
number of principles are followed while designing the software. These principles act as a framework for the
designers to follow a good design practice.

Some of the commonly followed design principles are as following.

▪ Software design should correspond to the analysis model: Often a design element corresponds to many
requirements, therefore, we must know how the design model satisfies all the requirements represented by
the analysis model.

▪ Choose the right programming paradigm: A programming paradigm describes the structure of the
software system. Depending on the nature and type of application, different programming paradigms such
as procedure oriented, object-oriented, and prototyping paradigms can be used. The paradigm should be
chosen keeping constraints in mind such as time, availability of resources and nature of user’s requirements.

▪ Software design should be uniform and integrated: Software design is considered uniform and integrated,
if the interfaces are properly defined among the design components. For this, rules, format, and styles are
established before the design team starts designing the software.

▪ Software design should be flexible: Software design should be flexible enough to adapt changes easily. To
achieve the flexibility, the basic design concepts such as abstraction, refinement, and modularity should be
applied effectively.

▪ Software design should ensure minimal conceptual (semantic) errors: The design team must ensure that
major conceptual errors of design such as ambiguousness and inconsistency are addressed in advance before
dealing with the syntactical errors present in the design model.

▪ Software design should be structured to degrade gently: Software should be designed to handle unusual
changes and circumstances, and if the need arises for termination, it must do so in a proper manner so that
functionality of the software is not affected.

▪ Software design should represent correspondence between the software and real-world problem: The
software design should be structured in such away that it always relates with the real-world problem.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 14

▪ Software reuse: Software engineers believe on the phrase: ‘do not reinvent the wheel’. Therefore, software
components should be designed in such a way that they can be effectively reused to increase the productivity.

▪ Designing for testability: A common practice that has been followed is to keep the testing phase separate
from the design and implementation phases. That is, first the software is developed (designed and
implemented) and then handed over to the testers who subsequently determine whether the software is fit for
distribution and subsequent use by the customer. However, it has become apparent that the process of
separating testing is seriously flawed, as if any type of design or implementation errors are found after
implementation, then the entire or a substantial part of the software requires to be redone. Thus, the test
engineers should be involved from the initial stages. For example, they should be involved with analysts to
prepare tests for determining whether the user requirements are being met.

▪ Prototyping: Prototyping should be used when the requirements are not completely defined in the
beginning. The user interacts with the developer to expand and refine the requirements as the development
proceeds. Using prototyping, a quick ‘mock-up’ of the system can be developed. This mock-up can be used
as a effective means to give the users a feel of what the system will look like and demonstrate functions that
will be included in the developed system. Prototyping also helps in reducing risks of designing software that
is not in accordance with the customer’s requirements.

Note that design principles are often constrained by the existing hardware configuration, the implementation
language, the existing file and data structures, and the existing organizational practices. Also, the evolution of
each software design should be meticulously designed for future evaluations, references and maintenance.

Software Design Concepts

Every software process is characterized by basic concepts along with certain practices or methods. Methods
represent the manner through which the concepts are applied. As new technology replaces older technology,
many changes occur in the methods that are used to apply the concepts for the development of software.
However, the fundamental concepts underlining the software design process remain the same, some of which
are described here.
Abstraction
Abstraction refers to a powerful design tool, which allows software designers to consider components at an
abstract level, while neglecting the implementation details of the components. IEEE defines abstraction as ‘a
view of a problem that extracts the essential information relevant to a particular purpose and ignores the
remainder of the information.’ The concept of abstraction can be used in two ways: as a process and as an entity.
As a process, it refers to a mechanism of hiding irrelevant details and representing only the essential features of
an item so that one can focus on important things at a time. As an entity, it refers to a model or view of an item.
Each step in the software process is accomplished through various levels of abstraction. At the highest level, an
outline of the solution to the problem is presented whereas at the lower levels, the solution to the problem is
presented in detail. For example, in the requirements analysis phase, a solution to the problem is presented using
the language of problem environment and as we proceed through the software process, the abstraction level
reduces and at the lowest level, source code of the software is produced.
There are three commonly used abstraction mechanisms in software design, namely, functional abstraction, data
abstraction and control abstraction. All these mechanisms allow us to control the complexity of the design
process by proceeding from the abstract design model to concrete design model in a systematic manner.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 15

▪ Functional abstraction: This involves the use of parameterized subprograms. Functional abstraction can be
generalized as collections of subprograms referred to as ‘groups’. Within these groups there exist routines
which may be visible or hidden. Visible routines can be used within the containing groups as well as within
other groups, whereas hidden routines are hidden from other groups and can be used within the containing
group only.

▪ Data abstraction: This involves specifying data that describes a data object. For example, the data
object window encompasses a set of attributes (window type, window dimension) that describe the window
object clearly. In this abstraction mechanism, representation and manipulation details are ignored.

▪ Control abstraction: This states the desired effect, without stating the exact mechanism of control. For
example, if and while statements in programming languages (like C and C++) are abstractions of machine
code implementations, which involve conditional instructions. In the architectural design level, this
abstraction mechanism permits specifications of sequential subprogram and exception handlers without the
concern for exact details of implementation.

Architecture
Software architecture refers to the structure of the system, which is composed of various components of a
program/ system, the attributes (properties) of those components and the relationship amongst them. The
software architecture enables the software engineers to analyze the software design efficiently. In addition, it
also helps them in decision-making and handling risks. The software architecture does the following.

• Provides an insight to all the interested stakeholders that enable them to communicate with each other
• Highlights early design decisions, which have great impact on the software engineering activities (like coding
and testing) that follow the design phase
• Creates intellectual models of how the system is organized into components and how these components
interact with each other.

Currently, software architecture is represented in an informal and unplanned manner. Though the architectural
concepts are often represented in the infrastructure (for supporting particular architectural styles) and the initial
stages of a system configuration, the lack of an explicit independent characterization of architecture restricts the
advantages of this design concept in the present scenario.
Note that software architecture comprises two elements of design model, namely, data design and architectural
design.
Patterns
A pattern provides a description of the solution to a recurring design problem of some specific domain in such
a way that the solution can be used again and again. The objective of each pattern is to provide an insight to a
designer who can determine the following.

▪ Whether the pattern can be reused

▪ Whether the pattern is applicable to the current project
▪ Whether the pattern can be used to develop a similar but functionally or structurally different design pattern.

Types of Design Patterns

Software engineer can use the design pattern during the entire software design process. When the analysis model
is developed, the designer can examine the problem description at different levels of abstraction to determine
whether it complies with one or more of the following types of design patterns.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 16

▪ Architectural patterns: These patterns are high-level strategies that refer to the overall structure and
organization of a software system. That is, they define the elements of a software system such as subsystems,
components, classes, etc. In addition, they also indicate the relationship between the elements along with the
rules and guidelines for specifying these relationships. Note that architectural patterns are often considered
equivalent to software architecture.

▪ Design patterns: These patterns are medium-level strategies that are used to solve design problems. They
provide a means for the refinement of the elements (as defined by architectural pattern) of a software system
or the relationship among them. Specific design elements such as relationship among components or
mechanisms that affect component-to-component interaction are addressed by design patterns. Note that
design patterns are often considered equivalent to software components.

▪ Idioms: These patterns are low-level patterns, which are programming-language specific. They describe the
implementation of a software component, the method used for interaction among software components, etc.,
in a specific programming language. Note that idioms are often termed as coding patterns.

Modularity
Modularity is achieved by dividing the software into uniquely named and addressable components, which are
also known as modules. A complex system (large program) is partitioned into a set of discrete modules in such
a way that each module can be developed independent of other modules. After developing the modules, they are
integrated together to meet the software requirements. Note that larger the number of modules a system is divided
into, greater will be the effort required to integrate the modules.

Modularizing a design helps to plan the development in a more effective manner, accommodate changes easily,
conduct testing and debugging effectively and efficiently, and conduct maintenance work without adversely
affecting the functioning of the software.
Information Hiding
Modules should be specified and designed in such a way that the data structures and processing details of one
module are not accessible to other modules. They pass only that much information to each other, which is
required to accomplish the software functions. The way of hiding unnecessary details is referred to
as information hiding. IEEE defines information hiding as ‘the technique of encapsulating software design
decisions in modules in such a way that the module’s interfaces reveal as little as possible about the module’s
inner workings; thus each module is a ‘black box’ to the other modules in the system.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 17

Information hiding is of immense use when modifications are required during the testing and maintenance phase.
Some of the advantages associated with information hiding are listed below.

▪ Leads to low coupling

▪ Emphasizes communication through controlled interfaces
▪ Decreases the probability of adverse effects
▪ Restricts the effects of changes in one component on others
▪ Results in higher quality software.

Stepwise Refinement
Stepwise refinement is a top-down design strategy used for decomposing a system from a high level of
abstraction into a more detailed level (lower level) of abstraction. At the highest level of abstraction, function or
information is defined conceptually without providing any information about the internal workings of the
function or internal structure of the data. As we proceed towards the lower levels of abstraction, more and more
details are available.
Software designers start the stepwise refinement process by creating a sequence of compositions for the system
being designed. Each composition is more detailed than the previous one and contains more components and
interactions. The earlier compositions represent the significant interactions within the system, while the later
compositions show in detail how these interactions are achieved.
To have a clear understanding of the concept, let us consider an example of stepwise refinement.
Every computer program comprises input, process, and output.

▪ INPUT

• Get user’s name (string) through a prompt.

• Get user’s grade (integer from 0 to 100) through a prompt and validate.

▪ PROCESS

▪ OUTPUT

This is the first step in refinement. The input phase can be refined further as given here.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 18

▪ INPUT
• Get user’s name through a prompt.
• Get user’s grade through a prompt.
• While (invalid grade)

Ask again:

▪ PROCESS

▪ OUTPUT

Note: Stepwise refinement can also be performed for PROCESS and OUTPUT phase.
Refactoring
Refactoring is an important design activity that reduces the complexity of module design keeping its behaviour
or function unchanged. Refactoring can be defined as a process of modifying a software system to improve the
internal structure of design without changing its external behavior. During the refactoring process, the existing
design is checked for any type of flaws like redundancy, poorly constructed algorithms and data structures, etc.,
in order to improve the design. For example, a design model might yield a component which exhibits low
cohesion (like a component performs four functions that have a limited relationship with one another). Software
designers may decide to refactor the component into four different components, each exhibiting high cohesion.
This leads to easier integration, testing, and maintenance of the software components.
Structural Partitioning
When the architectural style of a design follows a hierarchical nature, the structure of the program can be
partitioned either horizontally or vertically. In horizontal partitioning, the control modules are used to
communicate between functions and execute the functions. Structural partitioning provides the following
benefits.

• The testing and maintenance of software becomes easier.

• The negative impacts spread slowly.
• The software can be extended easily.

Besides these advantages, horizontal partitioning has some disadvantage also. It requires to pass more data across
the module interface, which makes the control flow of the problem more complex. This usually happens in cases
where data moves rapidly from one function to another.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 19

In vertical partitioning, the functionality is distributed among the modules–in a top-down manner. The modules
at the top level called control modules perform the decision-making and do little processing whereas the
modules at the low level called worker modules perform all input, computation and output tasks.
Concurrency
Computer has limited resources and they must be utilized efficiently as much as possible. To utilize these
resources efficiently, multiple tasks must be executed concurrently. This requirement makes concurrency one of
the major concepts of software design. Every system must be designed to allow multiple processes to execute
concurrently, whenever possible. For example, if the current process is waiting for some event to occur, the
system must execute some other process in the mean time.
However, concurrent execution of multiple processes sometimes may result in undesirable situations such as an
inconsistent state, deadlock, etc. For example, consider two processes A and B and a data item Q1 with the value
‘200’. Further, suppose A and B are being executed concurrently and firstly A reads the value of Q1 (which is
‘200’) to add ‘100’ to it. However, before A updates es the value of Q1, B reads the value ofQ1 (which is still
‘200’) to add ’50’ to it. In this situation, whether A or B first updates the value of Q1, the value of would
definitely be wrong resulting in an inconsistent state of the system. This is because the actions of A and B are
not synchronized with each other. Thus, the system must control the concurrent execution and synchronize the
actions of concurrent processes.
One way to achieve synchronization is mutual exclusion, which ensures that two concurrent processes do not
interfere with the actions of each other. To ensure this, mutual exclusion may use locking technique. In this
technique, the processes need to lock the data item to be read or updated. The data item locked by some process
cannot be accessed by other processes until it is unlocked. It implies that the process, that needs to access the
data item locked by some other process, has to wait.

Development of Detailed Design

To develop a complete specification of design (design model), four design models are needed. These models are
listed below.

▪ Data design: This specifies the data structures for implementing the software by converting data objects and
their relationships identified during the analysis phase. Various studies suggest that design engineering
should begin with data design, since this design lays the foundation for all other design models.

▪ Architectural design: This specifies the relationship between the structural elements of the software, design
patterns, architectural styles, and the factors affecting the ways in which architecture can be implemented.

▪ Component-level design: This provides the detailed description of how structural elements of software will
actually be implemented.

▪ Interface design: This depicts how the software communicates with the system that interoperates with it
and with the end-users.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 20

Creation of Software Design Document (SDD)

The design phase of software development deals with transforming the customer requirements as described in
the SRS documents into a form implementable using a programming language. The software design process
can be divided into the following three levels of phases design:
• Interface Design
• Architectural Design
• Detailed Design

Software Design Document:

Software Design Document is a written document that provides a description of a software product in terms of
architecture of software with various components with specified functionality.
The design specification addresses different aspects of the design model and is completed as the designer refines
his representation of the software. These design documents are written by software engineers/designers or
project managers and further passed to the software development team to give them an overview of what needs
to be built and how.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 21

S.No Software Design Document Module, Subpart

1. Existing software documentation

2. System Documentation
Reference Documents
3. Vendor (hardware or software) documents
01. 4. Technical reference

1. Processing narrative
2. Interface description
Modules for each module
3. Design language (or other) description
02. 4. Modules used

1. System objective
2. Hardware, software and human interfaces
Scope 3. Major software functions
4. Externally defined database
03. 5. Major design constraints, limitations

1. Data description
Design Description 2. Derived program structure
04. 3. Interface within structure

1. Test guidelines
Test Provisions 2. Integration strategy
05. 3. Special considerations

1. Special program overlay provisions

Packaging
06. 2. Transfer consideration

1. External Files structure

File Structure and global data 2. Global data
07. 3. File and data cross – reference

08. Requirement cross-reference 1. cross-reference

Importance of Design Documentation:

1. Requirements are well understood: With proper documentation, we can remove inconsistencies and
conflicts about the requirements. Requirements are well understood by every team member.
2. Architecture/Design of product: Architecture/Design documents give us a complete overview of how the
product look like and better insight to the customer/user about their product.
3. New Person can also work on the project: New person to the project can very easily understand the project
through documentations and start working on it. So, developers need to maintain the documentation and keep
upgrading it according to the changes made in the product/software.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 22

4. Everything is well Stated: This documentation is helpful to understand each and every working of the
product. It explains each and every feature of the product/software.
5. Proper Communication: Through documentation, we have good communication with every member who
is part of the project/software. Helpful in understanding role and contribution of each and every member.

Dataflow Oriented design

Data flow-oriented design is used in structured design and it represents the flows of data between different
processes

It is the first comprehensive and comprehensive document design method. Data flow design understands the
function of the system by considering the system flow. Data structured design uses data structures of input data,
internal data, and output data to develop software. This design emphasizes the definition of breaking down
functionality into modules. Data structuring introduces coupling and cohesion to assess design quality.

Data Structured Design : this introduces the coupling and cohesion criteria for evaluating the quality of a
design. So this approach emphasized functional decomposition into modules and the definition of module
interfaces.

Data Flow Diagram

Data flow diagram is graphical representation of flow of data in an information system. It is capable of
depicting incoming data flow, outgoing data flow and stored data. The DFD does not mention anything about
how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of control in
program modules. DFDs depict flow of data in the system at various levels. DFD does not contain any control
or branch elements.

Types of DFD
Data Flow Diagrams are either Logical or Physical.
Logical DFD - This type of DFD concentrates on the system process, and flow of data in the system.For
example in a Banking software system, how data is moved between different entities.
Physical DFD - This type of DFD shows how the data flow is actually implemented in the system. It is more
specific and close to the implementation.

DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of components

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 23

Entities - Entities are source and destination of information data. Entities are represented by a rectangles
with their respective names.
Process - Activities and action taken on the data are represented by Circle or Round-edged rectangles.
Data Storage - There are two variants of data storage - it can either be represented as a rectangle with absence
of both smaller sides or as an open- sided rectangle with only one side missing.
Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from the base of arrow
as its source towards head of the arrow as destination.

Levels of DFD
Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire information system
as one diagram concealing all the underlying details. Level 0 DFDs are also known as context level DFDs.

Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1 DFD depicts basic
modules in the system and flow of data among various modules. Level 1 DFD also mentions basic processes
and sources of information.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 24

Level 2 - At this level, DFD shows how data flows inside the modules mentioned in Level 1.
Higher level DFDs can be transformed into more specific lower level DFDs with deeper level of understanding
unless the desired level of specification is achieved.
Structure Charts
Structure chart is a chart derived from Data Flow Diagram. It represents the system in more detail than DFD.
It breaks down the entire system into lowest functional modules, describes functions and sub-functions of each
module of the system to a greater detail than DFD.
Structure chart represents hierarchical structure of modules. At each layer a specific task is performed.
Here are the symbols used in construction of structure charts -
Module - It represents process or subroutine or task. A control module branches to more than one sub-module.
Library Modules are re-usable and invokable from any module

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 25

Condition - It is represented by small diamond at the base of module. It depicts that control module can select
any of sub-routine based on some condition.

Jump - An arrow is shown pointing inside the module to depict that the control will jump in the middle of the
sub-module.

Loop - A curved arrow represents loop in the module. All sub-modules covered by loop repeat execution of
module.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 26

Data flow - A directed arrow with empty circle at the end represents data flow.

Control flow - A directed arrow with filled circle at the end represents control

flow
software design is a process to transform user requirements into some suitable form, which helps the
programmer in software coding and implementation.
For assessing user requirements, an SRS (Software Requirement Specification) document is created whereas
for coding and implementation, there is a need of more specific and detailed requirements in software terms.
The output of this process can directly be used into implementation in programming languages.
Software design is the first step in SDLC (Software Design Life Cycle), which moves the concentration from
problem domain to solution domain. It tries to specify how to fulfill the requirements mentioned in SRS.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 27

Data Flow Oriented Design I

Step 1: Review system model developed during requirements analysis Step 2: Review
and refine the data flow diagram
Step 3: Determine whether DFD has transform and/or transaction characteristics
(for transform DFD)

Step 4: Represent incoming, transform and outgoing information flow boundaries Step 5: Perform
first-level factoring
Step 6: Perform second-level factoring
Step 7: Perform third-level factoring and higher level factoring

Designing for reuse

Design reuse is the process of building new software applications and tools by reusing previously developed
designs. New features and functionalities may be added by incorporating minor changes.

In most engineering disciplines, systems are designed by composing existing components that have been used in
other systems. Software engineering has been more focused on original development but it is now recognized
that to achieve better software, more quickly and at lower cost, we need a design process that is based on
systematic software reuse. ² There has been a major switch to reuse-based development over the past 10 years.

Reuse-based software engineering

➢ Application system reuse

• § The whole of an application system may be reused either by incorporating it without change into other
systems (COTS reuse) or by developing application families.
➢ Component reuse
• § Components of an application from sub-systems to single objects may be reused.
➢ Object and function reuse
• § Software components that implement a single well-defined object or function may be reused.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 28

Benefits of software reuse

Benefit Explanation
Increased dependability Reused software, which has been tried and tested in working systems, should be more
dependable than new software. Its design and implementation faults should have been
found and fixed
Reduced process risk The cost of existing software is already known, whereas the costs of development are
always a matter of judgment. This is an important factor for project management
because it reduces the margin of error in project cost estimation. This is particularly
true when relatively large software components such as subsystems are reused
Effective use of specialists Instead of doing the same work over and over again, application specialists can develop
reusable software that encapsulates their knowledge
Standards compliance Some standards, such as user interface standards, can be implemented as a set of
reusable components. For example, if menus in a user interface are implemented using
reusable components, all applications present the same menu formats to users. The use
of standard user interfaces improves dependability because users make fewer mistakes
when presented with a familiar interface.
Accelerated development Bringing a system to market as early as possible is often more important than overall
development costs. Reusing software can speed up system production because both
development and validation time may be reduced

Problems with reuse

Problem Explanation
Increased maintenance If the source code of a reused software system or component is not available then
costs maintenance costs may be higher because the reused elements of the system may
become increasingly incompatible with system changes
Lack of tool support Some software tools do not support development with reuse. It may be difficult or
impossible to integrate these tools with a component library system. The software
process assumed by these tools may not take reuse into account. This is particularly
true for tools that support embedded systems engineering, less so for object-oriented
development tools
Not-invented-here Some software engineers prefer to rewrite components because they believe they can
syndrome improve on them. This is partly to do with trust and partly to do with the fact that
writing original software is seen as more challenging than reusing other people’s
software
Creating, maintaining, and Populating a reusable component library and ensuring the software developers can use
using a component library this library can be expensive. Development processes have to be adapted to ensure that
the library is used
Finding, understanding, Software components have to be discovered in a library, understood and, sometimes,
and adapting reusable adapted to work in a new environment. Engineers must be reasonably confident of
components finding a component in the library before they include a component search as part of
their normal development process

The reuse landscapes

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 29

✓ Although reuse is often simply thought of as the reuse of system components, there are many different approaches
to reuse that may be used.
✓ Reuse is possible at a range of levels from simple functions to complete application systems.
✓ The reuse landscape covers the range of possible reuse techniques.

Approaches that support software reuse

Approach Description
Architectural patterns Standard software architectures that support common types of application systems are
used as the basis of applications.
Design patterns Generic abstractions that occur across applications are represented as design patterns
showing abstract and concrete objects and interactions.
Component-based Systems are developed by integrating components (collections of objects) that conform
development to component-model standards.
Application frameworks Collections of abstract and concrete classes are adapted and extended to create
application systems
Legacy system wrapping Legacy systems are ‘wrapped’ by defining a set of interfaces and providing access to
these legacy systems through these interfaces
Service-oriented systems Systems are developed by linking shared services, which may be externally provided.
Software product lines An application type is generalized around a common architecture so that it can be
adapted for different customers.
COTS product reuse Systems are developed by configuring and integrating existing application systems.
ERP systems Large-scale systems that encapsulate generic business functionality and rules are
configured for an organization.
Configurable vertical generic systems are designed so that they can be configured to the needs of specific
applications system customers.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 30

Program libraries Class and function libraries that implement commonly used abstractions are available
for reuse
Model-driven engineering Software is represented as domain models and implementation independent models and
code is generated from these models.
Program generators A generator system embeds knowledge of a type of application and is used to generate
systems in that domain from a user-supplied system model
Aspect-oriented software Shared components are woven into an application at different places when the program
development is compiled.

Reuse planning factors

❖ The development schedule for the software.

❖ The expected software lifetime.
❖ The background, skills and experience of the development team.
❖ The criticality of the software and its non-functional requirements.
❖ The application domain.
❖ The execution platform for the software

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 31

Programming standards.

The Programming is the process of transforming the design of a system into a computer language format. This
Programming phase of software development is concerned with software translating design specification into the
source code. It is necessary to write source code & internal documentation so that conformance of the code to its
specification can be easily verified.

Coding is done by the coder or programmers who are independent people than the designer. The goal is not to
reduce the effort and cost of the Programming phase, but to cut to the cost of a later stage. The cost of testing and
maintenance can be significantly reduced with efficient coding.

➢ Goals of Coding
1. Translate the design of system into a computer language format: The Programming is the process of
transforming the design of a system into a computer language format, which can be executed by a
computer and that perform tasks as specified by the design of operation during the design phase.
2. Reduce the cost of later phases: The cost of testing and maintenance can be significantly reduced with
efficient coding.
3. Making the program more readable: Program should be easy to read and understand. It increases code
understanding having readability and understandability as a clear objective of the Programming activity
can itself help in producing more maintainable software.
For implementing our design into code, we require a high-level functional language. A programming language
should have the following characteristics:

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 32

✓ Readability: A good high-level language will allow programs to be written in some methods that resemble a quite-
English description of the underlying functions. The Programming may be done in an self-documenting way.

✓ Portability: High-level languages, being virtually machine-independent, should be easy to develop portable
software.

✓ Generality: Most high-level languages allow the writing of a vast collection of programs, thus relieving the
programmer of the need to develop into an expert in many diverse languages.

✓ Brevity: Language should have the ability to implement the algorithm with less amount of code. Programs mean
in high-level languages are often significantly shorter than their low-level equivalents.

✓ Error checking: A programmer is likely to make many errors in the development of a computer program. Many
high-level languages invoke a lot of bugs checking both at compile-time and run-time.

✓ Cost: The ultimate cost of a programming language is a task of many of its characteristics.

✓ Quick translation: It should permit quick translation.

✓ Efficiency: It should authorize the creation of an efficient object code.

✓ Modularity: It is desirable that programs can be developed in the language as several separately compiled
modules, with the appropriate structure for ensuring self-consistency among these modules.

✓ Widely available: Language should be widely available, and it should be feasible to provide translators for all the
major machines and all the primary operating systems.

✓ A Programming standard lists several rules to be followed during coding, such as the way variables are to be named,
the way the code is to be laid out, error return conventions, etc.

➢ Programming Standards
General Programming standards refers to how the developer writes code, so here we will discuss some essential standards
regardless of the programming language being used.
The following are some representative Programming standards:

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 33

1. Indentation: Proper and consistent indentation is essential in producing easy to read and maintainable programs.
Indentation should be used to:

o Emphasize the body of a control structure such as a loop or a select statement.

o Emphasize the body of a conditional statement

o Emphasize a new scope block

2. Inline comments: Inline comments analyse the functioning of the subroutine, or key aspects of the algorithm
shall be frequently used.

3. Rules for limiting the use of global: These rules file what types of data can be declared global and what cannot.

4. Structured Programming: Structured (or Modular) Programming methods shall be used. "GOTO" statements
shall not be used as they lead to "spaghetti" code, which is hard to read and maintain, except as outlined line in
the FORTRAN Standards and Guidelines.

5. Naming conventions for global variables, local variables, and constant identifiers: A possible naming
convention can be that global variable names always begin with a capital letter, local variable names are made of
small letters, and constant names are always capital letters.

6. Error return conventions and exception handling system: Different functions in a program report the way
error conditions are handled should be standard within an organization. For example, different tasks while
encountering an error condition should either return a 0 or 1 consistently.

➢ Programming Guidelines
General Programming guidelines provide the programmer with a set of the best methods which can be used to make
programs more comfortable to read and maintain. Most of the examples use the C language syntax, but the guidelines can

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 34

be tested to all languages.

1. Line Length: It is considered a good practice to keep the length of source code lines at or below 80 characters. Lines
longer than this may not be visible properly on some terminals and tools. Some printers will truncate lines longer than 80
columns.

2. Spacing: The appropriate use of spaces within a line of code can improve readability.

Example:

Bad: cost=price+(price*sales_tax)
fprintf(stdout ,"The total cost is %5.2f\n",cost);

Better: cost = price + ( price * sales_tax )

fprintf (stdout,"The total cost is %5.2f\n",cost);

3. The code should be well-documented: As a rule of thumb, there must be at least one comment line on the average for
every three-source line.

4. The length of any function should not exceed 10 source lines: A very lengthy function is generally very difficult to
understand as it possibly carries out many various functions. For the same reason, lengthy functions are possible to have a
disproportionately larger number of bugs.

5. Do not use goto statements: Use of goto statements makes a program unstructured and very tough to understand.

6. Inline Comments: Inline comments promote readability.

7. Error Messages: Error handling is an essential aspect of computer programming. This does not only include adding
the necessary logic to test for and handle errors but also involves making error messages meaningful.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 35

Test your skills (Questions):

True and false

1. True or False: Cohesion in software design refers to the degree of interdependence between modules.
Answer: False
2. True or False: In software design, coupling refers to the extent of connectivity between software
components.
Answer: True
3. True or False: A design notation is a formal language used exclusively by software designers.
Answer: False
4. True or False: Design principles play a minimal role in guiding decision-making during the software
design phase.
Answer: False
5. True or False: A structure design methodology helps organize and represent the software's architectural
components.
Answer: True
6. True or False: Risk analysis is relevant both in software project planning and software design to identify
potential issues.
Answer: True
7. True or False: Empirical estimation models are equally applicable to both project planning and software
design for estimating effort.
Answer: True
8. True or False: Decomposition techniques are used not only in project planning but also in breaking down
design elements.
Answer: True
9. True or False: The Make/Buy Decision influences project planning by determining whether to build or
purchase software components.
Answer: True
10. True or False: Cohesion and coupling principles apply both to project planning and software design to
ensure effective system development.
Answer: True
11. True or False: Project timelines in software project planning primarily focus on task scheduling and
resource allocation.
Answer: True
12. True or False: Empirical estimation models provide exact predictions of project effort without any margin
of error.
Answer: False
13. True or False: Decomposition techniques are only relevant for large-scale software projects and not for
smaller ones.
Answer: False

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 36

14. True or False: Risk analysis is a one-time activity conducted at the beginning of the software project
planning process.
Answer: False
15. True or False: A well-structured project plan helps in minimizing project risks and uncertainties.
Answer: True
16. True or False: High cohesion in software design implies strong interdependence between different
modules.
Answer: False
17. True or False: Low coupling in software design is generally considered a disadvantage as it indicates a
lack of connectivity between components.
Answer: False
18. True or False: Design principles guide decision-making in software design by providing a set of rigid
rules.
Answer: False
19. True or False: Design notations are essential only for communication among software designers and are
not meant for other stakeholders.
Answer: False
20. True or False: A structure design methodology primarily focuses on the graphical representation of the
software's user interface.
Answer: False
21. True or False: The Make/Buy Decision is solely concerned with resource allocation and has little impact
on project timelines.
Answer: False
22. True or False: Cohesion and coupling principles are considerations in both project planning and software
design for ensuring robust system development.
Answer: True
23. True or False: Risk analysis continues to play a role in software design to identify and address potential
challenges as the project progresses.
Answer: True
24. True or False: Decomposition techniques are equally applicable to breaking down project tasks and design
elements regardless of project size.
Answer: True
25. True or False: Design principles guide decision-making during both project planning and software design
phases.
26. Answer: True

Fill in the blank

1. The primary goal of software project planning is to accurately estimate project effort and allocate
_______________.
Answer: Resources
2. _______________ techniques involve breaking down a project into smaller, manageable tasks to facilitate
better planning and execution.

Virendra Kumar Tiwari |

 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 37

Answer: Decomposition
3. In the Make/Buy Decision, the team decides whether to build a software component in-house or
_______________ it.
Answer: Purchase
4. A comprehensive software project plan outlines tasks, timelines, and _______________ allocation to
ensure project success.
Answer: Resource
5. Risk analysis in software project planning involves identifying and mitigating potential _______________
that may impact project outcomes.
Answer: Risks
6. _______________ refers to the degree of interdependence between modules in software design.
Answer: Cohesion
7. _______________ in software design refers to the extent of connectivity between software components.
Answer: Coupling
8. Design principles guide decision-making during software design by providing a set of guiding
_______________.
Answer: Principles
9. Design notations are used to visually represent and communicate design ideas in a _______________
format.
Answer: Formal
10. A structure design methodology focuses on organizing and representing the architectural
_______________ of a software system.
Answer: Components
11. Empirical estimation models are used to provide a data-driven _______________ of project effort.
Answer: Prediction
12. Decomposition techniques break down a project into smaller tasks, often organized in a
_______________ hierarchy.
Answer: Hierarchical
13. The Make/Buy Decision is crucial in determining whether to develop a software component in-house or
_______________ it.
Answer: Outsource
14. Risk analysis in software project planning involves assessing and managing potential _______________
that may affect project success.
Answer: Risks
15. Project timelines serve as a critical _______________ for scheduling tasks and meeting project
milestones.
Answer: Framework
16. _______________ in software design refers to the strength of interdependence among elements within a
module.
Answer: Coupling
17. Low _______________ in software design indicates loose connections between software components.
Answer: Coupling
18. Design principles provide guidelines to ensure the _______________ and effectiveness of the software
system.
Virendra Kumar Tiwari |
 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 38

Answer: Quality
19. Design notations, such as UML, offer a standardized way to visually represent and communicate
_______________ ideas.
Answer: Design
20. A structure design methodology helps organize software components into a coherent and logical
_______________.
Answer: Structure
21. The success of a software project plan often relies on accurate _______________ of project effort and
resource requirements.
Answer: Estimation
22. In software design, a high level of cohesion contributes to better _______________ and ease of
maintenance.
Answer: Modularity
23. _______________ techniques, whether applied to project planning or design, enhance the manageability
of complex tasks.
Answer: Decomposition
24. Effective risk analysis in both project planning and design involves identifying and addressing potential
_______________.
Answer: Challenges
25. The Make/Buy Decision influences both project planning and design by determining the most
_______________ way to obtain required components.
Answer: Cost-effective

Question bank:
1) What is abstraction in software design, and why is it important?
2) How do you implement abstraction in your software design process?
3) Can you provide examples of abstraction in real-world software systems?
4) Define modularity in the context of software design.
5) What are the benefits of designing software with a modular approach?
6) How do you identify and define modules in a software system?
7) Explain the role of software architecture in the development process.
8) What are some common architectural patterns used in software design?
9) How do you choose the appropriate architecture for a given software project?
10) Define cohesion and coupling in software design.
11) Why is it important to achieve high cohesion and low coupling in software systems?
12) Can you provide strategies for improving cohesion and reducing coupling in a software design?
13) Discuss different design concepts and notations commonly used in software design.
14) How do design patterns contribute to software design and development?
15) Are there specific design methodologies or frameworks you prefer to use?
16) Development of Detailed Design & Creation of Software Design Document:
17) Describe the process of developing a detailed design for a software system.
18) What elements should be included in a comprehensive software design document?
19) How do you ensure that the design document effectively communicates the design decisions and rationale?
20) Explain the concept of dataflow-oriented design.
Virendra Kumar Tiwari |
 Department of Computer Application (MCA)
MCA-203- Software Engineering & UML {UNIT-II} 39

21) When is dataflow-oriented design appropriate, and what are its advantages?
22) Can you provide examples of tools or techniques used for dataflow-oriented design?
23) Why is designing for reuse important in software development?
24) What strategies can be employed to maximize the reusability of software components?
25) How do you balance the trade-offs between designing for reuse and other design considerations?
26) Discuss the significance of programming standards in software development.
27) What are some common programming standards and best practices followed in the industry?
28) How do you ensure adherence to programming standards within a development team?

Virendra Kumar Tiwari |