To really implement Rosa's Breakfast Service we have to generate compileable and executable code. This chapter describes the code models and the transformations from the PSMs to the code models. Each of the three PSMs is transformed into a separate code model that is applicable for the specific technology.
The result of the transformation from UML to relational model that is described in this section is a PSM, which is still a model. It is not the code to create the database with. Luckily, the PSM is closely linked to the relational database platform, and uses platform-specific concepts and constructs. From this model, it is easy to generate code.
From the relational model, a pair of SQL scripts is generated. One script is for creating the tables and the other script for dropping the tables. We will examine the creation script only, because the drop script is very simple and does not add much value to the example. The transformation is rather straightforward because the structure and amount of detail of the relational model is already similar to the SQL language. The following rules are used to generate the SQL creation script from the Relation model.
For each table, generate a “CREATE TABLE” text, followed by the name of the table, and a “{“, then execute rule 2, followed by rule 3, and end with “};”.
For each column in the table, generate the name of the column, followed by the name of the type, and (optional) size of the column, then generate “NOT” if the column may not have the NULL value and end with “NULL,”.
Generate a “PRIMARY KEY (” text, followed by a comma-separated list of the names of the columns of the primary key, and end with “)”.
Fragments of the generated code can be found in Appendix B.
To explain the EJB model to code transformation in detail, we must zoom in on the overall picture of the relations between all models used in the MDA process. Figure 6-1 shows a refinement of Figure 4-1. In it a distinction is made between the EJB PSM that represents the coarse grained component model, as described in section 5.2, and an EJB PSM that is much closer to the generated code. This PSM contains class definitions, and is called the EJB Class PSM. The EJB Class PSM consists of class diagrams where the classes relate one-to-one to the actual classes in the Java code. You could say that this model is on the same abstraction level as the EJB source code, but in a diagrammatic presentation.
In this section, we describe the transformation from the EJB Component PSM to the EJB Class PSM. The EJB Class PSM is written in the language defined by another UML variant, the standardized EJB Profile (Java Community Process document JSR26, 2001). Because the generation of code from the EJB Class PSM is very simple, we do not describe it. Fragments of the generated code can be found in Appendix B.
Before explaining the transformation rules, a small introduction to the specific aspects of entity beans in EJB is given.
According to the EJB specification (Sun Microsystems, Enterprise JavaBeans Specification, Version 2.1, 2002), a person (or persons) who develops entity beans must provide the following:
Entity bean class and all classes it depends on.
Key class.
Entity bean's remote interface and entity bean's remote home interface, if the entity bean provides a remote client view.
Entity bean's local interface and local home interface, if the entity bean provides a local client view.
A deployment descriptor written in XML defining some properties of the EJB components. The deployment descriptor describes the transactional behavior of the business methods, and also the persistence strategy for a component.
If an entity bean is managing its own persistence, then in its own implementation it has to call methods of a persistency API like Java Database Connectivity (JDBC). If the entity bean has container managed persistency, it does not have to call these methods but only has to set its own attributes. These attributes are copied from and to the database by the EJB container. Note that EJB containers are not developed by the EJB component developer but are completely generic, and work for all EJB compliant components.
For Rosa's Breakfast Service, we generate entity beans with container managed persistency. Besides that, we have to generate remote interfaces, remote home interfaces, the key classes, and the deployment descriptors, which are written in XML.
In addition to the code required by the EJB standard, we have chosen to generate coarse grained components and components that do not need any manually added code to work. This implies that the code model consists of Java packages with classes that implement the data classes in the EJB components. Each data class in Java has set- and get-methods and private attributes for maintaining the fine-grain data locally. The EJB component and remote interface need to have methods for getting and setting the data objects remotely. The bodies of the Java methods in the bean implementations consist of procedural code to construct the data objects and process all the changes made in the data objects. Although it helps that we have chosen container-managed persistency, we still have to generate a lot of code.
To make the code of the remote EJB clients simpler, a so-called data object manager is created. The data object manager is a normal local java class that creates an instance of the remote interface and is able to retrieve and store sets of data objects.
Figure 6-2 shows the RemoteInterface, the HomeInterface, and the EJB implementation class for the StandardBreakfast component. Note that the class derived from the PIM class Part does not have its own remote or home interface. It is accessible through the StandardBreakfast.
In Figure 6-3 the EJB key classes are shown. In EJB 2.0, the key classes are renamed to Handle classes; therefore, they implement the javax.ejb.Handle class.
Finally, Figure 6-4 shows the EJB data classes, which are communicated to clients of the component. As we can see, all access to Part objects can be done through the StandardBreakfastDataObject class.
It is clear from the above description that generating the code for the EJB Component PSM is far more complex than for the relational model. The EJB coarse grained model abstracts away many details. These details include all the procedural behavior of the EJB components. Because of the complexity of the details, we will not define all the transformation rules in detail, but give a global picture of the transformation rules needed for generating the EJB Class PSM. Because our target is still a visual model, there is no need to explicitly refer to the Java syntax. For example, we will write “generate a Java class” instead of “first generate 'public class' followed by the name of the class.”
The following set of rules is used to generate the classes in the EJB Class PSM for the EJB Entity Components in the EJB Component PSM.
For each EJB Entity Component, one EJB Entity Home Interface, one EJB Remote Interface, and one EJB Implementation is generated.
For each business method in an EJB Entity Component, one method in the Remote Interface and one method in the EJB Implementation is generated.
One “get” method and one “set” method is generated in each EJB Remote Interface and in each EJB Implementation with the corresponding EJB Data Object implementation as result and parameter type.
All the standard methods (according to the EJB specification) for entity beans are implemented in the EJB Implementation.
In each EJB Home Interface, three methods are generated: one EJB Create method, one EJB Finder method based on the EJB Key implementation, and one EJB finder method called findall.
The result of the method in the EJB Home Interface called findall is a Collection that contains a set of instances of Remote Interface that give access to all instances of the corresponding EJB Entity Component.
The following rules are used to generate the classes in the EJB Class PSM for the EJB key classes:
Each EJB key class is transformed into one Java class that implements javax.ejb.Handle.
For each attribute in an EJB key class, one constructor parameter, and one “get” method is generated in the corresponding implementation.
The following rules are used to generate the EJB Class model PSM for the from EJB Data Classes:
Each EJB Data Class is transformed into a Java class that implements java.io.Serializable.
For each attribute in an EJB Data Object, one “get” method and one “set” method is generated in the corresponding serializable Java class.
For each association end navigable from an EJB Data Object with a multiplicity not higher than 1, one “get” method and one “set” method is generated in the corresponding serializable Java class.
For each association end navigable from an EJB Data Object with a multiplicity higher than 1, one “get” method with return type Collection, one “add” and one “remove” method is generated in the corresponding serializable Java class.
The types of the Java parameters and method result types in the EJB Data Object implementation for “get” methods and “set” methods correspond with the Java class that is generated for the type in the source model.
One constructor per EJB Data Object implementation is generated with one parameter with the corresponding Key Class implementation as its type.
For each EJB data schema, one data object manager is generated with methods to initialize the EJB remote interface and to retrieve and store sets of data objects.
In Appendix B, you can find some fragments of the generated code.
To implement the Web components, we have to generate code that handles user requests from the Internet and that produces HTML as a response. In general, the complexity of this code can be high. A good MDA tool provides its user with transformations that are highly complex, thus creating a fully functional and working application, using well-established coding patterns. In this book, however, we generate Web code with simple functionality using a simple coding pattern. Although this is clearly not a sufficient MDA solution, we avoid long discussions about complex Web coding solutions.
In this example, the Web part of the application is implemented according to the J2EE standard for Web tiers (Sun Microsystems, Java 2 Platform, Enterprise Edition Specification, Version 1.3, 2001). We generate code that generates simple HTML pages that hold query results only. The components are implemented using JSP (Sun Microsystems, JavaServer Pages Specification, Version 1.2, 2001). Each request from a user instantiates one JSP and the resulting HTML is sent back to the browser. We generate exactly one JSP file for each Web component. At run-time, the JSP produces an HTML page containing a table with rows that correspond to all objects of one type (e.g., all customers) and columns corresponding to the attributes of that type (e.g., address and account number).
The JSPs access the data from the EJB components by iterating over a set of EJB Data Objects and getting the values of the attributes provided by them. The iteration is implemented in embedded Java code. The JSP code uses the EJB data object manager for the retrieval of the data objects. JSP supports the access of get methods for the attributes by simply stating the names of the attributes.
The following rules are used to generate the JSP code from Web Components and the Web Data Classes:
For each Web Component one “query” JSP file is generated with the same name as the Web component.
Within each query JSP one header is generated containing one name per attribute.
Within each query JSP one “useBean” element is generated to get access to the remote interface of the corresponding EJB entity bean.
Within each query JSP one iteration is written in embedded Java using the EJB data object manager to get the collection and iterate over the set of EJB data objects.
Within each iteration one HTML row is generated with a “getProperty” element for each attribute of the served data class.
One JSP named “MainMenu” is generated.
For each Web Component one URL is generated in the Main Menu JSP to access the corresponding query JSP.
One HTML file is generated that starts up the main menu.
One property file is generated with the static text on the HTML pages.
One JSP named “AppError” is generated to display exceptions to the user.
In Appendix B, you can find some fragments of the generated code.
In this chapter, we have seen that the transformation of the relational model to code is simple, because the relational model contains structures that can be mapped one to one to the structures used in the SQL language.
To transform the EJB model from section 5.2 to code, we introduced an intermediate model, called the EJB Class PSM. The EJB Class PSM was written in the language defined by another UML variant, the standardized EJB profile (Java Community Process document JSR26, 2001). Because the generation of code from the EJB Class PSM is very simple, we did not describe it.
In order to avoid the complexity that Web code can bring, we have defined a simple transformation from Web model to JSP and HTML code.