Sponsored Content
Top Forums UNIX for Dummies Questions & Answers Simulation of an ATM interface Post 302468127 by Jimmy_c on Monday 1st of November 2010 06:29:27 PM
Old 11-01-2010
Simulation of an ATM interface

Hi guys,

I recently discovered this problem and any help would be great.

1) Create a file in vi named Accounts_File with the following data:
The user, the name, the pin number, current balance and transaction history.

There are 3 users who need to be inputted with all their PIN, etc shown. In vi, how do I assign a name to a pin and transaction history, etc?

2) The program should great users with an initial screen prompting the user to log in.

3) When a user (one on the 3 in vi file) enters a valid username, he will be prompted to enter a PIN. If the PIN is recognised, the user will be allowed to login and the programme should navigate to the Accounts Options Menu (AOM) screen.

4) The AOM will display:
display balance, withdraw funds, deposit funds, mini stmt, logout.

5) Display balance displays the currently logged in user's account balance.

6) Withdraw funds will promp the user to select an amount to withdraw:
£10, £20, 50, other.
The number is then subtracted from the user's account balance. If no funds, a message is displayed.

7) Deposit funds - will be added to the account balance.

8) Logout - programme should give them option to logout.

Any ideas how to tackle this? would be awesome for some code!
 

9 More Discussions You Might Find Interesting

1. UNIX for Advanced & Expert Users

FTP over ATM issue

We just recently upgraded our T1 wan link to a 10Mbit ATM link. Windows pc's seem fine and get great speed, however we have 2 Sco unix box's that seem really slow at FTPing now. both Sco box's are SCO OpenServer Enterprise System (ver 5.0.5m) compaq ML530's I'm not really sure what to... (4 Replies)
Discussion started by: whegra
4 Replies

2. Shell Programming and Scripting

error in ftp script which pulls files from ATM

Hi Everyone, I have an ftp script which pulls files from ATM in a daily basis. But for the last two days i found that the script is throwing some error like ******************************************** cat: 0652-050 Cannot open EJpullErr_20090411.log. cat: 0652-050 Cannot open... (5 Replies)
Discussion started by: Renjesh
5 Replies

3. IP Networking

Need Cisco hardware that'll translate IP to ATM

Hello, This is my first time here so I hope I can describe everything. Due to the nature of what we're doing, I'm only going to describe what I need. We need to convert TCP/IP to ATM. I'm not talking about encapsulizing it by wrapping ATM around it, rather pure conversion from IP to ATM.... (0 Replies)
Discussion started by: sohel2009
0 Replies

4. Homework & Coursework Questions

Client/server atm with sockets

Hello everyone!I would appreciate any help you could give me,I have to make a program of an atm machine using client server sockets and semaphores.I know how to construct an ATM in c++ but don't know anything about unix c.The problem is that Don't know what to do and how to link the two programs... (0 Replies)
Discussion started by: tamanas
0 Replies

5. Solaris

Command line Interface or GUI Interface not shown on solaris

Dear all, I am a newbie in solaris and I need your advice. I have a Solaris version 5.9 installed on Sunfire V240. I am able to ssh the machine from putty remotely. My problem is that I cannot see the display from KVM switch I have connected to it. I need also to be able to see the GUI... (2 Replies)
Discussion started by: mbouster
2 Replies

6. SCO

Change SCO - GUI or Desktop interface to DOS based interface

Hi all I have installed a demo version of SCO OpenServer 5.0.2, I finally found it is Desktop Interface, I would like to know how to change its interface to dos based interface? If you have any ideas, please tell me then. Thank you (2 Replies)
Discussion started by: TinhNhi
2 Replies

7. UNIX for Dummies Questions & Answers

Create a simple ATM (Cash machine simulation)

I need to create a simple ATM (Cash machine simulation in unix) which shows a welcome screen, then a login screen to enter 3 users details. help please on the coding The users details need to be in a txt file: the details are: (PIN No, First name last name, Account number, Balance, Histrosy) ... (1 Reply)
Discussion started by: oobla01
1 Replies

