UNIT-II

REQUIREMENTS ANALYSIS AND DESIGN

Syllabus: Requirements analysis and specification, Use cases and scenarios, Object-oriented
analysis and design (OOAD), Design patterns, UML modelling techniques (class diagrams,
sequence diagrams, state machine diagrams, activity diagrams)

Requirement Engineering
 The process to gather the software requirements from client, analyse, and document them is known
as requirement engineering.
 The goal of requirement engineering is to develop and maintain sophisticated and descriptive
‘System Requirements Specification’ document.
Software Requirements analysis and specification
 The software requirements are description of features and functionalities of the target system.
 Requirements convey the expectations of users from the software product.
 The requirements can be obvious or hidden, known or unknown, expected or unexpected from
client’s point of view
It is divided into two main parts:
1.Software Requirements Analysis: The process of identifying,
analyzing, and defining the system's requirements
2.Software Requirements Specification (SRS):
The formal document that outlines the system’s
requirements in detail
 Software Requirements Analysis is the phase where the needs of the stakeholders are
gathered, understood, and documented. The primary goal of this phase is to ensure that
all aspects of the system, both functional and non-functional, are captured accurately
and comprehensively.

Key Activities in Software Requirements Analysis:

1. Requirement Elicitation:
o The process of gathering requirements from various stakeholders,
including users, clients, business analysts, and other subject matter
experts.
o Methods used:
 Interviews: Direct discussions with stakeholders to understand their
needs and expectations.
 Surveys/Questionnaires: Collecting feedback from users or a large
group of stakeholders.
 Workshops: Collaborative group discussions to extract requirements.
  Document Analysis: Reviewing existing system documentation or
business process documents.
 Prototyping: Developing a preliminary version of the system to gather
feedback.
2. Requirement Classification:
o Once gathered, the requirements are classified into two broad categories:
 Functional Requirements: Define the specific behaviors or
