SOFTWARE ENGINEERING

UNIT 2.1
REQUIREMENT ANALYSYS/MODELING

1
REQUIREMENT MODELING

 What : combination of text and diagrams to depict requirements in a way that is easy to understand,
straightforward to review for correctness, completeness, and consistency.
 Who : Software engineering builds the model using requirements elicited from users.
 Why : Software examined from different perspective : scenario-based, data-based and class-based
model.
 Work product : requirement models.

2
SA/SD METHODOLOGY
 Structured Analysis/Structured Design (SA/SD) technique draws heavily from the design methodologies
proposed by the following authors:
 DeMarco & Yourdon [1978], Constantine & Yourdon [1979], Gane & Sarson [1979], Hatley & Pirbhai [1987]
 The SA/SD technique can be used to perform the high-level design of a software.
 During structured analysis, the SRS document is transformed into a data flow diagram (DFD) model.
 During structured design, the DFD model is transformed into a structure chart.

3
STRUCTURED ANALYSIS

 Principles:
➢ Top-down decomposition approach.
➢ Application of divide and conquer principle.
➢ Graphical representation of the analysis results using data flow diagrams (DFDs).

4
DATA FLOW DIAGRAM (DFD)

 DFD or bubble chart is graphical representation of flow of data or information through a process or system.
 A DFD is a hierarchical graphical model of a system that shows the different processing activities or functions
that the system performs and the data interchange among those function
 It approaches Function-oriented design methodology.
 It clarifies system requirements and identifies major transformations.
 It also gives insight into the inputs and outputs of each entity and the process itself.
 DFD does not have control flow or execution sequence and no loops or decision rules are present.
 It represents system at different level of abstraction.
 It may be portioned into levels that represent increasing information flow and functional details.
 It provides an overview of
• What data is system processes, What transformation are performed.
5
• What data are stored., What results are produced , etc.
 DE MARCO NOTATIONS FOR DFD

Data flow b/w two processes or b/w external entity and process

Human user, H/w, S/w, interact with system

Provide Input to system or consume output from system
or Function Input →Process → Output
Data store or

or Database
External entity or

or Input/Output

6
LEVEL 0 DFD

 Also known as context diagram.

 This is the highest-level DFD, which
provides an overview of the entire system.
 It shows the major processes, data flows,
and data stores in the system, without
providing any details about the internal
workings of these processes.
 Abstraction view, showing the system as a
single process with its relationship to
external entities.
 It represents the entire system as a single
bubble with input and output data indicated
by incoming/outgoing arrows.
7
CONTEXT DIAGRAM

 It represents the entire system as a single bubble.

 This bubble is annotated with the name of the software system being developed (usually a noun).
 This is the only bubble in a DFD model, where a noun is used for naming the bubble.
 The bubbles at all other levels are annotated with verbs according to the main function performed by
the bubble.
 Purpose of the context diagram is to capture the context of the system rather than its functionality.
 To develop the context diagram of the system, we have to analyze the SRS document :
 To identify the different types o f users who would be using the system and the kinds of data they
would be inputting to the system and the data they would be receiving from the system.
 Users of the system also includes any external systems which supply data to or receive data from the8
system.
9
 LEVEL 1 DFD
 It represents the main functions of the
system and how they interact with each
other.
 This level provides a more detailed view
of the system by breaking down the
major processes identified in the level 0
DFD into sub-processes.
 Each sub-process is depicted as a
separate process on the level 1 DFD.
 The data flows and data stores
associated with each sub-process are
also shown.

10
LEVEL 1 DFD

 Usually contains three to seven bubbles.

 Examine the high-level functional requirements in the SRS document.
 What if more than seven high-level requirements identified in the SRS document?
 In this case, some of the related requirements have to be combined and represented as a single bubble in the level
1 DFD. These can be split appropriately in the lower DFD levels.
 What if a system has less than three high-level functional requirements?
 Then some of the high-level requirements need to be split into their subfunctions so that we have roughly about
five to seven bubbles represented on the diagram.

11
12
LEVEL 2 DFD
 It represents processes within each
functions of the system and how they
interact with each-other.
 This level provides an even more
detailed view of the system
 by breaking down the sub-processes
identified in the level 1 DFD into further
sub-processes.
 Each sub-process is depicted as a
separate process on the level 2 DFD.
 The data flows and data stores
