MODULE 2

Requirement Analysis
 REQUIREMENT ELICITATION (GATHERING)

 Requirements elicitation is the process of gathering

and defining the requirements for a software system.
 A requirement is a feature that the system must
have or a constraint that it must satisfy to be
accepted by the client.

 Requirements engineering includes two main

activities:

 requirements elicitation: specification of system that

client understands.

 Analysis: analysis model that developers can interpret.

REQUIREMENT ELICITATION

 Requirements elicitation is about

communication among developers and
users to define a new system.

 Failure to communicate and understand

each others - system fails

 Errors introduced during requirements

elicitation are expensive to correct, as they
are usually discovered late in the process,
often as late as delivery.
 REQUIREMENT ELICITATION
 Requirements elicitation methods aim at improving
communication among developers, clients, and users.

 Requirement Specification: The client, the developers,

and the users identify a problem area and define a
system that addresses the problem.
 Use case Diagram

Student
 REQUIREMENTS ELICITATION ACTIVITIES
1. Identifying actors: developers identify the
different types of users the future system will
support.

2. Identifying scenarios:
 Developers observe users and develop a set of
detailed scenarios (concrete examples of future
systems) for typical functionality provided by the
future system.
 Scenarios used for understanding application domain
in detail.
REQUIREMENTS ELICITATION ACTIVITIES
3. Identifying use cases:
 Once developers and users agree on a set of scenarios.

 Set of use cases are derived from scenarios that

represent future systems.

 Use cases are abstractions describing all possible cases

of the system
REQUIREMENTS ELICITATION ACTIVITIES
4. Refining use cases:
 requirements specification is complete by
detailing each use case.

 describing the behavior of the system in the

presence of errors and exceptional conditions.
REQUIREMENTS ELICITATION ACTIVITIES
5. Identifying relationships among use cases:
 identify dependencies among use cases.

 Consolidate(combine) the use case model by

factoring out common functionality.
REQUIREMENTS ELICITATION ACTIVITIES
 Identifying nonfunctional requirements:
 Developers, users, and clients agree on aspects that
are visible to the user, but not directly related to
functionality.

 These include constraints on the performance of the

system, its documentation, the resources it consumes,
its security, and its quality.
REQUIREMENT ELICITATION TECHNIQUES
• Questionnaires: Asking the end user a list of pre-selected
questions

• Task Analysis: Observing end users in their operational

environment

• Scenarios: Describe the use of the system as a series of

interactions between a concrete end user and the system

• Use cases: Abstractions that describe a class of scenarios.

FUNCTIONAL REQUIREMENTS
 Functional requirements describe the
interactions between the system and its
environment independent of its implementation.

 Example: SatWatch, a watch that resets itself without

user intervention
NON-FUNCTIONAL REQUIREMENTS
 Nonfunctional requirements describe aspects
of the system that are not directly related to the
functional behavior of the system.

 Usability to performance - non functional

requirements
Difference between Functional Requirements and Non-Functional
Requirements:

Functional Requirements Non Functional Requirements

A functional requirement defines a system or A non-functional requirement defines the quality attribute
its component. of a software system.
It specifies “What should the software It places constraints on “How should the software system
system do?” fulfill the functional requirements?”
Non-functional requirement is specified by technical
Functional requirement is specified by User. peoples e.g. Architect, Technical leaders and software
developers.
Defined at a component level. Applied to a system as a whole.
Helps you verify the functionality of the
Helps you to verify the performance of the software.
software.
Functional Testing like System, Integration, Non-Functional Testing like Performance, Stress,
End to End, API testing, etc are done. Usability, Security testing, etc are done.
Example
Example
1) Authentication of user whenever he/she
1) Emails should be sent with a latency of no greater than
logs into the system.
12 hours from such an activity.
2) System shutdown in case of a cyber
2) The processing of each request should be done within
attack.
10 seconds
3) A Verification email is sent to user
3) The site should load in 3 seconds when the number of
whenever he/she registers for the first time
simultaneous users are > 10000
on some software system.
NON-FUNCTIONAL REQUIREMENTS
(TYPES)
1. Usability is the ease with which a user can
learn to operate or use system.

 Usability requirements: online help or user level

documentation , manual etc.

 Clients can set usability issues for developer for

