Module 2

Requirements Analysis and Modelling

Requirements elicitation
Requirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development. It can be successful only through an
effective customer-developer partnership. It is needed to know what the users really need.
There are a number of requirements elicitation methods. Few of them are listed below –
1. Interviews
2. Surveys
3. Questionnaires
4. Task analysis
5. Domain Analysis
6. Brainstorming Sessions
7. Prototyping
8. Observation
9. Facilitated Application Specification Technique (FAST)
10. Quality Function Deployment (QFD)
11. Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users, and the customer involved.
1.Interviews:
Objective of conducting an interview is to understand the customer’s expectations from the
software.
It is impossible to interview every stakeholder hence representatives from groups are selected
based on their expertise and credibility.
Interviews maybe be open ended or structured.

1. In open ended interviews there is no pre-set agenda. Context free questions may be asked
to understand the problem.
2. In structured interview, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.

2. Brainstorming Sessions:
 It is a group technique
 It is intended to generate lots of new ideas hence providing a platform to share views
 A highly trained facilitator is required to handle group bias and group conflicts.
 Every idea is documented so that everyone can see it.
 Finally a document is prepared which consists of the list of requirements and their priority
if possible.

3.Facilitated Application Specification Technique:

It’s objective is to bridge the expectation gap – difference between what the developers
think they are supposed to build and what customers think they are going to get.
A team oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system
Each participant prepares his/her list, different lists are then combined, redundant entries are
eliminated, team is divided into smaller sub-teams to develop mini-specifications and finally
a draft of specifications is written down using all the inputs from the meeting.
4.Quality Function Deployment:
In this technique customer satisfaction is of prime concern, hence it emphasizes on the
requirements which are valuable to the customer.
3 types of requirements are identified –
 Normal requirements – In this the objective and goals of the proposed software are
discussed with the customer. Example – normal requirements for a result management
system may be entry of marks, calculation of results, etc
 Expected requirements – These requirements are so obvious that the customer need not
explicitly state them. Example – protection from unauthorized access.
 Exciting requirements – It includes features that are beyond customer’s expectations
and prove to be very satisfying when present. Example – when unauthorized access is
detected, it should backup and shutdown all processes.
The major steps involved in this procedure are –
1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorized as –
 It is possible to achieve
 It should be deferred and the reason for it
 It is impossible to achieve and should be dropped off
5. Use Case Approach:
This technique combines text and pictures to provide a better understanding of the
requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence they only give a
functional view of the system.
The components of the use case design includes three major things – Actor, Use cases, use
case diagram.
1. Actor – It is the external agent that lies outside the system but interacts with it in some
way. An actor maybe a person, machine etc. It is represented as a stick figure. Actors can
be primary actors or secondary actors.
 Primary actors – It requires assistance from the system to achieve a goal.
 Secondary actor – It is an actor from which the system needs assistance.
2. Use cases – They describe the sequence of interactions between actors and the system.
They capture who(actors) do what(interaction) with the system. A complete set of use
cases specifies all possible ways to use the system.
3. Use case diagram – A use case diagram graphically represents what happens when an
actor interacts with a system. It captures the functional aspect of the system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.
Surveys

Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.

Questionnaires

A document with pre-defined set of objective questions and respective options is handed over
to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.

Task analysis

Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is studied and
requirements of proposed system are collected.

Domain Analysis

Every software falls into some domain category. The expert people in the domain can be a
great help to analyze general and specific requirements.

Software Requirement Specifications

The production of the requirements stage of the software development process is Software
Requirements Specifications (SRS) (also called a requirements document).

This report lays a foundation for software engineering activities and is constructing when entire
requirements are elicited and analyzed.

SRS is a formal report, which acts as a representation of software that enables the customers
to review whether it (SRS) is according to their requirements. Also, it comprises user
requirements for a system as well as detailed specifications of the system requirements.

The SRS is a specification for a specific software product, program, or set of applications that
perform particular functions in a specific environment. It serves several goals depending on
who is writing it.

First, the SRS could be written by the client of a system. Second, the SRS could be written by
a developer of the system.

