INSTITUTE OF ENGINEERING

JIWAJI UNIVERSITY

SOFTWARE ENGINEERING
CS-603 ASSIGNMENT-02

Submitted to: Submitted by:

Lokendra sir Priyanka Pawar
3rd year (CSE)
171489954
Ques1: Explain Software Design Process?
Answer:
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.

Software Design Levels:

Software design yields three levels of results:

 Architectural Design - The architectural design is the highest

abstract version of the system. It identifies the software as a
system with many components interacting with each other. At
this level, the designers get the idea of proposed solution
domain.
 High-level Design- The high-level design breaks the ‘single
entity-multiple component’ concept of architectural design into
less-abstracted view of sub-systems and modules and depicts
their interaction with each other. High-level design focuses on
how the system along with all of its components can be
implemented in forms of modules. It recognizes modular
 structure of each sub-system and their relation and interaction
among each other.
 Detailed Design- Detailed design deals with the
implementation part of what is seen as a system and its sub-
systems in the previous two designs. It is more detailed
towards modules and their implementations. It defines logical
structure of each module and their interfaces to communicate
with other modules.

Modularization:
Modularization is a technique to divide a software system into
multiple discrete and independent modules, which are expected to
be capable of carrying out task(s) independently. These modules
may work as basic constructs for the entire software. Designers
tend to design modules such that they can be executed and/or
compiled separately and independently.
Modular design unintentionally follows the rules of ‘divide and
conquer’ problem-solving strategy this is because there are many
other benefits attached with the modular design of a software.
Advantage of modularization:
 Smaller components are easier to maintain
 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect

Concurrency:
Back in time, all software are meant to be executed sequentially. By
sequential execution we mean that the coded instruction will be
executed one after another implying only one portion of program
being activated at any given time. Say, software has multiple
modules, then only one of all the modules can be found active at any
time of execution.
In software design, concurrency is implemented by splitting the
software into multiple independent units of execution, like modules
and executing them in parallel. In other words, concurrency
provides capability to the software to execute more than one part of
code in parallel to each other.
It is necessary for the programmers and designers to recognize
those modules, which can be made parallel execution.

Example: The spell check feature in word processor is a module of

software, which runs alongside the word processor itself.

Coupling and Cohesion:

When a software program is modularized, its tasks are divided into
several modules based on some characteristics. As we know,
modules are set of instructions put together in order to achieve
some tasks. They are though, considered as single entity but may
refer to each other to work together. There are measures by which
the quality of a design of modules and their interaction among them
can be measured. These measures are called coupling and cohesion.

Cohesion:
Cohesion is a measure that defines the degree of intra-
dependability within elements of a module. The greater the
cohesion, the better is the program design.
There are seven types of cohesion, namely –

 Co-incidental cohesion - It is unplanned and random

cohesion, which might be the result of breaking the program
 into smaller modules for the sake of modularization. Because it
is unplanned, it may serve confusion to the programmers and
is generally not-accepted.
 Logical cohesion - When logically categorized elements are
put together into a module, it is called logical cohesion.
 Temporal Cohesion - When elements of module are organized
such that they are processed at a similar point in time, it is
called temporal cohesion.
 Procedural cohesion - When elements of module are grouped
together, which are executed sequentially in order to perform a
task, it is called procedural cohesion.
 Communicational cohesion - When elements of module are
grouped together, which are executed sequentially and work
on same data (information), it is called communicational
cohesion.
 Sequential cohesion - When elements of module are grouped
because the output of one element serves as input to another
and so on, it is called sequential cohesion.
 Functional cohesion - It is considered to be the highest
degree of cohesion, and it is highly expected. Elements of
module in functional cohesion are grouped because they all
contribute to a single well-defined function. It can also be
reused.

Coupling:
Coupling is a measure that defines the level of inter-dependability
among modules of a program. It tells at what level the modules
interfere and interact with each other. The lower the coupling, the
better the program.
There are five levels of coupling, namely -

 Content coupling - When a module can directly access or

modify or refer to the content of another module, it is called
content level coupling.
 Common coupling- When multiple modules have read and
write access to some global data, it is called common or global
coupling.
 Control coupling- Two modules are called control-coupled if
one of them decides the function of the other module or
changes its flow of execution.
 Stamp coupling- When multiple modules share common data
structure and work on different part of it, it is called stamp
coupling.
 Data coupling- Data coupling is when two modules interact
with each other by means of passing data (as parameter). If a
module passes data structure as parameter, then the receiving
module should use all its components.
Ideally, no coupling is considered to be the best.

