VI

CSE1005 SOFTWARE T

DESIGN &
DEVELOPEMENT
UNIT – 3:
DR. M. MADIAJAGAN
ASSOCIATE PROFESSOR / SCOPE
VIT
1

Dr. M. Madiajagan Associate Professor, SCOPE, VIT

 SYLLABUS VI
T
• Requirement Modeling:
 Requirement Analysis
Requirement Analysis
Domain Analysis
Elements of Requirement Analysis

VIT
Scenario-Based Modeling

Associate Professor, SCOPE,

Dr. M. Madiajagan
Use Case Diagram, Activity Diagram,
Swimlane Diagram,
Data Modeling
CRC Modeling ( Class-Responsibility-
Collaborator) 2
 Requirement Analysis VI
T
• Requirements analysis
• specifies software’s operational characteristics
• indicates software's interface with other system
elements
• establishes constraints that software must meet
• Requirements analysis allows the software

VIT
engineer (called an analyst or modeler in this

Associate Professor, SCOPE,

Dr. M. Madiajagan
role) to:
• elaborate on basic requirements established during
earlier requirement engineering tasks
• build models that depict user scenarios, functional
activities, problem classes and their relationships,
system and class behavior, and the flow of data as it is 3
transformed.
 Bridge:-

Dr. M. Madiajagan
T

Associate Professor, SCOPE,

VI

VIT
Rules VI
• The model should focus on requirements that are T
visible within the problem or business domain. The
level of abstraction should be relatively high.
• Each element of the analysis model should add to
an overall understanding of software requirements
and provide insight into the information domain,
function and behavior of the system.

VIT
• Delay consideration of infrastructure and other

Associate Professor, SCOPE,

Dr. M. Madiajagan
non-functional models until design.
• Minimize coupling throughout the system.
• Be sure that the analysis model provides value to
all stakeholders.
• Keep the model as simple as it can be. 5
Domain Analysis VI
T

Software domain analysis is the identification, analysis, and

specification of common requirements from a specific

application domain, typically for reuse on multiple projects

VIT
within that application domain . . . [Object-oriented domain

Associate Professor, SCOPE,

Dr. M. Madiajagan
analysis is] the identification, analysis, and specification of

common, reusable capabilities within a specific application

domain, in terms of common objects, classes, subassemblies,

and frameworks . . . 6
by Donald Firesmith
 VI
Domain Analysis … T

• Define the domain to be investigated.

• Collect a representative sample of
applications in the domain.

VIT
Associate Professor, SCOPE,
• Analyze each application in the

Dr. M. Madiajagan
sample.
• Develop an analysis model for the
objects.
7
 Elements of Requirements Analysis

Dr. M. Madiajagan
T

Associate Professor, SCOPE,

VI

VIT
Scenario-Based Modeling VI
T
• “[Use-cases] are simply an aid to defining
what exists outside the system (actors) and
what should be performed by the system
(use-cases).” Ivar Jacobson

VIT
• (1) What should we write about?

Associate Professor, SCOPE,

Dr. M. Madiajagan
• (2) How much should we write about it?
• (3) How detailed should we make our
description?
• (4) How should we organize the description?
9
What to Write About? VI
T

• Inception and elicitation—provide you with the

information you’ll need to begin writing use cases.
• Requirements gathering meetings, QFD, and other
requirements engineering mechanisms are used to
• identify stakeholders
• define the scope of the problem

VIT
• specify overall operational goals

Associate Professor, SCOPE,

Dr. M. Madiajagan
• establish priorities
• outline all known functional requirements, and
• describe the things (objects) that will be manipulated
by the system.
• To begin developing a set of use cases, list the functions
or activities performed by a specific actor.
10
How Much to Write About? VI
T

As further conversations with the

stakeholders progress, the requirements
gathering team develops use cases for
each of the functions noted.

VIT
In general, use cases are written first in

Associate Professor, SCOPE,

Dr. M. Madiajagan
an informal narrative fashion.
If more formality is required, the same
use case is rewritten using a structured
format similar to the one proposed. 11
UML - Building Blocks VI
T
• As UML describes the real-time systems, it is very important
to make a conceptual model and then proceed gradually. The
conceptual model of UML can be mastered by learning the
following three major elements −
• UML building blocks
• Rules to connect the building blocks