functions of the system (e.g., "The system should allow users to
register and log in").
 Non-Functional Requirements: Specify the qualities or attributes
the system must have (e.g., performance, security, reliability,
scalability, and usability).
3. Requirement Prioritization:
o This involves prioritizing the requirements to determine which ones are most
important and should be developed first. Prioritization techniques include:
 MoSCoW (Must have, Should have, Could have, Won't have).
 Kano Model (Basic, Performance, Excitement factors).
4. Requirement Validation:
o Ensuring that the requirements are realistic, feasible, and meet the needs
of the stakeholders.
o This step often involves reviewing the requirements with stakeholders to
ensure they are correctly understood and feasible within project constraints
(e.g., budget, timeline, technology).
5. Feasibility Analysis:
o Assessing the feasibility of the requirements in terms of technical,
operational, and financial constraints.
o This involves analyzing whether the requirements can be implemented
with the available resources and technologies.

2. Software Requirements Specification (SRS)

The Software Requirements Specification (SRS) is a formal document that describes in

detail the software system to be developed. The SRS serves as a contract between the client
and the development team, ensuring that both parties have a clear understanding of the
system's functionality and expectations.

Key Components of an SRS:

1. Introduction:
o Purpose: The purpose of the software, its intended audience, and the
scope of the project.
o Scope: A high-level overview of the system, describing the boundaries of the
system and what will and will not be included.
o Definitions, Acronyms, and Abbreviations: Any terms, acronyms, or
abbreviations used in the document to ensure clarity.
2. System Overview:
o A general description of the system’s purpose, context, and high-level
features. This section typically provides background information on the
problem the software is solving.
3. Functional Requirements:
o Detailed descriptions of the functionalities the system must have. Each
functional requirement should define a specific behavior or interaction.
o For example:
 "The system shall allow the user to reset their password via email."
 "The system shall generate monthly reports for administrators."
4. Non-Functional Requirements:
o These are the quality attributes of the system that specify how the system
should perform.
o Key non-functional requirements include:
 Performance: E.g., "The system must process 1000 transactions per
second."
 Security: E.g., "The system shall use AES-256 encryption for all sensitive
data."
 Usability: E.g., "The system shall have an intuitive user interface
that can be learned in 1 hour."
 Reliability: E.g., "The system shall be available 99.9% of the time."
5. External Interface Requirements:
o Describes how the system will interact with external systems, hardware, or
software components. This includes user interfaces, hardware interfaces,
software interfaces, and communication protocols.
o For example:
 User Interface: The layout and design of screens and inputs.
 Hardware Interface: Describing how the system will interface with
hardware (e.g., printers, sensors).
 Software Interface: Interfaces with other software applications or
systems (e.g., database systems, third-party APIs).
 6. System Features:
o A detailed list of all the features that the system will provide, organized in a
structured manner, often with corresponding functional requirements.
o Each feature description typically includes the expected inputs, processing, and
outputs, as well as any specific behaviors or constraints.
7. Assumptions and Constraints:
o Any assumptions made during the requirements gathering process or constraints
on the
system’s design or implementation.
o For example:
 "The system will be developed in Java."
 "The system must be able to run on a Windows environment."
8. Acceptance Criteria:
o The specific conditions or tests that must be met for the system to be accepted
by the client. This section is crucial for validating the software's functionality
and performance during the testing phase.
9. Appendices:
o Additional information, such as diagrams, prototypes, or examples, that might
be useful for understanding the requirements.
USE CASES AND SCENARIOS
 A use case diagram is used to represent the dynamic behavior of a system.
 It encapsulates the system's functionality by incorporating use cases, actors, and their
relationships.
 It models the tasks, services, and functions required by a system/subsystem of an
application.
 It depicts the high-level functionality of a system and also tells how the user handles a
system.
Purpose of Use Case Diagrams
1. The main purpose of a use case diagram is to portray the dynamic aspect of a
system.
2. It accumulates the system's requirement, which includes both internal as well as
external influences.
3. It invokes persons, use cases, and several things that invoke the actors and
elements accountable for the implementation of use case diagrams.
4. It represents how an entity from the external environment can interact with a part
of the system.
Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.
2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.
 How to draw a Use Case diagram
1. It is essential to analyse the whole system before starting with drawing a use case diagram, and
then the system's functionalities are found.
2. And once every single functionality is identified, they are then transformed into the use cases to
be used in the use case diagram
3. .After that, we will enlist the actors that will interact with the system.
4. The actors are the person or a thing that invokes the functionality of a system.
5. It may be a system or a private entity, such that it requires an entity to be pertinent to the
functionalities of the system to which it is going to interact
6. .Once both the actors and use cases are enlisted, the relation between the actor and use case/ system
is inspected.
7. It identifies the no of times an actor communicates with the system.
8. Basically, an actor can interact multiple times with a use case or system at a particular instance of
time.
Following are some rules that must be followed while drawing a use case diagram:
1. A pertinent and meaningful name should be assigned to the actor or a use case of a system.
2. The communication of an actor with a use case must be defined in an understandable way.
3. Specified notations to be used as and when required.
4. The most significant interactions should be represented among the multiple no of interactions
between the use case and actors.
Examples of use case

1)

2)
 OBJECT-ORIENTED ANALYSIS AND DESIGN (OOAD)
 Object-Oriented Analysis and Design (OOAD) is a way to design software by thinking of
everything as objects similar to real-life things.
 we first understand what the system needs to do, then identify key objects, and finally decide how
these objects will work together.
 This approach helps make software easier to manage, reuse, and grow.
 OOAD is based on the concepts of object-oriented programming (OOP) and is an organized and
systematic approach to designing and developing software systems.
 It is a software engineering paradigm that integrates two distinct but closely related processes:
Object-Oriented Analysis (OOA) and Object-Oriented Design (OOD).
Important Aspects of OOAD
Below are some important aspects of OOAD:
1. Object-Oriented Programming: In this the real-world items are represented/mapped as software
objects with attributes and methods that relate to their actions.
2. Design Patterns: Design patterns are used by OOAD to help developers in building software
systems that are more efficient and maintainable.
3. UML Diagrams: UML diagrams are used in OOAD to represent the different components and
interactions of a software system.
4. Use Cases: OOAD uses use cases to help developers understand the requirements of a system and
to design software systems that meet those requirements.

