CS8494 SOFTWARE ENGINEERING Unit-3

CS8494 – Software Engineering
III Year / V Semester

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.

SOFTWARE DESIGN
 Software design is a model of software which
translates the requirements into finished software
product.
 Software design model consists of 4 designs:
 Data/class Design
Architectural Design
Interface Design
Component Design

SOFTWARE DESIGN
 Analysis model:
 Scenario based elements
 Class based elements
 Behavioral elements
 Flow oriented elements.

SOFTWARE DESIGN
 Translating Analysis -> Design

Software Design
 Data/class design - Created by transforming the
analysis model class-based elements into classes and
data structures required to implement the software
 Architectural design - defines the relationships among
the major structural elements of the software, it is
designed from the class-based elements and flow-
oriented elements of the analysis model.

Software Design
 Interface design - describes how the software
elements, hardware elements, and end-users
communicate with one another, - analysis
model scenario-based elements, flow-oriented
elements, and behavioral elements.

Software Design
 Why design is so important?
 It provides us with representation of software that can be
assessed for quality.
Only way that can accurately translate a customer’s
requirements into a finished software product.
It serves as foundation for all software engineering
activities.
Without design difficult to assess: Risk , Test, Quality

Design Process
 S/w design is an iterative process through
which requirements are translated into a
“blueprint” for constructing the s/w.
As design iteration occur, subsequent
refinement leads to design representation at
much lower levels of abstraction

Design Process
 Characteristics of Good Design:
 The good design should implement all the
requirements specified by the customer.
 The design must implement all of the explicit
requirements contained in the analysis model, and it
must accommodate all of the implicit requirements
desired by the customer.

Design Process
 Characteristics of Good Design:
 The design should be simple enough so that the
software can be understood easily by the developers,
testers and customers.
 The design should provide a complete picture of the
software, addressing the data, functional, and
behavioral domains from an implementation
perspective.

Design Process
 Quality Guideline:
 The design architecture should be created using
following issues:
 The design should be created using architectural styles and
patterns.
 The implementation of design should be evolutionary, so
that testing can be performed at each phase of
implementation.

Design Process
 In the design the data, architecture, interfaces
and components should be clearly represented.
 The design should be modular.
 The data structure should be appropriately
chosen for the design of specific problem.

Design Process
 The components should be used in the design so
that functional independency can be achieved in
the design.
 The interfaces in the design should be such that
the complexity between the connected
components of the system gets reduced.

Design Process
 Quality Attributes (FURPS Model):
 Functionality – It can be checked by assessing
the set of features and capabilities of the
functions.
 Usability – It can be assessed by knowing the
usefulness of the system.

Design Process
 Quality Attributes (FURPS Model):
 Reliability – A measure of frequency and
severity of failure.
 Performance – The response of the system.
 Supportability – To adopt the enhancement or
changes made in the software.

Design Concepts
The software design concept provides a
framework for implementing the right
software.

Design Concepts
Abstraction:
 At the highest level of abstraction – a solution
is stated in broad terms
At lower level of abstraction – a more detailed
description of the solution is provided

Design Concepts
Abstraction – Types:
 Procedural Abstraction:
 Sequence of instructions in the specific function.
 Functionality of procedure is mentioned by its
implementation details are hidden.
 Ex: Search the record

Design Concepts
Abstraction – Types:
 Data Abstraction:
 collection of data that describes a data object.
 Search the record – record is the data

Design Concepts
Modularity:
 Software is divided into separately named and
addressable components, sometimes called
modules, which are integrated to satisfy problem
requirement.
 Modularity is the single attribute of software that
allows a program to be intellectually manageable.

Design Concepts
Modularity:
 It leads to a “divide and conquer” strategy. – it is easier
to solve a complex problem when you break into a
manageable pieces.
 Refer fig. that state that effort (cost) to develop an
individual software module does decrease if total
number of modules increase.
 However as the no. of modules grows, the effort (cost)