example – color scheme for GUI
NON-FUNCTIONAL REQUIREMENTS
2. Reliability is the ability of a system or component to
perform its required functions under stated
conditions for a specified period of time.

 Dependability includes reliability, robustness (the

degree to which a system or component can function
correctly in the presence of invalid inputs or stressful
environment conditions), and safety (a measure of the
absence of sudden consequences to the environment).
NON-FUNCTIONAL REQUIREMENTS
(TYPES)
3. Performance requirements are concerned with
quantifiable attributes of the system such as:
Response Time- how quickly the system reacts to a user
input
Throughput- how much work the system can accomplish
within a specified amount of time
Availability- the degree to which a system or component
is operational and accessible when required for use
Accuracy
 NON-FUNCTIONAL REQUIREMENTS (TYPES)
4. Supportability requirements are concerned with
the ease of changes to the system after deployment.
 Adaptability: the ability to change the system to
deal with additional application domain
concepts.

 Maintainability: the ability to change the system

to deal with new technology or to fix defects.

 Internationalization: the ability to change the

system to deal with additional international
conventions, such as languages, units, and number
formats
ADDITIONAL NON-FUNCTIONAL
REQUIREMENTS
 Implementation requirements
 constraints on the implementation of the system.

 specific tools, programming languages, or hardware

platforms.
 Interface requirements

 are constraints imposed by external systems

 interchange formats
ADDITIONAL NON-FUNCTIONAL
REQUIREMENTS
 Operations requirements
 are constraints on the administration and
management of the system.

 Packaging requirements
 are constraints on the actual delivery of the
system
 Installation media for software setting
ADDITIONAL NON-FUNCTIONAL
REQUIREMENTS
 Legal requirements
 are concerned with licensing, regulation, and
certification issues.

 Quality requirements
REQUIREMENTS CHARACTERISTICS
 Requirements are continuously validated with
the client and the user.

 Requirement validation involves checking that

the specification is complete, consistent,
unambiguous, and correct.
REQUIREMENTS CHARACTERISTICS
1. Completeness: It is complete if all possible
scenarios through the system are described,
including exceptional behavior.
2. Consistent: The requirements specification is
consistent if it does not contradict itself.
3. Unambiguous — The requirements specification is
unambiguous if exactly one system is defined.
4. Correct: represents accurately the system that the
client needs and that the developers intend to build.
 REQUIREMENT SPECIFICATION
 Three more desirable properties (qualities) of a
requirements specification are that it be realistic,
verifiable, and traceable.

 Realistic: if the system can be implemented within

constraints.

 Verifiable: if once the system is built, repeatable tests

designed to demonstrate that the system fulfills the
requirements specification.
REQUIREMENT SPECIFICATION
 Traceability: if each requirement can be traced
throughout the software development to its
system functions, and vice-versa.

 Traceability includes also the ability to track

the dependencies among requirements, system
functions, and the intermediate designs.
USE CASE DIAGRAMS
 Identifying Actors
 Actors represent external entities that interact
with the system.
 An actor can be human or an external system.

Actor
USE CASE DIAGRAMS
 Give meaningful business relevant names for actors.

 Primary actors should be to the left side of the

diagram –highlight the important roles in the system.

 Actors model roles (not positions) – In a hotel both the

front office executive and shift manager can make
reservations. “Reservation Agent” actor name to highlight
the role.

 External systems are actors – If your use case is send

email and if interacts with the email management software
then the software is an actor to that particular use case.
 Actors don’t interact with other actors
 Place inheriting actors below the parent actor
 USE CASE DIAGRAM
 Once the actors are identified, the next step in the
requirements elicitation activity is to determine the
functionality that will be accessible to each actor.

 Use cases are external (user) view of a system

 Intended for modeling dialogue between user and

system
 USE CASE DIAGRAM
 Identifying Scenarios
 A scenario is a narrative description of what people do
and experience as they try to make use of computer
systems and applications.

 Scenario is description of the system from single actor’s

or user’s point of view.

 Scenarios may be defined for current , future ,

evaluation or training phases of the software
development process.
USE CASE DIAGRAM
 Identifying Use Cases
 Use cases represent what the actors want your system
to do for them.

 A use case represents a complete flow of events

through the system.

 A Use Case captures some actor-visible function