VIT
• Common mechanisms of UML

Associate Professor, SCOPE,

Dr. M. Madiajagan
The building blocks of UML can be defined as
−
 Things
 Relationships
 Diagrams 12
• Things are the most important building blocks of UML. VI
Things can be − T
• Structural
• Behavioral
• Grouping
• Annotational
• Structural Things

VIT
• Structural things define the static part of the model. They

Associate Professor, SCOPE,

Dr. M. Madiajagan
represent the physical and conceptual elements. Following are
the brief descriptions of the structural things.
• Class − Class represents a set of objects having similar
responsibilities.

13
 VI
Interface − Interface defines a set of operations, which specify
T
the responsibility of a class.

Collaboration −Collaboration defines an interaction between

elements.

Use case −Use case represents a set of actions performed by a

system for a specific goal.

VIT
Associate Professor, SCOPE,
Dr. M. Madiajagan
Component −Component describes the physical part of a
system.

Node − A node can be defined as a physical element that exists at

run time.
14
Behavioral Things VI
• A behavioral thing consists of the dynamic parts of UML T
models. Following are the behavioral things −
• Interaction − Interaction is defined as a behavior that consists of
a group of messages exchanged among elements to accomplish a
specific task.

State machine − State machine is useful when the state of an

VIT
object in its life cycle is important. It defines the sequence of states

Associate Professor, SCOPE,

an object goes through in response to events. Events are external

Dr. M. Madiajagan
factors responsible for state change

15
• Grouping Things:- VI
• Grouping things can be defined as a mechanism to group T
elements of a UML model together. There is only one grouping
thing available −
• Package − Package is the only one grouping thing available for
gathering structural and behavioral things.

• Annotational Things:-

VIT
Associate Professor, SCOPE,
• Annotational things can be defined as a mechanism to capture

Dr. M. Madiajagan
remarks, descriptions, and comments of UML model
elements. Note - It is the only one Annotational thing
available. A note is used to render comments, constraints, etc.
of an UML element.

16
• Relationship:- VI
• Relationship is another most important building block of UML. It T
shows how the elements are associated with each other and this
association describes the functionality of an application.
• There are four kinds of relationships available.
• Dependency
• Dependency is a relationship between two things in which change in
one element also affects the other.

VIT
Associate Professor, SCOPE,
• Association is basically a set of links that connects the elements of a

Dr. M. Madiajagan
UML model. It also describes how many objects are taking part in that
relationship.

• Generalization can be defined as a relationship which connects a

specialized element with a generalized element. It basically describes
the inheritance relationship in the world of objects.
17
 VI
• Realization
T
• Realization can be defined as a relationship in
which two elements are connected. One element
describes some responsibility, which is not
implemented and the other one implements them.
This relationship exists in case of interfaces.

VIT
• All the elements, relationships are used to make a

Associate Professor, SCOPE,

Dr. M. Madiajagan
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 complete.
18
• UML includes the following nine diagrams
UML includes the following nine diagrams:- VI
• Class diagram T

• Object diagram
• Use case diagram
• Sequence diagram
• Collaboration diagram

VIT
• Activity diagram

Associate Professor, SCOPE,

Dr. M. Madiajagan
• Statechart diagram
• Deployment diagram
• Component diagram

19
UML - Modeling Types VI
There are three important types of UML modeling.:-
T
• Structural Modeling:- captures the static features of a system.
They consist of the following −
• Classes diagrams
• Objects diagrams
• Deployment diagrams
• Package diagrams

VIT
• Composite structure diagram

Associate Professor, SCOPE,

• Component diagram

Dr. M. Madiajagan
Structural model represents the framework for the system and this
framework is the place where all other components exist.
Hence, the class diagram, component diagram and deployment
diagrams are part of structural modeling. 
The structural model never describes the dynamic behavior of the
system. Class diagram is the most widely used structural diagram.
20
 VI
• Behavioral Modeling T
• Behavioral model describes the interaction in the system. It
represents the interaction among the structural diagrams.
Behavioral modeling shows the dynamic nature of the system.
They consist of the following −
• Activity diagrams
• Interaction diagrams
• Use case diagrams

VIT
• All the above show the dynamic sequence of flow in a system.

Associate Professor, SCOPE,

