1 EXN0 : 1 DATE : 09.07.2009 STUDY OF UML AIM: General study of UML. DESCRIPTION: The heart of object-oriented problem solving is the construction of a model. The model abstracts the essential details of the underlying problem from its usually complicated real world. Several modeling tools are wrapped under the heading of the UML™, which stands for Unified Modeling Language™. The purpose of this course is to present important highlights of the UML. At the center of the UML are its nine kinds of modeling diagrams, which we describe here. Use case diagrams Class diagrams Object diagrams Sequence diagrams Collaboration diagrams State chart diagrams Activity diagrams Component diagrams Deployment diagrams Some of the sections of this course contain links to pages with more detailed information. And every section has short questions. Use them to test your understanding of the section topic. Why is UML important?
Transcript
1
EX N0 : 1DATE : 09.07.2009
STUDY OF UML
AIM:
General study of UML.
DESCRIPTION:
The heart of object-oriented problem solving is the construction of a model. The
model abstracts the essential details of the underlying problem from its usually complicated
real world. Several modeling tools are wrapped under the heading of the UML™, which
stands for Unified Modeling Language™. The purpose of this course is to present important
highlights of the UML.
At the center of the UML are its nine kinds of modeling diagrams, which we describe
here.
Use case diagrams
Class diagrams
Object diagrams
Sequence diagrams
Collaboration diagrams
State chart diagrams
Activity diagrams
Component diagrams
Deployment diagrams
Some of the sections of this course contain links to pages with more detailed
information. And every section has short questions. Use them to test your understanding of
the section topic.
Why is UML important?
2
Let's look at this question from the point of view of the construction trade. Architects
design buildings. Builders use the designs to create buildings. The more complicated the
building, the more critical the communication between architect and builder. Blueprints are
the standard graphical language that both architects and builders must learn as part of their
trade.
Writing software is not unlike constructing a building. The more complicated the
underlying system, the more critical the communication among everyone involved in creating
and deploying the software. In the past decade, the UML has emerged as the software
blueprint language for analysts, designers, and programmers alike. It is now part of the
software trade. The UML gives everyone from business analyst to designer to programmer a
common vocabulary to talk about software design.
The UML is applicable to object-oriented problem solving. Anyone interested in
learning UML must be familiar with the underlying tenet of object-oriented problem solving -
- it all begins with the construction of a model. A model is an abstraction of the underlying
problem. The domain is the actual world from which the problem comes.Models consist of
objects that interact by sending each other messages. Think of an object as "alive." Objects
have things they know (attributes) and things they can do (behaviors or operations). The
values of an object's attributes determine its state.
Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviors
(methods or functions) into a single distinct entity. Objects are instances of classes.
Use case diagrams:
Use case diagrams describe what a system does from the standpoint of an external
observer. The emphasis is on what a system does rather than how.
Use case diagrams are closely connected to scenarios. A scenario is an example of what
happens when someone interacts with the system. Here is a scenario for a medical clinic.
"A patient calls the clinic to make an appointment for a yearly checkup. The
receptionist finds the nearest empty time slot in the appointment book and schedules
the appointment for that time slot. "
3
A use case is a summary of scenarios for a single task or goal. An actor is who or
what initiates the events involved in that task. Actors are simply roles that people or objects
play. The picture below is a Make Appointment use case for the medical clinic. The actor is
a Patient. The connection between actor and use case is a communication association (or
communication for short).
Actors are stick figures. Use cases are ovals. Communications are lines that link
actors to use cases.
A use case diagram is a collection of actors, use cases, and their communications.
We've put Make Appointment as part of a diagram with four actors and four use cases.
Notice that a single use case can have multiple actors.
Use case diagrams are helpful in three areas.
determining features (requirements). New use cases often generate new
requirements as the system is analyzed and the design takes shape.
communicating with clients. Their notational simplicity makes use case diagrams a
good way for developers to communicate with clients.
generating test cases. The collection of scenarios for a use case may suggest a suite
of test cases for those scenarios.
Class diagrams
4
A Class diagram gives an overview of a system by showing its classes and the
relationships among them. Class diagrams are static -- they display what interacts but not
what happens when they do interact.
The class diagram below models a customer order from a retail catalog. The central
class is the Order. Associated with it are the Customer making the purchase and the
Payment. A Payment is one of three kinds: Cash, Check, or Credit. The order contains
OrderDetails (line items), each with its associated Item.
UML class notation is a rectangle divided into three parts: class name, attributes, and
operations. Names of abstract classes, such as Payment, are in italics. Relationships between
classes are the connecting links.
Our class diagram has three kinds of relationships.
association -- a relationship between instances of the two classes. There is an
association between two classes if an instance of one class must know about the other
in order to perform its work. In a diagram, an association is a link connecting two
classes.
aggregation -- an association in which one class belongs to a collection. An
aggregation has a diamond end pointing to the part containing the whole. In our
diagram, Order has a collection of OrderDetails.
5
generalization -- an inheritance link indicating one class is a superclass of the other.
A generalization has a triangle pointing to the superclass. Payment is a superclass of
Cash, Check, and Credit.
An association has two ends. An end may have a role name to clarify the nature of the
association. For example, an OrderDetail is a line item of each Order.
A navigability arrow on an association shows which direction the association can be
traversed or queried. An OrderDetail can be queried about its Item, but not the other way
around. The arrow also lets you know who "owns" the association's implementation; in this
case, OrderDetail has an Item. Associations with no navigability arrows are bi-directional.
The multiplicity of an association end is the number of possible instances of the class
associated with a single instance of the other end. Multiplicities are single numbers or ranges
of numbers. In our example, there can be only one Customer for each Order, but a
Customer can have any number of Orders.
This table gives the most common multiplicities.
Multiplicities Meaning
0..1 zero or one instance. The notation n . . m indicates n to m instances.
0..* or * no limit on the number of instances (including none).
1 exactly one instance
1..* at least one instance
Every class diagram has classes, associations, and multiplicities. Navigability and roles are
optional items placed in a diagram to provide clarity.
Packages and object diagrams
To simplify complex class diagrams, you can group classes into packages. A package
is a collection of logically related UML elements. The diagram below is a business model in
which the classes are grouped into packages.
6
Packages appear as rectangles with small tabs at the top. The package name is on the
tab or inside the rectangle. The dotted arrows are dependencies. One package depends on
another if changes in the other could possibly force changes in the first.
Object diagrams show instances instead of classes. They are useful for explaining
small pieces with complicated relationships, especially recursive relationships.
This small class diagram shows that a university Department can contain lots of other
Departments.
The object diagram below instantiates the class diagram, replacing it by a concrete example.
7
Each rectangle in the object diagram corresponds to a single instance. Instance names
are underlined in UML diagrams. Class or instance names may be omitted from object
diagrams as long as the diagram meaning is still clear.
Sequence diagrams
Class and object diagrams are static model views. Interaction diagrams are dynamic.
They describe how objects collaborate.
A sequence diagram is an interaction diagram that details how operations are carried
out -- what messages are sent and when. Sequence diagrams are organized according to time.
The time progresses as you go down the page. The objects involved in the operation are listed
from left to right according to when they take part in the message sequence.
Below is a sequence diagram for making a hotel reservation. The object initiating the
sequence of messages is a Reservation window.
8
The Reservation window sends a makeReservation() message to a HotelChain. The
HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has available
rooms, then it makes a Reservation and a Confirmation.
Each vertical dotted line is a lifeline, representing the time that an object exists. Each
arrow is a message call. An arrow goes from the sender to the top of the activation bar of the
message on the receiver's lifeline. The activation bar represents the duration of execution of
the message.
In our diagram, the Hotel issues a self call to determine if a room is available. If so,
then the Hotel creates a Reservation and a Confirmation. The asterisk on the self call means
iteration (to make sure there is available room for each day of the stay in the hotel). The
expression in square brackets, [ ], is a condition.
Collaboration diagrams
Collaboration diagrams are also interaction diagrams. They convey the same
information as sequence diagrams, but they focus on object roles instead of the times that
messages are sent. In a sequence diagram, object roles are the vertices and messages are the
connecting links.
9
The object-role rectangles are labeled with either class or object names (or both).
Class names are preceded by colons ( : ).
Each message in a collaboration diagram has a sequence number. The top-level
message is numbered 1. Messages at the same level (sent during the same call) have the same
decimal prefix but suffixes of 1, 2, etc. according to when they occur.
Statechart diagrams
Objects have behaviors and state. The state of an object depends on its current activity
or condition. A statechart diagram shows the possible states of the object and the transitions
that cause a change in state.
Our example diagram models the login part of an online banking system. Logging in
consists of entering a valid social security number and personal id number, then submitting
the information for validation.
Logging in can be factored into four non-overlapping states: Getting SSN, Getting
PIN, Validating, and Rejecting. From each state comes a complete set of transitions that
determine the subsequent state.
10
States are rounded rectangles. Transitions are arrows from one state to another. Events
or conditions that trigger transitions are written beside the arrows. Our diagram has two self-
transition, one on Getting SSN and another on Getting PIN.
The initial state (black circle) is a dummy to start the action. Final states are also
dummy states that terminate the action.
The action that occurs as a result of an event or condition is expressed in the form
/action. While in its Validating state, the object does not wait for an outside event to trigger a
transition. Instead, it performs an activity. The result of that activity determines its
subsequent state.
Activity diagrams
An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart
diagrams are related. While a statechart diagram focuses attention on an object undergoing a
process (or on a process as an object), an activity diagram focuses on the flow of activities
involved in a single process. The activity diagram shows the how those activities depend on
one another.
For our example, we used the following process.
"Withdraw money from a bank account through an ATM."
11
The three involved classes (people, etc.) of the activity are Customer, ATM, and
Bank. The process begins at the black start circle at the top and ends at the concentric
white/black stop circles at the bottom. The activities are rounded rectangles.
Activity diagrams can be divided into object swimlanes that determine which object
is responsible for which activity. A single transition comes out of each activity, connecting it
to the next activity.
A transition may branch into two or more mutually exclusive transitions. Guard
expressions (inside [ ]) label the transitions coming out of a branch. A branch and its
subsequent merge marking the end of the branch appear in the diagram as hollow diamonds.
A transition may fork into two or more parallel activities. The fork and the subsequent join
of the threads coming out of the fork appear in the diagram as solid bars.
12
Component and deployment diagrams
A component is a code module. Component diagrams are physical analogs of class
diagram. Deployment diagrams show the physical configurations of software and hardware.
The following deployment diagram shows the relationships among software and
hardware components involved in real estate transactions.
The physical hardware is made up of nodes. Each component belongs on a node.
Components are shown as rectangles with two tabs at the upper left.
Result:
Thus an experiment for Study of UML is successfully done.
13
Ex No : 2DATE: 16.07.2009
PROBLEM STATEMENT
AIM:
To develop a problem statement for online ATM system.
PROBLEM ANALYSIS:
Online ATM system has to be developed for convenient withdrawal/deposit service in
everywhere, even if users don’t come to a bank.
The System developed should contain following features:
1. This ATM system would include a master database for accounts and transactions,
interaction with ATMs and providing account accessibility to the users.
2. Each bank provides its own computer to maintain its own accounts and process
transactions against them. With this system, a client must first have an account before he can
use ATM.
3. A client may open his account for depositing/withdrawing.
4. The client can check the account status 24 hours a day.
5. When the client deposits/withdraws money. The ATM system communicates with a central
computer which clears transactions with the appropriate banks.
6. An ATM accepts the pin number, interacts with the user, communicates with the central
system to carry out the transaction, dispenses cash, and prints receipts.
7. The system requires appropriate recordkeeping and security provisions. The system must
handle concurrent accesses to the same account correctly.
Result:
Thus the problem statement for ATM system has been successfully
written
14
EX N0 : 3DATE : 16.07.2009
STUDY OF RATIONAL ROSE
AIM:
To study the functionalities of the rational rose software.
INTRODUCTION:
ROSE = Rational Object Oriented Software Engineering.
Rational Rose is a set of visual modeling tools for
development of object oriented software.
Visual Modeling is the process of graphically depicting the
system to be developed
o Presenting essential details
o Filtering out non-essential details
o Viewing the system from different perspectives
WHY MODEL?
The UML models act as an architectural
blueprint for software development.
Good models:
o Identify requirements and communicate information
o Allows focus on how system components interact,
o without get bogged out in specific details
o Allows you to see relationships among design
o components
o Improves communication across your team through
o the use of common graphical language
WHEN SHOULD ROSE BE USED?
Modeling can be useful at any point in the application
development process.
Initial Design Work(Requirement Analysis and Definition)
15
• Use Cases
• Class Diagrams
• Sequence Diagram
• Rational Rose includes tools for reverse engineering
as well as forward engineering of classes and
component architectures.
• You can gain valuable insights to your actual
constructed architecture and pinpoint deviations from
the original design.
• Rose offers a fast way for clients and new employees
to become familiar with system internals
Rose GUI:
Diagram ToolBox
Window
Your model is
Really in HERE!
Log window
Documentation window
Diagram Window
16
RATIONAL ROSE INTERFACE:
Diagram window
•Allows you to create, update, and model different diagrams, that are, graphical views
of the model
Diagram toolbar
•Is unique to each diagram type and can be customized.
•Is active only when a diagram is displayed.
•May be visible or hidden; docked or floating.
•As with the standard toolbar, placing your cursor on an icon displays the tooltip for
that icon.
The Specification window
• Is a textual representation of a model element that allows you to view and manipulate
the element's properties.
•Note that information added to the documentation window is automatically added to
the documentation field in the specification window.
The Log window
•Reports progress, results, and errors
•Right-click on Log window to see available actions
Toolbar for Class Diagrams
Any element of a diagram can be created by placing the mouse pointer over a Tool
in the Toolbar
• Drag&Drop over the diagram canvas
17
Text Generalization
Note Package
Realisation
Pointer
Note Anchor Dependency or Instaniation
interface
class
association Association class
MODELS , VIEWS AND DIAGRAMS:
Models themselves are constructed using different views and diagrams to
accurately depict different stakeholder perspectives and the system’s building
blocks, respectively.
Models are complete representations of the system.
Views allow different stakeholders to see the system from their own perspectives
•Views contain Models…
•E.g. Logical View contains analysis model, business object model, design
model(Sometimes models can contain ‘views’ too…)
•Models generally contain a number of diagrams – some of these terms are ‘used’
interchangeably…
•E.g. Design model contains class diagrams, sequence diagrams, and a number of
others….
Diagrams: means by which we view of the system.
•Different building blocks (model elements) for different types.
Just as there are many views of a house under construction -the floor plan, the wiring
diagram, the elevation plan, there are many views of a software project under development.
Rational Rose is organized around the following views of a software project:
•Use Case
•Logical
•Component
•Deployment
Each of these views presents a different aspect of the model
and is explained in subsequent slides.
THE USE CASE VIEW:
The use-case view helps you to understand and use the system. This view looks at how
actors and use cases interact.
The diagrams in this view are:
•Use-case diagrams
•Sequence diagrams
•Collaboration diagrams
•Activity diagrams
This view contains a Main diagram by default. Additional
diagrams can be added throughout the analysis and
design process.
19
THE LOGICAL VIEW:
The logical view addresses the functional requirements of the system.
This view looks at classes and their relationships.
The diagrams in this view are:
•Class diagrams
•State chart diagrams
This view contains a Main diagram by default. Additional diagrams can be added throughout
the analysis and design process.
20
THE COMPONENT VIEW:
The component view addresses the software organization of the system.
This view contains information about the software, executable and library components for the system.
This view contains only component diagrams. The component view contains a Main diagram by default. Additional diagrams can be added to this view throughout the analysisand design process.
21
THE DEPLOYMENT VIEW:
The deployment view shows the mapping of processes to hardware.
This type of diagram is most useful in a distributed architecture environment where youmight have applications and servers at different locations.
This view contains only one diagram -the deployment diagram.
22
DIAGRAMS:Simply put, a diagram is a graphical representation of the elements of your system.Different diagram types allow you to view your system from multiple perspectives.You can create various types of diagrams in Rational Rose. The diagram types include:
Each of these diagram types is explained in subsequent slides.
USE CASE DIAGRAMS:
Use-case diagrams present a high-level view of system usage as viewed from an outsider's(actor's) perspective. These diagrams show the functionality of a system or a class and howthe system interacts with the outside world.
Use-case diagrams can be used during analysis to capture the system requirements and tounderstand how the system should work.
During the design phase, use-case diagrams specify the behavior of the system asimplemented.
Rose automatically creates a Main use-case diagram in the use-case view. There aretypically many use-case diagrams in a single model.
23
UC DIAGRAM EXAMPLE:
CLASS DIAGRAMS:
A class diagram helps you visualize the structural or static view of a system and is one ofthe most common diagram types.
Class diagrams show the relationships among and details about each class.
Class diagrams are also the foundation for component and deployment diagrams.
Rose automatically creates a Main class diagram in the logical view. There are typicallymany class diagrams in a single model.
24
CLASS DIAGRAM SAMPLE:
SEQUENCE DIAGRAMS:A sequence diagram illustrates object interactions arranged in a time sequence.
These diagrams are typically associated with use cases.
Sequence diagrams show you step-by-step what has to happen to accomplish something inthe use case.
This type of diagram emphasizes the sequence of events, whereas collaboration diagrams (an alternative view of the same information) emphasize the relationship.This type of diagram is best used early in the design or analysis phase because it is simple and easy to comprehend.
25
SEQUENCE DIAGRAM EXAMPLE:
COLLABORATION DIAGRAMS:Collaboration diagrams provide a view of the interactions or structural relationshipsbetween objects in the current model.
This type of diagram emphasizes the relationship between objects whereas sequence diagrams emphasize the sequence of events.
Collaboration diagrams contain objects, links, and messages.
Use collaboration diagrams as the primary vehicle to describe interactions that express decisions about system behavior.
26
COLLABORATION DIAGRAM EXAMPLE:
ACTIVITY DIAGRAMS:
Activity diagrams model the workflow of a business process and the sequence of activities in a process.
These diagrams are very similar to a flowchart because you can model a workflow from activity to activity or from activity to state.
It is often beneficial to create an activity diagram early in the modeling of a process to helpyou understand the overall process.
Activity diagrams are also useful when you want to describe parallel behavior or illustrate how behaviors in several use cases interact.
27
ACTIVITY DIAGRAM EXAMPLE:
COMPONENT DIAGRAMS:
Component diagrams provide a physical view of the current model.
They show the organization and dependencies among software components,including source code, binary code, and executable omponents.
You can create one or more component diagrams to depict components andpackages or to represent the contents of each component package.
28
COMPONENT DIAGRAM EXAMPLE:
DEPLOYMENT DIAGRAMS:
Each model contains a single deployment diagram that shows the mapping of processes to hardware.
29
DEPLOYMENT DIAGRAM EXAMPLE:
STATE CHART DIAGRAMS:
You can use statechart diagrams to model the dynamic behavior of individual classes orobjects.
Statechart diagrams show the sequences of states that an object goes through, the events that cause a transition from one state or activity to another, and the actions that result from astate or activity change.
A statechart diagram is typically used to model the discrete stages of an object's lifetime,whereas an activity diagram is better suited to model the sequence of activities in a process.
30
STATE CHART DIAGRAM EXAMPLE:
RESULT:Thus the study of Rational Rose was made.
31
SOFTWAREREQUIREMENTSPECIFICATION
FOR ATM
32
EX N0 : 4DATE : 16.07.2009
DEVELOPING SOFTWARE REQUIREMENTSPECIFICATION
1. INTRODUCTION:
PURPOSE:The purpose of ATM System is to automate the process of maintaining the
banking details of each and every customer. The ATM System keeps trackof the transaction done at any time by the customer and it also reducestime for procedural time for transaction.
SCOPE:The scope of the project is to maintain the banking details of each and every customer
by implementing the ATM system. The software contains followingfunctions
REFERENCE:The following reference materials were used: IEEE STD 830-1998-Software Requirements Specification document.
OVERVIEW:
S.NO ACRONYM FULL FORM1 DB Database2 IEEE Institute of
Electrical andElectronics Engineers
3 DBMS Database ManagementSystem
4 PC Personal Computer5 JDBC Java Database
Connectivity6 OS Operating System
33
The remaining contents of the Software Requirements Specifications is Organized inthe following structure:
Overall system description containing information about the productperspective ,User characteristics ,Constraints, Assumption andRequirements and Dependencies.
Specific requirements description containing information about the externalinterfaces ,functions ,performance requirements, logical databaserequirements, design constraints , standards compliance and additionalcomments.
2 OVERALL DESCRIPTION:
2.1 PRODUCT PERSPECTIVE:
The ATM system is independent, autonomous and self –contained system. Theuser interface consists of three main functions, pin verification, customer transactions,security pin changes on each function reveals the contents of respective page. TheHardware Interface that are used are the interface between customer, administratorwith ATM system; the interaction between entered data and the database; theinteraction between ATM and Database server. Communication interfaces include theWide Area Network interface and Wide Area Network Protocols.
2.2 PRODUCT FUNCTIONS :
The major functions provided by the software are: Login function provides access to the authentic user. The deposit function allows the customer to deposit money. The withdrawal function allows the customer to withdraw the required money. The balance enquiry function allows to view the current account balance. The pin change function allows to change the pin number.
2.3 USER CHARACTERISTICS:The user who will be using this software should possess the following
characteristics : The user must have the basic knowledge to use an ATM.
2.4 CONSTRAINTS:The following are the list of constraints: Only account holders can access the ATM.
2.5 ASSUMPTIONS AND DEPENDANCIES:The following are the list of assumptions and dependencies: The software requires Windows operating system. The software requires Internet explorer.
34
Software is dependent on MS-ACCESS.
3 SPECIFIC REQUIREMENTS:
3.1 EXTERNAL INTERFACES: The external interface is designed in a user friendly manner such that the user feels
easy.
3.2 PERFORMANCE REQUIREMENTS:Performance is a main problem because it is used daily. The system should provide very high performance with respect to speed,
security and processing of details because it has to be run every day as it will beaccessed including client and admin.
3.3 LOGICAL DATABASE REQUIREMENTS:The following are the logical database requirements: The database should contain the transaction details of the customer. Each customer should have a unique pin number.
3.4 DESIGN CONSTRAINTS:The following are the design constraints: Since the database is large, the software must be able to access from
different machines at a time.
Since the database is used every day, the database and machine
maintenance should be performed once in every 20 days in order to avoid the system
crash scenario.
The database should be backed up by duplicate database in order to avoid
the serve crash scenario.
3.5 SOFTWARE SYSTEM ATTRIBUTES:
The following are the software system attributes:
By adopting frequent manual supervision and maintenance, the reliability is
maintained.
By using firewalls and authentication along with confidentiality, the security of the
system is maintained.
Since VB is used, it is easy to access and the software is user friendly.
CONCLUSION:
Thus a sample of the software requirements for the ATM has been developed
according to the IEEE STD 830-1998 document.
35
EX N0 : 5
DATE : 23.07.2009
DEVELOPING USE CASE MODEL FOR PROJECT
AIM:
To develop a use case model for the ATM.
Use case diagram:
insert card
remove card
withdrawl
deposit
balance enquiry
transcation details
<<extend>>
client
pin changes
transaction completed
invalid pin
admin
approval
ACTORS:
1: User: customer who holds an account in bank .
2: Admin: Is the Administrator who maintains the Database for the
Organization
36
USE CASES:
BALANCE ENQUIRY:
Description: Use for the purpose of updating and displaying user's balance
pre condition: User must be authenticated
Post condition: Receipt must be printed if user needs
PIN CHANGE:
Description: used for changing the login pin number
Pre condition: User must enter the old PIN
Post condition: database must be updated with changed pin
WITHDRAWAL:
Description: to withdraw money from user's account
Pre Condition: User must have the minimum balance
Post Condition: database should be updated with available balance
LOGIN:
Description: to provide the security feature
Pre Condition: must be account holder of the respective bank to know the pin
Post condition: None
DEPOSIT:
Description: To Deposit money into the User’s Account.
Pre Condition: User must Have an account in bank to deposit money
Post condition: Database should be updated with the available balance.
RESULT:
Thus use case model for ATM was designed.
37
EX N0 : 6DATE : 30.07.2009
ACTIVITY DIAGRAMS FOR ATM
AIM:
To design activity diagram for the use cases designed for ATM.
ACTIVITY DIAGRAMS:
Login
enter pin
displayinvalid pin
check pin
transactions
valid
invalid
38
PIN CHANGE:
pin verify
entercorrect pin
check pin
enter new pin
valid
invalid
pin changed
39
BALANCE ENQUIRY:
pin check
entercorrect pin
check pin
transaction
valid
invalid
connect toDB
Get balancedetails from DB
DisplayDetails
DisconnectDB
40
WITHDRAWAL:
pin check
entercorrect pin
check pin
transaction
valid
invalid
withdrawal
Enter the amountto be withdrawan
ConnectDB
Update accountBalance
disconnectDB
41
DEPOSIT:
pin check
entercorrect pin
check pin
transaction
valid
invalid
DEPOSIT
Enter the amount TheAmount to be Deposited
ConnectDB
Update accountBalance
disconnectDB
Add Amount toAccount Balance
RESULT:
42
Thus the activity diagrams for the use cases have been designed for ATM.
EX N0 : 7DATE : 06.08.2009
IDENTIFYING CLASSES-NOUN PHRASE APPROACH FOR ATM
AIM:
To identify the various classes using the noun phrase approach.
SOLUTION:
STEP1: INITIAL LIST OF Noun Phrases: Candidate Classes
The initial study of the Employee Management System produces the following
noun phrases.
Administrator User User details Name Address Account Balance Transaction Deposit Bill Withdrawal Statement Credit Cash Login Pin Invalid Status Client Bank Card Name Valid Current account Savings account
43
STEP 2: ELIMINATE THE IRRELEVANT CLASSES
From the above List we can see that the following terms are irrelevant and hence can
be removed. The terms are administrator, statement, bill, credit, cash, status, and card.
So now these can be eliminated.
Administrator User User details Name Address Account Balance Transaction Password Deposit Bill Withdrawal Statement Credit Cash Login Pin Invalid Status Client Bank Card Valid Current account Savings account
44
STEP3: ELIMINATE REDUNDANT CLASSES AND BUILD A COMMON
VOCABULARY
The following are the class names that are used to refer the same concept
Password=Pin
Card, Bank, Client=user
Administrator User User details Name Address Account Balance Transaction Password Deposit Bill Withdrawal Statement Credit Cash Login Pin change Invalid Status Client Bank Card Valid Current account Savings account
45
STEP 4: REVIEWING THE CLASSES CONTAINING THE ADJECTIVES
The above list does not contain classes that are adjectives that we can eliminate.
STEP5: REVIEWING THE POSSIBLE ATTRIBUTES
The attributes that are possibly identified in the system are
1. Name, address , valid, Invalid : Pin change
2. Account, cash, savings account, current account: withdraw
3. Transaction:Balance
4. Login
Administrator User User details Name Address Account Balance Transaction Password Deposit Bill Withdrawal Statement Credit Cash Login Pin change Invalid Status Client Bank Card Valid Current account Savings account
46
STEP6: REVIEWING THE CLASS PURPOSE
The classes that add no purpose to the system have been deleted from the list. The
candidate classes are
Pin change: allows user to change the pin
Withdraw: to withdraw money from account
Balance: allow user to know the balance
Login: security feature to allow authenticated users to operate their account
CONCLUSION:
Thus the Candidate Classes have been identified using the noun phrase approach and
the classes are
Pin change
Withdraw
Balance
Login
47
EX N0 : 8DATE : 13.08.2009
DEVELOPING CLASS DIAGRAM FOR ATM
AIM:To draw the Class diagram for ATM system.
CLASS DIAGRAM:
customer details
customer name : stringbankname : stringbankcode : integeraddress : string
card number : integerpin number : integerpinchange : integer
userlogin()
ATMTransactions
balance enquirywithdrawaldepositsignout
balancenq()withdraw()deposit()signout()
1 1*
1
RESULT:Thus the class diagram for all the use case is drawn.
48
EX N0 : 9DATE : 10.09.2009
DEVELOPING SEQUENCE DIAGRAM FOR ATM
AIM:To draw the sequence diagram for the various use case deployed in ATM.
LOGIN:
customer succesful login transaction balance
1.pin check
2.selecttransaction
3.check balance
4.return balance
49
BALANCE ENQUIRY:
customer succesful login transaction balance
1.pin check
2.selecttransaction
3.check balance
4.return balance
PIN CHANGE:
customer succesful loginpin verify pin changed
1.login 2.enter ...
3.check pin
4.enter corr...
5.enter new pin
...
6.pin changed
50
WITHDRAWAL:
customer login transaction withdrawal
1.pin check2. selecttranscation
3.enter amount tobe with drawn
4.update balanceaccount
DEPOSIT:
customer login transaction deposit
1.pin check
2.selecttransction
enter amount to bedeposited
update account
RESULT:
Thus the sequence diagram for the ATM has been drawn.
51
EX N0 : 10DATE : 17.09.2009
DEVELOPING COLLABORATION DIAGRAM FOR ATM SYTEM
AIM:To draw the collaboration diagram for the ATM
BALANCE ENQUIRY:
customer succesfullogin
transaction
1.pin check 2.selecttransaction
3.check balance4.returnbalance
1:
Balance
2:
3:4:
PIN CHANGE:
: customer
succesfullogin
pin verify
pin change
3: check pin
6: pin changed
1: login 2: enter old pin
4: enter correct pin
5: enter new pin
52
WITHDRAWAL:
: customer
login transaction
withdrawl
1: pin check 2: select transaction
3: enter amount to be withdrawn
4: update account balance
DEPOSIT:
customer login
transaction
1.insert card and pin
2.check pin
3.valid pin4.invalid pin
1:
2:
3:
4:
RESULTSThus the collaboration diagram for ATM System has been drawn.
53
EX N0 : 11DATE : 24.09.2009
IMPLEMENTATION FOR ATM
AIM:To implement ATM system
PROCESSING FORM:
54
BALANCE ENQUIRY DETAILS:
CODING:
Dim WS As WorkspaceDim RS As RecordsetDim DB As DatabaseDim a As VariantDim i, wit, mohan As IntegerPrivate Sub Command1_Click()RS.MoveFirstFor i = 1 To mohan Step 1If (Text1.Text = RS.Fields(2)) ThenMsgBox "login correct", vbInformation, "welcome"Form1.Hide
55
Form2.ShowExit ForEnd If
RS.MoveNextNextIf (i = mohan + 1) ThenMsgBox "login incorrect", vbCritical, "WARNING!"Text1.Text = ""Text1.SetFocusEnd IfEnd Sub
Private Sub Command2_Click()EndEnd Sub
Private Sub Form_Load()Set WS = DBEngine.Workspaces(0)Set DB = WS.OpenDatabase("c:\mani.mdb")Set RS = DB.OpenRecordset("SELECT*FROM mb", dbOpenDynaset)RS.MoveLastmohan = RS.RecordCountText1.SetFocusEnd Sub
Private Sub Command1_Click()Form2.HideForm3.ShowEnd Sub
Private Sub Command2_Click()Form2.HideForm4.ShowEnd SubPrivate Sub Command3_Click()Form2.HideForm5.Show
End SubPrivate Sub Command4_Click()Form3.HideForm6.ShowEnd Sub
56
Dim WS As WorkspaceDim RS As RecordsetDim DB As DatabaseDim a As VariantDim i, wit, mohan As Integer
Private Sub Command1_Click()
RS.MoveFirst
For i = 1 To mohan Step 1
If (Text1.Text = RS.Fields(1) And Text2.Text = RS.Fields(0)) ThenMsgBox "VERIYFING BALANCE", vbInformation, "welcome"
Text3.Text = RS.Fields(3)
Exit ForEnd IfRS.MoveNext
NextIf (i = mohan + 1) ThenMsgBox "enter properly", vbCritical, "WARNING!"Text1.Text = ""Text2.Text = ""Text1.SetFocusEnd IfEnd Sub
Private Sub Form_Load()
Set WS = DBEngine.Workspaces(0)Set DB = WS.OpenDatabase("c:\mani.mdb")Set RS = DB.OpenRecordset("SELECT*FROM mb", dbOpenDynaset)RS.MoveLast
mohan = RS.RecordCountEnd Sub
57
Dim WS As WorkspaceDim RS As RecordsetDim DB As DatabaseDim a As VariantDim i, wit, mohan As Integer
Private Sub Command1_Click()a = InputBox("Enter Your withdrawal amount", "withdrawal amount", "enter here")If (a < 0) ThenMsgBox "cannot be retrieved"ElseText1.Text = Val(a)If (RS.Fields(3) < 101 Or (RS.Fields(3) - Val(Text1.Text)) < 100) ThenMsgBox "amount cannot be with drawn"ElseRS.Editwit = wit - Val(Text1.Text)RS.Fields(3) = witRS.Update
'Text1.Text = ""Text1.Text = ""End IfEnd IfEnd Sub
Private Sub Form_Load()
Set WS = DBEngine.Workspaces(0)Set DB = WS.OpenDatabase("c:\mani.mdb")Set RS = DB.OpenRecordset("SELECT*FROM mb", dbOpenDynaset)RS.MoveLastmohan = RS.RecordCount
RS.MoveFirst
For i = 1 To mohan Step 1
If (Form1.Text1.Text = RS.Fields(2)) Then'MsgBox "login correct", vbInformation, "welcome"'Form1.Hide'Form2.Show
wit = RS.Fields(3)
Exit For
58
End If
RS.MoveNext
Next
End Sub
Private Sub Label1_Click()
End Sub
59
Dim WS As WorkspaceDim RS As RecordsetDim DB As DatabaseDim a As VariantDim i, wit, mohan As Integer
Private Sub Command1_Click()If (Text1.Text = "") ThenMsgBox "please enter the amount"ElseRS.Editwit = wit + Val(Text1.Text)RS.Fields(3) = witRS.UpdateMsgBox "amount deposited"Text1.Text = ""End IfEnd Sub
Private Sub Form_Load()Set WS = DBEngine.Workspaces(0)Set DB = WS.OpenDatabase("c:\mani.mdb")Set RS = DB.OpenRecordset("SELECT*FROM mb", dbOpenDynaset)RS.MoveLastmohan = RS.RecordCount
RS.MoveFirst
For i = 1 To mohan Step 1
If (Form1.Text1.Text = RS.Fields(2)) Then'MsgBox "login correct", vbInformation, "welcome"'Form1.Hide'Form2.Show
wit = RS.Fields(3)Exit ForEnd If
RS.MoveNext
Next
End SubDim WS As WorkspaceDim RS As Recordset
60
Dim DB As DatabaseDim a As VariantDim i, wit, mohan As Integer
Private Sub Command1_Click()If (wit = Text1.Text) Then
RS.EditRS.Fields(2) = Text2.TextRS.UpdateMsgBox "PIN NUMBER CHANGED"ElseMsgBox "enter the correct old pin number"End If
End Sub
Private Sub Form_Load()Set WS = DBEngine.Workspaces(0)Set DB = WS.OpenDatabase("c:\mani.mdb")Set RS = DB.OpenRecordset("SELECT*FROM mb", dbOpenDynaset)RS.MoveLastmohan = RS.RecordCount
RESULTThus the ATM system has been successfully implemented using VisualBasic and Access
61
EX N0 : 12DATE : 03.10.2009
TESTING FOR ATM
AIM
To Test the ATM system.
TEST CASE: 1This Test case is to check the pin number of the customer orelse the customer
will not be allowed to access the system.
INPUT:Incorrect Pin number
EXPECTED OUTPUT:The user is not allowed to login into his account due to incorrect
password and he must be shown error message.
62
OBTAINED OUTPUT:The user was not allowed to login successfully and an error messagewas shown.
TEST STATUS : SUCCESS
63
TEST CASE: 2This test case is used for checking the sufficient balance in the account; theuser will not be allowed to withdraw if there is no sufficient balance in hisaccount.
INPUT:Enter the amount more than the account balance.
EXPECTED OUTPUT:The user must not be allowed to withdraw the amount from the ATMand the error message is shown.
64
OBTAINED OUTPUT:The user is not allowed to withdraw the amount and a error message isshown
TEST STATUS : SUCCESS
65
TEST CASE: 3This test case is used to check the pin number of the customer (incase of pin
change), the user will not be allowed to change the pin if he enters the old pin number wrongly;
INPUT:Enter the wrong old pin number.
EXPECTED OUTPUT:User is not allowed to change the pin number and an error message isshown.
66
OBTAINED OUTPUT:
The user was not allowed to change the pin and an error message wasshown.
TEST STATUS : SUCCESS
RESULT:
Thus the various test cases for ATM systems has been successfullyperformed.
