INDEX

S.N PAGE SIGNATU

DATE NAMEOFTHEEXPERIMENT
O NO RE

1 Problem statement

Process model
2
Software requirement specification
3
Use case diagrams
4

5 Activity diagrams

DFD decision table & ER diagram

6

7 Class diagram

8 Sequenc diagram

9 Collaboration diagram

10 State transition diagram

8 Test case

9 Functional point analysis

10 Cocomo model

11 Critical path method

12 Gant chart

13 Passport automation system

EX.NO:1 PROBLEM STATEMENT
DATE:

Aim:
To prepared problem statement for ATM system.
Theory:
The problem statement is the initial starting point for a project. It is basically a one
to three page statement that everyone on the project agrees with that describes what will be
done at a high level. The problem statement is intended for a broad audience and should be
written in non-technical terms. It helps the non-technical and technical personnel
communicate by providing a description of a problem. It doesn't describe the solution to
the problem.
Problem statement the project entitled ATM system has a drastic change to that of
the older version of banking system, customer feel inconvenient with the transaction
method as it was in the hands of the bank employees.
In our ATM system, the above problem is overcome here, the transactions are done
in person by the customer thus makes the customers feel safe and secure.
Thus the application of our system helps the customer in checking the balance and
transaction of the amount by validating the pin number therefore ATM system is more user
friendly.

Result:
Thus the problem statement was written successfully.
EX.NO:2 PROCESS MODEL
DATE:

Aim:
To select relevant process model to define activities and related task set for as
ATM machine.
Theory:
The automated teller machine (ATM) is an automatic banking machine (ABM)
that allows the customer to complete basic transactions without any help from bank
representatives. There are two types of automated teller machines (ATMs). The basic
one allows the customer to only draw cash and receive a report of the account balance.
Another one is a more complex machine that accepts the deposit, provides credit card
payment facilities and reports account information.
Architecture Diagram of Automated Teller Machine:
ATM SPECIFICATIONS
The main components of the ATM that will affect the interaction between ATM and
its users are:
1. Key-Switch: to startup (ON) or shutdown (OFF) of the ATM machine.
2. Card-Reader: to read the users ATM-cards (magnetic stripe reader).
3. Screen: to display the messages to the users.
4. Key-Pad: to enter the information to the ATM e.g. PIN.
5. Cash-Dispenser: for dispensing cash.
6. Deposit-Slot: to deposit cash or checks from the users.
7. Printer: for printing the receipts.
8. Communication/Network Infrastructure: it is assumed that the ATM has a
communication infrastructure to communicate with the bank upon any transaction or
activity.
ATM-Human Interactions
ATM system will interact with different human objects as
shown below:
ATM-Operator interaction: operator will be responsible of:
 Turning the ATM in ON/OFF status using the designated Key-Switch.
 Refilling the ATM with cash.
 Refill ATM's printer with receipts.
 Assumed to refill ATM's printer with INK.
 Takeout deposited envelopes.
ATM-User interactions
The ATM will provide for its users the functions as shown below:
 Cash withdraw: the user can withdraw certain amount of cash.
 Deposit funds: the user can deposit cash or checks in envelops to his/her account.
 Transfer funds: the user can transfer funds to the other accounts.
 Balance inquiry: the user can view his/her account balance.
ATM-Bank Officers interactions
 To check the total deposits.
 To check the total withdrawals.
 To keep track number of transactions.
Bank Manager:
 Check the total deposits
 Check the total withdrawals
 Check the number of transactions per day.
 Print total deposits/withdrawals.
 Checks remaining cash.
The main point that has to be noted is that the interaction between the
manager/officers with ATM would be conducted through the bank Database.
How To Deposit Money at an ATM
Depositing money at an ATM may work differently from machine to machine. But
here are some general instructions:
Insert your card. (Don’t forget to retrieve it before you leave.)
Enter your PIN.
Choose the “deposit” option on the ATM screen.
Pick the type of deposit (cash or check).
Insert the cash or check into the machine.
Follow the ATM’s on-screen instructions for completing the deposit.
Many ATMs, but not all, accept cash deposits.
How To Withdraw Money From an ATM
Withdrawing money at an ATM also may work differently from machine to machine.
But here are some general instructions:
Insert your card. (Don’t forget to retrieve it before you leave.)
Enter your PIN.
Choose the amount of cash you want to withdraw.
Take the cash from the ATM’s cash dispenser.
Follow the ATM’s on-screen instructions for completing the withdrawal.

Result:
Thus the activities and task set for selecting relevant process model has been
done successfully.
EX.NO:3 SOFTWARE REQUIREMENT SPECIFICATION
DATE:

Aim:
To prepare broad SRS (Software Requirement Specification) for the ATM machine
projects.
Theory:
Table of Contents
1. Introduction............................................................................................................ 3
Purpose 3
Scope 3
Definitions, Acronyms, and Abbreviations 3
References 4
Overview 5
2. The Overall Description ...............................................................................… 5
Product Perspective 5
Product Functions 5
User Characteristics 7
Constraints 7
Assumptions and Dependencies 8
3. External interface Requirements......................................................................… 9
User Interfaces 9
Hardware Interfaces 9
Software Interfaces 10
Communications Interfaces 10
4. System Features 10
5. Other Non-Functional Requirements 11
Performance Requirements 11
Capacity 11
Dynamic Requirements 11
Quality 12
Software System Attributes 12
Reliability 12
 Availability 12
Security 13
Maintainability 13
Business Rules 14
6. Other Requirements............................................................................................ 14
Appendix A: Glossary 15
Appendix S: Analysis Models 16
1. Introduction
The software ATM Excel 3.0TM version1.0 is to be developed for Automated
Teller Machines (ATM). An automated teller machine (ATM) is computerized
telecommunications device that provides a financial institution's customers a secure
method of performing financial transactions, in a public space without the need for a
human bank teller. Through ATMExcl 3.0TM, customers interact with a user-friendly
interface that enables them to access their bank accounts and perform various transactions.
Purpose
This SRS defines External Interface, Performance and Software System Attributes
requirements of ATMExcl 3.0TM. This document is intended for the following group of
people:-
 Developers for the purpose of maintenance and new releases of the software.
 Management of the bank.
 Documentation writers.
 Testers.
Scope
This document applies to Automated Teller Machine software ATM 3.0TM. This
software facilitates the user to perform various transactions in his account without going to
bank. This software offers benefits such cash withdrawals, balance transfers, deposits,
inquiries, credit card advances and other banking related operations for customers. It also
allows the administrator to fix the tariffs and rules as and when required. The software
takes as input the login Id and the bank account number of the user for login purposes. The
outputs then comprise of an interactive display that lets the user select the desirable
function that he wants to perform.The software is expected to complete in duration of six
months and the estimated cost is Rs18 lakhs.
Definitions, Acronyms, and Abbreviations.
AC Alternate Current
AIMS ATM Information Management System
ATM An unattended electronic machine in a public place, connected to a
system and related equipment and activated by a bank custome
obtain cash withdrawals and other banking services.
Braille A system of writing and printing for blind or visually impaired peo
in which varied arrangements of raised dots representing letters
numerals are identified by touch.
BMS Bank Management Software developed by KPM Bank.
CDMA Code Division Multiple Access, a reliable
communicationprotocol.
CMS Card Management Software developed by KPM Bank.
DES Data Encryption Standard.
Dial-Up POS A message format for low cost communications.
Electronic Journal For easier, safer information storage, related to modem.

Internet An interconnected system of networks that connects computers aro

the world via the TCP/IP protocol.
MB Mega Bytes
ms Milliseconds.
sec Seconds
Smart Card Card without hardware which stores the user‘s private keys with
tamper proof software guard.
SRS Software Requirements Specification.
Tactile Special keyboard designed to aid the visually impaired.
keyboard
TCP/IP Transmission Control Protocol/Internet Protocol.
V Volts
VGA Video Graphics Adaptor is a display standard.
References
The references for the above software are as follows:-
i. www.google.co.in
ii. www.winkipedia.com
iii. IEEE. Software Requirements Specification Std. 830-1993.
iv. Chevy Chase Bank, UMBC Branch.
v. Russell C. Bjork Requirements Statement for Example ATM System. Online.
URL: http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/
Overview
Section 1.0 discusses the purpose and scope of the software.
Section 2.0 describes the overall functionalities and constraints of the software and
user characteristics.
Section 3.0 details all the requirements needed to design the software.
2. The Overall Description
Product Perspective
 The ATM is a single functional unit consisting of various sub-components.
 This software allows the user to access their bank accounts remotely through an
ATM without any aid of human bank teller.
 This software also allows the perform various other functions apart from just
accessing his bank account such as mobile bill clearings etc.
 Some of its hardware components are cassettes, memory, drives, dispensers i.e.for
receipts and cash, a card reader, printer, switches, a console, a telephone dialer port, a
networking port and disks.
 The ATM communicates with the bank‘s central server through a dial-up
communication link.
 The Memory of the system shall be 20MB.
 The Cassette capacity shall be at least 2000 notes.
Product Functions
The major functions that ATM Excl 3.0TM performs are described as follows:-
Language Selection:- After the user has logged in, the display provides him with a list of
languages from which he can select any one in order to interact with the machine
throughout that session. After the language selection the user is prompted with an option
that whether he wants the selected language to be fixed for future use so that he is not
offered with the language selection menu in future thus making the transaction a bit faster.
User also has the freedom to switch to a different language mentioned in the list in between
that session.
Account Maintenance:- The various functions that a user can perform with his
account are as follows:-
Account Type:-The user has the freedom to select his account type to which all the
transactions are made, i.e. he can select whether the account is current account or savings
account etc.
Withdrawal/Deposit: The software allows the user to select the kind of operation to be
performed i.e. whether he wants to withdraw or deposit the money.
Amount:- The amount to be withdrawan or deposited is then mentioned by the user.
Denominations:- The user is also provided with the facility to mention the required
denominations. Once he enters his requirements the machine goes through its calculations
on the basis of current resources to check whether it is possible or not. If yes, the amount is
given to the user otherwise other possible alternatives are displayed.
Money Deposition:- Money deposition shall be done with an envelope. After typing the
amount to be deposited and verification of the same, the customer must insert the envelope
in the depositor.
Balance Transfer:- Balance transfer shall be facilitated between any two accounts linked
to the card for example saving and checking account.
Balance Enquiry:- Balance enquiry for any account linked to the card shall be facilitated.
Billing:- Any transaction shall be recorded in the form of a receipt and the same would be
dispensed to the customer. The billing procedures are handled by the billing module that
enable user to choose whether he wants the printed statement of the transaction or just the
upgradation in his account.
Canceling:- The customer shall abort a transaction with the press of a Cancel key. For
example on entering a wrong depositing amount. In addition the user can also cancel the
entire session by pressing the abort key and can start a fresh session all over again.
Map locating other machines:- The machine also has a facility of displaying the map that
marks the locations of other ATM machines of the same bank in the entire city.
Mobile Bills Clearings:- The machine also allows the user to clear off his pending mobile
bills there only, if the name of his operator is mentioned there in the list. The machine
displays the list of the companies supported by that bank to the user.
User Characteristics
There are different kind of users that will be interacting with the system. The intended user
of the software are as follows:-
 User A: A novice ATM customer. This user has little or no experience with
