Anjalai Ammal-Mahalingam Engineering College

Kovilvenni-614 403
(NAAC Accredited with B Grade)
Department of Computer Science and Engineering

UNIT-II REQUIREMENTS ANALYSIS AND SPECIFICATION

Requirement analysis and specification – Requirements gathering and analysis –

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

REQUIREMENTS ANALYSIS AND SPECIFICATION

 All plan-driven life cycle models prescribe that before starting to develop 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
understandthe 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
experienced members 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 the
requirements 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 single
document 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 form a large number of
stakeholders and from information scattered across several pieces of documents.
● Gathering requirements turns out to be especially challenging if there is no
workingmodel 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 to be
developed before visiting the customer site.
 Customers usually provide a statement of purpose (SoP) document to the
developers.
Interview:
 Typically, there are many different categories of users of software.
 Each category of users typically requires a different set of features from the
software.
 Therefore, it is important for the analyst to first identify the different categories of
users and then determine the requirements of each.
Task analysis:
 The users usually have a black-box view of software and consider the software as
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 performed
by the software.
 For each identified task, the analyst tries to formulate the different steps
necessary 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 under
different situations.
 For different types of scenarios of a task, the behavior 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 produced
are 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
rises above 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 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
andisthetoughest 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-
standthefunctionalities supported by the system.

Characteristics of a Good SRS Document:

 IEEE Recommended Practice for Software Requirements Specifications describes the
content 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 arequirement
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 requirements changes, 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 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 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 fuse 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
in one 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 the system, 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.

Non-functional Requirements:
 The non-functional requirements are non-negotiable obligations that must be
supportedby the software.
 The non-functional requirements capture those requirements of the customer that
cannotbe 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 optio ns 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 communication
interfaces, user interfaces, report formats, etc.
 To specify the user interfaces, each interface between the software and the users
must be described.
 One example of a user interface requirement of software can be that it should be
usable by factory shop floor workers who may not even have a high school degree.
 The details of the user interface design such as screen designs, menu structure,
navigation diagram, etc.
 It should be documented in a separate user interface specification document.
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 of
transactions 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
bythe customer for conformance at the time of acceptance testing.
 The goals of the implementation section might document issues such as easier
revisions to the system functionalities that may be required in the future, easier
support for new devices to 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 howthe
software would be used.
Project scope:
 This section should briefly describe the overall context within which thesoftware
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 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:
 These might include—corporate or regulatory policies; hardware limitations
(timing requirements, memory requirements);
 Interfaces to other applications; specific technologies, tools, and databases to
be used;
 Specific programming language to be used;
 Specific communication protocols to be used;
 Security considerations; design conventions or programming standards.
User documentation:
 This section should list out the types of user documentation, such as user
manuals, on-line help, and trouble-shooting manuals that will be delivered to
the customer along with the software.
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 and the
hardware components of the system.

IEEE format for SRS Document

 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 or damage 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.

FORMAL SYSTEM SPECIFICATION

 Formal techniques have emerged as a central issue in software engineering. This is not
accidental; the importance of precise specification, modelling, and verification is
recognised to be important in most engineering disciplines.
 Formal methods provide us with tools to precisely describe a system and show that a
system is correctly implemented.
 We say a system is correctly implemented when it satisfies its given specification. The
specification of a system can be given either as a list of its desirable properties
(property-oriented approach) or as an abstract model of the system (model-
orientedapproach).

What is a Formal Technique?

 A formal technique is a mathematical method to specify a hardware and/or software
system, verify whether a specification is realisable, verify that an implementation
satisfies its specification, prove properties of a system without necessarily running
the system, etc.
 The mathematical basis of a formal method is provided by its specification language.
More precisely, a formal specification language consists of two sets—syn and sem,
and a relation sat between them.
 The set syn is called the syntactic domain, the set sem is called the semantic domain,
and the relation sat is called the satisfaction relation.
 For a given specification syn, and model of the system sem, if sat (syn, sem), then syn
is said to be the specification of sem, and sem is said to be the specific and of syn.
Syntactic domains

 The syntactic domain of a formal specification language consists of an alphabet of

symbols and a set of formation rules to construct well-formed formulas from the
alphabet.
 The well-formed formulas are used to specify a system.
Semantic domains
 Formal techniques can have considerably different semantic domains.
 Abstract data type specification languages are used to specify algebras, theories,
