GLOBAL INSTITUTE OF TECHNOLOGY

JAIPUR

DEPARTMENT OF COMPUTER SCIENCE AND

ENGINEERING

SYSTEM DESIGNING IN UML LAB

MANUAL
(5CS8A)
 INDEX
5CS8A: SYSTEM DESIGN IN UML LAB
MM 75
S NO. NAME OF EXPERIMENT Mapping PAGE NO REMARK

with PO

1 INTRODUCTION TO UML b&h 4-13

2 CASE STUDY OF ATM SYSTEM b&l 14-20

3 USE CASE DIAGRAM OF ATM SYSTEM a, c & e 21-24

4 CLASS DIAGRAM OF ATM SYSTEM b, h & k 25-27

5 SEQUENCE DIAGRAM OF ATM SYSTEM a, d & h 28-30

6 COLLABORATION DIAGRAM OF ATM SYSTEM b&l 31-34

7 STATE CHART DIAGRAM OF ATM SYSTEM b, h & k 35-36

8 ACTIVITY DIAGRAM OF ATM SYSTEM a, i & m 37-38

9 COMPONENT DIAGRAM OF ATM SYSTEM b&l 39-40

10 DEPLOYMENT DIAGRAM OF ATM SYSTEM b&h 41-42

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 1

 LAB OBJECTIVE:

5CS8A: SYSTEM DESIGN IN UML LAB

Introduction to UML notations and diagrams.

Hands on exposure of Visual Paradigm software for UML involving analysis and
design with UML diagrams.

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 2

 LAB ASSESMENT CRITERIA:
5CS8A: SYSTEM DESIGN IN UML LAB

TOTAL LAB MARKS: 75 Marks

INTERNAL: 45 Marks

EXTERNAL: 30 Marks

For assessment of work done during mid semester the Internal marks (60% component) is to be
distributed under the following heads:

1. Performance of Practical 50%

2. Timely submission of records 20%
3. Quiz/Viva 10%
4. Internal midterm practical-20%

For assessment of external marks (40% component) is to be distributed as:

1. Comprehensive Examination through Quiz/Viva/Performance 40%

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 3

 EXPERIMENT NO. 1

AIM: - KNOW ABOUT UNIFIED MODELLING LANGUAGE.

Introduction of UML
The Unified Modeling Language (UML) is a standard visual modeling language intended to be
used for
modeling business and similar processes,
analysis, design, and implementation of software-based systems
UML is a common language for business analysts, software architects and developers used to
describe, specify, design, and document existing or new business processes, structure and
behavior of artifacts of software systems.
UML can be applied to diverse application domains (e.g., banking, finance, internet, aerospace,
healthcare, etc.) It can be used with all major object and component software development
methods and for various implementation platforms (e.g., J2EE, .NET).
UML is a standard modeling language, not a software development process. UML 1.4.2
Specification explained that process:
provides guidance as to the order of a teams activities,
specifies what artifacts should be developed,
directs the tasks of individual developers and the team as a whole, and
offers criteria for monitoring and measuring a projects products and activities.
UML is intentionally process independent and could be applied in the context of different
processes. Still, it is most suitable for use case driven, iterative and incremental development
processes. An example of such process is Rational Unified Process (RUP).
UML is not complete and it is not completely visual. Given some UML diagram, we can't be
sure to understand depicted part or behavior of the system from the diagram alone. Some
information could be intentionally omitted from the diagram, some information represented on
the diagram could have different interpretations, and some concepts of UML have no graphical
notation at all, so there is no way to depict those on diagrams.
For example, semantics of multiplicity of actors and multiplicity of use cases on use case
diagrams is not defined precisely in the UML specification and could mean either concurrent or
successive usage of use cases.
Name of an abstract classifier is shown in italics while final classifier has no specific graphical
notation, so there is no way to determine whether classifier is final or not from the diagram.

VERSIONS OF UML

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 4

The current version of the Unified Modeling Language is UML 2.5, released in June
2015. UML specification (standard) is updated and managed by the Object Management
Group (OMG) OMG UML. The first versions of UML were created by "Three Amigos" - Grady
Booch (creator of Booch method), Ivar Jacobson (Object-Oriented Software Engineering,
OOSE), and Jim Rumbaugh (Object-Modeling Technique, OMT).

Version Date Description

1.1 11-1997 UML 1.1 proposal is adopted by the OMG.

1.3 03-2000 Contains a number of changes to the UML metamodel, semantics, and
notation, but should be considered a minor upgrade to the original
proposal.

1.4 09-2001 Mostly "tuning" release but not completely upward compatible with the
UML 1.3. Addition of profiles as UML extensions grouped together.
Updated visibility of features. Stick arrowhead in interaction diagrams now
denotes asynchronous call. Model element may now have
multiple stereotypes. Clarified collaborations. Refined definitions of
components and related concepts. Artifact was added to represent physical
representations of components.

1.5 03-2003 Added actions - executable actions and procedures, including their run-
time semantics, defined the concept of a data flow to carry data between
actions, etc.

1.4.2 01-2005 This version was accepted as ISO specification (standard) ISO/IEC 19501.
UML 1.5 was released 2 years before.

2.0 08-2005 New diagrams: object diagrams, package diagrams, composite structure
diagrams, interaction overview diagrams, timing diagrams, profile
diagrams. Collaboration diagrams were renamed to communication
diagrams.

Activity diagrams and sequence diagrams were enhanced. Activities were

