The applet windows of the Customer side 

Contexts in source publication

Context 1

... refined a formal use case diagram and obtained a set of activity diagram, now we generate class diagrams from this diagram information. The class diagrams are built from Java swing classes. In the method, each use case corresponds with an applet class. Use cases are translated into classes with the same name as these use cases. The translated classes specialize in a Java Applet class. The components of the applet (use case) are described in activity diagrams. A terminal state is translated into that Java swing class represented by the stereotype of the state. The Java swing class is connected from the container class (i.e., that class working as an applet window in the use case diagram) and uses an association relationship whose role’s name is the one on the terminal state. For example, those terminal states stereotyped as <<JTextArea>> are translated into a JTextArea class in the class diagram. Some- thing similar happens to the rest of stereotyped states and transitions. The non-terminal states of an activity diagram may correspond to some other use cases (applets) or activity subdiagrams. In the last case, the non- terminal states can be considered an abstract class in the class diagram. Then, it can be described in another class diagram with the same name as that abstract class. Figure 3 shows the resultant class diagram of the customer side. The class diagram contains six classes of the applet type, four of which directly specialize in the Applet class: the NotifyShoppingCartEmpty class, the Customer class, the ConfirmRemoveArti- cle class and the ShoppingCart class. The other classes inherit the Applet class through their super classes. For example, the Purchase class inherits the applet class from the QueryCatalogue class. These six classes —which (direct or indirectly) inherit the applet class— correspond to those five use cases at the customer side in the use case diagram together with the customer actor. Furthermore, note how the stereotyped states and transitions in the activity diagrams are translated into Java classes in the class diagram. The stereotype name of a transition or state is translated into the appropriate Java swing class. The name of the stereotyped state (transition) is translated into an association between the swing class and the applet class that contains it. For example, the <<JButton>> stereotype of the Proceed transition that appears in the Manage shopping cart activity diagram (see Figure 2) is translated into a JButton class. The transition name ( Proceed ) is interpreted as an association —labeled with the same name— between the JButton class and the class containing it (i.e., the Purchase ). Due to the extension of the resultant class diagram, some classes have not been included in the figure. Finally, rapid GUI prototypes could be obtained from the class diagram. Figure 4 shows a first visual result of the Purchase applet, but without functionality. Note how the Purchase window (applet) is very similar to the Query Catalogue window, except that the second one includes three buttons more than the first window. This similarity between applets was reflected in the original use case diagram as a generalization relationship between use cases (applets), here, between the use cases Query catalogue and Purchase . Since the Internet Shopping project was designed, the customer will always work on a Purchase applet ...

Context 2

... the Customer applet, and never on a Query Catalogue applet, though the first one inherits the behaviour of the second (i.e., by the relation of generalization). The Shopping Cart window ( Figure 4, c) appears when the Show Cart button is pressed on the Purchase window (Figure 4, b). Note in the original use case diagram, shown in Figure 1, how the button is associated with the window by means of an << include >> relation between use cases. On the other hand, the two information applet windows (Figure 4, d) are also associated with two buttons: the Remove article button in the Shopping Cart window and the Proceed button in the Purchase window. Note again how these windows are also described as include relations between use cases. Also observe the activity diagrams shown in Figure 2 to track better the behaviour of the example. To develop the case study we have used the Ratio- nal Rose for Java tool. For space reasons, we have included here just a part of the GUI project developed for the case study. A complete version of the project is available at ̃liribarn/ Investigacion/usecases.html . In this section we will formalize the described method, and provide a formal definition for use case diagrams and use cases. In particular, we will define the use case relationships << include >> and generalization. We will also define well-formed use case diagram which follows some restrictions. In addition, we will provide an abstract definition of GUI, and we will define two relationships between GUI: inclusion and generalization. This will allow us to define a generic transformation technique for use case diagrams into a set of GUI. Finally, we will establish some properties of this transformation technique. Now, let us define a use case diagram as follows: Now, we formally define a use case being specified by means of an activity diagram as ...

Context 3

... the Customer applet, and never on a Query Catalogue applet, though the first one inherits the behaviour of the second (i.e., by the relation of generalization). The Shopping Cart window ( Figure 4, c) appears when the Show Cart button is pressed on the Purchase window (Figure 4, b). Note in the original use case diagram, shown in Figure 1, how the button is associated with the window by means of an << include >> relation between use cases. On the other hand, the two information applet windows (Figure 4, d) are also associated with two buttons: the Remove article button in the Shopping Cart window and the Proceed button in the Purchase window. Note again how these windows are also described as include relations between use cases. Also observe the activity diagrams shown in Figure 2 to track better the behaviour of the example. To develop the case study we have used the Ratio- nal Rose for Java tool. For space reasons, we have included here just a part of the GUI project developed for the case study. A complete version of the project is available at ̃liribarn/ Investigacion/usecases.html . In this section we will formalize the described method, and provide a formal definition for use case diagrams and use cases. In particular, we will define the use case relationships << include >> and generalization. We will also define well-formed use case diagram which follows some restrictions. In addition, we will provide an abstract definition of GUI, and we will define two relationships between GUI: inclusion and generalization. This will allow us to define a generic transformation technique for use case diagrams into a set of GUI. Finally, we will establish some properties of this transformation technique. Now, let us define a use case diagram as follows: Now, we formally define a use case being specified by means of an activity diagram as ...

Context 4

... the Customer applet, and never on a Query Catalogue applet, though the first one inherits the behaviour of the second (i.e., by the relation of generalization). The Shopping Cart window ( Figure 4, c) appears when the Show Cart button is pressed on the Purchase window (Figure 4, b). Note in the original use case diagram, shown in Figure 1, how the button is associated with the window by means of an << include >> relation between use cases. On the other hand, the two information applet windows (Figure 4, d) are also associated with two buttons: the Remove article button in the Shopping Cart window and the Proceed button in the Purchase window. Note again how these windows are also described as include relations between use cases. Also observe the activity diagrams shown in Figure 2 to track better the behaviour of the example. To develop the case study we have used the Ratio- nal Rose for Java tool. For space reasons, we have included here just a part of the GUI project developed for the case study. A complete version of the project is available at ̃liribarn/ Investigacion/usecases.html . In this section we will formalize the described method, and provide a formal definition for use case diagrams and use cases. In particular, we will define the use case relationships << include >> and generalization. We will also define well-formed use case diagram which follows some restrictions. In addition, we will provide an abstract definition of GUI, and we will define two relationships between GUI: inclusion and generalization. This will allow us to define a generic transformation technique for use case diagrams into a set of GUI. Finally, we will establish some properties of this transformation technique. Now, let us define a use case diagram as follows: Now, we formally define a use case being specified by means of an activity diagram as ...