Object-Oriented Analysis
 Object-Oriented Analysis (OOA) is the process of understanding and analyzing the system
 requirements by looking at the problem scenario in terms of objects.
 These objects represent real-world entities or concepts that are relevant to the system being
developed.
 During OOA, the goal is to identify the objects, their attributes, behaviors, and relationships,
without focusing on how the system will be implemented.
For example: Lets say you’re building a game:
 OOA helps you figure out all the things you need to know about the game world – the characters,
their features, and how they interact.
 It’s like making a map of everything important.
 OOA also helps you understand what your game characters will do. It’s like writing down a script
for each character.
 Every program has specific tasks or jobs it needs to do. OOA helps you list and describe these jobs.
 In our game, it could be tasks like moving characters or keeping score. It’s like making a to-do list
for your software.
 OOA is smart about breaking things into different parts. It splits the job into three categories: things
your game knows, things your game does, and how things in your game behave.
Object-Oriented Design
 In the object-oriented software development process, the analysis model, which is initially formed
through object-oriented analysis (OOA), undergoes a transformation during object-oriented design
(OOD) i.e implementation of the conceptual model developed in OOA.
 This evolution is crucial because it shapes the analysis model into a detailed design
model.Furthermore, as part of the object-oriented design process, it is essential to define specific
aspects:
Data Organization of Attributes:
o OOD involves specifying how data attributes are organized within the objects.
o This includes determining the types of data each object will hold and how they relate to one
another.
Procedural Description of Operations:
o OOD requires a procedural description for each operation that an object can perform.
o This involves detailing the steps or processes involved in carrying out specific tasks.
Below diagram shows a design pyramid for object-oriented systems. It is having the
following four layers.
1. The Subsystem Layer: It represents the subsystem that enables software to achieve user
requirements and implement technical frameworks that meet user needs.
2. The Class and Object Layer: It represents the class hierarchies that enable the system to develop
using generalization and specialization. This layer also represents each object.
3. The Message Layer: This layer deals with how objects interact with each other. It includes
messages sent between objects, method calls, and the flow of control within the system.
4. The Responsibilities Layer: It focuses on the responsibilities of individual objects. This includes
defining the behaviour of each class, specifying what each object is responsible for, and how it
responds to messages.

DESIGN PATTERNS
 Reusable solutions for typical software design challenges are known as design patterns.
 Expert object-oriented software engineers use these best practices to write more structured,
manageable, and scalable code.
 Design patterns provide a standard terminology and are specific to particular scenarios and
problems. Design patterns are not finished code but templates or blueprints only.
Key Characteristics of Design Patterns
 Reusability: Patterns can be applied to different projects and problems, saving time and effort in
solving similar issues.
 Standardization: They provide a shared language and understanding among developers, helping in
communication and collaboration.
 Efficiency: By using these popular patterns, developers can avoid finding the solution to same
recurring problems, which leads to faster development.
 Flexibility: Patterns are abstract solutions/templates that can be adapted to fit various scenarios and
requirements.
Why Learn Design Patterns?
There are multiple reasons to learn design patterns:
 Code that is simpler to comprehend, update, and expand is produced with the help of design patterns.
 They offer solutions that have been tried and tested as well as best practices.
 Learning this enables them to quickly and effectively address similar challenges in various projects.
 Developers can produce reusable components that can be utilized in a variety of applications by
implementing design patterns.
 This reduces redundancy and saves development time.
Types of Software Design Patterns
There are three types of Design Patterns:
1. Creational Design Pattern
2. Structural Design Pattern
3. Behavioral Design Pattern
Creational Design Patterns
Creational Design Patterns focus on the process of object creation or problems related to object
creation. They help in making a system independent of how its objects are created, composed and
represented.

Types of Creational Design Patterns:

 Factory Method Design Pattern
o This pattern is typically helpful when it's necessary to separate the construction of an object
from its implementation.
o With the use of this design pattern, objects can be produced without having to define the exact
class of object to be created.
 Abstract Factory Method Design Pattern
