IIMT COLLEGE OF ENGINEERING, GREATER NOIDA

SOFTWARE ENGINEERING

KCS-651

LABORATORY MANUAL
B.TECH
(3rd Year, 6th Semester)
(2023-24)
Department of Computer Science and Engineering

IIMT College of Engineering Greater Noida

Submitted To: Submitted By:

Course Outcomes
At the end of this lab session, the student would be able to:

CO 1 Identify ambiguities, inconsistencies and incompleteness from a requirements specification and

state functional and non-functional requirements.
CO 2 Identify different actors and use cases from a given problem statement and draw a use case diagram
to associate use cases with different types of relationships.
CO 3 Draw a class diagram after identifying classes and associations among them.
CO 4 Graphically represent various UML diagrams, and associations among them and identify the logical
sequence of activities undergoing in a system, and represent them pictorially.
CO 5 Able to use modern engineering tools for specification, design, implementation and testing.

2
 INDEX

S.No. Practical Name Page No. Signature

1 Prepare a SRS document in line with the IEEE 4

recommended standards.

2 Draw the use case diagram and specify role of each of the 12
actors. Also state the precondition, post condition and
function of each use case.

3 Draw the activity diagram. 16

4 Identify the classes. Classify them as weak and strong 17

classes and draw the class diagram.

5 Draw the sequence diagram for any two scenarios 18

6 Draw the collaboration diagram. 19

7 Draw the state chart diagram. 20

8 Draw the component diagram. 21

9 Perform forward engineering in java. (Model to code 22

conversion)

10 Perform reverse engineering in java. (Code to Model 23

conversion)

11 Draw the deployment diagram. 27

3
Practical 1

Prepare a SRS document in line with the IEEE

recommended standards.

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-functional depending
upon type of requirement. The interaction between different customers and contractor is done
because its necessary to fully understand needs of customers.

SRS of an ATM System:

4
 Table of Contents
Table of Contents ............................................................................................................................................ 1

1. Introduction ..................................................................................................................................................... 2
Purpose 2
Document Conventions..................................................................................................................................... 2
Intended Audience and Reading Suggestions ................................................................................................... 2
Product Scope ................................................................................................................................................... 2
References ......................................................................................................................................................... 2
2. Overall Description ......................................................................................................................................... 3
Product Perspective........................................................................................................................................... 3
Product Functions ............................................................................................................................................. 3
User Classes and Characteristics ...................................................................................................................... 3
Operating Environment ..................................................................................................................................... 3
Design and Implementation Constraints ........................................................................................................... 3
User Documentation ......................................................................................................................................... 3
Assumptions and Dependencies........................................................................................................................ 4
3. External Interface Requirements .................................................................................................................. 4
User Interfaces .................................................................................................................................................. 4
Hardware Interfaces .......................................................................................................................................... 4
Software Interfaces ........................................................................................................................................... 4
Communications Interfaces .............................................................................................................................. 5
4. System Features............................................................................................................................................... 5
Use Cases 5
5. Other Nonfunctional Requirements .............................................................................................................. 6
Performance Requirements ............................................................................................................................... 6
Safety Requirements ......................................................................................................................................... 6
Security Requirements ...................................................................................................................................... 6
Business Rules .................................................................................................................................................. 7
6. Other Requirements ....................................................................................................................................... 7
Appendix A: Glossary ..................................................................................................................................... 7
Appendix B: Analysis Models ........................................................................................................................ 7

5
1 Introduction

Purpose
This document describes the software requirements and specifications for an automated teller machine
(ATM) network. The document is intended for the customer and the developer (designers, testers,
maintainers).

Document Conventions
 Account- A single account at a bank against which transactions can be applied. Accounts may be of
various types with at least checking and savings. A customer can hold more than one account.
 Max Daily WithDraw- The maximum amount of cash that a customer can withdraw from an account in a
