Copyright @2005-2007 IBM. All Rights Reserved.
This transformation plug-in demonstrates the ability to generate a
runnable Web application from a UML model using IBM®
Rational® Software Architect (RSA) V7. The transformation
implements a limited subset of features commonly found in Web
applications. It is
not intended to generate fully operational applications but it is
intended to illustrate a Model-Driven Development approach:
business logic is captured in UML models and implementation technologies
are encapsulated in the transformation itself. This means in particular
that you can adopt new implementation technologies without having to
modify the business logic.
This version of the plug-in uses JSF for the presentation layer and Hibernate for the
persistence layer. Changes since the 1.3.0 version are:
Overview
Limitations
Running the Transformation
Using the WebModeling Profile
Using the DataModeling Profile
The
UX-To-Web Transformation is a prototype whose goal is to demonstrate the
MDD/MDA features of RSA to build a transformation that generates a
running Web application from a UML model to which appropriate profiles
have been applied. The application consists of a RSA Dynamic Web Project and the matching Enterprise Application Project. The integrality of the two projects is generated from the plug-in. JSF is used
for the presentation layer, Hibernate for the persistence layer.
The transformation generates the executable application from a
User-Experience (UX) model, i.e. a model that describes the screens of
the target application and the navigation between these screens. A
WebModeling profile was developed accordingly. A DataModeling profile was
developed for the persistence aspect.
Here is a typical scenario:
The following is a summary of the major capabilities covered by the
UX-To-Web Transformation:
This tranformation is not intended to generate fully operational
applications. See limitations.
The following stereotypes are provided. All
stereotype attributes have default values.
:
Stereotype | UML Element | Description |
<<screen>> | Class | Describes a screen. A screen is
transformed into a JSP. Relationships:
Attributes:
|
<<input>> | Class | Describes an input form. An input form
is intended for use with a <<screen>>
class and should contain one or more inputtext
fields. Relationships:
Attributes:
|
<<list>> | Class | Describes a list of items. A list is
intended for use with a <<screen>>
class and should contain one or more display
fields. ![]() Relationships:
Attributes:
|
<<display>> | Attribute | Describes a display field. Used in a
<<screen>> or in a <<list>> class. The
attribute type is ignored. A display field must have a match with an
attribute in a <<bean>> class. Relationships:
Attributes:
|
<<options>> | Attribute | Provides additional information about
the targeted element. Currently the only availabe "option"
is sortable. Attributes:
|
<<useraction>> | Operation | Describes a user action, rendered as
button or link (see attribute kind).Used in a
<<screen>> class. A user action must have a match with an
operation in a <<bean>> class (if not an error is
generated). The transformation will provide some default processing
based on the name of the action:
Relationships:
Attributes:
|
<<link>> | Attribute Operation |
When used with an attribute,
equivalent to a link-kind user action.
Typical use: with a <<display>> field in a
<<list>> as in the following example: ![]() Use with an operation to create an HTML link. A link must have an associated target <<screen>> class (error generated otherwise). Relationships:
Attributes:
|
<<inputtext>> <<listbox>> <<radiobutton>> |
Attribute | Describes an input field. Should only
appear in an <<input>> class. Should have a matching
attribute in a <<bean>> class. Currently the
implementation of <<listbox>> is not complete. Values for
<<radiobutton>> fields can be sepcified as enumerations
in the UML model as shown below:![]() Relationships:
Attributes for <<inputtext>>:
Attributes for <<listbox>>:
Attributes for <<radiobutton>>:
|
<<bean>> | Class | Describes a bean. Typically contain
attributes and operations referenced by <<screen>>,
<<input>> and <<list>> elements. See example
above. Derived attributes: a bean may contain derived attributes. For instance <<bean>> User contains a firstname and a lastname attribute. These attributes may map to database entries as this is the case in the provided sample model CDShop. But you might want to display the full name of the user. In order to do this, you simply add a fullname attribute and select the Derived qualifier in the General tab of the Properties view of this attribute. You can specify in the Documentation field of the attribute the actual code, for instance: 'return getFirstname() + " " + getLastname();'. The transformation will automatically generate the correct getter. Attributes
|
<<settings>> | Class | Defines global settings. Attributes:
|
The following stereotypes are provided.
:
Stereotype | UML Element | Description |
<<database>> | Component | Describes a database. Used to provide
connection parameters for database access. Relationships:
Attributes:
![]() |
<<table>> | Class | Describes a database table. Used to
perform the mapping between a <<bean>> class and a
database table. The existence of the mapping will cause the
transformation to automatically generate the access code. To create
the mapping in UML, display the structure compartment (see below),
populate this compartment with the class attributes (drag and drop
from the Attribute compartment) and draw dependencies to the table
"columns".![]() Relationships:
Attributes: None |
<<pk>> | Attribute | Defines a primary key. Currently only
single attributes can be used to form a primary key. Attributes:
|