electronic means of account management and is not a frequent user of the product.
 User A will find the product easy to use due to simple explanatory screens for each
ATM function. He is also assisted by an interactive teaching mechanism at every
step of the transaction, both with the help of visual and audio help sessions.
 User B: An experienced customer. This user has used an ATM on several
occasions before and does most of his account management through the ATM.
There is only a little help session that too at the beginning of the session thus
making the transaction procedure more faster.
Maintenance Personnel: A bank employee. This user is familiar with the functioning of
the ATM. This user is in charge of storing cash into the ATM vault and repairing the ATM
in case of malfunction. This user is presented with a different display when he logs in with
the administrator‘s password and is provided with options different from that of normal
user. He has the authority to change or restrict various features provided by the software in
situations of repairing.
Constraints
The major constraints that the project has are as follows:- ATM must service at
most one person at a time.
 The number of invalid pin entries attempted must not exceed three. After three
unsuccessful login attempts, the card is seized/blocked and need to be unlocked by
the bank.
 The simultaneous access to an account through both, the ATM and the bank is not
supported.
 The minimum amount of money a user can withdraw is Rs 100/- and the maximum
amount of money a user can withdraw in a session is Rs.10,000/- and the maximum
amount he can withdraw in a day is Rs 20,000/-
 Before the transaction is carried out, a check is performed by the machine to ensure
that a minimum amount of Rs 1000/- is left in the user‘s account after the
withdrawal failing which the withdrawal is denied.
 The minimum amount a user can deposit is Rs 100/- and the maximum amount he
can deposit is Rs 10,000/-.
 A user can select only that cellular operator for mobile bill clearings that is
supported by the bank.
 The software requires a minimum memory of 20GB
 The databse used should be Oracle7.0.
  There shall be a printer installed with the machine to provide the user with the
printed statement of the transaction.
 For voice interactions, speakers should also be there to accompany the machine.
Assumptions and Dependencies
The requirements stated in the SRS could be affected by the following factors:
 One major dependency that the project might face is the changes that need to be
incorporated with the changes in the bank policies regarding different services. As
the
 policies changes the system needs to be updated with the same immediately. A
delay in doing the same will result to tremendous loss to the bank. So this should be
changed as and when required by the developer.
 Another constraint relating to the operating environment is that we are specific to
Oracle Database.
 The project could be largely affected if some amount is withdrawn from the user‘s
account from the bank at the same time when someone is accessing that account
through the ATM machine. Such a condition shall be taken care of.
 At this stage no quantitive measures are imposed on the software in terms of speed
and memory although it is implied that all functions will be optimized with respect
to speed and memory.
It is furthermore assumed that the scope of the package will increase considerably in the
future.
3. External Interface Requirements
User Interface Requirements
The interface provided to the user should be a very user-friendly one and it should
provide an optional interactive help for each of the service listed. The interface provided is
a menu driven one and the following screens will be provided:-
1. A login screen is provided in the beginning for entering the required username/pin no.
and account number.
2. An unsuccessful login leads to a reattempt(maximum three) screen for again entering the
same information. The successful login leads to a screen displaying a list of supported
languages from which a user can select any one.
3. In case of administrator, a screen will be shown having options to reboot system, shut
down system, block system, disable any service.
4. In case of reboot/ shut down, a screen is displayed to confirm the user‘s will to reboot
and also allow the user to take any backup if needed.
5. In case of blocking system, a screen is provided asking for the card no. By entering the
card no of a particular user, system access can be blocked for him.
6. Administrator is also provided with a screen that enables him to block any service
provided to the user by enter in the name of the service or by selecting it from the list
displayed.
7. After the login, a screen with a number of options is then shown to the user. It contains
all the options along with their brief description to enable the user to understand their
functioning and select the proper option.
8. A screen will be provided for user to check his account balance.
9. A screen will be provided that displays the location of all other ATMs of same bank
elsewhere in the city.
10. A screen will be provided for the user to perform various transactions in his account.
The following reports will be generated after each session dealt with in the machine:-
1. The login time and logout time along with the user‘s pin no and account number
is registered in the bank‘s database.
2. The ATM‘s branch ID through which the session is established is also noted
down in the bank‘s database.
3. Various changes in the user‘s account after the transactions, if any, are reported
in the database.
4. A printed statement is generated for the user displaying all the transactions he
performed.
Other various user interface requirements that need to be fulfilled are as follows:-
 The display screen shall be of 10" VGA color type.
 The display screen shall have 256 color resolution.
 The display screen shall also support touchscreen facility.
 The speakers shall support Yamaha codecs.
 The keypad shall consist of 16 tactile keys.
 There shall be 8 tactile function keys.
 The keyboard will be weather resistant.
 The transaction receipt shall be 3.1" × 6".
 The statement receipt shall be 4.2" × 12".
  The deposit envelopes shall be 9" long and 4" wide.
Hardware Interface Requirements
There are various hardware components with which the machine is required to
interact. Various hardware interface requirements that need to be fulfilled for
successful functioning of the software are as follows:-
 The ATM power supply shall have a 10/220 V AC manual switch.
 The ATM card should have the following physical dimensions:- o Width -85.47mm-
85.72mm
 Height - 53.92mm-54.03mm
 Thickness - 0.76mm+0.08mm
 The card reader shall be a magnetic stripe reader
 The card reader shall have Smart card option.
The slot for a card in the card reader may include an extra indentation for the
embossed area of the card. In effect it acts as a polarization key and may be used to aid the
correct insertion orientation of the card. This is an additional characteristic to the magnetic
field sensor which operates off the magnetic stripe and is used to open a mechanical gate
on devices such as ATMs.
 There shall be a 40 column dot matrix receipt printer.
 There shall be a 40 column dot matrix statement printer.
 The receipt dispenser shall be a maximum of 4" width and 0.5" thickness.
 The statement dispenser shall be a maximum of 5" width and 0.5"thickness.
 The envelope depository shall be a maximum of 4.5" width, 10" length and 0.5"
thickness.
 Screen resolution of at least 800X600-required for proper and complete viewing of
screens. Higher resolution would not be a problem.
Software Interface Requirements
In order to perform various different functions, this software needs to interact with various
other software’s. So there are certain software interface requirements that need to be
fulfilled which are listed as follows:-
 The transaction management software used to manage the transaction and keep track
of resources shall be BMS version 2.0.
 The card management software used to verify pin no and login shall be CMS version
3.0.
 Yamaha codec’s 367/98 for active speakers.
 The database used to keep record of user accounts shall be Oracle version7.0.
Communication Interface Requirements
The machine needs to communicate with the main branch for each session for
various functions such as login verification, account access etc. so the following are the
various communication interface requirements that are needed to be fulfilled in order
to run the software successfully:-
 The system will employ dial-up POS with the central server for low cost
communication.
 The communication protocol used shall be TCP/IP.
 Protocol used for data transfer shall be File Transfer Protocol.(FTP)
4. System Features
1. Remote Banking and Account Management
Description
The system is designed to provide the user with the facility of remote banking and perform
various other functions at an interface without any aid of human bank teller. The
functioning of the system shall be as follows:-
At the start, the user is provided with a log in screen and he is required to enter his
PIN NO. and Account details which are then verified by the machine. In case of an
unsuccessful attempt a user is asked again for his credentials but the maximum
number of attempt given to the user is limited to 3 only, failing which his card is blocked
and need to be unblocked by the bank for any future use.
After a successful log in, the user is presented with a list of language. The user can
select any one in the list for interaction with the machine for the entire session.
After the language selection the user is also asked whether he wants to fix that language for
future use also so that he is never asked for language in future. In addition there is also a
facility for the user to switch to any other language during that session.
After the language selection, the user is directed towards a main page that displays
a set of options/services along with their brief description, enabling the user to understand
their functioning. The user can select any of the listed option and can continue with the
transaction.
The machine also provides the user with a number of miscellaneous services such
as:
 The machine lists a set of operators that are supported by the bank. A user can clear
off his pending mobile phone bills be selecting his operator.
The machine also has the facility to display a map that marks the location of other
ATMs of the same bank in the city. This may help the user to look for the ATM nearest to
his destination.
At any moment if the user wants to abort the transaction, he is provided with an
option to cancel it. Just by pressing the abort button he can cancel all the changes made so
far and can begin with a new transaction.
After the user is finished with his work, for security purpose, he is required to log
out and then take his card out of the slot.
Validity Checks
In order to gain access to the system, the user is required to enter his/her correct
user id/pin no and account no failing which his card may be blocked.
The user can access only one account at a time and can enter only one account no.
Also if the user is an administrator, he is required to enter his login id in order to
access and change the facilities provided by the system.
Sequencing Information
The information about the users and their account should be entered into the
database prior to any of the transactions and the backup be maintained for all account
information
Error Handling/ Response to Abnormal Situations
If any of the above validation/sequencing flow does not hold true, appropriate error
messages will be prompted to the user for doing the needful.
2. Receipt Generation
After each transaction user has performed, a receipt is generated that contains all
the information about the transaction. The format of the generated receipt is as shown
below:-
 KPM BANK
Branch name/Id
(address)
Login Time:- Date:-
Account No:-
User Name:-
TRANSACTIONS:
FROM TO TYPE AMOUNT

Logout Time:- BARCODE