day (from 00:00 AM to 23:59 PM) via ATMs.
 PIN- It refers to Personal Identification Number. Used to identify and validate the login of an ATM user.

Intended Audience and Reading Suggestions

 Software designers
 Systems engineers
 Software developers
 Software testers
 Customers

Product Scope
The network enables customers to complete simple bank account services via automated teller machines
(AT Ms) that may be located off premise and that need not be owned and operated by the customer’s
bank. The ATM identifies a customer by a cash card and password. It collects information about a simple
account transaction information to the customer’s bank, and dispenses cash to the customer. The banks
provide their own software for their own computers transaction (e.g. deposit, withdrawal, transfer, bill
payment), communicates the References
1. www.google.com
2. www.scribd.com

6
2. Overall Description
Product Perspective
An automated teller machine (ATM) is a computerized telecommunications device that provides the
customer rs of a financial institution with access to financial transactions in a public space without the
need for a human clerk or bank teller. On most modern ATMs, the customer is identified by inserting a
plastic ATM card with a magnetic stripe or a plastic smartcard with a chip, that contains a unique card
number and some security information, such as an expiration date or CVC (CVV). Security is provided by
the customer entering a personal identification number (PIN).

Product Functions
Using an ATM, customers can access their bank accounts in order to make cash withdrawals (or credit card
cash advances) and check their account balances.
The functions of the system are:
1. Login
2. Get balance information
3. Withdraw cash
4. Transfer funds

User Classes and Characteristics

a) User
This actor is the person who uses the software.
b) BANK/ATM
This actor represents the financial institute that provides services to ATM. Responsible for verifying bank
customers, authorizing transactions and recording completed transactions.

Operating Environment
The ATM is a network based mechanical device and shall operate in all environments, for model we are
taking Tidal 3600m.

Design and Implementation Constraints

Some of the constraints that have to be taken care of with respect to the software development could be
the platform where the software is to be run should have an access to MS-ACCESS. The end user needs to
have basic computer knowledge.
The user may fail to exactly explain his requirements however his requirements are analyzed and

7
 understood by the developer, as the software is a generic one.

User Documentation
Online help is provided for each of the feature available with the ATM. Online help is provided for each
and every feature provided by the system. The user manual should be available as a hard copy and also
as online help. An installation document will be provided that includes the installation instructions and
configuration guidelines, which is important to a full solution offering.

Assumptions and Dependencies

 Hardware never fails
 ATM casing is impenetrable
 Limited number of transactions per day (sufficient paper for receipts)
 Limited amount of money withdrawn per day (sufficient money)

3. External Interface Requirements

User Interfaces
The customer user interface should be intuitive, such that 99.9% of all new ATM users are able to
complete their banking transactions without any assistance.

Hardware Interfaces
The hardware should have following specifications:
 Ability to read the ATM card
 Ability to count the currency notes
 Touch screen for convenience
 Keypad (in case touchpad fails)
 Continuous power supply
 Ability to connect to bank’s network
 Ability to take input from user
 Ability to validate user

8
 Software Interfaces
The software interfaces are specific to the target banking software systems.
 Languages supported: java (Front end)
 Database: Microsoft Access (Back end)
 MS-Office
 ArgoUml

At present, two known banking systems will participate in the ATM network.
 State Bank
 Indian Overseas Bank

Communications Interfaces
These are protocols that are needed to directly interact with the customers. Apart from these protocols, to
maintain a healthy relationship with the customer, both formal and informal meetings, group discussions
and technical meetings will be conducted frequently.

4. System Features
This section of SRS should contain all of the software requirements and specification. At minimum, it
should include descriptions.
 All interfaces to the system
1. Every input to the system
2. Every output from the system
 All functions performed by the system are:
1. Validity checks on inputs
2. Relationship of outputs to inputs
3. Responses to abnormal situations
Input and output definitions should be consistent among use cases, functional specifications and UI’s.

