UNIT II

REQUIREMENTS ANALYSIS AND SPECIFICATION

Requirement analysis and specification – Requirements gathering and analysis – Functional and Non Functional
requirements – Software Requirement Specification – Formal system specification – Finite State Machines – Petrinets
– Object modelling using UML – Use case Model – Class diagrams – Interaction diagrams – Activity diagrams –
Functional modelling – Data Flow Diagram- CASE TOOLS.

Requirements Analysis and Specification

● All plan-driven life cycle models prescribe that before starting to develop a software, the exact requirements of the
customer must be understood and documented.
● Starting development work without properly understanding and documenting the requirements increases the number
of iterative changes in the later life cycle phases, and thereby alarmingly pushes up the development costs.
● A good requirements document not only helps to form a clear understanding of various features required from the
software, but also serves as the basis for various activities carried out during later life cycle phases.

Overview of requirements analysis and specification:

● The requirements analysis and specification phase starts after the feasibility study stage is complete and the project
has been found to be financially viable and technically feasible.
● The requirements analysis and specification phase ends when the requirements specification document has been
developed and reviewed.
● The requirements specification document is usually called the software requirements specification (SRS) document.
● The goal of the requirements analysis and specification phase is to clearly understand the customer requirements and
to systematically organize the requirements into a document called the Software Requirements Specification (SRS)
document.

Who performs requirements analysis

● Requirements analysis and specification activity is usually carried out by a few experiencedmembers of the
development team.
● It normally requires them to spend some time at the customer site.
● The engineers who gather and analyze customer requirements and then write therequirements specification
document are known as system analysts.

Requirements analysis and specification phase mainly involves carrying out the following two important activities:
● Requirements gathering and analysis.
● Requirements specification.

Requirements gathering and analysis:

● The complete set of requirements are almost never available in the form of a singledocument from the customer.
● Complete requirements are rarely obtainable from any single customer representative.
● We can conceptually divide the requirements gathering and analysis activity into two separate tasks:
 Requirements gathering and Requirements Analysis

Requirements gathering.

● Requirements gathering is also popularly known as requirements elicitation.

● The primary objective of the requirements gathering task is to collect the requirements from the stakeholders.
● A stakeholder is a source of the requirements and is usually a person, or a group of persons who either directly or
indirectly are concerned with the software.
● It is very difficult to gather all the necessary information from a large number ofstakeholders and from
information scattered across several pieces of documents.
● Gathering requirements turns out to be especially challenging if there is no working model of the software being
developed.
● Important ways in which an experienced analyst gathers requirements:
● Studying existing documentation:
○ The analyst usually studies all the available documents regarding the system tobe developed before visiting the
customer site.
○ Customers usually provide a statement of purpose (SoP) document to thedevelopers.
● Interview:
○ Typically, there are many different categories of users of a software.
○ Each category of users typically requires a different set of features from thesoftware.
○ Therefore, it is important for the analyst to first identify the different categories ofusers and then determine the
requirements of each.
Refer to: Delphi method
Task analysis:
○ The users usually have a black-box view of a software and consider the softwareas something that provides a
set of services (functionalities).
○ A service supported by software is also called a task.
○ The analyst tries to identify and understand the different tasks to be performedby the software.
○ For each identified task, the analyst tries to formulate the different stepsnecessary to realize the required
functionality in consultation with the users.
● Scenario analysis:
○ A task can have many scenarios of operation.
○ The different scenarios of a task may take place when the task is invoked underdifferent situation
 For different types of scenarios of a task, the behaviour of the software can be different.
Form analysis:
○ Form analysis is an important and effective requirements gathering activity that is undertaken by the analyst,
when the project involves automating an existing manual system.
○ In form analysis the existing forms and the formats of the notifications producedare analyzed to determine the
data input to the system and the data that are output from the system.

Requirements analysis:

● After requirements gathering is complete, the analyst analyses the gathered requirements to form a clear
understanding of the exact customer requirements and to weed out any problems in the gathered requirements.
● During requirements analysis, the analyst needs to identify and resolve three main types of problems in the
requirements:

○ Anomaly:
■ An anomaly is an ambiguity in a requirement. When a requirement is anomalous, several interpretations of that
requirement are possible.
■ Example: While gathering the requirements for a process control application, the following requirement was
expressed by a certain stakeholder: “When the temperature becomes high, the heater should be switched off”.
Please note that words such as “high”, “low”, “good”, “bad” etc. are indications of ambiguous requirements as
these lack quantification and can be subjectively interpreted.

○ Inconsistency:
■ Two requirements are said to be inconsistent, if one of the requirements contradicts the other.
■ Example: Consider the following two requirements that were collected from two different stakeholders in a
process control application development project.
● The furnace should be switched-off when the temperature of the furnace risesabove 500℃.
● When the temperature of the furnace rises above 500℃, the water shower should be switched-on and the
furnace should remain on.

○ Incompleteness:
■ An incomplete set of requirements is one in which some requirements have been overlooked. The lack of
these features would be felt by the customer much later, possibly while using the software.
■ Example: In a chemical plant automation software, suppose one of the requirements is that if the internal
temperature of the reactor exceeds 200℃ then an alarm bell must be sounded. However, on an examination
of all requirements, it was found that there is no provision for resetting the alarm bell after the temperature
has been brought down in any of the requirements. This is clearly an incomplete requirement.
 Software Requirements Specification (SRS):

● After the analyst has gathered all the required information regarding the software to be developed, and has removed all
incompleteness, inconsistencies, and anomalies from the specification, he starts to systematically organize the
requirements in the form of an SRS document.
● The SRS document usually contains all the user requirements in a structured though an informal form.SRS document is
probably the most important document and is the toughest to write.
● One reason for this difficulty is that the SRS document is expected to cater to the needs of a wide variety of audience.
● A well-formulated SRS document finds a variety of usage:
○ Forms an agreement between the customers and the developers.
○ Reduces future reworks.
○ Provides a basis for estimating costs and schedules
○ Provides a baseline for validation and verification
○ Facilitates future extensions

Users of SRS document:

● Users, customers, and marketing personnel:

These stakeholders need to refer to the SRS document to ensure that the system as described in the document will meet
their needs.
● Software developers:
The software developers refer to the SRS document to make sure that they are developing exactly what is required by
the customer.
● Test engineers:
The test engineers use the SRS document to understand the functionalities, and based on this write the test cases to
validate its working.
● User documentation writers:
The user documentation writers need to read the SRS document to ensure that they understand the features of the
product well enough to be able to write the users’ manuals.
● Project managers:
The project managers refer to the SRS document to ensure that they can estimate the cost of the project easily by
referring to the SRS document and that it contains all the information required to plan the project.
● Maintenance engineers:
The SRS document helps the maintenance engineers to under- stand the functionalities supported by the system.

Characteristics of a Good SRS Document:

● IEEE Recommended Practice for Software Requirements Specifications describes thecontent and qualities of a good
software requirements specification (SRS).
● Some of the identified desirable qualities of an SRS document are the following:
○ Concise: The SRS document should be concise and at the same time unambiguous,consistent, and complete.
○ Implementation-independent:
The SRS should be free of design and implementation decisions unless those decisions reflect actual requirements. It
should only specify what the system should do and refrain from stating how to do these.
○ Traceable:
It should be possible to trace a specific requirement to the design elements that implement it and vice versa. Similarly,
it should be possible to trace a requirement to the code segments that implement it and the test cases that test this
requirement and vice versa.
○ Modifiable:
Customers frequently change the requirements during the software development due to a variety of reasons.
Therefore, in practice the SRS document undergoes several revisions during software development. To cope up with
the requirementschanges, the SRS document should be easily modifiable. For this, an SRS document should be well-
structured.
○ Identification of response to undesired events:
The SRS document should discuss the system responses to various undesired events and exceptional conditions that
may arise.
○ Verifiable:
All requirements of the system as documented in the SRS document should be verifiable. This means that it should
be possible to design test cases based onthe description of the functionality as to whether or not requirements have
been met in an implementation.

Categories of Customer requirements:

An SRS document should clearly document the following aspects of a software:
● Functional requirements
● Non-functional requirements
○ Design and implementation constraints
○ External interfaces required
○ Other non-functional requirements
● Goals of implementation.

