Mapping Web Elements to UML, and Vice Versa

2017-11-03 09:05:03

The core WAE profile is not vendor specific and can be applied to any scripted page-based Web application development such as JavaServer Pages, Active Server Pages, PHP: Hypertext Preprocessor, Cold Fusion Markup, and others. At the time of this writing, Microsoft's newest version of Active Server Pages (ASPX) has just been released and therefore a complete profile for this environment is not ready. Presently no concrete work has been made available for the other environments except for JavaServer Pages (JSP). JSP 1.1 has been available for some time, and a WAE-based profile is available and described in this and the following sections. The UML profile JSP is described, as the base WAE profile, from two viewpoints: mapping Web elements to UML, and the reverse, UML to Web elements.

JavaServer Page to UML

This section of the JSP profile describes the mapping of JSP-specific technology elements to UML elements. The JSP elements range from the XML-formatted Web application and tag library descriptors to JSP files. There is no 1:1 mapping of elements in either space, so careful attention must be paid when describing and understanding the transformation of the model.

Web Application

A Web application is a collection of servlets or JSPs that make up an application that delivers user functionality to client HTML browsers. In J2EE terms, an application is defined by the web.xml file. This configuration file contains a number of application definitions, including the servlet mapping, which is how the Web container resolves URLs into servlets or JSPs. This mapping is a key part of the «virtual root» and «physical root» component packages.

The following web.xml fragment specifies a servlet named "searchServlet" and also specifies a mapping to a URL. This is modeled with an «HTTP Resource» component directly under the «virtual root» package that represents the application's host and context. The resulting URL is relative to the host and application context, which are specified as tag values in the «virtual root» package that owns this HTTP resource. So if the name of the Web application were glossary and the host were localhost, the URL pointing to this servlet would be http://localhost/glossary/search.

search searchServlet app.glossary.Search ... search search

Figure A-39 shows how this fragment would be modeled in the component view of the model. The «virtual root» has tag values specifying the host name { hostname = "localhost" } and the application context { context = "glossary" }.

Figure A-39. Modeling a servlet mapping

JSPs that are not explicitly mapped in the web.xml file are structured under the «physical root» package in the component view of the model. The «physical root» maps to the root of the Web archive file. All JSPs that can be requested are located in a package hierarchy under the physical root that mirrors the file system. See Figure A-40.

Figure A-40. Modeling JSPs in a «physical root» component package

JSP

A JSP file is modeled with a «JSP» stereotyped component or, optionally, a «dynamic page» component with a type tag value that indicates JSP. The contents of the JSP file are modeled in the logical view with «server page» stereotyped classes.

Operations and attributes defined in a <%! … %> block are mapped to «server page» static attributes and operations. Attributes defined in scriptlet blocks (<% … %>) are, optionally, mapped to «server page» attributes.

The following code fragment defines three operations and one static member variable. Four additional instance variables are defined. In this example, some of the page's code is executed in line, including the code that defines and assigns the instance variables for the page's scriptlets. The model for this code fragment is shown in Figure A-41.

<%! private int timesAccessed = 0; private void writeTable(SearchListing listing){ ... } private void writeRow( Item item ){ ... } private int getIndex( HttpRequest req ) { ... } private SearchListing search( SearchCriteria criteria, int startingIndex ){ ... } %> <% // member variable definitions int index = 0; int totalPages = 0; SearchListing listing = null; // beginning of main page logic timesAccessed++; SearchCriteria criteria = (SearchCriteria) session.getAttribute("criteria"); if( criteria != null ) { index = getIndex( request ); if( index > 0 ) { listing = search( criteria, index ); } } %>

Library Listing

...

Figure A-41. Sample «server page» class

<%jsp:usebean … %>

This tag maps directly to a «use bean» stereotyped association from a «server page» class to a JavaBean. The following use bean declaration is modeled in Figure A-41.

<%jsp:include … %>

The JSP include element is modeled with a simple «include» relationship from a «server page» to another page class. This is modeled the same way as the JSP include directive. Because there are architectural differences in these two types of include, the tag value "type" is set to "{ tag | directive }" to indicate which type of include is required.

<%jsp:forward … %>

The JSP forward element is modeled with a simple «forward» relationship to the page class that will take over control of the page request.

<%jsp:plugin … %>

The JSP plug-in element is modeled with an tag from the client page that is built from the server page.

<%@include file="…"%>

The include directive is modeled with a simple «include» relationship from a «server page» class to the page class that is to be included. This is modeled the same way as the JSP include element. Because there are architectural differences in these two types of include, the tag value "type" is set to "{ tag | directive }" to indicate which type of include is required.

<%@taglib … %>

A tag library itself is modeled with a «JSP tag library» stereotyped package. This package corresponds to a tag library descriptor file (.tld). The package contains a number of «JSP Tag» stereotyped classes, each representing one tag definition. Each tag has a dependency on a Java implementation class. This dependency is stereotyped «tag». An optional Tag Extra Info class may also be specified to define scripting variables that are available in the body of the tag. The Tag Extra Info class is identified by a «tei» dependency from the «JSP Tag» class to the class providing the extra information.

The following code is a tag definition in a descriptor file.

Entry app.glossary.taglib.EntryTag app.glossary.taglib.EntryTEI JSP entryid true true convertLineBreaks false true

The body of the Tag Extra Info class follows.

public class EntryTEI extends TagExtraInfo { public EntryTEI() { super(); } public VariableInfo[] getVariableInfo(TagData data) { return new VariableInfo[] { new VariableInfo("id", "String", true, VariableInfo.NESTED), new VariableInfo("term", "String", true, VariableInfo.NESTED), new VariableInfo("acronym", "String", true, VariableInfo.NESTED), new VariableInfo("longTerm", "String", true, VariableInfo.NESTED), new VariableInfo("description", "String", true, VariableInfo.NESTED), new VariableInfo("includesHTML", "String", true, VariableInfo.NESTED), new VariableInfo("lastmodified", "String", true, VariableInfo.NESTED) }; } }