associated with each sub-process are
also shown.
13
DATA FLOW DIAGRAM(DFS)
 Key points:
 Context diagram should depict the system as a single bubble.
 All external entities interacting with the system should be represented only in the context diagram.
 The external entities should not appear in the DFDs at any other level.
 DFDs at the different levels of a DFD model must be balanced.
 Only three to seven bubbles per diagram should be allowed.
 Do not attempt to represent control information in a DFD.
 A data flow arrow should not connect two data stores or even a data store with an external entity.
 The data and function names must be intuitive.
 Not to consider when or condition under which function is invoked or in what order different functions
(processes) are invoked.
 Too many data flowing in or out of DFD, it is better to combine these data items into a high-level data item.
14
15
16
17
SUPERMARKET PRIZE SCHEME

 A super market needs to develop a software that would help it to automate a scheme that it plans to
introduce to encourage regular customers.
 In this scheme, a customer would have first register by supplying his/her details.
 Each customer who registers for this scheme is assigned a unique customer number (CN) by the
computer.
 A customer can present his CN to the check out staff when he makes any purchase.
 Value of his purchase is credited against his CN.
 At the end of each year, the supermarket intends to award surprise gifts to 10 customers who make
the highest total purchase over the year.
 Also, it intends to award a 22 caret gold coin to every customer whose purchase exceeded Rs.
10,00,000.
 The entries against the CN are reset on the last day of every year after the prize winners’ lists are
18

generated.
Context Diagram

Level-1Diagram 19

Level- 2 Diagram
DATA FLOW DIAGRAM (DFD)
 The bubbles are decomposed into subfunctions at the successive levels of the DFD model.
 Construction of context diagram:
➢ Examine the SRS document to determine:
➢ Different high-level functions that the system needs to perform.
➢ Data input, Data output, Interactions (data flow) to every high-level function.
 Construction of level 1 diagram:
➢ Examine the high-level functions described in the SRS document.
➢ If there are three to seven high-level requirements in the SRS document, then represent each with a bubble.
➢ If more than seven bubbles, combine and If less than three bubbles, split.
 Construction of lower-level diagrams:
➢ Decompose each high-level function into its constituent subfunctions through: 20

➢ Identify the Data input, Data output, Interactions of the subfunctions.

