PTSM: A PORTLET SELECTION MODEL

Mª Ángeles Moraga, Coral Calero and Mario Piattini

Alarcos Research Group. UCLM-SOLUZIONA Research and Development Institute

University of Castilla-La Mancha, Paseo de la Universidad,4 Ciudad Real, Spain

Oscar Díaz

ONEKIN Research Group, University of the Basque Country, San Sebastián, Spain

Keywords: Portlet selection model, portlet quality model, non-functional characteristics, portals, portlets.

Abstract: The use of Web portals continues to rise, showing their importance in the current information society. The

success of a portal depends on customers using and returning to it. Nowadays, it is very easy for users to

change from one portal to another, so improving/assessing portal quality is a must. Hence, appropriate

quality model should be available to measure and drive portal development. Specifically, this work focuses

on portlet-based portals. Portlets are web components, and they can be thought as COTS but in a Web

setting. This paper presents a portlet selection model that guides the portal developer in choosing the best

portlet, among a set of portlets with similar functions for specified tasks and user objectives, in accordance

to five quality measures, namely, functionality, reliability, usability, efficiency and reusability, and other

three characteristics not related to the quality but important to carry out the selection.

1 INTRODUCTION

A portal provides a solution for aggregating content

and application from various systems for

presentation to the end user. Users do not need to

know how the content or functionality is provided

(Linwood and Minter, 2004).

Due to this complexity, vendors of portal

frameworks strive to bring component-based

development to the Web: the portlets. Portlets are

used by portals as pluggable user interface

components (Java Community Process, 2003). In

such a way, a portlet can be seen as a mixture of

software components and web applications.

So far however, portlets could not be reused by

different portals since they did not use the same API;

and the lack of a common model prevents portlet

interoperability. However, the delivery of the Web

Services for Remote Portlets (WSRP) specification

overcomes this problem, and opens the possibility of

a COST-like market for portlets (OASIS, 2005).

This raises the need for quality models that guide

the user to ascertain the appropriate portlet.

Therefore, if we want a “good” portal (with a good

level of quality), we must select the most

appropriated portlets for constructing it. In spite of

the existence of different quality models for software

web and components, a specific model for portlets

has not been developed yet.

The objective of this paper is to present a portlet

selection model (PtSM) which is composed by a set

of characteristics that must be taken into account

when selecting a portlet. In concrete, PtSM is

composed of two different kinds of characteristics.

On the one hand those characteristics based on the

quality of a portlet (considered as a software product

that combines characteristics of software

components and characteristics of web applications),

which are unified under a quality model, namely

PtQM (Portlet Quality Model). On the other hand,

PtSM will use other characteristics not related to the

portlet quality as such but are fundamental in order

to select the best portlet.

This paper is structured as follows. Section 2

specifies the portlets characteristics. Section 3

explains how to use the selection model of a portlet

(PtSM). Section 4 shows some related works.

Section 5 identifies the quality characteristics for

portlets whereas section 6 identifies the other

portlets characteristics used for the selection of

portlets. Finally, last section summarizes this paper

and outlines the main areas of future work.

301

Ángeles Moraga M., Calero C., Piattini M. and Díaz O. (2007).

PTSM: A PORTLET SELECTION MODEL.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - DISI, pages 301-306

DOI: 10.5220/0002346603010306

 SciTePress

2 PORTLET CHARACTERISTICS

First generation portals tended to present a

monolithic software architecture that compromised

portal development and management, but second-

generation portals let users create one or more

personal pages composed of personalizable portlets -

interactive Web mini-applications, local or remote to

the portal that render markup fragments (news,

weather, sports, and so on) that the portal can

aggregate into a page (Bellas, 2004).

Until recently, the main problem related to

portlets was the lack of a common model which

hindered portlet interoperability. Nevertheless,

WSRP (OASIS, 2005) overcomes this deficiency by

defining a common interface. The main goal of this

standard is to enable an application designer or

administrator to pick from a rich choice of compliant

remote content and application providers, and

integrate them with just a few mouse clicks and no

programming effort (OASIS, 2005).

Therefore, portlets are independent and reusable