Functional Requirements:
● The functional requirements capture the functionalities required by the users from the system.
● Consider a software as offering a set of functions {fi} to the user.
● These functions can be considered similar to a mathematical function f : I → O, meaning that a function transforms
an element (ii) in the input domain (I) to a value (oi) in the output (O).
● In order to document the functional requirements of a system, it is necessary to first learn to identify the high-level
functions of the systems by reading the informal documentation of the gathered requirements.
● Each high-level function is an instance of use of the system (use case) by the user in some way.
● A high-level function is one using which the user can get some useful piece of work done.
● Each high-level requirement typically involves accepting some data from the user through a user interface,
transforming it to the required response, and then displaying the system response in proper format.
● A high-level function transforms certain input data to output data.
● Except for very simple high- level functions, a function rarely reads all its required data inone go and rarely
outputs all the results in one shot.
● A high-level function usually involves a series of interactions between the system and one or more users.
● Functional requirements form the basis for most design and test methodologies.
● Unless the functional requirements are properly identified and documented, the design and testing activities cannot
be carried out satisfactorily.
● Once all the high-level functional requirements have been identified and the requirements problems have been
eliminated, these are documented.
● A function can be documented by identifying the state at which the data is to be input to thesystem, its input data
domain, the output data domain, and the type of processing to be carried on the input data to obtain the output data.
● Refer to Withdraw cash from ATM example in text book.

Non-functional Requirements:
● The non-functional requirements are non-negotiable obligations that must be supported by the software.
● The non-functional requirements capture those requirements of the customer that cannot be expressed as functions.
● Aspects concerning external interfaces, user interfaces, maintainability, portability, usability,maximum number of
concurrent users, timing, and throughput.
● The non-functional requirements can be critical in the sense that any failure by the developed software to achieve
some minimum defined level in these requirements can be considered as a failure and make the software
unacceptable by the customer.
● Design and implementation constraints:
○ Design and implementation constraints are an important category of non-functional requirements describing
any items or issues that will limit the options available to the developers.
○ Some of the example constraints can be—corporate or regulatory policies that need to be honored; hardware
limitations; interfaces with other applications; specific technologies, tools, and databases to be used; specific
communications protocols to be used; security considerations etc.
● External interfaces required:
○ Examples of external interfaces are - hardware, software and communicationinterfaces, user interfaces,
report formats, etc.
○ To specify the user interfaces, each interface between the software and the usersmust be described.
○ One example of a user interface requirement of a software can be that it should beusable by factory shop
floor workers who may not even have a high school degree
 ● Other non-functional requirements:
● This section contains a description of non- functional requirements that are neither design constraints nor
are external interface requirements.
● An important example is a performance requirement such as the number oftransactions completed per unit
time.

Goals of implementation:
● The ‘goals of implementation’ part of the SRS document offers some general suggestions regarding the software to
be developed.
● A goal, in contrast to the functional and nonfunctional requirements, is not checked by the customer for conformance
at the time of acceptance testing.
● The goals of the implementation section might document issues such as easier revisions tothe system functionalities
that may be required in the future, easier support for new devicesto be supported in the future, reusability issues, etc.

Organization of the SRS Document:

● The organization of an SRS document is prescribed by the IEEE 830 standard.
● IEEE 830 standard has been intended to serve only as a guideline for organizing a requirements specification
document into sections and allows the flexibility of tailoring it.
● Depending on the type of project being handled, some sections can be omitted, introduced,or interchanged.
● The three basic issues that any SRS document should discuss are—functional requirements, non-functional
requirements, and guidelines for system implementation.
● The introduction section should describe the context in which the system is being developed, and provide an overall
description of the system, and the environmental characteristics.

Various Sections of SRS:

Introduction
● Purpose: This section should describe where the software would be deployed and how the software would be
used.
● Project scope: This section should briefly describe the overall context within which the software is being
developed.
● Environmental characteristics: This section should briefly outline the environment (hardware and other
software) with which the software will interact.

Overall description of organization of SRS document

● Product perspective: This section needs to briefly state as to whether the software is intended to be a replacement
for a certain existing system, or it is a new software.
● Product features: This section should summarize the major ways in which the software would be used.
● User classes: Various user classes that are expected to use this software are identified and described here.
● Operating environment: This section should discuss in some detail the hardware platform on which the software
would run, the operating system, and other application software with which the developed software would interact.
● Design and implementation constraints: In this section, the different constraints on the design and implementation
are discussed.
● User documentation: This section should list out the types of user documentation, such asuser manuals, on-line
help, and trouble-shooting manuals that will be delivered to the customer along with the software.
IEEE format for SRS Document

External interface requirements

User interfaces: This section should describe a high-level description of various interfaces and various
principles to be followed.

Hardware interfaces: This section should describe the interface between the software andthe hardware components
of the system.
 Software interfaces: This section should describe the connections between this software and other specific
software components, including databases, operating systems, tools, libraries, and integrated commercial
components, etc.
Communications interfaces: This section should describe the requirements associated with any type of
communications required by the software, such as e-mail, web access, network server communications protocols,
etc.

Other non-functional requirements for organization of SRS document

● Performance requirements: Aspects such as number of transactions to be completed per second should be
specified here.
● Safety requirements: Those requirements that are concerned with possible loss ordamage that could result
from the use of the software are specified here.
● Security requirements: This section should specify any requirements regarding security or privacy
requirements on data used or created by the software.

Self Study:
Example Functional Requirements for Library Automation System in Text book.

Formal system specification

Formal system specification is a process in software engineering where the behavior, requirements, and
constraints of a system are expressed using formal languages and mathematical notations. It provides
a rigorous and unambiguous description of the system, which helps in understanding, analyzing, and
verifying its properties. Formal specification techniques help in improving the quality, reliability, and
maintainability of software systems. Here are some key aspects of formal system specification:

1. Precision and Unambiguity: Formal specifications aim to remove ambiguity and provide precise
definitions of system behavior and requirements. This precision helps in avoiding misunderstandings
and inconsistencies during the software development process.
2. Expressiveness: Formal specification languages provide expressive power to describe complex
system behaviors, requirements, and constraints in a concise and structured manner. These languages
often include constructs for specifying data types, operations, state transitions, and temporal
properties.
3. Mathematical Foundation: Formal specification techniques are based on mathematical principles
and formalisms, such as set theory, predicate logic, automata theory, and formal semantics. These
mathematical foundations enable rigorous reasoning and analysis of system properties.
4. Abstraction and Modularity: Formal specifications allow the system to be described at different
levels of abstraction, from high-level requirements to low-level implementation details. Modularity
in specifications facilitates the decomposition of complex systems into smaller, more manageable
components.
5. Verification and Validation: Formal specifications support formal methods for verifying and
validating system properties, such as consistency, completeness, correctness, and conformance to
requirements. Techniques such as model checking, theorem proving, and simulation are used to
analyze the behavior of the system against its specification.
6. Documentation and Communication: Formal specifications serve as comprehensive
documentation of the system's behavior and requirements, which can be used to communicate design
decisions, constraints, and assumptions among stakeholders, including developers, testers, and users.
7. Tool Support: Various tools and automated techniques are available to support the formal
specification process, including specification languages, model checkers, theorem provers, and static
 analyzers. These tools help in writing, analyzing, and maintaining formal specifications throughout
the software development lifecycle.
8. Integration with Development Process: Formal system specification is often integrated into the
software development process alongside other activities such as requirements analysis, design,
implementation, testing, and maintenance. It provides a foundation for systematic and disciplined
development practices.

Overall, formal system specification plays a crucial role in software engineering by providing a
rigorous and structured approach to defining system behavior and requirements, facilitating analysis,
verification, and validation, and ultimately improving the quality and reliability of software systems.

Finite State Machine

Finite State Machines (FSMs) are fundamental concepts in software engineering used to model and
control the behavior of systems with discrete states. FSMs consist of a set of states, transitions between
these states, and actions associated with these transitions.

Here's how FSMs are applied in software engineering:

1. Modeling System Behavior: FSMs are used to model the behavior of systems that exhibit discrete
states and transitions between these states. These systems could range from simple vending
machines to complex protocol implementations.
2. Designing Stateful Components: FSMs help in designing stateful components where the behavior
of the component depends on its current state and the input it receives. By defining states and
transitions, developers can create systems that react in predictable ways to various inputs and
events.
3. Implementation of Protocols and Communication Systems: FSMs are extensively used in the
implementation of communication protocols and network systems. The states represent different
phases of the communication process, and transitions depict how the system responds to incoming
messages or events.
4. Validation and Verification: FSMs can be used to formally verify the correctness of systems by
analyzing their state spaces and ensuring that certain properties hold under different conditions.
Model checking techniques can be applied to automatically verify properties of FSMs.
5. Embedded Systems and Real-time Applications: In embedded systems and real-time applications,
where timing and resource constraints are critical, FSMs offer a structured approach to managing
system behavior. They can help in designing systems that respond to inputs within specific time
constraints and maintain correct behavior under various conditions.
6. Compiler Design and Parsing: FSMs play a crucial role in compiler design and parsing algorithms.
Lexical analyzers and parsers often use FSMs to recognize and process tokens and syntactic
structures in programming languages.
7. User Interface Design: FSMs can be applied in user interface design to model different states of an
application's user interface and transitions triggered by user actions. This approach helps in creating
intuitive and responsive user experiences.
8. Game Development: FSMs are commonly used in game development to model the behavior of
characters, game states, and game mechanics. They help in defining how entities in the game world
interact and respond to player input.

Overall, Finite State Machines provide a structured and formal approach to modeling and controlling
the behavior of systems in software engineering, making them a powerful tool for designing robust and
predictable software systems.
Petri Nets
 Petri Nets are mathematical modeling languages used to describe and analyze systems characterized by
concurrent processes, synchronization, and resource sharing. They find applications in various
domains, including software engineering. Here's how Petri Nets are used in software engineering:

1. Concurrency Modeling: Petri Nets are effective in modeling concurrent systems where multiple
processes can execute simultaneously. In software engineering, concurrent systems are prevalent,
especially in multi-threaded and distributed applications. Petri Nets help in modeling the concurrent
behavior of such systems, including synchronization, communication, and resource sharing among
concurrent processes.
2. Workflow Modeling: Petri Nets are used to model and analyze workflows in software systems.
Workflow modeling involves representing the sequence of tasks or activities that need to be
performed to complete a process. Petri Nets can capture the dependencies between different tasks,
decision points, and concurrency aspects in workflows, enabling the analysis of process efficiency,
deadlock detection, and resource allocation.
3. Protocol Verification: Petri Nets are employed in the formal verification of communication
protocols and distributed systems. They help in specifying the expected behavior of protocols and
verifying properties such as deadlock freedom, liveliness, and message ordering. Petri Net-based
verification techniques ensure that communication protocols adhere to specified requirements and
standards.
4. Software Architecture Analysis: Petri Nets are used to model and analyze the behavior of software
architectures. They help in understanding the interactions between software components, the flow
of data and control among components, and the overall system behavior. Petri Net-based analysis
techniques aid in identifying potential bottlenecks, performance issues, and architectural flaws in
software systems.
5. Concurrency Control and Transaction Management: Petri Nets are applied in the design and
analysis of concurrency control mechanisms and transaction management protocols in database
systems. They help in modeling the concurrent execution of transactions, the coordination of
database accesses, and the prevention of conflicts and inconsistencies in data updates.
6. Formal Specification and Verification: Petri Nets serve as formal specification languages for
describing system behavior and requirements in software engineering. They provide a precise and
rigorous notation for capturing the dynamic behavior of software systems, facilitating formal
verification techniques such as model checking and theorem proving to ensure system correctness
and consistency.
7. Software Simulation and Testing: Petri Nets support software simulation and testing activities by
providing a graphical representation of system behavior and interactions. Software developers use
Petri Nets to simulate the execution of software systems, analyze performance metrics, and identify
potential issues such as deadlocks, livelocks, and resource contention.

Overall, Petri Nets are valuable modeling and analysis tools in software engineering, enabling the
formal representation, analysis, and verification of complex software systems and protocols. They help
in improving system reliability, performance, and maintainability by identifying and addressing design
flaws and concurrency-related issues early in the development lifecycle.

Unified Modeling Language (UML)

It is a general-purpose modeling language. The main aim of UML is to define a standard way
to visualize the way a system has been designed. It is quite similar to blueprints used in other
fields of engineering. UML is not a programming language, it is rather a visual language.

• We use UML diagrams to portray the behavior and structure of a system.

• UML helps software engineers, businessmen, and system architects with modeling, design,
and analysis.
• The Object Management Group (OMG) adopted Unified Modelling Language as a standard
in 1997. It’s been managed by OMG ever since.
• The International Organization for Standardization (ISO) published UML as an approved
standard in 2005. UML has been revised over the years and is reviewed periodically.

Why do we need UML?

• Complex applications need collaboration and planning from multiple teams and hence require
a clear and concise way to communicate amongst them.
• Businessmen do not understand code. So UML becomes essential to communicate with non-
programmers about essential requirements, functionalities, and processes of the system.
• A lot of time is saved down the line when teams can visualize processes, user interactions,
and the static structure of the system.

Different Types of UML Diagrams

UML is linked with object-oriented design and analysis. UML makes use of elements and forms
associations between them to form diagrams. Diagrams in UML can be broadly classified as:
0 seconds of 0 secondsVolume 0%

Structural UML Diagrams

Class Diagram

The most widely use UML diagram is the class diagram. It is the building block of all object
oriented software systems. We use class diagrams to depict the static structure of a system by
showing system’s classes, their methods and attributes. Class diagrams also help us identify
relationship between different classes or objects.
Composite Structure Diagram
 We use composite structure diagrams to represent the internal structure of a class and its
interaction points with other parts of the system.
• A composite structure diagram represents relationship between parts and their configuration
which determine how the classifier (class, a component, or a deployment node) behaves.
• They represent internal structure of a structured classifier making the use of parts, ports, and
connectors.
• We can also model collaborations using composite structure diagrams.
• They are similar to class diagrams except they represent individual parts in detail as compared
to the entire class.

Object Diagram

An Object Diagram can be referred to as a screenshot of the instances in a system and the
relationship that exists between them. Since object diagrams depict behaviour when objects
have been instantiated, we are able to study the behaviour of the system at a particular instant.

1. An object diagram is similar to a class diagram except it shows the instances of classes in
the system.
2. We depict actual classifiers and their relationships making the use of class diagrams.
3. On the other hand, an Object Diagram represents specific instances of classes and
relationships between them at a point of time

Component Diagram

Component diagrams are used to represent how the physical components in a system have been
organized. We use them for modelling implementation details.
• Component Diagrams depict the structural relationship between software system
elements and help us in understanding if functional requirements have been covered by
planned development.
• Component Diagrams become essential to use when we design and build complex
systems.
• Interfaces are used by components of the system to communicate with each other.

Deployment Diagram

Deployment Diagrams are used to represent system hardware and its software.It tells us what
hardware components exist and what software components run on them.
• We illustrate system architecture as distribution of software artifacts over distributed
targets.
• An artifact is the information that is generated by system software.
• They are primarily used when a software is being used, distributed or deployed over
multiple machines with different configurations.
Package Diagram
We use Package Diagrams to depict how packages and their elements have been organized. A
package diagram simply shows us the dependencies between different packages and internal
composition of packages.
• Packages help us to organise UML diagrams into meaningful groups and make the
diagram easy to understand.
• They are primarily used to organise class and use case diagrams.
Behavioural UML Diagrams

State Machine Diagrams

A state diagram is used to represent the condition of the system or part of the system at finite
instances of time. It’s a behavioral diagram and it represents the behavior using finite state
transitions.
• State diagrams are also referred to as State machines and State-chart Diagrams .
• These terms are often used interchangeably. So simply, a state diagram is used to model
the dynamic behavior of a class in response to time and changing external stimuli.

Activity Diagrams

We use Activity Diagrams to illustrate the flow of control in a system. We can also use an
activity diagram to refer to the steps involved in the execution of a use case.

• We model sequential and concurrent activities using activity diagrams. So, we basically
depict workflows visually using an activity diagram.
• An activity diagram focuses on condition of flow and the sequence in which it happens.
• We describe or depict what causes a particular event using an activity diagram.

Use Case Diagrams

Use Case Diagrams are used to depict the functionality of a system or a part of a system. They
are widely used to illustrate the functional requirements of the system and its interaction with
external agents(actors).
• A use case is basically a diagram representing different scenarios where the system can
be used.
• A use case diagram gives us a high level view of what the system or a part of the
system does without going into implementation details.

Sequence Diagram

