Play with CASE tools for UML state machines

We play with some models of "coffee machines" that accept coins and let the user choose among different drinks, such as coffee or tea.

Here are some historical notes state machine notations and tools:

• The first standardized modeling language for state machine was SDL, which was standardized by the Internation Telecommunication Union for the specification of telecommunication systems and protocol. The simple version from 1976 was extended and improved over the years, and commercial tools were developed starting in the later 1980ies. The most powerful tools for state machine modeling was probably the SDL tool of Telelogic around the years 2000. It includes facilities for automatuic reachability analysis, which is not provided by the current UML tools.
• The first version of UML was developed in the 1990ies. The Rational company had hired several leaders in the field of Object-Oriented System Analysis and Design, such as Booch, Rumbaugh and Jacobson. They played a leading role in the development of UML-1 within the OMG standardization process. They also had developed the so-called ROSE UML tool. Rational had also bought the Canadian company ObjecTime which had been created by Bran Selic (and others) as a spin-off from Nortel. Initially a group within Nortel, they had developed an OO CASE tool which became later the tool Rational Real-Time.
  • During the development of UML-2 in the early 2000, SDL was integrated into UML as a profile. Telelogic developed a new tool for the integrated UML-SDL language, which was called TAU. The SDL graphic notation for the behavior of transitions is called "transition oriented" in UML (here is an example from the UML document, for explanation - see slides 17 - 21 of Dr. Williams' notes).
  • IBM bought the Rational company in the early 2000, and has been marketing UML tools under the name Rational. A few years ago, they also bought Telelogic and offered some of their tools under the Rational banner.
• A discussion whether graphical representations for modeling languages are better than textual representations have been going on for decades. In the 1980ies, I was involved in the standardization of SDL (a graphical language which also had an alternate program-like syntax) and a similar language, called Estelle, which only had a program-like syntax. My colleague, Dr. Lethbridge has a project for developing a program-like syntax for (a subset of) the concepts in UML, called Umple. Recently, the Umple tool has been extended to include UML state machine modeling. Umple is characterized by close integration with the Java programming language and the tool has good facilities for generating Java implementation code for the specified models.

The purpose of this lab is to get acquainted with UML state machine modeling

• Part 1: Creating a UML State Machine model of a coffee machine. The model you create should be written in the graphic notation of UML for state machines (see for instance in the book by Booth et al.). You may draw it nicely by hand, or use any tool available to you.
• Part 2: Generating Java code from a state machine model of the coffee machine, and checking its correct operations through a few tests. The tool to be used for this purpose is Umple. Different versions of the Coffee Machine are considered.
  • Note: No tool is perfect. You will have to adapt to the specific functionalities provided by each tool. Before using a tool for a specific project, you should evaluate the tool to see whether it is suitable for what you intend to do.

Part 1: Create a UML State Machines model of the coffee machine

Description of the Coffee Machine to be modelled in this Lab

The basic functionality of the Coffee Machine is described in the example page. Your coffee machine should include all functions shown by the LTS diagram at the beginning of the web page, plus the following features:

1. Distinction between the controller and hardware components, and the interactions between the controller and the hardware for the preparation of tea.
2. The machine should accept all Canadian coins and allow the repeated selection of coffee or tea if sufficient money was entered before.
3. If after a period of 20 seconds, the user has not made any command, the machine should return all money that has not been spent.
4. The machine should not accept any coins when no cups are available. The machine has an internal counter about the available cups. The machine has a support interface by which an employee can enter new cups and update the internal counter accordingly.
5. Optional: The user may request the addition of sugar during the first 5 seconds after having made a request of coffee or tea.

Your task 1: Please do the following:

1. Draw an architectural diagram - explain
2. Identify the input and output interactions of the coffee machine (as a whole). Include any interaction parameters.
3. Draw the state machine diagram (including state variables, enabling conditions and actions of transitions, etc.). This diagram should be drawn in the graphic notation of UML for state machines.

Part 2: Using the Umple modeling and implementation tool

Please look at the introduction to Umple is on the Web.

Your task 2-A:

• Load the CoffeeMachine-2 into your Jave environment (see explanations in the Coffee Machine web page)
• Use the Umple-Online tool to create corresponding Java code from the Umple code on the Coffee Machine web page.
• Read the Java code and understand it.
• The given User thread realises a very simple use case. Execute the system to simulate the execution of the Coffee Machine; observe the output provided by the system on the console.

Your task 2-B:

• Complete the Umple specification of the CoffeeMachine class to include all the functionality defined by the LTS diagram in the Coffee Machine web page.
• Check the syntax and generate the corresponding Java code.
• Replace the Java code of the CoffeeMachine class by the code generated and make any related changes to the Java code of the other classes in the system.
• Test the obtained coffee machine implementation by executing a few different use cases. For this purpose, either create several versions of the User thread, each realising one use case, or include all the use cases in a single User module - the User module may accept input from the console.
• Include sufficient tracing information in order to be able to check that the different use cases function correctly.

Your task 2-C: Include a "hardware" component in the coffee machine

As shown in the third architecture diagram in the Coffee Machine web page, we now assume that the control unit of the coffee machine communicates with a "hardware" conponent which helps in the preparation of tea. (For the preparation of coffee, we do not introduce any changes for this task). We assume that the output of the transitions triggered by the tea input from the user (see FSM model in the Coffee Machine web page), instead of directly producing cupOfTea, would send the output FillWater to the hardware component, which will answer with the message WaterOK, etc. as indicated by the state machine of the SDL model. After several interactions, the controller will output the cupOfTea (called cupOfWater in the SDL model) to the user, that is, to the Delivery class.

• Change the Umple specification accordingly.
• In the tea processing transitions of the model, make sure that the case of non-specified reception is detected by your program. Note: In basic Umple, this condition is indicated by the fact that the boolean return value of a transition is false.
• Generate Java code and test your program with a simple use case involving the production of tea.
• If you find problems with your implementation, try to understand what is going on, and produce an explanation.

Your task 2-D: Use queued state machines

By using the keyword queued at the beginning of a Umple state machine, one obtains a state machine with input queue.

• Use your Umple state machines for the controller and hardware above, but make them state machines with input queues by using the keyword queued.
• Execute the same test case as for task 2-C. Observe what happens and give an explanation.

Results to be handed in: A lab report (to be submitted on paper to the TA at the next lab session)

Your lab report should report on your results for the tasks for Part 1 and Part 2 above.

The (preliminary) marking scheme is as follows:

• Task 1:
  • Architecture diagram (10 points)
  • Interactions (10 points)
  • State machine model (50 points)
• Task 2-A: (10 points)
• Task 2-B: (20 points)
• Task 2-C: (30 points)
• Task 2-D: (10 points)
• Writing style, organization, presentation of the report: (10 points)

Please consult with the TA during the Lab session. The role of the TA is to help you to do the work suggested within this Lab.