Web components which offer a specific

functionality and provide markup fragments ready to

be rendered. An example of a portlet can be a mini-

application whose objective is to provide the

cheapest books of the market. The portlet is

aggregated into the portal web page where the

rendering space available depends on the so-called

window state. In particular, WSRP standard

identifies five window states: normal indicates the

portlet probably shares the portal page with more

portlets; minimized the portlet should not render any

visible markup although can include non-visible

data; maximized indicates the portlet is probably the

only one that is being rendered or that this portlet

has more space; solo indicates that the portal page

only has this portlet; custom is useful for consumers

because they can declare custom window states.

In addition, portlets render different content

depending on its mode. WSRP defines five modes:

the view mode renders markup reflecting the current

state of the portlet; the edit mode provides content

and logic that let a user customize the behavior of

the portlet; the help mode provides help screens that

explains the portlet and its expected usage; the

preview mode provides a rendering of its standard

view mode content, as a visual sample of how this

portlet will appear on the end-user’s page with the

current configuration; the custom mode provides a

field for consumers to declare additional custom

modes (OASIS, 2005).

Next items summarize the main portlet features

for the purpose of this paper.

Portlets provide functionality: they are

individual components that provide content for a

portal (Linwood and Minter, 2004).

Portlets are reusable: they are portal

components that can be shared and exchanged by

various portlet containers to provide enhanced

functionality (Novotny et al., 2004).

Portlets must be usable components: they can be

subject by composition by third parties, so they need

clear interfaces and configurability (Diaz and

Rodriguez, 2004).

The portlet efficiency must be acceptable: they

have to provide an acceptable efficiency in order to

be aggregated to the portal page.

Portlets must be reliable: they must be capable

to manage the different faults that can arise during

its operation.

3 PORTLET SELECTION

MODEL - PTSM

We aim at providing a portlet selection model

(PtSM) based on both a portlet quality model and a

set of characteristics not related to the portlet quality

as such. The use of the selection model is outlined in

figure 1. Specifically, the PtSM must be used in

order to carry out the assessment of a set of portlets

which have similar functions for specified tasks and

user objectives. As a result, the values of the

different characteristics that make up the model must

be estimated for each portlet. Then, taking into

account the users’ needs, the best portlet among the

evaluated is chosen. As a final result, the best portlet

for each case is obtained.

Figure 1: Use of the Portlet Selection Model (PtSM).

The beneficiaries of the portlet selection model,

are portal administrators – the ones who must

choose the most appropriate portlet for building the

portal.

The characteristics of PtSM, can be split into

quality characteristics (these characteristics

constitute PtQM) and other characteristics.

ICEIS 2007 - International Conference on Enterprise Information Systems

302

4 RELATED WORK

Portlets sit in between Web applications and

Software Components and then PtQM is built upon

three main sources: the ISO/IEC 9126 standard,

quality models for components and quality models

for Web applications. Figure 2 describes the major

influences.

The ISO/IEC 9126 standard has come into

existence by the necessity of developing or selecting

high quality software products. This standard seeks

to define a quality model which specifies and

evaluates software product quality from different

perspectives: developers, acquirers, quality

assurance staff and independent evaluator.

Specifically, the model for software product

quality identifies six quality characteristics for

internal and external quality (functionality,

reliability, usability, efficiency, maintainability and

portability) which are decomposed into other sub-

characteristics.

There are other proposals which can be used as

basis to develop our portlet quality model.

Some examples of quality models proposed for

components are the following.

(Botella et al., 2003) propose a quality model for

the selection of Enterprise Resource Planning (ERP)

Systems. (Bertoa and Vallecillo, 2002) present a

quality model for commercial off-the-shelf (COTS)

components. (Simão and Belchior, 2003) identify

the quality characteristics and sub-characteristics

most relevant for software components. (Franch and

Carvallo, 2003) propose a methodology for building

structured quality models based on ISO/IEC 9126.

An example of a quality model proposed for web

applications is the web quality model, namely WQM

and developed by (Calero et al., 2004). Also, (Offutt,

2002) identifies different quality attributes for web

software applications.

Figure 2: Portlet Quality Model: major influences.