• Architectural Modeling

Dr. M. Madiajagan
• Architectural model represents the overall framework of the
system. It contains both structural and behavioral elements of the
system. Architectural model can be defined as the blueprint of the
entire system. Package diagram comes under architectural
modeling.
21
Use-Cases VI
T
• a scenario that describes a “thread of
usage” for a system
• actors represent roles people or devices
play as the system functions

VIT
• users can play a number of different roles

Associate Professor, SCOPE,

Dr. M. Madiajagan
for a given scenario

22
 VI
Developing a Use-Case T

• What are the main tasks or functions that are

performed by the actor?
• What system information will the actor acquire,
produce or change?
• Will the actor have to inform the system about

VIT
Associate Professor, SCOPE,
changes in the external environment?

Dr. M. Madiajagan
• What information does the actor desire from the
system?
• Does the actor wish to be informed about
unexpected changes?
23
USE-CASE DIAGRAM VI
T
The notation for a use diagram is pretty
straightforward and doesn't involve as many
types of symbols as other UML diagrams
Use cases - Use cases are the horizontally
shaped ovals.
Actors - represented by stick figure people and
are the people actually employing the use cases

VIT
Associations - represented by a line between

Associate Professor, SCOPE,

Dr. M. Madiajagan
actors and use cases. In a more complex
diagram, it is important to know which actors
are associated with which use cases.
System boundary boxes - a box that sets a
system scope to use cases. All use cases outside
the box would be considered outside the scope
24
of that system.
 Examples -UML…

Dr. M. Madiajagan
T

Associate Professor, SCOPE,

25
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

26
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

27
VI

VIT
 USE-CASE for CONFERENCE PROGRAM
CHAIR

Dr. M. Madiajagan
T

Associate Professor, SCOPE,

28
VI

VIT
Activity Diagram VI
• Supplements the use case by providing a graphical T
representation of the flow of interaction within a specific
scenario

VIT
Associate Professor, SCOPE,
Dr. M. Madiajagan
29
 Where to Use Activity Diagrams? VI
Activity diagram is suitable for modeling the activity T
flow of the system. An application can have multiple
systems.
Activity diagram also captures these systems and
describes the flow from one system to another.
This specific usage is not available in other diagrams.

VIT
These systems can be database, external queues, or any

Associate Professor, SCOPE,

other system.

Dr. M. Madiajagan
This diagram is used to model the activities which are
nothing but business requirements.
The diagram has more impact on business
understanding rather than on implementation details.
30
 VI
•Activity diagram can be used for − T

•Modeling work flow by using activities.

•Modeling business requirements.
•High level understanding of the
system's functionalities.

VIT
Associate Professor, SCOPE,
•Investigating business requirements at a

Dr. M. Madiajagan
later stage.

31
Concurrent Flows in VI
Activity Diagram:- T
You can use the Fork Node and
the Join Node to describe two or
more threads of activities that can
execute at the same time. The effect
of the Fork Node (1) is to divide
the thread of control into two or
more threads. When the previous
action ends, all the actions on the

VIT
output side of the fork can start.

Associate Professor, SCOPE,

A Join Node (2) brings concurrent

Dr. M. Madiajagan
threads together. The action after
the Join Node may not start until all
the actions leading to the Join
Node are complete.

32
Basic Activity Diagram Notations and Symbols VI
Initial State or Start Point T
Activity or Action State: An action state represents the non-
interruptible action of objects-
a rectangle with rounded corners

Action Flow :

VIT
Object Flow: refers to the creation and modification of objects

Associate Professor, SCOPE,

Dr. M. Madiajagan
by activities. An object flow arrow from an action to an object
means that the action creates or influences the object. An object
flow arrow from an object to an action indicates that the action
state uses the object.

33
Decisions and Branching VI
When an activity requires a decision prior to moving on to the T
next activity, add a diamond between the two activities.

Synchronization
A fork node is used to split a single incoming flow into multiple
concurrent flows. A join node joins multiple concurrent flows

VIT
back into a single outgoing flow.A fork and join mode used

Associate Professor, SCOPE,

together are often referred to as synchronization.

Dr. M. Madiajagan
34
• Time Event VI
This refers to an event that stops the flow for a time; an T
hourglass depicts it.

Merge Event
A merge event brings together multiple flows that are not
concurrent.