redesigned to use a Petri-like semantics. Edges can now be contained in
partitions. Partitions can be hierarchical and multidimensional. Explicitly
modeled object flows are new.
Classes have been extended with internal structures and ports (composite
structures). Information flows were added. A collaboration now is a kind

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 5

 of classifier, and can have any kind of behavioral descriptions associated.
Interactions are now contained within classifiers and not only within
collaborations. It is now possible for use cases to be owned by classifiers in
general and not just packages.
New notation for concurrency and branching using combined fragments.
Notation and/or semantics were updated for components, realization,
deployments of artifacts. Components can no longer be directly deployed
to nodes. Artifacts should be deployed instead. Implementation has been
replaced by manifest. Artifacts can now manifest any packageable
element (not just components, as before). It is now possible to deploy to
nodes with an internal structure.
New meta classes were added: connector, collaboration use, connector
end, device, deployment specification, execution environment, accept
event action, send object action, structural feature action, value pin,
activity final, central buffer node, data stores, flow final, interruptible
regions, loop nodes, parameter, port, behavior, behaviored classifier,
duration, interval, time constraint, combined fragment, creation event,
destruction event, execution event, interaction fragment, interaction use,
receive signal event, send signal event, extension, etc.
Many stereotypes were eliminated from the Standard UML Profile, e.g.
destroy, facade, friend, profile, requirement, table, thread.
Integration between structural and behavioral models was improved with
better support for executable models.
2.1 04-2006 Minor revision to UML 2.0 - corrections and consistency improvements.

2.1.1 02-2007 Minor revision to the UML 2.1

2.1.2 11-2007 Minor revision to the UML 2.1.1

2.2 02-2009 Fixed numerous minor consistency problems and added clarifications to
UML 2.1.2

2.3 05-2010 Minor revision to the UML 2.2, clarified associations and association
classes, added final classifier, updated component diagrams, composite
structures, actions, etc.

2.4.1 08-2011 UML revision with few fixes and updates to classes, packages - added URI
package attribute; updated actions; removed creation event, execution
event, send and receive operation events, send and receive signal events,

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 6

 renamed destruction event to destruction occurrence
specification; profiles - changed stereotypes and applied stereotypes to
have upper-case first letter - Metaclassand stereotype application.

2.5 06-2015 UML 2.5 is called a "minor revision" to the UML 2.4.1, while they spent a
lot of efforts to simplify and reorganize UML specification document. The
UML specification was re-written "to make it easier to read". For example,
they tried to "reduce forward references as much as possible".

There are no longer two separate infrastructure and superstructure

documents, the UML 2.5 specification is a single document. Package
merge is no longer used within the specification.
Four UML compliance levels (L0, L1, L2, and L3) are eliminated, as they
were not useful in practice. UML 2.5 tools will have to support complete
UML specification. Information flows, models, and templates are no
longer auxiliary UML constructs. At the same time, use
cases, deployments, and the information flows became "supplementary
concepts" in UML 2.5.
UML 2.5 has a number of fixes, clarifications, and explanations added.
They updated description for multiplicity and multiplicity element,
clarified definitions of aggregation and composition, and finally fixed
wrong instantiate dependency example for Car Factory. New notation
for inherited members with a caret '^' symbol was introduced. UML 2.5
clarified feature redefinition and overloading. They also moved and
rephrased definition of qualifiers.
Default for generalization sets was changed from {incomplete,
disjoint} to {incomplete, overlapping}.
There are few clarifications and fixes for stereotypes, state machines, and
activities. Protocol state machines are now denoted using protocol
instead of {protocol}. Use cases are no longer required to express some
needs of actors and to be initiated by an actor.

CLASSIFICATION OF UML DIAGRAMS:-

UML specification defines two major kinds of UML diagram: structure diagrams and behavior
diagrams.

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 7

Structure diagrams show the static structure of the system and its parts on different abstraction
and implementation levels and how they are related to each other. The elements in a structure
diagram represent the meaningful concepts of a system, and may include abstract, real world and
implementation concepts.
Behavior diagrams show the dynamic behavior of the objects in a system, which can be
described as a series of changes to the system over time.
UML 2.5 diagrams could be categorized hierarchically as shown below. Note, items shown in
blue are not part of official UML 2.5 taxonomy of diagrams.

Fig:- UML 2.5 Diagram

UML 2.5 Structure Diagrams:-

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 8

Structure diagrams show static structure of the system and its parts on different abstraction
and implementation levels and how those parts are related to each other. The elements in a
structure diagram represent the meaningful concepts of a system, and may include abstract, real
world and implementation concepts.
Structure diagrams are not utilizing time related concepts; do not show the details of dynamic
behavior. However, they may show relationships to the behaviors of the classifiers exhibited in
the structure diagrams.

Diagram Purpose Elements

Class Shows structure of the designed system, subsystem class, interface, feature,constraint
diagram or component as related classes and interfaces, with , association,generalization, depe
their features, constraints and relationships - ndency.
associations, generalizations, dependencies, etc.

Object Instance level class diagram which shows instance Instance

diagram specifications of classes and interfaces (objects), specification, object,slot, link.
slots with value specifications, and links (instances
of association). Object diagram was defined in now
obsolete UML 1.4.2 Specification as "a graph of
instances, including objects and data values. A static
object diagram is an instance of a class diagram; it
shows a snapshot of the detailed state of a system at a
point in time." It also stated that object diagram is "a
class diagram with objects and no classes." UML
2.5 specification simply provides no definition of object
diagram.

Package Shows packages and relationships between the package, packageable

diagram packages. element,dependency, element
import,package import, package
merge.