Thank You For your visit.
See you soon.
5. Other Nonfunctional Requirements
Performance Requirements
The following list provides a brief summary of the performance requirements for the
software:
Capacity
 The ATM shall provide customers a 24 hour service.
Dynamic requirements
 The card verification time must not exceed 0.8 sec. under normal server workload
and 1 sec. under peak server workload.
 The pin number verification time must not exceed 0.3 sec. under normal server
workload and 0.5 sec. under peak server workload.
 Account balance display time must not exceed 2 sec. under normal server workload
and 3 sec. under peak server workload.
 Account balance transfer time must not exceed 3 sec. under normal server workload
and 4 sec. under peak server workload.
 Cash withdrawal transaction time must not exceed 4 sec. under normal server
workload and 5 sec. under peak server workload.
  Deposit transaction time after insertion of the deposit envelope must not exceed 5
sec. under normal server workload and 6 sec. under peak server workload.
 Receipt printing time after must not exceed 3 sec. under normal server and
 peak server workload.
 Touch screen and button response time must not exceed 5000ms.
 Credit card advance time must not exceed 6 sec. under normal traffic and server
and peak traffic and server workload.
Quality – The primary objective is to produce quality software. As the quality of a piece of
software is difficult to measure quantitatively, the following guidelines will be used when
judging the quality of the software:
1. Consistency – All code will be consistent with respect to the style. (This is
implied when adhering to the standard).
2. Test cases – All functionality will be thoroughly tested
Software System Attributes
Reliability
 The data communication protocol shall be such that it ensures reliability and quality
of data and voice transmission in a mobile environment. For example, CDMA.
 The memory system shall be of non-volatile type.
Availability
 The product will have a backup power supply incase of power failures.
 Any abnormal operations shall result in the shutting down of the system.
 After abnormal shutdown of the ATM, the system shall have to be manually
restarted by a maintenance personnel.
 There should be no inconsistency introduced in the account during whose
transaction the system is abnormally shut down.
Security
 The system shall be compatible with AIMS security standards.
 The system shall have two levels of security i.e. ATM card and pin verification
both authenticated by the CMS software.
 The Encryption standard used during pin transmission shall be triple DES.
 The password shall be 6-14 characters long.
 Passwords shall not contain name of customers as they are easy to be hacked.
 Passwords can contain digit, hyphen and underscore.
  User should be provided with only three attempts for login failing which his card
needs to be blocked.
 There shall be a security camera installed near the ATM.
 There shall be a secured cash vault with a combination locking system.
 The product cabinet cover shall be manufactured using Fiber glass for security
purposes.
Maintainability
 The system components i.e. modem, memory, disk, drives shall be easily
serviceable without requiring access to the vault.
 The system should have the mechanism of self-monitoring periodically in order to
detect any fault.
 The system should inform the main branch automatically as soon as it detects any
error. The kind of fault and the problem being encountered should also be
mentioned by the system automatically.
Business Rules
The business rules for the software are as follows:
 The Administrator has the authority to fix the rules and regulations and to set or
update the policies as and when required.
 The staff at the bank performs the following:
a. Making the entries in the system regarding all the details of the bank account of the
user.
b. Keeping the bank account of the user updated as soon as changes are encountered
so that the data is in consistent state.
c. Blocking or seizing of the account of user on discovery of any illegal transaction.
d. Unblocking of ATM card that got blocked due to more than three unsuccessful
login attempt.
e. Blocking of a lost/stolen ATM card on complaint of the user, only if he presents his
verification and a FIR filed for that case.
f. Costantly monitor all the ATMs in the city to check whether any one of them is
encountering any fault.
g. Immediately correct any fault discovered in any of the ATM.
h. Maintain the backup of all the accounts for reliability purposes.
 i. Rollback all the changes made in an account during whose transaction an ATM got
abnormal shutdown.
 In case of loss of the ATM card. The user has to lodge a First Investigation
Report(FIR) and present its one copy to bank officials for card blocking purposes.
 A log of the following annexures is generated by the system:
 User bank account details.
 Updations made in the user account along with date, time and the changes made.
 Schedule of fixed assets.
6 Other Requirements None.
Appendix A: Glossary
AimS - ATM Information Management System.
ATM - An unattended electronic machine in a public place, connected to a data system and
related equipment and activated by a bank customer to obtain ash withdrawals and
other banking services
Braille- A system of writing and printing for blind or visually impaired people, in which
varied arrangements of raised dots representing letters and numerals are
identified by touch.
CDMA - Code Division Multiple Access, a reliable data communication protocol.
CMS - Card Management Software developed by KPM Bank.
Dial-Up - A message format for low cost communications.
POS Internet - An interconnected system of networks that connects computers around the
world via the TCP/IP protocol.
Smart Card - Card without hardware which stores the user‘s private keys within a tamper
proof software guard.
Tactile- Special keyboard designed to aid the visually impaired.
Keyboard
TCP/IP - Transmission Control Protocol/Internet Protocol.

Result:
The preparation broad of SRS (Software Requirement Specification) for the ATM
machine projects has been prepared successfully.
EX.NO:4 USE CASE DIAGRAMS
DATE:

Aim:
To draw the Use Case Diagram using Rational Rose.
Theory:
According to the UML specification a use case diagram is ―a diagram that shows
the relationships among actors and use cases within a system.
Use case diagrams are often used to:
 Provide an overview of all or part of the usage requirements for a system or
organization in the form of an essential model or a business model
 Communicate the scope of a development project
 Model your analysis of your usage requirements in the form of a system use case
model Use case models should be developed from the point of view of your project
stakeholders and not from the (often technical) point of view of developers.
There are guidelines for:
Use Cases
Actors
Relationships
System Boundary Boxes
1. Use Cases
A use case describes a sequence of actions that provide a measurable value to an
actor. A use case is drawn as a horizontal ellipse on a UML use case diagram.
1. Use Case Names Begin With a Strong Verb
2. Name Use Cases Using Domain Terminology
3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram
4. Imply Timing Considerations By Stacking Use Cases.
2. Actors
An actor is a person, organization, or external system that plays a role in one or
more interactions with your system (actors are typically drawn as stick figures on UML
Use Case diagrams).
1. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram
 2. Draw Actors To The Outside Of A Use Case Diagram
3. Name Actors With Singular, Business-Relevant Nouns
4. Associate Each Actor With One Or More Use Cases
5. Actors Model Roles, Not Positions
6. Use <<system>> to Indicate System Actors
7. Actors Don‘t Interact With One Another
8. Introduce an Actor Called ―Time‖ to Initiate Scheduled Events
3. Relationships
There are several types of relationships that may appear on a use case diagram:
 An association between an actor and a use case
 An association between two use cases
 A generalization between two actors
 A generalization between two use cases
Associations are depicted as lines connecting two modeling elements with an
optional open headed arrowhead on one end of the line indicating the direction of the initial
invocation of the relationship. Generalizations are depicted as a close-headed arrow with
the arrow pointing towards the more general modeling element.
1. Indicate An Association Between An Actor And A Use Case If The Actor
Appears within The Use Case Logic
2. Avoid Arrowheads On Actor-Use Case Relationships
3. Apply <<include>> When You Know Exactly When To Invoke The Use Case
4. Apply <<extend>> When A Use Case May Be Invoked Across Several Use Case
Steps
5. Introduce <<extend>> associations sparingly
6. Generalize Use Cases When a Single Condition Results In Significantly New
Business Logic
7. Do Not Apply <<uses>>, <<includes>>, or <<extends>>
8. Avoid More Than Two Levels Of Use Case Associations
9. Place An Included Use Case To The Right Of The Invoking Use Case
10. Place An Extending Use Case Below The Parent Use Case
11. Apply the ―Is Like‖ Rule to Use Case Generalization
12. Place an Inheriting Use Case Below The Base Use Case
13. Apply the ―Is Like‖ Rule to Actor Inheritance
 14. Place an Inheriting Actor Below the Parent Actor
4. System Boundary Boxes
The rectangle around the use cases is called the system boundary box and as the
name suggests it indicates the scope of your system – the use cases inside the rectangle
represent the functionality that you intend to implement.
1. Indicate Release Scope with a System Boundary Box.
2. Avoid Meaningless System Boundary Boxes.
Creating Use Case Diagrams
We start by identifying as many actors as possible. You should ask how the actors
interact with the system to identify an initial set of use cases. Then, on the diagram, you
connect the actors with the use cases with which they are involved. If actor supplies
information, initiates the use case, or receives any information as a result of the use case,
then there should be an association between them.
Procedure (for rational rose):
1. Click on the File menu and select New.

2. Now from the Dialogue Box that appears ,select the language which you want to use
for creating your model.
3. In the left hand side window of Rational Rose right click on ―Use Case view‖ and
select New>Use Case Diagram.

4. Enter the name of new Use Case file in the space provided,and then click on that file
name.
5. You can now use the window that appears on right hand side to draw your Use Case
diagram using the buttons provided on the vertical toolbar.
1. use case diagram for Bank ATM subsystem

Bank ATM Transactions and Customer Authentication Use Cases

Bank ATM Maintenance, Repair, Diagnostics Use Cases

Result:
The use case diagram was made successfully by following the steps described
above.
EX.NO:5 ACTIVITY DIAGRAM
DATE:

Aim:
To draw a sample activity diagram for real project or system.
Theory
UML 2 activity diagrams are typically used for business process modeling, for
modeling the logic captured by a single use case or usage scenario, or for modeling the
detailed logic of a business rule. Although UML activity diagrams could potentially model
the internal logic of a complex operation it would be far better to simply rewrite the
operation so that it is simple enough that you don‘t require an activity diagram. In many
ways UML activity diagrams are the
object-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured
development.
Let‘s start by describing the basic notation :
 Initial node. The filled in circle is the starting point of the diagram. An initial node
isn‘t required although it does make it significantly easier to read the diagram.
 Activity final node. The filled circle with a border is the ending point. An activity
 diagram can have zero or more activity final nodes.
 Activity. The rounded rectangles represent activities that occur. An activity may be
 physical, such as Inspect Forms, or electronic, such as Display Create Student
Screen.
 Flow/edge. The arrows on the diagram. Although there is a subtle difference
between flows and edges, never a practical purpose for the difference although.
 Fork. A black bar with one flow going into it and several leaving it. This denotes