and programs.
 Programming languages are used to specify functions from input to output values.
 Concurrent and distributed system specification languages are used to specify state
sequences, event sequences, state-transition sequences, synchronisation trees,
partial orders, state machines, etc
Satisfaction relation
 Given the model of a system, it is important to determine whether an element of
the semantic domain satisfies the specifications.
 This satisfaction is determined by using a homomorphism known as semantic
abstraction function.
 The semantic abstraction function maps the elements of the semantic domain into
equivalent classes.
 There can be different specifications describing different aspects of a system
model, possibly using different specification languages.
 Some of these specifications describe the system’s behaviour and the others
describe the system’s structure. Consequently, two broad classes of semantic
abstraction functions are defined— those that preserve a system’s behaviour and
those that preserve a system’s structure.

Model versus property-oriented methods

 Formal methods are usually classified into two broad categories—the so called
model-oriented and the property-oriented approaches.
 In a model oriented style, one defines a system’s behaviour directly by constructing
a model of the system in terms of mathematical structures such as tuples, relations,
functions, sets, sequences, etc.
 In the property-oriented style, the system’s behaviour is defined indirectly by
stating its properties, usually in the form of a set of axioms that the system must
satisfy.
 Let us consider a simple producer/consumer example. In a property-oriented style,
we would probably start by listing the properties of the system like—the consumer
can start consuming only after the producer has produced an item, the producer
starts to produce an item only after the consumer has consumed the last item, etc.
 Two examples of property-oriented specification styles are axiomatic specification
and algebraic specification.
  In a model-oriented style, we would start by defining the basic operations, p
(produce) and c (consume). Then we can state that S1 + p ⇒ S, S + c ⇒ S1. Thus
model-oriented approaches essentially specify a program by writing another,
presumably simpler program. A few notable examples of popular model-oriented
specification techniques are Z, CSP,CCS, etc.
 It is alleged that property-oriented approaches are more suitable for requirements
specification, and that the model-oriented approaches are more suited to system
design specification.
Operational Semantics
 Informally, the operational semantics of a formal method is the way computations
are represented.
 There are different types of operational semantics according to what is meant by a
single run of the system and how the runs are grouped together to describe the
behaviour of the system.
Linear semantics:
 In this approach, a run o f a system is described by a sequence (possibly infinite) of
events or states.
 The concurrent activities of the system are represented by non-deterministic
interleavings of the atomic actions. For example, a concurrent activity a || b is
represented by the set of sequential activities a; b and b; a. This is a simple but
rather unnatural representation of concurrency.
 The behaviour of a system in this model consists of the set of all its runs. To make
this model more realistic, usually justice and fairness restrictions are imposed on
computations to exclude the unwanted interleavings.
Branching semantics:
 In this approach, the behaviour of a system is represented by a directed graph.
 The nodes of the graph represent the possible states in the evolution of a system.
 The descendants of each node of the graph represent the states which can be
generated by any of the atomic actions enabled at that state.
 Although this semantic model distinguishes thebranching points in a computation,
still it represents concurrency by interleaving.
Maximally parallel semantics:
 In this approach, all the concurrent actions enabled at any state are assumed to be
taken together.
 This is again not a natural model of concurrency since it implicitly assumes the
availability of all the required computational resources.
Partial order semantics:
 Under this view, the semantics ascribed to a system is a structure of states
satisfying a partial order relation among the states (events).
 The partial order represents a precedence ordering among events, and constrains
some events to occur only after some other events have occurred; while the
occurrence of other events (called concurrent events) is considered to be
incomparable.
 This fact identifies concurrency as a phenomenon not translatable to any
interleaved representation.
 Merits of formal methods
 Formal specifications encourage rigour. It is often the case that the very process of
construction of a rigorous specification is more important than the formal
specification itself.

 Formal methods usually have a well-founded mathematical basis. Thus, formal

specifications are not only more precise, but also mathematically sound and can be
used to reason about the propertiesof a specification and to rigorously prove that
an implementation satisfies its specifications. Informal specifications may be useful
in understanding a system and its documentation, but they cannot serve as a basis
of verification.
 The mathematical basis of the formal methods makes it possible for automating the
analysis of specifications. For example, a tableau based technique has been used to
automatically check the consistency of specifications. Also, automatic theorem
proving techniques can be used to verify that an implementation satisfies its
specifications. The possibility of automatic verification is one of the most important
advantages of formal methods.
 Formal specifications can be executed to obtain immediate feedback on the
