Ilovepdf Merged Compressed

CSE3001 SOFTWARE ENGINEERING
L T P J C
2 0 2 4 4
Dr. S M SATAPATHY
Associate Professor,
School of Computer Science and Engineering,
VIT Vellore, TN, India – 632 014.
SOFTWARE
DESIGN
Module – 4
Software Design
1. Cohesion, Coupling
2. Architectural Design
3. Detailed Design
4. Object Oriented Design
5. User Interface Design
3
INTRODUCTION
• Design phase transforms SRS document:

– into a form easily implementable in some programming language.
SRS Document Design Documents

Design Activities
INTRODUCTION
• Items designed:
– module structure,
– control relationship among the modules
• call relationship or invocation relationship
– interface among different modules,
• data items to be exchanged among different modules,
– data structures of individual modules,
– algorithms for individual modules.
INTRODUCTION
• Good software designs:
– seldom arrived through a single step procedure:
– but through a series of steps and iterations.
• Design activities are usually classified into two stages:

– preliminary (or high-level) design
– detailed design.
• Meaning and scope of the two stages:
– vary considerably from one methodology to another.
HIGH LEVEL DESIGN
• The outcome of high-level design:
– program structure (or software architecture).
• Several notations are available to represent high-level design:
– Usually a tree-like diagram called structure chart is used.
– Other notations:
• Jackson diagram or Warnier-Orr diagram can also be used.
DETAILED DESIGN
• For each module, design:
– data structure
– algorithms
• Outcome of detailed design:
– module specification.
A FUNDAMENTAL QUESTION:
• How to distinguish between good and bad designs?
– Unless we know what a good software design is:
• we can not possibly design one.
• There is no unique way to design a system.

• Even using the same design methodology:
– different engineers can arrive at very different design solutions.
• We need to distinguish between good and bad designs.
WHAT IS GOOD SOFTWARE DESIGN?
• Correctness: Should implement all functionalities of the system correctly.
• Understandability: Should be easily understandable.
• Efficiency: Should be efficient.
• Maintainability: Should be easily amenable to change,
– i.e. easily maintainable.
WHAT IS GOOD SOFTWARE DESIGN?
• Understandability of a design is a major issue:
– determines goodness of design:
– a design that is easy to understand:
• also easy to maintain and change.
• Unless a design is easy to understand,
– tremendous effort needed to maintain it
– We already know that about 60% effort is spent in maintenance.
• If the software is not easy to understand:
– maintenance effort would increase many times.
UNDERSTANDABILITY
• Use consistent and meaningful names
– for various design components,
• Design solution should consist of:
– a cleanly decomposed set of modules (modularity),
• Different modules should be neatly arranged in a hierarchy:
– in a neat tree-like diagram.
MODULARITY
• Modularity is a fundamental attributes of any good design.
– Decomposition of a problem cleanly into modules:
– Modules are almost independent of each other
– divide and conquer principle.
• If modules are independent of each other:
– modules can be understood separately,
• reduces the complexity greatly.
– To understand why this is so,
• remember that it is very difficult to break a bunch of sticks but
very easy to break the sticks individually.
EXAMPLE OF CLEANLY AND NON-
CLEANLY DECOMPOSED MODULES
MODULARITY
• In technical terms, modules should display:
– high cohesion
– low coupling.
• Neat arrangement of modules in a hierarchy means:
– low fan-out
– abstraction
COHESION AND COUPLING
• Cohesion is a measure of:
– functional strength of a module.
– A cohesive module performs a single task or function.
• Coupling between two modules:
– a measure of the degree of interdependence or interaction between
the two modules.
• A module having high cohesion and low coupling:
– functionally independent of other modules:
• A functionally independent module has minimal interaction with
other modules.
ADVANTAGES OF FUNCTIONAL
INDEPENDENCE
• Functional independence is key to:
– understandability and good design:
– Complexity of design is reduced,
– different modules can be understood in isolation:
• modules are more or less independent of each other.
• Functional independence reduces error propagation.
– degree of interaction between modules is low.
– an error existing in one module does not directly affect other modules.
• Reuse of modules is possible.
ADVANTAGES OF FUNCTIONAL INDEPENDENCE
• A functionally independent module:

– can be easily taken out and reused in a different program.
• each module does some well-defined and precise function
• the interfaces of a module with other modules is simple and
minimal.
• Unfortunately, there are no ways:
– to quantitatively measure the degree of cohesion and coupling:
– classification of different kinds of cohesion and coupling:
• will give us some idea regarding the degree of cohesiveness of a
module.
COHESION
• Cohesion is a measure of the degree to which the elements of a module
are functionally related.
TYPES OF COHESION
Degree of
cohesion
COINCIDENTAL COHESION
• The module performs a set of tasks:
– which relate to each other very loosely, if at all.
• the module contains a random collection of functions.
• functions have been put in the module out of pure coincidence
without any thought or design.
• Coincidental cohesion exists in modules that contain instructions that
have little or no relationship to one another.
LOGICAL COHESION
• All elements of the module perform similar operations:
– e.g. error handling, data input, data output, etc.
• An example of logical cohesion:
– a set of print functions to generate an output report arranged into a
single module.
• Logical cohesion occurs in modules that contain instructions that appear
to be related because they fall into the same logical class of functions.
TEMPORAL COHESION
• The module contains tasks that are related by the fact:
– all the tasks must be executed in the same time span.
• Example:
– The set of functions responsible for
• initialization,
• start-up, shut-down of some process, etc.
• Module exhibits temporal cohesion when it contains tasks that
are related by the fact that all tasks must be executed in the
same time-span.
PROCEDURAL COHESION
• The set of functions of the module:
– all part of a procedure (algorithm)
– certain sequence of steps have to be carried out in a certain order for
achieving an objective,
• e.g. the algorithm for decoding a message.
• Procedural Cohesion occurs in modules whose instructions although
accomplish different tasks yet have been combined because there is a
specific order in which the tasks are to be completed.
COMMUNICATIONAL COHESION
• All functions of the module:
– reference or update the same data structure,
• Example:
– the set of functions defined on an array or a stack.
• X and Y both operate on the same input data or contribute towards the
same output data. But we might consider making them separate
procedures.
SEQUENTIAL COHESION
• Elements of a module form different parts of a sequence,
– output from one element of the sequence is input to the next.
– Example:
•
sort
search
display
FUNCTIONAL COHESION
• Different elements of a module cooperate:
– to achieve a single function,
– e.g. managing an employee's pay-roll.
• When a module displays functional cohesion,
– we can describe the function using a single sentence.
• The mathematical subroutine such as “calculate current GPA” or

“cumulative GPA” are typical example of functional cohesion.
DETERMINING COHESIVENESS
• Write down a sentence to describe the function of the module
– If the sentence is compound,
• it has a sequential or communicational cohesion.
– If it has words like “first”, “next”, “after”, “then”, etc.
• it has sequential or temporal cohesion.
– If it has words like initialize,
• it probably has temporal cohesion.
COUPLING
• Coupling is the measure of the degree of interdependence between
modules.
• There are no ways to precisely determine coupling between two modules:
– classification of different types of coupling will help us to
approximately estimate the degree of coupling between two modules.
•
EXAMPLE
• Consider the example of editing a student record in a “Student
Information System”.
TYPES OF COUPLING
Degree of
coupling
DATA COUPLING
• Two modules are data coupled,
– if they communicate via a parameter:
• an elementary data item,
• e.g an integer, a float, a character, etc.
– The data item should be problem related:
• not used for control purpose.
• The dependency between module A and B is said to be data coupled if
their dependency is based on the fact they communicate by only passing of
data. Other than communicating through data, the two modules are
independent.
STAMP COUPLING
• Two modules are stamp coupled,
– if they communicate via a composite data item
• such as a record in PASCAL
• or a structure in C.
• Stamp coupling occurs between module A and B when complete data
structure is passed from one module to another.
CONTROL COUPLING
• Data from one module is used to direct
– order of instruction execution in another.
• Example of control coupling:

– a flag set in one module and tested in another module.
• Module A and B are said to be control coupled if they communicate by

passing of control information. This is usually accomplished by means of
flags that are set by one module and reacted upon by the dependent
module.
CONTROL COUPLING
• Data from one module is used to direct
– order of instruction execution in another.
• Example of control coupling:

– a flag set in one module and tested in another module.
• Module A and B are said to be control coupled if they communicate by

passing of control information. This is usually accomplished by means of
flags that are set by one module and reacted upon by the dependent
module.
COMMON COUPLING
• Two modules are common coupled,
– if they share some global data.
• With common coupling, module A and module B have shared data. Global
data areas are commonly found in programming languages. Making a
change to the common data means tracing back to all the modules which
access that data to evaluate the effect of changes.
COMMON COUPLING
CONTENT COUPLING
• Content coupling exists between two modules:
– if they share code,
– e.g, branching from one module into another module.
• The degree of coupling increases
– from data coupling to content coupling.
• Content coupling occurs when module A changes data of module B or