Model UML auxiliary structure diagram which shows Model, package, packageable
diagram some abstraction or specific view of a system, to element, dependency.
describe architectural, logical or behavioral aspects
of the system. It could show, for example,
architecture of a multi-layered (aka multi-tiered)
application - see multi-layered application model.

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 9

Composite Diagram could be used to show: Internal structure
structure of a classifier A behavior of a collaboration
diagram

Internal Shows internal structure of a classifier - a Structured class, part, port,

structure decomposition of the classifier into its properties, connector, usage.
diagram parts and relationships.

Collaborati Shows objects in a system cooperating with each Collaboration, connector, part,
on use other to produce some behavior of the system. dependency.
diagram

Component Shows components and dependencies between component, interface,provided

diagram them. This type of diagrams is used forComponent- interface, required
Based Development (CBD), to describe systems interface, class, port,connector, ar
with Service-Oriented Architecture (SOA). tifact, component
realization, usage.

Manifestati While component diagrams show components and manifestation, component,artifact

on diagram relationships between components and classifiers, .
and deployment diagrams - deployments of artifacts
to deployment targets, some missing intermediate
diagram is manifestation diagram to be used to
show manifestation(implementation)
of components by artifacts and internal structure of
artifacts. Because manifestation diagrams are not
defined by UML 2.5 specification, manifestation of
components by artifacts could be shown using
either component diagrams or deployment
diagrams.

Deploymen Shows architecture of the system deployment, artifact,deployment

t diagram as deployment (distribution) of software artifacts target, node,device, execution
to deployment targets. environment,communication
path,deployment specification,
Note, that components were directly deployed to
nodes in UML 1.x deployment diagrams. In UML
2.x artifacts are deployed to nodes, and artifacts
could manifest (implement) components.
Components are deployed to nodes indirectly

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 10

 through artifacts.
Specification level deployment diagram (also called
type level) shows some overview of
deployment of artifacts to deployment targets,
without referencing specific instances of artifacts or
nodes.
Instance level deployment diagram shows
deployment of instances of artifacts to specific
instances of deployment targets. It could be used
for example to show differences in deployments to
development, staging or production environments
with the names/ids of specific build or deployment
servers or devices.
Network Deployment diagrams could be used to show node, switch, router, load
architecture logical or physical network architecture of the balancer, firewall,communication
diagram system. This kind of deployment diagrams - not path, network
formally defined in UML 2.5 - could be called segment, backbone.
network architecture diagrams.

Profile Auxiliary UML diagram which allows to define profile, metaclass, stereotype,exte
diagram custom stereotypes, tagged values, and constraints nsion, reference, profile
as a lightweight extension mechanism to the UML application.
standard. Profiles allow to adapt the UML
metamodel for different platforms (such as J2EE or
.NET), or domains (such as real-time or business
process modeling).Profile diagrams were first
introduced in UML 2.0.

UML 2.5 Behavior Diagrams:-

Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a
series of changes to the system over time.

Diagram Purpose Elements

Use case Describes a set of actions (use cases) that some Usecase, Actor,subject,
diagram system or systems (subject) should or can perform in extend, include,
collaboration with one or more external users of the association.
system (actors) to provide some observable and

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 11

 valuable results to the actors or other stakeholders of
the system(s).

Information Shows exchange of information between system information flow,

flow diagram entities at some high levels of abstraction. information item,
Information flows may be useful to describe actor, class.
circulation of information through a system by
representing aspects of models not yet fully specified
or with less details.

Activity Shows sequence and conditions for coordinating Activity, partition, actio
diagram lower-level behaviors, rather than which classifiers n,
own those behaviors. These are commonly object, control, activity
called control flow and object flow models. edge.

State Used for modeling discrete behavior through finite

machine state transitions. In addition to expressing the
diagram behavior of a part of the system, state machines can
also be used to express the usage protocol of part of a
system. These two kinds of state machines are
referred to as behavioral state machines and protocol
state machines.

Behavioral Shows discrete behavior of a part of designed system Behavioral

state machine through finite state transitions. state, behavioral
diagram transition, pseudo state.

Protocol state Shows usage protocol or a lifecycle of Protocol state, protocol

machine some classifier, e.g. which operations of the classifier transition, pseudo state.
diagram may be called in each state of the classifier, under
which specific conditions, and satisfying some
optional post conditions after the classifier transitions
to a target state.

Interaction Interaction diagrams include several different types

diagram of diagrams:

sequence diagrams,
communication diagrams (known as collaboration

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 12

 diagrams in UML 1.x),
timing diagrams,
interaction overview diagrams.
Sequence Most common kind of interaction diagrams which Lifeline, execution
diagram focuses on the message interchange between specification, message,
lifelines (objects). combined fragment,
interaction use, state
invariant, destruction
occurrence.

Communicati Focuses on the interaction between lifelines where Lifeline, message.

on the architecture of the internal structure and how this
diagram (a.k. corresponds with the message passing is central. The
a.Collaborati sequencing of messages is given through a sequence
on diagram numbering scheme.
in UML 1.x)

Timing Shows interactions when a primary purpose of the Lifeline, state or

diagram diagram is to reason about time. Timing diagrams condition timeline,
focus on conditions changing within and among destruction event,
lifelines along a linear time axis. duration constraint,
time constraint.

Interaction Defines interactions through a variant of activity initial node, flow final
overview diagrams in a way that promotes overview of the node, activity final
diagram control flow. Interaction overview diagrams focus on node, decision node,
the overview of the flow of control where the nodes merge node, fork node
are interactions or interaction uses. The lifelines and , join node, interaction,
the messages do not appear at this overview level. interaction use, duration
constraint, time
constraint.

RESULT: - Study of Unified Modelling Language done.