o Abstract Factory pattern is almost similar to Factory Pattern and is considered as another layer
of abstraction over factory pattern.
o Abstract Factory patterns work around a super-factory which creates other factories.
 Singleton Method Design Pattern
o Of all, the Singleton Design pattern is the most straightforward to understand.
o It guarantees that a class has just one instance and offers a way to access it globally.
 Prototype Method Design Pattern
o Prototype allows us to hide the complexity of making new instances from the client.
o The concept is to copy an existing object rather than creating a new instance from scratch,
something that may include costly operations.
 Builder Method Design Pattern
o To “Separate the construction of a complex object from its representation so that the same
construction process can create different representations.” Builder pattern is used
o It helps in constructing a complex object step by step and the final step will return the object.

Structural Design Patterns

Structural Design Patterns solves problems related to how classes and objects are
composed/assembled to form larger structures which are efficient and flexible in nature. Structural
class patterns use inheritance to compose interfaces or implementations.
Types of Structural Design Patterns:
 Adapter Method Design Pattern
o The adapter pattern convert the interface of a class into another interface clients expect.
o Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.
 Bridge Method Design Pattern
o The bridge pattern allows the Abstraction and the Implementation to be developed
independently.
o The client code can access only the Abstraction part without being concerned about the
Implementation part.
 Composite Method Design Pattern
o As a partitioning design pattern, the composite pattern characterizes a collection of items that
are handled the same way as a single instance of the same type of object.
o The intent of a composite is to “compose” objects into tree structures to represent part-whole
hierarchies.
 Decorator Method Design Pattern
o It allows us to dynamically add functionality and behavior to an object without affecting the
behavior of other existing objects within the same class.
 o We use inheritance to extend the behavior of the class. This takes place at compile-time, and all
the instances of that class get the extended behavior.
 Facade Method Design Pattern
o Facade Method Design Pattern provides a unified interface to a set of interfaces in a subsystem.
o Facade defines a high-level interface that makes the subsystem easier to use.
 Flyweight Method Design Pattern
o This pattern provides ways to decrease object count thus improving application required objects
structure.
o Flyweight pattern is used when we need to create a large number of similar objects.
 Proxy Method Design Pattern
o Proxy means ‘in place of’, representing’ or ‘in place of’ or ‘on behalf of’ are literal meanings of
proxy and that directly explains Proxy Design Pattern.
o Proxies are also called surrogates, handles, and wrappers. They are closely related in structure,
but not purpose, to Adapters and Decorators.
Behavioral Design Patterns
Behavioral Patterns are concerned with algorithms and the assignment of responsibilities between
objects. Behavioral patterns describe not just patterns of objects or classes but also the patterns of
communication between them. These patterns characterize complex control flow that’s difficult to
follow at run-time.
Types of Behavioral Design Patterns:
 Chain Of Responsibility Method Design Pattern
o Chain of responsibility pattern is used to achieve loose coupling in software design where a
request from the client is passed to a chain of objects to process them.
o Later, the object in the chain will decide themselves who will be processing the request and
whether the request is required to be sent to the next object in the chain or not.
 Command Method Design Pattern
o A behavioral design pattern called the Command Pattern transforms a request into an
independent object with all of the information's request
o This object can be passed around, stored, and executed at a later time.
 Interpreter Method Design Pattern
o Interpreter pattern is used to defines a grammatical representation for a language and
provides an interpreter to deal with this grammar.
 Mediator Method Design Pattern
o It enables decoupling of objects by introducing a layer in between so that the interaction
between objects happen via the layer.
 Memento Method Design Patterns
o It is used to return an object's state to its initial state.
o You might wish to create checkpoints in your application and return to them at a later time
when it develops.
 Observer Method Design Pattern
o It establishes a one-to-many dependency between objects, meaning that all of the dependents
(observers) of the subject are immediately updated and notified when the subject changes.
 State Method Design Pattern
o When an object modifies its behavior according to its internal state, the state design pattern
is applied.
o If we have to change the behavior of an object based on its state, we can have a state variable
in the Object and use the if-else condition block to perform different actions based on the
state.
 Strategy Method Design Pattern
