To:
The UML diagrams show 3 classes. And each class has data members and methods. Each of these can have 1 of 4 different access levels (public, private, protected or default/no modifier). The first step is to create the classes as you see in the diagrams. Start with the Account class first as it has no dependencies on any other part of the program. Then in main/driver try to create a simple Account instanceand use the methods. If that works, then move on to the Person class and repeat the process, adding the data members and methods. Then do a test dedicated to Person and see if you can alter the Account data member in Person correctly
UML Lab – basic object relationships (composition and inheritance) I know there is a lot of text here but please read it all. I continually get questions that are answered word for word in the document below. Please do feel like you can ask me any question you need but you may feel a little awkward if my response is to copy and paste lines out of this assignment specification. Bank bank:Bank -persons:Person[0…10] -personNumber:int +addPerson(name:String) +withdrawAccount(name:String, amt:int) +depositAccount(name:String, amt:int) +getAccountBalance(name:String) : int -getPerson(name:String) : Person Person -account : Account -name : String +Person(name:String) +getName(): String +deposit(amt:int) +withdraw(amt:int) + getAccountBalance() : int Account - value:int +Account(int value) +Account() +withdraw(amt:int) +deposit(amt:int) +getValue() : int Consider the following UML class diagram above. These UML class diagrams represent the design for 3 simple classes that work together -> Bank is composed of Person, and Person is composed of Account (note that this is usually shown with symbols which we will learn later but for now I will represent it with attributes, this is also an accepted representation if more rarely used). First, we will be translating this diagram into code. Remember that UML has 3 parts: ClassName attributes methods Access Modifiers UML also has a few symbols and other quirks to get used to. When it comes to access modifiers: + means public - means private (# mean protected and ~ means package/default but they are not used here). Special note: classes can have access modifiers too but they are usually reserved for 2 uses. The class that the file is named for (remember that the class where main is and the file must be named the same for the program to run) must be public. Otherwise, the JAVA Virtual Machine cannot access and start the application. Inner classes (a class within the scope of another class) can at times have access modifiers to (typically private). But for now, NO, I repeat, NO inner classes. Each class above should be separate from each other in their own individual scope. There are reasons to make inner classes that we will learn about later (chapter 9) but for now do not use inner classes (the book does breifly describe inner classes in chapter 3 and 6 but we wont need them for anything yet). Type Next, the type of a variable or attribute follows the name and is typically separated by a colon : “ name : String This also denotes the return type of a method as well: public int getValue() +getValue() : int You will sometimes see “: void” after a void method (a method that does not return a value) or other times like in the examples above the void will be implied if it is left blank. Arrays Next is that arrays are usually implied. Like grades:int may imply that there is more than 1 grade and it is up to the programmer to decide how they want to implement that. Other times the array is explicitly indicated with [0…5] saying that there are between 0 and 5 values in the array. Static vs Instanced Everything written is normally considered to be instanced by default and everything that is underlined is to be written as static. Remember that instanced things are unique to each instance or object of the class whereas static things are shared by all instances of the class. Filling in what is missing (50%) You will be making your best judgement as to what each method does and how each variable is used but typically the names of these are a good indication of what you need to add. Anything ambiguous is typically left to the programmer to decide how to solve, however sticking to the diagram is imperative, even if we don’t understand why we may be doing something (in this case it may not have a completely practical reason I just want you to demonstrate your proficiency at reading the diagram – other times the practical reason will only be understood in future classes). Obviously getValue() : int in the Account class is going to return the value stored in that class, hopefully much of the code is similarly intuitive (though you can always ask the instructor if you feel the need to). Adding a driver (25%) The code above is what we typically refer to as the model, as it models the behavior of the real world or application. What we need to use it is a driver (which in this case will serve as the controller and view as well). The job of the driver is to initialize everything and get the program started. It is also common for debug/testing drivers to create and populate the application with sample data to test with. This will be your job now. In a separate class (name it UML_Lab_Driver), create a main and run the program from there. In order to run the program the file must be named the same as this class and this class must be public (note that you can put the driver in a different file but it must be in the same package or folder - src is fine). In the test driver you will create 4 different Persons and add at least 3 withdraws and deposits to each person and display the results to confirm that everything works as expected. You may hard code values into a test driver (the values are meant for testing they are not the final values that a user would use). Adding Additional Account Types (25% to 30% or 10 for each, 5% bonus for getting the creditCard account correct) Now we will be adding in additional account types for checking account, savings account, and credit card account. These accounts will be based on the basic account class you made. You will be extending them with your new classes and overwriting methods as needed. Example: class checkingAccount extends Account By extending the Account class (Account will then be referred to as a Parent/Super/Base class – yes, I know, why do they have so many different names, we just have to deal with it) all the data members (like the value in the Account class) and all the methods (like the withdraw and deposit) become available to use in the sub class. However, since value is private you cannot directly access it and instead will still need to call the base class version of withdraw, deposit, and getValue in order to work with the value. The checkingAccount will be the easiest. Each time a purchase is made out of the checking account the account gets “cash back”. A percentage (1% or .01) of any withdraw gets added back to your account. In order to accomplish this you will need to overwrite and use the existing withdraw and deposit methods. Sub classes that inherit methods from a base class may “overwrite” methods and provide their own unique behaviors for those methods. They can even use the existing methods from the base class in their implementation. class base { public void test(int i) { //do something } } class sub { public void test(int i) { //do unique things //call base class to do its thing super.test(i); } } A couple of things to note. The method header must match exactly to overwrite a method, including all the input parameters (some languages differ when it comes to return type though). Even if for whatever reason you no longer need a specific parameter you must still take it in to match the base class. You may access the base classes behavior by using the super keyword, but you are not required to do this. In our case though since only the super class can edit the value we will need to make use of the super classes methods to do this. Next will come the savings account (or class savingsAccount extends Account). The savings account will get a bonus every time you deposit money of 5% or .05. But will incur a penalty of 8% or .08 every time you withdraw money from it (theoretically there would be adjustment periods where the penalty would be reduced or eliminated when certain criterion were met but we will keep things simple for now and not worry about that). For this class we will need to overwrite both the withdraw and the deposit methods as well as make use of those methods in the base class. Finally, we have the creditAccount. With credit cards you have a certain balance to start that is given to you on credit (kind of like a loan). We’ll say $1000 will be the default and this value can be recorded as the creditLimit (an int is fine to store this), though the value with this account will record not how much money you have in the account but how much you have charged to it. When you withdraw money you are adding to the value and if we getValue we want to know how much we have left before we reach our limit (so we will have to overwrite that method as well in this class). Note that we cannot overdraft our account so we will have to make sure any withdraws do not let the value exceed the credit limit, though deposits, which subtract from the value, may exceed the 0 and thus there would be a negative value in the account (showing that you have more than the credit limit that you can use). Last thoughts Other things to consider, please add appropriate comments to your code (no every line doesn’t have to be commented but an utter lack of comments may be grounds for losing some credit) and do your best to ensure that the code is formatted well prior to submission. Again, I want all of your .java files necessary to compile and run the code myself (it is fine if you have package lines at the top). Do not submit .class files, and if at all possible, please do not zip or rar the code unless eCampus gives you problems submitting your files – alternatively you may email me your code at that point with a description showing eCampus not allowing your submission for whatever reason. And lastly, I will repeat this as often as I can, make this your own individual work. If I find submissions that do or have surprisingly similar quirks in design or formatting it is rather obvious. Even if you have gotten away with cheating in the past do not think you can continue to do so all the way through this course or through your degree. Please do your work and if you run into problems ask and discuss the code with your instructor.