- Achieves some discrete (business-level) goal for that
actor
- May be read, write, or read-modify-write in nature
 USE CASE DIAGRAM
 Names begin with a verb – An use case models an action so the
name should begin with a verb.

 Make the name descriptive – This is to give more information

for others who are looking at the diagram. For example “Print
Invoice” is better than “Print”.

 Highlight the logical order – For example if you’re analyzing a

bank customer typical use cases include open account, deposit and
withdraw. Showing them in the logical order makes more sense.

 Place included use cases to the right of the invoking use

case – This is done to improve readability and add clarity.

 Place inheriting use case below parent use case – Again this
ELEMENTS OF USE CASE DIAGRAM: ACTOR
Actor
ELEMENTS OF USE CASE DIAGRAM: USE
CASE
 System function (process – automated or
manual).

Do Something
(Operation)
Use Case
ELEMENTS OF USE CASE DIAGRAM
USE CASE DIAGRAM FOR A SIMPLE WATCH
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

ASSOCIATION BETWEEN ACTOR AND USE CASE

 This one is straightforward and present in every use

case diagram.

 An actor must be associated with at least one use

case.
 An actor can be associated with multiple use
cases.
 Multiple actors can be associated with a single use
case.
ASSOCIATION BETWEEN ACTOR AND USE CASE
GENERALIZATION OF AN ACTOR

 Generalization of an actor means that one actor can

inherit the role of an other actor.
 EXTEND RELATIONSHIP BETWEEN TWO USE CASES

 It extends the 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.
 Arrow points to the base use case when using
<<extend>>
 Extending use case is optional
 INCLUDE RELATIONSHIP BETWEEN TWO USE CASES

 Include relationship show that the behavior of the included

use case is part of the including (base) use case.

 The base use case is incomplete without the included use

case.

 The included use case is mandatory and not optional.

 Like a “use case subroutine”

 GENERALIZATION OF A USE CASE

 This is similar to the generalization of an actor.

 This is used when there are common behavior between two
use cases and also specialized behavior specific to each use
case.
PROBLEM DEFINTION-VENDING
MACHINE
 A vending machine accepts coins for a variety of
products. The user selects the drink from
products available through the selection panel. If
the drink is available the price of the product is
displayed. The user the deposits the coins
depending on the price of the product. Coin
collector collects the coins. After stipulated time,
the controller will compare the deposited coins
with the price, If the amount deposited is less
than the price then error message will be
displayed and all deposited coins will be
dispensed by coin dispenser else the drink will be
dispensed by the product dispenser. Draw use
case diagram.
USE CASE DIAGRAM FOR VENDING
MACHINE
 Actor- User
 Processes involved in the system
 Select product
 Deposit coins
 Verify the deposited amount
 Dispense product
 Dispense coins
USE CASE EXAMPLE
 Customer (actor) uses bank ATM to Check
Balances of his/her bank accounts, Deposit
Funds, Withdraw Cash and/or Transfer Funds
(use cases). ATM Technician provides
Maintenance and Repairs. All these use cases
also involve Bank actor whether it is related to
customer transactions or to the ATM servicing.
USE CASE EXAMPLE
 On most bank ATMs, the customer is
authenticated by inserting a plastic ATM card
and entering a personal identification number
(PIN). Customer Authentication use case is
required for every ATM transaction so we show it
as include relationship. Including this use case as
well as transaction generalizations make the
ATM Transaction an abstract use case. Customer
may need some help from the ATM. ATM
Transaction use case is extended via extension
point called menu by the ATM Help use case
whenever ATM Transaction is at the location
specified by the menu and the bank customer
requests help, e.g. by selecting Help menu item.
USE CASE EXAMPLE
 ATM Technician maintains or repairs Bank
ATM. Maintenance use case includes
Replenishing ATM with cash, ink or printer
paper, Upgrades of hardware, firmware or
software, and remote or on-site Diagnostics.
Diagnostics is also included in (shared with)
Repair use case.
USE CASE

Online Airline
Reservation System
ACTIVITY DIAGRAM
 An activity diagram describes the behavior of a
system in terms of activities.

 Activity diagram is basically a flow chart to

represent the flow form one activity to another
activity.

 Activity diagram: operation of a system.

 This flow can be sequential, branched or