the beginning of parallel activity.
1. Join. A black bar with several flows entering it and one leaving it. All flows
going into the join must reach it before processing may continue. This denotes
the end of parallel processing.
2. Condition. Text such as [Incorrect Form] on a flow, defining a guard which
must evaluate to true in order to traverse the node.
 3. Decision. A diamond with one flow entering and several leaving. The flows
leaving include conditions although some modelers will not indicate the
conditions if it is obvious.
4. Merge. A diamond with several flows entering and one leaving. The
implication is that one or more incoming flows must reach this point until
processing continues, based on any guards on the outgoing flow.
5. Partition. If figure is organized into three partitions, it is also called swimlanes,
indicating who/what is performing the activities (either the Applicant, Registrar,
or System).
6. Sub-activity indicator. The rake in the bottom corner of an activity, such as in
the Apply to University activity, indicates that the activity is described by a
more finely detailed activity diagram.
7. Flow final. The circle with the X through it. This indicates that the process
stops at this point.
GUIDELINES ASSOCIATED FOR DRAWING AN ACTIVITY DIAGRAM
1.General Guidelines
2.Activities
3.Decision Points
4.Guards
5.Parallel Activities
6.Swimlane Guidelines
7.Action-Object Guidelines
1. General Guidelines
Figure1. Modeling a business process with a UML Activity Diagram
 1. Place The Start Point In The Top-Left Corner. A start point is modeled with a
filled in circle, using the same notation that UML State Chart diagrams use. Every UML
Activity Diagram should have a starting point, and placing it in the top-left corner reflects
the way that people in Western cultures begin reading. Figure1, which models the business
process of enrolling in a university, takes this approach.
2. Always Include an Ending Point. An ending point is modeled with a filled in
circle with a border around it, using the same notation that UML State Chart diagrams use.
Figure1 is interesting because it does not include an end point because it describes a
continuous process – sometimes the guidelines don‘t apply.
3. Flow charting Operations Implies the Need to Simplify. A good rule of thumb is
that if an operation is so complex you need to develop a UML Activity diagram to
understand it that you should consider refactoring it.
2. Activities
An activity, also known as an activity state, on a UML Activity diagram typically
represents the invocation of an operation, a step in a business process, or an entire business
process.
1. Question ―Black Hole‖ Activities. A black hole activity is one that has
transitions into it but none out, typically indicating that you have either missed one or more
transitions.
2. Question ―Miracle‖ Activities. A miracle activity is one that has transitions out
of it but
none into it, something that should be true only of start points.
3. Decision Points
A decision point is modeled as a diamond on a UML Activity diagram.
1. Decision Points Should Reflect the Previous Activity. In figure1 we see that there
is no
label on the decision point, unlike traditional flowcharts which would include text
describing the actual decision being made, we need to imply that the decision concerns
whether the person was enrolled in the university based on the activity that the decision
point follows. The guards, depicted using the format [description], on the transitions
leaving the decision point also help to describe the decision point.
2. Avoid Superfluous Decision Points. The Fill Out Enrollment Forms activity in
FIGURE1 includes an implied decision point, a check to see that the forms are filled out
properly, which simplified the diagram by avoiding an additional diamond.
4. Guards
A guard is a condition that must be true in order to traverse a transition.
1. Each Transition Leaving a Decision Point Must Have a Guard
2. Guards Should Not Overlap. For example guards such as x <0, x = 0, and x > 0
are consistent whereas guard such as x <= 0 and x >= 0 are not consistent because they
overlap – it isn‘t clear what should happen when x is 0.
3. Guards on Decision Points Must Form a Complete Set. For example, guards such
as x < 0 and x >0 are not complete because it isn‘t clear what happens when x is 0.
4. Exit Transition Guards and Activity Invariants Must Form a Complete Set. An
activity invariant is a condition that is always true when your system is processing an
activity.
5. Apply a [Otherwise] Guard for ―Fall Through‖ Logic.
6. Guards Are Optional. It is very common for a transition to not include a guard,
even when an activity includes several exit transitions.
5. Parallel Activities
It is possible to show that activities can occur in parallel, as you see in FIGURE 1
depicted using two parallel bars. The first bar is called a fork, it has one transition entering
it and two or more transitions leaving it. The second bar is a join, with two or more
transitions entering it and only one leaving it.
1. A Fork Should Have a Corresponding Join. In general, for every start (fork)
there is an end (join). In UML 2 it is not required to have a join, but it usually makes sense.
2. Forks Have One Entry Transition.
3. Joins Have One Exit Transition
4. Avoid Superfluous Forks. FIGURE 2 depicts a simplified description of the
software process of enterprise architectural modeling, a part of the Enterprise Unified
Process (EUP). There is significant opportunity for parallelism in this process, in fact all of
these activities could happen in parallel, but forks were not introduced because they would
only have cluttered the diagram.
6. Swimlane Guidelines
A swimlane is a way to group activities performed by the same actor on an activity
diagram or to group activities in a single thread. FIGURE 2 includes three swimlanes, one
for each actor.
Figure2. A UML activity diagram for the enterprise architectural modeling
(simplified).
Figure 3. Submitting expenses.

1. Order Swimlanes in a Logical Manner.

2. Apply Swim Lanes To Linear Processes. A good rule of thumb is that swimlanes
are best applied to linear processes, unlike the one depicted in FIGURE 3.
3. Have Less Than Five Swimlanes.
4. Consider Swimareas For Complex Diagrams.
5. Swimareas Suggest The Need to Reorganize Into Smaller Activity Diagrams.
6. Consider Horizontal Swimlanes for Business Processes. In FIGURE 3 you see
that the swimlanes are drawn horizontally, going against common convention of drawing
them vertically.
7 Action-Object Guidelines
Activities act on objects, In the strict object-oriented sense of the term an action
object is a system object, a software construct. In the looser, and much more useful for
business application modeling, sense of the term an action object is any sort of item. For
example in FIGURE 3 the ExpenseForm action object is likely a paper form.
1. Place Shared Action Objects on Swimlane Separators
2. When An Object Appears Several Time Apply State Names
3. State Names Should Reflect the Lifecycle Stage of an Action Object
4. Show Only Critical Inputs and Outputs
5. Depict Action Objects As Smaller Than Activities
UML Activity Diagram Example: ATM

Result:
The activity diagram was made successfully by following the steps described above.
EX.NO:6 DFD DECISION TABLE & ER DIAGRAM
DATE:

Aim:
To draw a sample ENTITY RELATIONSHIP DIAGRAM diagram for real
project or system.
Theory
Entity Relationship Diagrams are a major data modelling tool and will help
organize the data in your project into entities and define the relationships between the
entities. This process has proved to enable the analyst to produce a good database structure
so that the data can be stored and retrieved in a most efficient manner.
Entity
A data entity is anything real or abstract about which we want to store data. Entity
types fall into five classes: roles, events, locations, tangible things or concepts. E.g.
employee, payment, campus, book. Specific examples of an entity are called instances. E.g.
the employee John Jones, Mary Smith's payment, etc.
Relationship
A data relationship is a natural association that exists between one or more entities.
E.g. Employees process payments. Cardinality defines the number of occurrences of one
entity for single occurrence of the related entity. E.g. an employee may process many
payments but might not process any payments depending on the nature of her job.
Attribute
A data attribute is a characteristic common to all or most instances of a particular
entity. Synonyms include property, data element, field. E.g. Name, address, Employee
Number, pay rate are all attributes of the entity employee. An attribute or combination of
attributes that uniquely identifies one and only one instance of an entity is called a
primary key or identifier. E.g. Employee Number is a primary key for Employee.
AN ENTITY RELATIONSHIP DIAGRAM METHODOLOGY: (One way of doing it)
1. Identify Entities Identify the roles, events, locations, tangible things or conc
about which the end-users want to store data.
2. Find Relationships Find the natural associations between pairs of entities usin
relationship matrix.
3. Draw Rough ERD Put entities in rectangles and relationships on line segm
 connecting the entities.

4. Fill in Cardinality Determine the number of occurrences of one entity for a si

occurrence of the related entity. data?
5. Define Primary Keys Identify the data attribute(s) that uniquely identify one and only
occurrence of each entity.
6. Draw Key-Based ERD Eliminate Many-to-Many relationships and include primary
foreign keys in each entity.
7. Identify Attributes Name the information details (fields) which are essential to
system under development.
8. Map Attributes For each attribute, match it with exactly one entity that it describ
9. Draw fully attributed ERD Adjust the ERD from step 6 to account for entities or relations
discovered in step 8.
10. Check Results Does the final Entity Relationship Diagram accurately depict
system data?
A SIMPLE EXAMPLE
A company has several departments. Each department has a supervisor and at least
one employee. Employees must be assigned to at least one, but possibly more departments.
At least one employee is assigned to a project, but an employee may be on vacation and not
assigned to any projects. The important data fields are the names of the departments,
projects, supervisors and employees, as well as the supervisor and employee number and a
unique project number.
1. Identify Entities
The entities in this system are Department, Employee, Supervisor and Project. One
is tempted to make Company an entity, but it is a false entity because it has only one
instance in this problem. True entities must have more than one instance.
2. Find Relationships
We construct the following Entity Relationship Matrix:
Department Employee Supervisor Project
Department is assigned run by
Employee belongs to works on
Supervisor runs
Project uses
3. Draw Rough ERD
We connect the entities whenever a relationship is shown in the entity Relationship
Matrix.

4. Fill in Cardinality
From the description of the problem we see that:
 Each department has exactly one supervisor.
 A supervisor is in charge of one and only one department.
 Each department is assigned at least one employee.
 Each employee works for at least one department.
 Each project has at least one employee working on it.
 An employee is assigned to 0 or more projects.

5. Define Primary Keys

The primary keys are Department Name, Supervisor Number, Employee Number,
Project Number.
6. Draw Key-Based ERD
There are two many-to-many relationships in the rough ERD above, between
Department and Employee and between Employee and Project. Thus we need the
associative entities Department-Employee and Employee-Project. The primary key for
Department-Employee is the concatenated key Department Name and Employee Number.
The primary key for Employee Project is the concatenated key Employee Number and
Project Number.
7. Identify Attributes
The only attributes indicated are the names of the departments, projects, supervisors
and employees, as well as the supervisor and employee NUMBER and a unique project
number.
8. Map Attributes
Attribute Entity Attribute Entity
Department Name Department Supervisor Name Supervisor
Employee Number Employee Supervisor Name Supervisor
Employee Name Employee Project Name Project
Project Number Project