PO a b c d e f g h i j k l m

mapping

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 13

 EXPERIMENT NO. 2

AIM: - Case Study of ATM & its UML Diagrams.

Fig:- An ATM Machine

A cash machine, also known as an automated teller machine is an electronic telecommunications

device that enables the customers of a financial institution to perform financial transactions,
particularly cash withdrawal, without the need for a human cashier, clerk or bank teller. On most
modern cash machines, the customer is identified by inserting a plastic ATM card with
a magnetic stripe or a plastic smart card with a chip that contains a unique card number and some
security information such as an expiration date or CVVC (CVV). Authentication is provided by
the customer entering a personal identification number (PIN).

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 14

Using a cash machine, customers can access their bank deposit or credit accounts in order to
make a variety of transactions such as cash withdrawals, check balances, or credit mobile
phones. If the currency being withdrawn from the cash machine is different from that in which
the bank account is denominated the money will be converted at an official exchange rate. Thus,
cash machines often provide the best possible exchange rates for foreign travelers, and are
widely used for this purpose.

History
The idea of out-of-hours cash distribution developed from bankers' needs in Asia (Japan),
Europe (Sweden and the United Kingdom) and North America (the United States).Little is
known of the Japanese device other than it was called "Computer Loan Machine" and supplied
cash as a three-month loan at 5% p.a. after inserting a credit card. The device was operational in
1966.
In the US patent record, Luther George Simjian has been credited with developing a "prior art
device". Specifically his 132nd patent (US3079603), which was first filed on 30 June 1960 (and
granted 26 February 1963). The roll-out of this machine, called Bankograph, was delayed by a
couple of years, due in part to Simjian's Reflectone Electronics Inc. being acquired by Universal
Match Corporation.An experimental Bankograph was installed in New York City in 1961 by
the City Bank of New York, but removed after six months due to the lack of customer
acceptance. The Bankograph was an automated envelope deposit machine (accepting coins, cash
and cheques) and did not have cash dispensing features.

Actor Reg Varney using the world's first cash machine in Enfield Town, north London on 27
June 1967

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 15

It is widely accepted that the first cash machine was put into use by Barclays Bank in its Enfield
Town branch in north London, United Kingdom, on 27 June 1967. This machine was
inaugurated by English comedy actor Reg Varney. This instance of the invention is credited to
the engineering team lead by John Shepherd-Barron of printing firm De La Rue, who was
awarded an OBE in the 2005 New Year Honours. Transactions were initiated by inserting paper
cheques issued by a teller or cashier, marked with carbon-14 for machine readability and
security, which in a latter model were matched with a six digit personal identification number
(PIN). Shepherd-Barron stated; "It struck me there must be a way I could get my own money,
anywhere in the world or the UK. I hit upon the idea of a chocolate bar dispenser, but replacing
chocolate with cash."
The Barclays-De La Rue machine (called De La Rue Automatic Cash System or DACS) beat
the Swedish saving banks' and a company called Metior's machine (a device called Bankomat)
by a mere nine days and Westminster Banks-Smith Industries-Chubb system (called Chubb
MD2) by a month. The online version of the Swedish machine is listed to have been operational
on 6 May 1968, while claiming to be the first online cash machine in the world (ahead of a
similar claim by IBM and Lloyds Bank in 1971). The collaboration of a small start-up called
Speytec and Midland Bank developed a fourth machine which was marketed after 1969 in
Europe and the US by the Burroughs Corporation. The patent for this device (GB1329964) was
filed on September 1969 (and granted in 1973) by John David Edwards, Leonard Perkins, John
Henry Donald, Peter Lee Chappell, Sean Benjamin Newcombe & Malcom David Roe.
Both the DACS and MD2 accepted only a single-use token or voucher which was retained by the
machine while the Speytec worked with a card with a magnetic stripe at the back. They used
principles including Carbon-14 and low-coercivity magnetism in order to make fraud more
difficult.
Cash machine of Sber bank inTolyatti, Russia

The idea of a PIN stored on the card was developed by a British engineer working on the MD2
named James Goodfellow in 1965 (patent GB1197183 filed on 2 May 1966 with Anthony
Davies). The essence of this system was that it enabled the verification of the customer with the
debited account without human intervention. This patent is also the earliest instance of a
complete "currency dispenser system" in the patent record. This patent was filed on 5 March
1968 in the US (US 3543904) and granted on 1 December 1970. It had a profound influence on
the industry as a whole. Not only did future entrants into the cash dispenser market such as NCR
Corporation and IBM licence Goodfellows PIN system, but a number of later patents reference
this patent as "Prior Art Device". Cash machines are placed not only near or inside the premises

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 16

of banks, but also in locations such as shopping centers/malls, airports, grocery stores, petrol/gas
stations, restaurants, or anywhere frequented by large numbers of people. There are two types of
cash machine installations: on- and off-premises. On-premises cash machines are typically more
advanced, multi-function machines that complement a bank branch's capabilities, and are thus
more expensive. Off-premises machines are deployed by financial institutions and Independent
Sales Organizations (ISOs) where there is a simple need for cash, so they are generally cheaper
single function devices.