A sequence diagram simply depicts interaction between objects in a sequential order i.e. the
order in which these interactions take place.
• We can also use the terms event diagrams or event scenarios to refer to a sequence
diagram.
• Sequence diagrams describe how and in what order the objects in a system function.
• These diagrams are widely used by businessmen and software developers to document
and understand requirements for new and existing systems.

Communication Diagram

A Communication Diagram (known as Collaboration Diagram in UML 1.x) is used to show

sequenced messages exchanged between objects.
• A communication diagram focuses primarily on objects and their relationships.
• We can represent similar information using Sequence diagrams, however
communication diagrams represent objects and links in a free form.
Timing Diagram

Timing Diagram are a special form of Sequence diagrams which are used to depict the behavior
of objects over a time frame. We use them to show time and duration constraints which govern
changes in states and behavior of objects.

Interaction Overview Diagram

An Interaction Overview Diagram models a sequence of actions and helps us simplify complex
interactions into simpler occurrences. It is a mixture of activity and sequence diagrams.

Use-Case Model

The Use-case model is defined as a model which is used to show how users interact with the system in
order to solve a problem. As such, the use case model defines the user's objective, the interactions
between the system and the user, and the system's behavior required to meet these objectives.

Various model elements are contained in use-case model, such as actors, use cases, and the association
between them.

We use a use-case diagram to graphically portray a subset of the model in order to make the
communication simpler. There will regularly be a numerous use-case diagram which is related to the
given model, each demonstrating a subset of the model components related to a specific purpose. A
similar model component might be appearing on a few use-case diagrams; however, each use-case
should be consistent. If, in order to handle the use-case model, tools are used then this consistency
restriction is automated so that any variations to the component of the model (changing the name, for
instance) will be reflected automatically on each use-case diagram, which shows that component.

Packages may include a use-case model, which is used to organize the model to simplify the analysis,
planning, navigation, communication, development and maintenance.

Various use-case models are textual and the text captured in the use-case specifications, which are
linked with the element of every use-case model. The flow of events of the use case is described with
the help of these specifications.

The use-case model acts as an integrated thread in the development of the entire system. The use-case
model is used like the main specification of the system functional requirements as the basis for design
and analysis, as the basis for user documentation, as the basis of defining test cases, and as an input to
iteration planning.

Origin of Use-Case

Nowadays, use case modeling is frequently connected with UML, in spite of the fact that it has been
presented before UML existed. Its short history is:

o Ivar Jacobson, in the year 1986, originally formulated textual and visual modeling methods to
specify use cases.
o And in the year 1992, his co-authored book named Object-Oriented Software Engineering - A Use
Case Driven Approach, assisted with promoting the strategy for catching functional requirements,
particularly in software development.

Components of Basic Model

There are various components of the basic model:

1. Actor
2. Use Case
3. Associations

Actor
Usually, actors are people involved with the system defined on the basis of their roles. An actor can be
anything such as human or another external system.

Use Case
The use case defines how actors use a system to accomplish a specific objective. The use cases are
generally introduced by the user to meet the objectives of the activities and variants involved in the
achievement of the goal.

Associations
Associations are another component of the basic model. It is used to define the associations among
actors and use cases they contribute in. This association is called communicates-association.

Advanced Model Components

There are various components of the advanced model:

1. Subject
2. Use-Case Package
3. Generalizations
4. Generalizations
5. Dependencies

Subject
The subject component is used to represent the boundary of the system of interest.

Use-Case Package
We use the model component in order to structure the use case model to make simpler the analysis,
planning, navigation, and communication. Suppose there are various actors or use cases. In that case,
we can also use use-case packages in order to further structure the use-case model in much the similar
way we use directories or folders to organize the information on our hard-disk.

For various reasons, we divide the use-case model into the use-case packages, containing:

o To help parallel development by partitioning the problem into bite-sized parts.

o To improve communication with various stakeholders by making packaging containing actors, use
cases and related to the specific stakeholder.

Generalizations
Generalizations mean the association between the actors in order to help re-use of common properties.

Dependencies
In UML, various types of dependencies are defined between use cases. In particular, <<include>> and
<<extend>>.

ADVERTISEMENT

We use <<include>> dependency to comprise shared behavior from an included use case into a base
use case to use common behavior.

We use <<extend>> dependency to include optional behavior from an extended use-case into an
extended use case.

How to Draw a Use-Case Diagram?

If we want to draw a use case diagram in UML first, we must study the complete system appropriately.
We need to find out every function which is offered by the system. When we find out all the system's
functionalities then we convert these functionalities into a number of use cases, and we use these use-
cases in the use case diagram.

A use case means essential functionality of any working system. When we organize the use cases, then
next we need to enlist the numerous actors or things that will collaborate with the system. These actors
are used to implement the functionality of a system. Actors can be someone or something. It can
likewise be a private system's entity. The actors should be pertinent to the functionality or a system in
which the actors are interacting.

When we enlist the use cases and actors, then next, we need to find the relationship of a specific actor
with the system or a use case. An actor should find the total number of ways in order to cooperate with
the system. One actor can interact with the numerous use cases simultaneously, or it may interact with
the multiple-use cases concurrently.

We have to follow the following rules while drawing use-case for any framework:

o The use case name and actor name should be meaningful and related to the system.
o The actor's interaction with the use case should be well-described and in a comprehensible manner.
o Use annotations wherever they are essential.
o If the actor or use case has many relationships, then display only important interactions.
When to Use a Use-Case Diagram?

The use-case diagram is an extraordinary system's functionality that is accomplished by a client. The
objective of use-case diagram is to capture the system's key functionalities and visualize the interactions
of different thinkings known as actors with the use case. It is the basic use of use-case diagram.

With the help of the use-case diagram, we can characterize the system's main part and flow of work
among them. In the use-case, the implementation of details is hidden from external use, and only the
flow of the event is represented.

Using use-case diagrams, we can detect the pre-and post-conditions after communication with the actor.
We can determine these conditions using several test cases.

Generally, the use-cases diagram is used for:

o Examining the system's requirements.

o Capturing the system's Functionalities.
o We use use-case diagram in order to modeling the general idea behind the system.
o System's Forward and reverse engineering using several test cases.
o Complex visual designing of software.

Use cases are planned to convey wanted functionality so that the exact scope of use case can differ
based on the system and the purpose of making the UML model.

Tips for Drawing a Use-Case Diagram

There are various tips for drawing a use-case diagram:

o It must be complete.
o It must be simple.
o The use-case diagram must show each and every interaction with the use case.
o It is must that the use-case should be generalized if it is large.
o At least one system module must be defined in the use case diagram.
o When there are number of actors or use-cases in the use-case diagram, only the significant use-cases
must be represented.
o The use-case diagrams must be clear and easy so that anyone can understand them easily.

Importance of Use-Case Diagram

Use Cases have been broadly used over the last few years. There are various benefits of the use-case
diagram:

o Use-case diagram provides an outline related to all components in the system. Use-case diagram
helps to define the role of administrators, users, etc.
o The use-Case diagram helps to provide solutions and answers to various questions that may pop up
if you begin a project unplanned.
o It helps us to define the needs of the users extensively and explore how it will work.

Basic Use-Case Diagram Symbols and Notations

There are following use-case diagram symbols and notations:

System
With the help of the rectangle, we can draw the boundaries of the system, which includes use-cases.
We need to put the actors outside the system's boundaries.

Use-Case
With the help of the Ovals, we can draw the use-cases. With the verb we have to label the ovals in order
to represent the functions of the system.

Actors
Actors mean the system's users. If one system is the actor of the other system, then with the actor
stereotype, we have to tag the actor system.

Relationships
 With the simple line we can represent relationships between an actor and use cases. For relationships
between use-case, we use arrows which are labeled either "extends" or "uses". The "extends"
relationship shows the alternative options under the specific use case. The "uses" relationship shows
that single use-case is required to accomplish a job.

ADVERTISEMENT

Guidelines for Better Use-Cases

With regards to examine the system's requirements, use-case diagrams are another one to one. Use-
cases are simple to understand and visual. The following are some guidelines that help you to make
better use cases that are appreciated by your customers and peers the same.

Generally, the use-case diagram contains use-cases, relationships, and actors. Systems and boundaries
may be included in the complex larger diagrams. We'll talk about the guidelines of the use-case diagram
on the basis of the objects.

Do not forget that these are the use case diagram's guidelines, not rules of the use-case diagram.

Actors

o The actor's name should be meaningful and relevant to the business