9. Draw Fully Attributed ERD

10. Check Results

The final ERD appears to model the data in this system well.
FURTHER DISCUSSION:
Step 1. Identify Entities
A data entity is anything real or abstract about which we want to store data. Entity
types fall into five classes: roles, events, locations, tangible things, or concepts. The best
way to identify entities is to ask the system owners and users to identify things about which
they would like to capture, store and produce information. Another source for identifying
entities is to study the forms, files, and reports generated by the current system. E.g. a
student registration form would refer to Student (a role), but also Course (an event),
Instructor (a role), Advisor (a role), Room (a location), etc.
Step 2. Find Relationships
There are natural associations between pairs of entities. Listing the entities down
the left column and across the top of a table, we can form a relationship matrix by filling in
an active verb at the intersection of two entities which are related. Each row and column
should have at least one relationship listed or else the entity associated with that row or
column does not interact with the rest of the system. In this case, you should question
whether it makes sense to include that entity in the system. . A student is enrolled in one or
more courses subject verb objects
Step 3. Draw Rough ERD
Using rectangles for entities and lines for relationships, we can draw an Entity
Relationship Diagram (ERD).
Step 4. Fill in Cardinality
At each end of each connector joining rectangles, we need to place a symbol
indicating the minimum and maximum number of instances of the adjacent rectangle there
are for one instance of the rectangle at the other end of the relationship line. The placement
of these numbers is often confusing. The first symbol is either 0 to indicate that it is
possible for no instances of the entity joining the connector to be related to a given instance
of the entity on the other side of the relationship, 1 if at least one instance is necessary or it
is omitted if more than one instance is required. For example, more than one student must
be enrolled in a course for it to run, but it is possible for no students to have a particular
instructor (if they are on leave).
The second symbol gives the maximum number of instances of the entity joining
the connector for each instance of the entity on the other side of the relationship. If there is
only one such instance, this symbol is 1. If more than 1, the symbol is a crows foot opening
towards the rectangle.
 If you read it like a sentence, the first entity is the subject, the relationship is the
verb, the cardinality after the relationship tells how many direct objects (second entity)
there are.
I.e. A student is enrolled in one or more courses subject verb objects
Step5. Define Primary Keys
For each entity we must find a unique primary key so that instances of that entity
can be distinguished from one another. Often a single field or property is a primary key
(e.g. a Student ID). Other times the identifier is a set of fields or attributes (e.g. a course
needs a department identifier, a course number, and often a section number; a Room needs
a Building Name and a Room Number). When the entity is written with all its attributes,
the primary key is underlined.
Step 6. Draw Key-Based ERD
Looking at the Rough Draft ERD, we may see some relationships which are non-
specific or many-to-many. I.e., there are crows feet on both ends of the relationship line.
Such relationships spell trouble later when we try to implement the related entities as data
stores or data files, since each record will need an indefinite number of fields to maintain
the many-to-many relationship. Fortunately, by introducing an extra entity, called an
associative entity for each many-to-many relationship, we can solve this problem. The new
associative entity's name will be the hyphenation of the names of the two originating
entities. It will have a concatenated key consisting of the keys of these two entities. It will
have a 1-1 relationship with each of its parent entities and each parent will have the same
relationship with the associative entity that they had with each other before we introduced
the associative entity. The original relationship between the parents will be deleted from
the diagram.
The key-based ERD has no many-to-many relationships and each entity has its
primary and foreign keys listed below the entity name in its rectangle.
Step 7. Identify Attributes
A data attribute is a characteristic common to all or most instances of a particular
entity. In this step we try to identify and name all the attributes essential to the system we
are studying without trying to match them to particular entities. The best way to do this is
to study the forms, files and reports currently kept by the users of the system and circle
each data item on the paper copy. Cross out those which will not be transferred to the new
system, extraneous items such as signatures, and constant information which is the same
for all instances of the form (e.g. your company name and address). The remaining circled
items should represent the attributes you need. You should always verify these with your
system users. (Sometimes forms or reports are out of date.)
Step 8. Map Attributes
For each attribute we need to match it with exactly one entity. Often it seems like
an attribute should go with more than one entity (e.g. Name). In this case you need to add a
modifier to the attribute name to make it unique (e.g. Customer Name, Employee Name,
etc.) or determine which entity an attribute "best' describes. If you have attributes left over
without corresponding entities, you may have missed an entity and its corresponding
relationships. Identify these missed entities and add them to the relationship matrix now.
Step 9. Draw Fully-Attributed ERD
If you introduced new entities and attributes in step 8, you need to redraw the entity
relationship diagram. When you do so, try to rearrange it so no lines cross by putting the
entities with the most relationships in the middle. If you use a tool like Systems Architect,
redrawing the diagram is relatively easy. Even if you have no new entities to add to the
Key-Based ERD, you still need to add the attributes to the Non-Key Data section of each
rectangle. Adding these attributes automatically puts them in the repository, so when we
use the entity to design the new system, all its attributes will be available.
Step 10. Check Results
Look at your diagram from the point of view of a system owner or user. Is
everything clear? Check through the Cardinality pairs. Also, look over the list of attributes
associated with each entity to see if anything has been omitted.

Result:
The entity relationship diagram was made successfully by following the steps
described above.
EX.NO:7(a) CLASS DIAGRAM
DATE:

Aim:
To draw the class diagram for ATM system.
Theory:
A class diagram is a type of static structure diagram that describes the structure
of a system by showing the system's classes, their attributes, and the relationships between
the classes.
Class diagrams show the classes of the system, their inter-relationships, and the operations
and attributes of the classes. Class diagrams are typically used, although not all at once, to:
 Explore domain concepts in the form of a domain model
 Analyze requirements in the form of a conceptual/analysis model
 Depict the detailed design of object-oriented or object-based software
A class model is comprised of one or more class diagrams and the supporting
specifications that describe model elements including classes, relationships between classes,
and interfaces. There are guidelines
1. General issues
2. Classes
3. Interfaces
4. Relationships
5. Inheritance
6. Aggregation and Composition
GENERAL GUIDELINES
Because class diagrams are used for a variety of purposes – from understanding
requirements to describing your detailed design – it is needed to apply a different style in
each circumstance. This section describes style guidelines pertaining to different types of
class diagrams.
CLASSES
A class in the software system is represented by a box with the name of the class
written inside it. A compartment below the class name can show the class's attributes (i.e.
its properties). Each attribute is shown with at least its name, and optionally with its type,
initial value, and other properties. A class is effectively a template from which objects are
created (instantiated). Classes define attributes, information that is pertinent to their
instances, and operations, functionality that the objects support. Classes will also realize
interfaces (more on this later). Class diagrams are widely used to describe the types of
objects in a system and their relationships. Class diagrams model class structure and
contents using design elements such as classes, packages and objects. Class diagrams
describe three different perspectives when designing a system, conceptual, specification,
and implementation. These perspectives become evident as the diagram is created and help
solidify the design.
INTERFACES
An interface is a collection of operation signature and/or attributes definitions that
ideally define a cohesive set of behaviors. Interface a class or component must implement
the operations and attributes defined by the interface. Any given class or component may
implement zero or more interfaces and one or more classes or components can implement
the same interface.
RELATIONSHIPS
A relationship is a general term covering the specific types of logical connections
found on a class and object diagram. Class diagrams also display relationships such as
containment, inheritance, associations and others. The association relationship is the most
common relationship in a class diagram. The association shows the relationship between
instances of classes. Another common relationship in class diagrams is a generalization. A
generalization is used when two classes are similar, but have some differences.
AGGREGATION
Aggregation is a variant of the "has a" or association relationship; composition is

more specific than aggregation.

Aggregation occurs when a class is a collection or container of other classes, but
where the contained classes do not have a strong life cycle dependency on the container--
essentially, if the container is destroyed, its contents are not.
ASSOCIATION

Association are semantic connection between classes. When an association

connects two classes , each class can send messages to other in a sequence or a
collaboration diagram . Associations can be bidirectional or unidirectional.
DEPENDENCIES

Dependencies connect two class . Dependencies are always unidirectional and show that
one class, depends on the definitions in another class.
GENERALIZATION
The generalization relationship indicates that one of the two related classes (the
supertype) is considered to be a more general form of the other (the subtype). In practice,
this means that any instance of the subtype is also an instance of the supertype . The
generalization relationship is also known as the inheritance or "is a" relationship. The
supertype in the generalization relationship is also known as the "parent", superclass, base
class, or base type. The subtype in the generalization relationship is also known as the
"child", subclass, derived class, derived type, inheriting class, or inheriting type.
MULTIPLICITY
The association relationship indicates that (at least) one of the two related classes
makes reference to the other.
HOW TO DRAW CLASS DIAGRAM
When designing classes the attributes and operations it will have are observed.
Then determining how instances of the classes will interact with each other. These are the
very first steps of many in developing a class diagram. However, using just these basic
techniques one can develop a complete view of the software system. There are various
steps in the analysis and design of an object oriented system.

STEPS FOR DRAWING CLASS DIAGRAM

1. After completing the sequence diagrams and collaboration diagram which are a part of
the interaction diagrams. In Rational Rose, right click on the ―Use Case View‖ and select
new class diagram.

2. Enter the class name (here ―Hostel Class‖).

3. Click the cursor on the block representing class from the table of predefined symbols
into the screen
4. Select a new Class

1. Double click on the class formed to enter the class name in the general field .
2. In the operation field right click and select the inset option to add class operations or
functions.

3. Input the name of the new operation , its return type in the respective columns.
7. In the attribute field, enter the attribute names , their type and the parent class in the
respective columns.

8. Enter all the attributes and operations , and press ―OK‖ button to get the required class.
9. While building the classes of the system if you want to make nested class in some main
class(here ―LOGIN‖ class), then insert classes in the ‗Nested‘ field of class
specification(like the ―EDIT_RECORD‖ class)
10. Select the nested class and drag it to the Class diagram window

11. All the required classes were built completely with there operations, attributes and
nested classes , into the class diagram
12. Now we want to show the relationships between the various classes. To show an
ASSOCIATION relation select a block named ‗association‘ from the blocks to the left and
draw the arrows between the requisite classes.