Design Verification
The output of software design process is design documentation,
pseudo codes, detailed logic diagrams, process diagrams, and
detailed description of all functional or non-functional
requirements.
The next phase, which is the implementation of software, depends
on all outputs mentioned above.
It is then becomes necessary to verify the output before proceeding
to the next phase. The early any mistake is detected, the better it is
or it might not be detected until testing of the product. If the
outputs of design phase are in formal notation form, then their
associated tools for verification should be used otherwise a
thorough design review can be used for verification and validation.
By structured verification approach, reviewers can detect defects
that might be caused by overlooking some conditions. A good
design review is important for good software design, accuracy and
quality.

Ques2: Explain UML?

Answer:
UML, short for Unified Modeling Language, is a standardized
modeling language consisting of an integrated set of diagrams,
developed to help system and software developers for specifying,
visualizing, constructing, and documenting the artifacts of software
systems, as well as for business modeling and other non-software
systems. The UML represents a collection of best engineering
practices that have proven successful in the modeling of large and
complex systems. The UML is a very important part of developing
objects oriented software and the software development process.
The UML uses mostly graphical notations to express the design of
software projects. Using the UML helps project teams
communicate, explore potential designs, and validate the
architectural design of the software. In this article, we will give you
detailed ideas about what is UML, the history of UML and a
description of each UML diagram type, along with UML examples.
The Origin of UML
The goal of UML is to provide a standard notation that can be used
by all object-oriented methods and to select and integrate the best
elements of precursor notations. UML has been designed for a
broad range of applications. Hence, it provides constructs for a
broad range of systems and activities (e.g., distributed systems,
analysis, system design and deployment).
UML is a notation that resulted from the unification of OMT from
1. Object Modeling Technique OMT [James Rumbaugh 1991]
- was best for analysis and data-intensive information
systems.
2. Booch [Grady Booch 1994] - was excellent for design and
implementation. Grady Booch had worked extensively with
the Ada language, and had been a major player in the
development of Object Oriented techniques for the language.
Although the Booch method was strong, the notation was less
well received (lots of cloud shapes dominated his models - not
very tidy)
3. OOSE (Object-Oriented Software Engineering [Ivar
Jacobson 1992]) - featured a model known as Use Cases. Use
Cases are a powerful technique for understanding the
behavior of an entire system (an area where OO has
traditionally been weak).
In 1994, Jim Rumbaugh, the creator of OMT, stunned the software
world when he left General Electric and joined Grady Booch at
Rational Corp. The aim of the partnership was to merge their ideas
into a single, unified method (the working title for the method was
indeed the "Unified Method").
By 1995, the creator of OOSE, Ivar Jacobson, had also joined
Rational, and his ideas (particularly the concept of "Use Cases")
were fed into the new Unified Method - now called the Unified
Modelling Language1. The team of Rumbaugh, Booch and Jacobson
are affectionately known as the "Three Amigos"
UML has also been influenced by other object-oriented notations:
  Mellor and Shlaer [1998]
 Coad and Yourdon [1995]
 Wirfs-Brock [1990]
 Martin and Odell [1992]

UML also includes new concepts that were not present in other
major methods at the time, such as extension mechanisms and a
constraint language.
History of UML
1. During 1996, the first Request for Proposal (RFP) issued by
the Object Management Group (OMG) provided the catalyst
for these organizations to join forces around producing a joint
RFP response.
2. Rational established the UML Partners consortium with
several organizations willing to dedicate resources to work
toward a strong UML 1.0 definition. Those contributing most
to the UML 1.0 definition included:
 Digital Equipment Corp
 HP
 i-Logix
 IntelliCorp
 IBM
 ICON Computing
 MCI System house
 Microsoft
 Oracle
 Rational Software
 TI
 Unisys
3. This collaboration produced UML 1.0, a modeling language
that was well-defined, expressive, powerful, and generally
applicable. This was submitted to the OMG in January 1997 as
an initial RFP response.1
4. In January 1997 IBM, ObjecTime, Platinum Technology, Ptech,
Taskon, Reich Technologies and Softeam also submitted
separate RFP responses to the OMG. These companies joined
the UML partners to contribute their ideas, and together the
partners produced the revised UML 1.1 response. The focus of
the UML 1.1 release was to improve the clarity of the UML 1.0
semantics and to incorporate contributions from the new
partners. It was submitted to the OMG for their consideration
and adopted in the fall of 1997.1 and enhanced 1.1 to 1.5, and
subsequently to UML 2.1 from 01 to 06 (now the UML current
version is 2.5)
Ques3: Describe User Interface Design?
Answer:
User interface is the front-end application view to which user
interacts in order to use the software. User can manipulate and
control the software as well as hardware by means of user
interface. Today, user interface is found at almost every place
where digital technology exists, right from computers, mobile
phones, cars, music players, airplanes, ships etc.
User interface is part of software and is designed such a way that it
is expected to provide the user insight of the software. UI provides
fundamental platform for human-computer interaction.
UI can be graphical, text-based, audio-video based, depending upon
the underlying hardware and software combination. UI can be
hardware or software or a combination of both.
The software becomes more popular if its user interface is:

 Attractive
 Simple to use
 Responsive in short time
 Clear to understand
 Consistent on all interfacing screens
