Home > Articles > Software Development & Management > UML

This chapter is from the book

Portal Design

The most important functions of a Web portal are to aggregate content from several sources and to personalize the presentation for each user or user role. Our example portal for the catalog exchange service is called MyCat. This portal allows users to personalize their selection from a variety of content sources, including a category browser, product search, current promotional discounts, and so on. Each user can choose which sources to display, where to display them on the screen, and what colors to use for text and background.

A Web page as viewed in a browser is often the result of combining the output from several server-side components. Each component, or portlet, is responsible for producing a part of that page and is dedicated to one of the aggregated content sources. In the simplest architecture, one component might be responsible for the heading and menus, another for the footer, and a third for the main body of the page content. A page, however, can be decomposed into any number of regions, and a component can be assigned to produce the content within each region. A portal server provides a framework for configuring (and reconfiguring) the regions, including their size, relative location, presentation style (often called "skin"), and assignment of a component that will produce each region's content.

This architecture and terminology is used by the open source Apache portal server named Jetspeed.2 The Jetspeed server is used in Chapter 11 to illustrate portal design and especially to describe XML to HTML transformation using XSLT. A sample screen shot of Jetspeed used to present our demonstration MyCat portal is shown in Figure 5-3.

Figure 5-3 MyCat portal screen in CatX application

The Jetspeed portal framework controls the overall screen configuration in this example. Each sub-pane is produced by a separate portlet, and each portlet draws its content from one or more XML documents, which are combined and formatted by an XSLT stylesheet. The requirements for each of these functions is summarized by the following use case descriptions.

Design Portlet

A portlet's design determines the content and appearance of one region within the portal screen. The following design questions must be answered.

  • What is the source of content data (for example, file name, URL, database)?

  • How frequently will the data be refreshed?

  • What is the source data format (for example, XML, HTML, comma-delimited text)?

  • If the source is XML, what vocabulary schema defines its structure?

  • What kind of filtering is required to personalize content for the current user?

  • What content language is required for the current user?

  • How will the data be presented? What is the layout structure, color, font, and style?

  • How much space is required for its presentation?

  • What interactive controls are required (for example, edit, search, submit)?

Let's narrow our focus to one of the portlets shown in the MyCat portal. Figure 5-4 shows the product display portlet that presents the details about one product selected from the catalog. As shown previously, the XML document used to produce this portlet was authored in XMetaL.

A portlet is not required to include the title bar and control buttons as shown in this example; these design decisions were made as part of this use case. This portlet could also be displayed with a plain border or with no border or title at all. These simple configuration choices are available in the Jetspeed portal framework and in most other portal server products.

As you'll see in later chapters, the CatML catalog vocabulary includes links to other product detail resources in addition to the description shown in this portlet. The Edit button should allow users to customize their presentation either to include more detail or exclude the description as desired. The other control button allows users to display this portlet as full screen.

In the prototype application underlying this portal, portlet content is read from a file named Products.xml that contains data structured according to the CatML vocabulary. One of the elements in this XML document contains a URL reference to the product image, so the image file may be co-located on the same server or retrieved directly from the vendor's site. Given this information we need to design the content template for this portlet's presentation and select an approach for transforming the XML data into HTML. These decisions are the result of the next two use cases. You can trace these dependencies in Figure 5-1 where the Design Portlet use case includes Design Content Template.

Figure 5-4 Product display portlet

Design Content Template

A content template determines the structure of data presented in an individual portlet. In the spirit of proper use case specification, I make no assertions about how the content template is implemented; a use case only specifies the goal that must be achieved and a course of action that is followed when an actor invokes the use case. The primary goal in this case is to specify which product data items should be displayed and how those data should be positioned within the portlet. In the example shown in Figure 5-4, the CatML elements for product name, sku, list price, description, photo URL, and supplier are positioned within a simple two-column table structure for presentation.

There are many alternative choices available for implementing a content template, although some of these choices may be restricted or determined by your particular portal framework. Some portal server products are based on JavaServer Pages (JSP) and Enterprise JavaBeans (EJB) for their portlet implementation; others might depend on Active Server Pages (ASP). The Apache Jetspeed portal has a flexible architecture that could include the results of a JSP within the portlet content, or the content may be produced by a completely custom Java class implementation. However, for flexible rapid development, a Jetspeed portlet may use an XSLT stylesheet to both structure its content and to transform the XML data into that that structure. The next use case is optional but may be included to implement the content template and/or specify the XML data mapping.

Create Stylesheet

The stylesheet accepts XML data as input, then filters, reorders, summarizes, and presents the data as required to populate the content template. But the final presentation style applied to that data is partly determined by the user's device that displays this portlet. You could extend the use case diagram shown in Figure 5-1 to include several specializations of the Create Stylesheet use case. Similar to the way that Create Content has two sub-use cases that describe requirements for specialized types of content, you could define additional use cases for Create HTML Stylesheet, Create WML Stylesheet, and so on. Each would address the unique requirements of those presentation formats.

