PANIMALAR INSTITUTE OF TECHNOLOGY

(JAISAKTHI EDUCATIONAL TRUST)

CHENNAI 600 123

DEPARTMENT OF CSE
(Accredited to National Board of Accreditation)
CS8494 SOFTWARE ENGINEERING
II YEAR – IV SEMESTER
LECTURE NOTES - UNIT III

Prepared By Verified By Approved By

Mrs.E.Archana,
Mrs.S.Padmapriya Dr.V.Subedha Principal

Asst.Professor HOD/CSE
PIT – CSE II Year / IV Sem

UNIT III
SOFTWARE DESIGN

Design process: Design Concepts-Design Model, Design Heuristic. Architectural Design:

Architectural styles, Architectural Design, Architectural Mapping using Data Flow. User
Interface Design: Interface analysis, Interface Design. Component level Design:
Designing Class based components, traditional Components.

3.Design process:
Software design:
Software design is model of software which translates the requirements into finished
software products in which the details about software data structures, architectures,
interfaces and components that are necessary to implement the system are given.
Levels of design:

Software Quality Guidelines and Attributes(characteristics of good design):

 The design must implement all of the explicit requirements contained in the
requirements model, and it must accommodate all of the implicit requirements
desired by stakeholders.
 The design must be a readable, understandable guide for those who generate code
and for those who test and subsequently support the software.

CS8494 – Software Engineering 2

PIT – CSE II Year / IV Sem

 The design should provide a complete picture of the software, addressing the data,
functional, and behavioral domains from an implementation perspective.
Quality Guidelines
1. A design should exhibit an architecture that
(1) Has been created using recognizable architectural styles or patterns,
(2) Is composed of components that exhibit good design characteristics,
(3) Can be implemented in an evolutionary fashion.
2. A design should be modular; that is, the software should be logically partitioned into
elements or subsystems.
3. A design should contain distinct representations of data, architecture, interfaces, and
components.
4. A design should lead to data structures that are appropriate for the classes to be
implemented and are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
7. A design should be derived using a repeatable method that is driven by infor mation
obtained during software requirements analysis.
8. A design should be represented using a notation that effectively communicates its
meaning.
Quality Attributes
 Functionality
 Usability
 Reliability
 Performance
 Supportability

3.1Design Concepts
The software Design Concepts provides a framework for implementing the right software.
1. Abstraction
2. Modularity
3. Architecture
4. Refinement
5. Pattern
6. Information hiding
7. Functional independence
8. Refinement
9. Design classes

CS8494 – Software Engineering 3

PIT – CSE II Year / IV Sem

1.Abstraction:
 When you consider a modular solution to any problem, many levels of abstraction
can be posed.
 Highest level of abstraction, a solution is stated in broad terms.
 Lower levels of abstraction, a more detailed description of the solution is provided.
 Lowest level of abstraction, the solution is stated in a manner that can be directly
implemented.
Two types:
1. Procedural abstraction
2. Data abstraction
Procedural abstraction refers to a sequence of instructions that have a specific and
limited function. Data abstraction is a named collection of data that describes a data
object.
2.Architecture:
 Architecture is the structure or organization of program components (Modules), the
manner in which these components interact, and the structure of data that are used
by the components.
3.Patterns:
 A design pattern describes a design structure that solves a particular design
problem within a specific context and amid “forces” that may have an impact on the
manner in which the pattern is applied and used.
 The intent of each design pattern is to provide a description that enables a designer
to determine
(1) Whether the pattern is applicable to the current work,
(2) Whether the pattern can be reused (hence, saving design time), and
(3) Whether the pattern can serve as a guide for developing a similar, but functionally or
structurally different pattern.
Separation of Concerns:
 Separation of concerns is a design concept that suggests that any complex problem
can be more easily handled if it is subdivided into pieces that can each be solved
and/or optimized independently.
 A concern is a feature or behavior that is specified as part of the requirements model
for the software.
 By separating concerns into smaller and therefore more manageable pieces, a
problem takes less effort and time to solve.
 It also follows that the perceived complexity of two problems when they are
combined is often greater than the sum of the perceived complexity when each is
taken separately.

CS8494 – Software Engineering 4

PIT – CSE II Year / IV Sem

 This leads to a divide-and-conquer strategy—it’s easier to solve a complex problem

when you break it into manageable pieces. This has important implications with
regard to software modularity.
 Separation of concerns is manifested in other related design concepts: modularity,
aspects, functional independence, and refinement.
4.Modularity:
 Modularity is the most common example of separation of concerns. Software is
divided into separately named and addressable components, sometimes called
modules that are integrated to satisfy problem requirements.
 It has been stated that “modularity is the single attribute of software that allows a
program to be intellectually manageable”
 Follows “divide and conquer” concept, a complex problem is broken down into
several manageable pieces
Let p1 and p2 be two problems.
Let E1 and E2 be the effort required to solve them,
If c(p1)>c(p2)
Hence E(p1)>E(p2)
Now, Complexity of a problem that combines p1 and p2 is greater than
complexity when each problem is consider
C(p1+p2) > C(p1)+C(p2)
Hence, E(p1+p2) > E(p1)+E(p2)
 It is easier to solve a complex problem when you break it into manageable pieces

If an error occurs within a module then those errors are localized and not spread to other
modules.
The 5 criteria to evaluate a design method with respect to its modularity ,
 Modular understandability
Module should be understandable as a standalone unit (no need to refer to other modules)

CS8494 – Software Engineering 5

PIT – CSE II Year / IV Sem

 Modular continuity