Global use
There are no hard international or government-compiled numbers totaling the complete number
of cash machines in use worldwide. Estimates developed by ATMIA place the number of cash
machines in use currently at more than 2.2 million, or approximately 1 cash machine per 3000
people in the world.
To simplify the analysis of cash machine usage around the world, financial institutions generally
divide the world into seven regions, due to the penetration rates, usage statistics, and features
deployed. Four regions (USA, Canada, Europe, and Japan) have high numbers of cash machines
per million people. Despite the large number of cash machines, there is additional demand for
machines in the Asia/Pacific area as well as in Latin America. Cash machines have yet to reach
high numbers in the Near East and Africa.
The world's most southerly installed cash machine is located at McMurdo Station, located
in New Zealand's Ross Dependency, in Antarctica since 1997. There are two cash machines at
McMurdo, but only one active at any time, that are owned by Wells Fargo and serviced once
every two years by NCR.
Cash machines are ubiquitous on modern cruise ships and also can be found on some US
Navy ships.

Hardware
A cash machine is typically made up of the following devices:

CPU (to control the user interface and transaction devices)

Magnetic or chip card reader (to identify the customer)
PIN pad EEP4 (similar in layout to a touch tone or calculator keypad), manufactured as part
of a secure enclosure
Secure cryptoprocessor, generally within a secure enclosure

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 17

 Display (used by the customer for performing the transaction)
Function key buttons (usually close to the display) or a touch screen (used to select the
various aspects of the transaction)
Record printer (to provide the customer with a record of the transaction)
Vault (to store the parts of the machinery requiring restricted access)
Housing (for aesthetics and to attach signage to)
Sensors and indicators

Software

With the migration to commodity Personal Computer hardware, standard commercial "off-
the-shelf" operating systems and programming environments can be used inside of cash
machines. Typical platforms previously used in cash machine development
include RMX or OS/2.

Today, the vast majority of cash machines worldwide use a Microsoft Windows operating
system, primarily Windows XP Professional or Windows XP Embedded. A small number of
deployments may still be running older versions of the Windows OS, such as Windows
NT, Windows CE, or Windows 2000.
There is a computer industry security view that general public desktop operating systems (os)
have greater risks as operating systems for cash dispensing machines than other types of
operating systems like (secure) real-time operating systems (RTOS). RISKS Digest has many
articles about cash machine operating system vulnerabilities.
Linux is also finding some reception in the cash machine marketplace. An example of this
is Banrisul, the largest bank in the south of Brazil, which has replaced the MS-DOS operating
systems in its cash machines with Linux. Banco do Brasil is also migrating cash machines to
Linux. Indian-based Vortex Engineering is manufacturing cash machines which operate only
with Linux. Common application layer transaction protocols, such as Diebold 91x (911 or 912)
and NCR NDC or NDC+ provide emulation of older generations of hardware on newer platforms
with incremental extensions made over time to address new capabilities, although companies like
NCR continuously improve these protocols issuing newer versions (e.g. NCR's AANDC v3.x.y,
where x.y are subversions). Most major cash machine manufacturers provide software packages

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 18

that implement these protocols. Newer protocols such as IFX have yet to find wide acceptance
by transaction processors.
With the move to a more standardized software base, financial institutions have been
increasingly interested in the ability to pick and choose the application programs that drive their
equipment. WOSA/XFS, now known as CEN XFS (or simply XFS), provides a common API for
accessing and manipulating the various devices of a cash machine. J/XFS is a Java
implementation of the CEN XFS API.
While the perceived benefit of XFS is similar to the Java's "Write once, run anywhere" mantra,
often different cash machine hardware vendors have different interpretations of the XFS
standard. The result of these differences in interpretation means that cash machine applications
typically use a middleware to even out the differences among various platforms.

ATM Card

An ATM card is any payment card issued by a financial institution that enables a customer to
access an automated teller machine (ATM) in order to perform transactions such as deposits,
cash withdrawals, obtaining account information, etc. ATM cards are known by a variety of
names such as bank card, MAC (money access card), client card, key card or cash card, among
others. Most payment cards, such as debit and credit cards can also function as ATM cards,
although ATM-only cards are also available. Charge and proprietary cards cannot be used as
ATM cards. The use of a credit card to withdraw cash at an ATM is treated differently to
a POS transaction, usually attracting interest charges from the date of the cash
withdrawal. Interbank networks allow the use of ATM cards at ATMs of private operators and
financial institutions other than those of the institution that issued the cards.
ATM cards can also be used on improvised ATMs such as "mini ATMs", merchants' card
terminals that deliver ATM features without any cash drawer. These terminals can also be used
as cashless scrip ATMs by cashing the receipts they issue at the merchant's point of sale. The
size of ATM cards is 85.60 mm 53.98 mm (3.370 in 2.125 in) and rounded corners with a
radius of 2.883.48 mm, in accordance with ISO/IEC 7810#ID-1, the same size as other payment
cards, such as credit, debit and other cards. They also have an embossed bank card
number conforming to the ISO/IEC 7812 numbering standard.
All ATM machines, at a minimum, will permit cash withdrawals of customers of the machine's
owner (if a bank-operated machine) and for cards that are affiliated with any ATM network the

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 19

machine is also affiliated. They will report the amount of the withdrawal and any fees charged by
the machine on the receipt. Most banks and credit unions will permit routine account-related
banking transactions at the bank's own ATM, including deposits, checking the balance of an
account, and transferring money between accounts. Some may provide additional services, such
as selling postage stamps.

PO Mapping :-

PO a b c d e f g h i j k l m

mapping

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 20

 Experiment No. 3

Design a Use Case Diagram for ATM System & Describe in Detail.

Fig:- Use Case Diagram of ATM System

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 21

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

System Shutdown Use Case

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

Session Use Case

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

Transaction Use Case