when control is passed from one module to the middle of another. In Fig.
9, module B branches into D, even though D is supposed to be under the
control of C.
CONTENT COUPLING
LAYERED ARRANGEMENT OF MODULES
• Control hierarchy represents:
– organization of modules.
– control hierarchy is also called program structure.
• Most common notation:
– a tree-like diagram called structure chart.
• Neat arrangement of modules essentially means low fan-out and
abstraction.
CONCEPTS AND TERMINOLOGIES
• Superordinate and Subordinate Modules:
– A module that controls another module:
• said to be superordinate to it.
– Conversely, a module controlled by another module:
• said to be subordinate to it.
• Visibility:
– A module A is said to be visible by another module B,
• if A directly or indirectly calls B.
• Control Abstraction:
– The principle of abstraction requires:
• lower-level modules do not invoke functions of higher level
modules.
• Also known as layered design.
• Depth and Width:
– Depth:
• number of levels of control
– Width:
• overall span of control.
• Fan-out:
– a measure of the number of modules directly controlled by given
module.
– with high fan-out numbers is not a good design:
– a module having high fan-out lacks cohesion.
• Fan-in:
– indicates how many modules directly invoke a given module.
– High fan-in represents code reuse and is in general encouraged.
DESIGN APPROACHES
• Two fundamentally different software design approaches:
– Function-oriented design
– Object-oriented design
• These two design approaches are radically different.
– However, are complementary
• rather than competing techniques.
– Each technique is applicable at
• different stages of the design process.
FUNCTION-ORIENTED DESIGN
• A system is looked upon as something
– that performs a set of functions.
• Top-down Decomposition:
– Starting at this high-level view of the system:
• each function is successively refined into more detailed functions.
• Functions are mapped to a module structure.
• The function create-new-library- member:
– creates the record for a new member,
– assigns a unique membership number
– prints a bill towards the membership
• Create-library-member function consists of the following sub-functions:
– assign-membership-number
– create-member-record
– print-bill
• Each subfunction:
– split into more detailed subfunctions and so on.
• Centralised System State:
– The system state is centralized:
• accessible to different functions,
• member-records:
– available for reference and updation to several functions:
• create-new-member
• delete-member
• update-member-record
• Centralised System State:
– The system state is centralized:
• accessible to different functions,
• member-records:
– available for reference and updation to several functions:
• create-new-member
• delete-member
• update-member-record
• A few well-established function-oriented design approaches are:
– Step-wise refinement by Wirth [1971]
– Jackson’s Structured Design by Jackson [1975]
– Warnier-orr Methodology [1977, 1981]
– Structured Design by Constantine and Yourdan [1979]
– Hatley and Pirbhai’s Methodology [1987]
OBJECT-ORIENTED DESIGN
• System is viewed as a collection of objects (i.e. entities).
• System state is decentralized among the objects:
– each object manages its own state information.
• Library Automation Software:

– each library member is a separate object
• with its own data and functions.
– Functions defined for one object:
• cannot directly refer to or change data of other objects.
OBJECT-ORIENTED DESIGN
• Objects have their own internal data:
– defines their state.
• Similar objects constitute a class.

– each object is a member of some class.
• Classes may inherit features

– from a super class.
• Conceptually, objects communicate by message passing.

OOD VS. FOD
• Unlike function-oriented design,
– in OOD the basic abstraction is not functions such as “sort”, “display”,
“track”, etc.,
– but real-world entities such as “employee”, “picture”, “machine”, “radar
system”, etc.
• In OOD:
– software is not developed by designing functions such as:
• update-employee-record,
• get-employee-address, etc.
– but by designing objects such as:
• employees,
• departments, etc.
OOD VS. FOD
• Grady Booch sums up this fundamental difference saying:
– “Identify verbs if you are after procedural design and nouns if you are
after object-oriented design.”
• In OOD:
– state information is not shared in a centralized data.
– but is distributed among the objects of the system.
OOD VS. FOD
• In an employee pay-roll system, the following can be global data:
– names of the employees,
– their code numbers,
– basic salaries, etc.
• Whereas, in object oriented systems:
– data is distributed among different employee objects of the system.
• Objects communicate by message passing.
– one object may discover the state information of another object by
interrogating it.
• Of course, somewhere or other the functions must be implemented:
– the functions are usually associated with specific real-world entities
(objects)
– directly access only part of the system state information.
OOD VS. FOD
• Function-oriented techniques group functions together if:
– as a group, they constitute a higher level function.
• On the other hand, object-oriented techniques group functions together:
– on the basis of the data they operate on.
• To illustrate the differences between object-oriented and function-

oriented design approaches,
– let us consider an example ---
– An automated fire-alarm system for a large building.
AUTOMATED FIRE-ALARM SYSTEM
• We need to develop a computerized fire alarm system for a large multi-

storied building:
– There are 80 floors and 1000 rooms in the building.
• Different rooms of the building:
– fitted with smoke detectors and fire alarms.
• The fire alarm system would monitor:
– status of the smoke detectors.
AUTOMATED FIRE-ALARM SYSTEM
• Whenever a fire condition is reported by any smoke detector:
– the fire alarm system should:
• determine the location from which the fire condition was reported
• sound the alarms in the neighboring locations.
• The fire alarm system should:
– flash an alarm message on the computer console:
• fire fighting personnel man the console round the clock.
• After a fire condition has been successfully handled,
– the fire alarm system should let fire fighting personnel reset the alarms
FUNCTION-ORIENTED APPROACH:
• /* Global data (system state) accessible by various functions */
BOOL detector_status[1000];
int detector_locs[1000];
BOOL alarm-status[1000]; /* alarm activated when status set */
int alarm_locs[1000]; /* room number where alarm is located */
int neighbor-alarms[1000][10]; /* each detector has at most */
/* 10 neighboring alarm locations */
The functions which operate on the system state:
interrogate_detectors();
get_detector_location();
determine_neighbor();
ring_alarm();
reset_alarm();
report_fire_location();
OBJECT-ORIENTED APPROACH:
• class detector
attributes: status, location, neighbors
operations: create, sense-status, get-location,
find-neighbors
• class alarm
attributes: location, status
operations: create, ring-alarm, get_location,
reset-alarm
• In the object oriented program,
– appropriate number of instances of the class detector and alarm should
be created.
OOD VS. FOD
• In the function-oriented program :
– the system state is centralized
– several functions accessing these data are defined.
• In the object oriented program,
– the state information is distributed among various sensor and alarm
objects.
• Use OOD to design the classes:
– then applies top-down function oriented techniques
• to design the internal methods of classes.
• Though outwardly a system may appear to have been developed in an
object oriented fashion,
– but inside each class there is a small hierarchy of functions designed in
a top-down manner.
Architectural Design
1
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.
2
Why is Architecture Important?
 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” [BAS03].
3
Architectural Descriptions
 The IEEE Computer Society has proposed IEEE-Std-
1471-2000, Recommended Practice for Architectural
Description of Software-Intensive System, [IEE00]
 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.”
4
Architectural Decision Template
Used to document each major architectural decision for later review by
stakeholders who want to understand the proposed architectural
description
 Design issue
 Resolution
 Category
 Assumptions
 Constraints
 Alternatives
 Argument
 Implications
 Related decisions
 Related concerns
 Work products
 Notes 5
Architectural Genres
 Genre implies a specific category within the
overall software domain.
 Within each category, you encounter a number
of subcategories.
 For example, within the genre of buildings, you would
encounter the 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.
6
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.
 Data-centered architectures
 Data flow architectures
 Call and return architectures
 Object-oriented architectures
 Layered architectures
7
Data-Centered Architecture
8
Data Flow Architecture
9
Call and Return Architecture
10
Layered Architecture
11
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.
12
Architectural Design
 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
 An archetype is an abstraction (similar to a class)
that represents one element of system behavior
 The designer specifies the structure of the
system by defining and refining software
components that implement each archetype
13
Architectural Context
Safehome Internet-based
Product system
control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses
uses
sensors sensors
14
Archetypes
Cont roller
communicat es wit h
Node
Det ect or Indicat or
Figure 10.7 UML relat ionships f or Saf eHome securit y f unct ion archet ypes
(adapt ed f rom [ BOS00] ) 15
Component Structure
SafeHome
Execut ive
Funct ion
select ion
Ext ernal
Communicat ion
Management
Securit y Surveillance Home

management
GUI Int ernet

Int erface
Cont rol det ect or alarm

panel management processing
processing
16
Refined Component Structure
SafeHome
Executive
Ext ernal
Communicat ion
Management
Security
GUI Internet
Interface
Cont rol det ect or alarm