13. To show a GENERALIZATION or inheritance relation select a block named

‗generalization‘ from the blocks to the left and draw the arrows between the requisite
classes.
14. Select the ‗text box‘ block from the blocks field to describe any relation with the help
of text.

15. Enter text by placing text boxes over the various relationship arrows
Result:
Thus the class diagram for ATM system has been implemented successfully.
EX.NO:7(b) SEQUENC DIAGRAM
DATE:

Aim:
To draw the UML sequence diagram for ATM system.
Theory:
UML sequence diagrams model the flow of logic within the system in a visual
manner, enabling the user both to document and validate the logic, and are commonly used
for both analysis and design purposes. Sequence diagrams are the most popular UML
artifact for dynamic modeling, which focuses on identifying the behavior within your
system. Sequence diagrams, along with class diagrams and physical data models are the
most important design-level models for modern application development.
Sequence diagrams are typically used to model:
1. Usage scenarios. A usage scenario is a description of a potential way the system is used.
The logic of a usage scenario may be part of a use case, perhaps an alternate course. It may
also be one entire pass through a use case, such as the logic described by the basic course
of action or a portion of the basic course of action, plus one or more alternate scenarios.
The logic of a usage scenario may also be a pass through the logic contained in several use
cases. For example, a student enrolls in the university, and then immediately enrolls in
three seminars.
2. The logic of methods. Sequence diagrams can be used to explore the logic of a complex
operation, function, or procedure. One way to think of sequence diagrams, particularly
highly detailed diagrams, is as visual object code.
3. The logic of services. A service is effectively a high-level method, often one that can be
invoked by a wide variety of clients. This includes web-services as well as business
transactions implemented by a variety of technologies such as CICS/COBOL or CORBA-
compliant object request brokers (ORBs).
FIG 3.shows the logic for how to enroll in a seminar. One should often develop a system-
level sequence diagram to help both visualize and validate the logic of a usage scenario. It
also helps to identify significant methods/services, such as checking to see if the applicant
already exists as a student, which the system must support.
Figure 3. Enrolling in a seminar (method).
 The dashed lines hanging from the boxes are called object lifelines, representing the
life span of the object during the scenario being modeled. The long, thin boxes on the
lifelines are activation boxes, also called method-invocation boxes, which indicate
processing is being performed by the target object/class to fulfill a message.
How to Draw Sequence Diagrams
Sequence diagramming really is visual coding, even when you are modeling a
usage scenario via a system-level sequence diagram.
While creating a sequence diagram ,start by identifying the scope of what you are
trying to model.You should typically tackle small usage scenarios at the system level or a
single method/service at the detailed object level.
You should then work through the logic with at least one more person, laying out
classifiers across the top as you need them. . The heart of the diagram is in the messages,
which you add to the diagram one at a time as you work through the logic. You should
rarely indicate return values, instead you should give messages intelligent names which
often make it clear what is being returned.
It is interesting to note that as you sequence diagram you will identify new
responsibilities for classes and objects, and, sometimes, even new classes. The implication
is that you may want to update your class model appropriately, agile modelers will follow
the practice Create Several Models in Parallel, something that CASE tools will do
automatically. Remember, each message sent to a class invokes a static method/operation
on that class each message sent to an object invokes an operation on that object.
Regarding style issues for sequence diagramming, prefer drawing messages going
from left-to-right and return values from right-to-left, although that doesn‘t always work
with complex objects/classes. Justify the label on messages and return values, so they are
closest to the arrowhead. Also prefer to layer the sequence diagrams: from left-to-right.
indicate the actors, then the controller class(es), and then the user interface class(es), and,
finally, the business class(es). During design, you probably need to add system and
persistence classes, which you should usually put on the right-most side of sequence
diagrams. Laying your sequence diagrams in this manner often makes them easier to read
and also makes it easier to find layering logic problems, such as user interface classes
directly accessing persistence.
Procedure

Now from the Dialogue Box that appears ,select the language which you want to use for
creating your model.
In the left hand side window of Rational Rose right click on ―Use Case view‖ and select
New>Sequence Diagram

Enter the name of new Sequence file in the space provided,and then click on that file name.

You can now use the window that appears on right hand side to draw your Sequence
diagram using the buttons provided on the vertical toolbar.
Sequence diagram for withdrawing amount from ATM.

Result:
The sequence diagram was made successfully by following the steps described
above.
EX.NO:7(c) COLLABORATION DIAGRAM
DATE:

Aim:
To draw the collaboration diagram for ATM system.
Theory:
Collaboration diagrams are also relatively easy to draw. They show the relationship
between objects and the order of messages passed between them. The objects are listed as
icons and arrows indicate the messages being passed between them. The numbers next to
the messages are called sequence numbers. As the name suggests, they show the sequence
of the messages as they are passed between the objects. There are many acceptable
sequence numbering schemes in UML. A simple 1, 2, 3... format can be used, as the
example below shows, or for more detailed and complex diagrams a 1, 1.1 ,1.2, 1.2.1...
scheme can be used.
Check Balance communication diagram:

Here is an example of the Deposit Cash communication diagram:

For behavior: State, Activity Diagram
State Diagram:- State transition diagrams provide a way to model the various states in
which an object can exist. While the class diagram show a static picture of the classes and
their relationships, state transition diagrams model the dynamic behavior of a systen in
response to extermal events (stimuli). State transition diagrams consist of the following:
1. States , which show the possible situations in which an object can find itself
2. Transitions , which show the different events which cause a change in the state of
an object.
Here, is an example of the state diagram for the session of ATM.

Activity Diagram:- Activity diagrams describe the activities of a class. They are similar to
state transition diagrams and use similar conventions, but activity diagrams describe the
behavior/states of a class in response to internal processing rather than external events.
They contain the following elements:
1. Swimlanes , which delegate specific actions to objects within an overall activity
2. Action States , which represent uninterruptible actions of entities, or steps in the
execution of an algorithm
3. Action Flows , which represent relationships between the different action states on an
entity
4. Object Flows , which represent utilization of objects by action states, or influence of
action states on objects.
Following are the examples of Login, Withdraw Activity Diagrams.
Result:
Thus the implementation of collaboration diagram for ATM system has been
created successfully.
EX.NO:7(d) STATE TRANSITION DIAGRAM
DATE:

Aim:
To use state transition diagram for ATM system
Theory:
de a way to model the various states in which an object can
exist.

The Start state is represented by a block dot.

The Stop state is represented by a bull’s eye.
in square brackets is called a guard condition, and controls when
a transition can or cannot occur.
Process that occur while an object is in certain state are called actions.
STEPS TO DRAW STATE CHART DIAGRAM IN RATIONAL ROSE
SOFTWARE
state diagram secondary click on Logical View.
Select---New --- State chart Diagram.

e “START STATE” button.

state button. Place the instances for each state into the diagram and type in names for them.

make the easiest layout to work with.

“END STATE” button. Place an
instance into the diagram. Now add relationships to the diagram.
“STATE TRANSITION” button and drag arrows between the
appropriate states.
“OPEN
SPECIFICATION” button. Add a name for the event in the specification. Then click on
―apply‖ and then on ―OK‖ button.
this case add a relationship in the same way. Then enter the specification for the new state.

A STATE CHART DIAGRAM FOR THE SESSION OF ATM.

Result:
The state chart diagram was made successfully by following the steps described
above.
EX.NO:8 TEST CASE
DATE:

Aim:
To write Test Cases to validate requirements of ATM project from SRS Document.
Given below are the various test cases for ATM.
1. Verify if the card reader is working correctly. A screen should ask you to insert the
pin after inserting the valid card.
2. Verify if the cash dispenser is working as expected.
3. Verify if the receipt printer is working correctly. Which means it can print the data
on the paper and the paper comes out properly.
4. Verify if the Screen buttons are working correctly. For touch screen: Verify if it is
operational and working as per the expectations.
5. Verify if the text on the screen button is visible clearly.
6. Verify the font of the text on the screen buttons.
7. Verify each number button on the Keypad.
8. Verify the functionality of the Cancel button on the Keypad.
9. Verify the text color of the keypad buttons. The numbers should be visible clearly.
10. Verify the text color and font of the data on the screen. The user should be able to
read it clearly.
11. Verify the language selection option. If the messages or data are displayed in the
selected language.
12. Insert the card, the correct pin, and print the receipt for available balance.
13. Verify the receipt printing functionality after a valid transaction. Whether the
printed data is correct or not.
14. Verify how much time the system takes to log out.
15. Verify the timeout session functionality.
16. Verify the deposit slot functionality depending on its capability (Cash or cheque or
both) by inserting a valid cheque.
17. Verify using different cards (Cards of different banks).
Verifying the Message
18. Insert the card and an incorrect PIN to verify the message.
19. Verify the message when there is no cash in the ATM.
20. Verify the messages after a transaction.
21. Verify if a user will get a correct message if a card is inserted incorrectly.
Messages for each and every scenario should be verified.
Cash Withdrawal
1. Verify the cash withdrawal functionality by inserting some valid amount.
2. Verify if a user can perform only one cash withdrawal transaction per PIN insert.
3. Verify the different combinations of operation and check if there will be a power
loss in the middle of the operation.
Negative Test cases
1. Verify the functionality by entering a wrong pin number for 3 or more times.
2. Verify the card reader functionality by inserting an expired card.
3. Verify the deposit slot functionality by inserting an invalid cheque.
4. Verify the cash withdrawal functionality by inserting invalid numbers like 10, 20,
50 etc.
5. Verify the cash withdrawal functionality by entering an amount greater than the per
day limit,
6. Verify the cash withdrawal functionality by entering an amount greater than per
transaction limit.
7. Verify the cash withdrawal functionality by entering an amount greater than the
available balance in the account.

Result:
ATM machines must be tested for accuracy, reliability, and performance. It should
get tested for its response time per transaction as it works for 24*7.
EX.NO:9 FINCTIONAL POINT ANALYSIS
DATE:

Aim:
To estimate size of the project using function point metric.
Theory:
The basic and primary purpose of the functional point analysis is to measure and
provide the software application functional size to the client, customer, and the stakeholder
on their request. Further, it is used to measure the software project development along with
its maintenance, consistently throughout the project irrespective of the tools and the
technologies.
Following are the points regarding FPs
1. FPs of an application is found out by counting the number and types of functions used in
the applications. Various functions used in an application can be put under five types, as
shown in Table:
Types of FP Attributes