5 QUALITY CHARACTERISTICS

FOR PORTLETS

In concrete, the quality characteristics have been

split up into three groups: the first one is made up of

the quality characteristics that have been adapted

from ISO/IEC 9126 standard, the second is

composed of the quality characteristics that have

been adapted from quality models for components,

and finally, the last group is made up of

characteristics that have been considered from

quality models for web applications. It may be worth

emphasizing that each quality characteristic, which

has been considered for portlets, is directly related to

some of the portlet characteristics identified in

section two.

We must realize that there are some

characteristics from ISO/IEC 9126 standard that do

not make sense for portlets due to the own nature of

them. Concretely:

 Maintainability quality characteristic has not

been considered because the tasks related to

the maintenance of software must not be done

by the portal developer.

 Portability quality characteristic has not been

considered as a characteristic on its own but a

sub-characteristic of reusability. The

rationales are twofold. First portlet reusability

implies to understand what the portlet is

about. And second, the portlet must be liable

of being transferred from one environment to

another (i.e. must be portable).

Furthermore, the reusability quality characteristic

has been included because it is fundamental that

portlets can be reused from one environment to

another without problems.

In table 1 the definition of each characteristic of

PtQM is presented.

Table 1: Quality characteristics definitions for portlet

context.

Characteristic Definition

Functionality

Capability of the portlet to provide functions

which meet stated and implied needs when

the software is used under specified

conditions

Reliability

Capability of the portlet to maintain a

specified level of performance when used

under specified conditions

Usability

Ability of the portlet to be used by the portal

developer when constructing a portal with it.

Efficiency

Capability of the portlet to provide

appropriate performance, relative to the

amount of resources used, under stated

conditions.

Reusability

Capability of the portlet to be reused in

different portals by several developers

PTSM: A PORTLET SELECTION MODEL

303

5.1 Quality Subcharacteristics

This sub-section is concerned with obtaining the sub-

characteristics that affect each one of the quality

characteristics previously identified. Table 2 outlines these

sub-characteristics, and their sources (i.e. the work from

which the sub-characteristic has been adapted). More

information about the reusability characteristics can be

found in (Moraga et al., 2005).

Table 2: Quality characteristics definitions for portlet context.

Charac-

teristic

Sub-

characteristic

Definition for portlet context Original source

Accuracy

Capability of the portlet to provide the right or agreed results or effects

with the degree of precision accorded.

ISO/IEC 9126

Interoperability with the portal

Capability of the portlet to interact

with one or more portals

Interoperability

Interoperability with other portlets

Capability of the portlet to interact

with other portlets

ISO/IEC 9126

Security

Ability of the portlet to prevent unauthorized access, whether accidental

or deliberate, to information and data.

(Calero et al.,2004)

Self-

Containment

Capability of the portlet to accomplish by itself alone the function that it

is expected to perform

(Simão and

Belchior, 2003)

Functional-

Cohesion

Capability of the portlet to make use of all its elements in performing its

services.

(Simão and

Belchior, 2003)

Functionality

Compliance

Capability of the portlet to adhere to standards, conventions or

regulations in laws and prescriptions relating to functionality.

ISO/IEC 9126

Maturity Capability of the portlet to avoid failure as a result of faults. ISO/IEC 9126

Fault tolerance

Capability of the portlet to maintain a specified level of performance in

cases of software faults or of infringement of its specified interface.

ISO/IEC 9126

Recoverability Capability of the portlet to recover itself from unexpected failures.

(Bertoa, Vallecillo,

2002)

Degradability

Effort needed to re-establish the essential functionality of the portlet after

a breakdown.

(Calero et al., 2004)

Evaluability

Capability of the portlet to enable the portal developers to evaluate its

form and/or its content

(Simão and

Belchior, 2003)

Availability Capability of the portlet to be operational every day of the year (Offut, 2002)

Reliability

Compliance

Capability of the portlet to adhere to standards, conventions or

regulations in laws and prescriptions relating to reliability.

ISO/IEC 9126

Understanda-

bility

Capability of the portlet to enable the portal administrator to

understand what the portlet is about