concurrent.
 ACTIVITY DIAGRAM (BASIC NOTATIONS)
 Initial node.
 The filled in circle is the starting point of the diagram.
 It is shown as filled circle.
ACTIVITY DIAGRAM (BASIC NOTATIONS)

 Activity final node.

 The filled circle with a border is the ending point.
 The final activity is optional.
ACTIVITY DIAGRAM (BASIC NOTATIONS)
 Activity. The rounded rectangles represent activities
that occur.
ACTIVITY DIAGRAM (BASIC NOTATIONS)
 Flow/edge (Control Flow)
 The arrows on the diagram. Within the control
flow an incoming arrow starts a single step of an
activity; after the step is completed the flow
continues along the outgoing arrow.
 ACTIVITY DIAGRAM (BASIC NOTATIONS)
 Decision.
 Decisions are branches in the control flow.

 They denote alternatives based on a condition of the state of

an object or a set of objects.

 Decisions are depicted by a diamond with one or more

incoming open arrows and two or more outgoing arrows.
ACTIVITY DIAGRAM (BASIC NOTATIONS)
 The outgoing edges are labeled with the conditions
that select a branch in the control flow.

 Decisions are depicted by a diamond with one or more

incoming open arrows and two or more outgoing
arrows.

 The set of all outgoing edges from a decision

represents the set of all possible outcomes.
ACTIVITY DIAGRAM (BASIC NOTATIONS)
 ACTIVITY DIAGRAM (BASIC NOTATIONS)
 Some activities occur simultaneously or in parallel. Such
activities are called concurrent activities.

 Fork nodes and join nodes represent concurrency.

 Fork nodes denote the splitting of the flow of control

into multiple threads.

 Join nodes denotes the synchronization of multiple

threads and their merging of the flow of control into a
single thread.
ACTIVITY DIAGRAM (BASIC NOTATIONS)
 Swim Lanes
 The contents of an activity diagram may be
organized into partitions (swimlanes) using solid
vertical lines.

 A swim lane (or swimlane diagram) is a visual

element used in process flow diagrams, or
flowcharts, that visually distinguishes job
sharing and responsibilities for sub-processes of a
business process.
ACTIVITY DIAGRAM (BASIC NOTATIONS)
 Order Swimlanes in a Logical Manner.
 Apply Swim Lanes To Linear Processes.

 Have Less Than Five Swimlanes.

 Consider Swim areas For Complex Diagrams.

PROBLEM

ActivityDiagram for Ticket

Vending Machine

Problem Definition: Draw

Activity Diagram for Login
Procedure of a system.
PROBLEM DEFINITION
 Activity is started by Commuter actor who needs to buy a
ticket. Ticket vending machine will request trip information
from Commuter. This information will include number and
type of tickets, e.g. whether it is a monthly pass, one way or
round ticket, route number, destination or zone number, etc.
Based on the provided trip info ticket vending machine will
calculate payment due and request payment options.
 Those options include payment by cash, or by credit or debit
card. If payment by card was selected by Commuter, another
actor, Bank will participate in the activity by authorizing the
payment. After payment is complete, ticket is dispensed to the
Commuter. Cash payment might result in some change due, so
the change is dispensed to the Commuter in this case. Ticket
vending machine will show some "Thank You" screen at the
end of the activity.
Activity Diagram Example - Student Enrollment
CLASS DIAGRAM
A Class Diagram is a diagram describing
the structure of a system.

 shows the system's

 classes

 Attributes

 operations (or methods),

 Relationships among the classes.

ESSENTIAL ELEMENTS OF A CLASS DIAGRAM
 Class: A class represents the blueprint of its
objects.
 Attributes

 Operations

 Relationships

 Associations

 Generalization

 Realization

 Dependency
CLASS
 Describes a set of objects having similar:
 Attributes (status)
 Operations (behavior)
 Relationships with other classes
 Attributes and operations may
 have their visibility marked:
Class
 "+" for public Name Window
 "#" for protected size: Size
Attribute
 "−" for private s
visibility: boolean

 "~" for package Operation

display()
hide()
s
ASSOCIATIONS
 Association: It describes a static or physical
connection between two or more objects. It
depicts how many objects are there in the
relationship.
 For example, a department is associated