If small changes to the system requirements result in changes to individual modules, rather
than system wide changes, the impact of side effects will be minimized.

 Modular protection
If an error occurs within a module then those errors are localized and not spread to other
modules.

 Modular Composability
Design method should enable reuse of existing components.

 Modular Decomposability
Complexity of the overall problem can be reduced if the design method provides a
systematic mechanism to decompose a problem into sub problems.

5.Information Hiding:
 Modules should be specified and designed so that information (algorithms and data)
contained within a module is inaccessible to other modules that have no need for
such information.
 Hiding implies that effective modularity can be achieved by defining a set of
independent modules that communicate with one another only that information
necessary to achieve software function.
 The use of information hiding as a design criterion for modular systems provides
the greatest benefits when modifications are required during testing and later
during software maintenance.
 Because most data and procedural detail are hidden from other parts of the
software, inadvertent errors introduced during modification are less likely to
propagate to other locations within the software.

6.Functional Independence:
 The concept of functional independence is a direct outgrowth of separation of
concerns, modularity, and the concepts of abstraction and information hiding.
 You should design software so that each module addresses a specific subset of
requirements and has a simple interface when viewed from other parts of the
program structure.

Why independence is important?

 Software with effective modularity, that is, independent modules, is easier to
develop because function can be compartmentalized and interfaces are simplified.

CS8494 – Software Engineering 6

PIT – CSE II Year / IV Sem

 Independent modules are easier to maintain (and test) because secondary effec ts
caused by design or code modification are limited, error propagation is reduced, and
reusable modules are possible.
 Functional independence is a key to good design, and design is the key to software
quality.
Independence is assessed using two qualitative criteria:
1. cohesion
2. coupling
Cohesion is an indication of the relative functional strength of a module.
Coupling is an indication of the relative interdependence among modules.
 Cohesion is a natural extension of the information-hiding.
A cohesive module performs a single task, requiring little interaction with other
components in other parts of a program.
Types of Cohesion:
 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 is an indication of interconnection among modules in a software

structure. Coupling depends on the interface complexity between modules, the point
at which entry or reference is made to a module, and what data pass across the
interface.

CS8494 – Software Engineering 7

PIT – CSE II Year / IV Sem

Types of Coupling:

 Content coupling (high)

Content coupling (also known as pathological coupling) occurs when one module
modifies or relies on the internal workings of another module (e.g., accessing local
data of another module). In this situation, a change in the way the second module
produces data (location, type, timing) might also require a change in the dependent
module.
 Common coupling
Common coupling (also known as global coupling) occurs when two modules share
the same global data (e.g., a global variable). Changing the shared resource might
imply changing all the modules using it.
 External coupling
External coupling occurs when two modules share an externally imposed data
format, communication protocol, or device interface. This is basically related to the
communication to external tools and devices.
 Control coupling
Control coupling is one module controlling the flow of another, by passing it I
information on what to do (e.g., passing a what-to-do flag).
 Stamp coupling (data-structured coupling)
Stamp coupling occurs when modules share a composite data structure and use only
parts of it, possibly different parts (e.g., passing a whole record to a function that
only needs one field of it).In this situation, a modification in a field that a module
does not need may lead to changing the way the module reads the record.
 Data coupling
Data coupling occurs when modules share data through, for example, parameters.
Each datum is an elementary piece, and these are the only data shared (e.g., passing
an integer to a function that computes a square root).
 Message coupling (low)
This is the loosest type of coupling. It can be achieved by state decentralization (as
in objects) and component communication is done via parameters or message
passing.

CS8494 – Software Engineering 8

PIT – CSE II Year / IV Sem

7.Refinement:
 Refinement is actually a process of elaboration. You begin with a statement of
