The rapid evolution of the area of Web Engineering has motivated the proposal of several methods and frameworks for the development of Web Information Systems (WISs). In particular, it is becoming more and more common to use containerbased architectures and frameworks when it comes to their development. Following this idea, we have proposed a method for designing frameworkbased WISs, called FrameWeb. and, in this paper, we present FrameWeb's UML profile for modeling framework components in design models.
Web Engineering (WebE) can be defined as “the establishment and use of engineering
principles and disciplined approaches to the development, deployment and
maintenance of Webbased Applications” [
Also, new technologies for coding WISs have rapidly evolved. Frameworks for the
solution of infrastructure issues were developed and entire architectures providing
containers for user components became standards. For example, the most recent
version of Java EE [
This scenario motivated the proposition of FrameWeb [
The objective of this paper is to present FrameWeb's modeling profile. It is organized as follows: section 2 talks about the area of Web Engineering and what has motivated the authors for the creation of this UML profile. This section also summarizes the key points of FrameWeb's design method. Section 3 details FrameWeb's modeling profile, which is the focus of this paper; section 4 compares FrameWeb's profile to others; finally, section 5 concludes and lists future work. Web sites evolved from static pages to complex information systems. In this process, many frameworks (artifacts of code that provide components ready for reuse by inheritance, composition or configuration) were created to help Web developers speed up the development of Web applications.
These frameworks substantially change the kind of components that are built during coding. Classes that inherit from other classes in the framework, configuration files and others are now source code artifacts that must be written by developers. In particular, three kinds of frameworks have the most impact on this change: Front Controller, Object/Relational Mapping and Dependency Injection frameworks.
Front Controller [
Object/Relational Mapping (ORM) frameworks provide automatic and transparent
persistence of objects to tables of a Relational Database, using metadata that describe
the mapping between both worlds [
Dependency Injection (DI) frameworks allow the developer to program to interfaces [9, 7] and specify the concrete dependencies in a configuration file. The idea is that classes that depend on services from different tiers would declare an association with an interface instead of the concrete implementation. This facilitates, for instance, the replacement of the real service class with a mock object for unit testing. When an object is created, the DI framework wires all required dependencies automatically, based on a configuration file. In FrameWeb, the dependency relations between different tiers are represented in the Application Model (section 3.4).
A detailed description of these and other kinds of frameworks can be found at [
Our personal experience with the use of frameworks for the construction of WISs
has motivated the proposal of the FrameworkBased Design Method for Web
Engineering (FrameWeb) [
FrameWeb's standard architecture separates different frameworks concerns into three layers. At the Presentation layer (View and Controller packages), UI components and action classes integrate with the Front Controller framework, calling services from a Business layer, which contains service classes (Application package) and domain classes (Domain package). The latter, in turn, are mapped by the ORM framework and persisted by classes that belong to the Data Access layer (Persistence package). Class dependencies that cross a layer's boundaries are taken care of by the DI framework.
For a detailed description of the method, the interested reader should refer to [
Throughout the next subsections we detail these four models using as examples diagrams produced for a collaborative learning environment called JSchool1, developed by the local Java User Group2 using FrameWeb. JSchool contains a core subsystem, which is responsible for user registration, login, system configuration and allowing users to send messages to the administrators and view other users' profiles. JSchool also includes a group module, which contains features for creating, managing, searching, joining and participating in groups.
Figure 1 shows the conceptual model for the core and group modules. Collaborators are registered with name, email, password, institution, contact information and picture. Groups have names, descriptions, keywords and configurations such as if the group is open or public. Other classes complement these two, representing invitations to participate in a group, confirmation of a user's email address, a user membership and role in a group and requests from a user to create a group or participate in a group. 1 http://jschool.dev.java.net 2 Espírito Santo Java User Group (ESJUG) – http://esjug.dev.java.net The Domain Model is a UML class diagram that represents classes of objects from the problem domain and their Object/Relational (OR) mappings. This diagram should be used by developers to guide the codification of classes from the Domain package.
Designers should use the conceptual model built during Requirement Analysis and add platformspecific details and the OR mappings. Platformspecific details include attribute types, association navigabilities, etc. The OR mappings will guide the developers on how to configure the ORM framework to persist these entities.
Although this configuration is more related to persistence, it is represented in the Domain Model because the classes that should be mapped and their attributes are represented in this diagram.
Table 1 describes some possible OR mappings for the Domain Model. For each mapping, the table presents which lightweight extension mechanism was used and what are the possible values or syntax for its use. None of the mappings are mandatory and most of them have sensible defaults in order to lessen the amount of information on the model. These default values are shown in the possible values column in boldface or in parenthesis.
The Domain Model for the core and group modules of JSchool is shown in figure 2. According to the default values, all classes are persistent and class and attribute names are used as table and column names respectively. None of the classes have ID or version attributes because they are inherited from a utility package.
Attributes have received mappings such as nullability and size. Date attributes such as invitationDate, entryDate and requestDate were mapped as dateonly precision, while the remaining dates will be stored as timestamps. All three collections (navigable association endings with multiplicity “many”) were configured to be sorted naturally (will be implemented in the programming language, Java), to be fetched lazily (only when used for the first time) and to cascade all operations (e.g. if a group is deleted, all of its subgroups are automatically deleted).
Extension
Possible Values If the class is persistent, transient or mapped (not persistent itself, but its properties are persistent if another class inherits them) Name of the column in which an attribute will be persisted Size of the column in which an attribute will be persisted Inheritance mapping strategy: one table for each class using UNION, one table for each class using JOIN or single table for the entire hierarchy
Class stereotype
Class
constraint
Attribute
stereotype
Attribute
constraint
Attribute
constraint
Attribute
stereotype
Attribute
constraint
Attribute
constraint
Attribute
constraint
Inheritance
stereotype
<<persistent>>
<<transient>>
<<mapped>>
table=name
(default: class' name)
<<persistent>>
<<transient>>
Order of an association's collection: natural ordering
(implemented in code) or order by columns
(ascending or descending)
FrameWeb indicates the use of the Data Access Object (DAO) pattern [
For each domain class that needs to be persisted, the Persistence Model should present one DAO interface and one or more DAO classes, meaning that different persistence technologies can be implemented in the same system. Base DAO interface and implementation can be presented to reduce the amount of diagram elements in the Model: all DAO interfaces/classes automatically extend the base DAO interface/class, without the need to explicitly show it. Implementing common methods such as save(), delete() and retrieveById() in the base DAO can reduce the amount of modeling that has to be done.
Besides those basic methods, DAOs should also have methods to retrieve objects using specific queries. Also, it is assumed that the interface declares all methods presented by the DAO class to relief the designer of repeating them on the diagram. Thus, basically the Persistence Model represents the “query methods” and does not require any UML extension for such a task. For instance, to authenticate a collaborator's password we need to retrieve the collaborator object given his/her email. Therefore, the method retrieveByEmail(email: String) : Collaborator is modeled for the CollaboratorDAO implementation.
The Navigation Model is a UML class diagram that represents the different components that form the Presentation Logic tier, such as Web pages, HTML forms and action classes. Table 2 shows the stereotypes used by the different components that can be represented in a Navigation Model. This model is used by developers to guide the codification of classes from the View and Controller packages.
Dependency associations among these components dictate the control flow when an action is executed. When directed toward an action class, it means that data is coming from pages or forms and are being set at the action class. Analogously, when directed outward an action class, it means that data from that class is being displayed in some page or template. Homonymous attributes in pages, forms and action classes indicate the information being exchanged.
The designer is free to chose the granularity of the action class: one for each use case scenario, one for each use case, and so on. Since an action class can implement many actions with different methods and each of them can produce different outcomes, constraints at the dependency associations indicate which method/result is being modeled, when needed.
Figure 3 shows the Navigation Model for the “Send Message to Administrators” use case. The web::index page and web::home template represent the pages to which visitors and registered users, respectively, have access. These pages can request the action's input (a form to be filled and submitted), which results in the displaying of the sendMessageAdministration template. This template contains an input form that sends the name, email and body of message to the action that, after executed, displays the messageSent template, if successful. When a registered user requests the input form, the action retrieves its name and email and automatically fills those input fields. That is why the template has name and email as attributes.
At the time FrameWeb was being conceived, a question arose as to whether UML's sequence diagram would be better suited for the Navigation Model than the class diagram. The issue was discussed with the first group of developers which used FrameWeb in its early stages to build a WIS. Two main reasons contributed to the choice of the class diagram: (a) it provides a better visualization of the inner structure of action classes, forms and templates; and (b) it models page – form composition with a more appropriate notation (UML's composition association). In spite of this, FrameWeb does not suggest sequence diagrams should be avoided, but simply recognizes that class diagrams are better suited for the Navigation Model. Fig. 3. Navigation Model for the use case “Send Message to Administrators” (JSchool core)
The Application Model is a UML class diagram that represents service classes, which are responsible for the implementation of use cases. This diagram is used for guiding the codification of classes from the Application package and the configuration of the dependencies between Controller, Application and Persistence packages.
As with action classes, the designer should chose the granularity of the service classes and display, for each of them, one interface and one implementation. The Application Model displays, then, all action classes and their dependencies with the service interface, the methods of the service class that implement the use case scenarios and DAO interfaces and the dependencies that service classes have on them.
Figure 4 shows part of the Application Model of JSchool's core module, showing the service class for the “Configure System” use case and its dependencies. The action class (tagged with the controller:: namespace) depends on the service class for the execution of the use case. The service class, in turn, depends on the DAO classes for Collaborator and Group, as it needs to access data of both classes. Fig. 4. Part of an Application Model of the core module of JSchool. There are several Web Engineering methods that define modeling languages and profiles for Webspecific purposes.
Conallen [
OOWS (Object Oriented Web Solution) [
The UMLbased Web Engineering (UWE) [
FrameWeb uses only lightweight extension mechanisms, being easily supported by most CASE tools that support UML.
Other proposals, such as WebML [
Given all of the options available, FrameWeb comes in as a good choice when it comes to architectures that are based on the use of frameworks. In this case, which is very common for the development of WISs, FrameWeb's profile provides models that are directed towards the frameworks' architectures, allowing for quick understanding of the implementation. During two software projects developed to informally experiment the method and its modeling profile, developer feedback indicated that FrameWeb is easy to learn and use, noting some difficulty only on Navigation Models. This paper presented a detailed view of the UML profile proposed by FrameWeb, a design method suited for the development of frameworkbased Web Information Systems. The profile aims at depicting frameworkrelated components, easing the transition from design models to coding. Using lightweight extensions of UML makes the language more familiar to UML developers.
Future work has already started on the experimentation of the method with many different frameworks, to verify if different framework implementations also fit in the categories summarized in section 2. Other opportunities lie in developing a CASE tool to produce FrameWeb's design models and developing automatic code generation tools (feature that is present in other approaches, such as OOWS and UWE).
Although two software projects have already been conducted to informally evaluate
the method [
Acknowledgments. This work was accomplished with the financial support of CAPES, an entity of the Brazilian Government reverted to scientific and technological development.