Measurements Parameters Examples

1.Number of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports

3. Number of external inquiries (EQ) Prompts and interrupts.

4. Number of internal files (ILF) Databases and directories

5. Number of external interfaces (EIF) Shared databases and shared routines.

All these parameters are then individually assessed for complexity.

2. FP characterizes the complexity of the software system and hence can be used to depict
the project time and the manpower requirement.
3. The effort required to develop the project depends on what the software does.
4. FP is programming language independent.
5. FP method is used for data processing systems, business systems like information
systems.
6. The five parameters mentioned above are also known as information domain
characteristics.
7. All the parameters mentioned above are assigned some weights that have been
experimentally determined and are shown in Table
Weights of 5-FP Attributes

Measurement Parameter Low Average Hig

1. Number of external inputs (EI) 7 10 15

2. Number of external outputs (EO) 5 7 10

3. Number of external inquiries (EQ) 3 4 6

4. Number of internal files (ILF) 4 5 7

5. Number of external interfaces (EIF) 3 4 6

The functional complexities are multiplied with the corresponding weights against each
function, and the values are added up to determine the UFP (Unadjusted Function Point) of
the subsystem.

Here that weighing factor will be simple, average, or complex for a measurement
parameter type.
The Function Point (FP) is thus calculated with the following formula.
FP = Count-total * [0.65 + 0.01 * ∑(fi)]
= Count-total * CAF
where Count-total is obtained from the above Table.
CAF = [0.65 + 0.01 *∑(fi)]
and ∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment value/
factor-CAF (where i ranges from 1 to 14). Usually, a student is provided with the value of
∑(fi)
Also note that ∑(fi) ranges from 0 to 70, i.e.,
0 <= ∑(fi) <=70
and CAF ranges from 0.65 to 1.35 because
a. When ∑(fi) = 0 then CAF = 0.65
b. When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35
Based on the FP measure of software many other metrics can be computed:
a. Errors/FP
b. $/FP.
c. Defects/FP
d. Pages of documentation/FP
e. Errors/PM.
f. Productivity = FP/PM (effort is measured in person-months).
g. $/Page of Documentation.
8. LOCs of an application can be estimated from FPs. That is, they are
interconvertible. This process is known as backfiring. For example, 1 FP is equal to
about 100 lines of COBOL code.
9. FP metrics is used mostly for measuring the size of Management Information System
(MIS) software.
10. But the function points obtained above are unadjusted function points (UFPs). These
(UFPs) of a subsystem are further adjusted by considering some more General System
Characteristics (GSCs). It is a set of 14 GSCs that need to be considered. The procedure for
adjusting UFPs is as follows:
a. Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5.
(b) If a particular GSC has no influence, then its weight is taken as 0 and if it has a strong
influence then its weight is 5.
b. The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
c. Then Value Adjustment Factor (VAF) is computed from TDI by using the
formula: VAF = (TDI * 0.01) + 0.65
Remember that the value of VAF lies within 0.65 to 1.35 because
a. When TDI = 0, VAF = 0.65
b. When TDI = 70, VAF = 1.35
c. VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP
Example: Compute the function point, productivity, documentation, cost per function for
the following data:
1. Number of user inputs = 24
2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2
6. Effort = 36.9 p-m
7. Technical documents = 265 pages
8. User documents = 122 pages
9. Cost = $7744/ month
Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.
Solution:

Measurement Parameter Cou Weighing factor

1. Number of external inputs (EI) 24 * 4 = 96

2. Number of external outputs (EO) 46 * 4 = 184

3. Number of external inquiries (EQ) 8 * 6 = 48

4. Number of internal files (ILF) 4 * 10 = 40

5. Number of external interfaces (EIF) Count-total → 2 * 5 = 10

378

So sum of all fi (i ← 1 to 14) = 4 + 1 + 0 + 3 + 5 + 4 + 4 + 3 + 3 + 2 + 2 + 4 + 5 = 43

FP = Count-total * [0.65 + 0.01 *∑(fi)]
= 378 * [0.65 + 0.01 * 43]
= 378 * [0.65 + 0.43]
= 378 * 1.08 = 408

Total pages of documentation = technical document + user document

= 265 + 122 = 387pages
Documentation = Pages of documentation/FP
= 387/408 = 0.94

Result:
Thus the Size of the project using function point metric has been evaluated
successfully.
EX.NO:10 COCOMO MODEL
DATE:

Aim:
To estimate the cost of project using COCOMO MODEL.
Theory:
One of the efficient cost estimation models which are extensively applied to many
software projects is called “Constructive Cost Model (COCOMO)”. This cost estimation
model is extensively used in predicting the effort, development time, average team size and
effort required to develop a software project. The distinctiveness of this strategy is that
COCOMO estimates the cost based on the number of lines of source code and sets of
subjective assessment (cost drivers) of product, hardware, personnel and project attributes.
This provides transparency to the model which allows software managers to understand
why the model gives the estimates it does. Moreover, the baseline COCOMO originally
underlies a waterfall model life cycle.
Software projects under COCOMO model strategies are classified to 3 categories
including, organic, semi-detached, and embedded.
1. Organic:This suits a small software team since it has a generally stable
development environment. The problem is well understood and has been solved in the past.
2. Semi-detached:The software project which requires more experience and better
guidance and creativity. For example, Compiler or different Embedded System
3. Embedded:The project with operating tight constraints and requirements is under
this category. The developer requires high experiences and has to be creative to develop
complex models.
The table below indicates the criteria for selecting the type of software project to be applied
for further calculation in the model.
Table1:Comparison between three classes of software project in terms of size, team
size, developer experience, environment, innovation and deadline.
Types of COCOMO model:
COCOMO model allows software manager to decide how detailed they would like
to conduct the cost estimation for their own project. COCOMO can unveil the efforts and
schedule of a software product based on the size of the software in different levels. There
are basic COCOMO, Intermediate COCOMO, and Detailed/Completed COCOMO.
Basic COCOMO model
The basic COCOMO is used for rough calculation which limits accuracy in
calculating software estimation. This is because the model solely considers based on lines of
source code together with constant values obtained from software project types rather than
other factors which have major influences to Software development process as a whole.
Intermediate COCOMO model
Intermediate COCOMO model is an extension of the Basic COCOMO model which
includes a set of cost drivers into account in order to enhance more accuracy to the cost
estimation model as a result.
Complete/detailed COCOMO model
The model incorporates all qualities of both Basic COCOMO and Intermediate
COCOMO strategies on each software engineering process. The model accounts for the
influence of the individual development phase (analysis, design, etc.) of the project.
For instance, detailed COCOMO will perform cost estimation in each development phase of
Waterfall Model.
Figure 1. An illustration of classical Waterfall Model.
Step1:Get an initial estimate of the development effort from evaluation of thousands of
delivered lines of source code (KDLOC).
Step2:Determine a set of 15 cost factors from various attributes of the project.
Step3:Calculate the effort estimate by multiplying the initial estimate with all the
multiplying factors i.e., multiply the values in previous steps.
Now, let’s apply these steps to the real example in Basic COCOMO first. The basic
COCOMO is used in Organic mode by default.
Question:
Suppose the project was estimated to be 400 KDLOC , calculate the effort,
development time, and time of each of the 3 modes
The arithmetic formula of Basic COCOMO is
Effort applied to the project: E= ab(KLOC) bb (in person –month)
Development time: D= Cb(E)db (in month)
Manpower required: P= E/D (in person)
Where ab,bb,cb,db are constants for each category of software product.

Table 2. Constant values corresponding to software project type as stated in previous

section.
The calculations of Basic COCOMO corresponding to each of software project types are
shown in the Table 3.
Table 3. The calculation of Basic COCOMO on each software project type.

Result:
The cost of the project has been estimated successfully using COCOMO model.
EX.NO:11 CRITICAL PATH METHOD
DATE:

Aim:
To estimate critical path for project completion.
Theory:
Critical Path Method (CPM) is a method used in project planning, generally for
project scheduling for the on-time completion of the project. It actually helps in the
determination of the earliest time by which the whole project can be completed. There are
two main concepts in this method namely critical task and critical path. Critical task is the
task/activity which can’t be delayed otherwise the completion of the whole project will be
delayed. It must be completed on-time before starting the other dependent tasks.
Critical path is a sequence of critical tasks/activities and is the largest path in the
project network. It gives us the minimum time which is required to complete the whole
project. The activities in the critical path are known as critical activities and if these
activities are delayed then the completion of the whole project is also delayed.
Step1:Identifying the activities.
Step2:Construct the project network.
Step3:Perform time estimation using forward and backward pass.
Step4:Identify the critical path.

ACTIVITY A B C D E F G H

DURATION
6 4 3 4 3 10 3 2
(IN WEEKS)
PRECEDENTS – – A B B – E, F C, D

Rules for designing the Activity-on-Node network diagram:

 A project network should have only one start node

 A project network should have only one end node
 A node has a duration
 Links normally have no duration
 “Precedents” are the immediate preceding activities
  Time moves from left to right in the project network
 A network should not contain loops
 A network should not contain dangles

Node Representation:

 Activity label is the name of the activity represented by that node.

 Earliest Start is the date or time at which the activity can be started at the
earliest.
 Earliest Finish is the date or time at which the activity can completed at the
earliest.
 Latest Start is the date or time at which the activity can be started at the latest.
 Latest Finish is the date or time at which the activity can be finished at the
latest.
 Float is equal to the difference between earliest start and latest start or earliest
finish and latest finish.

Activity-On-Node diagram:
Forward Pass:
The forward pass is carried out to calculate the earliest dates on which each activity
may be started and completed.