function (or description
 Refinement helps you to reveal low-level details as design progresses
8.Refactoring
 Refactoring is a reorganization technique that simplifies the design (or code) of a
component without changing its function or behavior.
 Refactoring is the process of changing a software system in such a way that it does
not alter the external behavior of the code [design] yet improves its internal
structure.
 When software is refactored, the existing design is examined for redundancy,
unused design elements, inefficient or unnecessary algorithms, poo rly constructed
or inappropriate data structures, or any other design failure that can be corrected to
yield a better design.
Object-Oriented Design Concepts
The object-oriented (OO) paradigm is widely used in modern software engineering.
It includes classes and objects, inheritance, messages, and polymorphism
9.Design Classes:
 As the design model evolves, you will define a set of design classes that refine the
analysis classes by providing design detail that will enable the classes to be
implemented, and implement a software infrastructure that supports the business
solution.
 Five different types of design classes, each representing a different layer of the
design architecture
1. User interface classes define all abstractions that are necessary for human
computer interaction (HCI). In many cases, HCI occurs within the context of a
metaphor (e.g., a checkbook, an order form, a fax machine), and the design classes
for the interface may be visual representations of the elements of the metaphor.
2. Business domain classes are often refinements of the analysis classes defined
earlier. The classes identify the attributes and services (methods) that are required
to implement some element of the business domain.
3. Process classes implement lower-level business abstractions required to fully
manage the business domain classes.
4. Persistent classes represent data stores (e.g., a database) that will persist beyond
the execution of the software.
5. System classes implement software management and control functions that enable
the system to operate and communicate within its computing environment and with
the outside world.

CS8494 – Software Engineering 9

PIT – CSE II Year / IV Sem

They define four characteristics of a well-formed design class:

 Complete and sufficient.
 Primitiveness.
 High cohesion
 Low coupling

3.2 THE DESIGN MODEL

 The design model can be viewed in two different dimensions as illustrated in two
different dimensions.
1. process dimension
2. abstraction dimension

 The process dimension indicates the evolution of the design model as design tasks
are executed as part of the software process.
 The abstraction dimension represents the level of detail as each element of the
analysis model is transformed into a design equivalent and then refined iteratively.

CS8494 – Software Engineering 10

PIT – CSE II Year / IV Sem

1. Data Design Elements

 Customer’s/ User’s View:Data Architecting means it creates a model of data that is
represented at a high level of abstraction i.e. Build Architecture of Data.
 Program Component Level: The design of Data structure & algorithms.
 Application Level: Translate Data Model into a database.
 Business Level: Data warehouse(Reporting & Analysis of DB) & Data
mining(Analysis).
 At last it means creation of Data Dictionary.
2. Architectural Design Elements
 Provides an overall view of the software product(Similar like Floor Plan of house)
 The architectural model is derived from three sources:
a. Information about the application domain for the software to be built;
b. Specific requirements model elements such as data flow diagrams or
analysis classes, their relationships and collaborations for the problem at
hand;
c. The availability of architectural styles (Chapter 9) and patterns
 Difference: An architectural style is a conceptual way of how the system will be
created / will work.
 An architectural pattern describes a solution for implementing a style at the level of
subsystems or modules and their relationships.
3. Interface Design Elements
 The interface design elements for software represent information flows into and out
of the system and how it is communicated among the components defined as part of
the architecture.
 There are three important elements of interface design:
a. The user interface (UI);
b. External interfaces to other systems, devices, networks, or other
producers or consumers of information;
c. Internal interfaces between various design components.
4. Component-Level Design Elements
The component-level design for software fully describes the internal detail of each
software component.

CS8494 – Software Engineering 11

PIT – CSE II Year / IV Sem

5. Deployment-Level Design Elements

Deployment-level design elements indicate how software functionality and
subsystems will be allocated within the physical computing environment that will
support the software.

3.3DESIGN HEURISTICS:
1. Evaluate the "first iteration" of the program structure to reduce coupling and
improve cohesion.
Once the program structure has been developed, modules may be exploded or imploded
with an eye toward improving module independence. An exploded module becomes two or
more modules in the final program structure.
An imploded module is the result of combining the processing implied by two or more
modules. An exploded module often results when common processing exists in two or
more modules and can be redefined as a separate cohesive module. When high coupling is
expected, modules can sometimes be imploded to reduce passage of control, reference to
global data, and interface complexity.
2. Attempt to minimize structures with high fan-out; strive for fan-in as depth
increases.
The structure shown inside the cloud in figure does not make effective use of factoring. All
modules are “pancaked” below a single control module. In general, a more reasonable
distribution of control is shown in the upper structure. The structure takes an oval shape,
indicating a number of layers of control and highly utilitarian modules at lower levels.
3. Keep the scope of effect of a module within the scope of control of that
module.
The scope of effect of module e is defined as all other modules that are affected by a
decision made in module e. The scope of control of module e is all modules that are
subordinate and ultimately subordinate to module e. Referring to figure, if module e makes

CS8494 – Software Engineering 12

PIT – CSE II Year / IV Sem

a decision that affects module r, we have a violation of this heuristic, because module r lies
outside the scope of control of module e.
4. Evaluate module interfaces to reduce complexity and redundancy and
improve consistency.
Module interface complexity is a prime cause of software errors .Interfaces should be
designed to pass information simply and should be consistent with the function of a
module. Interface inconsistency (i.e., seemingly unrelated data passed via an a rgument list
or other technique) is an indication of low cohesion. The module in question should be
reevaluated.
5. Define modules whose function is predictable, but avoid modules that are
overly restrictive.
A module is predictable when it can be treated as a black box; that is, the same external
data will be produced regardless of internal processing details. Modules that have internal
"memory" can be unpredictable unless care is taken in their use.
6. Strive for “controlled entry” modules by avoiding "pathological connections."
This design heuristic warns against content coupling. Software is easier to understand and
therefore easier to maintain when module interfaces are constrained and controlled.
Pathological connection refers to branches or references into the middle of a module.

3.4 ARCHITECTURAL DESIGN

 Architectural styles
Five styles
 Architectural Designing
Representing the System in Context
Defining Archetypes
Refining the Architecture into Components
 Architectural Mapping using Data Flow
Transform mapping
Transaction mapping
3.4.1Architectural styles
 Data-centered architectures.
 Data-flow architectures.
 Call and return architectures
 Object-oriented architectures
 Layered architectures
Data-centered architectures.
 A data store (e.g., a file or database) resides at the center of this architecture and is
accessed frequently by other components that update, add, delete, or otherwise
modify data within the store.
 Client software accesses a central repository.

CS8494 – Software Engineering 13

PIT – CSE II Year / IV Sem

 In some cases the data repository is passive. That is, client software accesses the
data independent of any changes to the data or the actions of other client software.
 A variation on this approach transforms the repository into a “blackboard” that
sends notifications to client software when data of interest to the client change.
 Data-centered architectures promote inerrability. That is, existing components can
be changed and new client components can be added to the architecture without
concern about other clients (because the client components operate
independently).
 Client components independently execute process.
 In addition, data can be passed among clients using the blackboard mechanism (i.e.,
the blackboard component serves to coordinate the transfer o f information between
clients).

Data-flow architectures:

 This architecture is applied when input data are to be transformed through a series
of computational or manipulative components into output data.
 A pipe and filter pattern has a set of components, called filters, connected by pipes
that transmit data from one component to the next.
 Each filter works independently of those components upstream and downstream, is
designed to expect data input of a certain form, and produces data output (to the
next filter) of a specified form.
 However, the filter does not require knowledge of the working of its neighboring
filters.

CS8494 – Software Engineering 14

PIT – CSE II Year / IV Sem

 If the data flow degenerates into a single line of transforms, it is termed batch
sequential. This pattern accepts a batch of data and then applies a series of
sequential components (filters) to transform it.

Call and return architectures:

 This architectural style enables a software designer (system architect) to achieve a
program structure that is relatively easy to modify and scale.
 A number of sub styles exist within this category:
1. Main program/subprogram architectures
2. Remote procedure call architectures
 Main program/subprogram architectures: This classic program structure
decomposes function into a control hierarchy where a “main” program invokes a
number of program components, which in turn may invoke still other components.
 Remote procedure calls architectures: The components of a main program/
subprogram architecture are distributed across multiple computers on a network.

CS8494 – Software Engineering 15

PIT – CSE II Year / IV Sem

Object-oriented architectures:
 The components of a system encapsulate data and the operations that must be
applied to manipulate the data.
 Communication and coordination between components is accomplished via
message passing.

Layered architectures:
 A number of different layers are defined, each accomplishing operations that
progressively become closer to the machine instruction set.
 At the outer layer, components service user interface operations. At the inner layer,
components perform operating system interfacing.
 Intermediate layers provide utility services and application software functions.
 These architectural styles are only a small subset of those available to the software
designer.
 Once requirements engineering uncovers the characteristics and constraints of the
system to be built, the architectural pattern (style) or combination of patterns
(styles) that best fits those characteristics and constraints can be chosen.
 In many cases, more than one pattern might be appropriate and alternative
architectural styles might be designed and evaluated.

CS8494 – Software Engineering 16

PIT – CSE II Year / IV Sem

3.4.2 Architectural Designing:

As architectural design begins, the software to be developed must be put into context—
that is, the design should define the external entities (other systems, devices, peop le) that
the software interacts with and the nature of the interaction.
Representing the System in Context
At the architectural design level, a software architect uses an architectural context diagram
(ACD) to model the manner in which software interacts with entities external to its
boundaries.systems that interoperate with the target system (the system for which an
architectural design is to be developed) are represented as

CS8494 – Software Engineering 17

PIT – CSE II Year / IV Sem

 Super ordinate systems—those systems that use the target system as part of some
higher-level processing scheme.
 Subordinate systems—those systems that are used by the target system and provide
data or processing that are necessary to complete target system functionality.
 Peer-level systems—those systems that interact on a peer-to-peer basis (i.e.,
information is either produced or consumed by the peers and the target system.
 Actors—entities (people, devices) that interact with the target system by producing
or consuming information that is necessary for requisite processing.

Defining Archetypes
An archetype is a class or pattern that represents a core abstraction that is critical to the
design of an architecture for the target system. In general, a relatively small set of
archetypes is required to design even relatively complex systems. The target system
architecture is composed of these archetypes, which represent stable elements of the
architecture but may be instantiated many different ways based on the behavior of the
system.
Node: Represents a cohesive collection of input and output elements of the home security
function. For example a node might be comprised of
(1) various sensors and (2) a variety of alarm (output) indicators.
Detector: An abstraction that encompasses all sensing equipment that feeds information
into the target system.
Indicator: An abstraction that represents all mechanisms (e.g., alarm siren, flashing lights,
bell) for indicating that an alarm condition is occurring.

CS8494 – Software Engineering 18

PIT – CSE II Year / IV Sem

Controller: An abstraction that depicts the mechanism that allows the arming or disarming
of a node. If controllers reside on a network, they have the ability to communicate with one
another.

Refining the Architecture into Components

To create full structure of the system it is required to refine the software architecture into
components.
1. The data flow diagram is drawn from which the specialized components can be
identified. Such components are the components that process the data flow across the
interfaces.
2. The components can be the entities that follow following functionalities
External communication management—coordinates communication of the security
function with external entities such as other Internet-based systems and external alarm
notification.
Control panel processing—manages all control panel functionality.
Detector management—coordinates access to all detectors attached to the system.
Alarm processing—verifies and acts on all alarm conditions.

3.4.3 Architectural Mapping Using Data Flow

Transform flow:
A transform flow is a sequence of paths which forms transition in which input data are
transformed into output data.

Transaction flow:
A transaction flow represents the information flow in which single data item triggers the
overall information flow along the multiple paths.

Transform Mapping
Transform mapping is a set of design steps that allows a DFD with transform flow
characteristics to be mapped into a specific architectural style.

CS8494 – Software Engineering 19

PIT – CSE II Year / IV Sem

Transform Mapping

Step 1. Review the fundamental system model.

CS8494 – Software Engineering 20

PIT – CSE II Year / IV Sem

Step 2. Review and refine data flow diagrams for the software.

CS8494 – Software Engineering 21

PIT – CSE II Year / IV Sem

Step 3. Determine whether the DFD has transform or transaction flow

characteristics.

Step 4. Isolate the transform center by specifying incoming and outgoing flow
boundaries.

CS8494 – Software Engineering 22

PIT – CSE II Year / IV Sem

Step 5. Perform "first-level factoring." Program structure represents a top-down

distribution of control.

CS8494 – Software Engineering 23

PIT – CSE II Year / IV Sem

Step 6. Perform "second-level factoring." Second-level factoring is accomplished by

mapping individual transforms (bubbles) of a DFD into appropriate modules within
the architecture.

CS8494 – Software Engineering 24

PIT – CSE II Year / IV Sem

Step 7. Refine the first-iteration architecture using design heuristics for improved
software quality.

Transaction Mapping
 In many software applications a single data item leads to one or more information
flows.
 Each information flow specifies some distinct functionality. This data item is called
transaction center.

CS8494 – Software Engineering 25

PIT – CSE II Year / IV Sem

Step 1. Review the fundamental system model.

Step 2. Review and refine data flow diagrams for the software.
Step 3. Determine whether the DFD has transform or transaction flow
characteristics.
Step 4. Identify the transaction center and the flow characteristics along each of the
action paths.
Step 5. Map the DFD in a program structure amenable to transaction processing.

CS8494 – Software Engineering 26

PIT – CSE II Year / IV Sem

Step 6. Factor and refine the transaction structure and the structure of each action
path.

Step 7. Refine the first-iteration architecture using design heuristics for improved
software quality.

3.5 User Interface Design:

The Golden Rules
 Three Rules
User interface analysis and design
 Interface analysis and design model
 The process
Interface analysis
 User analysis
Interface design
 Design issues

CS8494 – Software Engineering 27

PIT – CSE II Year / IV Sem

User interface:
User interface is a communication between human and computer.
HCI (Human Computer Interaction).
User interface design:
 The overall process for designing a user interface begins with the creation of
different models of system function (as perceived from the outside).
 The human- and computer-oriented tasks that are required to achieve system
function are then delineated; design issues that apply to all interface designs are
considered; tools are used to prototype and ultimately implement the design model;
and the result is evaluated for quality.

3.5.1 The Golden Rules

1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.
Place the user in control:
 Define interaction modes in a way that does not force a user into unnecessary or
undesired actions.
 Provide for flexible interaction.
 Allow user interaction to be interruptible and undoable.
 Streamline interaction as skill levels advance and allow the interaction to be
customized.
 Hide technical internals from the casual user.
 Design for direct interaction with objects that appear on the screen.
Reduce the User’s Memory Load:
 Reduce demand on short-term memory.
 Establish meaningful defaults.
 Define shortcuts that are intuitive.
 The visual layout of the interface should be based on a real world metaphor.
 Disclose information in a progressive fashion.
Make the Interface Consistent:
 Allow the user to put the current task into a meaningful context.
 Maintain consistency across a family of applications.
 If past interactive models have created user expectations, do not make changes
unless there is a compelling reason to do so.

3.5.2 User Interface analysis and Design:

Steps:
1. Create different models for system functions.
2. In order to perform these functions identify the human-Computer interface tasks.

CS8494 – Software Engineering 28

 PIT – CSE II Year / IV Sem

3. Prepare all interface design by solving various design issues.

4. Apply modern tools and techniques to prototype the design.
5. Implement design model
6. Evaluate the design from end user to bring quality in it.

Two major things to be discussed in this topic

1. Interface analysis and Design Models
2. The process

Interface analysis and Design Models:

Interface analysis and

Design Models

The User model The Design model The system model The implementation
model

 User profile model – Established by a human engineer or software engineer

 Design model – Created by a software engineer
 Implementation model – Created by the software implementers
 User's mental model – Developed by the user when interacting with the application
Interface Design.

User models:
To build an effective user interface, “all design should begin with an understanding of the
intended users, including profiles of their age, gender, physical abilities, education, cultural
or ethnic background, motivation, goals and personality”.

There are three types of users.

1. Novices. No syntactic knowledge of the system and little semantic knowledge of the
application or computer usage in general.
2. Knowledgeable, intermittent users. Reasonable semantic knowledge of the
application but relatively low recall of syntactic information necessary to use the
interface.
3. Knowledgeable, frequent users. Good semantic and syntactic knowledge that often
leads to the "power-user syndrome"; that is, individuals who look for shortcuts and
abbreviated modes of interaction.

CS8494 – Software Engineering 29

PIT – CSE II Year / IV Sem

Design Model :
1. It consists of data, architectural, interface and procedural representation of the
software.
2. While preparing this model, the requirement specification must be used properly to
set the system constraints
Mental Model (System Model):
 The user’s mental model (system perception) is the image of the system that end
users carry in their heads.
For example, if the user of a particular word processor were asked to
describe its operation, the system perception would guide the response. Th e
accuracy of the description will depend upon the user’s profile (e.g., novices
would provide a sketchy response at best) and overall familiarity with
software in the application domain.
 A user who understands word processors fully but has worked with th e specific
word processor only once might actually be able to provide a more complete
description of its function than the novice who has spent weeks trying to learn
the system.
Implementation model:
 Implementation model gives the look and feel of the interface, coupled with all
supporting information (books, manuals, videotapes, help files) that describes
interface syntax and semantics.
 Matching implementation model with users mental model is necessary so that
user feel comfortable with developed system.

(ii) The Process:

CS8494 – Software Engineering 30

PIT – CSE II Year / IV Sem

The design process for user interfaces is iterative and can be represented using a spiral
model. The user interface design process encompasses four distinct framework activities:
1. environment analysis and modeling
2. Interface design
3. Interface implementation
4. Interface validation
Interface analysis: It focuses on the profile of the users who will interact with the system.
Skill level, business understanding, and general receptiveness to the new system are
recorded; and different user categories are defined. For each user category, requirements
are elicited.
Interface design: The goal of interface design is to define a set of interface objects and
actions (and their screen representations) that enable a user to perform all def ined tasks in
a manner that meets every usability goal defined for the system.
Interface construction normally begins with the creation of a prototype that enables usage
scenarios to be evaluated. As the iterative design process continues, a user interface tool kit
may be used to complete the construction of the interface.
Interface validation focuses on
(1) The ability of the interface to implement every user task correctly, to accommodate all
task variations, and to achieve all general user requirements;
(2) The degree to which the interface is easy to use and easy to learn, and
(3) The users’ acceptance of the interface as a useful tool in their work.

3.5.3 Interface Analysis

A key tenet of all software engineering process models is this: understand the problem
before you attempt to design a solution. In the case of user interface design, understanding
the problem means understanding
(1) The people (end users) who will interact with the system through the interface,
(2) The tasks that end users must perform to do their work,
(3) The content that is presented as part of the interface,
(4) The environment in which these tasks will be conducted.

User Analysis
User Interviews. The most direct approach, members of the software team meet with end
users to better understand their needs, motivations, work culture, and a myriad of other
issues. This can be accomplished in one-on-one meetings or through focus groups.
Sales input. Sales people meet with users on a regular basis and can gather information
that will help the software team to categorize users and better understand their
requirements.
Marketing input. Market analysis can be invaluable in the definition of market segments
and an understanding of how each segment might use the software in subtly diffe rent ways.

CS8494 – Software Engineering 31

PIT – CSE II Year / IV Sem

Support input. Support staff talks with users on a daily basis. They are the most likely
source of information on what works and what doesn’t, what users like and what they
dislike, what features generate questions and what features are easy to use.

Task Analysis and Modeling

The goal of task analysis is to answer the following questions:
 What tasks and subtasks will be performed as the user does the work?
 What specific problem domain objects will the user manipulate as work is
performed?
 What is the sequence of work tasks—the workflow?
 What is the hierarchy of tasks?
These techniques are applied to the user interface to answer the above questions
1. Use cases
2. Task elaboration.
3. Object elaboration
4. Workflow analysis
5. Hierarchical representation

3.5.4 Interface Design

Steps:
1. Using information developed during interface analysis define interface objects and
actions.
2. Define events (user actions) that will cause the state of the user interface to change.
3. Depict each interface state as it will actually look to the end user.
4. Indicate how the user interprets the state of the system from information provided
through the interface.

Design Issues
 Response time:System response time is measured from the point at which the user
performs some control action (e.g., hits the return key or clicks a mouse) until the
software responds with desired output or action.
 Help facilities.
 Will help be available for all system functions and at all times during system
interaction?
 How will the user request help?
 How will help be represented?
 How will the user return to normal interaction?
 Error handling.In general, every error message or warning produced by an
interactive system should have the following characteristics:

CS8494 – Software Engineering 32

PIT – CSE II Year / IV Sem

 The message should describe the problem in jargon that the user can
understand.
 The message should provide constructive advice for recovering from the error.
 Menu and command labeling.
 Will every menu option have a corresponding command?
 What form will commands take? Options include a control sequence (e.g., alt-P),
function keys, or a typed word.
 How difficult will it be to learn and remember the commands? What can be done
if a command is forgotten?
 Can commands be customized or abbreviated by the user?
 Application accessibility.Accessibility for users (and software engineers) who may
be physically challenged is an imperative for ethical, legal, and business reasons. A
variety of accessibility guidelines many designed for Web applications but often
applicable to all types of software—provide detailed suggestions for designing
interfaces that achieve varying levels of accessibility.
 Internationalization.Software engineers and their managers invariably
underestimate the effort and skills required to create user interfaces that
accommodate the needs of different locales and languages.

3.6 COMPONENT LEVEL DESIGN:

Designing Class based components

 Basic design principle
 Component level design guidelines
 Cohesion
 Coupling
Traditional Components
 Structured programming
Definition:
Component-level design, also called procedural design, occurs after data, architectural, and
interface designs have been established. The intent is to translate the design model into
operational software. But the level of abstraction of the existing design model is relatively
high, and the abstraction level of the operational program is low.
(i)Basic design principle
1. The Open-Closed Principle (OCP).
“A module [component] should be open for extension but closed for modification”
2. The Liskov Substitution Principle (LSP).
“Subclasses should be substitutable for their base classes”
3. Dependency Inversion Principle (DIP).
“Depend on abstractions. Do not depend on concretions”

CS8494 – Software Engineering 33

PIT – CSE II Year / IV Sem

4. The Interface Segregation Principle (ISP)

“Many client-specific interfaces are better than one general purpose interface”
5. The Release Reuse Equivalency Principle (REP).
“The granule of reuse is the granule of release”
6. The Common Closure Principle (CCP).
“Classes that change together belong together.”
7. The Common Reuse Principle (CRP).
“Classes that aren’t reused together should not be grouped together”
(ii)Component level design guidelines
Components
 Naming conventions should be established for components that are specified as part
of the architectural model and then refined and elaborated as part of the
component-level model.
 These names should be meaningful.
Interfaces
 Interfaces provide important information about communication and collaboration.
 For consistency, interfaces should flow from the left-hand side of the component
box.
Dependencies and Inheritance
 Dependencies from left to right.
 Inheritance from bottom (derived classes) to top (base classes).
 Component interdependencies should be represented via interfaces.
(iii)Cohesion
 Cohesion is an indication of the relative functional strength of a module.
 Cohesion is a natural extension of the information-hiding.
 A cohesive module performs a single task, requiring little interaction with other
components in other parts of a program.
Types of cohesion:
 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.

CS8494 – Software Engineering 34

PIT – CSE II Year / IV Sem

 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.
(iv)Coupling
 Coupling is an indication of interconnection among modules in a software structure.
 Coupling depends on the interface complexity between modules, the point at which
entry or reference is made to a module, and what data pass across the interface.
1. Data coupling
2. Content coupling
3. Common coupling
4. Control coupling
Content coupling: It occurs when one module makes use of data or control information
maintained in another module.
Common coupling: In this coupling common data or a global data is shared among
modules
Control coupling: the module shares related control data in control coupling.
Data coupling: Occurs when operations pass long strings of data arguments
3.6.2 Traditional Components
Structured programming:
There are three constructs of structured programming
1. Sequence - Sequence implements processing steps that are essential in the
specification of any algorithm.
2. Condition – Condition provides the facility for selected processing based on some
logical occurrence.
3. Repetition - Repetition allows for looping.

(i) Graphical Design Notation

 Flowchart
o A flowchart is quite simple pictorially. A box is used to indicate a processing step.
o A diamond represents a logical condition, and arrows show the flow of control.
o The sequence is represented as two processing boxes connected by a line
(arrow) of control.
o Condition, also called if-then-else, is depicted as a decision diamond that if true,
causes then-part processing to occur, and if false, invokes else-part processing.
o Repetition is represented using two slightly different forms.

CS8494 – Software Engineering 35

PIT – CSE II Year / IV Sem

Box Diagram
o It is also called as NS chart.
o The scope of the programming constructs such as repetition . if-then-else is well
defined.
o Arbitrary transfer of the control is not possible using the notation.
o Recursion can be represented conveniently.
o The scope of local and global data can be defined systematically.

CS8494 – Software Engineering 36

PIT – CSE II Year / IV Sem

(ii)Tabular Design Notation

o In many software applications, a module may be required to evaluate a complex
combination of conditions and select appropriate actions based on these conditions.
o Decision tables provide a notation that translates actions and conditions into a
tabular form.
o The table is difficult to misinterpret and may even be used as a machine-readable
input to a table-driven algorithm.

(iii)Program design language

o Program design language (PDL), also called structured English or pseudocode,
o It incorporates the logical structure of a programming language with the free -form
expressive ability of a natural language (e.g., English).
o Narrative text (e.g., English) is embedded within a programming language-like
syntax.
o Automated tools can be used to enhance the application of PDL.
o A basic PDL syntax should include constructs for
Component definition,
Interface description,

CS8494 – Software Engineering 37

PIT – CSE II Year / IV Sem

Data declaration,
Block structuring,
Condition constructs,
Repetition constructs,
Input-output (I/O) constructs.
o It should be noted that PDL can be extended to include keywords.

Part A
1. What are the elements of design model? [APR/MAY 2015] [R]
i. Data design
ii. Architectural design
iii. Interface design
iv. Component-level design

2. Define design process.[R]

Design process is a sequence of steps carried through which the requirements are
translated into a system or software model.

CS8494 – Software Engineering 38

PIT – CSE II Year / IV Sem

3. List the principles of a software design. [NOV/DEC 2014] [R]

i. The design process should not suffer from “tunnel vision”
ii. The design should be traceable to the analysis model.
iii. The design should exhibit uniformity and integration.
iv. Design is not coding.
v. The design should not reinvent the wheel.

4. What is the benefit of modular design? [R]

Changes made during testing and maintenance becomes manageable and they do not affect
other modules.

5. What is a cohesive module? [NOV/DEC 2014] [R]

A cohesive module performs only “one task” in software procedure with little inter action
with other modules. In other words cohesive module performs only one thing.

6. What are the different types of Cohesion? [R]

i. Coincidentally cohesive - The modules in which the set I\of tasks are related with
each other loosely.
ii. Logically cohesive – A module that performs the tasks that are logically related
with each other.
iii. Temporal cohesion – The module in which the tasks need to be executed in some
specific time span.
iv. Procedural cohesion – When processing elements of a module are related with
one another and must be executed in some specific order.
v. Communicational cohesion – When the processing elements of a module share the
data then such module is called communicational cohesive.

7. What is coupling? [APR/MAY 2012] [R]

Coupling is the measure of interconnection among modules in a program structure. It
depends on the interface complexity between modules.

8. What are the various types of coupling? [R]

i. Data coupling – The data coupling is possible by parameter passing or data
interaction.
ii. Control coupling – The modules share related control data in control coupling.
iii. Common coupling – The common data or a global data is shared among modules.
iv. Content coupling – Content coupling occurs when one module makes use of data
or control information maintained in another module.

CS8494 – Software Engineering 39

PIT – CSE II Year / IV Sem

9. What are the common activities in design process? [APR/MAY 2015] [U]
i. System structuring – The system is subdivided into principle subsystems
components and communications between these subsystems are identified.
ii. Control modeling – A model of control relationships between different parts of
the system is established.
iii. Modular decomposition – The identified subsystems are decomposed into
modules.

10. What are the benefits of horizontal partitioning? [U]

i. Software that is easy to test.
ii. Software that is easier to maintain.
iii. Propagation of fewer side effects.
iv. Software that is easier to extend.

11. What is vertical partitioning? [R]

Vertical partitioning often called factoring suggests that the control and work should be
distributed top-down in program structure.

12. What are the advantages of vertical partitioning? [APR/MAY 2012] [U]
i. These are easy to maintain changes.
ii. They reduce the change impact and error propagation.

13. What are the various elements of data design? [R]

i. Data object – The data objects are identified and relationship among various data
objects can be represented using ERD or data dictionaries.
ii. Databases – Using software design model, the data models are translated into
data structures and data bases at the application level.
iii. Data warehouses – At the business level useful information is identified from
various databases and the data warehouses are created.

14. List the guidelines for data design. [NOV/DEC 2014] [R]
i. Apply systematic analysis on data.
ii. Identify data structures and related operations.
iii. Establish data dictionary.
iv. Use information hiding in the design of data structure.
v. Apply a library of useful data structures and operations.

15. Name the commonly used architectural styles. .[R]

i. Data centered architecture.
ii. Data flow architecture.

CS8494 – Software Engineering 40

PIT – CSE II Year / IV Sem

iii. Call and return architecture.

iv. Object-oriented architecture. www.Vidyarthiplus.com
v. Layered architecture.

16. What is Transform mapping? [R]

The transform mapping is a set of design steps applied on the DFD in order to map
the transformed flow characteristics into specific architectural style.

17. What is a Real time system? [R]

Real time system is a software system in which the correct functionalities of the
system are dependent upon results produced by the system and the time at which
these results are produced.

18. What are the objectives of Analysis modeling?[U]

i. To describe what the customer requires.
ii. To establish a basis for the creation of software design.
iii. To devise a set of valid requirements after which the software can be built.

19. What is an Architectural design?[R]

The architectural design defines the relationship between major structural elements of the
software, the “design patterns” that can be used to achieve the requirements that have been
defined for the system.

20. What is data design?[U]

The data design transforms the information domain model created during analysis into the
data structures that will be required to implement the software.

21. What is interface design?[U]

The interface design describes how the software communicates within itself, with systems
that interoperate with it, and with humans who use it.

22. What is component level design?

The component level design transforms structural elements of the so ftware architecture
into a procedural description of software components.

23. What is software design?[U]

Software design is an iterative process through which the requirements are translated into
a “blueprint” for constructing the software.

CS8494 – Software Engineering 41

PIT – CSE II Year / IV Sem

24. What is user interface design?[U]

User interface design creates an effective communication medium between a human and a
computer.

25. What is system design?[R]

System design process involves deciding which system capabilities are to be implemented
in software and which in hardware.

26. What are data acquisition systems?[U]

Systems that collect data from sensors for subsequent processing and analysis are termed
as data acquisition systems. Data collection processes and processing processes may have
different periods and deadlines.

27. What is SCM? [APR/MAY 2012] [R]

Software Configuration Management is a set of activities carried out for identifying,
organizing and controlling changes throughout the lifecycle of computer software.

28. What is SCI? [APR/MAY 2012] [R]

Software Configuration Item is information that is carried as part of the software
engineering process.

29. List the principles of software design. [APR/MAY 2018] [R]

i. The design process should not suffer from “tunnel vision”

ii. The design should be traceable to the analysis model.
iii. The design should exhibit uniformity and integration.
iv. Design is not coding.
v. The design should not reinvent the wheel.

30. Define design pattern. [APR/MAY 2018] [U]

 A design pattern describes a design structure that solves a particular design
problem within a specific context and amid “forces” that may have an impact on the
manner in which the pattern is applied and used.
The intent of each design pattern is to provide a description that enables a designer to
determine
(1) Whether the pattern is applicable to the current work,
(2) Whether the pattern can be reused (hence, saving design time), and
(3) Whether the pattern can serve as a guide for developing a similar, but functionally or
structurally different pattern.

CS8494 – Software Engineering 42

PIT – CSE II Year / IV Sem

Part B:
1. Explain in detail the design concepts.[U]
2. Explain the design principles.
3. Explain the design steps of the transform mapping.
4. Explain in detail about the real time systems.
5. Explain in detail about SCM.
6. Explain about user interface design
7. Brief about real time executives
8. Explain about Data acquisition systems
9. Narrate User interface design [NOV/DEC 2014] [U]
10. Write note on monitoring and control system.
11. Explain the design model. [APR/MAY 2012] [U]
12. Explain in detail about the designing components. [APR/MAY 2012] [R]
13. What is cohesion? How is it related to coupling? Discuss in detail different types of cohesion
and coupling with suitable examples. [APR / MAY 2017][An]
14. What is software architecture? Describe in detail different types of software
architectures with illustrations. [APR / MAY 2017][U]
15. What is software architecture? Describe the different software architectural styles with
examples. [APR / MAY 2018][U]
16. Explain in detail types of cohesion and coupling with examples. [APR / MAY 2018][R]
17. What is the purpose of DFD? What are the components of DFD? Construct DFD for the
following system: [APR / MAY 2018][C]
An on – line shopping system for XYZ provides many services and benefits to its members
and staffs. Currently, XYZ staffs manually handle the purchasing information with the use of
basic office software such as Microsoft Office Word and Excel. It may results in having
mistaken easily and the process is very inconvenient. XYZ needs an online shopping system
at their Intranet based on the requirements of users. XYZ online shopping system has five
features:
i) To provide the user friendly online shopping cart function to members to
replace hardcopy ordering form.
ii) To store inventory and sales information in database to reduce the human
mistakes, increase accuracy and enhance the flexibility of information
processing.
iii) To provide an efficient inventory system which can help the XYZ staffs to gain
enough information to update the inventory.
iv) To be able to print invoices to members and print a set of summary reports for
XYZ’s internal usage.
v) To design the system that is easy to maintain and upgrade.
18.Consider the problem of determining the number of different words in an input file.
Carry out structured design by performing transform and transaction analysis construct
the structured chart. [APR / MAY 2018][C]

CS8494 – Software Engineering 43