If the use-case interacting with the outside organization, then we have to give the actor's name with
the function instead of the organization name, such as Airline company is better than the PanAir).
o Place inheriting actors below the parent actor
We have to place the inheriting actors below the parent actor because it makes the actors more
readable and easily highlights the use-cases, which are exact for that actor.
o External Systems are actors
If send-email is our use-case and when the use-case interrelates with the email management software,
then in this case, the software is an actor to that specific user-case.

Use-Cases

o The name of the use-case begins with a verb

The use-case models action, so the name of the use-case must start with a verb.
o The name of the use-case must be descriptive
The use-case is created to provide more information to others who are looking at a diagram, such as
instead of "Print," "print Invoice is good.
o Put the use-cases to the right of the included use-cases.
In order to add clarity and enhance readability, we have to place the included use-cases to the right of
the invoking use-cases.
o Place inheriting use-case below the parent use-case
In order to enhance the diagram's readability, we have to place the inheriting use-case below the
parent use-case.

Systems/Packages

o Give descriptive and meaningful names to these objects.

o Use them carefully and only if needed.

Class diagrams

Class diagrams are a type of UML (Unified Modeling Language) diagram used in software
engineering to visually represent the structure and relationships of classes in a system. UML is
a standardized modeling language that helps in designing and documenting software systems.
They are an integral part of the software development process, helping in both the design and
documentation phases.

In these diagrams, classes are depicted as boxes, each containing three compartments for the
class name, attributes, and methods. Lines connecting classes illustrate associations, showing
relationships such as one-to-one or one-to-many.

Class diagrams provide a high-level overview of a system’s design, helping to communicate

and document the structure of the software. They are a fundamental tool in object-oriented
design and play a crucial role in the software development lifecycle.

What is a class?

In object-oriented programming (OOP), a class is a blueprint or template for creating objects.

Objects are instances of classes, and each class defines a set of attributes (data members) and
methods (functions or procedures) that the objects created from that class will possess. The
attributes represent the characteristics or properties of the object, while the methods define the
behaviors or actions that the object can perform.

UML Class Notation

Class notation is a graphical representation used to depict classes and their relationships in
object-oriented modeling.

1. Class Name:
• The name of the class is typically written in the top compartment of the class box and is
centered and bold.
2. Attributes:
• Attributes, also known as properties or fields, represent the data members of the class. They
are listed in the second compartment of the class box and often include the visibility (e.g.,
public, private) and the data type of each attribute.
3. Methods:
• Methods, also known as functions or operations, represent the behavior or functionality of the
class. They are listed in the third compartment of the class box and include the visibility (e.g.,
public, private), return type, and parameters of each method.
4. Visibility Notation:
• Visibility notations indicate the access level of attributes and methods. Common visibility
notations include:
• + for public (visible to all classes)
• - for private (visible only within the class)
• # for protected (visible to subclasses)
• ~ for package or default visibility (visible to classes in the same package)
Parameter Directionality
In class diagrams, parameter directionality refers to the indication of the flow of information
between classes through method parameters. It helps to specify whether a parameter is an input,
an output, or both. This information is crucial for understanding how data is passed between
objects during method calls.

There are three main parameter directionality notations used in class diagrams:
• In (Input):
•An input parameter is a parameter passed from the calling object (client) to the called
object (server) during a method invocation.
•It is represented by an arrow pointing towards the receiving class (the class that owns the
method).
• Out (Output):
•An output parameter is a parameter passed from the called object (server) back to the
calling object (client) after the method execution.
•It is represented by an arrow pointing away from the receiving class.
• InOut (Input and Output):
•An InOut parameter serves as both input and output. It carries information from the
calling object to the called object and vice versa.
•It is represented by an arrow pointing towards and away from the receiving class.
Relationships between classes
In class diagrams, relationships between classes describe how classes are connected or interact
with each other within a system. There are several types of relationships in object-oriented
modeling, each serving a specific purpose. Here are some common types of relationships in
class diagrams:
 1. Association
An association represents a bi-directional relationship between two classes. It indicates that
instances of one class are connected to instances of another class. Associations are typically
depicted as a solid line connecting the classes, with optional arrows indicating the direction of
the relationship.
Let’s understand association using an example:
Let’s consider a simple system for managing a library. In this system, we have two main
entities: Book and Library. Each Library contains multiple Books, and each Book belongs to a
specific Library. This relationship between Library and Book represents an association.
The “Library” class can be considered the source class because it contains a reference to
multiple instances of the “Book” class. The “Book” class would be considered the target class
because it belongs to a specific library.

2. Directed Association
A directed association in a UML class diagram represents a relationship between two classes
where the association has a direction, indicating that one class is associated with another in a
specific way.
• In a directed association, an arrowhead is added to the association line to indicate the
direction of the relationship. The arrow points from the class that initiates the association to the
class that is being targeted or affected by the association.
• Directed associations are used when the association has a specific flow or directionality, such
as indicating which class is responsible for initiating the association or which class has a
dependency on another.
Consider a scenario where a “Teacher” class is associated with a “Course” class in a university
system. The directed association arrow may point from the “Teacher” class to the “Course”
class, indicating that a teacher is associated with or teaches a specific course.
• The source class is the “Teacher” class. The “Teacher” class initiates the association by
teaching a specific course.
• The target class is the “Course” class. The “Course” class is affected by the association as it is
being taught by a specific teacher.

3. Aggregation
Aggregation is a specialized form of association that represents a “whole-part” relationship. It
denotes a stronger relationship where one class (the whole) contains or is composed of another
class (the part). Aggregation is represented by a diamond shape on the side of the whole class.
In this kind of relationship, the child class can exist independently of its parent class.
Let’s understand aggregation using an example:
The company can be considered as the whole, while the employees are the parts. Employees
belong to the company, and the company can have multiple employees. However, if the
company ceases to exist, the employees can still exist independently.

4. Composition
Composition is a stronger form of aggregation, indicating a more significant ownership or
dependency relationship. In composition, the part class cannot exist independently of the whole
class. Composition is represented by a filled diamond shape on the side of the whole class.
Let’s understand Composition using an example:
 Imagine a digital contact book application. The contact book is the whole, and each contact
entry is a part. Each contact entry is fully owned and managed by the contact book. If the
contact book is deleted or destroyed, all associated contact entries are also removed.
This illustrates composition because the existence of the contact entries depends entirely on the
presence of the contact book. Without the contact book, the individual contact entries lose their
meaning and cannot exist on their own.

5. Generalization(Inheritance)
Inheritance represents an “is-a” relationship between classes, where one class (the subclass or
child) inherits the properties and behaviors of another class (the superclass or parent).
Inheritance is depicted by a solid line with a closed, hollow arrowhead pointing from the
subclass to the superclass.
In the example of bank accounts, we can use generalization to represent different types of
accounts such as current accounts, savings accounts, and credit accounts.
The Bank Account class serves as the generalized representation of all types of bank accounts,
while the subclasses (Current Account, Savings Account, Credit Account) represent specialized
versions that inherit and extend the functionality of the base class.

6. Realization (Interface Implementation)

Realization indicates that a class implements the features of an interface. It is often used in
cases where a class realizes the operations defined by an interface. Realization is depicted by a
dashed line with an open arrowhead pointing from the implementing class to the interface.
Let’s consider the scenario where a “Person” and a “Corporation” both realizing an “Owner”
interface.
• Owner Interface: This interface now includes methods such as “acquire(property)” and
“dispose(property)” to represent actions related to acquiring and disposing of property.
• Person Class (Realization): The Person class implements the Owner interface, providing
concrete implementations for the “acquire(property)” and “dispose(property)” methods. For
instance, a person can acquire ownership of a house or dispose of a car.
• Corporation Class (Realization): Similarly, the Corporation class also implements the
Owner interface, offering specific implementations for the “acquire(property)” and
“dispose(property)” methods. For example, a corporation can acquire ownership of real estate
properties or dispose of company vehicles.
Both the Person and Corporation classes realize the Owner interface, meaning they provide
concrete implementations for the “acquire(property)” and “dispose(property)” methods defined
in the interface.