Use Cases
Login
This is a use case used to verify the authentication of the user. In this the user gives his allotted pin
number as input, the system the verifies whether the card number and pin number stored in data base
matches or not, if it matches then it allows the user to use the system else it asks to enter the pin number
again.

9
 Balance Enquiry
This use case is used to check the balance in the user account. After every transaction the balance in the
user’s account is updated by taking data consistency into consideration and the updated account balance is
displayed to the user.
Withdrawal
This use case facilitates the user to withdraw money from his account. After the money is withdrawn it is
updated in the user’s account.
Generate Receipt

This use case is used to generate receipt for the transaction made by the user.

5. Other Nonfunctional Requirements

Performance Requirements
It must be able to perform in adverse conditions like high/low temperature etc. Uninterrupted interrupted
connections
High data transfer rate
Security Requirements
 Users accessibility is censured in all the ways
 Users are advised to change their PIN on first use
 Users are advised not to tell their PIN to anyone
 The maximum number of attempts to enter PIN will be three

Safety Requirements
 Must be safe kept in physical aspects, say in a cabin
 Must be bolted to floor to prevent any kind of theft.
 Must have an emergency phone outside the cabin
 There must be an emergency phone just outside the cabin
 The cabin door must have an ATM card swipe slot
 The cabin door will always be locked, which will open only when user swipes his/her ATM card
 In the slot & is validated as genuine

Business Rules
 Personal information should be protected
 The ATM should comply with quality assurance standards

10
 The Money circulation should be monitored and ATM should be filled regularly.

6. Other Requirements
The ATM should be implemented on computers with 50Mbytes free space on HDD for Database
(80Gbytes for server) and 32Mbytes RAM for Database (256Mbytes for server). The ATM should
correctly interface if MS Access applications and MS SQL Server

Appendix A: Glossary
ATM – Automated Teller Machine PIN – Personal Identification NumberCVV – Card Verification
Number UI – User Interface.

Appendix B: Analysis Models

 Use case diagram
 Activity diagram
 Sequence diagram
 Collaboration diagram
 Class diagram
 Component diagram
 Deployment diagram

11
Practical 2
Draw the use case diagram and specify role of each of the
actors. Also state the precondition, post condition and
function of each use case.

A use case diagram is a graphical depiction of a user's possible interactions with a system. A use
case diagram shows various use cases and different types of users the system has and will often
be accompanied by other types of diagrams as well. The use cases are represented by either
circles or ellipses.

Use case diagram of an ATM machine:

12
Flows of Events for Individual Use Cases

System Startup Use Case

The system is started up when the operator turns the operator switch to the "on" position. The
operator will be asked to enter the amount of money currently in the cash dispenser, and a
connection to the bank will be established. Then the servicing of customers can begin.

System Shutdown Use Case

The system is shut down when the operator makes sure that no customer is using the machine,
and then turns the operator switch to the "off" position. The connection to the bank will be shut
down. Then the operator is free to remove deposited envelopes, replenish cash and paper, etc.

Session Use Case

A session is started when a customer inserts an ATM card into the card reader slot of the
machine. The ATM pulls the card into the machine and reads it. (If the reader cannot read the
card due to improper insertion or a damaged stripe, the card is ejected, an error screen is
displayed, and the session is aborted.) The customer is asked to enter his/her PIN, and is then
allowed to perform one or more transactions, choosing from a menu of possible types of
transaction in each case. After each transaction, the customer is asked whether he/she would like
to perform another. When the customer is through performing transactions, the card is ejected
from the machine and the session ends. If a transaction is aborted due to too many invalid PIN
entries, the session is also aborted, with the card being retained in the machine.

The customer may abort the session by pressing the Cancel key when entering a PIN or choosing
a transaction type.

Transaction Use Case

Transaction is an abstract generalization. Each specific concrete type of transaction implements

certain operations in the appropriate way. The flow of events given here describes the behavior
common to all types of transaction. The flows of events for the individual types of transaction
(withdrawal, deposit, transfer, inquiry) give the features that are specific to that type of
transaction.