features of the specified system.

Limitations of formal methods

 Formal methods are difficult to learn and use.
 The basic incompleteness results of first-order logic suggest that it is impossible to
check absolute correctness of systems using theorem proving techniques.
 Formal techniques are not able to handle complex problems. A large unstructured
set of mathematical formulas is difficult to comprehend.

OBJECT MODELLI NG USI NG UML

 A model is constructed by focusing only on a few aspects of the problem and
ignoring the rest. The model of a problem is called an analysis model.
 On the other hand, the model of the solution (code) is called the design model.
 The design model is usually obtained by carrying out iterative refinements to the
analysis model using a design methodology.

Modelling language:
 A modelling language consists of a set of notations using which design and analysis
models are documented.
Design process:
 A design process consists of a step by step procedure (or recipe) using which a
problem description can be converted into a design solution.
 A design process is, at times, also referred to as a design methodology.

USE CASE MODEL

 The use case model for any system consists of a set of use cases.
 The use cases represent the different ways in which a system can be used by the users.
 A use case can be viewed as a set of related scenarios tied together by a common
goal.
 The main line sequence and each of the variations are called scenarios or instances of
the use case. Each scenario is a single path of user events and system activity.
 In contrast to all other types of UML diagrams, the use case model represents a
functional or process model of a system.

Representation of Use Cases

 A use case model can be documented by drawing a use case diagram and writing an
accompanying text elaborating the drawing.
 In the usecase diagram, each use case is represented by an ellipse with the name of the
use case written inside the ellipse.
 All the ellipses (i.e. use cases) of a system are enclosed within a rectangle which
represents the system boundary.
 The different users of the system are represented by using stick person icons. Each
stick person icon is referred to as an actor.
 An actor is a role played by a user with respect to the system use. It is possible that the
same user may play the role of multiple actors.
 An actor can participate in one or more use cases. The line connecting an actor and the
use case is called the communication relationship. It indicates that an actor makes use of
the functionality provided by the use case.
 Both human users and external systems can be represented by stick person icons.
 When a stick person icon represents an external system, it is annotated by the
stereotype <<external system>>.
 The stereotype construct when used to annotate a basic symbol, can give slightly
different meaning to the basic symbol— thereby eliminating the need to have several
symbols whose meanings differ slightly from each other.

Example: The use case model for the Tic-tac-toe game software is shown in Figure
below:
This software has only one use case, namely, “play move”. Note that we did not name
the use case “get-user-move”, as “get user-move” would be inappropriate because this
would represent the developer’s perspective of the use case. The use cases should be
named from the users’ perspective.
Text description
 Each ellipse in a use case diagram, by itself conveys very little information, other than
giving a hazy idea about the use case. Therefore, every use case diagram should be
accompanied by a text description.
 The text description should define the details of the interaction between the user and
the computer as well as other relevant aspects of the use case.
Contact persons:
 This section lists of personnel of the client organization with whom the use case was
discussed, date and time of the meeting, etc.
Actors:
 In addition to identifying the actors, some information about actors using a use case
which may help the implementation of the use case may be recorded.
Pre-condition:
 The preconditions would describe the state of the system before the use case
execution starts.
Post-condition:
This captures the state of the system after the use case has successfully completed.
Non-functional requirements:
 This could contain the important constraints for the design and implementation, such
as platform and environment conditions, qualitative statements, response time
requirements, etc.
Exceptions, error situations:
 This contains only the domain-related errors such as lack of user’s access rights,
invalid entry in the input fields, etc.
 Obviously, errors that are not domain related, such as software errors, need not be
discussed here.
Sample dialogs:
 These serve as examples illustrating the use case.
Specific user interface requirements:
 These contain specific requirements for the user interface of the use case. For
example, it may contain forms to be used, screen shots, interaction style, etc.
Document references:
 This part contains references to specific domain related documents which may be
useful to understand the system operation.

FACTORING OF COMMONALITY AMONG USE CASES

 Complex use cases need to be factored into simpler use cases. This would not only
make the behaviour associated with the use case much more comprehensible, but also
make the corresponding interaction diagrams more tractable.
 Without decomposition, the interaction diagrams for complex use cases may become
too large to be accommodated on a single standard-sized (A4) paper.
 Use cases need to be factored whenever there is common behavior across different
use cases.
 Factoring would make it possible to define such behaviour only once and reuse it
wherever required.

Generalisation
 Generalisation works the same way with use cases as it does with classes.
 The child use case inherits the behaviour and meaning of the present use case.
 Figure: Representation of use case Generalisation

Includes
 The includes relationship implies one use case includes the behaviour of another use
case in its sequence of events and actions.
 The includes relationship is represented using a predefined stereotype <<include>>.
 In the includes relationship, a base use case compulsorily and automatically includes
the behaviour of the common use case.

Figure: Example of use case inclusion.

Extends
 The main idea behind the extends relationship among use cases is that it allows you
show optional system behaviour.
 An optional system behaviour is executed only if certain conditions hold, otherwise
the optional behaviour is not executed.

Figure: Example of use case extension.

Organisation
 When the use cases are factored, they are organised hierarchically.
 The high-level use cases are refined into a set of smaller and more refined use cases
 Figure: Hierarchical organisation of use cases

USE CASE PACKAGING

 Packaging is the mechanism provided by UML to handle complexity.
 When we have too many use cases in the top-level diagram, we can package the
related use cases so that at best 6 or 7 packages are present at the top level diagram.
 Any modeling element that becomes large and complex can be broken up into
packages.
 The symbol for a package is a folder. Just as you organise a large collection of
documents in a folder, you organise UML elements into packages. An example of
packaging use cases is shown in below Figure.
 Figure: Use case packaging
Classes
 The classes represent entities with common features, i.e., attributes and operations.
Classes are represented as solid outline rectangles with compartments.
 Classes have a mandatory name compartment where the name is written centered in
boldface.
 The class name is usually written using mixed case convention and begins with an
uppercase (e.g. Library Member).
 Object names on the other hand, are written using a mixed case convention, but starts
with a small case letter (e.g.,Student Member).
 Class names are usually chosen to be singular nouns. An example of various
representations of a class are shown in below figure.
 Classes have optional attributes and operations compartments. A class may appear on
several diagrams. Its attributes and operations are suppressed on all but one diagram.
But, one may wonder why there are so many representations for a class. The answer is
that these different notations are used depending on the amount of information about
a class is available.
 At the start of the design process, only the names of the classes is identified.
 This is the most abstract representation for the class. Later in the design process the
methods for the class and the attributes are identified and the other more concrete
notations are used.
 Figure: Different representations of the Library Member class
Attributes
 An attribute is a named property of a class. It represents the kind of data that an object
might contain.
 Attributes are listed with their names, and may optionally contain specification of
their type (that is, their class,e.g., Int, Book, Employee, etc.) an initial value, and
constraints.
 Attribute names are written left-justified using plain type letters, and the names
should begin with a lower case letter.
 Attribute names may be followed by square brackets containing a multiplicity
expression, e.g. sensorStatus[10].
 The multiplicity expression indicates the number of attributes per instance of the
class. An attribute without square brackets must hold exactly one value.
 The type of an attribute is written by following the attribute name with a colon and
the type name,(e.g., sensorStatus[1]:Int).
 The attribute name may be followed by an initialisation expression.
 The initialisation expression can consist of an equal sign and an initial value that is
used to initialise the attributes of the newly created objects, e.g. sensorStatus[1]:Int=0.
 An operation may have a return type consisting of a single return type expression, e.g.,
issueBook(in bookName):Boolean.
 An operation may have a class scope (i.e., shared among all the objects of the class)
and is denoted by underlining the operation name.
Association
 Association between two classes is represented by drawing a straight line between
the concerned classes.
 The name of the association is written alongside the association line. An arrowhead
may be placed on the association line to indicate the reading direction of the
association.
 The arrowhead should not be misunderstood to be indicating the direction of a
pointer implementing an association. On each side of the association relation, the
multiplicity is noted as an individual number or as a value range.
 The multiplicity indicates how many instances of one class are associated with the
other.
  Value ranges of multiplicity are noted by specifying the minimum and maximum
value, separated by two dots.

Figure: Association between two classes.

Aggregation
 Aggregation is a special type of association relation where the involved classes are
not only associated to each other, but a whole-part relationship exists between
them. That is, the aggregate object not only knows the addresses of its parts and
therefore invoke the methods of its parts, but also takes the responsibility of
creating and destroying its parts.
 An example of aggregation, a book register is an aggregation of book objects.
 Books can be added to the register and deleted as and when required.
 Aggregation is represented by an empty diamond symbol at the aggregate end of a
relationship.
 An example of the aggregation relationship has been shown in below.
 The aggregation relationship cannot be reflexive (i.e. recursive). That is, an object
cannot contain objects of the same class as itself.
 Also, the aggregation relation is not symmetric. That is, two classes A and B cannot
contain instances of each other
 However, the aggregation relationship can be transitive. In this case, aggregation
may consist of an arbitrary number of levels.

Figure: Representation of aggregation.

Composition
 Composition is a stricter form of aggregation, in which the parts are existence-
dependent on the whole.
 This means that the life of the parts cannot exist outside the whole. In other words, the
lifeline of the whole and the part are identical.
 When the whole is created, the parts are created and when the whole is destroyed, the
parts are destroyed.
 A typical example of composition is an order object where after placing the order, no
item in the order cannot be changed.
 If any changes to any of the order items are required after the order has been placed,
then the entire order has to be cancelled and a new order has to be placed with the
changed items.
  In this case, as soon as an order object is created, all the order items in it are created
and as soon as the order object is destroyed, all order items in it are also destroyed.
That is, the life of the components (order items) is the same as the aggregate (order).
 The composition relationship is represented as a filled diamond drawn at the
composite-end. An example of the composition relationship is shown in below.

Figure : Representation of composition

Inheritance
 The inheritance relationship is represented by means of an empty arrow pointing
from the subclass to the superclass.
 The arrow may be directly drawn from the subclass to the superclass.

Figure: Representation of the inheritance relationship.

Dependency
 A dependency relationship is shown as a dotted arrow that is drawn from the
dependent class to the independent class.

Figure : Representation of dependence between classes

Constraints
 A constraint describes a condition or an integrity rule. Constraints are typically used
to describe the permissible set of values of an attribute, to specify the pre- and post-
conditions for operations, to define certain ordering of items, etc.
 For example, to denote that the books in a library are sorted on ISBN number we can
annotate the book class with the constraint {sorted}.
Object diagrams
 An object diagram shows the snapshot of the objects in a system at a point in time.
Since it shows instances of classes, rather than the classes themselves, it is often called
as an instance diagram.
 The objects are drawn using rounded rectangles. An object diagram may undergo
continuous change as execution proceeds.
 For example, links may get formed between objects and get broken.
 Objects may get created and destroyed, and so on. Object diagrams are useful to
explain the working of a system.

Figure: Different representations of a LibraryMember object.

INTERACTION DIAGRAMS
 When a user invokes one of the functions supported by a system, the required
behaviour is realised through the interaction of several objects in the system.
Interaction diagrams, as their name itself implies, are models that describe how
groups of objects interact among themselves through message passing to realise some
behaviour.
 Typically, each interaction diagram realises the behaviour of a single use case.
 There are two kinds of interaction diagrams—sequence diagrams and collaboration
diagrams.
 These two diagrams are equivalent in the sense that any one diagram can be derived
automatically from the other. However, they are both useful.
 These two actually portray different perspectives of behaviour of a system and
different types of inferences can be drawn from them.
 The interaction diagrams play a major role in any effective object oriented design
process.
Sequence diagram
 A sequence diagram shows interaction among objects as a two dimensional chart. The
chart is read from top to bottom.
 The objects participating in the interaction are shown at the top of the chart as boxes
attached to a vertical dashed line.
 Inside the box the name of the object is written with a colon separating it from the
name of the class and both the name of the object and the class are underlined.
 This signifies that we are referring any arbitrary instance of the class.
 For example, in below figure: Book represents any arbitrary instance of the Book
class.
 An object appearing at the top of the sequence diagram signifies that the object existed
even before the time the use case execution was initiated.
 However, if some object is created during the execution of the use case and
participates in the interaction (e.g., a method call), then the object should be shown at
the appropriate place on the diagram where it is created.
 The vertical dashed line is called the object’s lifeline.
 Any point on the lifeline implies that the object exists at that point.
 Absence of lifeline after some point indicates that the object ceases to exist after that
point in time, particular point of time.
 Normally, at the point if an object is destroyed, the lifeline of the object is crossed at
that point and the lifeline for the object is not drawn beyond that point.
 A rectangle called the activation symbol is drawn on the lifeline of an object to indicate