associated with integrating the modules also grows.

Design Concepts
Modularity – Criteria:
 Modular decomposability: A design method
provides a systematic mechanism for
decomposing the problem into sub-problems.
 Modular Composability: It enables existing
design components to assembled into s new
system.

Design Concepts
Modularity – Criteria:
 Modular Understandability: A module can be
understood as a standalone unit.
 Modular Continuity: Changes to individual modules.
 Modular protection: Effects are constrained within the
module.

Design Concepts
Architecture:
 Software architecture suggest the overall
structure of the software and the ways in which
that structure provides conceptual integrity for
a system

Design Concepts
Architecture – Models:
 Structural Model- represent architecture as an organized
collection of components
 Framework model – shows the architectural framework and
corresponding applicability.
 Dynamic model – address behavior of the program
architecture and indicating how system or structure
configuration may change as a function.

Design Concepts
Architecture – Models:
 Process Model – focus on design of the business or
technical process that the system must accommodate.
 Functional models – used to represent the functional
hierarchy of a system.

Design Concepts
Refinement:
 Refinement is a process of elaboration
 The architecture of a program is developed by
successively refining levels of procedural detail.
 Refinement causes the designer to elaborate on the
original statement, providing more and more detail as
each successive refinement (elaboration) occurs.

Design Concepts
Pattern:
 It acts as a design solution for a particular problem
occurring in specific domain.
 Pattern can be usable
 Pattern can be used for current work
 Pattern can be used to solve similar kind of problem
with different functionality.

Design Concepts
Information Hiding:
 It is the important property of modular design.
 The modules are designed in such a way that
information contained in one module cannot be
accessible to the other module.
 Only limited amount of information can be passed to
other module

Design Concepts
Information Hiding:
 The intent of information hiding is to hide the details of
data structure and procedural processing behind a module
interface.
 It gives benefits when modifications are required during
testing and maintenance because data and procedure are
hiding from other parts of software, unintentional errors
introduced during modification are less

Design Concepts
Functional Independence:
 It can be achieved by developing the functional
modules with single-minded approach.
 Independent modules are easier to maintain with
reduced error propagation.
 Benefit: To achieve effective modularity
 Qualitative criteria – Cohesion and Coupling

Design Concepts
Functional Independence – Cohesion:
 The information hiding can be done.
 It performs only “one task” in software
procedure with little interaction with other
modules.

Design Concepts
 Coincidentally cohesive: The set of tasks are related
with each other modules loosely.
 Logically cohesive: A module that performs the tasks
that are logically related with each other.
 Temporal cohesive: The module in which the tasks
need to be executed in some specific time span.

Design Concepts
 Procedural cohesive: when processing elements
of a module are related with one another and must
be executed in some specific order.
 Communicational cohesion: when processing
elements of a module share the data.

Design Concepts
Functional Independence – Coupling:
 It represents how the modules can be “connected” with
other module or with the outside world.
 It is a measure of interconnection among modules in a
program structure.
 It depends on the interface complexity between modules.
 The goal is to strive for lowest possible coupling among
modules in software design.

Design Concepts

Design Concepts
 Data Coupling: It is possible by parameter passing or data
interaction.
 Control coupling: It shares related control data
 Common coupling: common data or a global data is shared
among the modules
 Content coupling: It occurs when on module makes use of
data or control information maintained in another module.

Design Concepts
Refactoring:
 For simplifying the design without changing the
function or behavior.
 “The process of changing a software system in
such a way that the external behavior of the
design do not get changed, however the internal
structure gets improved. ”

Design Concepts
Refactoring – Benefits:
 The redundancy can be achieved.
 Inefficient algorithms can be eliminated
 Inaccurate data structures can be removed or
replaced.

Design Concepts
 Design Classes:
 The classes that describe some elements of problem
domain, focus on various aspects of problem from user’s
point of view.
 To refine the analysis classes by providing the detail