A portlet is not necessarily limited to a single stylesheet. Rather, a portlet is often designed with a set of alternative stylesheets, where each is specialized to a particular client application, such as Microsoft Internet Explorer or Netscape Mozilla, or to a type of device, such as a desktop PC, mobile phone, or PDA. The portal server dynamically selects an appropriate stylesheet for each portlet when a user's browser requests the portal Web page to be displayed.

The UML activity diagram shown in Figure 5-5 illustrates the decisions required to select a stylesheet for a user's device. The first decision uses information provided in the HTTP header to determine the user agent type and version, then the flow branches one of three ways. The HTTP header information also declares which MIME types are accepted by that user agent, thus determining whether a mobile device can accept advanced stylesheets using WML Script. The Wireless Markup Language (WML) has been standardized as part of the Wireless Application Protocol (WAP).3 WML documents are similar to HTML documents, but the markup language is specialized for the requirements of small Web browsers in mobile devices.

Web browsers contained in mobile devices are similar in concept to the familiar desktop browsers, but their capabilities are much more restricted. The most important point to remember from this use case summary is that a common XML document can be transformed into alternative presentation markup languages applicable to each of these device types and capabilities.

Figure 5-5 Activity flow for selecting a stylesheet

XSLT is a powerful transformation and presentation language that can fulfill many of the portal requirements listed in the introduction to this chapter. One XSLT stylesheet may aggregate the data from several XML source documents, where the specific source documents and elements from those documents are selected by the stylesheet rules at the time of presentation. Conversely, a stylesheet may disaggregate a large XML document by filtering its content based on stylesheet parameters. The stylesheet can also create HTML or WML hyperlinks in the presented portlet content based on a variety of advanced linking elements included in the source XML documents. However, the processing overhead of XSLT requires careful attention to caching of results in order to assure a scalable portal server. All of these XSLT features are described in greater detail in Chapters 10 and 11, along with examples of transforming CatML into HTML.

Design Portal Layout

Review Figure 5-1 to reestablish your context for this next use case. Assume that a Web application specialist has designed several portlets that pull their data from a variety of different sources. Each portlet design has made its own choices for structure and presentation of its data; the portal itself is not concerned with these decisions. However, the overall portal framework contributes configuration control and layout algorithms that are applied to the current set of portlets selected for display.

The portal layout may differ radically when viewed from alternative client devices. For example, a mobile phone cannot display all portlets simultaneously positioned within a large screen. Instead, a mobile phone treats each portlet as a card in a stack, and the layout must include navigational controls that enable a user to select the current portlet from a structured menu. In this situation, the portal layout is focused on navigational rather than positional layout within a screen, although both are equally important in their own contexts.

The specific details of how these layout algorithms work and how a designer applies them are not critical to this discussion. Each portal server vendor has made its own unique choices for how this is done, based in part on the underlying software platform used for the portal server implementation. Some additional details of portal layout are provided in Chapter 11 where I describe Jetspeed's Portal Site Markup Language (PSML) applied to the design of our CatX portal implementation. But first we must continue to focus on how such a markup language is designed.

Customize Portal Layout

One of the ubiquitous features of Web portals is the ability for each user to personalize the portal content and presentation style. In most cases, an end-user cannot create substantially different portlets but can pick from a set (maybe a very large set) of predefined portlets designed by the portal Web specialists. Figure 5-1 shows a Consumer interacting with the Customize Portal Layout use case; that use case includes the results of the portal layout design produced by the Web specialist.

The most radical customization allowed by portals is for a user to add or remove portlets from his or her current display. This permits the user to alter substantively the information aggregation provided by his or her personalized view. The second most significant customization is for the portlet designer to include an "Edit" control on the portlet title bar that gives a user control over the content of an individual portlet. The design of such a customization is very specific to each portlet's implementation. A good example of this feature is the stock ticker portlet available on most mass-market Internet portals. In this case, the Edit button allows, at minimum, customization of a user's preferred stock portfolio.

The third type of customization allows a user to control the skin applied either to individual portlets or to the portal as a whole. The term skin is frequently used in consumer-focused Web applications. Its implementation and capabilities vary. In the simplest case, a skin defines the background color, text color, and font applied to the display; in more advanced designs, a skin defines a collective theme of styles, button images, background wallpaper, and so on. Most business-oriented portals support skins that customize fonts and colors.

When the portal is viewed from small devices such as mobile phones, the customization should allow users to control order and hierarchy of navigational menus, in addition to the other customizations described above. The specifics of mobile device Web applications are beyond the scope of this book, but it's interesting to speculate about where they are headed.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020