panel m anagem ent processing
processing
Key pad
processing scheduler phone
com m unicat ion
CP display
funct ions
alarm
sensor
sensor
sensor
sensor
sensor
sensor
sensor
sensor
sensor
17
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 considered 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.
18
Architectural Complexity
 the overall complexity of a proposed
architecture is assessed by considering the
dependencies between components within the
architecture [Zha98]
 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.
19
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.
20
An Architectural Design Method
customer requirements
"four bedrooms, three baths,
lots of glass ..."
architectural design
21
Deriving Program Architecture
Program
Architecture
22
Partitioning the Architecture
 “horizontal” and “vertical” partitioning are
required
23
Horizontal Partitioning
 define separate branches of the module
hierarchy for each major function
 use control modules to coordinate
communication between functions
function 1 function 3
function 2
24
Vertical Partitioning: Factoring
 design so that decision making and work
are stratified
 decision making modules should reside at
the top of the architecture
decision-makers
workers
25
Why Partitioned Architecture?
 results in software that is easier to test

 leads to software that is easier to maintain
 results in propagation of fewer side effects
 results in software that is easier to extend
26
Structured Design
 objective: to derive a program
architecture that is partitioned
 approach:
 a DFD is mapped into a program
architecture
 the PSPEC and STD are used to
indicate the content of each module
 notation: structure chart
27
Flow Characteristics
Transform flow
This edition of
SEPA does not
cover transaction
mapping. For a
detailed
discussion see the
SEPA website
Transaction
flow
28
General Mapping Approach
isolate incoming and outgoing flow
boundaries; for transaction flows, isolate
the transaction center
working from the boundary outward, map

DFD transforms into corresponding modules
add control modules as required
refine the resultant program structure

using effective modularity concepts
29
General Mapping Approach
 Isolate the transform center by specifying incoming
and outgoing flow boundaries
 Perform "first-level factoring.”
 The program architecture derived using this mapping
results in a top-down distribution of control.
 Factoring leads to a program structure in which top-level
components perform decision-making and low-level
components perform most input, computation, and output
work.
 Middle-level components perform some control and do
moderate amounts of work.
 Perform "second-level factoring."
30
Transform Mapping
b g h
a e f
d
c i
j
data flow model
x1 "Transform" mapping
x2 x3 x4
b c d e f g i
a h j
31
Factoring
direction of increasing
decision making typical "decision
making" modules
typical "worker" modules
32
First Level Factoring
main
program
controller
input processing output

controller controller controller
33
Second Level Mapping
main
D
C
control
B A
A
B
C
mapping from the D

flow boundary outward
34
User Interface Design
1
Interface Design
Easy to learn?
Easy to use?
Easy to understand?
2
Interface Design
Typical Design Errors
lack of consistency
too much memorization
no guidance / help
no context sensitivity
poor response
Arcane/unfriendly
3
Golden Rules
 Place the user in control

 Reduce the user’s memory load
 Make the interface consistent
4
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.
5
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.
6
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.
7
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
8
User Interface Design Process
9
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.
10
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?
 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?
11
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
 Object elaboration identifies interface objects (classes)
 Workflow analysis defines how a work process is
completed when several people (and roles) are involved
12
Swimlane Diagram
pat ient pharmacist physician
r e q u e st s t h at a
d e t e r m in e s st at u s o f
p r e scr ip t io n b e r e f ille d p r e scr ip t io n
no ref ills ch e cks p at ie n t

remaining r e co r d s
ref ills
remaining approves ref ill
ref ill not

ch e cks in v e n t o r y f o r
allowed
r e f ill o r alt e r n at iv e
e v alu at e s alt e r n at iv e
m e d icat io n
r e ce iv e s o u t o f st o ck out of st ock
n o t if icat io n
alt ernat ive
available
in st ock
r e ce iv e s t im e / d at e
none
t o p ick u p
p icks u p f ills
p r e scr ip t io n p r e scr ip t io n
r e ce iv e s r e q u e st t o
co n t act p h y sician
Figure 12.2 Swimlane diagram for prescript ion refill funct ion
13
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?
14
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.
15
Design Issues
 Response time
 Help facilities
 Error handling
 Menu and command
labeling
 Application accessibility
 Internationalization
16
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.
17
Effective WebApp Interfaces
 Bruce Tognozzi [TOG01] 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.
18
Interface Design Principles-I
 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.
19
Interface Design Principles-II
 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.
 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.
20
Interface Design Principles-III
 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.”
21
Interface Design Workflow-I
 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.
22
Mapping User Objectives
Menu bar
major functions
List of user object ives

graphic, logo, and company name
object ive #1
object ive #2
object ive #3
object ive #4
object ive #5
graphic
object ive #n
Home page text copy
Navigation
menu
23
Interface Design Workflow-II
 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.
24
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.
25
Design Evaluation Cycle
26
Definition of System and Software
Architecture
 Eberhardt Rechtin’s definition of system architecture states “A system is defined ...
as a set of different elements so connected or related as to perform a unique
function not performable by the elements alone.”
 To understand it, take the example of a Car, it consists of tyre, engine and body as
elements, each element alone cannot perform the functionality of car unless they
are all assembled.
 Another widely quoted definition of software architecture given by Bass,

Clements, and Karman says “the software architecture of a program or computing
system is the structure or structures of the system, which comprise: software
components, the externally visible properties of those components and the
relationships among them.”
System Architecture
Under system architecture:
1) All the requirements are partitions into different categories,
2) Sub system are identified,
3) Requirements are assigned to different sub system,
4) The functionality of each sub system is specified and
5) Interface design is created for enabling communication between sub systems.

Software Architecture
 Software architecture is the description of structure of new software which is under
planning, description of data, interfaces and algorithms used in it. The large system are
designed iteratively, architects keep adding details by moving back and forth in previous
version and current version of architecture design.
Here relationships between different sub systems are identified.
An abstract specification of services and constraints of each sub systems are
defined.
Interface description is defined and documented
Data structure required to implement system is described in details.
Algorithms used to deliver services are defined.

Define Structure
Q. The key question is how to define structure of the system. Views are used to define
structure
A. In software architecture, several models are used to produce different views, static
models are used to produce structure of a Logical View, dynamic models are used
to depict Process View and Interface models are used to depict communication
between sub systems.
B. A sub system consists of set of modules, provides set of services and it is

independent of other sub systems so it is a system in its own realm.
C. Modules of the system are used to depict Development View.
D. Deployment diagrams depicting servers are used to show physical view of

architecture.
Model Views
The four views of the model of a real system are: logical, development, process and
physical view are produced for better communication.
 Logical view: It is the functionality that the system provides to end-users. So it is an

external view that shows the attributes of the architecture such as maintainability,
extensibility, performance and security.
 Process view: It deals with the dynamic behaviour of the system, i.e., the system
processes, their communication, data flow and focuses on the runtime behaviour of the
system. Process and data flow diagrams are used to represent it.
 Development view: It depicts a system from a programmers perspective. It is

concerned with software management. Components or Modules of the system are shown
here.
 Physical view: It depicts the servers and storage system. It is concerned with the
topology of software components on the physical layer, as well as communication
between these components. Deployment diagrams are used to represent it.
Architecture Styles
 Client/Server Architectural Style
It is a distributed design system involving clients and servers, which reside on
separate machines and they are connected through network. It is called as 2 Tier
architectural system.
 The example of client server architecture is Web Browser over which clients send request to
database servers and obtain response over from them. User interface is always on client and data
management is on server.
 Layered Architectural Style
 Under this style application functionality is broken down into various layers by grouping relevant
functions into one layer and placing the layers one after another in vertical fashion. Each layer is
assigned a particular role, the interaction between layers is through interfaces.
 For example, the interaction of users over internet with first layer, say, presentation is through
http, interaction between middle layer (business logic) and back layer (database) is through JDBC
 By dividing responsibility among different layers, separates out concerns, which makes it easy for
architects to bring flexibility and maintainability.
 There are two styles of layered architecture: strict layering and relax layering architecture
styles....Cntd
Architecture Styles
 Layered Architectural Style
 In a strict layering style, components of one layer can only talk to components
present either in same layer or with components which are directly below it.
 In relaxed layering style, components can interact with components of same

layer or with all components present in any layer which is below it.
 The layers can come all on a single hardware machine or each layer on one
separate hardware computer. If layers are mapped to individual hardware
machines, it is known as n-tier.
 Generally, web applications are spread over minimum 3 layers, first layer is
presentation layer, second layer consists of business logic processing and third
layer is data access.
Cont...d
Architecture Styles
 Separated Presentation Pattern
 Model View Controller or MVC, it is a software design pattern for developing web applications.
 MVC pattern has three parts:

 Model - The lowest level of the pattern which is responsible for maintaining data. It accepts requests from