Note: Transaction is an abstract generalization. Each specific concrete type of given here
describes the behavior common to all types of transaction. The flows of events for the individual
types of transaction (withdrawal, deposit, transfer, inquiry) give the features that are specific to
that type of transaction A transaction use case is started within a session when the customer
chooses a transaction type from a menu of options. The customer will be asked to furnish
appropriate details (e.g. account(s) involved, amount). The transaction will then be sent to the
bank, along with information from the customer's card and the PIN the customer entered.

Withdrawal Transaction Use Case

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

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 22

Deposit Transaction Use Case

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking)
from a menu of possible accounts, and to type in a dollar amount on the keyboard. The
transaction is initially sent to the bank to verify that the ATM can accept a deposit from this
customer to this account. If the transaction is approved, the machine accepts an envelope from
the customer containing cash and/or checks before it issues a receipt. Once the envelope has been
received, a second message is sent to the bank, to confirm that the bank can credit the customer's
account - contingent on manual verification of the deposit envelope contents by an operator later.
(The receipt of an envelope is also recorded in the ATM's log.) A deposit transaction can be
cancelled by the customer pressing the Cancel key any time prior to inserting the envelope
containing the deposit. The transaction is automatically cancelled if the customer fails to insert
the envelope containing the deposit within a reasonable period of time after being asked to do so.
Transfer Transaction Use Case

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

Inquiry Transaction Use Case

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

An invalid PIN extension is started from within a transaction when the bank reports that the
customer's transaction is disapproved due to an invalid PIN. to the bank again. If the bank
now approves the transaction, or disapprove sit for some other reason, the original use case
is continued; otherwise the process of re-entering the PIN is repeated. Once the PIN is
successfully re-entered, it is used for both the current transaction and all subsequent
transactions in the session. If the customer fails three times to enter the correct PIN, the card
is permanently retained, a screen is displayed informing the customer of this and suggesting
he/she contact the bank, and the entire customer session is aborted.
PO a b c d e f g h i j k l m

mapping

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 23

 Experiment No. 4

Design a Class Diagram for ATM System & Describe in Detail.

The basic structure of the class diagram arises from the responsibilities and relationships
discovered when doing the CRC cards and Interaction Diagrams. (If a class uses another class as
a collaborator, or sends a message to an object of that class during an Interaction, then there must
either be an association linking objects of those classes, or linking the "sending" class to an
object which provides access to an object of the "receiving" class.)

In the case of the ATM system, one of the responsibilities of the ATM is to provide access to its
component parts for Session and Transaction objects; thus, Session and Transaction have
associations to ATM, which in turn has associations to the classes representing the individual
component parts. (Explicit "uses" links between Session and Transaction, on the one hand, and
the component parts of the ATM, on the other hand, have been omitted from the diagram to
avoid making it excessively cluttered.)

The need for the various classes in the diagram was discovered at various points in the design
process.

Some classes were discovered when doing CRC cards

o Message - used to represent a message to the bank.

o Receipt - used to encapsulate information to be printed on a receipt.
o Status - used to represent return value from message to the bank.
o Balances - used to record balance information returned by the bank.

Some classes were discovered when doing detailed design or writing code

o Money - used to represent money amounts, in numerous places.

o AccountInformation - contains names of various types of accounts customer can
choose from

That is, OO design is not a "waterfall" process - discoveries made when doing detailed design
and coding can impact overall system design.

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 24

 Fig:- ATM Class Diagram

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 25

 Fig: Class Diagram of ATM (Another)

PO a b c d e f g h i j k l m

mapping

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 26

 Experiment No. 5

Design a State Chart Diagram for ATM System & Describe in

Detail.

Three of the objects we have identified have behavior that is sufficiently complex to warrant
developing a State Chart for them. (These are the objects that were identified as the major
controller objects.)

The object representing the machine itself (responsible for the System Startup and
Shutdown use cases)
Objects representing a customer session (one per session) (responsible for the Session use
case)
Objects representing an individual transaction (one per transaction) (responsible for the
Transaction use case, use cases for the specific types of transaction, and Invalid PIN
extension).

Fig:- State-Chart for Overall ATM

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 27

 Fig:- State-Chart Diagram for One Session

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 28

 Fig:- State-Chart Diagram for one transaction

PO a b c d e f g h i j k l m

mapping

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 29

 Experiment No. 6

Design a Sequence Diagram for ATM System & Describe in Detail.

UML defines two types of Interaction Diagram: the Sequence Diagram and the Collaboration
Diagram. In order to illustrate both types, the major use cases are documented using Sequence
Diagrams, and the specific sub cases of transaction (withdrawal, etc.) and the Invalid PIN
Extension are documented using Collaboration Diagrams. (The major reason for using two
different types of diagram is pedagogical - to illustrate each type.)
A sequence diagram emphasizes the time ordering of messages. Sequence diagrams have two
features that distinguish them from collaboration diagrams.

(i)Object life time

(ii) The focus of

control

We have two types of interaction diagrams in UML. One is sequence diagram and the
other is a collaboration diagram. The sequence diagram captures the time sequence of message
flow from one object to another and the collaboration diagram describes the organization of ob-
jects in a system taking part in the message flow.

Purpose:
1. To capture dynamic behaviour of a system.

2. To describe the message flow in the system.

3. To describe structural organization of the objects.

4. To describe interaction among objects.

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 30

 Fig:- Sequence Diagram for ATM Startup & Shutdown Process

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 31

 Fig:- Session Sequence Diagram for ATM

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 32

 Fig:- Transaction Sequence Diagram for ATM

PO a b c d e f g h i j k l m

mapping

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 33

 Experiment No. 7

Design a Collaboration/Communication Diagram for ATM System

& Describe in Detail.

A Communication diagram models the interactions between objects or parts in terms of

sequenced messages. Communication diagrams represent a combination of information taken
from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic
behavior of a system.
However, communication diagrams use the free-form arrangement of objects and links as used in
Object diagrams. In order to maintain the ordering of messages in such a free-form diagram,
messages are labeled with a chronological number and placed near the link the message is sent
over. Reading a communication diagram involves starting at message 1.0, and following the
messages from object to object.
Communication diagrams show a lot of the same information as sequence diagrams, but because
of how the information is presented, some of it is easier to find in one diagram than the other.
Communication diagrams show which elements each one interacts with better, but sequence
diagrams show the order in which the interactions take place more clearly.

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 34

 Fig:- Communication Diagram for ATM explaining Invalid Pin System
PO a b c d e f g h i j k l m

mapping

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 35

 Experiment No. 8

Design an Activity Diagram for ATM System & Describe in Detail.

Activity diagram is basically a flow chart to represent the flow form one activity to another . The
activity can be described as an operation of the system. So the control flow is drawn from one
operation to another. This flow can be sequential, branched or concurrent. Ac-tivity diagrams
deals with all type of flow by using elements like fork, join etc.
Contents
Initial/Final State , Activity , Fork & Join , Branch , Swim lanes

Fork
A fork represents the splitting of a single flow of control into two or more concur-rentFlow of
control. A fork may have one incoming transition and two or more outgoing transi-tions, each of
which represents an independent flow of control. Below fork the activities asso-ciated with each
of these path continues in parallel.

Join
A join represents the synchronization of two or more concurrent flows of control. A join may
have two or more incoming transition and one outgoing transition. Above the join the activ-ities
associated with each of these paths continues in parallel.

Branching
A branch specifies alternate paths takes based on some Boolean expression Branch is represented
by diamond Branch may have one incoming transition and two or more outgoing one on each
outgoing transition, you place a Boolean expression shouldnt overlap but they should cover all
possibilities.

Swim lane:
Swim lanes are useful when we model workflows of business processes to partition the activity
states on an activity diagram into groups. Each group representing the business organization
responsible for those activities , these groups are called Swimlanes .

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 36

 Fig:- Activity Diagram for ATM System
PO a b c d e f g h i j k l m

mapping

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 37

 Experiment No. 9

Design a Component Diagram for ATM System & Describe in

Detail.

Component diagrams are different in terms of nature and behaviour. Component diagrams are
used to model physical aspects of a system. Now the question is what are these physical
aspects? Physical aspects are the elements like executables, libraries, files, documents etc which
resides in a node. So component diagrams are used to visualize the organization and
relationships among components in a system. These diagrams are also used to make executable
systems.

Component diagram is a special kind of diagram in UML. The purpose is also different from all
other diagrams discussed so far. It does not describe the functionality of the system but it
describes the components used to make those functionalities. So from that point component
diagrams are used to visualize the physical components in a system. These components are
libraries, packages, files etc. Component diagrams can also be described as a static
implementation view of a system. Static implementation represents the organization of the
components at a particular moment. A single component diagram cannot represent the entire
system but a collection of diagrams are used to represent the whole.

So the purpose of the component diagram can be summarized as:

Visualize the components of a system.

Construct executables by using forward and reverse engineering.

Describe the organization and relationships of the components

These diagrams show the physical components of a system. To clarify it, we can say that
component diagrams describe the organization of the components in a system. Organization can
be further described as the location of the components in a system. These components are
organized in a special way to meet the system requirements. As we have already discussed those
components are libraries, files, executables etc. Now before implementing the application these
components are to be organized. This component organization is also designed separately as a

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 38

part of project execution. Component diagrams are very important from implementation
perspective. So the implementation team of an application should have a proper knowledge of
the component details.

Now the usage of component diagrams can be described as:

Model the components of a system.

Model database schema.

Model executables of an application.

Model system's source code.

PO a b c d e f g h i j k l m

mapping

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 39

 Experiment No. 10

Design a Deployment Diagram for ATM System & Describe in

Detail.

Deployment diagrams are used to visualize the topology of the physical components of a system
where the software components are deployed. So deployment diagrams are used to describe the
static deployment view of a system. Deployment diagrams consist of nodes and their
relationships. The name Deployment itself describes the purpose of the diagram. Deployment
diagrams are used for describing the hardware components where software components are
deployed. Component diagrams and deployment diagrams are closely related. Component
diagrams are used to describe the components and deployment diagrams shows how they are
deployed in hardware.

UML is mainly designed to focus on software artifacts of a system. But these two diagrams are
special diagrams used to focus on software components and hardware components. So most of
the UML diagrams are used to handle logical components but deployment diagrams are made to
focus on hardware topology of a system. Deployment diagrams are used by the system
engineers.

The purpose of deployment diagrams can be described as:

Visualize hardware topology of a system.

Describe the hardware components used to deploy software components.

Describe runtime processing nodes.

Deployment diagram represents the deployment view of a system. It is related to the component
diagram. Because the components are deployed using the deployment diagrams. A deployment
diagram consists of nodes. Nodes are nothing but physical hardwares used to deploy the
application. Deployment diagrams are useful for system engineers. An efficient deployment
diagram is very important because it controls the following parameters

Performance

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 40

 Scalability

Maintainability

Portability

So before drawing a deployment diagram the following artifacts should be identified:

Nodes

Relationships among nodes

Fig:- Deployment Diagram for ATM

PO a b c d e f g h i j k l m

mapping

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 41

 Viva Questions & Their Answers
1. Question: What is UML?
Answer: UML stands for the Unified Modeling Language.
It is a graphical language for 1) visualizing, 2) constructing, and 3) documenting the artifacts of
a system.
It allows you to create a blue print of all the aspects of the system, before actually physically
implementing the system.
2. Question: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.
3. Question: What are the different views that are considered when building an object-oriented
software system?
Answer: Normally there are 5 views.
1. Use Case view - This view exposes the requirements of a system.
2. Design View - Capturing the vocabulary.
3. Process View - modeling the distribution of the systems processes and threads.
4. Implementation view - addressing the physical implementation of the system.
5. Deployment view - focus on the modeling the components required for deploying the system.
4. Question:What are the major three types of modeling used?
Answer:
The 3 Major types of modeling are
1. architectural,
2. behavioral, and
3. structural.