DATA FLOW DIAGRAM (DFD)

 For simple problems, decomposition up to level 2 should suffice.

 Numbering of bubbles:
 These numbers help in uniquely identifying any bubble in the DFD from its bubble number.
 The bubble at the context level is usually assigned the number 0 to indicate that it is the 0 level DFD.
 Bubbles at level 1 are numbered, 0.1, 0.2, 0.3, etc. and at level 2, it is 0.1.1, 0.1.2, 0.1.3, etc.`
 When a bubble numbered x is decomposed, its children bubble are numbered x.1, x.2, x.3, etc
 Balancing a DFD:
 The data that flow into or out of a bubble must match the data flow at the next level of DFD.

21
DFD

Dos Don’ts

22
FOOD ORDER SYSTEM - DFD

23
CONTROL FLOW DIAGRAM (CFD)

 Also known as control flow chart or flow chart.

 It is a graphical representation of how control flow (order of execution) during the execution of a program.

24
UML

 UML is a language for documenting models.

 UML is primarily a graphical modeling tool.
 It provides a set of basic graphical notations that can be combined in certain ways to
document the design and analysis results.
 UML can be used to document object-oriented analysis and design results that have
been obtained using any methodology.
 Many of the UML notations are difficult to draw by hand on a paper and are best
drawn using a CASE tool.
25
MODELING

 It is an abstraction of a real problem , and is constructed by leaving out

unnecessary details.
 This reduces the problem complexity.
 To develop a good understanding of any problem, it is necessary to construct a
model of the problem.
 Graphical models are very popular because they are easy to understand and
construct.
 It reduces the design costs.
 Theses model can be used in Analysis, Specification, Design, Coding, Visualization, and,
26

Testing, etc.
UML DIAGRAM

 UML 1.0 can be used to construct nine

different types of diagrams to capture five
different views of a system.
 UML diagrams can capture the following
views (models) of a system:
 User’s view
 Structural view
 Behaviourial view
Different types of diagrams and views supported in UML
 Implementation view
 Environmental view
27
VIEWS (MODELS) OF A SYSTEM

 User’s view : view of the system in terms of the functionalities offered by the system to its
users.
 Structural view : structure of problem in terms of kinds of objects (classes) & its
relationship.
static model, since the structure of a system does not change with time.
 Behavioral view : interaction of objects with each other to realize the system behavior.
captures the time-dependent (dynamic) behavior of the system.
 Implementation view : important components of the system and their
interdependencies.
 Environmental view : different components are implemented on different pieces of
28
hardware.
 UML DIAGRAM CLASSIFICATION

 There are two broad categories of diagrams, - Structural Diagrams and Behavioral Diagrams.
 Structural diagrams ▪ Behavioral diagram
 It represent the static aspect of system.  It capture the dynamic aspect of system.
➢ Class diagram ➢ Use case diagram
➢ Object diagram ➢ Sequence diagram
➢ Component diagram ➢ Collaboration diagram
➢ Deployment diagram ➢ State chart diagram
➢ Activity diagram
 Another classification of UML diagram is:
 Static: Use case diagram, Class diagram and Object diagram
 Dynamic: State diagram, Activity diagram, Sequence diagram, Collaboration diagram 29

 Implementation: Component diagram and Deployment diagram

30
USE CASE MODEL

 The use case model for any system consists of a set of use cases.
 The use cases represent functions performed by the actors interacting with the system.
 A simple way to find all the use cases of a system is to ask the question —
“What can the different categories of users do by using the system?”
▪ It correspond to the high-level functional requirements.
▪ In contrast to all other types of UML diagrams, use case model represents functional or
process model of system.

31
REPRESENTATION OF USE CASE DIAGRAM

 It is a behavioral diagram.
 Each use case is represented by an ellipse with name of the use case written inside the ellipse.
 All use cases of system are enclosed within a rectangle which represents the system boundary.
 Name of system being modeled (e.g., library information system ) appears inside rectangle.
 Anything within the box represents functionality that is in scope and anything outside the box is
not.
 An actor is a role played by a user with respect to the system use.
 Consists of one main line sequence (interactions between a user and the system that normally
take place) and several alternate sequences (Several variations to the main line sequence).
 A sequence corresponding to the invocation of a use case is called a scenario of the use case.
32
USE CASE - TEXT DESCRIPTION

 Every use case diagram should be accompanied by a text description.

 It should define the details of the interaction between the user and the use case.
 It should include all the behavior associated with the use case in terms of the
mainline sequence, various alternate sequences, the system responses associated with
the use case, the exceptional conditions that may occur in the behavior, etc.
 Some of the information may be included in a use case text description in addition to
the mainline sequence, and the alternate scenarios :
 Actors’ information, pre-condition, post-condition, non-functional requirements,
exceptions, error situations, document references.
33
USE CASE DIAGRAM NOTATIONS
what is being described? (system),
who is using the system? (actors)
what do actors want to achieve? (use cases)
Domain specific notation in
addition to those standard ones. (Stereotype)
Stereotype – include & extend
Steps to generate use case diagram:
Step 1 : List out all the possible actors who can interact with system.
Step 2 : List out all the possible interactions (use cases), that each actor
can perform with the system.
Step 3 : List out mainline sequence and alternate sequences for association.
Step 4 : List out includes and extends relationship for use cases. 34

Step 5 : Do generalization of actors and use cases.

USE CASE RELATIONSHIP

 There can be 5 relationship types in a use case diagram.

➢ Association between actor and use case
➢ Generalization of an actor
➢ Extend between two use cases
➢ Include between two use cases
➢ Generalization of a use case

35
ASSOCIATION BETWEEN ACTOR AND USE CASE

 Association is relationship between an actor and a use case.

 Indicates that an actor can use the functionality of system.
 line connecting an actor and the use case is called the
communication relationship.
 An actor must be associated with at least ne use case.,
 An actor can be, associated with multiple use cases,
 Multiple actors can be associated with a single use case.
 Actors can be – primary or secondary.
 Actor can be Human, Systems / Software, Hardware ….
36
GENERALIZATION OF AN ACTOR

 One actor can inherit the role of

the other actor,
 descendant inherits all the use
cases of the ancestor,
 descendant has one or more use
cases that are specific to that role.

37
INCLUDE BETWEEN TWO USE CASES

 Included use case is part of the including

(base) use case,
 Main reason for this is to reuse common
actions across multiple use cases,
 The base use case is incomplete without
the included use case,
 The included use case is mandatory and
not optional.
 Include relationship or inclusion use cases
or implicit function.
 Represented using a predefined
stereotype <<include>>.
38
EXTEND BETWEEN TWO USE CASES

 Extends base use case and adds more

functionality to the system,
 The extending use case is dependent on the
extended (base) use case,
 The extending use case is usually
optional and can be triggered conditionally,
 The extended (base) use case must be
meaningful on its own.
 Extend relationship or extension use cases
or explicit function.
 Represented using a predefined stereotype
<<extend>>.
39
GENERALIZATION OF A USE CASE

 The behavior of the ancestor is inherited by the

descendant.
 This is used when there is common behavior
between two use cases and specialized behavior
specific to each use case.
 General use case is abstract. It can not be
instantiated, as it contains incomplete information.
 The title of an abstract use case is shown in italics.
 Use case generalization can be used when you have
one use case that is similar to another but does
something slightly differently or something more.
40
USECASE DIAGRAM

41
CLASS DIAGRAMS

 It is a structural diagram.
 It describes the static view/aspect/structure of a system.
 Object oriented view of the system
 It comprises a number of class diagrams and their dependencies.
 The main constituents of a class diagram are classes and their relationships—
 Visibility notations – (+→ public ; - → private ; # → protected)
 generalisation, aggregation, association, and various kinds of
dependencies.
42
 CLASS DIAGRAM

 Classes represent entities with

attributes and operations.
 Represented as solid outline
rectangles with compartments.
 Class names are usually chosen to
be singular nouns.
 Classes have a mandatory class
name compartment, optional
attributes and operations
compartments.

43
CLASS DIAGRAM

 Attributes:  Operations:

 named property of a class  written in italics.

 Attributes are listed with their names, and may  parameters of a function may have a kind specified.
optionally contain specification of their type , an initial  “in” - parameter is passed into the operation; or
value, and constraints. “out” - parameter is only returned from operation;
 An attribute without square brackets must hold  “inout” - parameter is used for passing data into the
exactly one value. operation and getting result from the operation.

 square brackets contains a multiplicity expression,  return type consisting of a single return type
expression.
 initialisation expression.
 issueBook(in bookName):Boolean
 sensorStatus[1]:Int=0  class scope (i.e., shared among all the objects of the
class) and is denoted by underlining the operation
44
name.
CLASS DIAGRAM RELATIONSHIP

 There can be 5 relationship types in a class diagram.

Steps to generate class diagram:
➢ Association
Step 1 : List out all the possible objects for the system.
➢ Dependency Step 2 : Mention name, attributes and operations of objects.
Step 3 : Mention interactions between objects for association.
➢ Aggregation Step 4 : Perform dependency, aggregation , composition of objects.
➢ Composition
➢ Generalization and Specialization

45
 ASSOCIATION
 It depicts static relationship b/w classes.
 Represented by drawing a labelled straight line, with direction, between the concerned classes.
 An arrowhead placed on the association line indicates the reading direction of the association.
 On each side of association relation, multiplicity is noted as an individual number or as a value range.
 Multiplicity indicates how many instances of one class are associated with the other.
 Value ranges of multiplicity noted by specifying min and max value, separated by two dots, e.g. 1..5, 1..*
 An asterisk is used as a wild card and means many (zero or more).
 Read as “Many books may be borrowed by a LibraryMember”.
 0..1→Zero or one, 1→One only, * or 0..*→Zero or more, 1..*→One or more, 7→Seven only, 4..7→Four to seven

46
DEPENDENCY

 It is shown as a dotted arrow that is drawn from the dependent class to the independent class.

47
 AGGREGATION
 Special type of association relation where the involved classes are not only associated to each other,
but a whole-part relationship exists between them. (has-a relationship)
 Represented by an empty diamond symbol at the aggregate end of a relationship.
 There is no strong dependency from contained class to container class(books exist without library)
 It cannot be reflexive (i.e. recursive), an object cannot contain objects of the same class as itself.
 It is not symmetric.That is, two classes A and B cannot contain instances of each other.
 It can be transitive. In this case, aggregation may consist of an arbitrary number of levels.
 Numbering notation on the line indicates, one document can have many paragraphs.

48

Whole or container class Part or contained class

 COMPOSITION
 Stricter form of aggregation, parts class are existence-dependent on the whole class.
 Life of the parts cannot exist outside the whole.
 When the whole is created, the parts are created and when the whole is destroyed, the parts are
destroyed.
 Represented as a filled diamond drawn at the composite-end.
 Like, order object where after placing the order, no item in the order cannot be changed.
 As soon as an order object is created, all the order items in it are created and as soon as the order
object is destroyed, all order items in it are also destroyed.

49
 GENERALIZATION / SPECIALIZATION
 Generalization - extracting shared
characteristics from two or more classes, and
combining them into a generalized superclass.
 Specialization means creating new subclasses
from an existing class.
 If it turns out that certain attributes,
associations, or methods only apply to some of
the objects of the class, a subclass can be
created.
 The most inclusive class in a
generalization/specialization is called the
superclass and is generally located at the top of
the diagram.
 The more specific classes are called subclasses 50

and are generally placed below the superclass.

 INHERITANCE
 Represented by means of an empty arrow pointing from the subclass to the superclass.
 The set of subclasses of a class having the same discriminator is called a partition.
 It is often helpful to mention the discriminator during modelling, as these become documented design
decisions.

51
CONSTRAINTS

 Condition or an integrity rule.

 Permissible set of values of an attribute, to specify the pre- and post-conditions for
operations, to define certain ordering of items, etc.
 UML allows you to use any free form expression to describe constraints, to be
enclosed within braces.

52
CLASS DIAGRAM

53
CLASS DIAGRAM

54
OBJECT DIAGRAMS

 Snapshot of objects in a system at a point in time.

 Static view of system at given time instance.
 Shows instances of classes and its interaction at
specific time,
 rather than the classes themselves, it is often called
Anonymous object
as an instance diagram. The objects are drawn
using rounded rectangles
 It may undergo continuous change as execution
proceeds.
 Object diagrams are useful to explain the working
of a system.
55
 All class relationships are also applicable to object
diagrams also.
OBJECT DIAGRAM

56
STATE DIAGRAM
 Also known as state machine or state chart diagram.
 Gives system’s behavior, dynamic nature & models lifetime of reactive
system.
 Gives state dependent behavior of an object.
 Object reacts differently to the same event, depending on the state in which the
object currently is.
 State – situation or movement in lifespan or lifecycle of an object or way an object
exists at a time.
 State name – unambiguous (relevant to system/scenario.)
 Identify or analyze all the different states through which an object will go through,
57

before making a state diagram.

STATE DIAGRAM
 Event – When an event occurs, it triggers an action/activity, so object moves from
one state to another state (Transition).
 Activity – During transition, object will perform an activity.
 Self transition – Transition to same state.
 Initial state – state from where life span of an object starts, starting point of state
machine diagram.
 Final or End state – state at which life span of an object sends , Termination point of
state machine diagram.
 Decision box – Helps objects to take decision in transition from one state to
another state.
 It visualizes an object’s state from its creation to its termination.
State diagrams are drawn for a single class to show the lifetime behavior of a single
58

object.
 If [balance > amount] then …

59
External Transition :
Termination : X
STATE DIAGRAM
 Guard condition is Boolean expression evaluated when trigger event occurs,
 If condition is true, it transits to new state else remains in the same state.
 For an event called online purchase, different states can be login, select the items,
put it in wish list or cart, create order, payment, shipment, parcel received.
 Step 1 : Define the states or conditions that an object might be in, any point of time.
 Step 2 : Describe the states – name, and entry, do , and exit activity.
 Step 3 : Define transitions, from one state to another.
 Step 4 : Define events and activity set triggers transition.
 Step 5 : Define constraints on transition.
60

 Step 6 : Define composite state.

Object - Button
61
62
63
64
ACTIVITY DIAGRAM

 It is behavioral diagram, so represents dynamic aspect.

 It is basically a flow chart to represent the flow of control form among activities in a system.
 Use case, Communication, Sequence and class diagram shows messages transition between
objects.
 Activity shows message transition among different activities.
 The flow of operation can be sequential, branched or concurrent.
 It describe activities which involve concurrency and synchronization,
 which are a variation of state diagrams that focuses on the flow of actions and events.
65
ACTIVITY DIAGRAM NOTATIONS

Helps in concurrent execution of activities

or concurrency or parallelism .

66
ONLINE PURCHASE – ACTIVITY DIAGRAM

67
BOOK ISSUE/BORROW – ACTIVITY DIAGRAM

68
 SWIMLANE DIAGRAM

functional bands or partition

▪ The activity diagram only represents the activities being performed, but Swimlane describes who does what
in a process or activity performed.
▪ It simply describes who is responsible for the activities being performed in the activity diagram and how they
are responsible.
▪ Activity diagram is divided according to the class responsible for working or performing out these activities.
▪ It simply shows the connection and strong communication between these lanes and
69
▪ It is used to highlight waste, redundancy, and inefficiency in a process of an activity or program.
70
SCHOLERSHIP –SWIMLANE DIAGRAM

71
72
SALES PROCESS SWIMLANEFLOWCHART

73
 Activity Diagram
State Chart Diagram
Model reactive systems Model non-reactive systems
Sequence of activities involved in a
Internal state of an object or system
process or workflow
States, transitions, events Activities, actions, transitions
More complex Less complex
Embedded systems, control systems, Business processes, workflows,
real-time systems software processes
Has trigger (arrow’s label) Has no trigger
No decision symbol but guard
Has decision symbol
condition
74
 INTERACTION DIAGRAM

 Two types of interaction diagram: Communication diagram and Sequence diagram.

 They are generated from use case description.

 Types of use case description:

 High-level use case description (Short non-
detailed description of each required process)
Eg : Use case : Enrol students ; Actor : Student ;
Description : Enters detail, selects subjects Pays the
fees, get enrolled.
▪ Expanded use case description (Interaction
between actor and system, how use case is going
to perform)
75
COMMUNICATION DIAGRAM

 It is also known as collaboration diagram.

 It is derived form high level or expanded use case description.
 It is used to show how objects interact to perform the behaviour of a particular use
case or a part of use case.
 It shows the objects of different classes participating in the interaction by their links
to each other and the messages that they send to each other.
 Its main purpose is to visualize the interactive behavior of the system.

76
COMMUNICATION DIAGRAM

 Steps to draw communication diagram:

1. Go through a Use Case Description and list the Domain Classes.
2. Draw an object symbol for each of the Domain Class Objects.
3. Add control objects to the diagram (controller to manage collaboration of objects).
4. Draw boundary object, it provides user interface and manages screen interaction.
5. Draw actors besides the boundary object.
6. Add association by drawing a line connecting any pair of objects which need to know about each other.
7. Add messages or method name to association link.
8. Actor → boundary object → controller object → other needed object.

77
USE CASE - ONLINE STUDENT ENROLLING

78
COMMUNICATION DIAGRAM - ONLINE STUDENT ENROLLING

79
SEQUENCE DIAGRAM

 It is behavioral diagram, provides dynamic aspects.

 Sequence diagram is also called an event diagram or event scenario.
 Interaction of different parts of a system to carry out a function, and the order in which the
interactions occur when a particular use case is executed.
 Sequence or order in which objects of your system interacts or coordinate with each other through
messages, arranged in a time sequence.
 It tells order in which interaction occur, when particular use case is executed.

80
SEQUENCE DIAGRAM COMPONENTS

1. Dimension - Drawn in two dimensions: I. Horizontal (Object Dimension) II. Vertical (Time Dimension)
2. Actor - Anyone how use to perform a certain function in system (can be someone or something).
3. Lifeline - A lifeline represents an individual participant in the interaction. Overlapping of lifeline of
objects is not allowed.
Lifeline notation with an actor element symbol is used when particular sequence diagram is owned
by the use case .
4. Activations - A thin rectangle box on a lifeline represents the time needed for an object to complete a
task. Actor will communicate with the objects of the system through activation bar.
Activation bar is a period or duration for which your respective object is active or operational.
5. Control Object - manages the collaboration of objects which gives effect to the Use Case Process.
6. Boundary Object - most use cases imply at least one boundary object & manages dialogue between
81
actor & system.
SEQUENCE DIAGRAM COMPONENTS

7. Message - communication between Lifelines of an interaction.

➢ 7.1. Synchronous Messages - Used when a sender must wait for a response to a message before it
continues.
➢ 7.2. Asynchronous Messages - It does not wait for a response from the receiver before the sender
continues.
➢ 7.3. Return Message - Used to indicate that the message receiver is done processing the message
and is returning control over to the message caller.
➢ 7.4. Create Message - An Object can be created at any time of execution of the process.
➢ 7.5. Reflexive Messages - Sometimes an object needs to communicate with the same class
methods.
➢ 7.6. Object Destruction - As soon as the object does not need any more in further process, object
destruction is called which is deleting the object.
82
➢ 7.7. Comment - A comment or note can be used to reflect the various remarks to the elements.
SEQUENCE DIAGRAM COMPONENTS

8. Focus of Control - indicates times during activation when processing is taking place within that object.
9. Guards - certain condition that must be met for a message to be sent to the object.
10. Alternative - choice between two or more message sequences.
11. Optional - similar to Guards where the fragment executes only if the supplied condition is true.
12. Parallel - each fragment is run in parallel.
13. Loops - The fragment may execute multiple times which may be need to model in a diagram.

83
SEQUENCE DIAGRAM

 Steps to generate sequence diagram:

 1. Fine the Domain Class
 2. Draw Control Object Lifeline
 3. Draw Boundary Object Lifeline
 4. Draw Actor Lifeline
 5. Show Messages with arrows
 6. Draw Objects Lifeline

84
ACTIVITY DIAGRAM
NOTATION

85
GUARD

86
ALTERNATIVE

87
OPTIONAL

88
PARALLEL

89
LOOPS

90
LOGIN – SEQUENCE DIAGRAM

91
ONLINE COURSE ENROLMENT
STEP 1 – FIND DOMAIN CLASSES

 Student
 Course Domain Classes

 Enrolment
 EnrolStudent Control object
 EnrolStudentUI Boundary object

92
ONLINE COURSE ENROLMENT
STEP 2 – DRAW CONTROL OBJECT LIFELINE

93
ONLINE COURSE ENROLMENT
STEP 3 - DRAW BOUNDARY OBJECT LIFELINE

94
ONLINE COURSE ENROLMENT
STEP 4 - DRAW ACTOR LIFELINE

95
ONLINE COURSE ENROLMENT
STEP 5 – ADDING MESSAGES

 Messages will be added in time sequence from top to bottom.

96
ONLINE COURSE ENROLMENT
STEP 6 - DRAW OBJECTS LIFELINE (STUDENT OBJECT)

97
ONLINE COURSE ENROLMENT
STEP 6 - DRAW OBJECTS LIFELINE (COURSE OBJECT)

98
ONLINE COURSE ENROLMENT
STEP 6 - DRAW OBJECTS LIFELINE (ENROLMENT OBJECT)

99
ONLINE COURSE ENROLMENT
INTERACTION

100
ONLINE COURSE ENROLMENT
PLACE DIAGRAM IN FRAME

101
ONLINE COURSE ENROLMENT – SEQUENCE DIAGRAM

102
HOTEL RESERVATION - SEQUENCE DIAGRAM

103
IMPLEMENTATION DIAGRAM

 They describes the different elements required for implementing a system.

 Two types of Implementation diagram - Component diagram and Deployment diagram.
 These are structural diagram used to model physical aspects of an object oriented system.
 They provide static representation of a system.

104
COMPONENT DIAGRAM

 It models the physical implementation of the software (file resources).

 Theses are type of object diagram that focus on system components that are often used to model static
implementation view of a system.
 It divides the system into various higher level of functionality.
 Each component is responsible for one clear goal within the entire system and interacts with other
essential elements.
 Used to visualize the organization of system components and the dependency relationships between them.
 Components are modular parts of a system that are independent and can be replaced with equivalent
components.
 The components can be a software component such as a database or user interface; or a hardware
component such as a circuit, microchip or device; or a business unit such as supplier, payroll or shipping. 105
106
COMPONENT DIAGRAM NOTATION

Rectangle with the component stereotype (the text

<<component>>). The component stereotype is usually
used above the component name

Rectangle with the component icon in the top right corner

and the name of the component.
Component

Rectangle with the component icon and the component

stereotype.

Component Components can be "wired" together to form subsystems,

Assemblies with the use of a ball-and-socket joint. 107
Provided Assembly connector allows linking the
Interface component’s required interface (represented
and with a semi-circle and a solid line) with the
Required provided interface (represented with a circle
Interface and solid line) of another component.
Interfaces show how components are wired This shows that one component is providing
together and interact with each other. the service that the other is requiring.

Port Port (represented by the small square at the

end of a required interface or provided
interface) is used when the component
delegates the interfaces to an internal class.
Dependencies Although you can show more detail about the
relationship between two components using
the ball-and-socket notation (provided
interface and required interface), you can just
as well use a dependency arrow to show the
relationship between two components.
108
 109

Component Diagram notations

COMPONENT DIAGRAM

110
COMPONENT DIAGRAM

 Steps to generate component diagram :

1. Identify the components such as the files, documents etc. in your system.
2. Figure out the relationships between the components.
3. Add components first, grouping them within other components as you see fit.
4. Add other elements such as interfaces, classes, objects, dependencies etc. to your component
diagram and complete it.
5. You can attach notes on different parts of your component diagram to clarify certain details to
others.

111
112
COMPONENT DIAGRAM

• The data (account and inspection ID) flows into the component via the port on the right-hand side
and is converted into a format the internal components can use. The interfaces on the right are
known as required interfaces, which represents the services the component needed in order to carry
out its duty.
• The data then passes to and through several other components via various connections before it is
output at the ports on the left. Those interfaces on the left are known as provided interface, which
represents the services to deliver by the exhibiting component.
• It is important to note that the internal components are surrounded by a large 'box' which can be the
overall system itself (in which case there would not be a component symbol in the top right corner) or
a subsystem or component of the overall system (in this case the 'box' is a component itself).

113
GENERAL COMPONENT DIAGRAM

 Following are the general components that can be included into any system’s component diagram:
 Central system server
 All below packages interacts with Central system server.
 User interface package (Optional interaction with central system server).
 Utility data processing package (Optional interaction with central system server).
 Operational detail package (Always uses/ interacts will central system server. )
 Connect 2-3 databases package/ database

114
115
116
TICKET SELLING SYSTEM COMPONENT DIAGRAM EXAMPLE

117
CLIENT SERVER ARCHITECTURE – COMPONENT DIAGRAM

118
DEPLOYMENT DIAGRAM

 It provides static deployment view of your system.

 It is used to define the hardware requirements for the product to execute the software.
 It visualizes how software interacts with hardware to complete the execution.
 Basically, it maps the software design requirement to the physical system which executes the
software design.
 Main Purpose of the Deployment Diagram :
• To represent the hardware topology of a system.
• Represent how different hardware components are inter-connected and how these
hardware components are used to deploy software components.
119
DEPLOYMENT DIAGRAM

 To design the deployment diagram, node, component, artifact, and interface notation are used.
 Artifacts(files) will be deployed on the nodes (computational unit) for execution.
 It tells how software and hardware work together.
 It can be used to model embedded system, client-server system, and fully distributed system.
 It can also can be used to plan system architecture and documenting the deployment of software
components.

120
DEPLOYMENT DIAGRAM NOTATIONS

121
DEPLOYMENT DIAGRAM COMPONENTS

1. Nodes – Nodes are used to represent the hardware and software within a single system. It is
represented by cube and is the physical element in the entire system.
2. Artifacts – These are the core elements of a system which are the result of a certain process. These
files varies from Library, Archive, Executable and Config files. And are represented by a rectangular
box.
3. Communication Association – It is a connector. It connects two different Nodes and shows a path of
communication between Nodes.
4. Device Node – This element is technically a node that contains the computational resources within a
system.
5. Deployment Specifications – This element shows the sequence of configuration.

122
GENERAL DEPLOYMENT DIAGRAM

 Following are the general components that can be made specific to include into any system’s
component diagram:
 Web server device (all services supported by your system will be components of web server)
 Application server device (Business logic- services provides by system layer & Data access layer –
which services you want to use)
 Database server device (can be single or multiple database and specifies main component)
 Number of users (will access web server through private network)

123
CLIENT SERVER ARCHITECTURE – DEPLOYMENT DIAGRAM

124
EMBEDDED SYSTEM – DEPLOYMENT DIAGRAM

125
DISTRIBUTED SYSTEM – DEPLOYMENT DIAGRAM

126
DECISION TABLE

 Brief visual representation for specifying which actions to perform depending on

given condition.
 It is good way to settle with different combination inputs with their corresponding
output.
 Very much helpful in requirement management and test design techniques.
 It provides a regular way of starting complex business rules, that is helpful for
developers as well as for testers.

127