VIT
• Sent and Received Signals

Associate Professor, SCOPE,

• Signals represent how activities can be modified from outside the

Dr. M. Madiajagan
system. They usually appear in pairs of sent and received signals,
because the state can't change until a response is received, much
like synchronous messages in a sequence diagram. 

35
Swimlanes: Swimlanes group related activities into one column. VI
T

VIT
Associate Professor, SCOPE,
Dr. M. Madiajagan
• Final State or End Point
36
An arrow pointing to a filled circle nested inside another circle
represents the final action state.
Data Modeling:- VI
T
examines data objects independently of processing
focuses attention on the data domain
creates a model at the customer’s level of abstraction
indicates how data objects relate to one another
What is a Data Object?
• a representation of almost any composite information that must be
understood by software.

VIT
• composite information—something that has a number of different
properties or attributes

Associate Professor, SCOPE,

• can be an external entity (e.g., anything that produces or consumes

Dr. M. Madiajagan
information), a thing (e.g., a report or a display), an occurrence
(e.g., a telephone call) or event (e.g., an alarm), a role (e.g.,
salesperson), an organizational unit (e.g., accounting department),
a place (e.g., a warehouse), or a structure (e.g., a file).
• The description of the data object incorporates the data object and
all of its attributes.
• A data object encapsulates data only—there is no reference within
a data object to operations that act on the data. 37
Data Objects and Attributes VI
T
A data object contains a set of attributes that
act as an aspect, quality, characteristic, or
descriptor of the object

object: automobile
attributes:

VIT
Associate Professor, SCOPE,
make

Dr. M. Madiajagan
model
body type
price
options code 38
What is a Relationship? VI
T
• Data objects are connected to one another in
different ways.
• A connection is established between
person and car because the two objects
are related.
• A person owns a car

VIT
• A person is insured to drive a car

Associate Professor, SCOPE,

Dr. M. Madiajagan
• The relationships owns and insured to drive
define the relevant connections between
person and car.
• Several instances of a relationship can exist
• Objects can be related in many different ways 39
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

40
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

41
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

42
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

43
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

44
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

45
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

46
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

47
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

48
VI

VIT
Interaction View:
VI
Sequence Diagram and Collaboration Diagram T

VIT
Associate Professor, SCOPE,
Dr. M. Madiajagan
49
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

50
VI

VIT
 Collaboration Diagram:-

Dr. M. Madiajagan
T

Associate Professor, SCOPE,

51
VI

VIT
 Kind of Classifier

Dr. M. Madiajagan
T

Associate Professor, SCOPE,

52
VI

VIT
 Kind of Relationship

Dr. M. Madiajagan
T

Associate Professor, SCOPE,

53
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

54
VI

VIT
 VI
Generalization and inheritance permits different T
classifiers to share the attributes, operations and
relationship that they have in common, without
repetition.

VIT
Associate Professor, SCOPE,
Dr. M. Madiajagan
The dependency relationship relates classes whose
behaviour or implementation affects other classes. There are
several kinds of dependency in addition to realization,
including trace, refinement, usage, and binding. 55
 VI
Associations: T
An Association describes discrete connections among objects or
other instances in a system. An Association relates an ordered list
(tuple) of two or more classifiers, with repetitions permitted. An
instance of an association is a link. Associations are the “glue”
that ties a system together.

VIT
Associate Professor, SCOPE,
Dr. M. Madiajagan
56
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

57
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

58
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

59
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

60
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

61
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

62
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

63
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

64
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

65
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

66
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

67
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

68
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

69
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

70
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

71
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

72
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

73
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

74
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

75
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

76
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

77
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

78
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

79
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

80
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

81
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

82
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

83
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

84
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

85
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

86
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

87
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

88
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

89
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

90
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

91
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

92
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

93
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

94
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

95
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

96
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

97
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

98
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

99
VI

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

VI

100

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

VI

101

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

VI

102

VIT
 Dr. M. Madiajagan
T

Associate Professor, SCOPE,

VI

103

VIT
 VI
Further Queries!!! T

• Any Questions ? ? ?
• Otherwise - contact me in my chamber:
SJT-6thFloor – 613-K.

VIT
Associate Professor, SCOPE,
Dr. M. Madiajagan
104