Looping
Outline
What is Design?
• Software design work products
• Characteristics of good Design
Design Models
The FURPS quality attributes
Design Concepts
Design Principles
Architectural Design & Styles
Component Level or Procedural Design
Cohesion & Coupling
User Interface Design
Golden Rules of User Interface Design
Web Application Design
What is Design?
A meaningful representation of something to be built
It's a process by which requirements are translated into blueprint for
constructing a software
Blueprint gives us the holistic view (entire view) of a software
Desig Softwar
SRS n e
Proce Design
Problem ss Solution
Domain Domain
2
Software Design Process?
Software design is the most creative part of the
development process
Requirement Analysis Design Design
Engineering Model Engineering Model
Blue Print Process involves
for Diversification &
Convergence
Constructi
ng
Software 3
Software design workCharacteristics
products of good Des
For a design to be easily implemented in a The design must implement all
conventional programming language, the explicit requirements available
following items must be designed during in requirement model
the design phase. The design must accommodate
Different modules required to
all implicit requirements given
implement the design solution.
by stakeholders
Control relationship among the The design must be readable &
identified modules. The relationship is understandable
also known as the call relationship or
The good design should provide
invocation relationship among modules.
Interface among different modules. complete picture of the
The interface among different modules software, addressing the data,
identifies the exact data items exchanged functional and behavioral
among the modules. domains.
Algorithms required to implement
each individual module.
Data structures of the individual
modules.
4
Design Models It is creative activity. It is most critical activity during
system development
Analysis Models Has great impact on testing and maintenance
Scenario-based Design document forms reference for later ph
elements
•Use cases - text
•Use-case diagrams
•Activity diagrams
•Flow-oriented
Swimlane diagrams
elements
•Data flow diagrams Procedural
•Control-flow diagrams Design Procedural description of Software componen
•Behavioral
Processing narratives
Interface Design Human computer interaction
elements
•State diagrams
•Class-based
Sequence diagrams
Architectural DesignRelationship among structural elemen
elements Data/Class Design Data Structure
•Class diagrams
•Analysis packages
•CRC models
5
Design Models Cont.
Data Design Architectural Interface Design Procedural
Design Design
It
transforms
It transforms It defines the It defines how structural
class models relationship software elements of
into design between communicates software into
class major with systems & procedural
realization and structural with humans. description
prepares data elements of An interface of software
structure the software implies flow of components
(data design) information &
required to behavior.
6
Gentle overview of – F U R P S
“Quality is not an act, it is a habit.”— Aristotle
7
Quality attributes of software design The FURPS quality
attributes
F Functional U Usability
ity
assessed by feature set and assessed by considering human
capabilities of the program, factors, overall aesthetics,
generality of the functions & consistency & documentations
security of overall system
R Reliability P Performan
assessed by measuring frequency & ce
measured by processing speed,
severity of failures, accuracy of response time, resource
outputs, mean-time-of-failure consumption, throughput and
(MTTF), ability to recover from efficiency
S Supportab
errors
ility to extend program, adaptability, serviceability, testability,
Ability
compatibility
8
Design Concepts
The beginning of wisdom for a software engineer is to
recognize the difference between getting program to work
and getting it right
Fundamental Each design concept helps to answer the following
software questions
design 1. What criteria can be used to partition software
concepts into individual components?
provide the 2. How is function or data structure detail separated
necessary from a conceptual representation of the software?
framework 3. What uniform criteria define the technical quality
for of a software design?
“getting it
right.”
9
Important Software Design Concepts
Abstraction Architecture Pattern
Separation of Modularity Information
Concern Hiding
Refactoring Refinement Aspects
Functional Independence
Abstracti
on
At the highest level of abstraction, a solution is stated in broad terms using the language of
the problem environment. At lower levels of abstraction, a more detailed description of the
solution is provided. Finally, at the lowest level of abstraction, the solution is stated in a
manner that can be directly implemented.
Creation of procedural and data abstractions are done.
A procedural abstraction refers to a sequence of instructions that have a specific and limited
function. A data abstraction is a named collection of data that describes a data object.
10
Design Principles
Design process should not suffer from Design should be structured to
“tunnel vision” degrade gently, even when
Design should be traceable to the analysis abnormal data, events, or
model operating conditions are
Design should not reinvent the wheel Design is not coding, coding is
encountered
Design should “minimize the intellectual not design
Design should be assessed for
distance” between the software and the
quality as it is being created,
real world problem
Design should exhibit (present) uniformity not after the fact
and integration Design should be reviewed to
Design should be structured to accommodate minimize conceptual (semantic)
change errors
Reinvent the
Wheel
Coding Design
11
Design Process Rough View
Informal Design Informal More formal Finished
Outline Design Design Design
Design
Process
Requirements
Specification Design Activities
Architectural Abstract Interface Component Data Algorithm
Design Specification Design Design Structure Design
Design
System Software Interface Component Data Algorithm
Architecture Specification Specification Specification Structure Specification
Specificatio
Design Productn
12
Architectural Design
Software Architecture &
Design
Large systems are decomposed into subsystems
Sub-systems provide related services
Initial design process includes
Identifying sub-systems
Establishing a framework for sub-system control and
communication
Why to document the
Architecture?
Stakeholder Communication: High-level presentation of
system
System Analysis: Big effect on performance, reliability,
maintainability and other –ilities (Usability, Maintainability,
Scalability, Reliability, Extensibility, Security, Portability)
Large-scale Reuse: Similar requirements similar architecture
13
Software Architecture & Design
Architectural design represents the structure
of data and program components
It considers
Architectural style that the system will take
Structure and properties of the components that Marry in
constitute the system haste
Interrelationships that occur among all architectural
components of a system repent at
leisure
Representations of software architecture are an
enabler for communication between all True for
parties (stakeholders). Software
Architecture “constitutes a relatively small, Architecture
intellectually graspable model of how the system is Design
structured and how its components work together”
14
Architectural Styles
Each style describes a system category that encompa
Data-centered
architecture style
Data-flow architectures A set of components (Ex., a database,
computational modules) that perform a
Call and return function required by a system.
architecture A set of connectors that enable
Object-oriented
architecture “communication, coordination and
Layered architecture 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.
15
Data-centered architecture style
A data store (Ex., a file or
database) resides at the
center of this architecture and
is accessed frequently by
other components.
Client software accesses a
central repository.
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.
16
Data-flow architectures
This architecture is applied when
input data are to be transformed.
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.
17
Call and return architecture
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 as below.
1. 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 call architectures
The components of a main
program/subprogram architecture are
distributed across multiple computers on
a network.
18
Object-oriented architecture
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.
19
Layered architecture
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.
20
Component Level or Procedural Design
Component is a modular, deployable and
replaceable part of a system that encapsulates
implementation and exposes a set of interfaces.
Component-level design occurs after data,
architectural and interface designs have been
established.
Effective
programmers It defines the data structures, algorithms,
should not interface characteristics, and communication
mechanisms allocated to each component.
waste their
time in The intent is to translate the design model into
debugging, operational software.
they should But the abstraction level of the existing design
not introduce model is relatively high and the abstraction level of
bug to start the operational program is low.
with
21
Function Oriented Approach
The following are the features of a typical function-oriented design
approach:
1. A system is viewed as something that performs a set of functions.
Starting at this high level view of the system, each function is successively refined
into more detailed functions.
For example, consider a function create-new-library member
which essentially creates the record for a new member, assigns a unique membership
number to him, and prints a bill towards his membership charge.
This function may consist of the following sub-functions:
• assign-membership-number, create-member-record and print-bill
Each of these sub-functions may be split into more detailed sub-functions and so on.
The system state is centralized and shared among different
functions.
For Ex., data such as member-records is available for reference and updating to
several functions such as:
create-new-member
delete-member
update-member-record
22
Object Oriented Approach
In the object-oriented design approach, the system is viewed as
collection of objects (i.e., entities).
The state is decentralized among the objects and each object
manages its own state information.
For example, in a Library Automation Software,
each library member may be a separate object with its own data and functions to
operate on these data.
In fact, the functions defined for one object cannot refer or change data of other
objects.
Objects have their own internal data which define their state.
23
Cohesion & Coupling The primary
characteristics of
A good software design neat module
implies clean decomposition are
decomposition of the high cohesion and
problem into modules, and low coupling.
the neat arrangement of
these modules in a
A cohesive
hierarchy.
module A Coupling is
performs a single an indication of
task, requiring the relative
little interaction interdependence
with other among modules.
components.
24
Cohesion
Cohesion is an indication of the relative Classification of Cohesion
functional strength of a module.
A cohesive module performs a single
task, requiring little interaction with Coincidental Low
other components.
Logical
Stated simply, a cohesive module should
(ideally) do just one thing. Temporal
A module having high cohesion and low Procedural
coupling is said to be functionally Communicati
independent of other modules.
onal
Sequential
By the term functional independence, we
mean that a cohesive module performs Functional High
a single task or function.
25
Classification of Cohesion cont.
Coincidental Logical cohesion
cohesion
A module is said to be logically
A module is said to have coincidental cohesion, if it
performs a set of tasks that relate to each other very cohesive, if all elements of the
loosely.
module perform similar operations.
In this case, the module contains a random collection
of functions. For Ex., error handling, data input,
It is likely that the functions have been put in the data output, etc.
module out of pure coincidence without any thought or An example of logical cohesion is the
design. case where a set of print functions
For Ex., in a transaction processing system (TPS), the generating different output reports
get-input, print-error, and summarize-members are arranged into a single module In
functions are grouped into one module this case, the module contains a
At the outer layer, components service user random collection of functions.
interface operations.
26
Classification of Cohesion cont.
Temporal Procedural
cohesion cohesion
When a module contains functions that If the set of functions of the
are related by the fact that all the module are all part of a
functions must be executed in the same procedure (algorithm) in which
time span. certain sequence of steps have
For Ex., the set of functions responsible to be carried out for achieving
for initialization, start-up, shutdown of an objective
some process, etc. For Ex., the algorithm for
Communicational decoding a message.
cohesion
If all functions of the module refer to the same data structure
For Ex., the set of functions defined on an array or a stack.
27
Classification of Cohesion cont.
Sequential
cohesion
If the elements of a module form the parts of sequence, where the
output from one element of the sequence is input to the next.
For Ex., In a Transaction Processing System, the get-input, validate-input,
sort-input functions are grouped into one module.
Functional
cohesion
If different elements of a module cooperate to achieve a single function.
For Ex., A module containing all the functions required to manage
employees’ pay-roll exhibits functional cohesion.
28
Coupling
Coupling between two modules is a Classification of Coupling
measure of the degree of
interdependence or interaction between
the two modules. Low
Data
A module having high cohesion and low
coupling is said to be functionally
independent of other modules. Stamp
If two modules interchange large
amounts of data, then they are highly Control
interdependent.
The degree of coupling between two modules Common
depends on their interface complexity.
The interface complexity is basically Content High
determined by the number of types of
parameters that are interchanged while
invoking the functions of the module.
29
Classification of Coupling Cont.
Data coupling Stamp coupling
Two modules are data coupled, if they This is a special case (or extension)
communicate through a parameter. of data coupling
Two modules (``A'' and ``B'') exhibit
An example is an elementary (primal)
stamp coupling if one passes
data item passed as a parameter directly to the other a composite
between two modules, e.g. an integer, data item - such as a record (or
a float, a character, etc. structure), array, or (pointer to) a list
or tree.
This occurs when ClassB is
Control coupling declared as a type for an argument
If data from one module is used to direct the
of an operation of ClassA
order of instructions execution in another.
An example of control coupling is a flag set in one
module and tested in another module
30
Classification of Coupling Cont.
Common
coupling
If data from one module is used to direct the order of instructions
execution in another.
An example of control coupling is a flag set in one module and tested in
another module.
Content
coupling
Content coupling occurs when one component secretly modifies data
that is internal to another component.
This violets information hiding – a basic design concept
Content coupling exists between two modules, if they share code.
31
User Interface Design
Golden Rules of User Interface Design
Place the User in Reduce the User’s Memory
Control Load
Make the Interface Consistent
32
Golden Rules of User Interface Design Cont.
Place the User in
Control
During a requirements-gathering session for a major new information system, a
key user was asked about.
Following are the design principles that allow the user to maintain control:
Define interaction modes in a way that does not force a user into
unnecessary or undesired actions.
rovide 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.
33
Golden Rules of User Interface Design Cont.
Reduce the User’s
Memory
The moreLoad
a user has to remember, the more error-prone the interaction with
the system will be.
Following are the design principles that enable an interface to reduce the user’s
memory load:
Reduce demand on short-term memory.
Establish meaningful defaults Define shortcuts that are
intuitive
ual layout of the interface should be based on a real-world metaphor
Disclose information in a progressive fashion
34
Golden Rules of User Interface Design Cont.
Make the Interface
Consistent
The interface should present and acquire information in a consistent
fashion.
Following are the design principles that help make the interface consistent
Maintain consistency across a family of
applications
If past interactive models have created user
expectations, do not make changes unless
there is a compelling (convincing) reason
to do so
35
User Interface Analysis and Design Models
User profile model – Established by a software engineer
Establishes the profile of the end-users of the system
based on age, gender, physical abilities, education, cultural background, motivation, goals,
and personality.
Design model – Created by a software engineer
Derived from the analysis model of the requirements.
Incorporates data, architectural, interface, and procedural representations of the software.
Implementation model – Created by the software implementers
Consists of the look and feel of the interface combined with all supporting information
(books, videos, help files) that describe system syntax and semantics.
User's mental model – Developed by the user when interacting with the
application
Often called the user's system perception.
Consists of the image of the system; that users carry in their heads.
The role of the interface designer is to merge these
differences and derive a consistent representation of the
interface.
36
Web Application Design
Design for WebApp encompasses technical and
nontechnical activities that include:
Establishing the look and feel of the WebApp
Defining the overall architectural structure
Developing the content and functionality that
reside within the architecture
Planning the navigation that occurs within the
WebApp
37
Web App Interface Design
The objectives of a WebApp interface Design pyramid for WebApps
are to
Establish a consistent window into
the content and functionality
provided by the interface.
Guide the user through a series of
interactions with the WebApp.
Organize the navigation options
and content available to the user
Interface
Design
One of the challenges of interface design for WebApps
is the nature of the user’s entry point.
38
Design pyramid for WebApps Cont.
Aesthetic Content Design Architecture
Design Design
It is tied to the goals established for
Also called graphic design, Generate content a WebApp, the content to be
is an artistic endeavor and design the presented, the users who will visit,
(offer) that complements representation for and the navigation that has been
the technical aspects of established.
content to be used
WebApp design. within a WebApp.
Component-Level Navigation
Design
Modern WebApps deliver increasingly sophisticated processing functions that Design
Define navigation
Perform localized processing to generate content and pathways that enable
navigation capability in a dynamic fashion users to access
Provide computation or data processing capability WebApp content and
that are appropriate for the WebApp’s business domain functions.
Provide sophisticated database query and access
Establish data interfaces with external corporate systems
39