A transaction use case is started within a session when the customer chooses a transaction type
from a menu of options. The customer will be asked to furnish appropriate details (e.g.

13
account(s) involved, amount). The transaction will then be sent to the bank, along with
information from the customer's card and the PIN the customer entered.

If the bank approves the transaction, any steps needed to complete the transaction (e.g.
dispensing cash or accepting an envelope) will be performed, and then a receipt will be printed.
Then the customer will be asked whether he/she wishes to do another transaction.

If the bank reports that the customer's PIN is invalid, the Invalid PIN extension will be
performed and then an attempt will be made to continue the transaction. If the customer's card is
retained due to too many invalid PINs, the transaction will be aborted, and the customer will not
be offered the option of doing another.

If a transaction is cancelled by the customer, or fails for any reason other than repeated entries of
an invalid PIN, a screen will be displayed informing the customer of the reason for the failure of
the transaction, and then the customer will be offered the opportunity to do another.

The customer may cancel a transaction by pressing the Cancel key as described for each
individual type of transaction below.

Withdrawal Transaction Use Case

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g.
checking) from a menu of possible accounts, and to choose a dollar amount from a menu of
possible amounts. The system verifies that it has sufficient money on hand to satisfy the request
before sending the transaction to the bank. (If not, the customer is informed and asked to enter a
different amount.) If the transaction is approved by the bank, the appropriate amount of cash is
dispensed by the machine before it issues a receipt. (The dispensing of cash is also recorded in the
ATM's log.)

A withdrawal transaction can be cancelled by the customer pressing the Cancel key any time
prior to choosing the dollar amount.

Deposit Transaction Use Case

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking)
from a menu of possible accounts, and to type in a dollar amount on the keyboard. The
transaction is initially sent to the bank to verify that the ATM can accept a deposit from this
customer to this account. If the transaction is approved, the machine accepts an envelope from the
customer containing cash and/or checks before it issues a receipt. Once the envelope has been
received, a second message is sent to the bank, to confirm that the bank can credit the customer's
account - contingent on manual verification of the deposit envelope contents by an operator later.
(The receipt of an envelope is also recorded in the ATM's log.)

14
A deposit transaction can be cancelled by the customer pressing the Cancel key any time prior to
inserting the envelope containing the deposit. The transaction is automatically cancelled if the
customer fails to insert the envelope containing the deposit within a reasonable period of time
after being asked to do so.

Transfer Transaction Use Case

A transfer transaction asks the customer to choose a type of account to transfer from (e.g.
checking) from a menu of possible accounts, to choose a different account to transfer to, and to
type in a dollar amount on the keyboard. No further action is required once the transaction is
approved by the bank before printing the receipt.

A transfer transaction can be cancelled by the customer pressing the Cancel key any time prior to
entering a dollar amount.

Inquiry Transaction Use Case

An inquiry transaction asks the customer to choose a type of account to inquire about from a
menu of possible accounts. No further action is required once the transaction is approved by the
bank before printing the receipt.

An inquiry transaction can be cancelled by the customer pressing the Cancel key any time prior
to choosing the account to inquire about.

Invalid PIN Extension

An invalid PIN extension is started from within a transaction when the bank reports that the
customer's transaction is disapproved due to an invalid PIN. The customer is required to re-enter
the PIN and the original request is sent to the bank again. If the bank now approves the
transaction, or disapproves it for some other reason, the original use case is continued; otherwise
the process of re-entering the PIN is repeated. Once the PIN is successfully re-entered, it is used
for both the current transaction and all subsequent transactions in the session. If the customer
fails three times to enter the correct PIN, the card is permanently retained, a screen is displayed
informing the customer of this and suggesting he/she contact the bank, and the entire customer
session is aborted.

If the customer presses Cancel instead of re-entering a PIN, the original transaction is cancelled.

15
Practical 3
Draw the activity diagram.
An activity diagram is a behavioral diagram i.e. it depicts the behavior of a system. 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 modeling. where their primary use is to depict the dynamic aspects of a system. An
activity diagram is very similar to a flowchart.

This is the sequence diagram of ATM:

16
Practical 4
Identify the classes. Classify them as weak and strong classes
and draw the 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.
Class diagram describes the attributes and operations of a class and also the constraints imposed
on the system. 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.
This is the class diagram of an ATM:

17
Practical 5
Draw the sequence diagram for any two scenarios.
A sequence diagram is a type of interaction diagram because it describes how—and in what
order—a group of objects works together. These diagrams are used by software developers
and business professionals to understand requirements for a new system or to document an
existing process.
This is the sequence diagram of ATM.

18
Practical 6

Draw the collaboration diagram.

A collaboration diagram, also known as a communication diagram, is an illustration of the
relationships and interactions among software objects in the Unified Modeling Language
(UML). These diagrams can be used to portray the dynamic behavior of a particular use case
and define the role of each object.
This is the collaboration diagram of fetching a web page.

19
Practical 7

Draw the state chart diagram.

State chart diagram is one of the five UML diagrams used to model the dynamic nature of a
system. They define different states of an object during its lifetime and these states are
changed by events. State chart diagrams are useful to model the reactive systems.

This is the State chart diagram of ATM.

20
Practical 8

Draw the component diagram.

Component diagrams are used to model physical aspects of a system. Physical aspects are the
elements like executables, libraries, files, documents etc which resides in a node. So
component diagrams are used to visualize the Organization and relationships among
components in a system. These diagrams are also used to make executable systems.

This is the Component diagram of ATM.

21
Practical 9
Perform forward engineering in java. (Model to code
conversion)
Forward Engineering:
Forward Engineering is a method of creating or making an application with the help of the
given requirements. Forward engineering is also known as Renovation and Reclamation.
Forward engineering is required high proficiency skills. It takes more time to construct or
develop an application.

Forward engineering is a technique of creating high-level models or designs to make in

complexities and low-level information. Therefore, this kind of engineering has completely
different principles in numerous package and information processes.
Forward Engineering applies of all the software engineering process which contains SDLC to
recreate associate existing application. It is near to full fill new needs of the users into re-
engineering.

22
 Practical 10

Perform reverse engineering in java. (Code to Model

conversion)
Reverse Engineering is also known as backward engineering, is the process of forward
engineering in reverse.
In this, the information is collected from the given or existing application.
It takes less time than forward engineering to develop an application. In reverse engineering,
the application is broken to extract knowledge or its architecture.
1. Study the source code. Read the register method in RegisterController.java to see how it
works.

2. Start Visual Paradigm

3. Create a new project by selecting Project > New from the toolbar. In the New Project
window, name the project as Account Registration and click Create Blank Project button.

23
4. Select Tools > Code > Instant Reverse Java to Sequence Diagram... from the toolbar.

5. In the Instant Reverse Java to Sequence Diagram window, click on Add Source
Folder... button.

6. Select the extracted source folder src. Click Next button.

7. Select the method to visualize. Select src > RegisterController.java > register
(String,int). Click the Next button.

24
 8. You need to select a diagram to visualize the interaction. The Create new sequence
diagram option is selected and diagram name is entered by default. Click Finish button.

9. As a result, a sequence diagram is formed.

25
When a person invokes Register Controller's register method (message: 1), it creates an
account object (message: 1.1). After that, the controller sets the id, name and age to the
account object (message 1.2, 1.3, 1.4) and adds itself to the account list (message: 1.5). The
invocation ends with a return (message 1.6).

26
Practical 11
Draw the deployment diagram.
A deployment diagram is a UML diagram type that shows the execution architecture of a
system, including nodes such as hardware or software execution environments, and the
middleware connecting them. Deployment diagrams are typically used to visualize the
physical hardware and software of a system.

This is deployment diagram of Book Club Web Application.

27