UI is broadly divided into two categories:

 Command Line Interface

 Graphical User Interface

Command Line Interface (CLI):

CLI has been a great tool of interaction with computers until the
video display monitors came into existence. CLI is first choice of
many technical users and programmers. CLI is minimum interface
software can provide to its users.
CLI provides a command prompt, the place where the user types
the command and feeds to the system. The user needs to remember
the syntax of command and its use. Earlier CLI were not
programmed to handle the user errors effectively.
A command is a text-based reference to set of instructions, which
are expected to be executed by the system. There are methods like
macros, scripts that make it easy for the user to operate.
CLI uses less amount of computer resource as compared to GUI.

CLI Elements

A text-based command line interface can have the following

elements:
  Command Prompt - It is text-based notifier that is mostly
shows the context in which the user is working. It is generated
by the software system.
 Cursor - It is a small horizontal line or a vertical bar of the
height of line, to represent position of character while typing.
Cursor is mostly found in blinking state. It moves as the user
writes or deletes something.
 Command - A command is an executable instruction. It may
have one or more parameters. Output on command execution
is shown inline on the screen. When output is produced,
command prompt is displayed on the next line.

Graphical User Interface:

Graphical User Interface provides the user graphical means to

interact with the system. GUI can be combination of both hardware
and software. Using GUI, user interprets the software.
Typically, GUI is more resource consuming than that of CLI. With
advancing technology, the programmers and designers create
complex GUI designs that work with more efficiency, accuracy and
speed.

GUI Elements:

GUI provides a set of components to interact with software or

hardware.
Every graphical component provides a way to work with the
system. A GUI system has following elements such as:
 Window - An area where contents of application are
displayed. Contents in a window can be displayed in the form
of icons or lists, if the window represents file structure. It is
easier for a user to navigate in the file system in an exploring
window. Windows can be minimized, resized or maximized to
the size of screen. They can be moved anywhere on the screen.
A window may contain another window of the same
application, called child window.
 Tabs - If an application allows executing multiple instances of
it, they appear on the screen as separate windows. Tabbed
Document Interface has come up to open multiple
documents in the same window. This interface also helps in
viewing preference panel in application. All modern web-
browsers use this feature.
 Menu - Menu is an array of standard commands, grouped
together and placed at a visible place (usually top) inside the
application window. The menu can be programmed to appear
or hide on mouse clicks.
  Icon - An icon is small picture representing an associated
application. When these icons are clicked or double clicked,
the application window is opened. Icon displays application
and programs installed on a system in the form of small
pictures.
 Cursor - Interacting devices such as mouse, touch pad, digital
pen are represented in GUI as cursors. On screen cursor
follows the instructions from hardware in almost real-time.
Cursors are also named pointers in GUI systems. They are
used to select menus, windows and other application features.

Application specific GUI components:

A GUI of an application contains one or more of the listed GUI

elements:
 Application Window - Most application windows uses the
constructs supplied by operating systems but many use their
own customer created windows to contain the contents of
application.
 Dialogue Box - It is a child window that contains message for
the user and request for some action to be taken. For Example:
Application generates a dialogue to get confirmation from
user to delete a file.
  Text-Box - Provides an area for user to type and enter text-
based data.
 Buttons - They imitate real life buttons and are used to submit
inputs to the software.

 Radio-button - Displays available options for selection. Only

one can be selected among all offered.
 Check-box - Functions similar to list-box. When an option is
selected, the box is marked as checked. Multiple options
represented by check boxes can be selected.
 List-box - Provides list of available items for selection. More
than one item can be selected.

Other impressive GUI components are:

 Sliders
 Combo-box
 Data-grid
  Drop-down list

User Interface Design Activities

There are a number of activities performed for designing user

interface. The process of GUI design and implementation is alike
SDLC. Any model can be used for GUI implementation among
Waterfall, Iterative or Spiral Model.
A model used for GUI design and development should fulfill these
GUI specific steps.

 GUI Requirement Gathering - The designers may like to have

list of all functional and non-functional requirements of GUI.
This can be taken from user and their existing software
solution.
 User Analysis - The designer studies who is going to use the
