RMIT International University Vietnam
RMIT International University Vietnam
RMIT International University Vietnam
Redtea
2009
This is the report that is produced by Redtea Team in which reflects our work from analysis step to shippable product step. Also, in this document, the reader can easily see all the design patterns that had been applied to this project along with its descriptions.
Redtea
Page 2
CONFIDENTIAL 10/13/2011
1 Requirements and Business Flow.............................................................................................................................................................4 2 Requirements........................................................................................................................................................................................5 3 Functional Redtea.............................................................................................................................................................................7 4 Non-Functional Redtea.....................................................................................................................................................................7 5 Diagram.............................................................................................................................................................................................8 6 Design.....................................................................................................................................................................................................11 7 Class Diagrams (Individual)...............................................................................................................................................................11 8 Class Diagram by Team Member...................................................................................................................................................11 9 Class Diagrams (Team)...................................................................................................................................................................15 10 Management and Project Planning.......................................................................................................................................................27 11 Management Approach.....................................................................................................................................................................27 12 Sprint Retrospective Meeting...........................................................................................................................................................27 13 Product Backlog................................................................................................................................................................................28 14 Sprint Backlog..................................................................................................................................................................................30 15 Sprint Review Meeting.....................................................................................................................................................................31 16 Sprint Review Meeting (Sprint 1).................................................................................................................................................31 17 Sprint Review Meeting (Sprint 2).................................................................................................................................................32 18 Attachment 1.........................................................................................................................................................................................32
Redtea
Page 3
CONFIDENTIAL 10/13/2011
Redtea
Page 4
CONFIDENTIAL 10/13/2011
ATM Client should be able to support both console and graphical interface. In order work, the project should have the reusability, follow the OO principal and keep in mind: close for modification but open for extension. Some of the basic required transaction: o Transfer money o Deposit money o Withdraw money o Exchange money o Check account balance The deadline of the project will be 02/09/2009; this project started from 22/06/2009 and was given by Mr. Eric.
2 Requirements
Deposit Money A customer can deposit money to a specific account. If the customer owns multiple accounts, the customer is able to choose which account to deposit to. You need to be able to simulate the process of a deposit. That includes any hardware that may be used to accept a deposit. Note: deposits are usually placed in a standard envelope which is given to the machine. Withdraw Cash A customer can withdraw cash from an account. An exchange is required if the currency withdrawn isnt the same as the account being withdrawn from. If the customer has multiple accounts, the customer is able to choose which account to withdraw from. Remember to consider the hardware aspects of the ABT. Think about what happens in the ATM machine when it doesnt have enough money. What happens if the hardware breaks? Can they withdraw any kind of currency denomination? Check Balance Get the balance of an account. The user can also get a balance of all accounts linked to the card
Redtea
Page 5
CONFIDENTIAL 10/13/2011
Support Multiple Linked Accounts An ATM card, as mentioned above, can be linked to multiple accounts. Currency An account can have difference currency but once created must maintain that type of currency. Notification After a transaction, if an account has reached a pre-determined level, a notification is automatically sent to the account holders email address. Balance Notification After a transaction, if an account has reached a pre-determined level, a notification is automatically sent to the account holders email address. Stat Session To start using an ATM, the customer inserts their card. They only need to enter a Personal Identification Number (PIN) for verification. Finish Session When the customer is finished using the ATM, they can choose to finish their session. The ATM will return their card. ATM User-Interfaces We have two types of ATMs. One type of ATM is GUI based and the other type is text based. We need to easily support both of them and still re-use source code specific to the ATM process. Communication We need to easily communicate with our server; however, we want this complete hidden from the objects you create. For example, when a user enters their PIN, we can simply code Pin.Validate. However, that command is really being executed on the server in some mystical way. Server: o Reporting Requirements - We have strict reporting requirements. As such, in the case of a user error or computer error, we need to be able to handle these situations dynamically.
Redtea
Page 6
CONFIDENTIAL 10/13/2011
o Redo/Undo and Logging Every time a user takes an action within the ATM it has to be logged and time stamped within the central system. If someone, for example, enters their pin incorrectly, that will be logged. If they withdraw money, it will be logged, etc. There is a great pattern for this.
3 Functional Redtea
Transfer money from one account to another Deposit money into specific account Withdraw money from an account Exchange money as an extra step to deal with foreign currency. Check account balance
4 Non-Functional Redtea
Graphic user interface friendly Database system management
Redtea
Page 7
CONFIDENTIAL 10/13/2011
5 Diagram
Redtea
Page 8
CONFIDENTIAL 10/13/2011
Redtea
Page 9
CONFIDENTIAL 10/13/2011
Redtea
Page 10
CONFIDENTIAL 10/13/2011
6 Design
7 Class Diagrams (Individual) 8 Class Diagram by Team Member
Redtea
Page 11
CONFIDENTIAL 10/13/2011
Redtea
Page 12
CONFIDENTIAL 10/13/2011
Extra
RegularCheckingAccount -earnInterest = false: boolean -writeChecks = true: boolean -withdrawalLim itations = false: boolean -payFees = true: boolean
InterestCheckingAccount -earnInterest = true: boolean -writeChecks = true: boolean -withdrawalLim itations = false: boolean -payFees = true: boolean
MoneyMarketAccount -earnInterest = true: boolean -writeChecks = true: boolean -withdrawalLim itations = true: boolean -payFees = true: boolean -am ountOfChecks = 3: Integer -am ountOfWithdrawals = 6: Integer
SavingAccount -earnInterest = true: boolean -writeChecks = false: boolean -withdrawalLim itations = true: boolean -payFees = true: boolean -am ountOfWithdrawals = 6: Integer
CertificateDepositAccount -earnInterest = true: boolean -writeChecks = false: boolean -withdrawalLim itations = false: boolean -payFees = false: boolean -rolloverDate: Date
Redtea
Page 13
CONFIDENTIAL 10/13/2011
EarnInterest +isEarnInterest(): boolean +getInterestAm ount(): double +process(am ount: double): void
Redtea
Page 14
CONFIDENTIAL 10/13/2011
Adapter pattern has been used in this project because it helps us achieve some goals, but the most two important things are: - Split the whole project into smaller project without dependencies in each other. For example, the client and server communicate with each other through proxy object, a person who develop client can introduce new function with number of parameters and leave a description how that method will be used, the purpose of each parameter and the expected result from that method on the IATMServer, after that, that programmer can move on and suppose that the method working already. Then when the person who develops the actual server come to that point, that developer will finish the rest to produce the expected result. In this scenario, the person who develop client does not care what happen at the server side and vice versa. Thus, the work will twice faster than normal because we do not spend time to wait for one to another to finish the job in order to move on.
Redtea
Page 15
CONFIDENTIAL 10/13/2011
With this pattern, our server can easily support other ATM client from other companies without modify a single line of code from either our server or their client. All they have to do is produce an adapter class to convert their current data into ours.
Redtea
Page 16
CONFIDENTIAL 10/13/2011
Command Pattern:
This pattern will helps us encapsulate each of transaction into a single object. Thus whenever we want to modify an object to adapt to new type of transaction, we only modify that single object, and it will not affect other class in the system. Also, if we want to introduce new kind of action, we just have to create new command object to act as the new type of action. In addition, this pattern support the undo function, thus, we can use it to undo an action that might have error on the system.
Redtea
Page 17
CONFIDENTIAL 10/13/2011
Redtea
Page 18
CONFIDENTIAL 10/13/2011
Decorator Pattern:
All the account will have the same basic attribute such as current balance, currency, and account type and so on. However, each type of account will behave differently, and each of account from each bank will be different as well. In order to implement those different, we would have implement a thousand of thousand of class of account type. However, with this pattern, we only need to create the new wrapper type of new bank account, then encapsulate new behavior of that bank account as a single object (strategy pattern would be the best choice here) then put it inside the wrapper class and the problem will be solve.
Redtea
Page 19
CONFIDENTIAL 10/13/2011
This pattern will help us control the creating new instance object of a class because if we use the new key work all over the place, it is not a good practice.
Redtea
Page 20
CONFIDENTIAL 10/13/2011
MVC Pattern:
For this pattern from the book, it actually is a MVC Compound pattern. A set of different patterns applied. By separating the roles into three parts, the View of the program is using the Composite pattern, because it has a lot of buttons and panels to display.
Redtea
Page 21
CONFIDENTIAL 10/13/2011
The Controller class is using Strategy pattern to interact between the View and Model. When there is an event from the View, the controller will take process to the Model and notify the View to change. It implements the IController interface, and uses these methods to control actions from View to Model. Model class is the ATMClient, used to connect to the server and handle all logic executions. However, the Observer pattern was not applied to this client, because in ATM systems, we only have a unique card to put in at a time. We do not have different screens for an account to see changes by the Observable interface. The second reason is that we do not need to accomplish the ATM System Monitor. So that it is not really necessary to use Observer on client.
Redtea
Page 22
CONFIDENTIAL 10/13/2011
Observer Pattern:
The actions that interact between user and computer are easily handled because every time user click button or press a key, it will trigger an event. But what if there is a change in the internal of the program and we want to notify the change to the user, how can we do it? We can use a thread to fulfill the job, however, the thread will run continuously and it cost a lot of resource. We can then reduce the priority of the thread and reduce the refresh rate by putting the thread in sleeping state. However, if there are 2 events occur in the sleeping period, then the user will not know. Here is where the observer pattern comes in; it will notify the observer immediately whenever there is a change from internal. Also, it take less memory to process compare to using thread method.
Redtea
Page 23
CONFIDENTIAL 10/13/2011
Proxy Pattern:
Proxy pattern will help us completely hide the actual class from client and still, it makes the client believe that they are process locally.
Redtea
Page 24
CONFIDENTIAL 10/13/2011
Singleton Pattern:
When we create an object, that object will only available within the class that creates that instance. However, we want that object is available for every class that can access and still, decoupled between that object and other classes. The singleton will do the job for us. In this particular problem, we use the command pattern to encapsulate each of the action and still, we do want to write a log to a file for that action in such the time of the action occurs, the result of the action, and we do not want to see so many relationships all over the place. Thus, we singleton the controller class, this is the class that handle all the internal activity, and through observer pattern, we can write the new log to the log file.
Redtea
Page 25
CONFIDENTIAL 10/13/2011
State Pattern:
This is an important factor to maintain states when the user using the ATM. There are 5 states: Balance State, Withdraw State, Deposit State, Transfer State and normal. If the user is at Withdraw State, he cannot grant access to method deposit (). The states implement State interface. When user selects an action, it will move to the desired state and run its duty. The others methods it will ignore and move to the next state. State pattern provides flexibility to change exact step to step in the application.
Redtea
Page 26
CONFIDENTIAL 10/13/2011
Redtea
Page 27
CONFIDENTIAL 10/13/2011
13 Product Backlog
Backlog Description TITLE Sprint Total Initial Estim ate (Days ) 1.0 2.0 2.0 2.0 2.0 2.0 2.0 13.0 3.0
Adjust ed Estim ate
0 1 4
0 2 5
0 3 7
0 4 14
0 5 14
0 6 17
0 7 12
0 8 11
0 9 16
1 0 0
ATM Simulator
Title Import
0 1 0 1 0 1 0 1 0 1 0 1 0 1 Analyse requirement Write Document Write class diagrams Graphic user interface Basic classes (account, client, server) Withdraw method Deposit method
Adjust Factor 0.2 0.0 0.0 0.2 0.2 0.2 0.2 1.0 0.0
0. 3 1. 0 0. 0 0. 1 0. 0 0. 4 0. 0 1. 8 0. 0 0. 0
0. 3 0. 0 0. 5 0. 4 0. 6 0. 0 0. 6 2. 4 0. 0 0. 0
0. 3 0. 5 0. 0 0 0. 0 0. 0 0. 0 0. 8 0. 0 1. 1
0. 3 0. 0 0. 0 1. 0 0. 0 0. 6 0. 0 1. 9 0. 8 1. 2
0. 0 0. 0 0. 0 0. 7 0. 6 0. 0 0. 0 1. 3 1. 5 0. 5
0. 0 0. 5 0. 5 0. 0 0. 0 0. 0 0. 6 1. 6 0. 3 0. 0
0. 0 0. 0 0. 0 0. 0 0. 4 0. 8 0. 4 1. 6 0. 4 0. 0
0. 0 0. 0 0. 0 0. 0 0. 6 0. 6 0. 6 1. 8 0. 0 0. 0
0. 0 0. 0 1. 0 0. 0 0. 0 0. 0 0. 6 1. 6 0. 0 1. 8
0. 0 0. 0 0. 0 0. 0 0. 0 0. 0 0. 0 0. 0 0. 0 0. 0
3.0
0.2
3.6
Redtea
Page 28
CONFIDENTIAL 10/13/2011
0 2 0 2
Sprint - 2 (Totals) 0 Testing ATM simulator 3 system 0 3 Formatting, comment 0 3 Complete report Sprint - 3 (Totals) Release - 1
0. 0 0. 0 0. 0 0. 0 0. 0 0. 0 0. 0 1. 8
0. 0 0. 0 0. 0 0. 0 0. 0 0. 0 0. 0 2. 4
0. 0 0. 0 1. 1 0. 2 0. 4 0. 0 0. 6 2. 5
0. 0 0. 0 2. 0 0. 0 1. 5 0. 0 1. 5 5. 4
0. 0 0. 5 2. 5 0. 6 0. 6 0. 0 1. 2 5. 0
2. 0 0. 2 2. 5 0. 0 0. 7 1. 5 2. 2 6. 3
0. 5 0. 5 1. 4 1. 5 0. 0 0. 0 1. 5 4. 5
0. 0 1. 0 1. 0 0. 0 0. 0 1. 5 1. 5 4. 3
0. 0 0. 8 2. 6 1. 5 0. 0 0. 0 1. 5 5. 7
0. 0 0. 0 0. 0 0. 0 0. 0 0. 0 0. 0 0. 0
Redtea
Page 29
CONFIDENTIAL 10/13/2011
14 Sprint Backlog
Redtea
Page 30
CONFIDENTIAL 10/13/2011
Confirm that the project is on track Examine the functionality which has been delivered Discuss functionality which was committed but not finished
5m 15m 5m
Redtea
Page 31
CONFIDENTIAL 10/13/2011
Confirm that the project is on track Examine the functionality which has been delivered Discuss functionality which was committed but not finished
5m 15m 5m
18 Attachment 1
Dont want comments on source code.
Redtea
Page 32
CONFIDENTIAL 10/13/2011