the points of time at which the object is active. Thus an activation symbol indicates
that an object is active as long as the symbol (rectangle) exists on the lifeline.
 Each message is indicated as an arrow between the lifelines of two objects.
 The messages are shown in chronological order from the top to the bottom. That is,
reading the diagram from the top to the bottom would show the sequence in which the
messages occur.
 Each message is labelled with the message name. Some control information can also
be included. Two important types of control information are:
 A condition (e.g., [invalid]) indicates that a message is sent, only if the condition is
true.
 An iteration marker shows that the message is sent many times to multiple receiver
objects as would happen when you are iterating over a collection or the elements of
an array. You can also indicate the basis of the iteration, e.g., [for every book object].
 Figure: Sequence diagram for the renew book use case

Collaboration diagram
 A collaboration diagram shows both structural and behavioural aspects explicitly.
 This is unlike a sequence diagram which shows only the behavioural aspects.
 The structural aspect of a collaboration diagram consists of objects and links among
them indicating association.
 In this diagram, each object is also called a collaborator.
 The behavioural aspect is described by the set of messages exchanged among the
different collaborators.
 The link between objects is shown as a solid line and can be used to send messages
between two objects.
 The message is shown as a labelled arrow placed near the link. Messages are prefixed
with sequence numbers because they are the only way to describe the relative
sequencing of the messages in this diagram.
 Use of the collaboration diagrams in our development process would be to help us to
determine which classes are associated with which other classes.
 Figure: collaboration diagram
ACTIVITY DIAGRAM
 The activity diagram is possibly one modelling element which was not present in any
of the predecessors of UML.
 The activity diagram focuses on representing various activities or chunks of
processing and their sequence of activation.
 The activities in general may not correspond to the methods of classes. An activity is a
state with an internal action and one or more outgoing transitions which
automatically follow the termination of the internal activity.
 If an activity has more than one outgoing transitions, then exact situation under which
each is executed must be identified through appropriate conditions.
 Activity diagrams are similar to the procedural flow charts.
 The main difference is that activity diagrams support description of parallel activities
and synchronisation aspects involved in different activities.
 Parallel activities are represented on an activity diagram by using swim lanes. Swim
lanes enable you to group activities based on who is performing them, e.g., academic
department vs. hostel office.
 Thus swim lanes sub divide activities based on the responsibilities of some
components.
 The activities in swim lanes can be assigned to some model elements, e.g. classes or
some component, etc.
 For example, In below Figure, the swim lane corresponding to the academic section,
the activities that are carried out by the academic section and the specific situation in
which these are carried out are shown below.
 Figure: Activity diagram
STATE CHART DIAGRAM
 A state chart diagram is normally used to model how the state of an object changes in
its life time.
 State chart diagrams are good at describing how the behaviour of an object changes
across several use case executions.
 However, if we are interested in modelling some behaviour that involves several
objects collaborating with each other, state chart diagram is not appropriate.
 We have already seen that such behaviour is better modelled using sequence or
collaboration diagrams.
 State chart diagrams are based on the finite state machine (FSM) formalism. An FSM
consists of a finite number of states corresponding to those of the object being
modelled.
 The object undergoes state changes when specific events occur.
 The FSM formalism existed long before the object-oriented technology and has been
used for a wide variety of applications.
 Apart from modelling, it has even been used in theoretical computer science as a
generator for regular languages.
Why state chart?
 A major disadvantage of the FSM formalism is the state explosion problem.
 The number of states becomes too many and the model too complex when used to
model practical systems. This problem is overcome in UML by using state charts.
Basic elements of a state chart
 The basic elements of the state chart diagram are as follows:
Initial state: This represented as a filled circle.
Final state: This is represented by a filled circle inside a larger circle.
State: These are represented by rectangles with rounded corners.
Transition: A transition is shown as an arrow between two states.

Figure: State chart diagram for an order object

DATA FLOW DIAGRAM

 A DFD is a hierarchical graphical model of a system that shows the different

processing activities or functions that the system performs and the data interchange
among those functions.
 The DFD (also known as the bubble chart) is a simple graphical formalism that can be
used to represent a system in terms of the input data to the system, various processing
carried out on those data, and the output data generated by the system.
 T he main reason why the DFD technique is so popular is probably because of the fact
that DFD is a very simple formalism— it is simple to understand and use.
 A DFD model uses a very limited number of primitive symbols to represent the
