Unit 2 - Software Design

18CSC206J –Software Engineering and Project Management
UNIT – II
Software Design
Disclaimer:
The lecture notes have been prepared by referring to many books and notes prepared by the teachers. This document does not claim
any originality and cannot be used as a substitute for prescribed textbooks.
Requirements Analysis
• Requirements analysis
– specifies software’s operational characteristics
– indicates software's interface with other system elements
– establishes constraints that software must meet
• Requirements analysis allows the software engineer (called an analyst or
modeler in this role) to:
– elaborate on basic requirements established during earlier requirement
engineering tasks
– build models that depict user scenarios, functional activities, problem classes
and their relationships, system and class behavior, and the flow of data as it is
transformed.
2
A Bridge
system
description
analysis
model
design
model
3
Domain Analysis
Software domain analysis is the identification, analysis, and
specification of common requirements from a specific
application domain, typically for reuse on multiple projects
within that application domain . . . Object-oriented domain
analysis is the identification, analysis, and specification of
common, reusable capabilities within a specific application
domain, in terms of common objects, classes,
subassemblies, and frameworks . . .
Donald Firesmith
4
Domain Analysis
• Define the domain to be investigated.
• Collect a representative sample of
applications in the domain.
• Analyze each application in the sample.
• Develop an analysis model for the objects.
5
Elements of Requirements Analysis
6
Scenario-Based Modeling
“[Use-cases] are simply an aid to defining what exists
outside the system (actors) and what should be
performed by the system (use-cases).” Ivar Jacobson
(1) What should we write about?
(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description?
7
Use-Cases
• a scenario that describes a “thread of usage” for
a system
• actors represent roles people or devices play as
the system functions
• users can play a number of different roles for a
given scenario
8
Developing a Use-Case
• What are the main tasks or functions that are performed by the
actor?
• What system information will the the actor acquire, produce or
change?
• Will the actor have to inform the system about changes in the
external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
9
Use-Case Diagram
S af e Ho m e
Acce s s cam e ra
s u rve illan ce via t h e cam e ras
In t e rn e t
Co n fig u re Safe Ho m e
s ys t e m p aram e t e rs
h o m e o wn e r
Se t alarm
10
Activity Diagram
Supplements the use
case by providing a
graphical e nt e r pa ssword
a nd use r ID
representation of the
flow of interaction valid pass wor ds / ID invalid pas swor ds/ ID
within a specific se le c t ma jor func t ion prompt for re e nt ry
scenario
ot her f unct ions
m ay als o be
select ed
input t r ies r em ain
se le c t surve illa nc e
no input
t r ies r em ain
t hum bnail views s elect a specif ic cam er a
se le c t spe c ific
se le c t c a me ra ic on
c a me ra - t humbna ils
vie w c a me ra out put

in la be lle d window
prompt for
a not he r vie w
exit t his f unct ion

s ee anot her cam er a
11
Swimlane Diagrams
home owne r c a m e ra i n t e rf a c e
Allows the modeler to

represent the flow of e nt e r p a s s word
activities described by the a nd us e r ID
use-case and at the same

time indicate which actor valid p as swo r d s/ ID
(if there are multiple

in valid
p as s wo r d s / ID
s e le c t m a jor fu nc t ion
actors involved in a o t h er f u n ct io n s p ro m pt for re e nt ry
specific use-case) or
m ay als o b e
s elect ed
analysis class has

in p u t t r ies
s e le c t s urve illa nc e r em ain
responsibility for the n o in p u t

t r ies r em ain
action described by an
activity rectangle t h u m b n ail views s elect a s p ecif ic cam er a
s e le c t s pe c ific
s e le c t c a m e ra ic on
c a m e ra - t hu m bna ils
ge ne ra t e vide o
out pu t
vie w c a m e ra ou tpu t prom pt for

in la be lle d wind ow a no the r v ie w
exit t h is
f u n ct io n
s ee
an o t h er
cam er a
12
Data Modeling
• examines data objects independently of
processing
• focuses attention on the data domain
• creates a model at the customer’s level of
abstraction
• indicates how data objects relate to one
another
These slides are designed to accompany

Software Engineering: A Practitioner’s
13
Approach, 7/e (McGraw-Hill, 2009). Slides
What is a Data Object?
• a representation of almost any composite information that
must be understood by software.
– composite information—something that has a number of
different properties or attributes
• can be an external entity (e.g., anything that produces or
consumes information), a thing (e.g., a report or a display),
an occurrence (e.g., a telephone call) or event (e.g., an
alarm), a role (e.g., salesperson), an organizational unit
(e.g., accounting department), a place (e.g., a warehouse),
or a structure (e.g., a file).
• The description of the data object incorporates the data
object and all of its attributes.
• A data object encapsulates data only—there is no reference
within a data object to operations that act on the data.

14
Data Objects and Attributes
A data object contains a set of attributes that act as an aspect,
quality, characteristic, or descriptor of the object
object: automobile
attributes:
make
model
body type
price
options code

15
What is a Relationship?
• Data objects are connected to one another in
different ways.
– A connection is established between person and
car because the two objects are related.
• A person owns a car
• A person is insured to drive a car
• The relationships owns and insured to drive
define the relevant connections between
person and car.
• Several instances of a relationship can exist
• Objects can be related in many different ways
16
ERD Notation
One common form:
(0, m)
object relationship object
1 (1, 1) 2
attribute
Another common form:
object relationship object

1 2
(0, m) (1, 1)

17
Building an ERD
• Level 1—model all data objects (entities)

and their “connections” to one another
• Level 2—model all entities and
relationships
• Level 3—model all entities, relationships,
and the attributes that provide further
depth

18
The ERD: An Example
request
Customer places
for service
(1,1) (1,m)
(1,1)
standard (1,n) work
task table generates
order
(1,1) (1,1) (1,1)
selected work (1,w)
consists
from
(1,w) tasks of
(1,i)
materials lists

19
Class-Based Modeling
• Class-based modeling represents:
– objects that the system will manipulate
– operations (also called methods or services) that will
be applied to the objects to effect the manipulation
– relationships (some hierarchical) between the objects
– collaborations that occur between the classes that are
defined.
• The elements of a class-based model include
classes and objects, attributes, operations, CRC
models, collaboration diagrams and packages.
20
Identifying Analysis Classes
• Examining the usage scenarios developed as part
of the requirements model and perform a
"grammatical parse" [Abb83]
– Classes are determined by underlining each noun or
noun phrase and entering it into a simple table.
– Synonyms should be noted.
– If the class (noun) is required to implement a solution,
then it is part of the solution space; otherwise, if a
class is necessary only to describe a solution, it is part
of the problem space.
• But what should we look for once all of the
nouns have been isolated?
21
CRC Models
• Class-responsibility-collaborator (CRC) modeling
[Wir90] provides a simple means for identifying
and organizing the classes that are relevant to
system or product requirements. Ambler [Amb95]
describes CRC modeling in the following way:
– A CRC model is really a collection of standard index
cards that represent classes. The cards are divided into
three sections. Along the top of the card you write the
name of the class. In the body of the card you list the
class responsibilities on the left and the collaborators
on the right.
22
CRC Modeling
Class:
Class:
Description:
Class:
Description:
Class: FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera

23
Class Types
• Entity classes, also called model or business classes, are extracted
directly from the statement of the problem (e.g., FloorPlan and
Sensor).
• Boundary classes are used to create the interface (e.g., interactive
screen or printed reports) that the user sees and interacts with as the
software is used.
• Controller classes manage a “unit of work” [UML03] from start to finish.
That is, controller classes can be designed to manage
– the creation or update of entity objects;
– the instantiation of boundary objects as they obtain information from
entity objects;
– complex communication between sets of objects;
– validation of data communicated between objects or between the user and
the application.

24
Responsibilities
• System intelligence should be distributed across classes to
best address the needs of the problem
• Each responsibility should be stated as generally as possible
• Information and the behavior related to it should reside
within the same class
• Information about one thing should be localized with a single
class, not distributed across multiple classes.
• Responsibilities should be shared among related classes,
when appropriate.

25
Collaborations
• Classes fulfill their responsibilities in one of two ways:
– A class can use its own operations to manipulate its own attributes,
thereby fulfilling a particular responsibility, or
– a class can collaborate with other classes.
• Collaborations identify relationships between classes
• Collaborations are identified by determining whether a class can
fulfill each responsibility itself
• three different generic relationships between classes [WIR90]:
– the is-part-of relationship
– the has-knowledge-of relationship
– the depends-upon relationship

26
Composite Aggregate Class
Player
PlayerHead PlayerBody PlayerArms PlayerLegs

27
Associations and Dependencies
• Two analysis classes are often related to one
another in some fashion
– In UML these relationships are called associations
– Associations can be refined by indicating multiplicity
(the term cardinality is used in data modeling
• In many instances, a client-server relationship
exists between two analysis classes.
– In such cases, a client-class depends on the server-class
in some way and a dependency relationship is
established
28
Multiplicity
Wa ll
1 1 1
is used to build is used to build
1..* 0..* is used to build 0..*
Wa llSe g m e n t Win d o w Do o r

29
Dependencies
DisplayWindow Camera
<<access>>
{password}

30
Analysis Packages
• Various elements of the analysis model (e.g., use-cases, analysis classes)
are categorized in a manner that packages them as a grouping
• The plus sign preceding the analysis class name in each package indicates
that the classes have public visibility and are therefore accessible from
other packages.
• Other symbols can precede an element within a package. A minus sign
indicates that an element is hidden from all other packages and a #
symbol indicates that an element is accessible only to packages contained
within a given package.

31
Analysis Packages
p ackag e n ame
Environm e nt
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building Rule sOfThe Gam e
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction
Charact e rs
+Player
+Protagonist
+Antagonist
+SupportingRole

32
Requirements Modeling Strategies
• One view of requirements modeling, called structured analysis,
considers data and the processes that transform the data as separate
entities.
– Data objects are modeled in a way that defines their attributes and
relationships.
– Processes that manipulate data objects are modeled in a manner that
shows how they transform data as data objects flow through the
system.
• A second approach to analysis modeled, called object-oriented
analysis, focuses on
– the definition of classes and
– the manner in which they collaborate with one another to effect
customer requirements.

33
Approach, 7/e (McGraw-Hill 2009). Slides
Flow-Oriented Modeling
 Represents how data objects are transformed at they move through

the system
 data flow diagram (DFD) is the diagrammatic form that is used
 Considered by many to be an “old school” approach, but continues
to provide a view of the system that is unique—it should be used to
supplement other analysis model elements

34
The Flow Model
Every computer-based system is an

information transform ....
computer
input based output
system

35
Flow Modeling Notation
external entity
process
data flow
data store

36
External Entity
A producer or consumer of data
Examples: a person, a device, a sensor
Another example: computer-based

system
Data must always originate somewhere

and must always be sent to something

37
Process
A data transformer (changes input
to output)
Examples: compute taxes, determine area,

format report, display graph
Data must always be processed in some

way to achieve system function

38
Data Flow
Data flows through a system, beginning

as input and transformed into output.
base
compute
triangle area
height area

39
Data Stores
Data is often stored for later use.
sensor #
sensor #, type,
look-up location, age
sensor
report required data
type,
location, age
sensor number
sensor data

40
Data Flow Diagramming: Guidelines
• all icons must be labeled with meaningful

names
• the DFD evolves through a number of levels
of detail
• always begin with a context level diagram
(also called level 0)
• always show external entities at level 0
• always label data flow arrows
• do not represent procedural logic
41
Constructing a DFD—I
• review user scenarios and/or the
data model to isolate data objects
and use a grammatical parse to
determine “operations”
• determine external entities
(producers and consumers of data)
• create a level 0 DFD

42
Level 0 DFD Example
processing
user request requested
video
digital signal
video monitor
processor
video
source NTSC
video signal

43
Constructing a DFD—II
• write a narrative describing the

transform
• parse to determine next level
transforms
• “balance” the flow to maintain data
flow continuity
• develop a level 1 DFD
• use a 1:5 (approx.) expansion ratio
44
The Data Flow Hierarchy
a b
x P y level 0
c p2
a f
p1
p4 b
d 5
p3 e g
level 1

45
Flow Modeling Notes
• each bubble is refined until it does just
one thing
• the expansion ratio decreases as the
number of levels increase
• most systems require between 3 and 7
levels for an adequate flow model
• a single data flow item (arrow) may be
expanded as levels increase (data
dictionary provides information)

46
Process Specification (PSPEC)
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
47
DFDs: A Look Ahead
analysis model
Maps into
design model

48
Control Flow Modeling
• Represents “events” and the processes that
manage events
• An “event” is a Boolean condition that can be
ascertained by:
• listing all sensors that are "read" by the software.
• listing all interrupt conditions.
• listing all "switches" that are actuated by an operator.
• listing all data conditions.
• recalling the noun/verb parse that was applied to the
processing narrative, review all "control items" as possible
CSPEC inputs/outputs.
49
Control Specification (CSPEC)
The CSPEC can be:
state diagram
(sequential spec)
state transition table

combinatorial spec
decision tables
activation tables

50
Behavioral Modeling
• The behavioral model indicates how software will respond to
external events or stimuli. To create the model, the analyst
must perform the following steps:
• Evaluate all use-cases to fully understand the sequence of
interaction within the system.
• Identify events that drive the interaction sequence and understand
how these events relate to specific objects.
• Create a sequence for each use-case.
• Build a state diagram for the system.
• Review the behavioral model to verify accuracy and consistency.

51
State Representations
• In the context of behavioral modeling, two different characterizations of
states must be considered:
– the state of each class as the system performs its function and
– the state of the system as observed from the outside as the system performs
its function
• The state of a class takes on both passive and active characteristics
[CHA93].
– A passive state is simply the current status of all of an object’s attributes.
– The active state of an object indicates the current status of the object as it
undergoes a continuing transformation or processing.

52
State Diagram for the ControlPanel Class
t ime r < lo cke d Time
t ime r > lo cke d Time lo cke d
p as swo rd = in co rre ct
& n u mb e rOfTrie s < maxTrie s
re ad in g co mp arin g n u mb e rOfTrie s > maxTrie s

ke y h it
p as swo rd
e n t e re d do: va lida t e Pa s s w ord
p ass wo rd = co rre ct
se le ct in g
act iv at io n s u cce ss fu l

53
The States of a System
• state—a set of observable circum-stances
that characterizes the behavior of a system
at a given time
• state transition—the movement from one
state to another
• event—an occurrence that causes the
system to exhibit some predictable form of
behavior
• action—process that occurs as a
consequence of making a transition
54
Behavioral Modeling
• make a list of the different states of a system
(How does the system behave?)
• indicate how the system makes a transition
from one state to another (How does the
system change state?)
– indicate event
– indicate action
• draw a state diagram or a sequence diagram

55
Sequence Diagram
h o meo w n er co n t ro l p an el s ys t em ssen
enssoorsrs
s ys t em read in g
A
read y
p as sw o rd en t ered
req u es t lo o ku p
co mp arin g
res u lt
pa s s word = c orre c t
num be rOfTrie s > m a xTrie s req u es t act ivat io n
lo cked
t imer > lo cked Time

A
s elect in g
act ivat io n s u cces s fu l act ivat io n s u cces sfu l
Figure 8 .2 7 Se que nc e dia gra m (pa rt ia l) for Saf e Hom e s e c urit y func t ion

56
Writing the Software
Specification
Everyone knew exactly
what had to be done
until someone wrote it
down!
57
Patterns for Requirements Modeling
• Software patterns are a mechanism for capturing domain

knowledge in a way that allows it to be reapplied when a new
problem is encountered
– domain knowledge can be applied to a new problem within the same
application domain
– the domain knowledge captured by a pattern can be applied by analogy
to a completely different application domain.
• The original author of an analysis pattern does not “create” the
pattern, but rather, discovers it as requirements engineering work is
being conducted.
• Once the pattern has been discovered, it is documented

58
Discovering Analysis Patterns
• The most basic element in the description of

a requirements model is the use case.
• A coherent set of use cases may serve as the
basis for discovering one or more analysis
patterns.
• A semantic analysis pattern (SAP) “is a pattern
that describes a small set of coherent use cases
that together describe a basic generic
application.” [Fer00]
59
Requirements Modeling for WebApps
Content Analysis. The full spectrum of content to be provided by the
WebApp is identified, including text, graphics and images, video,
and audio data. Data modeling can be used to identify and describe
each of the data objects.
Interaction Analysis. The manner in which the user interacts with the
WebApp is described in detail. Use-cases can be developed to
provide detailed descriptions of this interaction.
Functional Analysis. The usage scenarios (use-cases) created as part of
interaction analysis define the operations that will be applied to
WebApp content and imply other processing functions. All
operations and functions are described in detail.
Configuration Analysis. The environment and infrastructure in which
the WebApp resides are described in detail.

60
When Do We Perform Analysis?
• In some Web situations, analysis and design merge.
However, an explicit analysis activity occurs when …
– the WebApp to be built is large and/or complex
– the number of stakeholders is large
– the number of Web engineers and other contributors is
large
– the goals and objectives (determined during
formulation) for the WebApp will effect the business’
bottom line
– the success of the WebApp will have a strong bearing on
the success of the business
61
The Content Model
• Content objects are extracted from use-cases
– examine the scenario description for direct and indirect
references to content
• Attributes of each content object are identified
• The relationships among content objects and/or
the hierarchy of content maintained by a WebApp
– Relationships—entity-relationship diagram or UML
– Hierarchy—data tree or UML

62
Data Tree
Ma rke t ingDe s c ript ion
Phot ogra ph
pa rt Numbe r
Te c hDe s c ript ion

pa rt Na me
c ompone nt Sc he ma t ic
pa rt Type
Vide o
de s c ript ion
pric e
Whole s a le Pric e
Re t a ilPric e
Fig u re 1 8 . 3 Da t a t re e fo r aS a fe Ho m e c o m p o n e n t

63
The Interaction Model
• Composed of four elements:
– use-cases
– sequence diagrams
– state diagrams
– a user interface prototype
• Each of these is an important UML notation
and is described in Appendix I

64
Sequence Diagram
:Produc t :Billof FloorPla n BoM
:Room :FloorPla n
Compone nt Ma t e ria ls Re pos it ory Re pos it ory
new cust o mer
d e sc rib e s
ro o m *
p la c e s ro o m
in f lo o r p la n
sa v e f lo o r p la n c o n f ig u ra t io n
se le c t s p ro d u c t c o m p o n e n t *
a d d t o Bo M
sa v e b ill o f m a t e ria ls
Figure 18.5 Se que nce diagram for use -case :se le ct Saf e Hom e com pone nt s
65
State Diagram
Va lida t ing use r Se le ct ing use r a ct ion
use rid se le c t ot he r func t ions
syst e m st a t us=“input re a dy” va lida t e d syst e m st a t us=“link re a dy”
se le ct “log-in” displa y msg = “e nt e ruse rid” displa y: na viga t ion choice s”
displa y msg =“e nt e r pswd”
pa ssword va lida t e d
e nt ry/ va lida t e d use r
e nt ry/ log-in re que st e d
n e w cu st o m e r do: link a s re quire d
do: run use r va lida t ion
e xit / use r a ct ion se le ct e d
e xit / se t use r a cce ss swit ch
c ust omiz a t ion c omple t e

se le c t e -c omme rc e (purc ha se ) func t iona lit y
se le c t c ust omiz a t ion func t iona lit y
ne xt se le ct ion
Sa ving floor pla n
Cust omiz ing se le ct de script ive
cont e nt syst e m st a t us=“input re a dy”
syst e m st a t us=“input re a dy” De fining room se le ct de script ive displa y: st ora ge indica t or
displa y: ba sic inst ruct ions cont e nt
room be ing de fine d syst e m st a t us=“input re a dy” e nt ry/ floor pla n sa ve se le ct e d
displa y: roomde f. window do: st ore floor pla n
e nt ry/ va lida t e d use r e xit / sa ve comple t e d
do: proce ss use r se le ct ion
e nt ry/ roomde f. se le ct e d
e xit / cust omiz a t ion t e rmina t e d a ll rooms do: run room que rie s
de fine d do: st ore room va ria ble s
e xit / room comple t e d
Building floor pla n se le ct de script ive

se le ct sa ve floor pla n
cont e nt
syst e m st a t us=“input re a dy”
se le ct e nt e r room in floor pla n displa y: floor pla n window
e nt ry/ floor pla n se le ct e d

do: inse rt room in pla ce
do: st ore floor pla n va ria ble s
e xit / room inse rt ion comple t e d
room inse rt ion comple t e d
Figure 1 8 .6 Pa rt ia l s t a t e dia gra m for n e w c u s t o m eintr e ra c t ion
66
The Functional Model
• The functional model addresses two
processing elements of the WebApp
– user observable functionality that is delivered by
the WebApp to end-users
– the operations contained within analysis classes
that implement behaviors associated with the
class.
• An activity diagram can be used to represent
processing flow
67
Activity Diagram
init ialize t ot alCos t
no c omp one nt s re ma in o nBo MList c ompo ne n t s re ma in on BoMList
invoke g et price and

calcShipping Cost quant it y
ret urns:
shipping Cost
lineCost =
price x quant it y
invoke
det erm ineDiscount
ret urns : dis count add lineCost t o

t ot alCost
d isc oun t >0

t ot alCost=
t ot alCost - dis count
d isc ou nt < = 0
t axTot al=
t ot alCos t x t axrat e
priceTot al =
t ot alCos t + t axTot al
+ shipping Cost
Figure 1 8 .7 Act ivit y dia gra m for c o m p u t e Pr i (c )e o p e r a t i o n

68
Topics
• Software Design Fundamentals
• Design Standards - Design Type
• Design Model – Architectural design, Software Architecture
• Software Design Methods
• Top Down, Bottom Up
• Module Division (Refactoring)
• Module Coupling
• Component Level Design
• User Interface Design
• Pattern Oriented Design
• Web Application Design
• Design Reuse
• Concurrent Engineering in Software Design
• Design Life-Cycle Management 69
Software Design
Introduction
• Software design is the process where the software architecture is built and
refined using the end user requirements.
• In the waterfall model, the software product will have a large number of parts
which can be designed separately from each other and later can be joined.
• If you need to break the software product design into many parts then either
top down approach or bottom up approach can be used.
• In top down approach, the software design for the entire product is built first
and later its parts are designed.
• In bottom up approach, the software product parts are designed first and later
they are joined to create design of the entire product.
• With each change request there will be a different version of the software
design.
• Maintaining these design versions through the development process is very
important.
• It is necessary to make sure that the right design is used for software
construction.
• Software design should be robust and should also be able to take change
requests without any problems.
Software Design
Introduction
• When a software product is incrementally built then the later versions of the
software design should be fully compatible with the original software design.
• There are many software design techniques available to make appropriate
software designs for the product being built.
• They include prototyping, structural models, object oriented design, entity
relationship models etc.
• Refactoring is a design technique which is used in iterative models.
• When the design become bulky after many iterations of development, it starts
getting crumbling against new features being added to the product.
• In such cases, the design is changed so that new factors of the features being
added are incorporated.
• Software design development can be likened to designing a physical product.
• Suppose a new car model is to be developed.
• The car design is broken down into separate components and in the end
assembling them will become a complete design for the car model.
• Various factors are considered during the design of the components.
Software Design
Introduction
• Suppose one factor to be considered is that during a car accident, the car body
should take most of the impact and the passengers should get the least impact,
so that injury to car passengers can be minimized during accidents.
• For this to happen, the car body should be made of material that can collapse
on impact and thus take most of the impact.
• So during design, when selecting the material of the car with safety in mind, the
body is one of the prime considerations.
• Similarly, an aerodynamic body helps in keeping the car from rolling over during
accidents and thus it is a prime safety factor that the car body should be
aerodynamic.
• During design, one consideration is also made that though each component is
developed separately, after assembly the components should work with each
other without any problems.
• That means assembling does not create any problems in the product itself.
• Similar considerations are also done when software products are designed.
Software Design
Introduction
• In fact, in designing software systems, consideration is given to things like how
well the system will be maintained during operation and how easily the system
will be actually developed and be tested.
• Software design is done using modeling languages like UML and using notation
methods like use cases and activity diagrams.
• We will learn all about software design considerations, workflows involved in
design, etc.
Software Design
Software Design Fundamentals
• When a building is constructed, a good foundation is laid out for the building, so
that the building will have a long lifespan and will not collapse.
• Similarly, it is given a strong and resilient structure, so that even in case of an
earthquake, it will not fall down.
• Similarly, software design provides the foundation and structure upon which the
software system is constructed.
• The design should provide a sound, resilient and scalable structure to support
the software system (Figure below-Characteristics of a good software design).
• In these days, most software systems are built incrementally.
• In the beginning, a software system may consist of only a few features.
• The feature set is expanded in future releases as and when it becomes
necessary to include them in the system.
• If proper structure is not provided from the very beginning, the addition of
these new features will make the system unstable.
• To deal with this problem, a technique called refactoring is used on these agile
projects where incremental software development is done.
Software Design
Software Design Fundamentals
• Some of the design techniques that help make good software design include
open architecture, modularity and scalability.
• The current trend of service-oriented architecture (SOA) has also helped
tremendously in changing the design concepts.
• SOA is built on Web services and loose coupling of software components.
• The asynchronous messaging method of SOA is a vital aspect for developing
Web-based applications.
Software Design
Design Standards
• If design standards are implemented on a project, then it will help in
streamlining activities that are involved during the software design phase.
• Some industry standards for software design include operator interface
standards, test scenarios, safety standards, design constraints and design
tolerances.
Design Types
• Software design on any project may consist of many work products, which
together can be termed the software design for the software product that will
be built during the software project.
• Some examples include prototypes, structural models, object-oriented design,
systems analysis and entity relationship models.
Software Design
Design Types
• A good software design not only ensures a smooth transition to the
development phase but also ensures that the software product has a good shelf
life during operation.
• So what are the keys to a good design? A good design should start from the
most possible abstract architecture of the software product often termed as
"high level design".
• Subsequent transition of the abstract design should lead to platform-specific
design often termed as "low level design".
• The platform-specific design or low level design will be in terms of a good
database model and a good application model (Figure above - Software design
techniques).
• Over the years, many software design techniques have evolved with the
evolution of different programming paradigms.
• Starting with the early procedural programming paradigms, programming has
evolved into present day "service-oriented architecture".
• Software design has kept the pace with these evolving paradigms, and thus it
has also been evolving. So, we have early structural design paradigms to modern
day SOA designs. Let us discuss some of these design techniques.
Software Design
Design Types – Prototypes
• Prototyping is cheap and fast.
• It also gets a buy in from customer at an early stage of the project.
• If not, a full prototype of the application, a partial prototype can contribute to
win over the customer.
• There are many automatic code generation tools that allows to drag and drop
some components on screens, and the tool generates the code and makes a
working prototype of the application that can be demonstrated to the customer.
• A miscommunication or misunderstanding between the customer and the
project team gets cleared once the difference of opinion are sorted out early on
during the prototype demonstration sessions.
• This greatly helps in reducing the risks of not meeting customer expectations.
• In any case, customers do not care about internal workings of the application.
• They are always concerned about what the application screens look like and
how the application behaves with different kind of inputs and events.
Software Design
Design Types – Prototypes
• The downside about prototypes is that many customers assume the prototype is
the fully functional application and later on wonder why the application is taking
so much time in development when they saw the working demonstration so
early in the project.
• Customer expectations become difficult to manage in such instances.
• Prototypes can only show the user interface screens.
• When complex logic is involved in developing applications, that logic cannot be
depicted in prototypes, as program logic is mostly not visible and cannot be
developed in prototypes.
• Starting with the early procedural programming paradigms, programming has
evolved into present day "service-oriented architecture".
Software Design
Design Types – Design Reuse
• For large software products, the design can be broken into many design parts
representing each module of the product.
• Each of these design modules contain a lot of design information that can be
represented as design components.
• Many details inside these design components can be repeated inside different
components.
• If a standard method of representing the same information can be used for
these components, then it is possible to use these pieces of information in many
components by reusing them.
• It will reduce effort in designing the product.
• This method of design reuse is known as internal design reuse.
• A more potent design reuse is becoming available after the advent of the open
source paradigm and SOA.
• In the case of open source, the design reuse is in fact a case of copying existing
design and then using it exactly as it is or modifying it to suit the needs.
• But in the case of SOA, there is no copying or modifying a software design.
• The existing design is utilized as it is.
Software Design
Design Types – Design Reuse
• In addition, there is no process of buying the application/component whose
design is required.
• There is simply buying a service from the owner of the application/component
and using that service in building the application.
• The owner of that application/component publishes full details as to how to
integrate with the application for the according application/component.
• The full interface details are provided by the owner.
• Using this information, the design is done for the application.
• There is an assumption that as if the application/component provided as a
service is available and the application uses this application/component.
• SOA is indeed leading to a reuse model that is going to transform the world of
computing and the lives in years to come.
Software Design
Design Types – Structural Models
• Most software applications are built using components.
• At the bottom are the smallest units of functions and procedures in a software
application.
• These functions are contained within classes or packages depending on the
programming language used.
• Many classes together build a component.
• Components in turn make modules. Modules in turn make the complete
application.
• For ease of working, maintenance, and breaking development tasks to allocate
to group of developers, it is essential that an application is broken down into
manageable parts.
• Breaking into parts for an application can best be done using a structural
analysis.
• From requirement specifications, a feature set is made to decide what features
will be in the application.
• This feature set is analyzed and broken down into smaller sets of features, which
will go into different modules.
• This is represented in a structural model of the application.
Software Design
Design Types – Systems Analysis
• System analysis is the process of finding solutions in the form of a system
designed from the inputs coming from business needs.
• The fundamental question addressed in system analysis is whether a business
scenario can be converted into a software application, so that the user can use
the software application to do his routine business tasks.
• For instance, a person may want to access his bank account using an Internet
connection to the online web site of the bank.
• This scenario calls for many things that are involved in the whole chain of
objects and events.
• The system analysis will be concerned with user activities, what objects on the
web site act with user activities, how these objects interact with the underlying
software system of the bank, and how connections are made between the user
and the website and between the website and the bank system.
• System analysis will analyze all these things.
• Based on the analysis, a system model can be made that will be used in
developing the application.
Software Design
Design Types – Object-oriented Design
• It has always been difficult to represent business entities and business
information flow in a software model.
• With object-oriented design, this problem was solved.
• Business entities are represented as objects in the object- oriented software
design.
• Properties of these objects are made in such a way that they are similar to the
properties of the business entities.
• These objects are instantiated from classes in the form of child classes.
• These child classes inherit all the properties of their parent class, and they can
have some more properties of their own in addition.
• So if we have a group of similar objects with somewhat different properties,
then we can implement classes in such a way that a base parent class has child
classes with different properties.
• This concept aligns very much to the real-world scenarios.
• Object-oriented design takes input from use cases, activity diagrams, user
interfaces etc.
Software Design
Design Types – Entity Relationship Models
• Entity relationship models are one of the ways to represent business entities
and their relationships to each other through diagrams.
• These diagrams are used for creating databases and database tables.
• How many tables are needed to fulfill the needs of the software product, how
these tables are related to each other, and in what form data are to be kept
inside these tables, etc. are decided through these diagrams.
• With object-oriented modeling, it is possible to correlate each object with a
corresponding database object.
• This kind of representation helps to make a clean database design.
Design Model
Analysis Model -> Design Model
Co m p o n e n t -
s c e na rio - ba s e d f lo w- o rie nt e d Le v e l D e s ig n
e le me nt s e le me nt s
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams proces sing narratives
swim lane diagrams
In t e rf a c e D e s ig n
Ana lysis Mode l
A rc h it e c t u ra l D e s ig n
c la ss- ba se d b e ha v io ra l
e le me nt s e le me nt s
class diagrams s tate diagrams
analysis packages s equence diagrams
CRC models D a t a / Cla s s D e s ig n
collaboration diagrams
Desig n Mo d el
Design Model
Design Model Elements Importance of software
• Data Elements design : Quality Design
• Data model  Data structures
• Data model  Database architecture
• Architectural Elements
• Application domain
• Analysis classes, their relationships, collaborations and behaviors are
transformed into design realizations
• Patterns and “styles”.
• Interface Elements
• User Interface (UI)
• External interfaces to other systems, devices, networks or other producers
or consumers of information.
• Internal interfaces between various design components
• Component Elements – Transform structural elements of the software
architecture into a procedural desc of software components
• Deployment Elements
Design Model
Analysis Model -> Design Model
hig h
a n a ly s is m o d e l
c la s s dia gra ms
a na lys is pa c ka ge s
us e -c a s e s - t e xt c la s s dia gra ms
Re quire m e nt s :
CRC mode ls us e -c a s e dia gra ms c ons t ra int s
a na lys is pa c ka ge s
c olla bora t ion dia gra ms
a c t ivit y dia gra ms CRC mode ls int erope rabilit y
da t a flow dia gra ms s w im la ne dia gra ms c olla bora t ion dia gra ms t a rge t s and
c ont rol-flow dia gra ms c olla bora t ion dia gra ms da t a flow dia gra ms
proc e s s ing na rra t ive s s t a t e dia gra ms c ont rol-flow dia gra ms
c onf igura t ion
s e que nc e dia gra ms proc e s s ing na rra t ive s
s t a t e dia gra ms
s e que nc e dia gra ms
de s ign c la s s re a liz a t ions

s ubs ys t e ms
c olla bora t ion dia gra ms t e c hnic a l int e rfa c e c ompone nt dia gra ms
de s ign c la s s re a liz a t ions
de s ign de s ign c la s s e s
s ubs ys t e ms
Na viga t ion de s ign a c t ivit y dia gra ms
c olla bora t ion dia gra ms
GUI de s ign s e que nc e dia gra ms
c ompone nt dia gra ms
d e s ig n m o d e l de s ign c la s s e s
re f ine m e nt s t o: a c t ivit y dia gra ms
re f ine m e nt s t o: s e que nc e dia gra ms
c ompone nt dia gra ms
de s ign c la s s re a liz a t ions de s ign c la s s e s
s ubs ys t e ms a c t ivit y dia gra ms
lo w c olla bora t ion dia gra ms s e que nc e dia gra ms de ployme nt dia gra ms
archit ect ure int erface co m po nent -level deplo ym ent -level
elem ent s elem ent s elem ent s elem ent s
p ro c e s s d ime ns io n
Architectural Design
• The overall structure of the software and the ways in which that structure
provides conceptual integrity for a system.
Structural properties
• This aspect of the architectural design representation defines the components
of a system (e.g., modules, objects, filters) and the manner in which those
components are packaged and interact with one another.
• For example, objects are packaged to encapsulate both data and the processing
that manipulates the data and interact via the invocation of methods.
Extra-functional properties
• The architectural design description should address how the design architecture
achieves requirements for performance, capacity, reliability, security,
adaptability, and other system characteristics.
Families of related systems
• The architectural design should draw upon repeatable patterns that are
commonly encountered in the design of families of similar systems.
• In essence, the design should have the ability to reuse architectural building
blocks.
Software Architecture
Why Architecture?
• The architecture is not the operational software.
• Rather, it is a representation that enables a software engineer to:
(1) Analyze the effectiveness of the design in meeting its stated requirements,
(2) Consider architectural alternatives at a stage when making design changes is
still relatively easy, and
(3) Reduce the risks associated with the construction of the software.
Architecture - Significance
• Representations of software architecture are an enabler for communication
between all parties (stakeholders) interested in the development of a computer-
based system.
• The architecture highlights early design decisions that will have a profound
impact on all software engineering work that follows and, as important, on the
ultimate success of the system as an operational entity.
• Architecture “constitutes a relatively small, intellectually graspable mode of
how the system is structured and how its components work together”.
Software Architecture
Architectural Descriptions
• The IEEE Computer Society has proposed IEEE-Std-1471-2000, Recommended
Practice for Architectural Description of Software-Intensive System,
– To establish a conceptual framework and vocabulary for use during the
design of software architecture,
– To provide detailed guidelines for representing an architectural description,
and
– To encourage sound architectural design practices.
• The IEEE Standard defines an architectural description (AD) as a “a collection of
products to document an architecture.”
– The description itself is represented using multiple views, where each view
is “a representation of a whole system from the perspective of a related
set of [stakeholder] concerns.”
Architectural Genres
• Genre implies a specific category within the overall software domain.
• Within each category, there are a number of subcategories.
– For example, within the genre of buildings, there are following general
styles: houses, condos, apartment buildings, office buildings, industrial
building, warehouses, and so on.
– Within each general style, more specific styles might apply.
– Each style would have a structure that can be described using a set of
predictable patterns.
Architectural Styles
• Each style describes a system category that encompasses:
(1) a set of components (e.g., a database, computational modules) that perform
a function required by a system,
(2) a set of connectors that enable “communication, coordination and
cooperation” among components,
(3) constraints that define how components can be integrated to form the
system, and
(4) semantic models that enable a designer to understand the overall properties
of a system by analyzing the known properties of its constituent parts.
Architectural Styles –
1. Data Centered Architecture
• 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.
• Figure below illustrates a typical data-centered style.
Architectural Styles – Data Centered Architecture
• 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.
• A variation on this approach transforms the repository into a "blackboard" that
sends notifications to client software when data of interest to the client
changes.
Architectural Styles – 2. Data Flow Architecture
• 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.
Architectural Styles – Data Flow Architecture
• 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 workings of its
neighboring filters.
• If the data flow degenerates into a single line of transforms, it is termed batch
sequential.
• This structure accepts a batch of data and then applies a series of sequential
components (filters) to transform it.
Architectural Styles – 3. Call and Return Architecture
• This architectural style enables you to achieve a program structure that is
relatively easy to modify and scale.
• A number of sub-styles exist within this category:
• Main program/subprogram architectures: This classic program structure
decomposes function into a control hierarchy where a "main program invokes a
number of program components that in turn may invoke still other components.
The figure below illustrates an
Architectural Styles – Call and Return Architecture
• Remote procedure call architectures: The components of a main
program/subprogram architecture are distributed across multiple computers on
a network.
4. Architectural Styles – 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 are accomplished via
message passing.
5. Architectural Styles – Layered Architecture
• The basic structure of a layered architecture is illustrated below.
• 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.
• Once requirements engineering uncovers
the characteristics and constraints of
the system to be built, the architectural
style and/or combination of patterns
that best fits those characteristics and
constraints can be chosen.
Architectural Patterns
• Concurrency—applications must handle multiple tasks in a manner that
simulates parallelism
– Operating system process management pattern
– Task scheduler pattern
• Persistence—Data persists if it survives past the execution of the process that

created it. Two patterns are common:
– A database management system pattern that applies the storage and
retrieval capability of a DBMS to the application architecture.
– An application level persistence pattern that builds persistence features into
the application architecture.
• Distribution— the manner in which systems or components within systems

communicate with one another in a distributed environment
– A broker acts as a ‘middle-man’ between the client component and a server
component.
Architectural Context
• The software must be placed into context
– The design should define the external entities (other systems, devices,
people) that the software interacts with and the nature of the interaction.
• A set of architectural archetypes should be identified.
• The designer specifies the structure of the system by defining and refining
software components that implements each archetype.
• The below diagram illustrates Architectural context diagram for the SafeHome
security function.
Safehome Internet-based
Product system
control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses
uses
sensors sensors
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 are required to design even
relatively complex systems.
Cont rolle r
• In relation to the SafeHome home
security function, it is necessary to
define the following archetypes: com m un icat e s wit h
• Node – represents a cohesive collection

of input and output elements of the Node
home security function.

• Detector – An abstraction that
encompasses all sensing equipment
that feeds information into the target
De t e ct or Indicat or
system.
• The diagram illustrates the UML
relationships for SafeHome security
function archetypes. Figure 10.7 UML re lat ions hips for Safe Hom e se curit y funct ion arche t ype s
(adapt e d from [BOS00])
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 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.
• Each of these archetypes is depicted using UML notation as shown in above
figure.
• Recall that the archetypes form the basis for the architecture but are
abstractions that must be further refined as architectural design proceeds.
• For example, Detector might be refined into a class hierarchy of sensors.
Component Structure
• As the software architecture is refined into components, the structure of the
system begins to emerge.
• But how are these components chosen? In order to answer this question, it is
necessary to begin with the classes that were described as part of the
requirements model.
Safe Home
Execut ive
Funct ion
sele ct ion
Ext e rn al
Co mmu n icat io n
Man ag e me n t
Securit y Surveillance Hom e

ma na gem ent
GUI Int e rnet

Int erfac e
Cont rol de t e c t or a la rm
pa ne l ma na ge me nt proc e s s ing
proc e s s ing
Component Structure
• The figure above illustrates the overall architectural structure for SafeHome with
top-level components.
• These analysis classes represent entities within the application (business)
domain that must be addressed within the software architecture.
• Hence, the application domain is one source for the derivation and refinement
of components.
• Another source is the infrastructure domain. The architecture must
accommodate many infrastructure components that enable application
components but have no business connection to the application domain.
• In regards to the SafeHome home security function example, the set of top-level
components might be defined to address the following functionality:
1. External communication management – coordinates communication of the
security function with external entities such as other Internet-based systems
and external alarm notification.
2. Control panel processing – manages all control panel functionality.
3. Detector management – coordinates access to all detectors attached to the
system.
4. Alarm processing – verifies and acts on all alarm conditions.
Refined Component Structure
• The architectural design that has been modeled to this point is still relatively
high level.
• The context of the system has been represented, archetypes that indicate the
important abstractions within the problem domain have been defined, the
overall structure of the system is apparent, and the major software
components have been identified.
• However, further refinement (recall that all design is iterative) is still necessary.
• To accomplish this, an actual instantiation of the architecture is developed.
• The figure below illustrates an instantiation of the SafeHome architecture for
the security system.
• Components shown in figure above are elaborated to show additional details.
• For example, the detector management component interacts with a scheduler
infrastructure component that implements polling of each sensor object used by
the security system.
• Similar elaboration is performed for each of the components represented in
figure above.
Refined Component Structure
SafeHo me
Executive
Ext e rna l
Communic a t ion
Ma na ge me nt
Security
GUI Internet
Interface
Co n t ro l d e t e ct o r alarm
p an e l m an ag e m e n t p ro ce s sin g
p ro ce ss in g
Ke y p ad
p ro ce ss in g phone
sch e d u le r
co m m u n icat io n
CP d isp lay
fu n ct io n s
alarm
s e nnso
se so r
se nssoorrr
sseennnso
se sorr
se n s or r
ses enns so
or
Analyzing Architectural Design
1. Collect scenarios.
2. Elicit requirements, constraints, and environment description.
3. Describe the architectural styles/patterns that have been chosen to address
the scenarios and requirements:
• Module view
• Process view
• Data flow view
4. Evaluate quality attributes by considering each attribute in isolation.
5. Identify the sensitivity of quality attributes to various architectural attributes
for a specific architectural style.
6. Critique candidate architectures (developed in step 3) using the sensitivity
analysis conducted in step 5.
Architectural Complexity
• The overall complexity of a proposed architecture is assessed by considering
the dependencies between components within the architecture.
– Sharing dependencies represent dependence relationships among
consumers who use the same resource or producers who produce for the
same consumers.
– Flow dependencies represent dependence relationships between producers
and consumers of resources.
– Constrained dependencies represent constraints on the relative flow of
control among a set of activities.
ADL
• Architectural description language (ADL) provides a semantics and syntax for
describing a software architecture
• Provide the designer with the ability to:
– Decompose architectural components
– Compose individual components into larger architectural blocks and
– Represent interfaces (connection mechanisms) between components.
An Architectural Design Method
• Customer customer requirements
requirements "four bedrooms, three baths,
• Deriving program lots of glass ..."
architecture
architectural design
Partitioning the Architecture
• The “horizontal” and “vertical” partitioning are required
Why Partitioned Architecture?

• Results in software that are easier to test
• Leads to software that are easier to maintain
• Results in propagation of fewer side effects
• Results in software that are easier to extend
Horizontal Partitioning
• Define separate branches of the module hierarchy for each major function
• Use control modules to coordinate communication between functions
Vertical Partitioning – Factoring
• Design so that decision making and work are stratified
• Decision making modules should reside at the top of the architecture
Software Design Methods
Top Down
• In the top-down approach, the top structure of the product is conceived and
designed first.
• Once the structure is perfected, components that will make the product are
designed.
• Once the major components are designed, the features that make the
component are designed (Figure below – Top-down Software Design).
• Apart from the functional consideration for making the structure, nonfunctional
considerations are also considered from the top level for example, how the
security, performance, usability, aspects will be provided in the product.
Top Down
• There are many benefits to the top -down approach.
• Nonfunctional aspects are taken care of at the beginning of design, and hence
they are an integral part of the product and not an after-thought.
• This makes a secure, robust, and usable product.
• A top- down approach also helps in creating reusable components and hence
increases productivity as well as maintainability.
• This approach also promotes integrity, as the whole product is designed inside a
single framework.
• So a fragmented and dissimilar approach for designing different parts of the
product is avoided.
• The drawback of the top -down approach is that it is a risky model.
• The whole design has to be made in one go instead of making attempts to
incrementally building the design, which is relatively a safer option.
• Generally, the top-down design approach is adopted on waterfall model-based
projects.
Bottom Up
• In the bottom-up approach, first, the minute functions of the software product
are structured and designed.
• Then, the middle-level components are designed, and, finally, the top-level
structure is designed.
• Once some components are designed, they can be shown to the customer, and
a buy in can be made for the project.
Bottom Up
• There are some benefits to the bottom-up approach.
• It leads to incremental building of design that ensures that any missing
information can be accommodated later in the design (Figure above – Bottom-
up Software Design).
• With increasing use of incremental and iterative development methodologies,
the bottom-up design approach is becoming more popular than the top-down
approach.
• In fact, nowadays, agile models do not go for elaborate and complete software
design from the beginning of the project.
• In each iteration, a design is thought of for the requirements that are taken
during the iteration.
• To compensate for a sturdy and elaborate design upfront, the project team
engages in refactoring (discussed next) the design to make sure that it does not
become bulgy and unmanageable in later iterations.
Module Division (Refactoring)
• Whenever a software product is designed, it is done with good intentions.
• Care is taken to ensure that the design is extensible, so that when customer
needs increase over time, the product can be extended to take care of those
increased needs.
• Unfortunately, even this foresight is not enough, and it becomes difficult to
extend the product functionality further. In such cases, it becomes necessary to
change the internal structure of software code without changing external
behavior of the software product.
Figure - Characteristics of a software product code that requires refactoring
• To do this, one technique is employed, which is known as refactoring.
• Using refactoring, the internal design of a piece of software code is improved by
decreasing coupling among classes of objects and increasing cohesion among classes.
• Refactoring is very similar to the concept of normalization in relational
databases.
• Some of the indications of code analysis that may suggest that the code needs
refactoring include duplicate code at many places, using long methods, a large
class with many concepts, the need to pass a large number of parameters, too
much communication between classes resulting from a large number of calls for
methods in code, and message chaining by calling one method which in turn
calls another method.
• When software code starts having these characteristics, then it is better to go
for code cleaning or refactoring.
• Going for refactoring will be justified by savings in time due to better code reuse
and make it easier to maintain code and scale up the product.
• Refactoring can be achieved by dividing cumbersome classes into smaller classes
that can be managed and used in a better way.
• In the new code, the functions will be the same, but many of the functions will
be moved now into new classes.
• On agile projects, the project team builds the software product without making
an elaborate design from start.
• One product module is built after another in the subsequent project iterations.
• This fact makes it necessary to adjust the software design as the product evolves
in this fashion.
• The adjustment in the software design in such cases is done using refactoring.
Module Coupling
• One area similar to refactoring is coupling between modules.
• As products mature and more and more lines of code are added to the existing
product, coupling between modules tends to increase.
• This has a profound impact when any changes in code are required.
• Changes in code result in more than normal occurrence of defects as
dependency between modules keeps increasing with increase in the size of the
product.
• To reduce the chances of product defects, it is necessary to reduce the number
of calls among different modules and classes.
• Service Oriented Architecture (SOA) architecture provides great help here.
• SOA architecture essentially promotes loose coupling, and this implies more or
less self-contained classes having less dependency on other classes.
• Increasing module coupling with increase in size of software product is always a
concern.
• Frequent refactoring can help in reducing module coupling among classes.
Component Level Design
• OMG (Object Management Group) Unified Modeling Language Specification
defines a component as
• “A modular, deployable, and replaceable part of a system that encapsulates
implementation and exposes a set of interfaces.”
• OO view: A component contains a set of collaborating classes
• Conventional view: A component contains processing logic, the internal data
structures that are required to implement the processing logic, and an interface
that enables the component to be invoked and data to be passed to it.
Object Oriented Component
• In the context of object-oriented
software engineering, a component
contains a set of collaborating classes.
• Each class within a component has
been fully elaborated to include all
attributes and operations that are
relevant to its implementation.
• To illustrate this process of design
elaboration, consider software to be
built for a sophisticated print shop.
• The overall intent of the software is to
collect the customer's requirements at
the front counter, cost a print job, and
then pass the job on to an automated
production facility.
• During requirements engineering, an
analysis class called PrintJob was derived..
Object Oriented Component
• The attributes and operations defined during analysis are noted at the top of
figure given here.
• During architectural design, PrintJob is defined as a component within the
software architecture and is represented using the shorthand UML notation
shown in the middle right of the figure.
• Note that PrintJob has two interfaces, computejob which provides job costing
capability and initiatejob, which passes the job along to the production facility.
• These are represented using the "lollipop" symbols shown to the left of the
component box.
• Component level design begins at this point.
• The details of the component PrintJob must be elaborated to provide sufficient
information to guide implementation.
• The original analysis class is elaborated to flush out all attributes and operations
required to implement the class as the component PrintJob.
• Referring to the lower right portion of figure given, the elaborated design class
PrintJob contains more detailed attribute information as well as an expanded
description of operations required to implement the component.
Conventional Component
• In the context of traditional software engineering, a component is a functional
element of a program that incorporates processing logic, the internal data
structures that are required to implement the processing logic, and an
interface that enables the component to be invoked and data to be passed to
it.
• A traditional component, also called a module, resides within the software
architecture and serves one of three important roles:
(1) A Control component that coordinates the invocation of all other problem domain
components,
(2) A Problem domain component that implements a complete or partial function
that is required by the customer, or
(3) An Infrastructure component that is responsible for functions that support the
processing required in the problem domain.
• Like object-oriented components, traditional software components are derived
from the analysis model.
• In this case, however, the data flow-oriented element of the analysis model
serves as the basis for the derivation.
• To illustrate this process of design elaboration for traditional components, again
consider software to be built for a sophisticated print shop.
• A set of data flow diagrams would be derived during requirements modeling.
• Assume that these are mapped into an architecture shown in below figure.
• Each box represents a software component.
• During component-level design, each module in above figure is elaborated.
• The module interface is defined explicitly.
• That is, each data or control object that flows across the interface is
represented.
• The data structures that are used internal to the module are defined.
• The algorithm that allows the module to accomplish its intended function is
designed using the stepwise refinement approach.
• The behavior of the module is sometimes represented using a state diagram.
• To illustrate this process, consider the module ComputePageCost.
• The intent of this module is to compute the printing cost per page based on
specifications provided by the customer.
• Data required to perform this function are: number of pages in the document,
total number of documents to be produced, one- or two-side printing, color
requirements, and size requirements.
• These data are passed to ComputePageCost via the module’s interface.
• ComputePageCost uses these data to determine a page cost that is based on the
size and complexity of the job—a function of all data passed to the module via
the interface.
• Page cost is inversely proportional to the size of the job and directly
proportional to the complexity of the job.
• The figure above represents the component-level design using a modified UML
notation.
• The ComputePageCost module accesses data by invoking the module
getJobData, which allows all relevant data to be passed to the component, and
a database interface, accessCostsDB, which enables the module to access a
database that contains all printing costs.
• As design continues, the ComputePageCost module is elaborated to provide
algorithm detail and interface detail (Figure above).
Basic Design Principles*
• The Open-Closed Principle (OCP). “A module [component] should be open for
extension but closed for modification.
• The Liskov Substitution Principle (LSP). “Subclasses should be substitutable for
their base classes.”
• Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend
on concretions.”
• The Interface Segregation Principle (ISP). “Many client-specific interfaces are
better than one general purpose interface.”
• The Release Reuse Equivalency Principle (REP). “The granule of reuse is the
granule of release.”
• The Common Closure Principle (CCP). “Classes that change together belong
together.”
• The Common Reuse Principle (CRP). “Classes that aren’t reused together should
not be grouped together.”
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.
• Interfaces
– Interfaces provide important information about communication and
collaboration (as well as helping us to achieve the OPC).
• Dependencies and Inheritance
– It is a good idea to model dependencies from left to right and inheritance
from bottom (derived classes) to top (base classes).
Conducting Component-Level Design
• Collaboration Diagram with Messaging
• Refactoring Interfaces and Class Definitions for PrintJob
• Activity Diagram for Compute-PaperCost
• State Chart Fragment for PrintJob Class
Component Design for WebApps
• WebApp component is
– (1) A well-defined cohesive function that manipulates content or provides
computational or data processing for an end-user, or
– (2) A cohesive package of content and functionality that provides end-user
with some required capability.
• Therefore, component-level design for WebApps often incorporates elements of
content design and functional design.
Content Design for WebApps
• Focuses on content objects and the manner in which they may be packaged for
presentation to a WebApp end-user.
• Consider a Web-based video surveillance capability within
SafeHomeAssured.com - Potential content components can be defined for the
video surveillance capability:
(1) The content objects that represent the space layout (the floor plan) with
additional icons representing the location of sensors and video cameras;
(2) The collection of thumbnail video captures (each an separate data object)
(3) The streaming video window for a specific camera.
• Each of these components can be separately named and manipulated as a
package.
Functional Design for WebApps
• Modern Web applications deliver increasingly sophisticated processing functions
that:
(1) Perform localized processing to generate content and navigation capability
in a dynamic fashion;
(2) Provide computation or data processing capability that is appropriate for
the WebApps business domain;
(3) Provide sophisticated database query and access, or
(4) Establish data interfaces with external corporate systems.
• To achieve these (and many other) capabilities, it is suggested to design and
construct WebApp functional components that are identical in form to software
components for conventional software.
Designing Conventional Components
• The design of processing logic is governed by the basic principles of algorithm
design and structured programming.
• The design of data structures is defined by the data model developed for the
system.
• The design of interfaces is governed by the collaborations that a component
must effect.
Algorithm Design
• The closest design activity to coding
• The approach:
1. Review the design description for the component
2. Use stepwise refinement to develop algorithm
3. Use structured programming to implement procedural logic
4. Use ‘formal methods’ to prove logic
Algorithm Design – Stepwise Refinement
open
walk to door;
reach for knob;
open door; repeat until door opens

turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
Algorithm Design
• Represents the algorithm at a level of detail that can be reviewed for quality
• Options:
– Graphical (E.g. flowchart, box diagram)
– Pseudo code (E.g., PDL) ... choice of many
– Programming language
– Decision table
Structured Programming
• Uses a limited set of logical constructs:
– Sequence
– Conditional – If-then-else, Select-case
– Loops – Do-while, Repeat until
• Leads to more readable, testable code
• Can be used in conjunction with “proof of correctness”
• Important for achieving high quality, but not enough
Structured Procedural Design and Decision Table
add a condition Z,
a if true, exit the program
x1 Ru le s
Co n d it io n s 1 2 3 4 5 6
b x2 c re gular cust om e r T T
silve r cust om e r T T
x3 d
gold cust om e r T T
f e
spe cial discount F T F T F T
x4 Ru le s
no discount
g apply 8 pe rce nt discount
apply 15 pe rce nt discount

x5
apply addit ional x pe rce nt discount
Program Design Language (PDL)
if condition x
then process a;
else process b;
endif
if-then-else PDL
easy to combine with source code
machine readable, no need for graphics input
graphics can be generated from PDL
enables declaration of data as well as procedure
easier to maintain
Why Design Language?
• Machine readable and able to process
• Can be embedded with source code, therefore easier to maintain
• Can be represented in great detail, if designer and coder are different
• Easy to review
Component-based Development
• When faced with the possibility of reuse, the software team asks:
– Are commercial off-the-shelf (COTS) components available to implement the
requirement?
– Are internally-developed reusable components available to implement the
requirement?
– Are the interfaces for available components compatible within the
architecture of the system to be built?
• At the same time, they are faced with the following impediments to reuse ...
Impediments to Reuse
• Few companies and organizations have anything that even slightly resembles a
comprehensive software reusability plan.
• Although an increasing number of software vendors currently sell tools or
components that provide direct assistance for software reuse, the majority of
software developers do not use them.
• Relatively little training is available to help software engineers and managers
understand and apply reuse.
• Many software practitioners continue to believe that reuse is “more trouble than
it’s worth.”
• Many companies continue to encourage of software development
methodologies which do not facilitate reuse.
• Few companies provide incentives to produce reusable program components.
Component Based Software Engineering (CBSE) Process
Domain Engineering
Domain Software Reusable

Architecture Artifact
Analysis
Development Development
Repository
Domain Structural Reusable
model Model Artifacts/
Components
Software Engineering
System Specification
& Construction
Analysis
User Design
Requirements
Analysis Application
System & Design
Spec Models Software
Domain Engineering
1. Define the domain to be investigated.
2. Categorize the items extracted from the domain.
3. Collect a representative sample of applications in the domain.
4. Analyze each application in the sample.
5. Develop an analysis model for the objects.
Identifying Reusable Components

• Is component functionality required on future implementations?
• How common is the component's function within the domain?
• Is there duplication of the component's function within the domain?
• Is the component hardware-dependent?
• Does the hardware remain unchanged between implementations?
• Can the hardware specifics be removed to another component?
• Is the design optimized enough for the next implementation?
• Can we parameterize a non-reusable component so that it becomes reusable?
• Is the component reusable in many implementations with only minor changes?
Identifying Reusable Components
• Is reuse through modification feasible?
• Can a non-reusable component be decomposed to yield reusable components?
• How valid is component decomposition for reuse?
Component-Based SE
• A library of components must be available
• Components should have a consistent structure
• A standard should exist, e.g.,
– OMG/CORBA
– Microsoft COM
– Sun JavaBeans
CBSE Activities
• Component qualification
• Component adaptation
• Component composition
• Component update
CBSE Activities – Qualification
Before a component can be used, it is necessary to consider:
• Application programming interface (API)
• Development and integration tools required by the component
• Run-time requirements including resource usage (e.g., memory or storage),
timing or speed, and network protocol.
• Service requirements including operating system interfaces and support from
other components.
• Security features including access controls and authentication protocol.
• Embedded design assumptions including the use of specific numerical or non-
numerical algorithms.
• Exception handling
CBSE Activities – Adaptation
The implication of “easy integration” is:
(1) that consistent methods of resource management have been implemented
for all components in the library;
(2) that common activities such as data management exist for all components,
and
(3) that interfaces within the architecture and with the external environment
have been implemented in a consistent manner.
CBSE Activities – Composition

• An infrastructure must be established to bind components together.
• Architectural ingredients for composition include:
– Data exchange model
– Automation
– Structured storage
– Underlying object model
OMG/CORBA
• The Object Management Group has published a common object request broker
architecture (OMG/CORBA).
• An object request broker (ORB) provides services that enable reusable
components (objects) to communicate with other components, regardless of
their location within a system.
• Integration of CORBA components (without modification) within a system is
assured if an interface definition language (IDL) interface is created for every
component.
• Objects within the client application request one or more services from the ORB
server.
• Requests are made via an IDL or dynamically at run time.
• An interface repository contains all necessary information about the service’s
request and response formats.
ORB Architecture
Interface Client
Repository
Client
Dynamic ORB
Invocation IDL interface
Stubs
Server
LAN Objects
ORB Core
Server
ORB Object
IDL
interface Adapter
Stubs Interface
Repository
Microsoft COM
• The component object model (COM) provides a specification for using
components produced by various vendors within a single application running
under the Windows operating system.
• COM encompasses two elements:
– COM interfaces (implemented as COM objects)
– A set of mechanisms for registering and passing messages between COM
interfaces.
SUN JavaBeans
• The JavaBeans component system is a portable, platform independent CBSE
infrastructure developed using the Java programming language.
• The JavaBeans component system encompasses a set of tools, called the Bean
Development Kit (BDK), that allows developers to
– Analyze how existing Beans (components) work
– Customize their behavior and appearance
– Establish mechanisms for coordination and communication
– Develop custom Beans for use in a specific application
– Test and evaluate Bean behavior.
Classification
• Enumerated classification—Components are described by defining a hierarchical
structure in which classes and varying levels of subclasses of software
components are defined.
• Faceted classification—A domain area is analyzed and a set of basic descriptive
features are identified.
• Attribute-value classification—A set of attributes are defined for all components
in a domain area.
Reuse Environment
• A component database capable of storing software components and the
classification information necessary to retrieve them.
• A library management system that provides access to the database.
• A software component retrieval system (e.g., an object request broker) that
enables a client application to retrieve components and services from the library
server.
• CBSE tools that support the integration of reused components into a new design
or implementation.
COHESION
Cohesion
• Conventional view:
– The “single-mindedness” of a module
• OO view:*
– Cohesion implies that a component or class encapsulates only
attributes and operations that are closely related to one another and
to the class or component itself.
– It is the degree to which all elements directed towards performing a
single task are contained in the component. Basically, cohesion is the
internal glue that keeps the module together. A good software design
will have high cohesion.
Cohesion
• Levels of cohesion
– Functional
– Layer
– Communicational
– Sequential
– Procedural
– Temporal
– Utility
Cohesion
• Functional Cohesion: Every essential element for a single computation is
contained in the component. A functional cohesion performs the task and
functions. It is an ideal situation.
• Sequential Cohesion: An element outputs some data that becomes the
input for other element, i.e., data flow between the parts. It occurs
naturally in functional programming languages.
• Communicational Cohesion: Two elements operate on the same input
data or contribute towards the same output data. Example- update record
into the database and send it to the printer.
• Procedural Cohesion: Elements of procedural cohesion ensure the order
of execution. Actions are still weakly connected and unlikely to be
reusable. Ex- calculate student GPA, print student record, calculate
cumulative GPA, print cumulative GPA.
Contd..
• Temporal Cohesion: The elements are related by their timing
involved. A module connected with temporal cohesion all the tasks
must be executed at the same time-span. This cohesion contains the
code for initializing all the parts of the system. Lots of different
activities occur, all at init time.
• Logical Cohesion: The elements are logically related and not
functionally. Ex- A component reads inputs from tape, disk, and
network. All the code for these functions is in the same component.
Operations are related, but the functions are significantly different.
• Coincidental Cohesion: The elements are not related(unrelated). The
elements have no conceptual relationship other than location in
source code. It is accidental and the worst form of cohesion. Ex- print
next line and reverse the characters of a string in a single component.
Coupling
• Conventional view:
– The degree to which a component is connected to other components and
to the external world. Coupling is the measure of the degree of
interdependence between the modules. A good software will have low
coupling.
• OO view:
– A qualitative measure of the degree to which classes are connected to one
another.
Types of Coupling
• Types of Coupling:
• Data Coupling: If the dependency between the modules is based on the fact that
they communicate by passing only data, then the modules are said to be data
coupled. In data coupling, the components are independent to each other and
communicating through data. Module communications don’t contain tramp data.
Example-customer billing system.
• Stamp Coupling In stamp coupling, the complete data structure is passed from
one module to another module. Therefore, it involves tramp data. It may be
necessary due to efficiency factors- this choice made by the insightful designer,
not a lazy programmer.
• Control Coupling: If the modules communicate by passing control information,
then they are said to be control coupled. It can be bad if parameters indicate
completely different behavior and good if parameters allow factoring and reuse of
functionality. Example- sort function that takes comparison function as an
argument.
Types Coupling
• External Coupling: In external coupling, the modules depend on
other modules, external to the software being developed or to a
particular type of hardware. Ex- protocol, external file, device format,
etc.
• Common Coupling: The modules have shared data such as global
data structures. The changes in global data mean tracing back to all
modules which access that data to evaluate the effect of the change. So
it has got disadvantages like difficulty in reusing modules, reduced
ability to control data accesses and reduced maintainability.
• Content Coupling: In a content coupling, one module can modify the
data of another module or control flow is passed from one module to
the other module. This is the worst form of coupling and should be
avoided.
• Step 1. Identify all design classes that correspond to the problem domain.
• Step 2. Identify all design classes that correspond to the infrastructure domain.
• Step 3. Elaborate all design classes that are not acquired as reusable
components.
• Step 3a. Specify message details when classes or component collaborate.
• Step 3b. Identify appropriate interfaces for each component.
• Step 3c. Elaborate attributes and define data types and data structures required
to implement them.
• Step 3d. Describe processing flow within each operation in detail.
• Step 4. Describe persistent data sources (databases and files) and identify the
classes required to manage them.
• Step 5. Develop and elaborate behavioral representations for a class or
component.
• Step 6. Elaborate deployment diagrams to provide additional implementation
detail.
• Step 7. Factor every component-level design representation and always
consider alternatives.
User Interface Design
Interface Design
• Easy to learn?
• Easy to use?
• Easy to understand?
Typical Design Errors

• Lack of consistency
• Too much memorization
• No guidance / help
• No context sensitivity
• Poor response
• Arcane/unfriendly
Golden Rules
• Place the user in control
• Reduce the user’s memory load
• 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.
User Interface Design Models
• User model — A profile of all end users of the system
• Design model — A design realization of the user model
• Mental model (system perception) — The user’s mental image of what the
interface is
• Implementation model — The interface “look and feel” coupled with supporting
information that describe interface syntax and semantics.
User Interface Design Process

User Interface Design Process - Steps
• Interface analysis focus on the profile of users who interact with the system
[skill level , business understanding etc] – to understand the system
perception for each class of users.
– Task Analysis – Tasks user performs to accomplish the goals of the system, elaborated over
number of iterations, then focus on physical work environment
• The information gathered as part of the analysis action is used to create an
analysis model for the interface, using the analysis model is created.
• The goal of interface design is to define a set of interface objects and actions
that enable a user to perform all defined 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.
• 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
User Interface Design Process – Interface Analysis
• Interface analysis 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
• 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 keyboard phobic?
• What is the age range of the user community?
• 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?
User Analysis
• 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?
• What are the consequences if a user makes a mistake using the system?
• Are users experts in the subject matter that is addressed by the system?
• Do users want to know about the technology the sits behind the interface?
Task Analysis and Modeling

• Answers the following questions …
– 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?
• Use-cases define basic interaction
• Task elaboration refines interactive tasks
Task Analysis and Modeling
• Use Cases - When used as part of task analysis, the use case is developed to
show how an end user performs some specific work-related task
• Task Elaboration - Task analysis for interface design uses an elaborative
approach to assist in understanding the human activities the user interface must
accommodate
• Object elaboration identifies interface objects (classes)
• Workflow analysis defines how a work process is completed when several
people (and roles) are involved
– Swimlane Diagram for Prescription
refill function
Analysis of Display Content
• Are different types of data assigned to consistent geographic locations on the
screen (e.g., photos always appear in the upper right hand corner)?
• 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?

Interface Design Steps
• 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.
Design Issues
• Response time
• Help facilities
• Error handling
• Menu and command labeling
• Application accessibility
• Internationalization
WebApp Interface Design
• Where am I?
The interface should
– Provide an indication of the WebApp that has been accessed
– Inform the user of her location in the content hierarchy.
• What can I do now?

The interface should always help the user understand his current options
– What functions are available?
– What links are live?
– What content is relevant?
• Where have I been, where am I going?

The interface must facilitate navigation.
– Provide a “map” (implemented in a way that is easy to understand) of where
the user has been and what paths may be taken to move elsewhere within
the WebApp.
Effective WebApp Interfaces
• Bruce Tognozzi suggests…
– Effective interfaces are visually apparent and forgiving, instilling in their
users a sense of control.
– Users quickly see the breadth of their options, grasp how to achieve their
goals, and do their work.
– Effective interfaces do not concern the user with the inner workings of the
system.
– Work is carefully and continuously saved, with full option for the user to
undo any activity at any time.
– Effective applications and services perform a maximum of work, while
requiring a minimum of information from users.
Interface Design Principles
• Anticipation—A WebApp should be designed so that it anticipates the use’s next
move.
• Communication—The interface should communicate the status of any activity
initiated by the user
• Consistency—The use of navigation controls, menus, icons, and aesthetics (e.g.,
color, shape, layout)
• Controlled autonomy—The interface should facilitate user movement
throughout the WebApp, but it should do so in a manner that enforces
navigation conventions that have been established for the application.
• Efficiency—The design of the WebApp and its interface should optimize the
user’s work efficiency, not the efficiency of the Web engineer who designs and
builds it or the client-server environment that executes it.
• Focus—The WebApp interface (and the content it presents) should stay focused
on the user task(s) at hand.
• Fitt’s Law—“The time to acquire a target is a function of the distance to and size
of the target.”
• Human interface objects—A vast library of reusable human interface objects has
been developed for WebApps.
Interface Design Principles
• Latency reduction—The WebApp should use multi-tasking in a way that lets the
user proceed with work as if the operation has been completed.
• Learnability— A WebApp interface should be designed to minimize learning
time, and once learned, to minimize relearning required when the WebApp is
revisited.
• Maintain work product integrity—A work product (e.g., a form completed by the
user, a user specified list) must be automatically saved so that it will not be lost
if an error occurs.
• Readability—All information presented through the interface should be
readable by young and old.
• Track state—When appropriate, the state of the user interaction should be
tracked and stored so that a user can logoff and return later to pick up where
she left off.
• Visible navigation—A well-designed WebApp interface provides “the illusion
that users are in the same place, with the work brought to them.”
Interface Design Workflow
• Review information contained in the analysis model and refine as required.
• Develop a rough sketch of the WebApp interface layout.
• Map user objectives into specific interface actions.
• Define a set of user tasks that are associated with each action.
• Storyboard screen images for each interface action.
• Refine interface layout and storyboards using input from aesthetic design.
• Identify user interface objects that are required to implement the interface.
• Develop a procedural representation of the user’s interaction with the interface.
• Develop a behavioral representation of the interface.
• Describe the interface layout for each state.
• Refine and review the interface design model.
Mapping User Objectives
Menu bar
major functions
List of use r obje ct ive s

graphic, logo, and company name
obje ct ive #1
obje ct ive #2
obje ct ive #3
obje ct ive #4
obje ct ive #5
graphic
obje ct ive #n
Home page text copy
Navigation
menu
Aesthetic Design
• Don’t be afraid of white space.
• Emphasize content.
• Organize layout elements from top-left to bottom right.
• Group navigation, content, and function geographically within the page.
• Don’t extend your real estate with the scrolling bar.
• Consider resolution and browser window size when designing layout.

Design Evaluation Cycle
preliminary
design
build
prototype #1
interface
build
prototype # n
interface
user
evaluate's
interface
design
modifications
are made
evaluation
is studied by
designer
Interface design
is complete
Design Pattern
• A design pattern can be characterized as “a three-part rule
which expresses a relation between a certain context, a
problem, and a solution”.
• In Software design, context allows the reader to
understand the environment in which the problem resides
and what solution might be appropriate within that
environment.
• A set of requirements, including limitations and
constraints, acts as a system of forces that influences how
the problem can be interpreted within its context and how
the solution can be effectively applied
Kinds of Patterns
• Architectural patterns describe broad-based design problems that are solved
using a structural approach
• Data patterns describe recurring data-oriented problems and the data
modeling solutions that can be used to solve them.
• Component patterns (alsoreferred to as design patterns) address problems
associated with the development of subsystems and components, the
manner in which they communicate with one another, and their placement
within a larger architecture.
• Interface design patterns describe common user interface problems and their
solution with a system of forces that includes the specific characteristics of
end users.
• WebApp patterns address a problem set that is encountered when building
WebApps and often incorporates many of the other patterns categories just
mentioned
Pattern Based Design in Context
Pattern Oriented Design
Patterns for Requirements Modeling
• Software patterns are a mechanism for capturing domain knowledge in a way
that allows it to be reapplied when a new problem is encountered.
• Domain knowledge can be applied to a new problem within the same application
domain
• The domain knowledge captured by a pattern can be applied by analogy to a
completely different application domain.
• The original author of an analysis pattern does not “create” the pattern, but
rather, discovers it as requirements engineering work is being conducted.
• Once the pattern has been discovered, it is documented.
Discovering Analysis Patterns

• The most basic element in the description of a requirements model is the use
case.
• A coherent set of use cases may serve as the basis for discovering one or more
analysis patterns.
• A semantic analysis pattern (SAP) “is a pattern that describes a small set of
coherent use cases that together describe a basic generic application.”
An Example
• Consider the following preliminary use case for software required to control and
monitor a real-view camera and proximity sensor for an automobile:
• Use case: Monitor reverse motion
• Description: When the vehicle is placed in reverse gear, the control
software enables a video feed from a rear-placed video camera to the
dashboard display.
• The control software superimposes a variety of distance and orientation
lines on the dashboard display so that the vehicle operator can maintain
orientation as the vehicle moves in reverse.
• The control software also monitors a proximity sensor to determine
whether an object is inside 10 feet of the rear of the vehicle.
• It will automatically break the vehicle if the proximity sensor indicates an
object within 3 feet of the rear of the vehicle.
• This use case implies a variety of functionality that would be refined and
elaborated (into a coherent set of use cases) during requirements gathering and
modeling.
An Example
• Regardless of how much elaboration is accomplished, the use case(s) suggest(s)
a simple, yet widely applicable SAP (Semantic Analysis Pattern)—the software-
based monitoring and control of sensors and actuators in a physical system.
• In this case, the “sensors” provide information about proximity and video
information.
• The “actuator” is the breaking system of the vehicle (invoked if an object is very
close to the vehicle.
• But in a more general case, a widely applicable pattern is discovered -->
Actuator-Sensor
Actuator-Sensor Pattern
• Pattern Name: Actuator-Sensor
• Intent: Specify various kinds of sensors and actuators in an embedded system.
Motivation:
• Embedded systems usually have various kinds of sensors and actuators.
• These sensors and actuators are all either directly or indirectly connected to a
control unit.
• Although many of the sensors and actuators look quite different, their behavior
is similar enough to structure them into a pattern.
• The pattern shows how to specify the sensors and actuators for a system,
including attributes and operations.
• The Actuator-Sensor pattern uses a pull mechanism (explicit request for
information) for Passive Sensors and a push mechanism (broadcast of
information) for the Active Sensors.
Constraints:
• Each passive sensor must have some method to read sensor input and attributes
that represent the sensor value.
• Each active sensor must have capabilities to broadcast update messages when
its value changes.
• Each active sensor should send a life tick, a status message issued within a
specified time frame, to detect malfunctions.
• Each actuator must have some method to invoke the appropriate response
determined by the ComputingComponent.
• Each sensor and actuator should have a function implemented to check its own
operation state.
• Each sensor and actuator should be able to test the validity of the values
received or sent and set its operation state if the values are outside of the
specifications.
Applicability: Useful in any system in which multiple sensors and actuators are
present.
Structure:
• A UML class diagram for the Actuator-Sensor Pattern is shown below.
Structure:
• Actuator, PassiveSensor and ActiveSensor are abstract classes and denoted in
italics.
• There are four different types of sensors and actuators in this pattern.
• The Boolean, integer, and real classes represent the most common types of
sensors and actuators.
• The complex classes are sensors or actuators that use values that cannot be
easily represented in terms of primitive data types, such as a radar device.
• Nonetheless, these devices should still inherit the interface from the abstract
classes since they should have basic functionalities such as querying the
operation states.
Behavior:
• The figure below presents a UML sequence diagram for an example of the
Actuator-Sensor Pattern as it might be applied for the SafeHome function that
controls the positioning (e.g., pan, zoom) of a security camera.
Behavior:
• Here, the Control Panel queries a sensor (a passive position sensor) and an
actuator (pan control) to check the operation state for diagnostic purposes
before reading or setting a value.
• The messages Set Physical Value and Get Physical Value are not messages
between objects.
• Instead, they describe the interaction between the physical devices of the
system and their software counterparts.
• In the lower part of the diagram, below the horizontal line, the Position Sensor
reports that the operation state is zero.
• The ComputingComponent then sends the error code for a position sensor
failure to the Fault Handler that will decide how this error affects the system and
what actions are required.
• It gets the data from the sensors and computes the required response for the
actuators.
Web Application Design
• Content Analysis - The full spectrum of content to be provided by the WebApp
is identified, including text, graphics and images, video, and audio data. Data
modeling can be used to identify and describe each of the data objects.
• Interaction Analysis - The manner in which the user interacts with the WebApp
is described in detail. Use-cases can be developed to provide detailed
descriptions of this interaction.
• Functional Analysis - The usage scenarios (use-cases) created as part of

interaction analysis define the operations that will be applied to WebApp
content and imply other processing functions. All operations and functions are
described in detail.
• Configuration Analysis - The environment and infrastructure in which the

WebApp resides are described in detail.
When Do We Perform Analysis?
• In some Web situations, analysis and design merge.
• However, an explicit analysis activity occurs when…
– The WebApp to be built is large and/or complex
– The number of stakeholders is large
– The number of Web engineers and other contributors is large
– The goals and objectives (determined during formulation) for the WebApp
will effect the business’ bottom line
– The success of the WebApp will have a strong bearing on the success of the
business
The Content Model
• Content objects are extracted from use-cases
– Examine the scenario description for direct and indirect references to
content
• Attributes of each content object are identified
• The relationships among content objects and/or the hierarchy of content
maintained by a WebApp
– Relationships—Entity-relationship diagram or UML
– Hierarchy—Data tree or UML
Data Tree
• Data tree for a SafeHome-Assured.com component – represents a hierarchy of
information that is used to describe a component.
• Simple or composite data items (one or more data values) are represented as
unshaded rectangles.
• Content objects are represented as shaded ones.
Interaction Model
Composed of four elements:
• Use-cases
• Sequence diagrams
• State diagrams
• User interface prototype

Interaction Model - Sequence diagram
:Produc t :Billof FloorPla n BoM
:Room :FloorPla n
Compone nt Ma t e ria ls Re pos it ory Re pos it ory
new cust o mer
d e s c rib e s
ro o m *
p la c e s ro o m
in f lo o r p la n
sa v e f lo o r p la n c o n f ig u ra t io n
se le c t s p ro d u c t c o m p o n e n t *
a d d t o Bo M
s a v e b ill o f m a t e ria ls
Figure 18.5 Se que nce diagram for us e -cas e :se le ct Saf e Hom e com pone nt s
Interaction Model - State diagram
Va lida t ing use r Se le ct ing use r a ct ion
use rid se le c t ot he r func t ions
syst e m st a t us=“input re a dy” va lida t e d syst e m st a t us=“link re a dy”
se le ct “log-in” displa y msg = “e nt e ruse rid” displa y: na viga t ion choice s”
displa y msg =“e nt e r pswd”
pa ssword va lida te d
e nt ry/ va lida t e d use r
e nt ry/ log-in re que st e d
n e w cu st o m e r do: link a s re quire d
do: run use r va lida t ion
e xit / use r a ct ion se le ct e d
e xit / se t use r a cce ss swit ch
c ust omiz a t ion c omple t e

se le c t e -c omme rc e (purc ha se ) func t iona lit y
se le c t c ust omiz a t ion func t iona lit y
ne xt se le ct ion
Sa ving floor pla n
Cust omiz ing se le ct de script ive
cont e nt syste m st a t us=“input re a dy”
syst e m st a t us=“input re a dy” De fining room se le ct de script ive displa y: st ora ge indica t or
displa y: ba sic inst ruct ions cont e nt
room be ing de fine d syst e m st a t us=“input re a dy” e nt ry/ floor pla n sa ve se le ct e d
displa y: roomde f. window do: st ore floor pla n
e nt ry/ va lida t e d use r e xit / sa ve comple t e d
do: proce ss use r se le ct ion
e nt ry/ roomde f. se le ct e d
e xit / cust omiz a t ion t e rmina t e d a ll rooms do: run room que rie s
de fine d do: st ore room va ria ble s
e xit / room comple t e d
Building floor pla n se le ct de script ive

se le ct sa ve floor pla n
cont e nt
syst e m st a t us=“input re a dy”
se le ct e nte r room in floor pla n displa y: floor pla n window
e nt ry/ floor pla n se le ct e d

do: inse rt room in pla ce
do: st ore floor pla n va ria ble s
e xit / room inse rt ion comple t e d
room inse rt ion comple t e d
Figure 1 8 .6 Pa rt ia l s t a t e dia gra m for n e w c u s t o m eint

r e ra c t ion
Functional Model
• The functional model addresses two processing elements of the WebApp
– User observable functionality that is delivered by the WebApp to end-users
– The operations contained within analysis classes that implement behaviors
associated with the class.
• An activity diagram can be used to represent processing flow
Functional Model - Activity diagram
init ialize t ot alCost
no c ompone nt s re ma in onBoMList c ompone nt s re ma in on BoMList
invoke g et price and

calcShipping Cos t quant it y
ret urns:
s hipping Cost
lineCos t =
price x quant it y
invoke
det ermineDis count
ret urns : dis count add lineCost t o
t ot alCos t
disc ount >0

t ot alCos t=
t ot alCos t - dis count
disc ount < = 0
t axTot al=
t ot alCos t x t axrat e
priceTot al =
t ot alCos t + t axTot al
+ s hipping Cos t
Configuration Model
• Server-side
– Server hardware and operating system environment must be specified
– Interoperability considerations on the server-side must be considered
– Appropriate interfaces, communication protocols and related collaborative
information must be specified
• Client-side
– Browser configuration issues must be identified
– Testing requirements should be defined
Navigation Modeling
• Should certain elements be easier to reach (require fewer navigation steps) than
others? What is the priority for presentation?
• Should certain elements be emphasized to force users to navigate in their

direction?
• How should navigation errors be handled?
• Should navigation to related groups of elements be given priority over

navigation to a specific element.
• Should navigation be accomplished via links, via search-based access, or by

some other means?
• Should certain elements be presented to users based on the context of previous

navigation actions?
• Should a navigation log be maintained for users?

Navigation Modeling
• Should a full navigation map or menu (as opposed to a single “back” link or
directed pointer be available at every point in a user’s interaction?
• Should navigation design be driven by the most commonly expected user

behaviors or by the perceived importance of the defined WebApp elements?
• Can a user “store” his previous navigation through the WebApp to expedite
future usage?
• For which user category should optimal navigation be designed?
• How should links external to the WebApp be handled, whether it is by

overlaying the existing browser window or as a new browser window or as a
separate frame?
Web Application Design Quality
Design Pyramid – Web Apps
Concurrent Engineering in Software Design
• Concurrent engineering deals with taking advance information from an earlier
stage for a later stage in project, so that both the stages can be performed
simultaneously.
• Though project activities are planned ahead in time, most often there are
dependencies between a previous task and the next task in line.
• So, the latter task cannot start until the previous task finishes.
• That is why it is significant to be aware that it is not feasible to initiate
developing an application until its design is complete.
• Moreover, the development will depend on the design.
• Until all details about design are made, development cannot be started.
• So, the development team cannot start their job until they have a software
design in their hands.
• Still some aspects about latter tasks can be done in advance.
• For instance, what development language will be used and how the application
can be partitioned for development work can be decided at the design stage
itself.
• Similarly, how maintenance and support functions will be done for the
application can be determined at the design stage itself.
• Knowing in advance helps in taking care of issues that may arise in later stages.
Benefits of Software Reuse
Problems with Reuse
4 Layers of Reuse
System Level Reuse
Architecture Level - Reuse
Reuse at Design Level
Reuse at Implementation Level
Reuse at Design Level
Design Life-Cycle Management
• Software requirements go through design process steps to become a full-
fledged software design.
• At the high level, system analysis is performed.
• System analysis includes a study of requirements and finding feasibility of
converting them into software design.
• Once the feasibility is done, then the actual software design is made.
• The software design is in the form of activity diagrams, use cases, prototypes,
etc.
• Once the design process is complete, these design documents are verified and
validated through design reviews.
• Once the design is reviewed and approved, then the design phase is over (Figure
below – Software Design Life Cycle).
REFERENCES
• Ashfaque Ahmed, Software Project Management: A Process-driven approach,
Boca Raton, Fla: CRC Press, 2012
• Roger S. Pressman, Software Engineering – A Practitioner Approach, 6th ed.,

McGraw Hill, 2005
• Ian Somerville, Software Engineering, 8th ed., Pearson Education, 2010

THANK YOU

Unit 2 - Software Design

Uploaded by

Copyright:

Available Formats

You might also like

Unit 2 - Software Design

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 2 - Software Design

Uploaded by

Copyright:

Available Formats

18CSC206J –Software Engineering and Project Management

within a specific se le c t ma jor func t ion prompt for re e nt ry

t hum bnail views s elect a specif ic cam er a

vie w c a me ra out put

exit t his f unct ion

Allows the modeler to

activities described by the a nd us e r ID

use-case and at the same

(if there are multiple

actors involved in a o t h er f u n ct io n s p ro m pt for re e nt ry

analysis class has

responsibility for the n o in p u t

vie w c a m e ra ou tpu t prom pt for

These slides are designed to accompany

These slides are designed to accompany

These slides are designed to accompany

One common form:

object relationship object

These slides are designed to accompany

• Level 1—model all data objects (entities)

These slides are designed to accompany

These slides are designed to accompany

These slides are designed to accompany

These slides are designed to accompany

These slides are designed to accompany

These slides are designed to accompany

PlayerHead PlayerBody PlayerArms PlayerLegs

These slides are designed to accompany

is used to build is used to build

1..* 0..* is used to build 0..*

These slides are designed to accompany

These slides are designed to accompany

These slides are designed to accompany

These slides are designed to accompany

These slides are designed to accompany

 Represents how data objects are transformed at they move through

These slides are designed to accompany

Every computer-based system is an

These slides are designed to accompany

These slides are designed to accompany

Examples: a person, a device, a sensor

Another example: computer-based

Data must always originate somewhere

These slides are designed to accompany

Examples: compute taxes, determine area,

Data must always be processed in some

These slides are designed to accompany

Data flows through a system, beginning

These slides are designed to accompany

These slides are designed to accompany

• all icons must be labeled with meaningful

These slides are designed to accompany

These slides are designed to accompany

• write a narrative describing the

These slides are designed to accompany

These slides are designed to accompany

These slides are designed to accompany

state transition table