Unit-3

Software Design

• Software design is a mechanism to transform user requirements into

some suitable form, which helps the programmer in software coding
and implementation. It deals with representing the client's
requirement, as described in SRS (Software Requirement
Specification) document, into a form, i.e., easily implementable using
programming language.
Analysis and Design model
Software 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
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

[Link] is easy to understand

[Link] becomes simple
[Link] is easy to test
[Link] is easy to modify
[Link] is easy to maintain
[Link] 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.
Abstraction

• 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.
• there are two common abstraction mechanisms
[Link] Abstraction
[Link] Abstraction
Functional Abstraction

i. A module is specified by the method it performs.

[Link] details of the algorithm to accomplish the functions are not
visible to the user of the function.
• 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

• Modularity specifies to the division of software into separate modules

which are differently named and addressed and are integrated later
on 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 a
large number of reference variables, control paths, global variables,
etc.
• The desirable properties of a modular system are:
• Each module is a well-defined system that can be used with other
applications.
• Each module has single specified objectives.
• Modules can be separately compiled and saved in the library.
• Modules should be easier to use than to build.
• Modules are simpler from outside than inside.
Advantages and Disadvantages of Modularity

There are several advantages of Modularity

• It allows large programs to be written by several or different people
• It encourages the creation of commonly used routines to be placed in
the library and used by other programs.
• It simplifies the overlay procedure of loading a large program into
main storage.
• It provides more checkpoints to measure progress.
• It provides a framework for complete testing, more accessible to test
• It produced the well designed and more readable program.
Disadvantages of Modularity
• There are several disadvantages of Modularity
• Execution time maybe, but not certainly, longer
• Storage size perhaps, but is not certainly, increased
• Compilation and loading time may be longer
• Inter-module communication problems may be increased
• 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.
[Link] 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.
Functional Independence Cont…
• It is measured using two criteria:
• Cohesion: It measures the relative function strength of a module.
• 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:
[Link]-down Approach
[Link]-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
case of an existing system.
Coupling and Cohesion

• 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:
• 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.

• 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 among 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 common coupled if they
share information through some global data items.
• 7. Content Coupling: Content Coupling exists among 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."
[Link] Cohesion: Functional Cohesion is said to exist if the
different elements of a module, cooperate to achieve a single
function.
[Link] Cohesion: A module is said to possess sequential
cohesion if the element of a module form the components of the
sequence, where the output from one component of the sequence is
input to the next.
[Link] 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 are all parts of a procedure in which
particular 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 Binding. Cohesion is also called Intra-Module Binding.

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

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

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

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

• User Interface Design

• Types of User Interfaces in Software Engineering
• Designing user interface using spiral model
• Characteristics of a good user interface
User Interface Design
• The visual part of a computer application or operating system through
which a client interacts with a computer or software.
• It determines how commands are given to the computer or the
program and how data is displayed on the screen.
Types of User Interface

• There are two main types of User Interface:

• Text-Based User Interface or Command Line Interface
• Graphical User Interface (GUI)
Text-Based User Interface:
• This method relies primarily on the keyboard. A typical example of
this is UNIX.
• Advantages
• Many and easier to customizations options.
• Typically capable of more important tasks.
• Disadvantages
• Relies heavily on recall rather than recognition.
• Navigation is often more difficult.
Graphical User Interface (GUI):
• GUI relies much more heavily on the mouse. A typical example of this type
of interface is any versions of the Windows operating systems.
• Advantages
• Less expert knowledge is required to use it.
• Easier to Navigate and can look through folders quickly in a guess and
check manner.
• The user may switch quickly from one task to another and can interact with
several different applications.
• Disadvantages
• Typically decreased options.
• Usually less customizable. Not easy to use one button for tons of different
variations.
UID Characteristics

• Interactive, attractive, ease to use, & responsive.