Question:Name 9 modeling diagrams that are frequently used?

Answer:
9 Modeling diagrams that are commonly used are

1. Use case diagram

2. Class Diagram
3. Object Diagram
4. Sequence Diagram
5. Statechart Diagram
6. Collaboration Diagram
7. Activity Diagram
8. Component diagram

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 42

9. Deployment Diagram.

Question:How would you define Architecture?

Answer:
Architecture is not only taking care of the structural and behavioral aspect of a software system but also
taking into account the software usage, functionality, performance, reuse, economic and technology
constraints.

Question:What are Relationships?

Answer: There are different kinds of relationships:

1. Dependencies,
2. Generalization, and
3. Association.

Dependencies are relationships between two entities.

A change in specification of one thing may affect another thing.
Most commonly it is used to show that one class uses another class as an argument in the
signature of the operation.

Generalization is relationships specified in the class subclass scenario, it is shown when one
entity inherits from other.
Associations are structural relationships that are:

1. a room has walls,

2. Person works for a company.

Aggregation is a type of association where there is a has a relationship.

As in the following examples: A room has walls, or if there are two classes room and walls then the
relation ship is called a association and further defined as an aggregation.

Question:Static Diagrams (Also called Structural Diagram):

Answer:
The following diagrams are static diagrams.