o It is possible to select an object's behavior at runtime by utilizing the Strategy Design
Pattern.
 o Encapsulating a family of algorithms into distinct classes that each implement a common
interface is the foundation of the Strategy pattern.
 Template Method Design Pattern
o The template method design pattern defines an algorithm as a collection of skeleton
operations, with the child classes handling the implementation of the specifics.
o The parent class maintains the overall structure and flow of the algorithm.
 Visitor Method Design Pattern
o It is used when we have to perform an operation on a group of similar kind of Objects. With
the help of visitor pattern, we can move the operational logic from the objects to another
class.
UML MODELLING TECHNIQUES (CLASS DIAGRAMS, SEQUENCE DIAGRAMS, STATE
MACHINE DIAGRAMS, ACTIVITY DIAGRAMS)
1)Class Diagram
 The class diagram depicts a static view of an application.
 It represents the types of objects residing in the system and the relationships between them.
 A class consists of its objects, and also it may inherit from other classes
 . A class diagram is used to visualize, describe, document various different aspects of the system,
and also construct executable software code.
 It shows the attributes, classes, functions, and relationships to give an overview of the software
system.
 It constitutes class names, attributes, and functions in a separate compartment that helps in
software development.
 Since it is a collection of classes, interfaces, associations, collaborations, and constraints, it is
termed as a structural diagram.
Purpose of Class Diagrams
 The main purpose of class diagrams is to build a static view of an application. It is the only
diagram that is widely used for construction, and it can be mapped with object-oriented
languages. It is one of the most popular UML diagrams. Following are the purpose of class
diagrams given below:
1. It analyses and designs a static view of an application.
2. It describes the major responsibilities of a system.
3. It is a base for component and deployment diagrams.
4. It incorporates forward and reverse engineering.
Vital components of a Class Diagram
o Upper Section: The upper section encompasses the name of the class. A class is a representation of
similar objects that shares the same relationships, attributes, operations, and semantics. Some of the
following rules that should be taken into account while representing a class are given below:
o Capitalize the initial letter of the class name.
o Place the class name in the centre of the upper section.
o A class name must be written in bold format.
o The name of the abstract class should be written in italics format.
o Middle Section: The middle section constitutes the attributes, which describe the quality of the
class. The attributes have the following characteristics:
o The attributes are written along with its visibility factors, which are public (+), private (-),
protected (#), and package (~).
o The accessibility of an attribute class is illustrated by the visibility factors.
o A meaningful name should be assigned to the attribute, which will explain its usage inside the
class.
o Lower Section: The lower section contain methods or operations. The methods are represented in
the form of a list, where each method is written in a single line. It demonstrates how a class interacts
with data.

Relationships
In UML, relationships are of three types:
1)Dependency: A dependency is a semantic relationship between two or more classes where a
change in one class cause changes in another class. It forms a weaker relationship.
In the following example, Student_Name is dependent on the Student_Id.

2)Generalization: A generalization is a relationship between a parent class (superclass) and a child

class (subclass). In this, the child class is inherited from the parent class.
For example, The Current Account, Saving Account, and Credit Account are the generalized form of
Bank Account.
3)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.

4)Multiplicity: It defines a specific range of allowable instances of attributes. In case if a

range is not specified, one is considered as a default multiplicity.
For example, multiple patients are admitted to one hospital.

5)Aggregation: An aggregation is a subset of association, which represents has a relationship.

It is more specific then association. It defines a part-whole or part-of relationship. In this kind
of relationship, the child class can exist independently of its parent class.
The company encompasses a number of employees, and even if one employee resigns, the
company still exists.

6)Composition: The composition is a subset of aggregation. It portrays the dependency

between the parent and its child, which means if one part is deleted, then the other part also
gets discarded. It represents a whole-part relationship.
A contact book consists of multiple contacts, and if you delete the contact book, all the
contacts will be lost.
 EXAMPLE OF CLASS DIGRAM:

Usage of Class diagrams

1. To describe the static view of a system.
2. To show the collaboration among every instance in the static view.
3. To describe the functionalities performed by the system.
4. To construct the software application using object-oriented languages.