View and responds to instructions from the controller to update its data. It is the data base layer.
 View - This is responsible for displaying all or a portion of the data to the user. This is screen form design
portion. They are script based systems such as JSP, ASP, PHP. etc..
 Controller – This is Software Code that controls the interactions between the Model and View.
 It receives the input, validates it and then performs the business operation that modifies the state of the data
model. Typically, it reads data from a view (form), control user input, and send input data to the model
(database).
 MVC isolates the application logic from the user interface layer and supports separation of concerns.
 N-Tier / 3-Tier Architectural Style
 It is an improved way of designing layered architecture style, here instead of assigning all layers to one
physical server, each layer is assigned and hosted to a separate physical computer.
 The tiers interact with each other using platform specific protocol of communication- HTTP, JDBC, etc.
Object-Oriented
Architecture
In an object oriented architecture, the functionality is broken down into sub
systems using the constructs of object oriented data models such as object
classes, attributes and operations.
It is a modular decomposition architectural style which is applied at

application design level.
This architecture is based on breaking the responsibilities of an application

into separate reusable independent objects.
Data and methods, i.e., structure and behaviour both are kept in the object.
This kind of style views the system as a collection of cooperating objects
instead of set of sub programs or procedures.
Objects are solid, independent and loosely coupled. Interfaces or messages are
used by the objects to communicate with each other.
Principles of Object-Oriented
 Abstraction:- Conceive the complex operations at a higher level by generalizing it and
retaining fundamental characteristics of operations and leaving irrelevant details.
 Decomposition:- The larger problem can be broken down into smaller components which
can be easily solved.
 Composition:-A large object can be carved out by combining other objects. The non
required objects can be masked.
 Inheritance:- No need to write functionality already addressed by some objects by a new

object. It can inherit it and provide new behaviour.
 Encapsulation: - The objects functionality is provided through their operations and

properties. The access to internal variables and operations of the objects are not provided
for modifications. So encapsulation ensures that internal details such as variables and
operations are secure from unauthorized access
 Polymorphism: As the name indicates, the functionality of base class can be used by its
sub classes in poly (many) ways.
 Decoupling: An abstract interface provided by object decouples it from consumer or caller

object.
Inter Organizational Communication
 Some time organizations follow distributed architecture or they need to talk to
each other to get specialized services from other organizations.
 These days in each transaction based application where payment is involved,

requires integration with payment gateways.
 In such cases, either message or web services based architecture can be adopted.
 It is an example of distributed architecture systems which can support resource

sharing, interoperability, scalability and transparency.
Message Oriented Architecture
 The need for integrating different systems is increasing. The way departments is to define schema
which contains semantics of information which will be exchanged between two departments. It is
called as contract between Service Provider and Service Consumer. It is expressed in WSDL
document.
 On the basis of format of information agreed, an XML packet is generated. It is sent over transport
protocol, http. The envelope so created is called as SOAP. The way to achieve the above integration is
either use Message Oriented architecture (MOA) or SOA (Web Services).
 In SOA, the integration takes place between components (web services) which are identical so
integration is seamless. The SOA integration is Action Oriented, i.e., message is sent, operation is
performed over it and results are delivered back by the invoked web service. Integration is on point
to point basis.
 In Message Oriented Architecture, the integration components are not necessarily identical but
message format is identical.
 A message bus is capable of providing:

 Message-oriented communications: The communication between disparate applications is based on known
protocol, message format (known schema) and protocol.
 Complex processing logic: Complex operations is broken down into simple operations and results are computed
in multiple stages. The final results are joined up.
Enterprise Service Bus (ESB)
 ESB uses message router which locates the desired web services in UDDI based
directory before sending the request.
 It then interacts with its port on the web site called as endpoint on behalf of Service
consumer application acting as proxy for Service Provider.
 So all service consumers only talk to single point of contact, i.e., enterprise service
bus.
 As a value added service, an ESB usually provides data transformational services

which transform messages from one data format to another.
Principles of SOA Architecture Style
 Independence among services.: Development, deployment, maintenance and version
control for each service is not dependent on other services.
 Loose coupling of services: Services interact with each other through well defined
interfaces so their maintenance is easy as it does not impact application.
 Services share schema and binding agreement, not class: Schema and binding
agreement are used to share information with service consumers allowing them to use services
it is a better way of sharing compared to sharing internal details of classes.
 Policy based Compatibility: Policy is defined in terms of data format (XML), transport
protocol (http) and security. It is called as SOAP, it brings interoperability since services can
run on any platform.
Component-Based Architectural Style
 The architecture of component based style assumes that components will be developed
independently as standalone entities by different people
 As per Ivica Crnkovic, Magnus Larsson, definitions of component are:
 A component is a non-trivial, nearly independent, and replaceable part of a system that fulfils a clear
function in the context of a well-defined architecture.
 A component conforms to and provides the physical realization of a set of interfaces.
 A run-time software component is a dynamically linkable package of one or more programs managed as a
unit and accessed through documented interfaces that can be discovered at run-time.
 The widely accepted definition of component is “a component is a constituent of software is in binary form
so that the need tore compile it is alleviated, it has specified interface or Application Programming
Interface and it can be deployed or dynamically loaded or replaced.”
 It is integrals in the system without the need for modifying and rebuilding it.
 The components express their functionality through interfaces, so it is from where the user
connects to the component. It gives designer the opportunity to abstract the design at a higher
level than what is abstracted by the principles of object-oriented design. It does not pay
attention on issues like communication protocols and shared state.
Domain Driven Design Style
 Common Communication Language: Building model of domain facilitates both IT

teams and business stakeholders to articulate business wisdom and requirements
in a common language free from technical jargons.
 Easy of Testing: Loose coupling and cohesion are the cornerstone of domain
modelling, which make this style easy to test the application.
 Extensible: As this style is based upon object oriented design, which in turn
supports the principles of inheritance so it implies that this style is extensible.
Cloud Computing Architecture Style
 Cloud computing is defined as delivering compute power as service instead of a product to the
customers. Thus shared resources such as storage box, software and information are provided to
customers as utility like water or phone connection over an internet. The customers pay for
resources as per usage.
 It supports multi tenancy architecture whereby it enables sharing of resources and costs across a large
number of users by centralizing infrastructure at those locations which has lower costs of land, electricity,
labour. It also enables better utilization and efficiency of system resources which are not utilized fully.
 Cloud Computing comes in three flavours: Infrastructure as a Service ( IaaS ), Platform as a Service ( PaaS )
and Software as a Service (SaaS ).
 Infrastructure as a Service: The cloud providers are expected to create fabric of all the hardware servers,
storage boxes and system software as a common pool in the data Canters so that as per the requirements
of each application, the resources can be assigned to it instantaneously
 Platform as a Service: Besides, building the pool of Infrastructure, the cloud providers are expected to
install both open source and proprietary Web Servers, Application Servers, Databases and tools so that a
technology agnostic development platform becomes available for application development. The
development platform should be available in an on-demand provision mode to the customer
organizations.
 Software as a Service: The cloud Providers, install on the Infrastructure pool, some commonly used
finished products both COTS and be spoke applications such e-mail, Customer Relationship Module
(CRM)MS office, Star Office. It also includes other customized applications which the organization is
developing for sharing with others such as HR, Payroll, Accounting, etc. on pay as per usage pattern.
GRID Computing and Cloud Computing
 Grid Computing is an aggregation, selection and sharing of geographically distributed resources
such as computers, storage, data sources and specialized devices owned by different
organizations for solving resource intensive specific engineering and science problems.
 Creating Cloud Computing Platform:- Hypervisor software (e.g. Xen, ESX, Hyper V, KVM)
(refer layer 4 in Figure 4.9) is used to partition a single physical machine into several virtual
machines.
 The operating system which runs inside the virtual machine is called as Guest Operating
System.
 Hypervisor is positioned between the guest operating system running in the virtual machine and
hardware resources.
 This positioning enables the hypervisor to control how guest operating system running inside a
virtual machine uses hardware resources.
 This enables administrator to control all hardware resources using the hypervisor as single point
of control, which allows him to view hardware as a pool of resources which can run arbitrary
services on demand.
Multi Tenancy Architecture
 Multi tenancy means a type of architecture in which single instance of software hosted on a server
serves several customers organizations (tenants). Multi tenancy is different from multi instance
architecture. In the latter case separate software instances or hardware systems are enabled for
different organizations.
 But in case of multitenant architecture, the application is designed in such a way so that it can be
configured for different customer organizations and dataset of each organization is stored separately.
Separate virtual instance of application is created for each organization. There are three ways to
implement it.
 Separate Databases separate schema
 Common application source code and common system resources are used by all the tenants.
 The data base and schema are different for different tenants. The data and schema of each tenant
is stored separately.
 It results in sound and robust security and privacy for the data of each tenant.
 Shared Database, Separate Schemas
 Another approach involves housing several tenants in one database, each tenant has separate