design, so that further implementation can be done easily.
 To create new set of classes for implementing the
infrastructure of the software.

Design Concepts
Design Classes – Types:
 User interface class: A visual representation of
the HCI.
 Business Domain class: Identify the attributes
and service that are needed to implement some
elements of business domain.

Design Concepts
 Process Class: It implements lower level
business abstractions used by the business
domain.
 Persistent Class: represent the data store.

Design Concepts
 System Class: responsible for software
management and control functions that are
used for system operation.
 Characteristics: Complete and efficient, High
cohesion and low coupling.

Design Model
 Data design elements
 The data design element produced a model of data that
represent a high level of abstraction.
This model is then more refined into more implementation
specific representation which is processed by the computer
based system.
The structure of data is the most important part of the
software design.

Design Model
Architectural design elements
 The architecture design elements provides us overall
view of the system.
The architectural design element is generally
represented as a set of interconnected subsystem that
are derived from analysis packages in the requirement
model.

Design Model
Architectural design elements-Sources
 The information about the application domain to built
the software.
Requirement model elements like data flow diagram or
analysis classes, relationship and collaboration
between them.
The architectural style and pattern as per availability.

Design Model
Interface design elements:
 The interface design elements for software
represents the information flow within it and out of
the system.
They communicate between the components
defined as part of architecture.

Design Model
Interface design elements – Elements:
 The user interface - GUI
The external interface to the other systems, networks
etc.
The internal interface between various components –
Ex: Classes can communicate with each other by
operations or by passing messages

Design Model
 Component level diagram elements:
 The component level design for software is similar to the
set of detailed specification of each room in a house.
 It describes the internal details of the each software
component.
 The processing of data structure occurs in a component
and an interface which allows all the component
operations.

Design Model
Component level diagram elements:
 The UML diagram is used to represent the
processing logic.

Design Model
Deployment level design elements:
 It shows the software functionality and subsystem
that allocated in the physical computing
environment which support the software.

Design Model
Deployment level design elements:

Design Heuristic
Evaluate the first iteration of the program
structure to reduce the coupling and improve
cohesion:
 Exploding and imploding modules

Design Heuristic
Attempt to minimize the structures with high
fan-out and strive for fan-in as depth increases:
 Fan-out: number of immediate subordinates to the
module
 Fan-in: number of immediate relations the module
have.

Design Heuristic
Keep scope of the effect of a module within
the scope of control of that module:
 Module ‘A’ should not affect the module ‘b’

Design Heuristic
Evaluate the module interfaces to reduce
complexity and redundancy and improve
consistency.
 Define module whose function is predictable but
avoid modules that are too restrictive.
 Strive for controlled entry modules by avoiding
pathological connections.

Introduction to Architectural Design
 A design created to represent the data and
program components that are required to build the
computer based systems.
 It considers the system’s structure and properties
of the system components.
 The person who is responsible to design –
Software Architect.

 Software Architecture:
“A structure of systems which consists of various
components, externally visible properties of these
components and the inter-relationship among these
components”

 Software Architecture:
 To establish the overall structure of software
system.
 The link between design specification and actual
design process.

 Software Architecture – Structural Partitioning:
 Horizontal partitioning:
 It defines separate branches of the modular hierarchy
for each major program function.
 It defines three partitions—input, data transformation
(often called processing) and output.

 Horizontal partitioning – Benefits:
 software that is easier to test
software that is easier to maintain
propagation of fewer side effects
software that is easier to extend

 Software Architecture – Structural
Partitioning:
 Vertical partitioning: It suggests the control
and work should be distributed top-down in
program structure

 Vertical partitioning:
 Top-level modules should perform control functions
and do little actual processing work.
 Low-level modules in the structure should be the
workers, performing all input, computation, and output
tasks.

Data Design
 The model of the data that is represented at
the high level of abstraction.
Elements:
 Data Object: Use ER diagram or Data Dictionary
 Databases
 Data warehouses

