Create a UML Model and Transform the UML Model to Java Using TDD

timer Asked: Jul 17th, 2015

Question Description

Complete Insturction is on attachment file. The datas needed to complete the assignment is attached as well. All instructions must be followed. Any incorrect, incomplete, low work won't be accepted.

Read the instruction first before you bid. Again, if you do it wrong, I will NOT give you another day to fix it.

Instruction.docx  (Read first and must meet all the requirement and provide quality)



UML Lecture.docx  (this shows sample picture of UML and helpful information)

Assignment_02 “Create a UML Model and Transform the UML Model to Java Using TDD” 1. Create the user story for “Withdraw_Money_UC” in Astah, using the basic UML Model template in Astah for “Authenticate_Customer_UC” that I have already provided to you on Attachment. Make sure you create a new package in the browser structure for the use case “Withdraw_Money_UC”. 2. The user story should begin with the precondition that the “Authenticate_Customer_UC” completed successfully. 3. A complete and accurate user story is the cornerstone of a successful UML Model and Java application. Remember, all you are describing is a step-by-step process describing WHAT (NOT HOW) the External Actor(s) (Customer, BankDatabase) and the System (ATM) must do for the Customer to withdraw money from the ATM. Here’s how we would start this user story: (1) “The use case begins when the Customer selects “Withdraw Money” from the list of customer choices displayed by the ATM. (2) The System responds by displaying a request for the Customer to enter the desired amount of currency to be withdrawn. (several intermediate steps……….) (n) The use case ends when (a) the Customer has received the currency from the ATM; and/or (b) the Customer has received his/her ATM card from the ATM.” There are 2 and ONLY 2 – conditions that must occur in this user story: (a) The ATM/BankDatabase must verify that the Customer has sufficient funds in his/her account for withdrawal before dispensing currency; (b) The Customer must choose whether or not he/she wants to make a further transaction (e.g., “Transfer_Money”, “Deposit_Money” etc.); 4. Write the “Withdraw_Money_UC” user story into the document window that corresponds with the Withdraw_Money_UC” use case icon in your Astah UML Model file. Now create your use case diagram (UCD), activity diagram (AD) and sequence diagram (SD) using the Astah UML Model template for the ATM “Authenticate_Customer_UC” already posted on Moodle. Make sure you place all your diagrams UNDER the use case icon – which should already be under the new package you just created. Use the UML Model ATM Template Astah file I created for “Authenticate_Customer” and posted on attachment. 5. Now focus on the sequence diagram (SD). Translate this SD into 3 Java classes: (1) a JUnit test class; (2) an ATM class; & (3) a BankDatabase class; the JUnit test class will play the role of Customer in the Java code testing; name the JUnit test class “”; 6. Write an “Assert Statement” that tests whether or not the Customer has sufficient funds in his/her account to cover the amount of the withdrawal requested. Page 1 of 2 7. Now create the Java code in your JUnit test class that will implement this test. Note that you should test 2 conditions: (1) the Customer has sufficient funds to cover the requested withdrawal; (2) the Customer does NOT have sufficient funds to cover the requested withdrawal; (1) Place the JUnit test class in the “test” directory; put the “” class in the “production” directory; put the “” in the “helper” directory; (2) Write the Java code within the JUnit test class that will create an instance of the BankDatabase class; have the JUnit test class initialize the BankDatabase class with a Customer account balance of 500 dollars (Type int) using an overloaded constructor; (3) Have the Customer request a withdrawal of 400 dollars (Type int) from the ATM; NOTE: You must have the JUnit object pass the reference to the BankDatabase object it created to the ATM object; otherwise, the JUnit test object and the ATM object will be dealing with different instances of the BankDatabase object; (4) Now use JUnit to test whether there is a sufficient amount of money in the Customer’s account or not; (5) Now rerun the test by having the Customer request a withdrawal of 600 dollars (Type int); (6) Rerun the JUnit test; (7) Take screen shots of your command line for both tests including the JUnit Swing GUI result; (8) NOTE: You have not been asked to test the “Any further transactions” condition; 8. For assignment submission you must include: (1) your Astah UML Model that includes the “Withdraw_Money_UC” user story and UML Model with UCD, AD and SD; (2) a screen shot of the command line (compile & execute statements) plus the JUnit Swing GUI results for both tests; (3) a screen shot of your Java code for all Java classes in this assignment; & (4) a zip/RAR file containing your Javadoc web pages for all 3 Java source code files; 9. Don’t forget to comment your Java code using Javadoc, then execute Javadoc from the command line and zip/RAR your web page files to submit them. Page 2 of 2
UML_to_TDD_Monograph_01_StudentTest_example_v5.0_150712 UML_to_TDD_Monograph_01 – “UML Model to TDD – StudentTest JUnit Test Class & Student Production Class Overview Let’s review the UML Model sequence diagram for “StoreStudentName_UC”. It is shown in Figure 1. Figure 1. the AL_00_WB_SD for “StoreStudentName_UC;” The question before us is, “How do we translate this UML Model into Java code using TDD with JUnit? Answer: we have to define the “single responsibility” of the production class. Defining the JUnit Assert Statement The key to translating the UML Model sequence diagram into Java source code is an accurate JUnit assert statement. To understand what the assert statement must be, we have to understand what functional behavior criterion are we testing. Clearly, in the Student class case this functional behavior defines the class “single responsibility”. This “single Page 1 of 7 UML_to_TDD_Monograph_01_StudentTest_example_v5.0_150712 responsibility” is to store a submitted student name, and when asked to retrieve the student name stored, can retrieve the same name stored. What we must do now is translate this criterion of functional behavior into an “assert statement” that either (1) compares 2 like Java Types or (2) evaluates a boolean expression that will return “true” or “false”. Following this line of reasoning, we reach the following conclusion: “The condition to be tested is whether the student name to be stored that is submitted to the Student production class is the same name that is returned when requested.” What we are asserting in this statement suggests a comparison between the student name submitted for storage and the student name retrieved. This comparison satisfies the JUnit “assertEquals()” statement. This helps us build the JUnit test class. Using the JUnitTestTemplate class already presented, here is our first cut. We will name it the “” JUnit test class. The associated production class will be the “” class. Here is the skeleton JUnit test class. Figure 2. the skeleton JUnit test class, “”, based on an “assertEquals()” statement; Page 2 of 7 UML_to_TDD_Monograph_01_StudentTest_example_v5.0_150712 The Production Class, “” Having the “assertEquals()” statement helps to establish the “skeleton” Java code framework for the desired production class, “”. We know the “” class must have (a) a means to store the student name, and (b) a means to retrieve it. This means we should use a “Student” class instance variable to store the student name and a method to retrieve it. Here is the resulting skeleton of the “” production class. Figure 3. the skeleton of the production class, “;” Submitting a Student Name to be Stored We already know that to use the services of the “” class we have to create an instance of this class. Further, it is a well-known “design pattern” to pass in the student name to be stored as a parameter to a Student class overloaded constructor. This overloaded constructor would be “ public Student(String name) { studentName = name; } The JUnit test class, “” would add the following line of Java code in the test method “testStudentNameStorage()”: Page 3 of 7 UML_to_TDD_Monograph_01_StudentTest_example_v5.0_150712 assertEquals(studentNameSubmitted, studentNameRetrieved); Retrieving the Stored Student Name We would like the “getStudentName()” method to return the value of the instance variable, “studentName” to the class that calls this method (the JUnit test class in our example). We will insert another line of Java code in the JUnit test class (a) defining a String variable, and (b) assigning the value of the returned String variable to the new JUnit String variable. Here is the resulting JUnit test class, Figure 4. the resultant JUnit test class,; note that the Javadoc documentation is completed in the final JUnit test class version below; Below is the final StudentTest JUnit test class. Notice that I have removed the instantiation of the StudentInformation class from the test method “testStudentNameStorage()” and added it to a “setUp()” method. The purpose of the “setUp()” method is to initialize the test by creating an instance of the production class to be tested and passing to it any initial data necessary to start the test. By doing this, I can maintain the “studentInfo” reference variable in scope for other tests. As an instance variable, it will be available (“in scope”) as long as the JUnit test class is loaded. The production class we are trying to build, “” shown in Figure 3. above, remains the same. Notice again that we used the JUnit test class to help us establish the necessary Java code components to “build” the production class, “”. Page 4 of 7 UML_to_TDD_Monograph_01_StudentTest_example_v5.0_150712 Here is the final JUnit test class, “”. Figure 5. the final JUnit test class, “”; Note that we can “refactor” the “testStudentNameStorage()” method by eliminating a line of Java source code. We can simply replace the “studentNameRetrieved” String variable in the “assertEquals()” method with “studentInfo.getStudentName()”. Try it on your own. Page 5 of 7 UML_to_TDD_Monograph_01_StudentTest_example_v5.0_150712 Here is the output from the command line displaying the successful JUnit test GUI. Figure 6. The JUnit test Page 6 of 7 UML_to_TDD_Monograph_01_StudentTest_example_v5.0_150712 Summary Figure 7. The original UML Model sequence diagram Here is the translation of the UML sequence diagram into Java code as seen above. UML Sequence Diagram Message Java method Comments 1. submitSpecificStudentName(String studentName) Student studentInfo = new Student(“Reece Robinson”) 2. receiveSpecificStudentName(String studentName) 3. storeSpecificStudentName(String studentName) 4. retrieveSpecificStudentNameRequest() StudentInformation(String submittedName) studentName = name; 5. retrieveSpecificStudentName(String storedName) 6. returnSpecificStudentName(String storedName) return studentName; JUnit test class called production class overloaded constructor. overloaded constructor; overloaded constructor code; called retrieval method; same as above; 7. compareSubmittedWithReturnedName() assertEquals(studentNameSubmitted, studentNameRetrieved); Page 7 of 7 studentInfo.getStudentName(); String studentNameRetrieved = studentInfo.getStudentName(); assigned returned String to new String variable JUnit assertEquals() statement
Lecture_04 • Introduction to UML 1 The Unified Modeling Language (UML) Invented by Booch, Jacobson and Rumbaugh (the “three amigos”) as a universal modeling tool to facilitate precision of technical expression and communication among software engineers. •UML is currently in version 2.0. •Independent of any software language. •Object-oriented. •Has strict rules of usage and syntax. •Has become a world standard managed by the Object Management Group. Please see •Establishes relationships to describes different “views” of a system. •UML has the notion of a “Class” with attributes (data) and operations (behavior). •UML supports inheritance (including multiple inheritance). •There are special relationships that can be described between and among Classes. These are: –Inheritance (“is a” relationship) –Aggregation (“ is a part of”, or “has a” relationship)– an open set –Composition (“is composed of”, or “has a” relationship) – a closed set –Association –Dependency 2 The Generalization (Inheritance) Class Relationship This Class Diagram shows the inheritance relationship. •The Square “is a” Shape, as is a Triangle, etc. •Each Subclass inherits operations from the Superclass. •Class Square inherits the computeArea() operation from Class Shape as does Class Triangle and Class Circle. •“Polymorphism” ensures that when an instance of any Subclass is created, and the computeArea() operation is called, only the operation for the specific instance created is called. •For example, if I create an instance of the Square Class and call the operation computeArea(), the operation for computing the area of the Square is called. •It’s like magic! •Note the Shape Class is shown in italics. In UML, this means it is abstract and therefore cannot be instantiated. 3 The Aggregation Class Relationship This is an example of Aggregation. A Vehicle Class “has a” –Door Class –Engine Class –Tire Class •But even if one of these Classes is missing, it is still a Vehicle Class. •This is an example of an open set. •NOTE: The arrowhead on the aggregation relationship symbol is for navigation purposes. The Vehicle class knows about the Door class, for example, but the Door class does NOT know about the Vehicle class. 4 The Composition Class Relationship This is an example of Composition. The compound NaOH Class contains (“is composed of”) Na+ and OH-. •It would NOT be NaOH unless it contained BOTH the Na+ Class and the OH - Class. •It is still a “has a” relationship. •This an example of a closed set. 5 Class Relationship Examples – “WaterBottle” Class Suppose we consider the WaterBottle class. • The class is the fundamental abstraction or “template” within object-oriented technology. • The class has data (information in the form of attributes). Note that they are private. • This data is persistent and is required for an instance of the class to do its job. • It also has behavior in the form of operations. Note that these are public. • These operations are what the object does, what can be done to the object or events that the object responds to. • This object (“producer”) provides services to other objects (“consumers”) by providing operations on its public interface. 6 The Dependency Class Relationship • • • • • Consumer objects need to interact with the producer object to receive a service. This is represented by the dependency relationship on the right. What we mean by this is that the object “sending” the message is ACTUALLY calling or INVOKING an operation provided by the producer object on its public interface. In order to make use of the services of the producer object the consumer object needs a relationship with the producer object. Here, an instance of the Person class knows that there is an interface to an instance of the WaterBottle class. HOWEVER, the Person object does not yet have access to an instance of the WaterBottle class (it does not have a reference to it). 7 The Association Class Relationship • • • • An instance of the Person Object knows about the interface to an instance of the WaterBottle object. AND – has access to a SPECIFIC INSTANCE of a WaterBottle class (has a reference to it). Here several Person objects have access to a specific instance of the WaterBottle class (multiplicity). All Person objects have a reference to the WaterBottle class. 8 The Aggregation and Composition Class Relationships • • • The Person object “has” a WaterBottle object (Aggregation). Assume the WaterBottle is “composed of” – A plastic body – An integrated fill tube – An integrated cap This is the composition class diagram. – The WaterBottle “must” have all three to be a WaterBottle (and not just a Container class – see next slide). – These classes are both necessary and sufficient to replace the WaterBottle class in any White Box analysis. – Why? Because we defined it that way with this Composition class diagram. 9 The Generalization Relationship • • • • Here we have generalization. Note that WaterBottle inherits the operations and attributes of Container (an abstract class). That is because they are either protected or public. Note within the WaterBottle class specification that the protected attributes of Container are inherited, as are the public operations, drink() and fill(). The WaterBottle class adds its own public operations, open() and close() and attributes weight and color. Note that the Container class is abstract and therefore cannot be instantiated (see “Detail” tab on the class specification). 10 The UML Use Case A Use Case is the description of a single interaction between an Actor, external to the system, and the system. •The Use Case is used to model behavior desired by the customer. This desired behavior is usually described in the RFP or Operational Concept Document. –The Use Case actually models functional requirements. –THE USE CASE MUST BE INITIATED BY SOME ACTOR EXTERNAL TO THE SYSTEM BOUNDARY. –The Use Case can be described in words, for example, 1.“The Use Case begins when the Actor does something to the system. 2.The system responds by doing something to respond to the Actor’s input. 3.The Use Case ends when the Actor achieves some desired response from the system.” Usually, the Use Case is shown as a Use Case Diagram. •The system is treated like a “Black Box”. The Actor doesn’t know and doesn’t care what is in the Black Box. The Actor only wants to achieve the desired system response. •I have modeled a simple example from real life. The example is Withdrawing Money From an ATM. 11 “Authenticate_Customer_UC” User Story The external Actors are the Customer and the Bank Database. •The System is the ATM. •This is a “sunny day” scenario. 1.“The use case begins when the customer inserts his/her ATM card into the ATM. 2. The System responds by requesting the Customer’s PIN. 3.The Customer responds by entering his/her PIN. 4. The System responds by validating the Customer’s PIN using the Bank Database. 5.The use case ends when the System presents transaction options to the Customer. 12 Use Case Diagram (UCD) Note the association lines between the external actors and the ATM System (use case oval). •They mean both external actor and system know about each other. •The “oval” can be considered as the system boundary. •The use case diagram appears trivial in this use case, but it becomes increasingly important as use cases become more complex. •The use case diagram (UCD) also provides the context within which the use case is executed. 13 Use Case Diagram (UCD) - Observations The Use Case Diagram (previous slide) •The external Actors are the Customer and the Bank DataBase. •The system is the ATM. •“The Use Case begins when the customer inserts his/her ATM card into the ATM. The Use Case ends when the system provides the Customer with several transaction options. •Think of the use case “oval” icon as the ATM system boundary. •The system boundary concept is one of the most important in UML modeling. •The system boundary separates the external actors from the system. The Team responsible for the system only has authority and responsibility within the system boundary. •The Team cannot assign functionality to an external actor UNLESS: –The System needs the services of the external actor to fulfill its functional requirements. –The Team has negotiated the required operations on the external actor functional interface with the responsible external actor team (the ATM Team has negotiated with the BankDataBase Team). •If the System is providing services to an external actor, the System CANNOT assign functional responsibility to that external Actor. •The System must provide all interface functionality to the external actor. 14 The AL_00_Black Box Activity Diagram (AL_00_BB_AD) Note that the Activity Diagram (AD) shows not only the flow of how the use case will execute, but also which class performs each activity. • There is no concept of time in the AD. It is simply a roadmap showing what steps need to be done for the System to interact with the external actors to execute the functional behavior of the use case. •The AD is much better than a standard engineering flow diagram because it shows the interaction of the classes involved. •Make sure you understand the concepts of the –Merge –Decision diamond –Synchronization (“sync”) bar •An activity can have only 1 input and 1 output. 15 The Activity Diagram (AD) - Observations Composed of “swimlanes” named for the Classes that interact within the Use Case. •Each “swimlane” contains the Activities performed by the swimlane Class. •Each Class performs some activity that affects the other Class(es). •These Activities taken together become a “flow diagram” of the Use Case. •There can be conditional (branching) flows (like “if - else” statements in software). •There is one main “thread” of Activity flow. There may be several alternate flows or “branches.” There is one main thread that is called the “sunny day” scenario. •Each Activity is represented as an operation or “message” (like a software method) between Objects in a Sequence Diagram (see next slide). •Note that I said Object, not Class. In the Sequence Diagram we deal with an instance of a defined UML Class. •The boundaries between swimlanes represent Interfaces between Classes represented by the swimlanes. 16 The AL_00 Black Box Sequence Diagram_AL_00_BB_SD) The operations folding back upon themselves are called “reflexive”. •They are contained solely within the collaborating object on whose “lifeline” they lie. •They cannot be “called” by any other collaborating object. They can therefore be considered as “private” access operations. •These reflexives must be initiated by some other operation. They cannot initiate themselves. •All operations terminating on a collaborating object’s lifeline requires the collaborating object to provide the functionality and services demanded by that operation. 17 The Sequence Diagram - Observations The Sequence Diagram (SD) takes each Activity in the Activity Diagram and shows •The Objects that are interacting. •The direction (to-from) of the messages between objects. •These messages can pass data as parameters. •The operations between Objects within the sequence diagram (“Object Lifelines”) become operations supported by the Interface between these Objects. •This Interface is the “contract” between collaborating Objects. •The SD is the heart of UML analysis. It shows which collaborating object provides the functionality for an operation (mapped to a message). If the operation arrowhead terminates on the collaborating object’s lifeline, the collaborating object must provide the operation on its public interface. •This means that the collaborating object providing the operation on its public interface is providing a service to those other objects calling this operation. •The SD shows time running from the top of the SD to the bottom, and therefore the “sequence” of the operations performed in the execution of the use case. 18

This question has not been answered.

Create a free account to get help with this and any other question!

Brown University

1271 Tutors

California Institute of Technology

2131 Tutors

Carnegie Mellon University

982 Tutors

Columbia University

1256 Tutors

Dartmouth University

2113 Tutors

Emory University

2279 Tutors

Harvard University

599 Tutors

Massachusetts Institute of Technology

2319 Tutors

New York University

1645 Tutors

Notre Dam University

1911 Tutors

Oklahoma University

2122 Tutors

Pennsylvania State University

932 Tutors

Princeton University

1211 Tutors

Stanford University

983 Tutors

University of California

1282 Tutors

Oxford University

123 Tutors

Yale University

2325 Tutors