ISO/IEC 9126

Learnability

Capability of the portlet to enable the user to learn how the portlet

achieves its aim

ISO/IEC 9126

Customizabi-

lity

It refers to the attributes of portlet that enable the portlet to be

customized by the user, to reduce the effort required to use it and also to

increase satisfaction with the portlet

(Calero et al., 2004)

Usability

Compliance

Capability of the portlet to adhere to standards, conventions or

regulations in laws and similar prescriptions relating to usability.

ISO/IEC 9126

Time behaviour

Capability of the portlet to provide appropriate response and

processing times when performing its function, under stated conditions.

ISO/IEC 9126

Resource

utilisation

Capability of the portlet to use appropriate amounts and types of

resources when the portlet performs its function under stated conditions.

ISO/IEC 9126

Efficienc

Compliance

Capability of the portlet to adhere to standards, conventions or

regulations in laws and similar prescriptions relating to efficiency.

ISO/IEC 9126

Understan-

dability

Capability of the portlet to enable the user to understand what the

portlet is about

(Calero et al., 2004)

Reusa-

bility

Portability

Capability of the portlet to be transferred from one environment to

another.

(Washizaki et al.

2004)

ICEIS 2007 - International Conference on Enterprise Information Systems

304

6 OTHER CHARACTERISTICS

FOR PORTLET SELECTION

In addition to the quality characteristics previously

identified we think that exist other set of

characteristics which affect when selecting a portlet.

For example, we must consider the characteristics

that affect a portlet as a product that must be bought

and aggregated to our software and the reputation or

profile of the provider.

Specifically, in order to determine the set of

characteristics and sub-characteristics, not directly

related to quality, several standards exist. These

standards can be split up into two groups: standards

targeted at components and standards targeted at

software product. In figure 3, the influence of these

standards is shown.

Figure 3: Standards analyzed to obtain characteristics and

sub-characteristics not directly related to quality.

ISO/IEC 14102 and IEEE 1209 are a guideline

for evaluation and selection of CASE tools while

ISO/IEC 90003 is a guideline for the application of

ISO 9001 to computer software.

These standards enumerate different

characteristics which must be considered when a

tool is chosen. These characteristics have been

adapted to the portlet context and gathered in three

main characteristics which are composed of other

sub-characteristics (see Table 3).

Table 3: Other characteristics for portlet selection.

Characteristic Sub-characteristic

Cost

Licensing policies

Acquisition

Surveys to user groups

Portlet vendor profile

Portlet profile

Information related to the installation

Portlet vendor support

Indicators of

support

Feedback of the client to deal with

their complaints

Compliance Portlet vendor certification

The acquisition characteristic accounts for

purchase and usage, and includes the following sub-

characteristics.

Cost: the cost can be derived from the portlet

purchasing or renting.

Licensing policies: it refers to the available

license options, the right to copy (media and

documentation), and any restrictions and/or fees for

secondary usage (because of the fact that portlets

can use other elements to carry out its functionality).

Surveys to user groups: the opinion that portlet’s

users have about it can be a good or bad influence on

the decision to choose the portlet or not.

The indicator of support characteristic is

related to the support that the portlet vendor

provides, as well as, the profile of both the portlet

vendor and the portlet itself. This characteristic is

composed of the following subcharacteristics.

Portlet vendor profile: it is a general indication

of the portlet vendor’s overall capability. This

profile might include the portlet vendor’s size,

number of years in business, a financial statement, a

listing of any complementary products,

identification of relevant business relationships (for

example, other tool suppliers), and the company’s

planned direction for future development.

Portlet profile: general information about the

portlet including portlet age, number of paid

installations, existence, size and level of activity of a

user’s group, formal problem reporting system,

portlet development program, body of applications,

freedom from error, and availability (i.e.

commercial, government public domain, in-house,

or under development).

Information related to the installation:

documentation related to the portlet installation. This

information is useful if the portlet is locally run.

Feedback of the client to deal with their

complaints: the portlet vendor provides some

mechanism to help users to process their complaints.

Portlet vendor support: availability,

responsiveness, and quality of services provided by

the vendor to portlet users. Such support services