7. Dependency Relationship
A dependency exists between two classes when one class relies on another, but the relationship
is not as strong as association or inheritance. It represents a more loosely coupled connection
between classes. Dependencies are often depicted as a dashed arrow.
Let’s consider a scenario where a Person depends on a Book.
• Person Class: Represents an individual who reads a book. The Person class depends on the
Book class to access and read the content.
• Book Class: Represents a book that contains content to be read by a person. The Book class
is independent and can exist without the Person class.
The Person class depends on the Book class because it requires access to a book to read its
content. However, the Book class does not depend on the Person class; it can exist
independently and does not rely on the Person class for its functionality.
 8. Usage(Dependency) Relationship
A usage dependency relationship in a UML class diagram indicates that one class (the client)
utilizes or depends on another class (the supplier) to perform certain tasks or access certain
functionality. The client class relies on the services provided by the supplier class but does not
own or create instances of it.
• Usage dependencies represent a form of dependency where one class depends on another
class to fulfill a specific need or requirement.
• The client class requires access to specific features or services provided by the supplier class.
• In UML class diagrams, usage dependencies are typically represented by a dashed arrowed
line pointing from the client class to the supplier class.
• The arrow indicates the direction of the dependency, showing that the client class depends on
the services provided by the supplier class.
Consider a scenario where a “Car” class depends on a “FuelTank” class to manage fuel
consumption.
• The “Car” class may need to access methods or attributes of the “FuelTank” class to check the
fuel level, refill fuel, or monitor fuel consumption.
• In this case, the “Car” class has a usage dependency on the “FuelTank” class because it
utilizes its services to perform certain tasks related to fuel management.

Purpose of Class Diagrams

