Technically speaking, Zebra is composed of development-time components and runtime components. The main runtime component is the Java code generator. It accepts the UML model as input - either in Rational Rose (rose petal files) or in the universal XML metadata interchange (XMI) format, and generates a set of Java classes implementing the behavior described by the model.
Theoretically, the generated classes can be used per se, either completely composing some application or being only a part of it. But to use all the advantages offered by Zebra, it makes sense to use these classes along with Zebra runtime components. These are, generally, the Zebra server, the Zebra presentations, presentation connectors along with some other lower-scale components helping to create applications.
The Zebra architecture is presented on the following figure:
Fig. 12. Zebra architecture.
As you can see, the classes of Zebra applications are generated as Java classes using the UML model as the source. Then they are compiled by any Java compiler and executed in a certain environment (which is built in course of interaction between the Zebra server and one or several Zebra presentations).
- Zebra server provides the standard implementation of numerous entities which are common for many applications, such as sessions, scenarios of work with users, presentation management functions, security subsystem and so on. The Zebra server runs the classes which implement operation logic and UI logic.
- Presentation is the active layer between the user (client) and the Zebra server. From the viewpoint of the Zebra server (and respectively, of the business and UI logic developer) all presentations look identically, and the access to presentation features is implemented via the same Presentation Java interface. This significantly simplifies the replacement of one presentation with another and, consequently, the restyling of the application appearance (since the UI presentation layer is described within the presentations). The current Zebra version provides JSP, XML and Swing presentations.
- Presentation connectors provide the ability of Zebra server and of the standard presentation to run on different machines, thus allowing to develop systems with a "thick" client based on various protocols. The existing version provides presentation connectors for SOAP and JMS protocols.
- Zebra client is completely controlled by the application running on the server. According to the presentation used, this can be either just the Internet Browser (for a JSP presentation) or a fully-functional application communicating with the server using a certain protocol (e.g., JMS for a JMS presentation).
4.2. Zebra application
Usually a Zebra application has the following structure:
Fig. 13. Zebra application.
- BL implementation - the layer containing the classes implementing the operation logic. Usually these are the UML model classes with the "zbasic" stereotype (see in "Zebra language" section) along with other classes and interfaces probably used by the application, but not generated by Zebra generator (e.g., classes from existing third-part libraries).
- BL interface - the layer of interfaces providing access of the next layer to the operation logic. This layer can be omitted for the not-too-complex applications.
- UI Logic - the layer of user interface logic. Usually implemented by classes with "zbasic" and "zform" stereotypes. The objects with the "zform bean" stereotype are also the integral part of this layer. They act as mediators between the UI logic layer and the UI presentation layer, being the abstractions of data transferred between the visual components of user interface and the objects implementing the respective behavior.
- UI Presentation - this layer is implemented by presentation and presentation-specific objects (components of user interface). Thus, for a JSP presentation these will be the jsp pages, for a Swing presentation - components of the Swing library, and so on.
4.3. Zebra language
As it was already mentioned, the Zebra language is UML + Java. The UML language is used to describe the static structure of application classes (class diagrams) and the behavior of these classes (state diagrams for classes and the Java code of elementary class operations). The UML semantics is not changed, the standard technique of extension (stereotypes) is used. Consequently, Zebra can be used in conjunction with other tools for managing UML models which are compliant to the same standards.
The following class stereotypes are reserved:
- zbasic. The class which has a behavior but is not designed for immediately controlling some element of user interface. On a UML diagram it is a class which can be bound to a state diagram. The generator will produce the respective Java class with the behavior determined by the diagram.
- zform. The class which has a behavior and is designed for immediate control over some user interface element. On a UML diagram this is a class which can be bound to a state diagram, associated with a class of "zform bean" stereotype. The generator produces the respective Java class (with the behavior determined by the diagram and some predefined set of operations required to connect to the presentation).
- zform bean. This class has no behavior of its own. It is used only to transmit data and events between zform and the presentation and is (from the viewpoint of the UI logic layer developer) an abstraction of some UI presentation layer component.
4.4. Example of creating an application with Zebra
Here we provide an example of creating a primitive application using Zebra. The application will open a window (or display a page, depending upon the presentation used), with a "Hello world!" message. The behavior of the application can be described in more details as follows: the application should display a text window with the message "Hello World" inside. The window also should display an OK button. When you press this button, the window is closed and the application terminates.
First, a model defining the application structure is created. Since Rational Rose is currently the main tool of Zebra development, a blank Rational Rose document should be created and initialized (a more detailed description of creating and initializing a blank Zebra model can be found in the Zebra developer's guide).
A Zebra application itself is just a set of classes, the behavior of which is determined by respective state diagrams. In the blank model two classes linked by an association should be created:
Fig. 14. Classes of the "Hello World" application.
One of these classes, HelloWorld ("zform" stereotype), is the primitive controller of a UI control element (in this case the latter is a window or a HTML page). The other class, HelloWorldFormBean ("zform bean" stereotype), specifies the abstract structure of this UI element.
The HelloWorldFormBean class has two attributes (fields):
- A text attribute of the String type - specifies the text to be displayed in the window;
- The ACTION_ok attribute of the int type - defines the button. The attributes starting with "ACTION_", are conventionally used to specify that a user can call a discrete action within this control element - e.g., press a button.
The HelloWorldFormBean class defines the general appearance of the control element, while the controller class HelloWorld describes its behavior. The association between HelloWorldFormBean and HelloWorld specifies the relationship between these classes. The method initializeFormBean() used when creating HelloWorld and HelloWorldFormBean objects is determined for the HelloWorld class. This method is composed of a single code line: "getFb().setText("Hello World");".
Now the window behavior should be defined. In order to do this, a state diagram is set up for the HelloWorld class:
Fig. 15. State diagram of the HelloWorld class
The diagram illustrates what will the lifecycle of the HelloWorld object be:
- Transition from the initial state to the Init state is not labeled by any conditions and does not involve execution of any actions. The transition occurs immediately. Upon entering the Init state two actions are sequentially performed - the call of the initializeFormBean() method (initializes the contents of the text window), and the call of the registerFormBean() method to register the object of the HelloWorldFormBean class within the presentation (displays the window to the user). Finally, the window with the text "Hello World" and the OK button is created.
- Transition to the WaitOkAction state. No actions are performed in this state, just waiting for the transition to the Terminate state.
- The transition from WaitOkAction to Terminate is of the stereotype. This means that the transition will be started only upon receipt of a specific event, only if a certain condition is met, and only after executing a particular action. In this particular case the transition is activated if a FormEvent event is detected. Then, the condition check is performed - whether the detected form event is the ACTION_ok event of the HelloWorldFormBean class. If the condition is met, the unregisterFormBean() method is called - this results in closing the window.
- In the Terminate state the System.exit(0) method is called. The JVM is immediately shut down and the application terminates.
The Zebra technology was successfully used in several software projects and demonstrated decent results. It is suggested to continue developing the technology in future in the following directions:
- Automation of other stages of the development process (or integration with systems and/or technologies providing such automation).
Thus, it is possible to incorporate into the system under development a module facilitating business analysis (by semi-automatic processing of natural language texts describing the subject area and the customer's requirements for the system).
- Introduction of new components simplifying development of applications of specific types (primarily Web applications).
It is suggested to point the technology mainly towards development of Web applications - this implies introducing new or optimizing existing runtime components, adding new stereotypes of classes aimed at implementation of Web applications.
The more distant prospects are:
- Extending the prototyping abilities, allowing to generate prototypes using not only the detailed class diagrams, but also the less detailed use-case and interaction diagrams;
- Support of languages other than Java.