1. Activity A may start immediately. Hence, earliest date for its start is zero i.e.
ES(A) = 0. It takes 6 weeks to complete its execution. Hence, earliest it can
finish is week 6 i.e. EF(A) = 6.
2. Activity B may start immediately. Hence, earliest date for its start is zero i.e.
ES(B) = 0. It takes 4 weeks to complete its execution. Hence, earliest it can
finish is week 4 i.e. EF(B) = 4.
3. Activity F may start immediately. Hence, earliest date for its start is zero i.e.
ES(F) = 0. It takes 10 weeks to complete its execution. Hence, earliest it can
finish is week 10 i.e. EF(F) = 10.
4. Activity C starts as soon as activity A completes its execution. Hence, earliest
week it can start its execution is week 6 i.e. ES(C) = 6. It takes 3 weeks to
complete its execution. Hence, earliest it can finish is week 9 i.e. EF(C) = 9.
5. Activity D starts as soon as activity B completes its execution. Hence, earliest
week it can start its execution is week 4 i.e. ES(D) = 4. It takes 4 weeks to
complete its execution. Hence, earliest it can finish is week 8 i.e. EF(D) = 8.
6. Activity E starts as soon as activity B completes its execution. Hence, earliest
week it can start its execution is week 4 i.e. ES(E) = 4. It takes 3 weeks to
complete its execution. Hence, earliest it can finish is week 7 i.e. EF(E) = 7.
 7. Activity G starts as soon as activity E and activity F completes their execution.
Since, activity requires the completion of both for starting its execution, we
would consider the MAX(ES(E), ES(F)). Hence, earliest week it can start its
execution is week 10 i.e. ES(G) = 10. It takes 3 weeks to complete its
execution. Hence, earliest it can finish is week 13 i.e. EF(G) = 13.
8. Activity H starts as soon as activity C and activity D completes their execution.
Since, activity requires the completion of both for starting its execution, we
would consider the MAX(ES(C), ES(D)). Hence, earliest week it can start its
execution is week 9 i.e. ES(H) = 9. It takes 2 weeks to complete its execution.
Hence, earliest it can finish is week 11 i.e. EF(H) = 11.

Backward Pass:
The backward pass is carried out to calculate the latest dates on which each activity
may be started and finished without delaying the end date of the project.
Assumption: Latest finish date = Earliest Finish date (of project).

1. Activity G’s latest finish date is equal to the earliest finish date of the
precedent activity of finish according to the assumption i.e. LF(G) = 13. It
 takes 3 weeks to complete its execution. Hence, latest it can start is week 10
i.e. LS(G) = 10.
2. Activity H’s latest finish date is equal to the earliest finish date of the
precedent activity of finish according to the assumption i.e. LF(H) = 13. It
takes 2 weeks to complete its execution. Hence, latest it can start is week 11
i.e. LS(H) = 11.
3. The latest end date for activity C would be the latest start date of H i.e. LF(C)
= 11. It takes 3 weeks to complete its execution. Hence, latest it can start is
week 8 i.e. LS(C) = 8.
4. The latest end date for activity D would be the latest start date of H i.e. LF(D)
= 11. It takes 4 weeks to complete its execution. Hence, latest it can start is
week 7 i.e. LS(D) = 7.
5. The latest end date for activity E would be the latest start date of G i.e. LF(G)
= 10. It takes 3 weeks to complete its execution. Hence, latest it can start is
week 7 i.e. LS(E) = 7.
6. The latest end date for activity F would be the latest start date of G i.e. LF(G)
= 10. It takes 10 weeks to complete its execution. Hence, latest it can start is
week 0 i.e. LS(F) = 0.
7. The latest end date for activity A would be the latest start date of C i.e. LF(A)
= 8. It takes 6 weeks to complete its execution. Hence, latest it can start is
week 2 i.e. LS(A) = 2.
8. The latest end date for activity B would be the earliest of the latest start date of
D and E i.e. LF(B) = 7. It takes 4 weeks to complete its execution. Hence,
latest it can start is week 3 i.e. LS(B) = 3.
Identifying Critical Path:
Critical path is the path which gives us or helps us to estimate the
earliest time in which the whole project can be completed. Any delay to an
activity on this critical path will lead to a delay in the completion of the whole
project. In order to identify the critical path, we need to calculate the activity
float for each activity.

Activity float is actually the difference between an activity’s Earliest

start and its latest start date or the difference between the activity’s Earliest
finish and its latest finish date and it indicates that how much the activity can
be delayed without delaying the completion of the whole project. If the float of
an activity is zero, then the activity is an critical activity and must be added to
the critical path of the project network. In this example, activity F and G have
zero float and hence, are critical activities.
Result:
Thus the critical path for project completion has been estimated.
EX.NO:12 GANTT CHART
DATE:

Aim:
To use Timeline charts/Gantt charts to track progress of the project.
Theroy:
A Gantt chart is a bar graph of a project’s tasks. A typical Gantt chart has the name
of individual tasks or group of tasks in the project on the Y-axis. The X-axis has a timeline
divided into days or weeks. Color bars indicate when a task is expected to start. Different
colors indicate how much of an activity has been completed and how much remains
unfinished.
The ability to grasp the overall status of a project and its tasks at once is the key
advantage in using a Gantt chart tool. Therefore, upper management or the sponsors of the
project can make informed decisions just by looking at the Gantt chart tool.
The software-based Gantt charts are able to show the task dependencies in a project
schedule. This helps to identify and maintain the critical path of a project schedule. Gantt
chart tools can be used as the single entity for managing small projects. For small projects,
no other documentation may be required; but for large projects, the Gantt chart tool should
be supported by other means of documentation

Step 1: Develop a Work Breakdown Structure

What is a Work Breakdown Structure (WBS)? It is a process by which a project is
planned by breaking it into easily definable and understandable goals, milestones and tasks.
Listing the major components first is the first step in developing a WBS. This can be done
by in a word processor, spreadsheet, or using a Gantt chart program.
A key element in the WBS is to plan for intended outcomes, rather than planning
actions. That is, understand what the goals of the project are, define key milestones, and
then start the process of breaking those pieces down into tasks. If there are fixed dates that
need to be met, make sure those are shown in the Gantt chart. This way, as the topics are
broken into tasks, it will become clear upfront whether more resources will need to be
added to meet these deadlines.
After the major topics are determined, the process of breaking these into tasks is
next. Depending on the complexity of each task, the project planner may find it necessary
to continue breaking these items into sub-tasks until they are very specific.
For many project planners, a visual model of the WBS is easier to work with than the
"laundry list"dictated by the Gantt chart format. A mind map is ideal for this because it lets
you easily see the work breakdown.
A good Gantt chart software program, such as Smart Draw, will allow you to work
in Gantt chart or mind map view, with relational data that automatically updates both views
when changes are made in either one.
It is estimated that more than 90% of projects are late. The primary reason for this is that
they weren't properly planned with a well-thought-out work breakdown structure. The
more detailed the breakdown, the easier it is to plan, organize and schedule a project
accurately.
Step 2: Assign Tasks
One of the most critical pieces in how to build a Gantt chart is the distribution of
work. There are several things to consider.

-à-vis their currently scheduled workload?

 get these tasks completed on time?
Step 3: Evaluate Task Dependencies
One of the benefits of creating a Gantt chart for project planning is that it makes it
easier to see dependencies. This is a situation where one task is dependent upon the
completion or outcome of another. For example, a webmaster can't build a web page unless
the copywriter and illustrator have finished their tasks. Identifying these dependent
relationships is critical, as delays in the primary steps will almost certainly ripple
throughout the entire project. Automated software will allow you to add dependencies as
you create your Gantt chart. If you're doing this by hand or using a less sophisticated
program, you'll need to remember to do this crucial step manually.

Step 4: Share & Evaluate the Plan with Your Team

When the Gantt chart is complete, distribute it to team members for review and
feedback. It's important that each member of the project buys off on the plan upfront. This
helps to ensure that the plan is accurate and reasonable. It's much easier to allow for
contingencies, plan additional resources, or even propose a revised schedule at this stage,
rather than at a critical juncture later.
Result:
Thus use of Timeline charts/Gantt charts to track progress of the project has been
tracked successfully.
EX.NO:13 PASSPORT AUTOMATION SYSTEM
DATE:

Aim:
To draw the diagrams[use case, activity, sequence, collaboration, class] for the
Passport automation system.
HARDWARE REQUIREMENTS:

SOFTWARE REQUIREMENTS:

PROJECT DESCRIPTION:
This software is designed for the verification of the passport details of the applicant
by the central computer. The details regarding the passport will be provided to the central
computer and the computer will verify the details of applicant and provide approval to the
office. Then the passport will issue from the office to the applicant.
USE CASE DIAGRAM:
This diagram will contain the actors, use cases which are given below
Actors: Applicant, Enquiry officer.
Use case: Applicant details, Applicant proof, Verification of proof, Issue of
passport, Cancellation of the passport.
ACTIVITY DIAGRAM:
This diagram will have the activities as Start point ,End point, Decision boxes as
given below:
Activities: Enter applicant details, Submission of proof, Verification of details, issue
of passport.
Decision box: Check details whether it is correct or not.
CLASS DIAGRAM:
This diagram consists of the following classes, attributes and their operations.

SEQUENCE DIAGRAM:
This diagram consists of the objects, messages and return messages.
Object: Applicant, Enquiry officer, Passport management system
COLLABORATION DIAGRAM:
This diagram contains the objects and actors. This will be obtained by the
completion of the sequence diagram and pressing the F5 key.
MERITS:

DEMERITS:

USECASE DIAGRAM:

CLASS DIAGRAM:
ACTIVITY DIAGRAM:

SEQUENCE DIAGRAM:
COLLABORATION DIAGRAM:

STATE CHART DIAGRAM:

Every object undergoes through some state and on receiving some event the state
gets changed. This transition of the state can be represented by the state transition
diagram

DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM

Deployment diagrams are used to visualize the topology of the physical
components of a system where the software components are deployed.
COMPONENT DIAGRAM:
Component diagrams are used to visualize the organization and relationships
among components in a system.

IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL

SERVICE LAYER:
//Source file: authorityClass.java
public class authorityClass
{
private int offcierId;
private string name;
private string description;
private string password;
public authorityClass()
{
}
public void search()
{
}
}
//void authorityClass.seach(){
//
// }
//Source file: appointmentClass.java
public class appointmentClass
{
private int appointmentId;
private int applicantId;
private date sate;
private int time;
private string description;
public verificationClass theVerificationClass;
public appointmentClass()
{
}
public void getappointment()
{
}
/**
@roseuid 50F8E4C503D8
*/
public void getappointmentStatus()
{
}
public void modify()
{
}
public void cancel()
{
}
}

RESULT:
Thus the mini project for passport automation system has been successfully
executed and codes are generated.