The two methods create entirely various situations and establish different purposes for the
document altogether. The first case, SRS, is used to define the needs and expectation of the
users. The second case, SRS, is written for various purposes and serves as a contract document
between customer and developer.
Characteristics of good SRS

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS.
SRS is said to be perfect if it covers all the needs that are truly expected from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following elements:

(1). All essential requirements, whether relating to functionality, performance, design,

constraints, attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of input data in all
available categories of situations.

(3). Full labels and references to all figures, tables, and diagrams in the SRS and definitions of
all terms and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in its conflict. There are three types of possible conflict in the SRS:

(1). The specified characteristics of real-world objects may conflicts. For example,
(a) The format of an output report may be described in one requirement as tabular but in another
as textual.

(b) One condition may state that all lights shall be green while another states that all lights shall
be blue.

(2). There may be a reasonable or temporal conflict between the two specified actions. For
example,

(a) One requirement may determine that the program will add two inputs, and another may
determine that the program will multiply them.

(b) One condition may state that "A" must always follow "B," while other requires that "A and
B" co-occurs.

(3). Two or more requirements may define the same real-world object but use different terms
for that object. For example, a program's request for user input may be called a "prompt" in
one requirement's and a "cue" in another. The use of standard terminology and descriptions
promotes consistency.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a method
used with multiple definitions, the requirements report should determine the implications in
the SRS so that it is clear and simple to understand.

5. Ranking for importance and stability: The SRS is ranked for importance and stability if
each requirement in it has an identifier to indicate either the significance or stability of that
particular requirement.

Typically, all requirements are not equally important. Some prerequisites may be essential,
especially for life-critical applications, while others may be desirable. Each element should be
identified to make these differences clear and explicit. Another way to rank requirements is to
distinguish classes of items as essential, conditional, and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly
obtain changes to the system to some extent. Modifications should be perfectly indexed and
cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-
effective system to check whether the final software meets those requirements. The
requirements are verified with the help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it
facilitates the referencing of each condition in future development or enhancement
documentation.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly referencing its
source in earlier documents.
2. Forward Traceability: This depends upon each element in the SRS having a unique name
or reference number.

The forward traceability of the SRS is especially crucial when the software product enters the
operation and maintenance phase. As code and design document is modified, it is necessary to
be able to ascertain the complete set of requirements that may be concerned by those
modifications.

9. Design Independence: There should be an option to select from multiple design alternatives
for the final system. More specifically, the SRS should not contain any implementation details.

10. Testability: An SRS should be written in such a method that it is simple to generate test
cases and test plans from the report.

11. Understandable by the customer: An end user may be an expert in his/her explicit domain
but might not be trained in computer science. Hence, the purpose of formal notations and
symbols should be avoided too as much extent as possible. The language should be kept simple
and clear.

12. The right level of abstraction: If the SRS is written for the requirements stage, the details
should be explained explicitly. Whereas,for a feasibility study, fewer analysis can be used.
Hence, the level of abstraction modifies according to the objective of the SRS.

Software Requirement Specification (SRS) Format

1. Introduction
 (i) Purpose of this document
 (ii) Scope of this document
 (iii) Definition, Acronyms, and abbreviations
 (iv) References
 (v) Overview
2. General description
 Product Perspective
 Product Function
 User characteristics
 Constraints
 Assumption & Dependencies
 Apportioning of requirements

3. Specific Requirements
 Interfaces
 Database
 Performance
 Software system attributes
 4. Change Management Process
5. Document Approvals
6. Supporting Information

Software Requirement Specification (SRS) Format as name suggests, is complete

specification and description of requirements of software that needs to be fulfilled for
successful development of software system. These requirements can be functional as well as
non-requirements depending upon type of requirement. The interaction between different
customers and contractor is done because its necessary to fully understand needs of customers.

Depending upon information gathered after interaction, SRS is developed which describes
requirements of software that may include changes and modifications that is needed to be done
to increase quality of product and to satisfy customer’s demand.
1. Introduction :
 (i) Purpose of this Document –
At first, main aim of why this document is necessary and what’s purpose of document
is explained and described.
 (ii) Scope of this document –
In this, overall working and main objective of document and what value it will
provide to customer is described and explained. It also includes a description of
development cost and time required.
 (iii) Overview –