Data Design
 Guideline for data design:
 Apply systematic analysis on data
 Identify the data structures and related operations
 Establish data dictionary
 Define the low level design decisions until late in
the design process

Data Design
 Guideline for data design:
 Use information hiding in the design of the data
structures
 Apply a library of useful data structures and
operations
 Use a software design and programming to support
data specification and abstraction

Architectural Style
It is a pattern for creating the system
architecture for given problem.
Components: It performs a function required
by a system. Ex: a database, computational
modules, clients and servers.

Architectural Style
Connectors: It enables “communication, co-
ordinations and cooperation” among components.
 Constraints that define how components can be
integrated to form the system.
 Semantic models that enable a designer to
understand the overall properties of a system.

Architectural Style
Data-centered architecture:

Architectural Style
 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 without
any change in data.

Architectural Style
 It posses the property of interchangeability.
 Any component from the architecture can be
replaced by a new component without affecting the
working of other components.
 The data can be passed among components.

Architectural Style
 Data Flow architecture – Pipe and Filter:
When input data are to be transformed through a series of
computational components into output data.

Architectural Style
 Data Flow architecture – Pipe and Filter:
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 (i.e. upstream, downstream)
and is designed to expect data input of a certain form, and
produces data output (to the next filter) of a specified form.
The filter does not require knowledge of the working of its
neighboring filters.

Architectural Style
 Data Flow architecture – Batch Sequential:
 If the data flow degenerates into a single line of
transforms, it is termed batch sequential.

Architectural Style
 Call and return architecture:

Architectural Style
 Call and return architecture:
 Architecture style enables a software designer (system
architect) to achieve a program structure that is relatively
easy to modify and scale.
 Main/sub program architecture: 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

Architectural Style
Object-oriented architecture:
The object-oriented paradigm, like the abstract data type
paradigm from which it evolved, emphasizes the bundling of
data and methods to manipulate and access that data (Public
Interface).
Components of a system summarize data and the operations that
must be applied to manipulate the data.
Communication and coordination between components is
accomplished via message passing

Architectural Style
Layered Architecture:

Architectural Style
 A number of different layers are defined, each
accomplishing operations that progressively become closer
to the machine instruction set.
At the outer layer, components examine user interface
operations.

Architectural Style
 At the inner layer, components examine operating system
interfacing.
Intermediate layers provide utility services and application
software functions.

Architectural Patterns
 An approach for handling behavioural characteristics of
software systems.
 Domains:
 Concurrency: Handling multiple tasks in parallel.
 Persistence: The data used in earlier execution can be made
available further by storing it in files.
 Distribution: The system components communicate with each
other.

Architectural Design
 The design should define the external entities (other systems,
devices, people) that the software interacts with and the nature
of the interaction.
 This information can generally be acquired from the
requirements model and all other information gathered during
requirements engineering.
 The designer specifies the structure of the system by defining
and refining software components that implement each
archetype.

 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.

 Super ordinate systems : systems that use the target system as
part of some higher-level processing scheme.
 Subordinate systems: Systems that are used by the target system
and provide data or processing that are necessary to complete
target system functionality.
 Peer-level systems:Systems that interact on a peer-to- peer basis.
 Actors: entities (people, devices) that interact with the target
system by producing or consuming information.

 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.
 A relatively small set of entities is required to design even
relatively complex systems.
 For example, an archetype for a car: wheels, doors, seats,
engine In software engineering

 Defining Archetypes:
 Node : Represents a cohesive collection of input and
output elements.
 Detector : An abstraction that covers all sensing
equipment that feeds information into the target
system.

 Defining Archetypes:
 Indicator: An abstraction that represents all
mechanisms (e.g., alarm siren, flashing lights, bell)
for indicating that an alarm condition is occurring.
 Controller. An abstraction that describes the