set of tables, indexes, triggers and a schema.
 The data is stored at one place for all the tenants so security and privacy of data are concern.
 But each tenant has separate schema, it allows each tenant to exercise its own strategic control
over the database design.
Multi Tenancy Architecture
 Shared Database, Separate Schemas
 This approach is good for applications which use small number of tables, say of the order
of 100 or less.
 The cost of hosting a tenant is lower since database of all the tenants is common so costs of
data storage and maintenance gets shared among the tenants.
 Shared Database, Shared Schema
 This approach uses one database and same set of tables for all the tenants hosted on the
server.
 The tables store records of all tenants in same table; tenant ID is assigned to each row (refer
Figure 4.8).
 This approach is good if large number of tenants with small number of hardware servers
are to be served.
 Naturally, both the cost of tenancy and degree of data isolation are lowest in this kind of
data architecture.
Core Configurable and Customizable
Architecture
 Core:- Applications which have the potential for replication should be designed
following paradigm of core, configurable and customizable one.
 Configuration:- Out of 15 services, only 5 optional services as chosen by state will

be enabled. The fonts, layout and colour of different forms will be enabled as per
the choice of state.
 Customization: - In program code may be required to meet state specific

requirements.
Some of the key benefits of configurable solutions are that only one ? version of
application is maintained so a better support can be provided. Quality control
remains focused which results in stable and reliable system.
Thank you
Example 3: Trading-House
Automation System (TAS)
z A large trading house wants us
to develop a software:
y to automate book keeping
activities associated with its
business.
z It has many regular customers:
y who place orders for various
kinds of commodities.
Example 3: Trading-House
z The trading house maintains names and
addresses of its regular customers.
z Each customer is assigned a unique
customer identification number (CIN).
z As per current practice when a customer
places order:
y the accounts department first checks the
credit-worthiness of the customer.
Example: Trading-House
z The credit worthiness of a customer is
determined:
y by analyzing the history of his payments to
the bills sent to him in the past.
z If a customer is not credit-worthy:
y his orders are not processed any further
y an appropriate order rejection message is
generated for the customer.
z If a customer is credit-worthy:
y items he/she has ordered are checked
against the list of items the trading
house deals with.
z The items that the trading house
does not deal with:
y are not processed any further
y an appropriate message for the
customer for these items is generated.
z The items in a customer's order that
the trading house deals with:
y are checked for availability in the
inventory.
z If the items are available in the
inventory in desired quantities:
y a bill with the forwarding address of
the customer is printed.
y a material issue slip is printed.
z The customer can produce
the material issue slip at the
store house:
y take delivery of the items.
y inventory data adjusted to
reflect the sale to the
customer.
z If an ordered item is not
available in the inventory in
sufficient quantity:
y to be able to fulfill pending orders
store details in a "pending-order"
file :
x out-of-stock items along with
quantity ordered.
x customer identification number
z The purchase department:
y would periodically issue
commands to generate indents.
z When generate indents command
is issued:
y the system should examine the
"pending-order" file
y determine the orders that are pending
y total quantity required for each of the
items.
z TAS should find out the
addresses of the vendors
who supply the required
items:
y examine the file containing
vendor details (their address, items
they supply etc.)
y print out indents to those

vendors.
z TAS should also answers
managerial queries:
y statistics of different items
sold over any given period of
time
y corresponding quantity sold
and the price realized.
Context Diagram
indent
query
Trading-House-
Automation-
Manager System
statistics 0
order Generate-
response indent
Customer Purchase-
Department
Level 1 DFD
Customer-history Item-file
query
Accept- inventory statistics

Customer-file order
0.1 Handle-
query
0.3
order Process-
Accepted-orders
order
Vendor-list 0.2
Handle-
indent- Sales-statistics
Indent-request request
0.4
Indents pending-order Material-issue-slip +
bill
Example: Data Dictionary
z response: [bill + material-issue-slip, reject-message]
z query: period /* query from manager regarding sales
statistics*/
z period: [date+date,month,year,day]
z date: year + month + day
z year: integer
z month: integer
z day: integer
z order: customer-id + {items + quantity}*
z accepted-order: order /* ordered items available in inventory
*/
z reject-message: order + message /* rejection message */
z pending-orders: customer-id + {items+quantity}*
z customer-address: name+house#+street#+city+pin
Example: Data Dictionary
z item-name: string
z house#: string
z street#: string
z city: string
z pin: integer
z customer-id: integer
z bill: {item + quantity + price}* + total-amount + customer-
address
z material-issue-slip: message + item + quantity + customer-
address
z message: string
z statistics: {item + quantity + price }*
z sales-statistics: {statistics}*
z quantity: integer
Observation
zFrom the examples,
yobserve that DFDs help
create:
xdata model
xfunction model
Observation
z As a DFD is refined into
greater levels of detail:
y the analyst performs an
implicit functional
decomposition.
y At the same time, refinements
of data takes place.
Guidelines For
Constructing DFDs
z Context diagram should
represent the system as a
single bubble:
y Many beginners commit the
mistake of drawing more than
one bubble in the context
diagram.
Guidelines For
Constructing DFDs
z All external entities should be
represented in the context
diagram:
y external entities should not appear at
any other level of DFD.
z Only 3 to 7 bubbles per diagram
should be allowed:
y each bubble should be decomposed to
between 3 and 7 bubbles.
Guidelines For
Constructing DFDs
z A common mistake
committed by many
beginners:
y attempting to represent
control information in a DFD.
y e.g. trying to represent the
order in which different
functions are executed.
Guidelines For
Constructing DFDs
z A DFD does not represent control
information:
y when or in what order different functions
(processes) are invoked
y the conditions under which different
functions are invoked are not represented.
y For example, a function might invoke one
function or another depending on some
condition.
y Many beginners try to represent this aspect
by drawing an arrow between the
corresponding bubbles.
Example-1
z Check the input value:
y If the input value is less than -1000 or
greater than +1000 generate an error
message
y otherwise search for the number
Gener
Chec ate message
k Error
number numb
er number
Searc [found,not-found]
h
Guidelines For
Constructing DFDs
z If a bubble A invokes either
bubble B or bubble C depending
on some conditions:
y represent the data that flows
from bubble A to bubble B and
bubbles A to C
y not the conditions depending on
which a process is invoked.
Example-2
z A function accepts the book name to be searched from
the user
z If the entered book name is not a valid book name
y generates an error message,
z If the book name is valid,
y searches the book name in the database.
Search-
Good-book- book
Get-book- name
name Book-details
Print-err- Error-
message message
Book-name
Guidelines For
Constructing DFDs
z All functions of the system must be
captured in the DFD model:
y no function specified in the SRS
document should be overlooked.
z Only those functions specified in
the SRS document should be
represented:
y do not assume extra functionality of
the system not specified by the SRS
document.
Commonly made errors
z Unbalanced DFDs
z Forgetting to mention the names of the data flows
z Unrepresented functions or data
z External entities appearing at higher level DFDs
z Trying to represent control aspects
z Context diagram having more than one bubble
z A bubble decomposed into too many bubbles in the next
level
z Terminating decomposition too early
z Nouns used in naming bubbles
Shortcomings of the DFD
Model
z DFD models suffer from several
shortcomings:
z DFDs leave ample scope to be
imprecise.
y In a DFD model, we infer about the
function performed by a bubble from
its label.
y A label may not capture all the
functionality of a bubble.
Model
z For example, a bubble named find-
book-position has only intuitive
meaning:
y does not specify several things:
x what happens when some input
information is missing or is incorrect.
x Does not convey anything regarding what
happens when book is not found
x or what happens if there are books by
different authors with the same book title.
Model
z Control information is not represented:
y For instance, order in which inputs are
consumed and outputs are produced is not
specified.
Accept- inventory
Customer-file order
order Process-
Accepted-orders
order
Model
z A DFD does not specify
synchronization aspects:
y For instance, the DFD in TAS example
does not specify:
x whether process-order may wait until the
accept-order produces data
x whether accept-order and handle-order
may proceed simultaneously with some
buffering mechanism between them.
TAS: Level 1 DFD
query