In this, description of product is explained. It’s simply summary or overall review of
product.

2. General description :
In this, general functions of product which includes objective of user, a user
characteristic, features, benefits, about why its importance is mentioned. It also describes
features of user community.

3. Functional Requirements :
In this, possible outcome of software system which includes effects due to operation of
 program is fully explained. All functional requirements which may include calculations,
data processing, etc. are placed in a ranked order.

4. Interface Requirements :
In this, software interfaces which mean how software program communicates with each
other or users either in form of any language, code, or message are fully described and
explained. Examples can be shared memory, data streams, etc.

5. Performance Requirements :
In this, how a software system performs desired functions under specific condition is
explained. It also explains required time, required memory, maximum error rate, etc.

6. Design Constraints :
In this, constraints which simply means limitation or restriction are specified and
explained for design team. Examples may include use of a particular algorithm, hardware
and software limitations, etc.

7. Non-Functional Attributes :
In this, non-functional attributes are explained that are required by software system for
better performance. An example may include Security, Portability, Reliability,
Reusability, Application compatibility, Data integrity, Scalability capacity, etc.

8. Preliminary Schedule and Budget :

In this, initial version and budget of project plan are explained which include overall time
duration required and overall cost required for development of project.

9. Appendices :
In this, additional information like references from where information is gathered,
definitions of some specific terms, acronyms, abbreviations, etc. are given and explained.

Developing Use Cases (UML)

UML (Unified Modeling Language) is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software systems. UML was created by the
Object Management Group (OMG) and UML 1.0 specification draft was proposed to the
OMG in January 1997. It was initially started to capture the behavior of complex software
and non-software system and now it has become an OMG standard.
Use Case:
Use case plays a significant role in the distinct phases of Software Development Life Cycle.
Use Case depends on ‘User Actions’ and ‘Response of System’ to the User Actions.
It is the documentation of the ‘Actions’ performed by the Actor/User and the corresponding
‘Behaviour’ of the System to the User ‘Actions’. Use Cases may or may not result in
achieving a goal by the ‘Actor/User’ on interactions with the system.
In Use Case, we will describe ‘How a System will respond to a given Scenario?’. It is ‘user-
oriented’ not ‘system oriented’.
It is ‘user-oriented’: We will specify ‘what are the Actions done by the user?’ and ‘What
the Actors see in a system?’.
It is not ‘system oriented’: We will not specify ‘What are the input given to the system?’
and ‘What are the output produced by the system?’.
The development team needs to write the ‘Use Cases’, as the development phase highly
depends on them.
Use case writer, Team members, and the Customers will contribute towards the creation of
these cases.
For creating the these, we need to have a development team assembled and the team should
be highly aware of the project concepts.
After implementing the case, the document is tested, and the behavior of the System
is checked accordingly. In a case the capital Letter ‘A’ denotes ‘Actor’, the letter ‘S’
denotes ‘System’.
Elements in Use Cases
1) Brief description: A brief description explaining the case.
2) Actor: Users that are involved in Use Cases Actions.
3) Precondition: Conditions to be Satisfied before the case begins.
4) Basic Flow: ‘Basic Flow’ or ‘Main Scenario’ is the normal workflow in the system. It
is the flow of transactions done by the Actors on accomplishing their goals. When the actors
interact with the system, as it’s the normal workflow, there won’t be any error and the
Actors will get the expected output.
5) Alternate flow: Apart from the normal workflow, a system can also have an ‘Alternate
workflow’. This is the less common interaction done by a user with the system.
6) Exception flow: The flow that prevents a user from achieving the goal.
7) Post Conditions: The conditions that need to be checked after the case is completed.
Use Case Diagram
Use Case Diagram is a pictorial representation of a user(s) Actions in a system. It does
provide a great tool in this context, if the diagram is containing a lot of actors, then it is
very easy to understand. If it is a high-level diagram, it won’t share a lot of details. It shows
complex ideas in a fairly basic way.
As shown in the Fig above it represents a diagram where Rectangle represents a ‘System’,
oval represent a ‘Use Case’, Arrow represents a ‘Relationship’ and the Man represents a
‘User/Actor’. It Shows a system/application, then it shows the organization/people who
interact with it and shows the basic flow of ‘What the system does?’
This is the Use case diagram of ‘Login’ case. Here, we have more than one actor, they are
all placed outside the system. Students, teachers, and parents are considered as primary
actors. That is why they all are placed on the left side of the rectangle.
Admin and Staff are considered as secondary actors, so we place them on the right side of
the rectangle. Actors can log in to the system, so we connect the actors and login case with
a connector.
Other functionality found in the system are Reset Password and Forgot password. They are
all related to login case, so we connect them to the connector.
EXAMPLE 1: Write the scenario for user interaction with ATM system.