mechanism that allows the arming (Supporting) or
disarming of a node

 Refining the Architecture into Components
 As the software architecture is refined into components.
 Analysis classes represent entities within the application
(business) domain that must be addressed within the
software architecture.
 In some cases (e.g., a graphical user interface), a
complete subsystem architecture with many components
must be designed.

 Refining the Architecture into Components
 External communication management
 Control panel processing
 Detector management
 Alarm processing

 Describing Instantiations of the System
The overall structure of the system is apparent, and the
major software components have been identified.
However, further refinement is still necessary.
 To accomplish this, an actual instantiation of the
architecture is developed. It means, again it simplify by
more details.

Architectural Mapping using Data
Flow
 Transform flow: A sequence of paths which forms
transition in which input data are transformed into
output data.
 Transaction flow: The information flow in which
single data item triggers the overall information flow
along the multiple paths.

Flow
 Transform flow – Automated Railway Reservation
System:
 Registers for the using the system
 Make the train enquiry
 Can view the status of reservation by entering PNR number.
 Can make the reservations
 Can cancel the reservations

Flow
 Transform flow:
A collection of design steps using which a DFD
containing transform flow characteristics is mapped
into specific architectural style.

Flow
 Transform flow:
 Step 1: Review fundamental system model to
identify information flow:
 Obtained from System Specification and SRS.

Flow
 Transform flow - Step 2: Review and refine the data
flow diagram for software:

Flow
 Transform flow - Step 3: Determine if the DFD has
the transform or transaction flow characteristics:
 The information flow within the system is usually
represented as transform flow.
 If draw level 3 DFD for the process Make Reservation
then the transformation flow can be identified.

Flow – Step 3

Flow
 Transform flow - Step 4: Isolate the transform center
by specifying incoming and outgoing flow
boundaries:
 Separate out the incoming and outgoing flow boundaries
and the transform center can be identified.

Flow – Step 4

Flow
 Transform flow - Step 5: Perform first level factoring:
 It results in top down architecture.
 Top level – Perform decision making
 Low level – perform most input, computation and output.
 Middle level – perform some control and some amount
of work.

Flow
 Transform flow - Step 5: Perform first level
factoring:

Flow
 Transform flow
Step 6: Perform second level factoring:
 Individual bubble of DFD is mapped into appropriate
module within architecture

Flow
 Transform flow – Step 6: Perform second level
factoring:

Flow
 Transform flow
 Step 7: Refine the first iteration architecture using
design heuristics for improved software quality:
 Refined by applying the module independency
 It always follows “High Cohesion and Low Coupling”

Flow
 Transform flow - Step 7: Refine the first iteration
architecture using design heuristics for improved
software quality:

Flow
 Transaction flow :
 A single data item leads to one or more information flows.
 Each information flow specifies some distinct
functionality – Transaction center.

Flow
 Transaction flow – Design Steps:
 Review fundamental system model to identify information
flow.
 Review and refine the data flow diagram for software.
 Determine if the DFD has the transform or transaction
flow characteristics.

Flow
 Identify the transaction center and flow
characteristics along each of the action paths.
 To identify the location of transaction centre.
 Ex: User selects Book Ticket, Ticket Enquiry options.
There can be multiple action paths fanning out from the
transaction center.

Flow
 Transaction flow – Design Steps - Identify the
transaction center and flow characteristics along each
of the action paths.

Flow
 Map DFD into transaction processing structure:
 The identified transaction flow is mapped into an
architecture that contains an incoming branch and a
dispatcher branch.
 The corresponding bubbles on incoming path are mapped
into the appropriate modules.

Flow
 Transaction flow – Design Steps - Map DFD into
transaction processing structure:

Flow
 Factor and refine the transaction structure and
structure of each action path:
 Action path related sub structure is developed.

Flow
 Transaction flow – Design Steps- Factor and refine
the transaction structure and structure of each action
path:

Flow
Refine the first iteration architecture using design
heuristics for improved software quality :
 Refined by applying the module independency
 It always follows “High Cohesion and Low Coupling”

User Interface Design
 User interface design creates an effective
communication medium between a human and a
computer.
 Follows a set of interface design principles, design
identifies interface objects and actions and then
creates a screen layout that forms the basis for a user
interface prototype.

 Advantages:
 The user interface systems provide fast and intuitive
interactions to the user. The new user can easily operate the
system.
 As in user interface design, menus are provided, it avoids typing
mistakes.
 The user interface helps in simple data entry.
 It provides the flexibility in switching from one task to another.

 Golden Rules:
 Place the user in control
Reduce the user’s memory load
Make the interface consistent

 Golden Rules - Place the user in control:
Define interaction modes in a way that does not force
a user into unnecessary or undesired actions
An interaction mode is the current state of the interface.
 Provide for flexible interaction
 Because different users have different interaction
preferences, choices should be provided

 Allow user interaction to be interruptible and undoable.
Even when involved in a sequence of actions, the user should be
able to interrupt the sequence to do something else.
 Allow user to customize the interaction
Users often find that they perform the same sequence of
interactions repeatedly.

 Hide technical internals from the casual user
The interface should never require that the user interact at a level
that is “inside” the machine.
 The objects appearing on the screen should be interactive
with the user
User should be in position to adjust the object appearing on the
screen.

 Golden Rules - Reduce the User’s Memory Load:
 Reduce demand on short-term memory.
The interface should be designed to reduce the requirement
to remember past actions and results.
 Establish meaningful defaults
a “reset” option should be available, enabling the
redefinition of original default values.

 Golden Rules - Reduce the User’s Memory Load:
Define shortcuts that are intuitive
Shortcuts are required in the user interface
 The visual layout of the interface should be realistic
It helps a causal user to handle the system with ease.
 Disclose the information gradually
 The interface should be organized hierarchically.

 Golden Rules - Make the Interface Consistent:
 The interface should present and acquire information in a
consistent fashion.
 All visual information is organized according to a design standard that
is maintained throughout all screen displays.
 Input mechanisms are constrained to a limited set that are used
consistently throughout the application
 Navigating from task to task are consistently defined and implemented

 Allow the user to put the current task into a meaningful
context.
A user interface with proper indicators
 Maintain consistency across a family of applications.
A set of applications (or products) should all implement the same
design rules so that consistency is maintained for all interaction.

 If certain standards are maintained in previous model
of application do not change it until and unless it is
necessary.
 Once a particular interactive sequence has become a de
facto standard (e.g., the use of alt-S to save a file)

 Models:
 User model — To understand the user who is using the
system.
 The profile of all end users of the system ( Considering
Age, Gender, Educational and cultural background)
 Users: Novice, Knowledgeable and intermittent and
Knowledgeable and frequent

 Models:
 Design Model –Data, Architectural, Interface and
Procedural representation of the software.
 Requirement specification must be used properly to
set the system constraints.

 Models:
 Mental Model – The representation of what user
thinks about the system?
 If the user is knowledgeable then more complete
description of the system can be obtained that of
novice user.

 Models:
 Implementation Model – It generates the look and
feel of interface.
 User can feel comfortable with the developed system

User Interface Design – The Process
 Activities:
 Environment analysis and modeling
 Interface Design
 Implementation
 Interface validation

 Activities - Environment analysis and modeling:
 Factors:
 User profile is analysed to understand the user and to elicit the
requirements.
 The tasks that are required to carry out desired functionality
are identified and analysed.
 Environment which involves the physical work environment.

 Activities – Interface Design: All the interface
objects and corresponding actions of each task are
defined.
 Implementation: Creation of prototype using which
the interface scenarios can be evaluated.
 Validation: To validate the interface for its correct
performance.

 Interface Analysis:
 Interface analysis means understanding