might include telephone support, local technical

support and on-site support.

Finally, the compliance characteristic alludes to

the certifications that the portlet vendor owns. This

characteristic includes the sub-characteristic Portlet

vendor certification: certification from a

professionally recognized software engineering

evaluation organization (for example, the Software

Engineering Institute, the ISO) that shows that the

software engineering practices of the portlet vendor

meet some minimum level, or are at some defined

level. Certification may be informal, for example by

reviewing vendor-supplied quality/defect data.

PTSM: A PORTLET SELECTION MODEL

305

7 CONCLUSIONS AND FUTURE

WORK

We have presented a portlet selection model, namely

PtSM, to be used to choose the “most appropriate” portlet

among a set of portlets with similar functions for specified

tasks and user objectives. This model uses a quality model

(PtQM) which integrates and adapts to the portlet case,

models proposed for Web applications, Software

components and Software products. The outcome is shown

in figure 4.

Figure 4: Portlet Selection Model.

The next step will be to identify measures for

each one of the characteristics and sub-

characteristics. To date, we have identified the

measures which affect reusability characteristic

(Moraga et al., 2005). A similar reasoning should be

used to obtain the measures that affect the rest of

characteristics.

Future work also includes the validation of the

model characteristics through surveys. Thereby, the

PtSM for portlets will be finished.

The final goal is to have a well-defined model

that facilitates portlet selection as well as identify

possible improvements in the characteristics based

on the values of the measures of a given portlet in

order to assure that it will be selected when

compared with others.

ACKNOWLEDGEMENTS

This work is part of the MECENAS (PBI06-0024)

project supported by Junta de Comunidades de

Castilla-La Mancha, the DIMENSIONS project

(PBC-05-012-1) supported by FEDER and Junta de

Comunidades de Castilla-La Mancha and the

CALIPSO network (TIN2005-24055-E) supported

by the Spanish Ministerio de Educación y Ciencia.

REFERENCES

Bellas, F. (2004). "Standards for Second-Generation

Portals." IEEE Internet Computing. 8(2): 54-60.

Bertoa, M. F. y A. Vallecillo (2002). Quality Attributes for

COTS Components. Proc. of the 6th ECOOP

Workshop on Quantitative Approaches in Object-

Oriented Software Engineering (QAOOSE 2002).

Málaga, Spain.

Botella, P., X. Burgués, J. P. Carvallo, X. Franch, J. A.

Pastor y C. Quer (2003). "Towards a Quality Model

for the Selection of ERP Systems." Component-Based

Software Quality: 225-245.

Calero, C., J. Ruiz y M. Piattini (2004). A web metrics

survey using WQM. Fourth International Conference

on Web Engineering, Munich. pp. 147-160

Diaz, O. y J. J. Rodriguez (2004). "Portlets as Web

Components: an introduction." Journal of Universal

Computer Science 10(4): 454-472.

Franch, X. y J. P. Carvallo (2003). "Using Quality Models

in Software Package Selection." IEEE Software.

20(1): 34-41.

Java Community Process (2003). JSR 168 portlet

specification. http://www.jcp.org/en/jsr/detail?id=168.

Linwood, J. y D. Minter (2004). Building Portals with the

Java Portlet API. United States of America, Apress.

Moraga, M. Á., C. Calero, I. Paz, O. Diaz y M. Piattini

(2005). A Reusability model for Portlets. Web

Information Systems Quality (WISQ 2005) Workshop.

pp. 21-32

Novotny, J., M. Russell y O. Wehrens (2004). GridSphere:

An Advanced Portal Framework. 30th EUROMICRO

Conference. pp. 412-419

OASIS (2005). Web Service for Remote Portals (WSRP)

Version 2.0. http://www.oasis-

open.org/commitees/wsrp/.

Offutt, A. J. (2002). "Quality attributes of web software

applications." IEEE Software. 19(2): 25-32.

Simão, R. P. y A. Belchior (2003). Quality Characteristics

for Software Components: Hierarchy and Quality

Guides. Component-Based Software Quality. pp. 184-

206

ICEIS 2007 - International Conference on Enterprise Information Systems

306