SEQUENCE DIAGRAM
 The sequence diagram represents the flow of messages in the system and is also termed as an
event diagram.
 It helps in envisioning several dynamic scenarios.
 It portrays the communication between any two lifelines as a time-ordered sequence of events,
such that these lifelines took part at the run time.
 In UML, the lifeline is represented by a vertical bar, whereas the message flow is represented
by a vertical dotted line that extends across the bottom of the page.
  It incorporates the iterations as well as branching.
Purpose of a Sequence Diagram
1. To model high-level interaction among active objects within a system.
2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.

Notations of a Sequence Diagram

1)Lifeline
An individual participant in the sequence diagram is represented by a lifeline. It is positioned at the
top of the diagram.

2)Actor
A role played by an entity that interacts with the subject is called as an actor. It is out of the scope of
the system. It represents the role, which involves human users and external hardware or subjects. An
actor may or may not represent a physical entity, but it purely depicts the role of an entity. Several
distinct roles can be played by an actor or vice versa.

3)Activation
It is represented by a thin rectangle on the lifeline. It describes that time period in which an operation
is performed by an element, such that the top and the bottom of the rectangle is associated with the
initiation and the completion time, each respectively.
 4)Messages
The messages depict the interaction between the objects and are represented by arrows. They are in
the sequential order on the lifeline. The core of the sequence diagram is formed by messages and
lifelines.
Following are types of messages enlisted below:
o Call Message: It defines a particular communication between the lifelines of an interaction, which
represents that the target lifeline has invoked an operation.

o Return Message: It defines a particular communication between the lifelines of interaction that
represent the flow of information from the receiver of the corresponding caller message.

o Self Message: It describes a communication, particularly between the lifelines of an interaction that
represents a message of the same lifeline, has been invoked.
o Recursive Message: A self message sent for recursive purpose is called a recursive message. In
other words, it can be said that the recursive message is a special case of the self message as it
represents the recursive calls.

o Create Message: It describes a communication, particularly between the lifelines of an interaction

describing that the target (lifeline) has been instantiated.

o Destroy Message: It describes a communication, particularly between the lifelines of an interaction

that depicts a request to destroy the lifecycle of the target.
 o

o Duration Message: It describes a communication particularly between the lifelines of an interaction,

which portrays the time passage of the message while modeling a system.

Note
A note is the capability of attaching several remarks to the element. It basically carries useful
information for the modelers.
 EXAMPLE OF SEQUENCE DIGRAM

STATE MACHINE DIAGRAM

 The state machine diagram is also called the Statechart or State Transition diagram,
 which shows the order of states underwent by an object within the system.
 It captures the software system's behavior.
 It models the behavior of a class, a subsystem, a package, and a complete system.

Following are the types of a state machine diagram that are given below:
1. Behavioral state machine
The behavioral state machine diagram records the behavior of an object within the system. It depicts
an implementation of a particular entity. It models the behavior of the system.
2. Protocol state machine
It captures the behavior of the protocol. The protocol state machine depicts the change in the state of
the protocol and parallel changes within the system. But it does not portray the implementation of a
particular component.

Notation of a State Machine Diagram

Following are the notations of a state machine diagram enlisted below:
1. Initial state: It defines the initial state (beginning) of a system, and it is represented by a black filled
circle.
2. Final state: It represents the final state (end) of a system. It is denoted by a filled circle present
within a circle.
3. Decision box: It is of diamond shape that represents the decisions to be made on the basis of an
evaluated guard.
4. Transition: A change of control from one state to another due to the occurrence of some event is
termed as a transition. It is represented by an arrow labelled with an event due to which the change
has ensued.
5. State box: It depicts the conditions or circumstances of a particular object of a class at a specific
point of time. A rectangle with round corners is used to represent the state box.

Types of State
The UML consist of three states:
1. Simple state: It does not constitute any substructure.
2. Composite state: It consists of nested states (substates), such that it does not contain more than one
initial state and one final state. It can be nested to any level.
3. Submachine state: The submachine state is semantically identical to the composite state, but it can
be reused.