EXAMPLE 2: Write the steps for booking a ticket in a reservation.

Scenario-based model
We use Activity Diagrams to illustrate the flow of control in a system and 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.

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.
We can depict both sequential processing and concurrent processing of activities using
an activity diagram. They are used in business and process modelling where their
primary use is to depict the dynamic aspects of a system.
How to Draw an activity diagram –

1. Identify the initial state and the final states.

2. Identify the intermediate activities needed to reach the final state from he initial
state.
3. Identify the conditions or constraints which cause the system to change control
flow.
4. Draw the diagram with appropriate notations.

The various components used in the diagram and the standard notations are explained
below.

Activity Diagram Notations –

1. Initial State – The starting state before an activity takes place is depicted using
the initial state.

Figure – notation for initial state or start state

For example – Here the initial state is the state of the system before the application
is opened.

Figure – initial state symbol being used

2. 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.

Figure – notation for an activity state

For example – Consider the previous example of opening an application opening
the application is an activity state in the activity diagram.
 Figure – activity state symbol being used

3. 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.

Figure – notation for control Flow

An activity state can have multiple incoming and outgoing action flows.
Consider the example – Here both the states transit into one final state using action
flow symbols i.e. arrows.

Figure – using action flows for transitions

4. Decision node and Branching – When we need to make a decision before

deciding the flow of control, we use the decision node.

Figure – notation for 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.
 Figure – an activity diagram using decision node

5. Guards – A Guard refers to a statement written next to a decision node on an arrow

sometimes within square brackets.

Figure – guards being used next to a decision node

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.
6. Fork – Fork nodes are used to support concurrent activities.

Figure – fork notation

When we use a fork node when both the activities get executed concurrently
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.

Figure – a diagram using fork

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

Figure – join notation

For example – When both activities i.e. steaming the milk and adding coffee get
completed, we converge them into one final activity.
 Figure – a diagram using join notation

8. 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.

Figure – merge notation

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.
 Figure – an activity diagram using merge notation

9. Time Event –

Figure – time event notation

We can have a scenario where an event takes some time to complete. We use an
hourglass to represent a time event.
For example – Let us assume that the processing of an image takes takes a lot of
time. Then it can be represented as shown below.
 Figure – an activity diagram using time event

10. 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.

Figure – notation for final state

Figure – an activity diagram for an emotion based music player

The above figure depicts an activity diagram for an emotion based music player which
can also be used to change the wallpaper.
Figure – an activity diagram
The above diagram prints the number if it is odd otherwise it subtracts one from the
number and displays it.

Uses of an Activity Diagram –

 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.
For example, below is an Activity Diagram for Reserving a Ticket.
Swimlane Diagram :
It is also a graphical representation of the System.

Swimlane diagrams are also known as the Rummler-Brache diagram or a cross-

functional diagram. Swimlanes are sometimes called functional bands.

It simply describes who is responsible for the activities being performed in the activity
diagram and how they are responsible.

The activity diagram only represents the activities being performed, but Swimlane
describes who does what in a process or activity performed.

In the Swimlane diagram, the activity diagram is divided according to the class
responsible for working or performing out these activities.

It simply shows the connection and strong communication between these lanes and is
used to highlight waste, redundancy, and inefficiency in a process of an activity or
program.

Essential key-points of all the above diagrams :

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.

Figure – swimlanes notation

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.

Figure – an activity diagram making use of swimlanes

 Fork –
It is used to represent the multiple parallel flows.
 Branches –
It allow the parallel flow within activities.
 Merge –
It brings together or combines together multiple branches.
 Join –