The descriptor file specifies the tag attributes that it expects in the opening tag with «attribute» stereotyped attributes. Scripting variables available in the body of the tag are specified in the TagExtraInfo class. The tag described here is modeled in Figure A-42.

Figure A-42. Model of a JSP custom tag

A tag library is referenced by a server page with the taglib directive.

<%@ taglib uri="/glytlb" prefix="gly" %>

In the model, it is drawn as «JSP Tag library» stereotyped relationship to the library package (Figure A-43). [7] The relationship is named gly, which is how the tags from this particular library are referenced in the JSP code.

[7] In this diagram, a dependency is a limitation of the modeling tool I am using. A more proper relationship would be an association.

Figure A-43. Modeling server page use of tag libraries

response.sendRedirect( … ) Method

The method sendRedirect( … ) is an architecturally significant call that can be made by server pages. When this behavior is a structural part of the designis the normal flow of behaviorit can appear in the model as a «redirect» relationship from one server page class to another page class.

UML to JavaServer Page

This section of the JSP profile describes the mapping of UML elements into JSP-specific technology elements and components. All of the UML elements are stereotyped, and the range includes classes, packages, associations, attributes, and operations.

«JSP» Component

Each «JSP» component creates a single JSP file (.jsp) located in a subdirectory under the Web application root. The «physical root» package maps to the top-level directory in the Web archive file (.war). Each subpackage of the physical root is mirrored with a subdirectory in the Web archive folder. The following physical file, where some Web root is located in the root of the Web context, results in the component mapping shown in Figure A-44.

Figure A-44. Component mapping for JSP file

/(some web root)/tutorials/fractions/certificate.jsp

«server page» Stereotyped Class

A «server page» stereotyped class is the logical abstraction of a JSP as it is executed on the server. The class's instance attributes correspond to instance variables used in the main body of the JSP code and that have pagewide scope.[8] Figure A-45 shows a class diagram with a server page defined. This class maintains two instance variables: to a Product and to a ShopController. The role names on these relationships are used as the variable names in the main body of JSP code.

[8] Not declared inside a function declaration or a statement block { }.

Figure A-45. Server page with object relations and a link

This class diagram also defines a hyperlink from the client page class that it builds. This link is to a UX screen and as such requires a little bit of navigation and deeper understanding of the architecture to resolve. The architecture in this case maps the product.scr «HttpResource» component to the appropriate set of JSP pages.

<%@ page import="com.numberstore.catalog.*" %> <% ShopController controller = (ShopController) session.getAttribute("controller"); Product special = controller.getProductSpecial(); int specialCategoryId = special.getCategoryId(); int specialProductId = special.getId(); String specialName = special.getName(); String specialDescription = special.getDescription(); String specialPrice = special.priceString(); String specialUrl = response.encodeURL("product.scr?cat&prod<%=specialUrl %>"> <%= specialName %>

<%= specialDescription %>

...

The class diagram of Figure A-46 shows a server page with three defined operations and one static attribute, all coded in a JSP <%! … %> block. The two instance variables are scriptlet variables used in the page and with page scope (see the following code).

Library Listing...

Figure A-46. Server page with operation definitions

«use bean» Association

The «use bean» association between a JSP and a Java class in the model is coded with a simple JSP use bean tag.

«include» Association

An «include» association from a server page class can be coded as either a JSP directive (<%@ include file="…" %>) or a JSP tag (). The version of the include is dictated by the type tag value (type = { tag | directive }).

«forward» Association

A «forward» association is coded with the tag.

«redirect» Association

A «redirect» association is implemented by the sendRedirect(String location) operation on the HttpResponse object, which is available in the context of a JSP by the response variable.

«JSP Tag» Class

A «JSP Tag» in the model corresponds to a JSP custom tag (Figure A-47). The class defines a number of tag attributes and scripting variables. Attributes of the «JSP Tag» that are stereotyped are element attributes that can be specified in the opening tag. These attributes are captured in the tag library descriptor file with the following XML fragment:

Entry app.glossary.taglib.EntryTag app.glossary.taglib.EntryTEI JSP

Figure A-47. Sample «JSP Tag» class

entryid true true convertLineBreaks false true

Tag values on the attributes indicate whether the attribute is required (required = { yes | no }).

Scripting variable stereotyped attributes must be defined in a TagExtraInfo class, which is identified by a «tei» stereotyped dependency from the «JSP Tag». The TagExtraInfo class for the example in Figure A-47 follows.

The «JSP Tag» implementing class is identified with a «tag» dependency. Its implementation must include certain operations (see the JSP specification for details). The class in this example follows, with operation bodies removed for clarity. Each specified attribute must provide a get and a set operation.

Public class EntryTag extends BodyTagSupport { public String getConvertLineBreaks(){ } public void setConvertLineBreaks(String _convertLineBreaks ){} public String getEntryid() {} public void setEntryid(String _id ){} public void doInitBody() throws JspException {} public int doStartTag() throws JspException {} public int doEndTag() throws JspTagException {} public void release() {} }

«JSP Tag Library» Package

A JSP tag library (Figure A-48) maps to a .tld descriptor file. This file uses the «attribute» stereotyped attributes and the two dependency relationships to the implementing classes («tag» and «tei») to define most of the fields in this descriptor file.

1.0 1.1 Entry app.glossary.taglib.EntryTag app.glossary.taglib.EntryTEI JSP entryid true true convertLineBreaks false true

Figure A-48. Tag library package

Категории