with the college
DIRECTED ASSOCIATION

 Refers to a directional relationship

represented by a line with an arrowhead. The
arrowhead depicts a container-contained
directional flow.
REFLEXIVE ASSOCIATION

 A reflexive association is a relationship from one class

back to itself.
MULTIPLICITY
• the number of objects that participate in the
association.
• Multiplicity Indicators
 ASSOCIATION CLASS
 In modeling an association, there are times when you need
to include another class because it includes valuable
information about the relationship.
 use an association class that you tie to the primary
association.
 An association class is represented like a normal class.

 The difference is that the association line between the

primary classes intersects a dotted line connected to the
association class.
BASIC AGGREGATION
 Aggregation is a special type of association used
to model a "whole to its parts" relationship.
 Example: Car as a whole entity and Car Wheel as
part of the overall Car.
 2..* 1..*
Car Door House

Whol Part
e
COMPOSITION AGGREGATION
A strong form of aggregation
 The whole is the sole owner of its part.
 The part object may belong to only one whole
 Multiplicity on the whole side must be zero or one.
 The life time of the part is dependent upon the whole.
GENERALIZATION
 The Generalization association ("is a") is the
relationship between the base class that is
named as “superclass” or “parent” and the
specific class that is named as “subclass” or
“child”.
REALIZATION
 A realization relationship indicates that one class
implements a behavior specified by another
class (an interface or protocol).

 a broken line with an unfilled solid arrowhead is

drawn from the class that defines the functionality to
the class that implements the function.
DEPENDENCY
 It means that the class at the source end of the
relationship has some sort of dependency on the
class at the target (arrowhead) end of the
relationship.
DEPENDENCY
 In UML, a dependency relationship is a relationship in
which one element, the client, uses or depends on
another element, the supplier.

 a Cart class depends on a Product class because

the Cart class uses the Product class as a parameter
for an add operation.

 Cart class is, therefore, the client, and the Product

class is the supplier.
 Dependency shows that an element is dependent on
another element as it fulfils its responsibilities within
the system
A class diagram describing the sales order system is given below.
 Task

Class Diagram for Online Shopping

Class Diagram for Hospital

Management System
SEQUENCE DIAGRAM
 The Sequence Diagram models the
collaboration of objects based on a time
sequence.

 Sequence diagrams represent the objects

participating in the interaction horizontally and
time vertically.
 Sequence Diagrams
• Depicts sequence of actions that occur in a system

• Useful tool to represent dynamic behavior of a

system

• 2 dimensional :

– Horizontal axis

– Vertical axis
 Sequence Diagram
• The focus is less on messages themselves and
more on the order in which messages.

• Sequence diagrams are good at showing which

objects communicate with which other objects;
and what messages trigger those
communications.
Participants in a Sequence Diagram
• A sequence diagram is made up of a collection
of participants.

• Participants – the system parts that interact

each other during the sequence.

• Classes or Objects – each class (object) in the

interaction is represented by its named icon
along the top of the diagram
 Elements of Sequence Diagram
Object1:C1 Object2:C2

• ACTOR Click Update Button

updateStatus( )
• OBJECTS Us e r

• LIFELINES

• MESSAGES

• ACTIVATION-represents time an object needs to complete

task
 Elements of Sequence Diagram
• Class Roles or Participants or Objects: Class
roles describe the way an object will behave in
context.
 • Activation or Execution
Elements of Sequence Occurrence
Diagram
Activation boxes represent
the time an object needs to
complete a task.

• When an object is busy

executing a process or
waiting for a reply
message, use a thin gray
rectangle placed vertically
on its lifeline.
 Elements of Sequence Diagram
• Synchronous Message
• A synchronous message requires a response
before the interaction can continue.
• It's usually drawn using a line with a solid
arrowhead pointing from one object to
another.
 Elements of Sequence Diagram
• Asynchronous Message
Asynchronous messages don't need a reply for
interaction to continue.
• They are drawn with an arrow connecting two
lifelines; however, the arrowhead is usually
open and there's no return message depicted.
 Elements of Sequence Diagram
• Reply or Return Message
• A reply message is drawn with a dotted line
and an open arrowhead pointing back to the
original lifeline.
 Elements of Sequence Diagram