Customer-file order
Handle-
query
order Process-
Accepted-orders
order
Vendor-list
Handle-
Indents
pending-order
Model
z The way decomposition is carried out to
arrive at the successive levels of a DFD
is subjective.
z The ultimate level to which
decomposition is carried out is
subjective:
y depends on the choice and judgement of the
analyst.
z Even for the same problem,
y several alternative DFD representations are
possible:
y many times it is not possible to say which
DFD representation is superior or preferable.
Model
z DFD technique does not provide:
y any clear guidance as to how exactly one
should go about decomposing a function:
y one has to use subjective judgement to carry
out decomposition.
z Structured analysis techniques do not
specify when to stop a decomposition
process:
y to what length decomposition needs to be
carried out.
Extending DFD Technique to Real-
Time Systems
z For real-time systems (systems
having time bounds on their
actions),
y essential to model control flow and
events.
y Widely accepted technique: Ward and
Mellor technique.
x a type of process (bubbles) that handles
only control flows is introduced.
x These processes are represented using
dashed circles.
Structured Design
z The aim of structured design
y transform the results of structured analysis
(i.e., a DFD representation) into a structure
chart.
z A structure chart represents the
software architecture:
y various modules making up the system,
y module dependency (i.e. which module calls
which other modules),
y parameters passed among different
modules.
Structure Chart
z Structure chart representation
y easily implementable using programming
languages.
z Main focus of a structure chart:
y define the module structure of a
software,
y interaction among different modules,
y procedural aspects (e.g, how a
particular functionality is achieved)
are not represented.
Basic building blocks of
structure chart
z Rectangular box:
y A rectangular box represents a
module.
y annotated with the name of the
module it represents.
Process-order
Arrows
z An arrow between two modules implies:
y during execution control is passed from one
module to the other in the direction of the
arrow.
root
Process-order Handle-indent Handle-query

Data flow Arrows
z Data flow arrows represent:
y data passing from one module to another in
the direction of the arrow.
root
order
Process-order
Library modules
z Library modules represent
frequently called modules:
y a rectangle with double side edges.
y Simplifies drawing when a module is
called by several modules.
Quick-sort
Selection
z The diamond symbol represents:
y one module of several modules connected to
the diamond symbol is invoked depending on
some condition.
root

Repetition
z A loop around control flow arrows
denotes that the concerned modules are
invoked repeatedly.
root

Structure Chart
z There is only one module at the top:
y the root module.
z There is at most one control relationship
between any two modules:
y if module A invokes module B,
y module B cannot invoke module A.
z The main reason behind this restriction:
y consider modules in a structure chart to be
arranged in layers or levels.
Structure Chart
z The principle of abstraction:
y does not allow lower-level
modules to invoke higher-
level modules:
y But, two higher-level modules
can invoke the same lower-
level module.
Example
root
Valid-numbers rms
rms
Valid-numbers
Get-good-data Compute-solution Display-solution
Validate-data
Get-data
Bad Design
Shortcomings of Structure
Chart
z By looking at a structure chart:
y we can not say whether a module
calls another module just once or
many times.
z Also, by looking at a structure
chart:
y we can not tell the order in which
the different modules are
invoked.
Flow Chart (Aside)
z We are all familiar with the flow chart
representations:
y Flow chart is a convenient technique to represent the
flow of control in a system. A=B
z A=B
z if(c == 100) yes no
z P=20
P=20 P=80
z else p= 80
z while(p>20) dummy
z print(student mark) yes no
Print
Flow Chart versus
Structure Chart
z A structure chart differs from a flow
chart in three principal ways:
y It is difficult to identify modules of a
software from its flow chart
representation.
y Data interchange among the modules
is not represented in a flow chart.
y Sequential ordering of tasks inherent
in a flow chart is suppressed in a
structure chart.
Transformation of a DFD Model
into Structure Chart
z Two strategies exist to

guide transformation of a
DFD into a structure
chart:
yTransform Analysis
yTransaction Analysis
Transform Analysis
z The first step in transform
analysis:
y divide the DFD into 3 types of
parts:
xinput,
xlogical processing,
xoutput.
Transform Analysis
z Input portion in the DFD:
y processes which convert input data
from physical to logical form.
y e.g. read characters from the terminal
and store in internal tables or lists.
z Each input portion:
y called an afferent branch.
y Possible to have more than one
afferent branch in a DFD.
Transform Analysis
z Output portion of a DFD:
y transforms output data from logical
form to physical form.
x e.g., from list or array into output
characters.
y Each output portion:
x called an efferent branch.
z The remaining portions of a DFD
y called central transform
Transform Analysis
z Derive structure chart by
drawing one functional
component for:
y the central transform,
y each afferent branch,
y each efferent branch.
Transform Analysis
z Identifying the highest level input and
output transforms:
y requires experience and skill.
z Some guidelines:
y trace the inputs until a bubble is found
whose output cannot be deduced from the
inputs alone.
y Processes which validate input are not
central transforms.
y Processes which sort input or filter data from
it are.
Transform Analysis
z First level of structure chart:
y draw a box for each input and output
units
y a box for the central transform.
z Next, refine the structure chart:
y add subfunctions required by each
high-level module.
y Many levels of modules may required
to be added.
Factoring
z The process of breaking functional
components into subcomponents.
z Factoring includes adding:
y read and write modules,
y error-handling modules,
y initialization and termination modules,
etc.
z Finally check:
y whether all bubbles have been
mapped to modules.
Example 1: RMS
Calculating Software
Data- Compute-
items RMS
0
User result
Context Diagram
Example 1: RMS
z From a cursory analysis of the
problem description,
y easy to see that the system needs to
perform:
x accept the input numbers from the user,
x validate the numbers,
x calculate the root mean square of the
input numbers,
x display the result.
Example 1: RMS
numbers
Read- Validate-
numbers numbers
0.1 0.2
Valid -
Data- numbers
items error
Compute-
Display rms
0.4 0.3
result RMS
Example 1: RMS
z By observing the level 1
DFD:
y identify read-number and
validate-number bubbles as
the afferent branch
y display as the efferent branch.
Example 1: RMS
Example 2: Tic-Tac-Toe
Computer Game
z As soon as either of the human player or
the computer wins,
y a message congratulating the winner should
be displayed.
z If neither player manages to get three
consecutive marks along a straight line,
y and all the squares on the board are filled up,
y then the game is drawn.
z The computer always tries to win a
game.
Context Diagram for
Example 2
Tic-tac-toe
display software
0
move
Human Player
Level 1 DFD
game
Display-
move board result
Validate- Check-
move board winner
Play-
move
Structure Chart
root
Get-good-move Compute-game Display
Get-move Validate- play-move Check-

move winner
Transaction Analysis
z Useful for designing transaction
processing programs.
y Transform-centered systems:
x characterized by similar processing steps
for every data item processed by input,
process, and output bubbles.
y Transaction-driven systems,
x one of several possible paths through the
DFD is traversed depending upon the input
data value.
Transaction Analysis
z Transaction:
y any input data value that triggers an action:
y For example, selected menu options might
trigger different functions.
y Represented by a tag identifying its type.
z Transaction analysis uses this tag to
divide the system into:
y several transaction modules
y one transaction-center module.
Transaction analysis
Transaction-
center
trans 3
trans 1
trans 2
type 1 type 2 type 3

Level 1 DFD for TAS
query

Customer-file order
Handle-
query
order Process-
Accepted-orders
order
Vendor-list
Handle-
Indents
pending-order
Structure Chart
Unified Modeling Language (UML)
Dr. Shashank Mouli Satapathy
February 1, 2021
School of Computer Science & Engineering

Vellore Institute of Technology (VIT), Vellore
Tamil Nadu - 632014, India
Dr. Shashank Mouli Satapathy Unified Modeling Language (UML) February 1, 2021 1
Introduction
Importance of Modeling
A model is a simplification of reality.

Why do we model?
We build model, so that we can better understand the system, we are
developing.
Through modeling, we can achieve four aims:
Models help us to visualize a system as it is or as we want it to be.
Models permit us to specify the structure or behavior of system.
Models give us a template that guides us in constructing a system.
Models document the decisions we have made.
Introduction UML
UML
The Unified Modeling Language (UML) is a family of graphical no-

tations, backed by single meta-model, that help in describing and
designing software systems, particularly software systems built us-
ing the object-oriented (OO) style .
The Unified Modeling Language (UML) is a graphical language for

creating diagrams that are useful in the software development pro-
cess.
The UML provides a set of standard graphical symbols and the rules
for combining them.
The Unified Modeling Language has quickly become the de-facto

standard for building Object-Oriented software.
Introduction OMG
OMG
The UML is a relatively open standard, controlled by the Object

Management Group (OMG), an open consortium of companies.
The OMG was formed to build standards that supported interoper-

ability, specifically the interoperability of object-oriented systems.
The OMG is perhaps best known for the CORBA (Common Object
Request Broker Architecture) standards.
UML 1.0 specification draft was proposed to the OMG in January

1997.
Introduction Definition
Definition
The OMG specification states :
The Unified Modeling Language (UML) is a graphical language for

visualizing, specifying, constructing , and documenting the artifacts of
a software-intensive system.
The UML offers a standard way to write a system’s blueprints, including

conceptual things such as business processes and system functions as well
as concrete things such as programming language statements, database
schemas, and reusable software components.
Definition(Contd..)
UML is a language for Visualizing : The UML is much more

than just a bunch of graphical symbols. Rather, behind each symbol
in UML notation, there is a well defined semantics available.
UML is a language for Specifying : Specifying means build-

ing models that are precise, unambiguous and complete. UML ad-
dresses the specification of all important analysis, design and imple-
mentation decisions that must be made in developing and deploying
a s/w system.
UML is a language for Constructing : UML is not visual

programming language, but its models can be directly connected to
a variety of programming language. This means that it is possible to
map from a model in UML to a programming language (like JAVA,
C++ etc).
Definition(Contd..)
UML is a language for Documenting :

Requirements
Architecture
Design
Source code
Project Plans
Test
Prototype
Releases
Introduction Application Areas
Application Areas of UML
Enterprise Information System

Banking and Financial Services
Telecommunications
Transportations
Defence or Aerospace
Retail
Medical Electronics
Scientific
Distributed Web-based Services etc..
Conceptual Model
Conceptual Model of UML
As UML describes the real time systems, it is very important to

make a conceptual model and then proceed gradually.
Conceptual model of UML can be mastered by learning the following

three major elements:
UML building blocks
Rules to connect the building blocks
Common mechanisms of UML
Conceptual Model UML Building Blocks
UML Building Blocks
The building blocks of UML can be defined as :

Things
Relationships
Diagrams
Conceptual Model UML Building Blocks
Things
Things are the most important building blocks of UML. Things can be:
Structural
Behavioral
Grouping
Annotational
Conceptual Model Things
Structural Things
The Structural things define the static part of the model.

They represent physical and conceptual elements.
The various structural things are :
Class : It is a set of objects that share the same attributes, opera-
tions, relationship and semantics.
Interface : A collection of functions that specify a service of a class

or component, i.e. externally visible behavior of that class.
Structural Things(Contd..)
Collaboration : A larger pattern of behaviors and actions. Exam-

ple: All classes and behaviors that create the modeling of a moving
tank in a simulation.
Use case : A sequence of actions that a system performs that

yields an observable result. Used to structure behavior in a model.
Is realized by a collaboration.
Structural Things(Contd..)
Active Class : Like a class but its represents behavior that runs
concurrent with other behaviors, i.e. threading.
Component : A physical and replaceable part of a system that

implements a number of interfaces. Example: a set of classes, in-
terfaces, and collaborations.
Node : A physical element existing at run time and represents a

resource.
Behavioural Things
A behavioral thing consists of the dynamic parts of UML models.

The two types of behavioral things are :
Interaction : A behavior made up of a set of messages exchanged
among a set of objects in a particular context to accomplish a spe-
cific purpose.
State Machine : A behavior that specifies the sequences of states

an object or interaction goes through during its’ lifetime in response
to events.
Grouping Things
Grouping things can be defined as a mechanism to group elements

of a UML model together.
There is only one grouping thing available :
Package : A general purpose mechanism for organizing elements
into groups.
Annotational Things
Annotational things can be defined as a mechanism to capture re-

marks, descriptions, and comments of UML model elements.
There is only one annotational thing available :
Note : It is used to render comments, constraints etc of an UML
element.
Conceptual Model Relationship
Relationship
It is another most important building block of UML. It shows how

elements are associated with each other and this association de-
scribes the functionality of an application.
There are four kinds of relationships available :
Dependency : A semantic relationship in which a change on one
thing (the independent thing) may cause changes in the other thing
(the dependent thing).
Relationship(Contd..)
Association : A structural relationship describing links between

objects. May also include labels to indicate number and role of the
links. In the example there may be any number of employees (*)
each of which has 0 or 1 employer. The double arrowhead is used
to indicate a ”has-a” relationship, meaning there is 1 employer who
may have many (*) employees.
Relationship(Contd..)
Generalization : Simply put this describes the relationship of a

parent class (generalization) to its subclasses (specializations).
Realization : Defines a relationship in which one class specifies

something that another class will perform. Example: The relation-
ship between an interface and the class that realizes or executes that
interface.
Conceptual Model Diagrams
Diagrams
UML diagrams are the ultimate output of the entire discussion.

All the elements, relationships are used to make a complete UML
diagram and the diagram represents a system.
The visual effect of the UML diagram is the most important part
of the entire process.
All the other elements are used to make it a complete one.
UML Diagrams(Contd..)
UML 1.x includes the following NINE diagrams :

1 Use Case Diagram
2 Activity Diagram
3 Class Diagram
4 Statechart Diagram
5 Sequence Diagram
6 Collaboration Diagram
7 Component Diagram
8 Deployment Diagram
9 Object Diagram
UML 2.x
UML has matured significantly since UML 1.1. Several minor revi-
sions (UML 1.3, 1.4, and 1.5) fixed shortcomings and bugs with the
first version of UML, followed by the UML 2.0 major revision that
was adopted by the OMG in 2005.
UML versions 2.1.1 and 2.1.2 appeared in 2007, followed by UML
2.2 in February 2009. UML 2.3 was formally released in May 2010.
UML 2.4.1 was formally released in August 2011. UML 2.5 was
released in October 2012 as an ”In process” version and has yet to
become formally released.
UML 2.x (Contd..)
UML 2.2 has 14 types of diagrams divided into two categories.

Seven diagram types represent structural information, and the other
seven represent general types of behavior, including four that rep-
resent different aspects of interactions.
UML 2.x (Contd..)
These diagrams can be categorized hierarchically as shown in the

following diagram:
4+1 Architectural View Model
4 + 1 Architectural View Model of UML
Philippe Kruchten originally presented the 4+1 View Model to de-

scribe the architecture of software-intensive systems.
This approach uses multiple views to separate stakeholders con-
cerns.
The 4+1 View Approach is widely accepted by the software industry
to represent application architecture blueprints.
Architecture also means different things to different stakeholders.
For example, a Network Engineer would only be interested in the
hardware and network configuration of the system; a Project Man-
ager in the key components to be developed and their timelines; a
Developer in classes that make up a component; and a Tester in
scenarios.

(Contd..)
So, we need multiple view points for distinct stakeholders needs,

showing what is relevant while masking the details that are irrele-
vant.
The 4+1 View Approach is an architecture style to organize an ap-
plications architecture representations into views to meet individual
stakeholders needs.

(Contd..)

(Contd..)
Tool Support
UML Tools
StarUML - StarUML is an open source project to develop fast,

flexible, extensible, featureful, and freely-available UML/MDA plat-
form running on Win32 platform.
ArgoUML - ArgoUML is the leading open source UML modeling
tool and includes support for all standard UML diagrams.
MagicDraw UML - It is a visual UML, SysML, BPMN, and
UPDM modeling tool with team collaboration support. Designed
for business analysts, software analysts, programmers, and QA en-
gineers.
GenMyModel - An online UML modeling tool
UML Tools List @ Wiki - Comprehensive list of UML Tools
and Utilities.
Tool Support
UML Tools (Contd..)
IBM Rational Software Architect - IBM RSA builts on Eclipse

version 3.4 and supports UML version 2.1. IBM Rational Software
Architect, (RSA) made by IBM’s Rational Software division, is a
modeling and development environment that uses the Unified Mod-
eling Language (UML) for designing architecture for C++ and Java
2 Enterprise Edition (J2EE) applications and web services.
IBM Rational Rose - With the IBM Rational June 2006 Prod-
uct Release, IBM withdrew the eXtended Development Environ-
ment(XDE) family of products and introduced the Rational Rose
Family of products as replacements. The Rational Rose Family of
products is a set of UML modeling tools for software design. It sim-
plifies the complex process of software design, creating a ”blueprint”
for construction of software systems.
Useful Resources
Useful Resources
Object Management Group - OMG Unified Modeling Language

Specification.
UML @ Wiki - Good tutorial on UML.
UML r Resource Page - A listing of various other resources for
UML.
Standards
Standards
Two types of standards:
De-Jure
De-facto
De-jure standards, or standards according to law , are en-

dorsed by a formal standards organization. The organization ratifies
each standard through its official procedures and gives the standard
its stamp of approval.
De-facto standards, or standards in actuality , are adopted

widely by an industry and its customers. They are also known as
market-driven standards. These standards arise when a crit-
ical mass simply likes them well enough to collectively use them.
Market-driven standards can become de jure standards if they are
approved through a formal standards organization.
SRS
SOFTWARE REQUIREMENT
SPECIFICATION
SRS Sample SRS
Sample SRS
R 1: Withdraw cash
Description: The withdraw cash function first determines the type of
account that the user has and the account number from which the user
wishes to withdraw cash. It checks the balance to determine whether
the requested amount is available in the account. If enough balance is
available, it outputs the required cash, otherwise it generates an error
message.
R 1.1: Select withdraw amount option
Input: “Withdraw amount” option
output: User prompted to enter the account type
R 1.2: Select account type
Input: User option from any one of the following: savings / current.
Output: Prompt to enter amount
SRS Sample SRS
Sample SRS (Contd..)
R 1.3: Get required amount