The main purpose of using class diagrams is:
• This is the only UML that can appropriately depict various aspects of the OOPs concept.
• Proper design and analysis of applications can be faster and efficient.
• It is the base for deployment and component diagram.
• It incorporates forward and reverse engineering.
Benefits of Class Diagrams
• Modeling Class Structure:
• Class diagrams help in modeling the structure of a system by representing classes and their
attributes, methods, and relationships.
• This provides a clear and organized view of the system’s architecture.
• Understanding Relationships:
• Class diagrams depict relationships between classes, such as associations, aggregations,
compositions, inheritance, and dependencies.
This helps stakeholders, including developers, designers, and business analysts, understand
how different components of the system are connected.
• Communication:
Class diagrams serve as a communication tool among team members and stakeholders. They
provide a visual and standardized representation that can be easily understood by both technical
and non-technical audiences.
• Blueprint for Implementation:
• Class diagrams serve as a blueprint for software implementation. They guide developers in
writing code by illustrating the classes, their attributes, methods, and the relationships between
them.
• This can help ensure consistency between the design and the actual implementation.
• Code Generation:
• Some software development tools and frameworks support code generation from class
diagrams.
• Developers can generate a significant portion of the code from the visual representation,
reducing the chances of manual errors and saving development time.
• Identifying Abstractions and Encapsulation:
• Class diagrams encourage the identification of abstractions and the encapsulation of data and
behavior within classes.
• This supports the principles of object-oriented design, such as modularity and information
hiding.
How to draw Class Diagrams
Drawing class diagrams involves visualizing the structure of a system, including classes, their
attributes, methods, and relationships. Here are the steps to draw class diagrams:
1. Identify Classes:
Start by identifying the classes in your system. A class represents a blueprint for objects and
should encapsulate related attributes and methods.
2. List Attributes and Methods:
For each class, list its attributes (properties, fields) and methods (functions, operations). Include
information such as data types and visibility (public, private, protected).
3. Identify Relationships:
Determine the relationships between classes. Common relationships include associations,
aggregations, compositions, inheritance, and dependencies. Understand the nature and
multiplicity of these relationships.
4. Create Class Boxes:
Draw a rectangle (class box) for each class identified. Place the class name in the top
compartment of the box. Divide the box into compartments for attributes and methods.
5. Add Attributes and Methods:
Inside each class box, list the attributes and methods in their respective compartments. Use
visibility notations (+ for public, – for private, # for protected, ~ for package/default).
6. Draw Relationships:
Draw lines to represent relationships between classes. Use arrows to indicate the direction of
associations or dependencies. Different line types or notations may be used for various
relationships.
7. Label Relationships:
Label the relationships with multiplicity and role names if needed. Multiplicity indicates the
number of instances involved in the relationship, and role names clarify the role of each class
in the relationship.
8. Review and Refine:
Review your class diagram to ensure it accurately represents the system’s structure and
relationships. Refine the diagram as needed based on feedback and requirements.
9. Use Tools for Digital Drawing:
While you can draw class diagrams on paper, using digital tools can provide more flexibility
and ease of modification. UML modeling tools, drawing software, or even specialized
diagramming tools can be helpful.
Use cases of Class Diagrams
• System Design:
•During the system design phase, class diagrams are used to model the static structure
of a software system. They help in visualizing and organizing classes, their attributes,
methods, and relationships, providing a blueprint for system implementation.
• Communication and Collaboration:
•Class diagrams serve as a visual communication tool between stakeholders, including
developers, designers, project managers, and clients. They facilitate discussions about
the system’s structure and design, promoting a shared understanding among team
members.
• Code Generation:
 •Some software development environments and tools support code generation based on
class diagrams. Developers can generate code skeletons, reducing manual coding
efforts and ensuring consistency between the design and implementation.
• Testing and Test Planning:
•Testers use class diagrams to understand the relationships between classes and plan test
cases accordingly. The visual representation of class structures helps in identifying
areas that require thorough testing.
• Reverse Engineering:
•Class diagrams can be used for reverse engineering, where developers analyze existing
code to create visual representations of the software structure. This is especially
helpful when documentation is scarce or outdated.

Interaction Diagrams

From the term Interaction, it is clear that the diagram is used to describe some type of
interactions among the different elements in the model. This interaction is a part of dynamic
behavior of the system.

This interactive behavior is represented in UML by two diagrams known as Sequence

diagram and Collaboration diagram. The basic purpose of both the diagrams are similar.

Sequence diagram emphasizes on time sequence of messages and collaboration diagram

emphasizes on the structural organization of the objects that send and receive messages.

Purpose of Interaction Diagrams

The purpose of interaction diagrams is to visualize the interactive behavior of the system.
Visualizing the interaction is a difficult task. Hence, the solution is to use different types of
models to capture the different aspects of the interaction.

Sequence and collaboration diagrams are used to capture the dynamic nature but from a
different angle.

The purpose of interaction diagram is −

• To capture the dynamic behaviour of a system.

• To describe the message flow in the system.
• To describe the structural organization of the objects.
• To describe the interaction among objects.

How to Draw an Interaction Diagram?

As we have already discussed, the purpose of interaction diagrams is to capture the dynamic
aspect of a system. So to capture the dynamic aspect, we need to understand what a dynamic
aspect is and how it is visualized. Dynamic aspect can be defined as the snapshot of the
running system at a particular moment

We have two types of interaction diagrams in UML. One is the sequence diagram and the
other is the collaboration diagram. The sequence diagram captures the time sequence of the
message flow from one object to another and the collaboration diagram describes the
organization of objects in a system taking part in the message flow.

Following things are to be identified clearly before drawing the interaction diagram

• Objects taking part in the interaction.

• Message flows among the objects.
• The sequence in which the messages are flowing.
• Object organization.

Following are two interaction diagrams modeling the order management system. The first
diagram is a sequence diagram and the second is a collaboration diagram

The Sequence Diagram

The sequence diagram has four objects (Customer, Order, SpecialOrder and NormalOrder).

The following diagram shows the message sequence for SpecialOrder object and the same
can be used in case of NormalOrder object. It is important to understand the time sequence
of message flows. The message flow is nothing but a method call of an object.

The first call is sendOrder () which is a method of Order object. The next call is confirm
() which is a method of SpecialOrder object and the last call is Dispatch () which is a
method of SpecialOrder object. The following diagram mainly describes the method calls
from one object to another, and this is also the actual scenario when the system is running.

The Collaboration Diagram

The second interaction diagram is the collaboration diagram. It shows the object
organization as seen in the following diagram. In the collaboration diagram, the method call
sequence is indicated by some numbering technique. The number indicates how the
methods are called one after another. We have taken the same order management system to
describe the collaboration diagram.

Method calls are similar to that of a sequence diagram. However, difference being the
sequence diagram does not describe the object organization, whereas the collaboration
diagram shows the object organization.

To choose between these two diagrams, emphasis is placed on the type of requirement. If
the time sequence is important, then the sequence diagram is used. If organization is
required, then collaboration diagram is used.

Where to Use Interaction Diagrams?

We have already discussed that interaction diagrams are used to describe the dynamic nature
of a system. Now, we will look into the practical scenarios where these diagrams are used.
To understand the practical application, we need to understand the basic nature of sequence
and collaboration diagram.

The main purpose of both the diagrams are similar as they are used to capture the dynamic
behavior of a system. However, the specific purpose is more important to clarify and
understand.

Sequence diagrams are used to capture the order of messages flowing from one object to
another. Collaboration diagrams are used to describe the structural organization of the
objects taking part in the interaction. A single diagram is not sufficient to describe the
dynamic aspect of an entire system, so a set of diagrams are used to capture it as a whole.

Interaction diagrams are used when we want to understand the message flow and the
structural organization. Message flow means the sequence of control flow from one object
to another. Structural organization means the visual organization of the elements in a
system.

Activity Diagrams
 Activity Diagrams are used to illustrate the flow of control in a system and refer to the steps
involved in the execution of a use case. It is a type of behavioral diagram and we can depict
both sequential processing and concurrent processing of activities using an activity diagram ie
an activity diagram focuses on the condition of flow and the sequence in which it happens.

• An activity diagram portrays the control flow from a start point to a finish point showing the
various decision paths that exist while the activity is being executed.
• They are used in business and process modeling where their primary use is to depict the
dynamic aspects of a system.
Activity Diagram Notations

In activity diagrams, the notations are like visual symbols that help represent different elements
and actions in a simple way.
2.1. Initial State
The starting state before an activity takes place is depicted using the initial state.

A process can have only one initial state unless we are depicting nested activities. We use a
black filled circle to depict the initial state of a system. For objects, this is the state when they
are instantiated. The Initial State from the UML Activity Diagram marks the entry point and
the initial Activity State.
For example:
Here the initial state of the system before the application is opened.
Action or Activity State
An activity represents execution of an action on objects or by objects. We represent an activity
using a rectangle with rounded corners. Basically any action or event that takes place is
represented using an activity.

For example: Consider the previous example of opening an application, opening the
application is an activity state in the activity diagram.

Action Flow or Control flows

Action flows or Control flows are also referred to as paths and edges. They are used to show
the transition from one activity state to another activity state.
An activity state can have multiple incoming and outgoing action flows. We use a line with an
arrow head to depict a Control Flow. If there is a constraint to be adhered to while making the
transition it is mentioned on the arrow.
For example:
Here both the states transit into one final state using action flow symbols i.e. arrows.

Decision node and Branching

When we need to make a decision before deciding the flow of control, we use the decision
node. The outgoing arrows from the decision node can be labelled with conditions or guard
expressions. It always includes two or more output arrows.

For example:
We apply the conditions on input number to display the result :
• If number is odd then display the number.
• If number if even then display the error.
 Guard
A Guard refers to a statement written next to a decision node on an arrow sometimes within
square brackets.

The statement must be true for the control to shift along a particular direction. Guards help us
know the constraints and conditions which determine the flow of a process.
Fork
Fork nodes are used to support concurrent activities. When we use a fork node when both the
activities get executed concurrently i.e. no decision is made before splitting the activity into
two parts. Both parts need to be executed in case of a fork statement. We use a rounded solid
rectangular bar to represent a Fork notation with incoming arrow from the parent activity state
and outgoing arrows towards the newly created activities.

For example:
In the example below, the activity of making coffee can be split into two concurrent activities
and hence we use the fork notation.
 Join
Join nodes are used to support concurrent activities converging into one. For join notations we
have two or more incoming edges and one outgoing edge.

For example:
When both activities i.e. steaming the milk and adding coffee get completed, we converge them
into one final activity.

Merge or Merge Event

Scenarios arise when activities which are not being executed concurrently have to be merged.
We use the merge notation for such scenarios. We can merge two or more activities into one if
the control proceeds onto the next activity irrespective of the path chosen.
For example:
In the diagram below: we can’t have both sides executing concurrently, but they finally merge
into one. A number can’t be both odd and even at the same time.

Swimlanes
We use Swimlanes for grouping related activities in one column. Swimlanes group related
activities into one column or one row. Swimlanes can be vertical and horizontal. Swimlanes
are used to add modularity to the activity diagram. It is not mandatory to use swimlanes. They
usually give more clarity to the activity diagram. It’s similar to creating a function in a program.
It’s not mandatory to do so, but, it is a recommended practice.

We use a rectangular column to represent a swimlane as shown in the figure above.

For example:
Here different set of activities are executed based on if the number is odd or even. These
activities are grouped into a swimlane.
Time Event
This refers to an event that stops the flow for a time; an hourglass depicts it. We can have a
scenario where an event takes some time to completed.

For example:
Let us assume that the processing of an image takes a lot of time. Then it can be represented as
shown below.

Final State or End State

The state which the system reaches when a particular process or activity ends is known as a
Final State or End State. We use a filled circle within a circle notation to represent the final
state in a state machine diagram. A system or a process can have multiple final states.
How to Draw an Activity Diagram in UML?

Below are the steps of how to draw the Activity Diagram in UML:
Step 1. Identify the Initial State and Final States:
• This is like setting the starting point and ending point of a journey.
• Identify where your process begins (initial state) and where it concludes (final states).
• For example, if you are modelling a process for making a cup of tea, the initial state
could be “No tea prepared,” and the final state could be “Tea ready.”
Step 2. Identify the Intermediate Activities Needed:
• Think of the steps or actions required to go from the starting point to the ending point.
• These are the activities or tasks that need to be performed.
• Continuing with the tea-making , intermediate activities could include “Boil water,”
“Pour tea into a cup”.
Step 3. Identify the Conditions or Constraints:
• Consider the conditions or circumstances that might influence the flow of your process.
• These are the factors that determine when you move from one activity to another.
• Using the tea-making scenario, a condition could be “Water is boiled,” which triggers
the transition to the next activity.
Step 4. Draw the Diagram with Appropriate Notations:
• Now, represent the identified states, activities, and conditions visually using the
appropriate symbols and notations in an activity diagram. This diagram serves as a visual
map of your process, showing the flow from one state to another.

What are Activity Diagrams used for?

Activity diagrams are used in software development and system design to model and visualize
the dynamic aspects of a system. Here are some common uses of activity diagrams:
• Dynamic modelling of the system or a process.
• Illustrate the various steps involved in a UML use case.
• Model software elements like methods,operations and functions.
• We can use Activity diagrams to depict concurrent activities easily.
• Show the constraints, conditions and logic behind algorithms.
• During the requirements analysis phase, activity diagrams assist in capturing and
documenting the dynamic aspects of user interactions.

Functional modelling

In the Functional Model, software converts information. and to accomplish this, it must
perform at least three common tasks- input, processing and output. When functional models
of an application are created, the software engineer emphasizes problem specific tasks. The
functional model begins with a single reference level model (i.e., be manufactured). In a
series of iterations, more and more functional detail is given, until all system functionality is
fully represented.

Information is converted because it flows from a computer-based system. The system takes
input in various forms; Hardware, software, and human elements are applied to replace it;
And produces in various forms. The transformation (s) or function may be composed of a
single logical comparison, a complex numerical method, or a rule- the invention approach of
an expert system. The output can light an LED or provide a 200 page report. Instead, we can
create a model or flow model for any computer- based system, regardless of size and
complexity.
 Structural analysis started as an Information Flow Modelling technique. A computer-based
system can be modeled as an information transform function as shown in figure.

A rectangle represents an external unit. That is, a system element, such as a hardware, a
person or another system that provides information for transformation by the software or
receives information provided by the software. A circle is used to represent a process or
transform or a function that is applied to data and changes it in some way. An arrow is used to
represent one or more data items.

All arrows should be labeled in a DFD. The double line is used to represent data store. There
may be implicit procedure or sequence in the diagram but explicit logical details are generally
delayed until software design.

Data Flow Diagram

DFD is the abbreviation for Data Flow Diagram. The flow of data of a system or a process is
represented by DFD. It also gives insight into the inputs and outputs of each entity and the
process itself. DFD does not have control flow and no loops or decision rules are present.
Specific operations depending on the type of data can be explained by a flowchart. It is a
graphical tool, useful for communicating with users ,managers and other personnel. it is useful
for analyzing existing as well as proposed system.
It should be pointed out that a DFD is not a flowchart. In drawing the DFD, the designer has to
specify the major transforms in the path of the data flowing from the input to the output. DFDs
can be hierarchically organized, which helps in progressively partitioning and analyzing large
systems.
It provides an overview of
• What data is system processes.
• What transformation are performed.
• What data are stored.
• What results are produced , etc.
Data Flow Diagram can be represented in several ways. The DFD belongs to structured-
analysis modeling tools. Data Flow diagrams are very popular because they help us to visualize
the major steps and data involved in software-system processes.

Characteristics of DFD
• DFDs are commonly used during problem analysis.
• DFDs are quite general and are not limited to problem analysis for software requirements
specification.
• DFDs are very useful in understanding a system and can be effectively used during analysis.
• It views a system as a function that transforms the inputs into desired outputs.
• The DFD aims to capture the transformations that take place within a system to the input data
so that eventually the output data is produced.
• The processes are shown by named circles and data flows are represented by named arrows
entering or leaving the bubbles.
• A rectangle represents a source or sink and it is a net originator or consumer of data. A source
sink is typically outside the main system of study.
Components of DFD
The Data Flow Diagram has 4 components:
• Process Input to output transformation in a system takes place because of process function.
The symbols of a process are rectangular with rounded corners, oval, rectangle or a circle. The
process is named a short sentence, in one word or a phrase to express its essence
• Data Flow Data flow describes the information transferring between different parts of the
systems. The arrow symbol is the symbol of data flow. A relatable name should be given to the
flow to determine the information which is being moved. Data flow also represents material
along with information that is being moved. Material shifts are modeled in systems that are not
merely informative. A given flow should only transfer a single type of information. The
direction of flow is represented by the arrow which can also be bi-directional.
• Warehouse The data is stored in the warehouse for later use. Two horizontal lines represent
the symbol of the store. The warehouse is simply not restricted to being a data file rather it can
be anything like a folder with documents, an optical disc, a filing cabinet. The data warehouse
can be viewed independent of its implementation. When the data flow from the warehouse it is
considered as data reading and when data flows to the warehouse it is called data entry or data
updating.
• Terminator The Terminator is an external entity that stands outside of the system and
communicates with the system. It can be, for example, organizations like banks, groups of
people like customers or different departments of the same organization, which is not a part of
the model system and is an external entity. Modeled systems also communicate with terminator.

Rules for creating DFD

• The name of the entity should be easy and understandable without any extra assistance(like
comments).
• The processes should be numbered or put in ordered list to be referred easily.
• The DFD should maintain consistency across all the DFD levels.
• A single DFD can have a maximum of nine processes and a minimum of three processes.
Symbols Used in DFD
• Square Box: A square box defines source or destination of the system. It is also called entity.
It is represented by rectangle.
• Arrow or Line: An arrow identifies the data flow i.e. it gives information to the data that is
in motion.
• Circle or bubble chart: It represents as a process that gives us information. It is also called
processing box.
• Open Rectangle: An open rectangle is a data store. In this data is store either temporary or
permanently.
 Levels of DFD
DFD uses hierarchy to maintain transparency thus multilevel DFD’s can be created. Levels of
DFD are as follows:
• 0-level DFD: It represents the entire system as a single bubble and provides an overall picture
of the system.
• 1-level DFD: It represents the main functions of the system and how they interact with each
other.
• 2-level DFD: It represents the processes within each function of the system and how they
interact with each other.
• 3-level DFD: It represents the data flow within each process and how the data is transformed
and stored.
Advantages of DFD
• It helps us to understand the functioning and the limits of a system.
• It is a graphical representation which is very easy to understand as it helps visualize contents.
• Data Flow Diagram represent detailed and well explained diagram of system components.
• It is used as the part of system documentation file.
• Data Flow Diagrams can be understood by both technical or nontechnical person because
they are very easy to understand.
Disadvantages of DFD
• At times DFD can confuse the programmers regarding the system.
• Data Flow Diagram takes long time to be generated, and many times due to this reasons
analysts are denied permission to work on it.

Computer Aided Software Engineering (CASE)

Computer-aided software engineering (CASE) is the implementation of computer-
facilitated tools and methods in software development. CASE is used to ensure high-quality
and defect-free software. CASE ensures a check-pointed and disciplined approach and helps
designers, developers, testers, managers, and others to see the project milestones during
development.
CASE can also help as a warehouse for documents related to projects, like business plans,
requirements, and design specifications. One of the major advantages of using CASE is the
delivery of the final product, which is more likely to meet real-world requirements as it ensures
that customers remain part of the process.
CASE illustrates a wide set of labor-saving tools that are used in software development. It
generates a framework for organizing projects and to be helpful in enhancing productivity.
There was more interest in the concept of CASE tools years ago, but less so today, as the tools
have morphed into different functions, often in reaction to software developer needs. The
concept of CASE also received a heavy dose of criticism after its release.

What is CASE Tools?

The essential idea of CASE tools is that in-built programs can help to analyze developing
systems in order to enhance quality and provide better outcomes. Throughout the 1990, CASE
tool became part of the software lexicon, and big companies like IBM were using these kinds
of tools to help create software.
Various tools are incorporated in CASE and are called CASE tools, which are used to support
different stages and milestones in a software development life cycle.

Types of CASE Tools:

1. Diagramming Tools: It helps in diagrammatic and graphical representations of the data and
system processes. It represents system elements, control flow and data flow among different
software components and system structures in a pictorial form. For example, Flow Chart Maker
tool for making state-of-the-art flowcharts.
2. Computer Display and Report Generators: These help in understanding the data
requirements and the relationships involved.
3. Analysis Tools: It focuses on inconsistent, incorrect specifications involved in the diagram
and data flow. It helps in collecting requirements, automatically check for any irregularity,
imprecision in the diagrams, data redundancies, or erroneous omissions.
For example:
•(i) Accept 360, Accompa, CaseComplete for requirement analysis.
•(ii) Visible Analyst for total analysis.

4. Central Repository: It provides a single point of storage for data diagrams, reports, and
documents related to project management.
5. Documentation Generators: It helps in generating user and technical documentation as per
standards. It creates documents for technical users and end users.
For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.
6. Code Generators: It aids in the auto-generation of code, including definitions, with the help
of designs, documents, and diagrams.
7. Tools for Requirement Management: It makes gathering, evaluating, and managing
software needs easier.
8. Tools for Analysis and Design: It offers instruments for modelling system architecture and
behaviour, which helps throughout the analysis and design stages of software development.
9. Tools for Database Management: It facilitates database construction, design, and
administration.
10. Tools for Documentation: It makes the process of creating, organizing, and maintaining
project documentation easier.
Advantages of the CASE approach:
• Improved Documentation: Comprehensive documentation creation and maintenance is
made easier by CASE tools. Since automatically generated documentation is usually more
accurate and up to date, there are fewer opportunities for errors and misunderstandings brought
on by out-of-current material.
• Reusing Components: Reusable component creation and maintenance are frequently
facilitated by CASE tools. This encourages a development approach that is modular and
component-based, enabling teams to shorten development times and reuse tested solutions.
• Quicker Cycles of Development: Development cycles take less time when certain jobs, such
testing and code generation, are automated. This may result in software solutions being
delivered more quickly, meeting deadlines and keeping up with changing business
requirements.
• Improved Results: Code generation, documentation, and testing are just a few of the time-
consuming, repetitive operations that CASE tools perform. Due to this automation, engineers
are able to concentrate on more intricate and imaginative facets of software development, which
boosts output.
• Achieving uniformity and standardization: Coding conventions, documentation
formats and design patterns are just a few of the areas of software development where CASE
tools enforce uniformity and standards. This guarantees consistent and maintainable software
development.
Disadvantages of the CASE approach:
• Cost: Using a case tool is very costly. Most firms engaged in software development on a
small scale do not invest in CASE tools because they think that the benefit of CASE is
justifiable only in the development of large systems.
• Learning Curve: In most cases, programmers’ productivity may fall in the initial phase of
implementation, because users need time to learn the technology. Many consultants offer
training and on-site services that can be important to accelerate the learning curve and to the
development and use of the CASE tools.
• Tool Mix: It is important to build an appropriate selection tool mix to urge cost advantage
CASE integration and data integration across all platforms is extremely important.

Finaly software development world, computer-aided software engineering is a vital tool that
enables teams to produce high-quality software quickly and cooperatively. CASE tools will
probably become more and more essential as technology develops in order to satisfy the
demands of complicated software development projects.