1. Class diagram,
2. Object diagram,
3. Component Diagram,
4. Deployment diagram.

Question:Dynamic Diagrams (Also called Behavioral Diagrams):

Answer:
The following diagrams are dynamic diagrams.

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 43

1. Use Case Diagram,
2. Sequence Diagram,
3. Collaboration Diagram,
4. Activity diagram,
5. Statechart diagram.

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

Question:What is an Use Case?

Answer: A use case specifies the behavior of a system or a part of a system.
Use cases are used to capture the behavior that need to be developed.
It involves the interaction of actors and the system.

What is an Use Case?

A use case specifies the behavior of a system or a part of a system, se cases are used to capture
the behavior that need to be developed. It involves the interaction of actors and the system.

Can you explain Extend and Include in use cases?

Extend and Include define relationships between use cases. Below figure Extend and
Include shows how these two fundamentals are implemented in a project. The below use case
represents a system which is used to maintain customer. When a customer is added successfully
it should send an email to the admin saying that a new customer is added. Only admin have
rights to modify the customer. First lets define extend and include and then see how the same fits
in this use case scenario.

Include: Include relationship represents an invocation of one use case by the other. If you
think from the coding perspective its like one function been called by the other function.
Extend: This relationship signifies that the extending use case will work exactly like the
base use case only that some new steps will inserted in the extended use case.

How do we represent private, public and protected in class diagrams?

In order to represent visibility for properties and methods in class diagram we need to place
symbols next to each property and method as shown in figure Private, Public and Protected. +
indicates that its public properties/methods. -indicates private properties which means it can
not be accessed outside the class. # indicate protected/friend properties. Protected properties
can only be seen within the component and not outside the component.

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 44

Can you explain sequence diagrams?
Sequence diagram shows interaction between objects over a specific period time. The message
flow is shown vertically in waterfall manner i.e. it starts from the top and flows to the bottom.
Dashed lines represent the duration for which the object will be live. Horizontal rectangles on the
dashed lines represent activation of the object. Messages sent from a object is represented by
dark arrow and dark arrow head. Return message are represented by dotted arrow.

Can you explain primary and secondary actors?

Actors are further classified in to two types primary and secondary actors. Primary actors are the
users who are the active participants and they initiate the user case, while secondary actors are
those who only passively participate in the use case.

Can you explain use case diagrams?

Use case diagram answers what system does from the user point of view. Use case answer What
will the system do?. Use cases are mainly used in requirement document to depict clarity
regarding a system. There are three important parts in a use case scenario, actor and use case.

Scenario: A scenario is a sequence of events which happen when a user interacts with the
system.
Actor: Actor is the who of the system, in other words the end user.
Use Case: Use case is task or the goal performed by the end user. Below figure Use
Case shows a simple scenario with Actor and a Use Case. Scenario represents an
accountant entering accounts data in the system. As use cases represent action performed
they are normally represented by strong verbs.

Can you explain aggregation and composition in class diagrams?

In this Association there are two types mainly Aggregation Association and Composition
Association.
Aggregation Association signifies that the child objects can exist without the Aggregated Object.
Composition on the other hand represents a strict "has a" relationship wherein child objects are
tightly bound to the parent class and life of its instance depends upon lifetime of top level class
instance. For example say we have three classes University class, Department class and the
Professor Class. The Department cannot exist without university which means that if University
is closed the Department will also be closed. In other words lifetime of the Department depend
on the lifetime of University. This is an example of composition. On the other hand instances of
Professor class can continue to exist even if a Department is shutdown representing and
aggregation association with Department class.

GLOBAL INSTITUTE OF TECHNOLOGY, JAIPUR Page 45