When to use a State Machine Diagram?

 The state machine diagram implements the real-world models as well as the object-oriented systems.
It records the dynamic behavior of the system, which is used to differentiate between the dynamic
and static behavior of a system.
EXAMPLE

1. An example of a top-level state machine diagram showing Bank Automated Teller Machine
(ATM) is given below.
2. Initially, the ATM is turned off. After the power supply is turned on, the ATM starts performing
the startup action and enters into the Self Test state.
3. If the test fails, the ATM will enter into the Out Of Service state, or it will undergo a
triggerless transition to the Idle state.
4. This is the state where the customer waits for the interaction.
5. Whenever the customer inserts the bank or credit card in the ATM's card reader, the ATM state
changes from Idle to Serving Customer, the entry action readCard is performed after
entering into Serving Customer state.
6. Since the customer can cancel the transaction at any instant, so the transition from Serving
Customer state back to the Idle state could be triggered by cancel event.
7. Here the Serving Customer is a composite state with sequential substates that are Customer
Authentication, Selecting Transaction, and Transaction.
8. Customer Authentication and Transaction are the composite states itself is displayed by a
hidden decomposition indication icon.
9. After the transaction is finished, the Serving Customer encompasses a triggerless transition
back to the Idle state.
10. On leaving the state, it undergoes the exit action ejectCard that discharges the customer card
 ACTIVITY DIAGRAM
 In UML, the activity diagram is used to demonstrate the flow of control within the system rather than
the implementation.
 It models the concurrent and sequential activities.
 The activity diagram helps in envisioning the workflow from one activity to another.
 It put emphasis on the condition of flow and the order in which it occurs.
 The flow can be sequential, branched, or concurrent, and to deal with such kinds of flows, the
activity diagram has come up with a fork, join, etc.
Components of an Activity Diagram
Activities
 The categorization of behaviour into one or more actions is termed as an activity. In other
words, it can be said that an activity is a network of nodes that are connected by edges.
 The edges depict the flow of execution.
 It may contain action nodes, control nodes, or object nodes.
 The control flow of activity is represented by control nodes and object nodes that illustrates
the objects used within an activity. The activities are initiated at the initial node and are
terminated at the final node.

Activity partition /swimlane

 The swimlane is used to cluster all the related activities in one column or one row. It can be
either vertical or horizontal.
 It used to add modularity to the activity diagram.
 It is not necessary to incorporate swimlane in the activity diagram. But it is used to add more
transparency to the activity diagram.

Forks
 Forks and join nodes generate the concurrent flow inside the activity.
 A fork node consists of one inward edge and several outward edges..
  Whenever a data is received at an inward edge, it gets copied and split crossways various
outward edges.
 It split a single inward flow into multiple parallel flows.

Join Nodes
 Join nodes are the opposite of fork nodes.
 A Logical AND operation is performed on all of the inward edges as it synchronizes the flow
of input across one single output (outward) edge.

Pins
 It is a small rectangle, which is attached to the action rectangle.
 It clears out all the messy and complicated thing to manage the execution flow of activities.
 It is an object node that precisely represents one input to or output from the action.

Notation of an Activity diagram

Activity diagram constitutes following notations:
1. Initial State: It depicts the initial stage or beginning of the set of actions.
2. Final State: It is the stage where all the control flows and object flows end.
3. Decision Box: It makes sure that the control flow or object flow will follow only one path.
4. Action Box: It represents the set of actions that are to be performed.
 EXAMPLE

USE AN ACTIVITY DIAGRAM

1. To graphically model the workflow in an easier and understandable way.
2. To model the execution flow among several activities.
3. To model comprehensive information of a function or an algorithm employed within the system.
4. To model the business process and its workflow.
5. To envision the dynamic aspect of a system.
6. To generate the top-level flowcharts for representing the workflow of an application.
7. To represent a high-level view of a distributed or an object-oriented system.
 LIBRARY MANAGEMENT SYSTEM
USE CASE

SEQUENCE DIGRAM

STATE MACHINE DIGARAM

ACTIVITY DIGRAM
CLASS DIGRAM