It is used to control and synchronize various parallel flows.

For example, below is a Swimlane diagram for reserving a ticket.

Class-based model
Class-based modeling identifies classes, attributes and relationships that the system will use.

In the airline application example,

the traveller/user and the boarding pass represent classes.
The traveller’s first and last name, and travel document type represent attributes, characteristics
that describe the traveller class.
The relationship between traveller and boarding pass classes is that the traveller must enter
these details into the application in order to get the boarding pass, and that the boarding pass
contains this information along with other details like the flight departure gate, seat number
etc.
Class based modeling represents the object. The system manipulates the operations.
The elements of the class based model consist of classes and object, attributes, operations, class
– responsibility - collaborator (CRS) models.
Classes
Classes are determined using underlining each noun or noun clause and enter it into the simple
table.
Classes are found in following forms:
External entities: The system, people or the device generates the information that is used by
the computer based system.
Things: The reports, displays, letter, signal are the part of the information domain or the
problem.
Occurrences or events: A property transfer or the completion of a series or robot movements
occurs in the context of the system operation.
Roles: The people like manager, engineer, salesperson are interacting with the system.
Organizational units: The division, group, team are suitable for an application.
Places: The manufacturing floor or loading dock from the context of the problem and the
overall function of the system.
Structures: The sensors, computers are defined a class of objects or related classes of objects.
Attributes
Attributes are the set of data objects that are defining a complete class within the context of the
problem.
For example, 'employee' is a class and it consists of name, Id, department, designation and
salary of the employee are the attributes.

Class Diagram
Class diagram is a static diagram. It represents the static view of an application. Class diagram
is not only used for visualizing, describing, and documenting different aspects of a system but
also for constructing executable code of the software application.
The class diagrams are widely used in the modeling of object-oriented systems because they
are the only UML diagrams, which can be mapped directly with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and
constraints. It is also known as a structural diagram.

Purpose of Class Diagrams

The purpose of the class diagram can be summarized as −
 Analysis and design of the static view of an application.
 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.

Components of a Class Diagram

The class diagram is made up of three sections:

o Upper Section: The upper section encompasses the name of the class.

Some of the following rules that should be taken into account while representing a class are given below:

a. Capitalize the initial letter of the class name.

b. Place the class name in the center of the upper section.

c. A class name must be written in bold format.

d. The name of the abstract class should be written in italics format.

 o Middle Section: The middle section constitutes the attributes, which describe the quality of the
class. The attributes have the following characteristics:

. The attributes are written along with its visibility factors, which are public (+), private (-), protected
(#), and package (~).

o Lower Section: The lower section contain methods or operations. The methods are represented in
the form of a list, where each method is written in a single line. It demonstrates how a class interacts
with data.

Relationships
In UML, relationships are of three types:

o Dependency: A dependency is a semantic relationship between two or more classes where a change
in one class cause changes in another class. It forms a weaker relationship.
In the following example, Student_Name is dependent on the Student_Id.

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

class (subclass). In this, the child class is inherited from the parent class.
For example, The Current Account, Saving Account, and Credit Account are the generalized form
of Bank Account.
 o Association: It describes a static or physical connection between two or more objects. It depicts
how many objects are there in the relationship.
For example, a department is associated with the college.

Multiplicity: It defines a specific range of allowable instances of attributes. In case if a range is not specified,
one is considered as a default multiplicity.

For example, multiple patients are admitted to one hospital.

Aggregation: An aggregation is a subset of association, which represents has a relationship. It is more

specific then association. It defines a part-whole or part-of relationship. In this kind of relationship, the child
class can exist independently of its parent class.

The company encompasses a number of employees, and even if one employee resigns, the company still
exists.

Composition: The composition is a subset of aggregation. It portrays the dependency between the parent
and its child, which means if one part is deleted, then the other part also gets discarded. It represents a whole-
part relationship.

A contact book consists of multiple contacts, and if you delete the contact book, all the contacts will be lost.
Abstract Classes
In the abstract class, no objects can be a direct entity of the abstract class. The abstract class can neither be
declared nor be instantiated.

Let us assume that we have an abstract class named displacement with a method declared inside it, and that
method will be called as a drive (). Now, this abstract class method can be implemented by any object, for
example, car, bike, scooter, cycle, etc.

How to Draw a Class Diagram?

The following points should be remembered while drawing a class diagram −
 The name of the class diagram should be meaningful to describe the aspect of the
system.
 Each element and their relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be clearly identified
 For each class, minimum number of properties should be specified, as unnecessary
properties will make the diagram complicated.
 Use notes whenever required to describe some aspect of the diagram. At the end of the
drawing it should be understandable to the developer/coder.
 Finally, before making the final version, the diagram should be drawn on plain paper
and reworked as many times as possible to make it correct.
The following diagram is an example of an Order System of an application. It describes a
particular aspect of the entire application.
 First of all, Order and Customer are identified as the two elements of the system. They
have a one-to-many relationship because a customer can have multiple orders.
 Order class is an abstract class and it has two concrete classes (inheritance relationship)
SpecialOrder and NormalOrder.
 The two inherited classes have all the properties as the Order class. In addition, they
have additional functions like dispatch () and receive ().
The following class diagram has been drawn considering all the points mentioned above.
A class diagram describing the sales order system is given below.

Where to Use Class Diagrams?

Class diagram is a static diagram and it is used to model the static view of a system. The static
view describes the vocabulary of the system.
Class diagram is also considered as the foundation for component and deployment diagrams.
Class diagrams are not only used to visualize the static view of the system but they are also
used to construct the executable code for forward and reverse engineering of any system.
Generally, UML diagrams are not directly mapped with any object-oriented programming
languages but the class diagram is an exception.
Class diagram clearly shows the mapping with object-oriented languages such as Java, C++,
etc. From practical experience, class diagram is generally used for construction purpose.
In a nutshell it can be said, class diagrams are used for −
 Describing the static view of the system.
 Showing the collaboration among the elements of the static view.
 Describing the functionalities performed by the system.
 Construction of software applications using object oriented languages.

Usage of Class diagrams

The class diagram is used to represent a static view of the system. It plays an essential role in the
establishment of the component and deployment diagrams. It helps to construct an executable code to
perform forward and backward engineering for any system, or we can say it is mainly used for construction.
It represents the mapping with object-oriented languages that are C++, Java, etc. Class diagrams can be used
for the following purposes:

1. To describe the static view of a system.

2. To show the collaboration among every instance in the static view.

3. To describe the functionalities performed by the system.

4. To construct the software application using object-oriented languages.

Behavioral Model
Behavioral Model is specially designed to make us understand behavior and factors
that influence behavior of a System. Behavior of a system is explained and represented
with the help of a diagram. This diagram is known as State Transition Diagram. It is
a collection of states and events. It usually describes overall states that a system can
have and events which are responsible for a change in state of a system.
So, on some occurrence of a particular event, an action is taken and what action needs
to be taken is represented by State Transition Diagram.
Example :
Consider an Elevator. This elevator is for n number of floors and has n number of
buttons one for each floor.
Elevator’s working can be explained as follows :
1. Elevator buttons are type of set of buttons which is there on elevator. For
reaching a particular floor you want to visit, “elevator buttons” for that particular
floor is pressed. Pressing, will cause illumination and elevator will start moving
towards that particular floor for which you pressed “elevator buttons”. As soon as
elevator reaches that particular floor,
illumination gets canceled.

2. Floor buttons are another type of set of buttons on elevator. If a person is on a

particular floor and he wants to go on another floor, then elevator button for that
floor is pressed. Then, process will be same as given above. Pressing, will cause
illumination and elevator to start moving, and when it reaches on desired floor,
illumination gets canceled.
3. When there is no request for elevator, it remains closed on current floor.
State Transition Diagram for an elevator system is shown below –

Advantages :
 Behavior and working of a system can easily be understood without any effort.
 Results are more accurate by using this model.
 This model requires less cost for development as cost of resources can be minimal.
 It focuses on behavior of a system rather than theories.

Disadvantages :
 This model does not have any theory, so trainee is not able to fully understand
basic principle and major concept of modeling.
 This modeling cannot be fully automated.
 Sometimes, it’s not easy to understand overall result.
 Does not achieve maximum productivity due to some technical issues or any
errors.