functions performed by a system and the data flow among these functions.
Primitive symbols used for constructing DFDs
There are essentially five different types of symbols used for constructing DFDs. These
primitive symbols are depicted below

Figure: Symbols used for designing DFDs.

Function symbol:
 A function is represented using a circle.
 This symbol is called a process or a bubble. Bubbles are annotated with the names of
the corresponding functions
External entity symbol:
 An external entity such as a librarian, a library member, etc. is represented by a
rectangle.
 The external entities are essentially those physical entities external to the software
system which interact with the system by inputting data to the system or by
consuming the data produced by the system.
 In addition to the human users, the external entity symbols can be used to represent
external hardware and software such as application software that would interact with
the software being modelled.
Data flow symbol:
 A directed arc (or an arrow) is used as a data flow symbol.
 A data flow symbol represents the data flow occurring between two processes or
between an external entity and a process in the direction of the data flow arrow.
 Data flow symbols are usually annotated with the corresponding data names.
For example the DFD in Figure(a) shows three data flows—the data item number
flowing from the process read-number to validate-number, data item flowing into
read-number, and valid-number flowing out of validate-number.
Data store symbol:
 A data store is represented using two parallel lines. It represents a logical file. That is,
a data store symbol can represent either a data structure or a physical file on disk.
 Each data store is connected to a process by means of a data flow symbol.
 The direction of the data flow arrow shows whether data is being read from or written
into a data store.
 An arrow flowing in or out of a data store implicitly represents the entire data of the
data store and hence arrows connecting t o a data store need not be annotated with
the name of the corresponding data items.
 As an example of a data store, number is a data store in Figure b.
Output symbol:
 The output symbol is used when a hard copy is produced.
Synchronous and asynchronous operations
 If two bubbles are directly connected by a data flow arrow, then they are synchronous.
This means that they operate at t h e same speed. An example of such an arrangement
is shown in Figure (a).
 Here, the validate-number bubble can start processing only after the read-number
bubble has supplied data to it; and the read-number bubble has to wait until the
validate-number bubble has consumed its data.
 However, if two bubbles are connected through a data store, as in Figure(b) then the
speed of operation of the bubbles are independent.
 This statement can be explained using the following reasoning.
The data produced by a producer bubble gets stored in the data store.
It is therefore possible that the producer bubble stores several pieces of data items,
even before the consumer bubble consumes any of them.

Figure: Synchronous and asynchronous data flow

Data dictionary
 Every DFD model of a system must be accompanied by a data dictionary. A data
dictionary lists all data items that appear in a DFD model.
 The data items listed include all data flows and the contents of all data stores
appearing on all the DFDs in a DFD model.
 However, a single data dictionary should capture all the data appearing in all the DFDs
constituting the DFD model of a system.
 A data dictionary lists the purpose of all data items and the definition of all composite
data items in terms of their component data items.
 For example, a data dictionary entry may represent that the data grossPay consists of
the components regularPay and overtimePay.
grossPay = regularPay + overtimePay
Data definition
Composite data items can be defined in terms of primitive data items using the
following data definition operators.
+: Denotes composition of two data items, e.g. a+b represents data a and b.
[,,]: Represents selection, i.e. any one of the data items listed inside the square bracket
can occur For example, [a,b] represents either a occurs or b occurs.
(): The contents inside the bracket represent optional data which may or may not
appear. a+(b) represents either a or a+b occurs.
{}: represents iterative data definition, e.g. {name}5 represents five name data.
{name}* Represents zero or more instances of name data.
=: Represents equivalence, e.g. a=b+c means that a is a composite data item
comprising of both b and c.
/* */: Anything appearing within /* and */ is considered as comment.

Levels of DFD
Level 0:
 DFD Level 0 is also called a Context Diagram. It’s a basic overview of the whole system
or process being analyzed or modeled.
 It’s designed to be an at-a-glance view, showing the system as a single high-level
process, with its relationship to external entities.
 It should be easily understood by a wide audience, including stakeholders, business
analysts, data analysts and developers.
Level 1:

 DFD Level 1 provides a more detailed breakout of pieces of the Context Level Diagram.
 It highlights the main functions carried out by the system and break down the high-
level process of the Context Diagram into its sub processes
Level 2:

 DFD Level 2 then goes one step deeper into parts of Level 1.
 It may require more text to reach the necessary level of detail about the system’s
functioning.