Input: Amount to be withdrawn in integer values greater than 100 and
less than 10,000 in multiples of 100.
Output: The requested cash and printed transaction statement.
Processing: The amount is debited from the user’s account, if sufficient
balance is available, otherwise an error message is displayed.
UML Diagrams
UML DIAGRAMS
UML Diagrams Use Case Diagram
Use Case Diagram
A use case diagram can portray the different types of users of a

system and the various ways that they interact with the system.
The purpose of use case diagram is to capture the dynamic aspect
of a system.
Use case diagrams are used to gather the requirements of a system
including internal and external influences.
These requirements are mostly design requirements.
So when a system is analyzed to gather its functionalities use cases
are prepared and actors are identified.
Use Case Diagram (Contd..)
Actor :
An actor is an idealization of an external person, process, or thing

interacting with a system, subsystem, or class.
An actor characterizes the interactions that outside users may have
with the system.
Each actor interacts with one or more use cases by exchanging mes-
sages.
Use Case :
A use case is a coherent unit of externally visible functionality pro-

vided by a system unit and expressed by sequences of messages
exchanged by the system unit and one or more actors of the system
unit.
The purpose of a use case is to define a piece of coherent behavior
without revealing the internal structure of the system.
The dynamics of a use case may be specified by UML interactions,
shown as statechart diagrams, sequence diagrams, collaboration di-
agrams, or informal text descriptions.
When use cases are implemented, they are realized by collaborations
among classes in the system.

Kinds of Use Case Relationships :
UML Diagrams Activity Diagram
Activity Diagram
Activity diagrams are graphical representations of workflows of step-

wise activities and actions with support for choice, iteration and
concurrency.
It also captures the dynamic behaviour of the system.
Activity diagrams deals with all type of flow control by using dif-
ferent elements like fork, join etc.
Activity Diagram (Contd..)
An activity state is shown as a box with rounded ends containing a

description of the activity.
Simple completion transitions are shown as arrows.
Branches are shown as guard conditions on transitions or as dia-
monds with multiple labeled exit arrows.
A fork or join of control is shown the same way as on a statechart,
by multiple arrows entering or leaving a heavy synchronization bar.
Swimlanes :
It is often useful to organize the activities in a model according to

responsibility.
For example, by grouping together all the activities handled by one
business organization.
This kind of assignment can be shown by organizing the activities
into distinct regions separated by lines in the diagram.
Because of their appearance, each region is called a swimlane.

Object Flows :
An activity diagram can show the flow of object values, as well as

the flow of control.
An object flow state represents an object that is the input or output
of an activity.
For an output value, a dashed arrow is drawn from an activity to
an object flow state.
For an input value, a dashed arrow is drawn from an object flow
state to an activity.
If an activity has more than one output value or successor control
flow, the arrows are drawn from a fork symbol.
Similarly, multiple inputs are drawn to a join symbol.
UML Diagrams Class Diagram
Class Diagram
A class is the description of a concept from the application domain

or the application solution.
The static view is displayed in class diagrams, so called because
their main focus is the description of classes.
Classes are drawn as rectangles. Lists of attributes and operations
are shown in separate compartments. The compartments can be
suppressed when full detail is not needed.
Relationships among classes are drawn as paths connecting class
rectangles.
A class diagram from the box office application is provided in the
next slide.
Class Diagram (Contd..)
Statechart Diagram
A state machine models the possible life histories of an object of a

class. A state machine contains states connected by transitions.
Each state models a period of time during the life of an object during
which it satisfies certain conditions.
When an event occurs, it may cause the firing of a transition that
takes the object to a new state.
When a transition fires, an action attached to the transition may
be executed.
State machines are shown as statechart diagrams.
Statechart Diagram (Contd..)
Statechart Diagram (Contd..)
UML Diagrams Sequence Diagram
Sequence Diagram
A sequence diagram shows a set of messages arranged in time se-

quence.
Each classifier role is shown as a lifeline, i.e., a vertical line that
represents the role over time through the entire interaction.
Messages are shown as arrows between lifelines.
One use of a sequence diagram is to show the behavior sequence of
a use case.
When the behavior is implemented, each message on a sequence
diagram corresponds to an operation on a class or an event trigger
on a transition in a state machine.
UML Diagrams Sequence Diagram
Sequence Diagram (Contd..)
UML Diagrams Collaboration Diagram
Collaboration Diagram
A collaboration diagram shows the roles in the interaction as a

geometric arrangement.
The messages are shown as arrows attached to the relationship lines
connecting classifier roles.
The sequence of messages is indicated by sequence numbers prepended
to message descriptions.
One use of a collaboration diagram is to show the implementation
of an operation.
The collaboration shows the parameters and local variables of the
operation, as well as more permanent associations.
When the behavior is implemented, the message sequencing cor-
responds to the nested calling structure and signal passing of the
program.
UML Diagrams Collaboration Diagram
Collaboration Diagram (Contd..)
UML Diagrams Component Diagram
Component Diagram
A component is a physical unit of implementation with well-defined

interfaces that is intended to be used as a replaceable part of a
system.
Each component embodies the implementation of certain classes
from the system design.
Well-designed components do not depend directly on other compo-
nents but on interfaces that components support. In that case, a
component in a system can be replaced by another component that
supports the proper interfaces.
A component is drawn as a rectangle with two small rectangles on
its side. It may be attached by solid lines to circles that represent
its interfaces.
A component diagram shows dependencies among components.
UML Diagrams Component Diagram
Component Diagram (Contd..)
UML Diagrams Deployment Diagram
Deployment Diagram
Deployment diagrams show a system’s physical layout, revealing

which pieces of software run an what pieces of hardware.
The main items in the diagram are nodes connected by communi-
cation paths . A node is something that can host some software.
Nodes come in two forms. A device is hardware, it may be a Com-
puter or a simpler piece of hardware connected to a system . An
execution environment is software that itself hosts or contains other
software, examples are an operating System or a Container process.
The nodes contain artifacts, which are the physical manifestations
of software: usually, files. These files might be executables (such as
.exe files, binarfies, DLLs, JAR files, assemblies, or scripts), or data
files, configuration files, HTML documents, and so on.
UML Diagrams Deployment Diagram
Deployment Diagram (Contd..)

Ilovepdf Merged Compressed

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

Ilovepdf Merged Compressed

Uploaded by

Copyright:

Available Formats

CSE3001 SOFTWARE ENGINEERING

4. Object Oriented Design

5. User Interface Design

• Design phase transforms SRS document:

SRS Document Design Documents

• Design activities are usually classified into two stages:

• There is no unique way to design a system.

• A functionally independent module:

• The mathematical subroutine such as “calculate current GPA” or

• Example of control coupling:

• Module A and B are said to be control coupled if they communicate by

• Example of control coupling:

• Module A and B are said to be control coupled if they communicate by

• Content coupling occurs when module A changes data of module B or

• Library Automation Software:

• Similar objects constitute a class.

• Classes may inherit features

• Conceptually, objects communicate by message passing.

• To illustrate the differences between object-oriented and function-

• We need to develop a computerized fire alarm system for a large multi-

Det ect or Indicat or

Securit y Surveillance Home

GUI Int ernet

Cont rol det ect or alarm

Cont rol det ect or alarm

 results in software that is easier to test

working from the boundary outward, map

add control modules as required

refine the resultant program structure

typical "worker" modules

input processing output

mapping from the D

 Place the user in control

no ref ills ch e cks p at ie n t

ref ill not

List of user object ives

Home page text copy

 Another widely quoted definition of software architecture given by Bass,

1) All the requirements are partitions into different categories,

2) Sub system are identified,

3) Requirements are assigned to different sub system,

4) The functionality of each sub system is specified and

5) Interface design is created for enabling communication between sub systems.

Here relationships between different sub systems are identified.

Interface description is defined and documented

Data structure required to implement system is described in details.

Algorithms used to deliver services are defined.

B. A sub system consists of set of modules, provides set of services and it is

C. Modules of the system are used to depict Development View.

D. Deployment diagrams depicting servers are used to show physical view of

 Logical view: It is the functionality that the system provides to end-users. So it is an

 Development view: It depicts a system from a programmers perspective. It is

 Layered Architectural Style

 In relaxed layering style, components can interact with components of same

 MVC pattern has three parts:

 N-Tier / 3-Tier Architectural Style

It is a modular decomposition architectural style which is applied at

This architecture is based on breaking the responsibilities of an application

 Inheritance:- No need to write functionality already addressed by some objects by a new

 Encapsulation: - The objects functionality is provided through their operations and

 Decoupling: An abstract interface provided by object decouples it from consumer or caller

 These days in each transaction based application where payment is involved,

 It is an example of distributed architecture systems which can support resource