software GUI. The target audience matters as the design
details change according to the knowledge and competency
level of the user. If user is technical savvy, advanced and
 complex GUI can be incorporated. For a novice user, more
information is included on how-to of software.
 Task Analysis - Designers have to analyze what task is to be
done by the software solution. Here in GUI, it does not matter
how it will be done. Tasks can be represented in hierarchical
manner taking one major task and dividing it further into
smaller sub-tasks. Tasks provide goals for GUI presentation.
Flow of information among sub-tasks determines the flow of
GUI contents in the software.
 GUI Design & implementation - Designers after having
information about requirements, tasks and user environment,
design the GUI and implements into code and embed the GUI
with working or dummy software in the background. It is then
self-tested by the developers.
 Testing - GUI testing can be done in various ways.
Organization can have in-house inspection, direct involvement
of users and release of beta version are few of them. Testing
may include usability, compatibility, user acceptance etc.

GUI Implementation Tools:

There are several tools available using which the designers can
create entire GUI on a mouse click. Some tools can be embedded
into the software environment (IDE).
GUI implementation tools provide powerful array of GUI controls.
For software customization, designers can change the code
accordingly.
There are different segments of GUI tools according to their
different use and platform.

Example: Mobile GUI, Computer GUI, Touch-Screen GUI etc. Here is a

list of few tools which come handy to build GUI:
  FLUID
 AppInventor (Android)
 LucidChart
 Wavemaker
 Visual Studio

User Interface Golden rules

The following rules are mentioned to be the golden rules for GUI
design, described by Shneiderman and Plaisant in their book
(Designing the User Interface).
 Strive for consistency - Consistent sequences of actions
should be required in similar situations. Identical terminology
should be used in prompts, menus, and help screens.
Consistent commands should be employed throughout.
 Enable frequent users to use short-cuts - The user’s desire
to reduce the number of interactions increases with the
frequency of use. Abbreviations, function keys, hidden
commands, and macro facilities are very helpful to an expert
user.
 Offer informative feedback - For every operator action, there
should be some system feedback. For frequent and minor
actions, the response must be modest, while for infrequent
and major actions, the response must be more substantial.
 Design dialog to yield closure - Sequences of actions should
be organized into groups with a beginning, middle, and end.
The informative feedback at the completion of a group of
actions gives the operators the satisfaction of
accomplishment, a sense of relief, the signal to drop
contingency plans and options from their minds, and this
indicates that the way ahead is clear to prepare for the next
group of actions.
  Offer simple error handling - As much as possible, design the
system so the user will not make a serious error. If an error is
made, the system should be able to detect it and offer simple,
comprehensible mechanisms for handling the error.
 Permit easy reversal of actions - This feature relieves
anxiety, since the user knows that errors can be undone. Easy
reversal of actions encourages exploration of unfamiliar
options. The units of reversibility may be a single action, a
data entry, or a complete group of actions.
 Support internal locus of control - Experienced operators
strongly desires the sense that they are in charge of the
system and that the system responds to their actions. Design
the system to make users the initiators of actions rather than
the responders.
 Reduce short-term memory load - The limitation of human
information processing in short-term memory requires the
displays to be kept simple, multiple page displays be
consolidated, window-motion frequency be reduced, and
sufficient training time be allotted for codes, mnemonics, and
sequences of actions.

Ques4: Explain SA/SD component based design?

Answer:
Structured Analysis is a development method that allows the
analyst to understand the system and its activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze
and refine the objectives of an existing system and develop a new
system specification which can be easily understandable by user.
It has following attributes −
  It is graphic which specifies the presentation of application.
 It divides the processes so that it gives a clear picture of
system flow.
 It is logical rather than physical i.e., the elements of system do
not depend on vendor or hardware.
 It is an approach that works from high-level overviews to
lower-level details.

Structured Analysis Tools:

During Structured Analysis, various tools and techniques are used
for system development. They are −

 Data Flow Diagrams

 Data Dictionary
 Decision Trees
 Decision Tables
 Structured English
 Pseudocode
Data Flow Diagrams (DFD) or Bubble Chart:
It is a technique developed by Larry Constantine to express the
requirements of system in a graphical form.
 It shows the flow of data between various functions of system
and specifies how the current system is implemented.
 It is an initial stage of design phase that functionally divides
the requirement specifications down to the lowest level of
detail.
 Its graphical nature makes it a good communication tool
between user and analyst or analyst and system designer.
 It gives an overview of what data a system processes, what
transformations are performed, what data are stored, what
results are produced and where they flow.

Basic Elements of DFD:

DFD is easy to understand and quite effective when the required
design is not clear and the user wants a notational language for
communication. However, it requires a large number of iterations
for obtaining the most accurate and complete solution.
The following table shows the symbols used in designing a DFD and
their significance −

Symbol Name Symbol Meaning

Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow

Open Rectangle Data Store

Types of DFD:
DFDs are of two types: Physical DFD and Logical DFD. The following
table lists the points that differentiate a physical DFD from a logical
DFD.

Physical DFD Logical DFD

It is implementation dependent. It It is implementation independent. It

shows which functions are focuses only on the flow of data
performed. between processes.

It provides low level details of It explains events of systems and data

hardware, software, files, and required by each event.
people.

It depicts how the current system It shows how business operates; not
operates and how a system will be how the system can be implemented.
implemented.

Context Diagram:
A context diagram helps in understanding the entire system by one
DFD which gives the overview of a system. It starts with mentioning
major processes with little details and then goes onto giving more
details of the processes with the top-down approach.
The context diagram of mess management is shown below.

Data Dictionary:
A data dictionary is a structured repository of data elements in the
system. It stores the descriptions of all DFD data elements that is,
details and definitions of data flows, data stores, data stored in data
stores, and the processes.
A data dictionary improves the communication between the analyst
and the user. It plays an important role in building a database. Most
DBMSs have a data dictionary as a standard feature. For example,
refer the following table −

Sr.No. Data Name Description No. of Characters

1 ISBN ISBN Number 10

2 TITLE title 60

3 SUB Book Subjects 80

4 ANAME Author Name 15

Decision Trees:
Decision trees are a method for defining complex relationships by
describing decisions and avoiding the problems in communication.
A decision tree is a diagram that shows alternative actions and
conditions within horizontal tree framework. Thus, it depicts which
conditions to consider first, second, and so on.
Decision trees depict the relationship of each condition and their
permissible actions. A square node indicates an action and a circle
indicates a condition. It forces analysts to consider the sequence of
decisions and identifies the actual decision that must be made.
The major limitation of a decision tree is that it lacks information in
its format to describe what other combinations of conditions you
can take for testing. It is a single representation of the relationships
between conditions and actions.
For example, refer the following decision tree −

Decision Tables:
Decision tables are a method of describing the complex logical
relationship in a precise manner which is easily understandable.
  It is useful in situations where the resulting actions depend on
the occurrence of one or several combinations of independent
conditions.
 It is a matrix containing row or columns for defining a problem
and the actions.

Components of a Decision Table:

 Condition Stub − It is in the upper left quadrant which lists all
the condition to be checked.
 Action Stub − It is in the lower left quadrant which outlines all
the action to be carried out to meet such condition.
 Condition Entry − It is in upper right quadrant which
provides answers to questions asked in condition stub
quadrant.
 Action Entry − It is in lower right quadrant which indicates
the appropriate action resulting from the answers to the
conditions in the condition entry quadrant.
The entries in decision table are given by Decision Rules which
define the relationships between combinations of conditions and
courses of action. In rules section,

 Y shows the existence of a condition.

 N represents the condition, which is not satisfied.
 A blank - against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be
carried out.
For example, refer the following table −

CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4

 Advance payment made Y N N N

Purchase amount = Rs - Y Y N
10,000/-

Regular Customer - Y N -

ACTIONS

Give 5% discount X X - -

Give no discount - - X X

Structured English:
Structure English is derived from structured programming
language which gives more understandable and precise description
of process. It is based on procedural logic that uses construction
and imperative sentences designed to perform operation for action.
 It is best used when sequences and loops in a program must be
considered and the problem needs sequences of actions with
decisions.
 It does not have strict syntax rule. It expresses all logic in
terms of sequential decision structures and iterations.
For example, see the following sequence of actions −
if customer pays advance
then
Give 5% Discount
else
 if purchase amount >=10,000
then
if the customer is a regular customer
then Give 5% Discount
else No Discount
end if
else No Discount
end if
end if

Pseudo code
A pseudo code does not conform to any programming language and
expresses logic in plain English.
 It may specify the physical programming logic without actual
coding during and after the physical design.
 It is used in conjunction with structured programming.
 It replaces the flowcharts of a program.

Guidelines for Selecting Appropriate Tools:

Use the following guidelines for selecting the most appropriate tool
that would suit your requirements −
 Use DFD at high or low level analysis for providing good
system documentations.
 Use data dictionary to simplify the structure for meeting the
data requirement of the system.
 Use structured English if there are many loops and actions are
complex.
 Use decision tables when there are a large number of
conditions to check and logic is complex.
 Use decision trees when sequencing of conditions is important
and if there are few conditions to be tested.