The people (end-users) who will interact with the system
through the interface;
The tasks that end-users must perform to do their work,
The content that is presented as part of the interface
The environment in which these tasks will be conducted.

 Interface Analysis:
User Analysis – what the user wants from the UI:
 User interviews: Representatives from software team
meet the end user to better understand the user needs,
motivations and many other issues.
 Meeting are conducted for this purpose.

 Interface Analysis - User Analysis – what the user
wants from the UI:
 Sales input:
 Sales people interact with the users regularly and collect
the information
 Users are categorized in groups and thereby their
requirements are better understood.

wants from the UI:
 Marketing input:
 To understand the usage of software

wants from the UI:
 Support input:
 Support staff keeps a regular interaction with the user
interaction for knowing the certain things likings and
dislikes of the user.

 User Analysis:
 Are users trained professionals, technician, clerical, or
manufacturing workers?
What level of formal education does the average user have?
Are the users capable of learning from written materials or have
they expressed a desire for classroom training?
Are users expert typists or use of keyboard?
What is the age range of the user community?

 User Analysis:
 Will the users be represented predominately by one gender?
How are users compensated for the work they perform?
Do users work normal office hours or do they work until the job
is done?
Is the software to be an integral part of the work users do or will
it be used only occasionally?
What is the primary spoken language among users?

 Task Analysis and modeling:
 What work will the user perform in specific circumstances?
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?

 Task Analysis and modeling – Techniques:
 Use cases: It describes interaction between user and
system.
It shows how the end user performs specific work
related task.

 Task Elaboration – Stepwise refinement of the processing task
is done.
 Object Elaboration – Extract information about the physical
objects. These objects are further classified into classes.
 Workflow analysis defines how a work process is completed
when several people (and roles) are involved. Ex: Swimlane
Diagram.

 Hierarchical representation – The task hierarchy for each
user type should be specified.
 Fill reservation Form:
 Personal Info: Specify name, Specify age, Desired source city,
Desired destination city, Date and time
 Reservation details: Age, Source City, Destination City, Seat
numbers, Type of reservation and Name of the train.

 Analysis of Display Content:
 The display contents can be spreadsheets, pictures, a graph
and audio or video files.
 The format and nature of the display contents are
considered.

 Are different types of data assigned to consistent
geographic locations on the screen.
 Can the user customize the screen location for content?
 Is proper on-screen identification assigned to all content?
 If a large report is to be presented, how should it be
partitioned for ease of understanding?

 Will mechanisms be available for moving directly to summary
information for large collections of data.
 Will graphical output be scaled to fit within the bounds of the
display device that is used?
 How will color to be used to enhance understanding?
How will error messages and warning be presented to the user?

 Analysis of work environment:
 There may be interactive presentation of the information,
proper lighting, good display height, easy keyboard access,
proper sitting arrangement.

 Interface Design:
 Using information developed during interface analysis, define
interface objects and actions (operations).
Define events (user actions) that will cause the state of the user
interface to change. Model this behavior.
Depict each interface state as it will actually look to the end-user.
Indicate how the user interprets the state of the system from
information provided through the interface.

 User interface Design Pattern:
Pattern Description
TopLevelNavigation It enables direct navigation to any of the system’s
major functions
Fill-in-the-Blanks Allow alphanumeric data to be entered in a “text box.”
SortableTable Display a long list of records that can be sorted by
selecting a toggle mechanism for any column label.
SimpleSearch ability to search a website
Wizard the completion of the task through a series of simple
window displays.
ShoppingCart Provides a list of items selected for purchase
ProgressIndicator Provides an indication of progress when an operation
takes longer than n seconds

 Design Issues:
 System Response Time:
 It is measured from the point at which the user performs
some control action until the software responds with
desired output or action.
 Characteristics – Length: Amount of time taken by the
system to respond
 Variability: the deviation from average response time

 Design Issues:
 Help facilities:
 User manuals
 Online help facilities that enable a user to get a question
