Lab Name
:
Software Engineering Lab
Lab Code
:
3CS4-23
Branch
:
Computer Science & Engineering
Year/Sem
:
2ND Year /III SEM
ARYA Institute of Engineering Technology & Management
Department of Computer Science & Engineering
(Rajasthan Technical University, Kota)
2021-2022
Priya Goyal/AIETM/CSE/3/SE LAB (3CS4-23)
Page 1
INSTRUCTIONS OF LAB
Do’s
1 Know the location of the fire extinguisher and the first aid box and how to use them in case of
an emergency.
2. Read and understand how to carry out an activity thoroughly before coming to the laboratory.
3. Report fires or accidents to your lecturer/laboratory technician immediately.
4. Report any broken plugs or exposed electrical wires to your lecturer/laboratory technician
immediately.
Don’ts
1. Do not eat or drink in the laboratory.
2. Avoid stepping on electrical wires or any other computer cables.
3. Do not open the system unit casing or monitor casing particularly when the power is turned
on. Some internal components hold electric voltages of up to 30000 volts, which can be fatal.
4.Do not insert metal objects such as clips, pins and needles into the computer casings. They
may cause fire.
5. Do not remove anything from the computer laboratory without permission.
6. Do not touch, connect or disconnect any plug or cable without our lecturer/laboratory
technician’s permission.
7. Do not misbehave in the computer laboratory.
Priya Goyal/AIETM/CSE/3/SE LAB (3CS4-23)
Page 2
Choose any one project and do the following exercises for that project
a. Student Result Management System
b. Library management system
c. Inventory control system
d. Accounting system
e. Fast food billing system
f. Bank loan system
g. Blood bank system
h. Railway reservation system
i. Automatic teller machine
j. Video library management system
k. Hotel management system
l. Hostel management system
m. E-ticking
n. Share online trading
o. Hostel management system
p. Resource management system
q. Court case management system
EXERCISE-1
Development of requirement specification, function-oriented design using SA/SD, Objectoriented design using UML, use-case design, implementation. Use of apt case tool such as
configuration management tools, program analysis tools in Software life cycle.
Procedure:
Step 1:
Introduction:
Purpose
Identify the product whose software requirements are specified in this document. Describe
the scope of the product that is covered by this SRS, particularly if this SRS describes only part of
the system or a single subsystem.Describe the different types of user that the document is intended
for, such as developers, project managers, marketing staff, users, testers, and documentation
writers. Describe what the rest of this SRS contains and how it is organized. Suggest a sequence
for reading the document, beginning with the overview sections and proceeding through the
sections that are most pertinent to each reader type.
Project Scope
Provide a short description of the software being specified and its purpose, including
relevant benefits, objectives, and goals. Relate the software to corporate goals or business
strategies. If a separate vision and scope document is available, refer to it rather than duplicating
its contents here. An SRS that specifies the next release of an evolving product should contain its
own scope statement as a subset of the long-term strategic product vision.
Step 2:
Overall Description
Product Perspective
Describe the context and origin of the product being specified in this SRS. For example,
state whether this product is a follow-on member of a product family, a replacement for certain
existing systems, or a new, self-contained product. If the SRS defines a component of a larger
system, relate the requirements of the larger system to the functionality of this software and identify
interfaces between the two. A simple diagram that shows the major components of the overall
system, subsystem interconnections, and external interfaces can be helpful.
Product Features
Summarize the major features the product contains or the significant functions that it
performs or lets the user perform. Only a high level summary is needed here. Organize the functions
to make them understandable to any reader of the SRS. A picture of the major groups of related
requirements and how they relate, such as a top level data flow diagram or a class diagram, is often
effective.
User Classes and Characteristics
Identify the various user classes that you anticipate will use this product. User classes may
be differentiated based on frequency of use, subset of product functions used, technical expertise,
security or privilege levels, educational level, or experience. Describe the pertinent characteristics
of each user class. Certain requirements may pertain only to certain user classes.
Distinguish the favored user classes from those who are less important to satisfy.
Operating Environment
Describe the environment in which the software will operate, including the hardware
platform, operating system and versions, and any other software components or applications with
which it must peacefully coexist.
Design and Implementation Constraints
Describe any items or issues that will limit the options available to the developers. These
might include: corporate or regulatory policies; hardware limitations (timing requirements,
memory requirements); interfaces to other applications; specific technologies, tools, and databases
to be used; parallel operations; language requirements; communications protocols; security
considerations; design conventions or programming standards (for example, if the customer’s
organization will be responsible for maintaining the delivered software).
Step 3:
System Features
This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section by
use case, mode of operation, user class, object class, functional hierarchy, or combinations of these,
whatever makes the most logical sense for your product.
System Feature 1
Don’t really say “System Feature 1.” State the feature name in just a few words.
1
Description and Priority
Provide a short description of the feature and indicate whether it is of High,
Medium, or Low priority. You could also include specific priority component
ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale from
a low of 1 to a high of 9).
2
Stimulus/Response Sequences
List the sequences of user actions and system responses that stimulate the behavior
defined for this feature. These will correspond to the dialog elements associated with use
cases.
3
Functional Requirements
Itemize the detailed functional requirements associated with this feature. These are
the software capabilities that must be present in order for the user to carry out the services
provided by the feature, or to execute the use case. Include how the product should respond
to anticipated error conditions or invalid inputs. Requirements should be concise, complete,
unambiguous, verifiable, and necessary.
<Each requirement should be uniquely identified with a sequence number or a
meaningful tag of some kind.>
REQ-1:
REQ-2:
Step 4:
External Interface Requirements
User Interfaces
Describe the logical characteristics of each interface between the software product and the
users. This may include sample screen images, any GUI standards or product family style guides
that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that
will appear on every screen, keyboard shortcuts, error message display standards, and so on. Define
the software components for which a user interface is needed. Details of the user interface design
should be documented in a separate user interface specification.
Hardware Interfaces
Describe the logical and physical characteristics of each interface between the software
product and the hardware components of the system. This may include the supported device types,
the nature of the data and control interactions between the software and the hardware, and
communication protocols to be used.
Software Interfaces
Describe the connections between this product and other specific software components
(name and version), including databases, operating systems, tools, libraries, and integrated
commercial components. Identify the data items or messages coming into the system and going out
and describe the purpose of each. Describe the services needed and the nature of communications.
Refer to documents that describe detailed application programming interface protocols. Identify
data that will be shared across software components. If the data sharing mechanism must be
implemented in a specific way (for example, use of a global data area in a multitasking operating
system), specify this as an implementation constraint.
Communications Interfaces
Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication standards
that will be used, such as FTP or HTTP. Specify any communication security or encryption issues,
data transfer rates, and synchronization mechanisms.
Nonfunctional Requirements
Performance Requirements
If there are performance requirements for the product under various circumstances, state
them here and explain their rationale, to help the developers understand the intent and make suitable
design choices. Specify the timing relationships for real time systems. Make such requirements as
specific as possible. You may need to state performance requirements for individual functional
requirements or features.
Safety Requirements
Specify those requirements that are concerned with possible loss, damage, or harm that
could result from the use of the product. Define any safeguards or actions that must be taken, as
well as actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the product’s design or use. Define any safety certifications that must be satisfied.
Security Requirements
Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product. Define any user identity
authentication requirements. Refer to any external policies or regulations containing security issues
that affect the product. Define any security or privacy certifications that must be satisfied.
Software Quality Attributes
Specify any additional quality characteristics for the product that will be important to either
the customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness,
testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At
the least, clarify the relative preferences for various attributes, such as ease of use over ease of
learning.
Other Requirements
Define any other requirements not covered elsewhere in the SRS. This might include
database requirements, internationalization requirements, legal requirements, reuse objectives for
the project, and so on. Add any new sections that are pertinent to the project.
Exercise-2
Objective- Develop Software Requirement Specification (SRS) for a given
problem in IEEE template.
An SRS is basically an organization's understanding (in writing) of a customer or potential client's
system requirements and dependencies at a particular point in time (usually) prior to any actual
design or development work. It's a two-way insurance policy that assures that both the client and
the organization understand the other's requirements from that perspective at a given point in time.
The basic issues that the SRS shall address are the following:
a) Functionality. What is the software supposed to do?
b) External interfaces. How does the software interact with people, the system‘s
hardware, other hardware, and other software?
c) Performance. What is the speed, availability, response time, recovery time of various
software functions, etc.?
d) Attributes. What are the portability, correctness, maintainability, security, etc.
considerations?
e) Design constraints imposed on an implementation. Are there any required
standards in effect, implementation language, policies for database integrity, resource
limits, operating environment(s) etc.?
Chracteristics of a good SRS
An SRS should be
a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable
SAMPLE SRS
SOFTWARE REQUIREMENTS SPECIFICATION
ATM
Version 1.0
September 8, 2006
AN AUTOMATED TELLER MACHINE
Table of Contents
1. Introduction
The software ATMExcl 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.
1.1 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.
1.2 Scope
This document applies to Automated Teller Machine software ATM 3.0TM. This software
facilitates the user to perform various transaction 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 tha 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.
1.3 Definitions, Acronyms, and Abbreviations.
AC
Alternate Current
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 cash 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.
Bank Management Software developed by KPM Bank.
BMS
CDMA
CMS
Code Division Multiple Access, a reliable data communication
protocol.
Card Management Software developed by KPM Bank.
DES
Data Encryption Standard.
Dial-Up POS
A message format for low cost communications.
Electronic
Journals
Internet
For easier, safer information storage, related to modem.
MB
An interconnected system of networks that connects computers
around the world via the TCP/IP protocol.
Mega Bytes
ms
Milliseconds.
sec
Seconds
Smart Card
Card without hardware which stores the user‘s private keys within a
tamper proof software guard.
Software Requirements Specification.
SRS
Tactile
keyboard
TCP/IP
Special keyboard designed to aid the visually impaired.
V
Volts
VGA
Video Graphics Adaptor is a display standard.
Transmission Control Protocol/Internet Protocol.
1.4 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.
Online.
Russell C. Bjork Requirements Statement for Example ATM System.
URL: http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/
1.5 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
2.1 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.
2.2 Product Functions
The major functions that ATMExcl 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 depositary.
▪ 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 updation in his account.
✓ Cancelling:- 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.
2.3 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 intarctive teaching mechanism at every
atep 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 admninistrator‘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.
2.4 Constraints
The major constraints that the project has are as follows:✓ The 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.
2.5 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
3.1.1 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.
2.
3.
4.
5.
6.
7.
8.
A login screen is provided in the beginning for entering the required
username/pin no. and account number.
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 languagesfrom which a user can select any one.
In case of administrator, a screen will be shown having optins to reboot system,
shut down system, block system, disable any service.
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.
In case of blocking system, a screen is provided asking for the card no. By
entering the carnd no of a particular user, system accees can be blocked for
him.
Administrator is also provided with a screen that enables him to block any
service provided to the user by enterin the name of the service or by selecting it
from the list displayed.
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.
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.
3.1.2 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 o Height - 53.92mm-54.03mm
o 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 thye 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.
3.1.3 Software Interface Requirements
In order to perform various different functions, this software needs to interact with
various other softwares. 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 codecs 367/98 for active speakers.
❑ The database used to keep record of user accounts shall be Oracle
version7.0.
3.1.4 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 ech 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
Logout Time:-
TO
TYPE
BARCODE
Thank You For your visit.
See you soon.
AMOUNT
5. Other Nonfunctional Requirements
5.1 Performance Requirements
The following list provides a brief summary of the performance requirements for the software:
5.1.1
Capacity
❑ The ATM shall provide customers a 24 hour service.
5.1.2 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.
5.1.3 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
5.2 Software System Attributes
5.2.1 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.
5.2.2 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.
5.2.3 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.
5.2.4 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.
5.3 Business Rules
The business rules for the software are as follows:
•
•
•
•
•
•
6
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.
Other Requirements
None.
Appendix A: Glossary
AIMS
ATM
-
ATM Information Management System.
An unattended electronic machine in a public place, connected
to a data system and related equipment and activated by a bank customer to obtain
cash 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
-
Card without hardware which stores the user‘s private keys within a
tamper proof software guard.
Smart Card Tactile Keyboard
TCP/IP
An interconnected system of networks that connects computers around the
world via the TCP/IP protocol.
Special keyboard designed to aid the visually impaired.
-
Transmission Control Protocol/Internet Protocol.
Exercise No. 3
AIM :
Develop DFD model (level-0, level-1 DFD and Data dictionary) of the project.
OVERALL DESCRIPTION :
Data analysis attempts to answer four specific questions:
•
What processes make up a system?
•
What data are used in each process?
•
What data are stored?
•
What data enter and leave the system?
Data drive business activities and can trigger events (e.g. new sales order data) or be processed to
provide information about the activity. Data flow analysis, as the name suggests, follows the flow
of data through business processes and determines how organisation objectives are accomplished.
In the course of handling transactions and completing tasks, data are input, processed, stored,
retrieved, used, changed and output. Data flow analysis studies the use of data in each activity and
documents the findings in data flow diagrams, graphically showing the relation between processes
and data.
Physical and Logical DFDs
There are two types of data flow diagrams, namely physical data flow diagrams and logical data
flow diagrams and it is important to distinguish clearly between the two:
Physical Data Flow Diagrams
An implementation-dependent view of the current system, showing what tasks are carried
out and how they are performed. Physical characteristics can include:
Names of people
Form and document names or numbers
Master and transaction files
Equipment and devices used
Logical Data Flow Diagrams
An implementation-independent view of the a system, focusing on the flow of data between
processes without regard for the specific devices, storage locations or people in the system. The
physical characteristics listed above for physical data flow diagrams will not be specified.
ORDERS
CUSTOMERS
INVOICES
Fig. A typical DFD
Data Flow Diagram (DFD)
The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows
the different processing activities or functions that the system performs and the data interchange among these
functions. Each function is considered as a processing station (or process) that consumes some input data and
produces some output data. The system is represented in terms of the input data to the system, various
processing carried out on these data, and the output data generated by the system. A DFD model uses a very
limited number of primitive symbols [as shown in fig. 5.1(a)] to represent the functions performed by a system
and the data flow among these functions.
Symbols used for designing DFDs
Here, two examples of data flow that describe input and validation of data are considered.
In Fig. 5.1(b), the two processes are directly connected by a data flow. This means that the
‘validate-number’ process can start only after the ‘read-number’ process had supplied data
to it. However in Fig 5.1(c), the two processes are connected through a data store. Hence,
the operations of the two bubbles are independent. The first one is termed ‘synchronous’
and the second one ‘asynchronous’.
Importance of DFDs in a good software design
The main reason why the DFD technique is so popular is probably because of the fact that
DFD is a very simple formalism – it is simple to understand and use. Starting with a set of highlevel functions that a system performs, a DFD model hierarchically represents various
subfunctions. In fact, any hierarchical model is simple to understand. Human mind is such that it
can easily understand any hierarchical model of a system – because in a hierarchical model, starting
with a very simple and abstract model of a system, different details of the system are slowly
introduced through different hierarchies. The data flow diagramming technique also follows a very
simple set of intuitive concepts and rules. DFD is an elegant modeling technique that turns out to
be useful not only to represent the results of structured analysis of a software problem, but also for
several other applications such as showing the flow of documents or items in an organization.
Data dictionary
A data dictionary lists all data items appearing in the DFD model of a system. The data
items listed include all data flows and the contents of all data stores appearing on the DFDs
in the DFD model of a system. A data dictionary lists the purpose of all data items and the
definition of all composite data items in terms of their component data items. For example,
a data dictionary entry may represent that the data grossPay consists of the components
regularPay and overtimePay.
Viva-Voce
Q1. What is DFD.
Answer- A data flow diagram (DFD) is a graphical representation of the "flow"
of data through an information system, modelling its process aspects. A DFD is
often used as a preliminary step to create an overview of the system without
going into great detail, which can later be elaborated.
Q2. What Is Level-0 DFD?
Answer: Highest abstraction level DFD is known as Level 0 DFD also called a
context level DFD, which depicts the entire information system as one diagram
concealing all the underlying details.
Q3. Briefly Define Top-down and Bottom-up Design Model.
Answer : Top-down model starts with generalized view of system and
decomposes it to more specific ones, whereas bottom-up model starts with most
specific and basic components first and keeps composing the components to get
higher level of abstraction.
Q4. What Are Various Phases of Sdlc?
Answer: The generic phases of SDLC are: Requirement Gathering, System
Analysis and Design, Coding, Testing and implementation. The phases depend
upon the model we choose to develop software.
Q5- What is a Level 2 data flow diagram?
Answer- A level 2 data flow diagram (DFD) offers a more detailed look at the
processes that make up an information system than a level 1 DFD does. It can be
used to plan or record the specific makeup of a system. You can then input the
particulars of your own system.
Q6- What Arrow represents in DFD?
Answer: Arrows represent how the data flows. Use the type of data that is
moving through the system as the name for the arrow.
Q8- How many level in DFD?
Answer- there are three level in DFD
1) 0 level
2) 1 level
3) 2 level
Q9- What Is Data Dictionary?
Answer : Data dictionary is referred to as meta-data. Meaning, it is a repository of data
about data. Data dictionary is used to organize the names and their references used in
system such as objects and files along with their naming conventions.
Q10- Give an Example of a DFD level 0
Answer-
Exercise No.4
Develop Structured design for the DFD model developed.
A DFD model of a system graphically depicts the transformation of the data input to the
system to the final result through a hierarchy of levels. A DFD starts with the most abstract
definition of the system (lowest level) and at each higher level
DFD, more details are successively introduced. To develop a higher-level DFD model,
processes are decomposed input data to these functions and the data output by these
functions and represent them appropriately in the diagram.
If a system has more than 7 high- level functional requirements, then some of the related
requirements have to be combined and represented in the form of a bubble in the level 1
DFD. Such a bubble can be split in the lower DFD levels. If a system has less than three
high-level functional requirements, then some of them need to be split into their
subfunctions so that we have roughly about 5 to 7 bubbles on the diagram.
Decomposition:Each bubble in the DFD represents a function performed by the system. The bubbles are
decomposed into sub-functions at the successive levels of the DFD.
Decomposition of a bubble is also known as factoring or exploding a bubble. Each bubble
at any level of DFD is usually decomposed to anything between 3 to 7 bubbles. Too few
bubbles at any level make that level superfluous. For example, if a bubble is decomposed
to just one bubble or two bubbles, then this decomposition becomes redundant. Also, too
many bubbles, i.e. more than 7 bubbles at any level of a DFD makes the DFD model hard
to understand. Decomposition of a bubble should be carried on until a level is reached at
which the function of the bubble can be described using a simple algorithm.
Numbering of Bubbles:It is necessary to number the different bubbles occurring in the DFD. These numbers help
in uniquely identifying any bubble in the DFD by its bubble number. The bubble at the
context level is usually assigned the number 0 to indicate that it is the 0 level DFD. Bubbles
at level 1 are numbered, 0.1, 0.2, 0.3, etc, etc. When a bubble numbered x is decomposed,
its children bubble are numbered x.1, x.2, x.3, etc. In this numbering scheme, by looking
at the number of a bubble we can unambiguously determine its level, its ancestors, and its
successors.
Example:A supermarket needs to develop the following software to encourage regular customers.
For this, the customer needs to supply his/her residence address, telephone number, and the
driving license number. Each customer who registers for this scheme is assigned a unique
customer number (CN) by the computer. A customer can present his CN to the check out
staff when he makes any purchase. In this case, the value of his purchase is credited against
his CN. At the end of each year, the supermarket intends to award surprise gifts to 10
customers who make the highest total purchase over the year. Also, it intends to award a
22 caret gold coin to every customer whose purchase exceeded
Rs.10,000. The entries against the CN are the reset on the day of every year after the prize
winners’ lists are generated.
EXERCISE NO-5
Aim:
Develop all structure UML diagram of given project.
Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, coloured monitor.
Software Requirements:
Rational Rose, Windows XP,
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.
2.
3.
4.
2.
Use Case Names Begin With a Strong Verb
Name Use Cases Using Domain Terminology
Place Your Primary Use Cases In The Top-Left Corner Of The Diagram
Imply Timing Considerations By Stacking Use Cases.
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.
2.
3.
4.
5.
6.
7.
8.
3.
Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram
Draw Actors To The Outside Of A Use Case Diagram
Name Actors With Singular, Business-Relevant Nouns
Associate Each Actor With One Or More Use Cases
Actors Model Roles, Not Positions
Use <<system>> to Indicate System Actors
Actors Don‘t Interact With One Another
Introduce an Actor Called ―Time‖ to Initiate Scheduled Events
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 openheaded
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):
•
Click on the File menu and select New.
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>Use
Case Diagram.
Enter the name of new Use Case 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 Use Case
diagram using the buttons provided on the vertical toolbar.
Conclusion: The use case diagram was made successfully by following the steps described above.
Some Sample Use Case Diagrams are given below for illustration purpose:
Authentication
User/BT
Searching
Data Transfer
Administrator
Mobility Management
Signalling Management
Software Updation
Use Case Diagram for Bluetooth Software
Cancellation of Boo
ked Hall
Booking
login
Employee
Enquiry
Report
Resources
Update
Use Case Diagram for Resource Management
Administrator
Viva-voice
Question 1.What Is Uml?
Answer:
•
•
•
UML is Unified Modeling Language.
Graphical language for visualizing artifacts of the system.
Allow to create a blue print of all the aspects of the system.
Question 2. What Are The Three Types Of Modeling In
Uml?
Answer :
•
•
•
Structural.
behavioral.
architectural.
Question 3. What Is Uml Architecture?
Answer :Takes care structural and behavioral aspect of a software system.
Includes software usage, functionality, performance, reuse, economic and
technology constraints.
Question 4. What Are Uml Messages?
Answer: Specification of a communication.
Question 5: What is the purpose of a use case diagram?
Answer: The main purpose of a use case diagram is to show who interacts with your
system, and the main goals they achieve with it
Question 6. Explain Class and objects?
Answer: class: a class describes the contents of the objects that belong to it: it
describes an aggregate of data fields (called instance variables), and defines the
operations (called methods).
object: an object is an element (or instance) of a class; objects have the behaviors of their
class.
Exercise-6
Introduction to Behavioral Modelling Using UML.
Basic Ideas on UML
Model:
A model is the graphical, textual,
mathematical, or program code-based representation. A
model captures important aspect for some application while omitting (or abstracting) the rest. Models
are very useful in documenting the design and analysis results.
Need for a model
An important reason behind constructing a model is that it helps manage complexity. Once
models of a system have been constructed, these can be used for a variety of purposes
during software development, including the following:
• Analysis
• Specification
• Code generation
• Design
• Visualize and understand the problem and the working of a system
• Testing, etc
Unified Modeling Language (UML)
UML, as the name implies, is a modeling language. It may be used to visualize,
specify, construct, and document the artifacts of a software system. It provides a set of
notations (e.g. rectangles, lines, ellipses, arrow etc.) to create a visual model of the system.
UML was developed to standardize the large number of object-oriented modeling
notations that existed and were used extensively in the early 1990s. Some of the principles
that ones in use were:
• Object Management Technology [Rumbaugh 1991]
• Booch’s methodology [Booch 1991]
• Object-Oriented Software Engineering [Jacobson 1992]
• Odell’s methodology [Odell 1992]
• Shaler and Mellor methodology [Shaler 1992]
UML was adopted by Object Management Group (OMG) as a de facto standard in
1997. OMG is an association of industries which tries to facilitate early formation of
standards.
Viva- Voce
Q1. When and By whom was UML designed?
Answer: It was developed by software engineers Grady Booch, Ivar Jacobson, and James
Rumbaugh of Rational software during 1994 and 1995. It was under development till 1996.
All of UML creators, viz, Grady Booch, Ivar Jacobson, and James Rumbaugh had a fabulous
idea for creating a language that will reduce the complexity.
•
•
•
•
Booch’s method was flexible to work with throughout the design and creation of
objects.
Jacobson’s method contributed a great way to work on use-cases. It further has a great
approach for high-level design.
Rumbaugh’s method turned out to be useful while handling sensitive systems.
Behavioral models and state-charts were added in the UML by David Harel.
Q2. What do you understand by class diagram?
Answer: This diagram explores detail design of the system. The class diagram is
designed using Use Case diagram. We can identify all Nouns in use cases as classes
and verbs as method of the classes.
Q3. - How many types of UML Diagram?
Answer- various types of UML are listed below:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Use Case Diagram
Class Diagram:
Object diagram
State Diagram
Sequence diagram
Collaboration diagram
Activity diagram
Component diagram
Deployment diagram
Q4.- Why UML diagram is important?
Answer: An object contains both data and methods that control the data. UML is
powerful enough to represent all the concepts that exist in object-oriented analysis
and design. UML diagrams are representation of object-oriented concepts only.
Thus, before learning UML, it becomes important to understand OO concept in
detail.
Q5.- Why do we use class diagram?
Answer: Class diagram describes the attributes and operations of a class and also
the constraints imposed on the system. The class diagrams are widely used in the
modeling of object-oriented systems because they are the only UML diagrams,
which can be mapped directly with object-oriented languages.
Q6. What Is Polymorphism in OOPS?
Answer: The ability of different methods to implement the same operation, and
thus to respond same messages in different ways that are appropriate to their
class is called polymorphism.
Exercise-7
Develop Behavioral UML diagram for any software project.
UML diagrams
UML can be used to construct several different types of diagrams to capture five
different views of a system. Just as a building can be modeled from several views (or
perspectives) such as
ventilation
perspective,
electrical
perspective,
lighting perspective, heating perspective, etc.
.
The UML diagrams can capture the following five views of a system:
• User’s view
• Structural view
• Behavioral view
• Implementation view
• Environmental view
Fig. 1: Different types of diagrams and views supported in UML
1. User’s view:
This view defines the functionalities (facilities) made available by the system to its
users. The users’ view captures the external users’ view of the system in terms of the
functionalities offered by the system. The users’ view is a black-box view of the system
where the internal structure, the dynamic behavior of different system components, the
implementation etc. are not visible. It is very different from all other that it is a functional
model compared to the object model of all other views. The users’ view can be considered
as the central view and all others are expected to conform to this view.
2. Structural view:
The structural view defines the kinds of objects (classes) important to the
understanding of the working of a system and to its implementation. It also captures the
relationships among the classes (objects). The structural model is also called the static
model, since the structure of a system does not change with time.
3. Behavioral view:
The behavioral view captures how objects interact with each other to realize the
system behavior. The system behavior captures the time-dependent (dynamic) behavior
of the system.
4. Implementation view:
This view captures the important components of the system and their
dependencies.
5. Environmental view:
This view models how the different components are implemented on different
pieces of hardware platform
Use Case Model
The use case model for any system consists of a set of “use cases”, users and relationship
among them within the system. Use case describes the action that user takes on a system.
Use case diagram model the process flow of a system. It is the way to communicate with
the user. Intuitively, use cases represent the different ways in which a system can be used
by the users. A simple way to find all the use cases of a system is to ask the question:
“What the users can do using the system?”. Four basic components to construct use case
diagram are:
a) System: Something that performs a function or system is a piece/multiple piece of
software that perform some function for its user.
b)actor: actor is something that uses our system. It is named based on their job title.
An actor can be a person or another external system like developer, student, clerk,
teacher, officer
etc.
c)use cases: are the actions that a user takes on a system. According to above example
developer creates s/w, teacher record grade, officer create command etc.
d)relationship: connection between the actor to the use cases. Actor can relates to
multiple use cases and a use cases relate to multiple actors.
Thus for the Library Information System (LIS), the use cases could be:
• issue-book
• query-book
• return-book
• create-member
• add-book, etc
Similarly the use case model for the Supermarket Prize Scheme is shown in fig. 2. As
discussed earlier, the use cases correspond to the high level functional requirements. From
the problem description and the context diagram. In fig.2 we can identify three use cases:
“register-customer”, “register-sales”, and “select-winners”. As a sample, the text
description for the use case “register-customer” is shown below.
Fig. 2 Use case model for Supermarket Prize Scheme
Text description
U1: register-customer: Using this use case, the customer can register
himself by providing the necessary details.
Scenario 1: Mainline sequence
1. Customer: select register customer option.
2. System: display prompt to enter name, address, and telephone
number.
3. Customer: enter the necessary values.
4. System: display the generated id and the message that the customer
has been successfully registered.
Scenario 2: at step 4 of mainline sequence
1. System: displays the message that the
customer has already registered.
Scenario 2: at step 4 of mainline sequence
1. System: displays the message that some input information has not been entered.
The system displays a prompt to enter the missing value.
Utility of use case diagrams
Use cases are represented by ellipses. They along with the accompanying text description
serve as a type of requirements specification of the system and form the core model to
which all other models must conform. UML offers three mechanisms for factoring of use
cases as follows:
Generalization
Generalization is a technique that used to inherit an item in UML. It can be applied to
both actor and use cases to indicate that their child item inherit functionality from parent.
Fig. 3: Representation of use case generalization
Includes
Include relationship indicate that use case will include functionality from an additional
use cases. The relationship involves one use case including the behavior of another use
case in its sequence of events and actions. The includes relationship occurs when a chunk
of behavior that is similar across a number of use cases
Fig. 4: Example use case inclusion
Extends
Extended relationship indicates that use case may be extended by another use case. The
main idea behind the extends relationship among the use cases is that it allows us to show
optional system behavior. The extend relationship is similar to generalization. But unlike
generalization, the extending use case can add additional behavior only at an extension
point only when certain conditions are satisfied.
<<>extended>
Fig. 5: Hierarchical organization of use cases
Exercise- 8
Develop all the Diagrams for any software project using UML design methodology.
Solution:1. Class and Interaction Diagrams
Class diagrams
A class diagram describes the static structure of a system. It shows how a system is
structured rather than how it behaves. The static structure of a system comprises of a
number of class diagrams and their dependencies. The main constituents of a class
diagram are classes and their relationships: generalization, aggregation, association, and
various kinds of dependencies.
Classes
The classes represent entities with common features, i.e. attributes and operations. Classes
are represented as solid outline rectangles with compartments. It has a mandatory name
compartment where the name is written centered in boldface. The class name is usually
written using mixed case convention and begins with an uppercase. The class names are
usually chosen to be singular nouns.
Attributes
An attribute is a property of a class written in left justified. It represents the kind of data
that an object might contain. Attributes are listed with their names, and may be contain
specification of their type, an initial value, and constraints. The type of the attribute is
written by appending a colon and the type name after the attribute name as
book Name : String
Operation
Operation is the implementation of a service/activity that supported by class and invoked
by other class object. It can be requested from any object of the class to affect behavior.
An object’s data or state can be changed by invoking an operation of the object. A class
may have any number of operations or no operation at all. Generally the first letter of an
operation name is a small letter. Its return type is Boolean as E.g
issueBook(in bookName):Boolean
Association
When two classes associated with each other, their exists association relation. It is
represented by straight line between concerned classes. Associations enable objects to
communicate with each other. An association describes a connection between classes.
The association relation between two objects is called object connection or link. Links
are instances of associations. Mathematically, a link can be considered to be a tuple, i.e.
an ordered list of object instances. An association describes a group of links with a
common structure and common semantics. Each side of association relation multiplicity
is noted as an individual number or value range. Multiplicity (*) indicate how many
instance of one class are associated with the other. Range of multiplicity are noted by
specifying range of minimum to maximum by giving two dots i.e 1..5. An asterisk is
used as a wild card (last entry), zero or more.
Let us consider the statement that below illustrates the graphical representation of
the association relation. The name of the association is written alongside the association
line. An arrowhead is placed on the association line to indicate the reading direction of
the association. The arrowhead should not be misunderstood to be indicating the direction
of a pointer implementing an association. The multiplicity indicates how many instances
of one class are associated with each other.
Fig. 6: Association between two classes
Aggregation
Aggregation is a special type of association relation, where classes are not only
associated but also whole part relation exist between them. Here involved classes that
takes the responsibility of forwarding messages to the appropriate parts. Thus, it takes the
responsibility of delegation and leadership. When an instance of one object contains
instances of some other objects, then aggregation relationship exists between the
composite object and the component object. Aggregation is represented by the diamond
symbol at the composite end of a relationship. For example boo register is an aggregation
of book objects similarly document can be consider as an aggregation of paragraph and
aggregation of line. Here 1 and * means one document can have many paragraph and
many lines constitute a paragraph. This relation cannot be reflexive means an object
cannot have the object of same class as itself nor symmetric (i.e two classes cannot contain
instance of each other). However aggregation relationship is transitive and it can consist
of arbitrary number of levels.
Composition
Composition is a stricter form of aggregation, in which the parts are existencedependent
on the whole. Means that the life of the parts closely ties to the life of the whole. The
composition relationship is represented as a filled diamond drawn at the composite-end.
An example of the composition relationship is
Fig. 7: Diagram representing aggregation and composition.
Dependency
It represented by dotted arrow from dependent class to independent class. It provides pre
and post condition for operation to define ordering of an item.
Association vs. Aggregation vs. Composition
•
Association is the most general (m:n) relationship. Aggregation is a stronger
relationship where one is a part of the other. Composition is even stronger than
aggregation.
•
Association relationship can be reflexive (objects can have relation toitself), but
aggregation cannot be reflexive. Aggregation is anti-symmetric (If B is a part of A, A
cannot be a part of B).
•
Composition has the property of exclusive aggregation i.e. an object can be a part
of only one composite at a time. For example, a Frame belongs to exactly one Window
whereas in simple aggregation, a part may be shared by several objects. For example, a
Wall may be a part of one or more Room objects.
•
In composition, the whole has the responsibility for the decomposition of all its
parts, i.e. for their creation and destruction. For example, when a Frame is created, it has
to be attached to an enclosing Window. Similarly, when the Window is destroyed, it must
in turn destroy its Frame parts.
Inheritance vs. Aggregation/Composition
•
Inheritance describes ‘is a’ / ‘is a kind of’ relationship between classes (base class
- derived class) whereas aggregation describes ‘has a’ relationship between classes.
Inheritance means that the object of the derived class inherits the properties of the base
class; aggregation means that the object of the whole has objects of the part.
•
Inheritance means the objects of the subclass can be used anywhere the super
class may appear, but not the reverse; i.e. wherever we could use instances of ‘payment’
in the system, we could substitute it with instances of ‘cash payment’, but the reverse
cannot be done.
•
Inheritance is defined statically. It cannot be changed at run-time. Aggregation is
defined dynamically and can be changed at run-time. Aggregation is used when the type
of the object can change over time.
For example, consider this situation in a business system. A Business Partner might be a
Customer or a Supplier or both. During its lifetime, a business partner might become a
customer as well as a supplier, or it might change from one to the other. In such cases, we
prefer aggregation instead. Here, a business partner is a Customer if it has an aggregated
Customer object, a Supplier if it has an aggregated Supplier object and a "Customer
Supplier" if it has both. Here, we can have only two types. Hence, we are able to model
it as inheritance.
•
The advantage of aggregation is the integrity of encapsulation. The operations of
an object are the interfaces of other objects which imply low implementation
dependencies. The disadvantage of aggregation is the increase in the number of objects
and their relationships. On the other hand, inheritance allows for an easy way to modify
implementation for reusability.
.
1.1 Interaction Diagrams
Interaction diagram describe the interaction among group of objects through message
passing. Interaction diagrams are models that describe how group of objects collaborate
to realize some behavior. Each interaction diagram realizes the behavior of a single use
case. An interaction diagram shows a number of example objects and the messages that
are passed between the objects. There are two kinds of interaction diagrams: sequence
diagrams and collaboration diagrams.
2. Sequence Diagram:
A sequence diagram shows interaction among objects as a two dimensional chart. The
chart is read from top to bottom. The objects participating in the interaction are shown at
the top of the chart as boxes attached to a vertical dashed line. Vertical dashed line is
called object life line. Any point on life line implies that object exist at that point. If object
is destroyed, lifeline of object is crossed at that point and lifeline of that object is not
drowned at that point. Control rectangle is used as activation symbol drown from lifeline
of an object that the point at which object is active. Object is active as long as control
rectangle is exist in lifeline of object. Each message is labeled with message name. Inside
the box the name of the object is written with a colon separating it from the name of the
class and both the name of the object and the class is underlined. The objects appearing at
the top signify that the object already existed when the use case execution was initiated.
Note: single use case represent single sequence diagram.
Object1
Object2 c
Object3
message
[invalid]
•
A condition (e.g. [invalid]) indicates that a message is sent, only
if the condition is true.
•
An iteration marker shows the message is sent many times to
multiple receiver objects. As it happened elements of an array are being
iterated. The basis of the iteration can also be indicated e.g. [for every
book object].
Fig. 8: Sequence diagram for the renew book use case
3. Collaboration Diagram
Collaboration diagram is a cross between the class diagram and sequence iagram.
It model the objects and sequenced communication between each other. Collaboration
diagram shows both structural and behavioral aspects explicitly. Structural aspect consists
of objects and links among the objects which indicate the association. Object in
collaboration diagram is called collaborator. But in sequence diagram it shows only the
behavioral aspects. The link between objects is shown as a solid line and can be used to
send messages between two objects. The message is shown as a labeled arrow placed near
the link. The use of the collaboration diagrams in our development process is to help us
to determine which classes are associated with which other classes. This model used to
represent interaction between objects and role. Link between object is shown in solid line
and can be used to send messages between two objects. Collaboration diagram derived
from sequence diagram which realize for single use case. It helps us to, which class
associated with the other class. For example collaboration diagram for renew book use
case
Fig. 9: Collaboration diagram for the renew book use case
4. Activity diagrams
Activity diagram represent the various activity or chunk of process and their sequence
of activation. It shows the system execution and changes of direction based on different
condition. It model workflow for use case. It is possibly based on the event diagram of
Odell [1992] through the notation is very different from that used by Odell. An interesting
feature of the activity diagrams is the swim lanes. Swim lanes enable us to group activities
based on who is performing them, e.g. academic department vs. hostel office. This is
carried out during the initial stages of requirements analysis and specification. Activity
diagram gives start and end state and can show the path within the use case as well as
between the use cases. It explains what condition needs to meet for use cases for use case
to be valid condition state etc.
Components of activity diagram are:
a)Activities or action state: notation used for activity/action is rectangle with
rounded corner and it indicate action.
b)State: activity diagram can have only one start state but can have several
end/stop state. UML may describe two special state called start state and
stop
state represented as: black dot and black dot with round circle.
c)Transition: used to show control flow from one state to another state. It shows
flow from state to an activity, between activity or between states.
Guard is noted on transition between two activity or states. And diamond is used as
decision point for condition. An activity is a state with an internal action and one or more
outgoing transition which automatically follow the internal activity termination.
Activity diagram is similar to procedural flow chart, difference is that activity diagram
support description of parallel activity and synchronization exist between activity and
parallel activities are represented by swim lane.
Fig. 9: Activity diagram for student admission procedure at IIT
Viva-Voce
Q1.What Is An Activity Diagram?
Answer: A variation of a state chart diagram that focuses on a flow of activity driven
by internal processing within an object rather than by events that are external to it. In
an activity diagram most (or all) states are action states, each of which represents the
execution of an operation.
Q2. What is the use of Activity Diagram?
Answer- Activity diagram gives detail view of the business logic.
Q3. Brief Explanation of All Elements in Activity Diagrams?
Answer
•
•
•
•
Activities: An activity indicates an action that performed in the system.
Transitions: Transitions are represented by open arrow heads. Transitions
are used to indicate the flow among elements in the diagram.
Decision Points: The logical branching is depicted by the decision points.
States: A state is shown in a rounded rectangle. States are indicated to
mention the mile stones of processing in the activity diagrams.
Q4. What Is the Difference Between Activity and Sequence Diagrams?
Answer : The following are the difference between Activity and Sequence Diagrams:
A sequence diagram shows the way of processes execute in a sequence. For example,
the order of operations and the parameters.
► An activity diagram depicts the operational workflows.
► A sequence diagram is focused to represent interactions between different objects.
► Activity diagram shows the actions for various objects.
Q5. What Are Messages?
Answer: A message is the specification of a communication, when a message is
passed that results in action that is in turn an executable statement.
Q6. What Is an Activity?
Answer: An activity is some behavior that may persist for the duration of a state.
Exercise-9
Manage Files using ProjectLibre Project Management tool.
Solution: ProjectLibre is considered one of the best open-source project management tools. It was
created by the founders of OpenProj.
ProjectLibre is considered as an efficient project management tool that is used, and in its
usage all data is entered in tables as rows, like Excel. And after all of it’s entered,
diagrams, Gantt Charts and a WBS (Work Breakdown Structure) generate automatically. No
need to draw the diagrams yourself, all you have to do is clearly define your project, and
enter your project-data correctly.
Step-1: Enter the name of all the activities that are to be accomplished related to any specific
project.
2.Once the activities are entered, then click on task option in Menu bar and then
click on Gantt chart. Hence you can see the Gantt chart is automatically
generated.
Step-3: Likewise other activities of project like Activity Network, PERT, Work
Breakdown structure (WBS), Critical Path Method are also generated.
This helps to understand and decide which activity is to be started as soon as
possible and that could be started late with some time lag. All these tasks are
done to avoid any kind of risk that ultimately leads to the failure of the project
due to bound timelines.
Viva- Voce
What Is Modeling? What Are The Advantages Of Creating A Model?
Answer :
Modeling is a proven and well-accepted engineering technique which helps build a model.
Model is a simplification of reality; it is a blueprint of the actual system that needs to be built.
Model helps to visualize the system. Model helps to specify the structural and behavior of the
system. Model helps make templates for constructing the system. Model helps document the
system.
What Are The Different Views That Are Considered When Building An Objectoriented Software System?
Answer :
Normally there are 5 views.
Use Case view - This view exposes the requirements of a system.
Design View - Capturing the vocabulary.
Process View - modeling the distribution of the systems processes and threads.
Implementation view - addressing the physical implementation of the system.
Deployment view - focus on the modeling the components required for deploying the system.
What Is Generalization And Specialization?
Answer :
Generalization: Generalization is the abstraction of common feature among elements by the
creation of a hierarchy of more general elements that encapsulate common features. For
example, in animal world a cat and a dog share some common features and we create a common
general class “Mammal” which encapsulates common their common feature. A cat, a dog –
both
are
consistent
with
mammal
class.
Specialization: The other face of generalization is specialization. A class is said to be
specialized when it has a set of characteristics that uniquely distinguish it from its super class.
For example, a cat is a mammal but it is more specialized.
What are design patterns?
Answer:
Design patterns are the recurring solutions to recurring problems in software architecture.
Which design patterns have you used in your project?
Answer:
This question is very subjective as every developer has his own experience. So we will pick
up three design patterns, i.e., factory, singleton, and facade, and discuss the same in more
depth. In case you are using some other design pattern below is the list with classification, go
and pick your best three.
There are three basic classifications of patterns Creational, Structural, and Behavioral
patterns.