We have now built a static model of our application, so let's move on to the dynamic behavior. We will focus on the use case Order Ticket. Based on the class model (see Design Classes), we see that we need to create a Ticket object with 1 Customer and 1 Flight. The Customer is the user that is logged in to the application. The user needs to select a Flight object to order a ticket.
To select a Flight, the user will go through the following steps:
1. Select an Airport to depart from.
2. Select the destination Airport.
3. Select one of the available Flights between those Airports.
4. Review the price and place the order.
We will implement this use case in the class OrderTicket. This object will gather the information from the user input and place the order when ready. Here is our first attempt at the business methods needed for this use case:
First, the user will select the departure Airport.
The listDepartures() method will return all available Airports,
and the user will select one of them and set the departure.
Then, the user will select the destination using listDestinations().
This method will return all Airports that can be reached from the selected departure.
The user will select one of them and set the destination.
Finally, the user will select a Flight with listFlights(),
which returns all Flights between the selected departure and destination.
Then, the user will set the flight to store the selection
and placeOrder to make the payment.
The list methods will be implemented as database queries.
Their return types are set according to what the query will return
and how many objects:
Airport[*] means that the method will return 0 or more Airport objects.Airport[1] means that the method will return exactly 1 Airport object.Airport means that the method will return 0 or 1 Airport objects.
(This is the same as Airport[0..1])
Note that OrderTicket is not <<Persistent>>, so it will not be stored in the database. (We could do that if we wanted to store this information between user sessions.)
Now, we want to test our methods.
The first method, listDepartures(), should return all Airport objects in the database.
To test the OrderTicket, we will create another class OrderTicketTest that will prepare some objects, call methods in OrderTicket and verify the results. We set the stereotype of OrderTicketTest to <<Persistent Test>>. This will generate some code that makes it easy to test with a database.
To prepare some objects to test, right-click on the OrderTicketTest class and select Design Objects. This will open an object diagram where we can create objects that will be set up before the test is run. We need an OrderTicket object to test, 1 Customer, a few Airports and a Flight:
We will use JUnit to run the tests. JUnit 3 requires that all test methods
start with "test" and have no arguments.
We implement testListDepartures() in Java to call listDepartures() and
verify that it returns 2 Airport objects:
public void testListDepartures() throws Exception {
java.util.List<Airport> departures = orderTicket.listDepartures();
java.util.HashSet<String> departureNames = new java.util.HashSet<String>();
for(Airport a : departures)
departureNames.add(a.getCode());
String[] expected = { "OSL", "ARL" };
assertEquals("departures", java.util.Arrays.asList(expected), departureNames);
}
Before running the test, JUnit will call setUp().
This method calls initObjects(),
which creates the objects we designed and saves the <<Persistent>> objects
in the database.
By default, HiberObjects creates a hibernate.properties file that is configured with HSQLDB running in memory as follows:
hibernate.connection.url=jdbc:hsqldb:mem:mydatabase
hibernate.hbm2ddl.auto=create-dropThis will cause Hibernate to automatically create a clean database every time it starts, so we don't keep the data between test runs. (Make sure to not use this in production.)
It will also run HSQLDB in memory instead of against a database server:
To run the test, select Run -> Run As -> JUnit Test.
We don't expect the test to succeed, we have not even implemented the listDepartures() method yet. Actually, the method will not even compile now.
So, let's implement it. Right-click on the listDepartures() method in the OrderTicket class and select Edit Query. This will open a dialog box with a query:
select a from Airport aThis seems reasonable. Let's save the query and try. (This is not SQL but HQL - Hibernate Query Language. Please refer to the Hibernate manual for more details.)
The test fails, but the result seems to be correct.
The problem is that the test compares a List with a Set.
Let's change the test as follows:
public void testListDepartures() throws Exception {
java.util.List<Airport> departures = orderTicket.listDepartures();
java.util.HashSet<String> departureNames = new java.util.HashSet<String>();
for(Airport a : departures)
departureNames.add(a.getCode());
String[] expected = { "OSL", "ARL" };
assertEquals("departures",
new java.util.HashSet(java.util.Arrays.asList(expected)),
departureNames);
}And run the test again. Success! The method works.
So what have we accomplished? We have implemented the first business method and verified that it works. We will run all tests periodically to ensure that this functionality doesn't break at a later time. We will automate this with JUnit. This is crucial, because it will take far too much resources to test everything manually all the time.
We have achieved this with very little Java code. All the domain objects are generated completely from a class diagram, and the test objects are designed in an object diagram. Not only is this very productive, but the diagrams are also useful for documentation and for discussions with others.