answered or resolve a problem without leaving the interface

 Design Issues -Error handling –Message Characteristics:
 The message should describe the problem in terminology that
the user can understand
 There should be some useful message along with error in order
to recover from the error.
 There should be some audible or visual cue along with the error
message.
 There should not be any negative impact of error on the user.
 The wording of the error should be carefully used

 Design Issues:
 Menu and command labeling:
 The typed command was once the most common mode of
interaction between user and system software
 The use of window-oriented, point-and pick interfaces has
reduced reliance on typed commands

 Design Issues:
 Application accessibility:
 Software engineers must develop a mechanism by which
the most frequently required applications must be availed
easily.
 Accessibility for users who may be physically challenged
is an imperative for ethical, legal, and business reasons.

 Design Issues:
 Internationalization:
 “globalized” software - user interfaces should be designed to
accommodate a generic core of functionality that can be
delivered to all who use the software.
 Localization features enable the interface to be customized for a
specific market.
 The Unicode standard has been developed for characters and
symbols.

Component Level Design
 OMG UML Specification defines a component as
“a modular, deployable, and replaceable part of a
system that encapsulates implementation and exposes
a set of interfaces”

 Designing Class based Components
 Component is represented as a part of architectural model. It
collects the information about the system as a part of analysis
model.
 OO View: a component contains a set of collaborating classes
 The detailed description of attributes, operations and interfaces
of these infrastructure classes is required during the system
building.

 Design Principles:
 Open-Closed Principle: A module should be open for extension but
closed for modification.
 Liskov Substitution Principle: Subclasses should be substitutable
for their base classes.
 Dependency Inversion Principle: Depend on abstractions. Do not
depend on concrete component.
 Interface Segregation Principle: Many client-specific interfaces are
better than one general purpose interface

 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.

 Design Guidelines:
 Interfaces - provide important information about
communication and collaboration.
 Dependencies and Inheritance:
 Dependencies from left to right - inheritance from
bottom(derived classes) to top(base classes)

Structured Programming
 Three constructs:
 Sequence: A linear processing of the statements
 Condition: To test the logical conditions
 Repetition: To denote the looping
 Advantages:
 reduces program complexity
 enhances readability, testability and maintainability

 Graphical Design Notations – Flow Chart:

 Graphical Design Notations –Box Diagram:
 Nassi-Shneiderman charts, N-S charts, or Chapin charts –
Characteristics:
 Functional domain (that is, the scope of repetition or if-then-else) is
well defined and clearly visible as a pictorial representation
 Arbitrary transfer of control is impossible
 The scope of local and/or global data can be easily determined
 Recursion is easy to represent

 Graphical Design Notations –Box Diagram:
 Nassi-Shneiderman charts, N-S charts, or Chapin
charts:

 Tabular Design Notations:
Decision tables provide a notation that translates actions and conditions
into a tabular form.
 Sections:
 The upper left-hand quadrant contains a list of all conditions.
 quadrant contains a list of all actions
 The right-hand quadrants form a matrix that indicates condition
combinations
 the corresponding actions that will occur for a specific combination

List all actions that can be associated with a specific procedure
(or module).
List all conditions (or decisions made) during execution of the
procedure.
Associate specific sets of conditions with specific actions,
eliminating impossible combinations
Define rules by indicating what action(s) occurs for a set of
conditions

 Program Design Language:
 It is a pseudo code or structured English.
 to translate the design into the programming language.

 Program Design Language:
 Easy to combine with source code
Can be represented in great detail
Machine readable, no need for graphics input
Graphics can be generated from PDL
Enables declaration of data as well as procedure
Easier to review and maintain

CS8494 SOFTWARE ENGINEERING Unit-3

More Related Content

What's hot

Similar to CS8494 SOFTWARE ENGINEERING Unit-3

More from SIMONTHOMAS S

Recently uploaded

CS8494 SOFTWARE ENGINEERING Unit-3