This chapter gives insight into the three PIM to PSM transformations that are needed to implement the system for Rosa's Breakfast Service.
The transformation rules for generating relational database models typically take care of a consistent object-relational mapping. Although most of these rules are rather straightforward and well-known (Blaha 1998), it can be a hard job to execute them manually. Small changes in the PIM can have a large effect on the relational model. For instance, changing the type of an attribute in the PIM from a simple data type to a class means introducing a foreign key in the corresponding table. The simple data type can be mapped directly to a column in a table. But if the data type is a class, this class will be mapped to a table itself. The column will now have to hold a reference (foreign key) to a key value in that other table.
What rules should be used to generate a relational model? Note that we want to formulate rules that will apply to any UML model, not only to Rosa's PIM. First, we must decide how the basic data types are being mapped. This is a fairly simple task. All we need to do is find the right corresponding data type in the relational model. Data types can be mapped according to the following rules. Note that we define an arbitrary length for each of the relational data types.
But what do we with the Address? In the PIM the address is not a class, but a data type, a struct containing only attributes, and no operations. We have two options: either make a separate table for every data type, or inline the data type into the table that holds the attribute. Here we choose the latter option, because it will simplify the alignment with the EJB model. So for struct data types we have the following rule:
A UML data type that has no operations will be mapped onto a number of columns, each representing a field in the data type.
Second, every class should be transformed into a table, where all attributes are fields in the table (rules ClassToTable and AttrToCol). When the type of the attribute is not a data type but a class, the field in the table should hold a foreign key to the table representing that class (rule AttrToFrkey). Note that we do not yet take into account the possibility that the multiplicity of the attribute is more than one.
The third step is more complicated. Associations in the UML model need to be transformed into a foreign key relation in the database model, possibly introducing a new table. Note that we have several possibilities for the multiplicities of an association from class A to class B in a UML model:
The multiplicity at A is zero-or-one.
The multiplicity at A is one.
or
The multiplicity at A is more than one.
The same holds for the multiplicity at B. This leaves us with nine different combinations of multiplicities at both ends. Furthermore, we have to take into account that an association can be adorned with an association class. The rule can best be expressed in pseudocode:
if the association A to B is adorned by an association class or the multiplicity at both ends is more-than-one then create a table representing the association class or the association and create foreign keys in both the table representing A and the table representing B referring this new table else if the multiplicity at one end is zero-or-one then create a foreign key in the table representing the class at that end, referencing the other end else /* the multiplicity of the association is one-to-one */ create a foreign key in one of the tables, referencing the other end endif endif
Note that in this example we do not take into account the navigability of the association. We assume, for the sake of simplicity, that all associations are navigable.
Each column in a relational model may or may not have the NULL value. In this transformation, only the columns generated from the attributes of the PIM may have the value NULL. The other columns are generated based on the association ends to constitute the foreign keys. These columns may not have the value NULL. The following rules correspond with the above:
A UML attribute will be mapped to a column that may contain the NULL value.
A UML association end will be mapped to a number of columns that may not contain the NULL value.
Figure 5-1 depicts the resulting database model in the form of an Entity-Relationship diagram. You can see that there is one table for each class in the PIM. Columns that are part of the key are repeated as foreign key columns in tables representing the “many” side of the association. The struct called address is inlined into the Customer and BreakfastOrder tables, and for each field there is one column in the table. The fact that a column may have the NULL value is not shown in the diagram, but assumed to be part of the generated relational model.
To complete the system for Rosa's Breakfast Service we need to generate an EJB PSM. We will make a number of architectural choices in the way that we use the EJB framework. These choices are specific for Rosa's Breakfast Service. Depending on the project requirements and the possibilities offered by the available tools, you will need to make your own choices in your own situation. We start out by explaining some aspects of the choices we have made regarding the EJB PSM.
The EJB model for Rosa's Breakfast Service is structured in a rather different manner than the PIM. We could have built a component model for Rosa's Breakfast Service by simply generating a component for each class. However, it is crucial for the performance of EJB components in a distributed environment with remote access that the communication between components remains minimal.
The attributes of an object could be exchanged one by one, where each get- or set-operation on an attribute value causes a remote method invocation. This is a straightforward, but rather naive approach. To minimize the frequency of interaction between components, wherever possible, it is better to exchange all attributes of an object in one remote call. This results in messages that are more complex, and include a relatively high amount of data, and in component interfaces that have a relatively low number of operations, relieving the burden on the communication network.
Furthermore, it is better to keep the number of components relatively small, because intercomponent communication will not burden the network, whereas intracomponent communication will. To minimize the number of components, we can combine closely related classes into one component, instead of having a component for each of them separately. We call a component model that adheres to these principles a coarse grained component model.
A coarse grained component model is a model of components where the components are large and have infrequent interaction with a relatively high amount of data in each interaction.
In contrast to the coarse grained component model there is the fine grained component model.
A fine grained component model is a model of components where the components are small and have frequent communication with a low amount of data in each interaction.
For Rosa's Breakfast Service we have chosen to use a coarse grained EJB component model. There are a number of books where you can find out more about component models (for example, Cheeseman 2001, Szyperski 1998, and Allen 1998). This book does not address that subject.
The interfaces of the coarse grained components have methods to exchange complete sets of associated objects, and they do not have methods for accessing the individual attributes and associations between these objects. Therefore, a number of classes in the source model must be clustered into so-called EJB data schemas.
An EJB data schema is a set of classes, attributes, and associations that is served by an EJB component as a whole.
An EJB data class is a class that is part of an EJB data schema.
To find out which EJB data classes should be part of a data schema, we use the composite aggregation property of the associations in the PIM. Every class that is part of a whole is clustered into the data schema that is generated from the whole. For example, the class Breakfast is defined to be part of the class BreakfastOrder, therefore Breakfast will be clustered in the data schema for BreakfastOrder and there will be no separate data schema or component for Breakfast.
Likewise, association classes are clustered in the data schema that is generated from the associated class that is able to navigate to the other associated class. For example, the class Change would be clustered into the data schema for Breakfast, but because the class Breakfast itself is clustered into the data schema for BreakfastOrder, the class Change becomes part of the data schema for BreakfastOrder as well.
A client of the EJB component can access the details of these clustered classes by getting a so-called EJB data object.
An EJB data object is an instance of an EJB data class.
Each data class has its own local get- and set-operations for its attributes and associations to other data classes. When the client of the EJB component has finished, all changes that need to be made on the data objects are sent back to the EJB component with the request to process all changes.
Besides data classes that are holding the state of the exchanged objects, we need so-called key classes.
If a data class has an association to a class that does not reside in the same data schema, it will refer to a key class instead of a data class. In this manner, the amount of exchanged data in one data object is limited to the instances of the classes within one data schema.
Now that we have established that we are going to generate a coarse grained EJB model, we are able to define the rules for the transformation from the PIM to the EJB PSM. Figure 5-2 shows the four EJB components that result from this transformation.
As explained in the previous section, the granularity of the EJB components is based on the composition of the classes in the domain model. In the transformation rules, we will use the term outermost composition of x to refer to the class that is not a part (via a composite association) of another class and is equal to or the (direct or indirect) container of the class x. To make the following transformation rules readable, we will leave out the words UML and EJB whenever the source and target model are clear.
For each PIM class, an EJB key class is generated.
Each PIM class that is not a composite part of another PIM class is transformed into an EJB component and an EJB data schema.
Each PIM class is transformed into an EJB data class residing in an EJB data schema that is generated from the PIM class that is the outermost composition of the transformed PIM class.
Each PIM association is transformed into an EJB association within an EJB data schema that is generated from the PIM class that is the outer-most composition of the transformed PIM association.
Each PIM association class is transformed into two EJB associations and an EJB data class. The EJB associations and the EJB data class are generated within the EJB data schema that is generated from the PIM class that is the outer-most composition of the PIM class that can navigate across the transformed PIM association class.
Each PIM attribute of a class is transformed into an EJB attribute of the mapped EJB data class.
Each PIM operation is transformed into an EJB operation of the generated EJB component that is generated from the PIM class that is the outer-most composition of the PIM class that owns the transformed PIM operation.
Figure 5-3 depicts the EJB data schemas of the Comestible and StandardBreakfast components. As indicated by the composition relations between the classes in the PIM, the Comestible data schema includes only the Comestible EJB data class, while the StandardBreakfast data schema includes the EJB data classes StandardBreakfast and Part.
The Web model specifies the definitions of the Web components. The Web components serve HTML content to the user. Each component serves a subset of the classes and associations of the system. Extra details are added to the Web model to define the layout and the user interactions of the HTML pages. In this example, the Web components serve the same classes as in the data schemas of the entity beans.
Web components are defined similarly to EJB components. The served classes and associations are defined in Web data schemas similar to the EJB data schemas. The most important differences are:
The data types in the Web model define user presentation and interaction details.
In the Web application model there are no key classes; instead, the key classes of the EJB model are referenced.
Web actions are added that define actions that can be triggered by the end-user.
The Web data schemas define which information is shown that can be altered by the user. One Web data schema is typically presented to the user in more than one HTML page. A user may create, query, alter, and delete objects from the domain. Which changes the user may execute is defined in properties of the elements of the Web data schemas.
The rules for generating the Web application model from the UML model are almost equal to the ones for generating the EJB application model. Again, we will leave out the words UML and Web whenever the source and target model are clear.
Each class that is not part of another class is transformed into a component and a data schema. The component is set to serve the data schema.
Each class is transformed into a data class residing in a data schema that is generated from the class that is the outer-most composition of the transformed class.
Each association is transformed into an association within a data schema that is generated from the class that is the outer-most composition of the transformed association.
Each association class is transformed into two associations and a data class. The associations and the data class are generated within the data schema that is generated from the class that is the outer-most composition of the class that can navigate across the transformed association class.
Each attribute of a class is transformed into an attribute of the mapped data class.
Each operation is transformed into an operation of the generated Web component that is generated from the class that is the outer-most composition of the class that owns the transformed operation.
Figure 5-4 depicts the Web model generated from the same PIM classes as the EJB model shown in Figure 5-3.
The MDA process has not been completely described if we do not reference the generation of the communication bridges between the relational model and the EJB model and between the Web model and the EJB model.
In Figure 4-1 on page 46, the communication bridges are shown by arrows. This means that there is a direction in the relation between the two models. The Web model uses (and knows) the EJB model, and the EJB model uses (and knows) the relational model.
Both bridges are simple and have been explained. The data storage for the EJB components is provided by a relational database, structured according to the generated relational model in Figure 5-1. The EJB-Relational bridge is constituted by the relation between the table generated for a UML class and the EJB data class that is generated from the same UML class. The relationship between the generated relational model and the generated EJB component is shown in Figure 5-5. The figure depicts the EJB component model for Rosa's Breakfast Service without showing the EJB data schemas, but with all dependencies on the tables of the relational model of Figure 5-1.
The bridge between the Web model and the EJB model is constituted by the links to the EJB key classes and EJB components as shown in Figure 5-4. Note that both communication bridges are relationships between the PSMs. This relationship will need to be preserved when the PSMs are transformed into code.
As pointed out earlier, the MDA especially pays off when the transformation process is not trivial, or when the transformation is well-known but involves much work. In the example given in this chapter, both situations are present. The UML-Relational mapping is worthwhile because it speeds up the process. The UML-EJB mapping is clearly a non-trivial mapping, where the transformation rules supply much knowledge of the platform.
In general, we can say that when the structures of the source and target language differ greatly, the transformation becomes more complex. Small changes in the source model may have a huge impact on the structure of the target models and thus on the implementation code.
The process of implementing a PIM is greatly improved by the application of MDA in terms of quality, because we are forced to specify transformation definitions that are generally applicable.