• All interactive mechanism must be supported.
• Hide technical interaction from causal users.
• Direct intraction with object on the screen.
• Shortcut must be defined.
• Meaningful default setting .
• Consistency across a family of applications.
• Place the user in control .
Software Configuration Management
In Software Engineering, Software Configuration Management(SCM) is a process to
systematically manage, organize, and control the changes in the documents, codes, and
other entities during the Software Development Life Cycle. The primary goal is to increase
productivity with minimal mistakes.
Why do we need Configuration management?
• There are multiple people working on software which is continually updating
• It may be a case where multiple version, branches, authors are involved in a software
config project, and the team is geographically distributed and works concurrently
• Changes in user requirement, policy, budget, schedule need to be accommodated.
• Software should able to run on various machines and Operating Systems
• Helps to develop coordination among stakeholders
• SCM process is also beneficial to control the costs involved in making changes to a
system
Configuration Management

Any change in the software configuration

Items will affect the final product.
Therefore, changes to configuration
items need to be controlled and
managed.
Tasks in SCM process
• Configuration Identification
• Baselines
• Change Control
• Configuration Status Accounting
• Configuration Audits and Reviews
Configuration Identification:
• Identification of configuration Items like source code modules, test case, and
requirements specification.
• Identification of each CSCI in the SCM repository, by using an object-oriented approach
• The process starts with basic objects which are grouped into aggregate objects. Details of
what, why, when and by whom changes in the test are made
• Every object has its own features that identify its name that is explicit to all other objects
• List of resources required such as the document, the file, tools, etc.
Example:
Instead of naming a File [Link] its should be named login_v1.[Link] where v1.2 stands
for the version number of the file
Instead of naming folder "Code" it should be named "Code_D" where D represents code
should be backed up daily.
Baseline:
A baseline is a formally accepted version of a software configuration item. It is
designated and fixed at a specific time while conducting the SCM process. It can
only be changed through formal change control procedures.
Activities during this process:
• Facilitate construction of various versions of an application
• Defining and determining mechanisms for managing various versions of these
work products
• The functional baseline corresponds to the reviewed system requirements
• Widely used baselines include functional, developmental, and product
baselines
In simple words, baseline means ready for release.
Change Control:
Change control is a procedural method which ensures quality and
consistency when changes are made in the configuration object. In this
step, the change request is submitted to software configuration manager.
Activities during this process:
• Control ad-hoc change to build stable software development
environment. Changes are committed to the repository
• The request will be checked based on the technical merit, possible side
effects and overall impact on other configuration objects.
• It manages changes and making configuration items available during the
software lifecycle
Configuration Status Accounting:
Configuration status accounting tracks each release during the SCM process.
This stage involves tracking what each version has and the changes that lead to
this version.
Activities during this process:
• Keeps a record of all the changes made to the previous baseline to reach a
new baseline
• Identify all items to define the software configuration
• Monitor status of change requests
• Complete listing of all changes since the last baseline
• Allows tracking of progress to next baseline
• Allows to check previous releases/versions to be extracted for testing
Configuration Audits and Reviews:
Software Configuration audits verify that all the software product satisfies the
baseline needs. It ensures that what is built is what is delivered.
Activities during this process:
• Configuration auditing is conducted by auditors by checking that defined
processes are being followed and ensuring that the SCM goals are satisfied.
• To verify compliance with configuration control standards. auditing and
reporting the changes made
• SCM audits also ensure that traceability is maintained during the process.
• Ensures that changes made to a baseline comply with the configuration status
reports
• Validation of completeness and consistency
Participant of SCM process: [Link] Manager
Configuration Manager is the head
who is Responsible for identifying
configuration items.
CM ensures team follows the SCM
process
He/She needs to approve or reject
change requests
2. Developer
The developer needs to change the
code as per standard development
activities or change requests. He is
responsible for maintaining
configuration of code.
The developer should check the
changes and resolves conflicts
Participant of SCM process:
[Link]
• The auditor is responsible for SCM audits and reviews.
• Need to ensure the consistency and completeness of release.
4. Project Manager:
• Ensure that the product is developed within a certain time frame
• Monitors the progress of development and recognizes issues in the SCM process
• Generate reports about the status of the software system
• Make sure that processes and policies are followed for creating, changing, and testing
5. User
The end user should understand the key SCM terms to ensure he has the latest version of
the software