• Self Message
• A message an object sends to itself, usually
shown as a U shaped arrow pointing back to
itself.
 Sequence diagrams: an example

: object1 : object2 : object3

: Custom er

Actor

Instances
of classes
 Sequence Diagram: Lifelines

:actor :object1
Time :object2 :object3

Each object has a lifeline.

Time flows from top to down.
 Sequence diagrams: rectangles

:actor :object1
Time :object2 :object3

Rectangles refer to events that

are related to each other.
 Sequence diagrams: messages

:actor :object1
Time :object2 :object3

Arrows indicate messages that are

sent from one object to another.
 Sequence diagrams - different types of messages

: object1 : object2 : object3

: Custom er
request( )

createObject3( )
Message
create( )
An object sends a
message to itself.

Feedback arrow
shows that a
value is returned.
 Sequence diagrams: endpoints

: object1 : object2 : object3

: Custom er
request( )

createObject3( )

create( )

X at the end of
the lifeline shows
that the object
ceases to exist.
Before drawing the sequence diagram, it’s
necessary to identify the objects or actors that
would be involved in creating a new user account.
These would be;

• Librarian
• Online Library Management system
• User credentials database
• Email system
Here are the steps that occur in the use case named
‘Create New Library User Account’.

• The librarian request the system to create a new online

library account
• The librarian then selects the library user account type
• The librarian enters the user’s details
• The user’s details are checked using the user
Credentials Database
• The new library user account is created
• A summary of the new account’s details is then
emailed to the user
Admin: Librarian Library Management System User credintial database Email
system
 Sequence Diagram
• Draw sequence diagram for login procedure of
a system. Include all possible scenarios and
also draw activity diagram. (10M)
 Collaboration Diagram
• Collaboration diagram-emphasis is on structural
organization of the objects that send/receive messages.

 Elements of a collaboration diagram

Object Name: Class Name Object Name: Class Name
• Object

• Relation/Association
Function()

• Messages
STEPS TO DRAW COLLABORATION DIAGRAM

• Place objects as vertices in a graph

• Add links to connect these object as arcs of

graph

• Write messages on links with sequence

numbers for send and receive

Ex. Collaboration Diagram
Collaboration Diagram Syntax

AN ACTOR

AN OBJECT anObject:aClass

AN ASSOCIATION

A MESSAGE aMessage()
 Sequence Diagrams Collaboration Diagrams
The sequence diagram represents the
The collaboration diagram also comes
UML, which is used to visualize the
under the UML representation which
sequence of calls in a system that is
is used to visualize the organization of
used to perform a specific
the objects and their interaction.
functionality.
The sequence diagram are used to The collaboration diagram are used to
represent the sequence of messages represent the structural organization
that are flowing from one object to of the system and the messages that
another. are sent and received.
The collaboration diagram is used
The sequence diagram is used when
when object organization is main
time sequence is main focus.
focus.
The collaboration diagrams are better
The sequence diagrams are better suited for depicting simpler
suited of analysis activities. interactions of the smaller number of
objects.
 State Chart Diagram
• A state in UML is a condition or situation an
object (in a system) might find itself in during
its life time.

• A state chart diagram is normally used to

model how the state of an object changes in
its lifetime.

• We capture the behavior of the subject object

through modeling these various states and
transitions between them.
 State Chart Diagram
• Thus, a state machine diagram does not
necessarily model all possible states, but
rather the critical ones only. When we say
“critical” states, we mean those that act as
stimuli and prompt for response in the
external world.
 State Chart Diagram
• Initial state. This is
represented as a filled circle.
• Final state. This is represented
by a filled circle inside a larger
circle.

• State. These are represented by

rectangles with rounded corners.

• Transition. A transition is shown

as an arrow between two states.
Normally, the name of the event
which causes the transition is
places along side the arrow.
 State Chart Diagram
• A guard condition is a condition that has to be
met in order to enable the transition to which
it belongs:

• Guard conditions can be used to document

that a certain event, depending on the
condition, can lead to different transitions.
 Elements of state diagram
• Initial State

• State

Event[Guard Condition]/Action]

• Transition

• Final States
 Elements of state diagram

Self transition

Composite state
a state with internal activities using a composite state.
Elements of state diagram

Fork

Join
ATM Withdraw