8. Shell Programming and Scripting

Simulation of ATM interface

Hi guys, I recently discovered this problem and any help would be great. 1) Create a file in vi named Accounts_File with the following data: The user, the name, the pin number, current balance and transaction history. There are 3 users who need to be inputted with all their PIN, etc... (1 Reply)
Discussion started by: Jimmy_c
1 Replies

9. Solaris

ATM to Ethernet conversion

More old kit ..... We have a bunch of old Sun kit E4500, E450 etc that are currently running on ATM nic's and need to be put on the the onboard Ethernet ports.... Anyone know how to do this without downtime? It'd be better if I can keep the original Ip Addresses though it may be possible to... (2 Replies)
Discussion started by: Martincorneuk
2 Replies
Moose::Cookbook::Basics::BankAccount_MethodModifiersAndSUseraContributed PerlMoose::Cookbook::Basics::BankAccount_MethodModifiersAndSubclassing(3)

NAME
Moose::Cookbook::Basics::BankAccount_MethodModifiersAndSubclassing - Demonstrates the use of method modifiers in a subclass VERSION
version 2.0604 SYNOPSIS
package BankAccount; use Moose; has 'balance' => ( isa => 'Int', is => 'rw', default => 0 ); sub deposit { my ( $self, $amount ) = @_; $self->balance( $self->balance + $amount ); } sub withdraw { my ( $self, $amount ) = @_; my $current_balance = $self->balance(); ( $current_balance >= $amount ) || confess "Account overdrawn"; $self->balance( $current_balance - $amount ); } package CheckingAccount; use Moose; extends 'BankAccount'; has 'overdraft_account' => ( isa => 'BankAccount', is => 'rw' ); before 'withdraw' => sub { my ( $self, $amount ) = @_; my $overdraft_amount = $amount - $self->balance(); if ( $self->overdraft_account && $overdraft_amount > 0 ) { $self->overdraft_account->withdraw($overdraft_amount); $self->deposit($overdraft_amount); } }; DESCRIPTION
The first recipe demonstrated how to build very basic Moose classes, focusing on creating and manipulating attributes. The objects in that recipe were very data-oriented, and did not have much in the way of behavior (i.e. methods). In this recipe, we expand upon the concepts from the first recipe to include some real behavior. In particular, we show how you can use a method modifier to implement new behavior for a method. The classes in the SYNOPSIS show two kinds of bank account. A simple bank account has one attribute, the balance, and two behaviors, depositing and withdrawing money. We then extend the basic bank account in the CheckingAccount class. This class adds another attribute, an overdraft account. It also adds overdraft protection to the withdraw method. If you try to withdraw more than you have, the checking account attempts to reconcile the difference by withdrawing money from the overdraft account. (1) The first class, BankAccount, introduces a new attribute feature, a default value: has 'balance' => ( isa => 'Int', is => 'rw', default => 0 ); This says that a BankAccount has a "balance" attribute, which has an "Int" type constraint, a read/write accessor, and a default value of 0. This means that every instance of BankAccount that is created will have its "balance" slot initialized to 0, unless some other value is provided to the constructor. The "deposit" and "withdraw" methods should be fairly self-explanatory, as they are just plain old Perl 5 OO. (2) As you know from the first recipe, the keyword "extends" sets a class's superclass. Here we see that CheckingAccount "extends" BankAccount. The next line introduces yet another new attribute feature, class-based type constraints: has 'overdraft_account' => ( isa => 'BankAccount', is => 'rw' ); Up until now, we have only seen the "Int" type constraint, which (as we saw in the first recipe) is a builtin type constraint. The "BankAccount" type constraint is new, and was actually defined the moment we created the BankAccount class itself. In fact, Moose creates a corresponding type constraint for every class in your program (3). This means that in the first recipe, constraints for both "Point" and "Point3D" were created. In this recipe, both "BankAccount" and "CheckingAccount" type constraints are created automatically. Moose does this as a convenience so that your classes and type constraint can be kept in sync with one another. In short, Moose makes sure that it will just DWIM (4). In CheckingAccount, we see another method modifier, the "before" modifier. before 'withdraw' => sub { my ( $self, $amount ) = @_; my $overdraft_amount = $amount - $self->balance(); if ( $self->overdraft_account && $overdraft_amount > 0 ) { $self->overdraft_account->withdraw($overdraft_amount); $self->deposit($overdraft_amount); } }; Just as with the "after" modifier from the first recipe, Moose will handle calling the superclass method (in this case "BankAccount->withdraw"). The "before" modifier will (obviously) run before the code from the superclass is run. Here, "before" modifier implements overdraft protection by first checking if there are available funds in the checking account. If not (and if there is an overdraft account available), it transfers the amount needed into the checking account (5). As with the method modifier in the first recipe, we could use "SUPER::" to get the same effect: sub withdraw { my ( $self, $amount ) = @_; my $overdraft_amount = $amount - $self->balance(); if ( $self->overdraft_account && $overdraft_amount > 0 ) { $self->overdraft_account->withdraw($overdraft_amount); $self->deposit($overdraft_amount); } $self->SUPER::withdraw($amount); } The benefit of taking the method modifier approach is we do not need to remember to call "SUPER::withdraw" and pass it the $amount argument when writing "CheckingAccount->withdraw". This is actually more than just a convenience for forgetful programmers. Using method modifiers helps isolate subclasses from changes in the superclasses. For instance, if BankAccount->withdraw were to add an additional argument of some kind, the version of CheckingAccount->withdraw which uses "SUPER::withdraw" would not pass that extra argument correctly, whereas the method modifier version would automatically pass along all arguments correctly. Just as with the first recipe, object instantiation uses the "new" method, which accepts named parameters. my $savings_account = BankAccount->new( balance => 250 ); my $checking_account = CheckingAccount->new( balance => 100, overdraft_account => $savings_account, ); And as with the first recipe, a more in-depth example can be found in the t/recipes/moose_cookbook_basics_recipe2.t test file. CONCLUSION
This recipe expanded on the basic concepts from the first recipe with a more "real world" use case. FOOTNOTES
(1) If you're paying close attention, you might realize that there's a circular loop waiting to happen here. A smarter example would have to make sure that we don't accidentally create a loop between the checking account and its overdraft account. (2) Note that for simple methods like these, which just manipulate some single piece of data, it is often not necessary to write them at all. For instance, "deposit" could be implemented via the "inc" native delegation for counters - see Moose::Meta::Attribute::Native::Trait::Counter for more specifics, and Moose::Meta::Attribute::Native for a broader overview. (3) In reality, this creation is sensitive to the order in which modules are loaded. In more complicated cases, you may find that you need to explicitly declare a class type before the corresponding class is loaded. (4) Moose does not attempt to encode a class's is-a relationships within the type constraint hierarchy. Instead, Moose just considers the class type constraint to be a subtype of "Object", and specializes the constraint check to allow for subclasses. This means that an instance of CheckingAccount will pass a "BankAccount" type constraint successfully. For more details, please refer to the Moose::Util::TypeConstraints documentation. (5) If the overdraft account does not have the amount needed, it will throw an error. Of course, the overdraft account could also have overdraft protection. See note 1. ACKNOWLEDGMENT
The BankAccount example in this recipe is directly taken from the examples in this chapter of "Practical Common Lisp": http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html <http://www.gigamonkeys.com/book/object-reorientation-generic- functions.html> AUTHOR
Moose is maintained by the Moose Cabal, along with the help of many contributors. See "CABAL" in Moose and "CONTRIBUTORS" in Moose for details. COPYRIGHT AND LICENSE
This software is copyright (c) 2012 by Infinity Interactive, Inc.. This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself. perl v5.16.2 2012-09-1Moose::Cookbook::Basics::BankAccount_MethodModifiersAndSubclassing(3)
All times are GMT -4. The time now is 02:40 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy