NORWEGIAN UNIVERSITY OF SCIENCE AND TECHNOLOGY Department of Computer and Information Science

Pre-diploma Project Thesis

Research@work
Design and Implementation of a Portal for Researchers at Telenor Research & Development

By Minh Hoang Nguyen and Thor Gunnar Steinsli

AUTUMN 2002

ABSTRACT
In the context of cooperative technology, this report presents a portal that gives user access to resources related to conducting research in an industry environment and promoting learning. The project work is carried out at Telenor Research & Development, which is the largest private research establishment in Norway within the area of Information and Communication Technology. This report makes the following contributions: It presents requirements specification of the portal. It presents a comprehensive architecture description of the portal. It presents an implementation of the portal based on the requirements specification.

The originally text of given project task sound as written: Coop. Tech - Online researcher portal. Telenor R&D employs approximately 350 researchers nationwide involved in internal, national and international research projects. Telenor R&D is the largest private research center in Norway in the area of telecommunication. The aim of this task is to develop an online resource center for Telenor R&D, giving access to resources related to conducting research in an industry environment and promoting learning. The deliverables of the task are a requirements document and an online researcher portal: A requirements specification document: This document will collect the results from interviews with Telenor R&D researchers, outlining their information needs and specifying the functionality of the portal. An online researcher portal: This portal will consist mainly of web pages with pointers to internal and external resources and information. The portal will be structured according to the requirements document, and will be used as a support tool by all Telenor R&D researchers in their work.

It is recommended that this task is taken in connection with a diploma thesis. The aim of a possible diploma thesis will be to further integrate the researcher portal with the internal e-learning system used by Telenor.

ii

PREFACE
This report represents our pre-diploma project thesis in Software Engineering at the Norwegian University of Science and Technology, Department of Computer and Information Science. We chose to work on the project originally called "Cooperative Technology - Online researcher portal". The project is carried out jointly by the undersigned.

We would especially like to express our gratitude to our supervisors: Dr.

Monica Divitini and Dr. Babak Farshchian.

~ We would also like to thank all participants at Telenor Research & Development in Trondheim for their time and cooperation during the work on this project. ~

Trondheim, November 22nd, 2002.

___________________________

___________________________

Minh Hoang Nguyen

Thor Gunnar Steinsli

iii

TABLE OF CONTENTS
ABSTRACT.......................................................................................................................... I PREFACE ...........................................................................................................................II 1 INTRODUCTION ........................................................................................................1 1.1 THE PROJECT TASK............................................................................................1 1.1.1 The task assignment ........................................................................................1 1.1.2 Motivation for the task ....................................................................................1 1.1.3 Problem definition...........................................................................................1 1.1.4 Objectives .......................................................................................................1 1.2 THE PROJECT EXECUTION................................................................................2 1.2.1 Project results..................................................................................................2 1.2.2 Project execution.............................................................................................2 1.2.3 Prototyping development model ......................................................................3 1.3 CUSTOMER REQUIREMENTS............................................................................4 1.3.1 High-level functional requirements..................................................................4 1.3.2 High-level non-functional requirements ..........................................................4 1.4 TELENOR RESEARCH & DEVELOPMENT .......................................................5 1.4.1 About Telenor Research & Development ........................................................5 1.4.2 About the research work..................................................................................5 1.5 THE STRUCTURE OF THE REPORT ..................................................................6 2 STATE-OF-THE-ART .................................................................................................7 2.1 THEORETICAL BACKGROUND.........................................................................7 2.1.1 The term portal............................................................................................7 2.1.2 Web portal services .........................................................................................7 2.2 TECHNICAL BACKGROUND .............................................................................8 2.2.1 Portlets and Portlet Containers ........................................................................8 2.2.2 Remote Portlets...............................................................................................9 2.2.3 Web Services for Remote Portals ..................................................................10 2.2.4 Portal Server Standardization ........................................................................11 2.2.5 Web portal solution .......................................................................................11 2.3 NON-COMMERCIAL SOLUTIONS ...................................................................11 2.3.1 Jetspeed.........................................................................................................11 2.3.2 Zope..............................................................................................................11 2.4 CONCLUSION ....................................................................................................12 3 PREPARATORY STUDY .........................................................................................13 3.1 INTRODUCTION ................................................................................................13 3.2 JAVASERVER PAGES (JSP) ..............................................................................13 3.2.1 JSP Definition ...............................................................................................13 3.2.2 JSP Advantages.............................................................................................13 3.3 TECHNOLOGIES COMPARISON......................................................................14 3.3.1 JSP versus CGI .............................................................................................14 3.3.2 JSP versus PHP .............................................................................................15 3.3.3 JSP versus ASP .............................................................................................15 4 PORTAL REQUIREMENTS SPECIFICATION.....................................................16 4.1 4.2 INTRODUCTION ................................................................................................16 OVERALL DESCRIPTION .................................................................................16

iv 4.3 FUNCTIONAL REQUIREMENTS ......................................................................17 4.3.1 Ordinary user actor related requirements .......................................................17 4.3.2 Editor user actor related requirements ...........................................................18 4.3.3 Functional requirements summary list ...........................................................19 4.4 USE CASES .........................................................................................................20 4.4.1 Use case for Ordinary user actor....................................................................20 4.4.2 Use case for Editor user actor........................................................................21 4.5 NON-FUNCTIONAL REQUIREMENTS ............................................................22 4.5.1 Non-functional requirements summary list ....................................................22 5 PORTAL ARCHITECTURE.....................................................................................23 5.1 INTRODUCTION ................................................................................................23 5.2 DEPLOYMENT VIEW ........................................................................................23 5.2.1 Overview ......................................................................................................23 5.2.2 JSP architecture of the portal .........................................................................23 5.2.3 The web server ..............................................................................................24 5.2.4 JSP application platform................................................................................25 5.2.5 JSP Syntax Basics .........................................................................................26 5.3 DATA VIEW........................................................................................................28 5.3.1 Design of the database...................................................................................28 5.3.2 Database table details ....................................................................................29 6 THE PORTAL ............................................................................................................30 6.1 GRAPHICAL USER INTERFACE (GUI) OF THE PORTAL..............................30 6.1.1 GUI of the front page ....................................................................................30 6.1.2 GUI related to user........................................................................................31 6.1.3 GUI related to editor .....................................................................................34 6.2 SCENARIO OF USAGE ......................................................................................38 6.2.1 Inexperienced user ........................................................................................38 6.2.2 Experienced user ...........................................................................................38 7 EVALUATION OF THE RESULT ...........................................................................39 7.1 7.2 7.3 8 8.1 8.2 9 10 11 11.1 11.2 12 OBJECTIVES ACHIEVEMENT..........................................................................39 REQUIREMENTS FULFILMENT.......................................................................40 EVALUATION OF SCENARIOS ........................................................................41 SUMMARY .........................................................................................................42 FURTHER WORK ...............................................................................................42 GLOSSARY ............................................................................................................44 APPENDIX A USE CASE DESCRIPTIONS .....................................................46 ORDINARY USER USE CASES .........................................................................46 EDITOR USER USE CASES ...............................................................................49 APPENDIX B CUSTOMER FEEDBACK .........................................................54

CONCLUSIONS.........................................................................................................42

REFERENCES ...........................................................................................................43

TABLE OF FIGURES
Figure 1-1: Project execution..................................................................................................2 Figure 1-2: Schematic representation of the prototype model..................................................3 Figure 1-3: High-level requirements .......................................................................................4 Figure 1-4: The research process ............................................................................................5 Figure 2-1: Building blocks of a portal server (provided by [3]) .............................................9 Figure 2-2: Portlets run on the local portal server (provided by [3]) ......................................10 Figure 2-3: Locating remote portlets (provided by [3]) .........................................................10 Figure 4-1: Users in the system ............................................................................................16 Figure 4-2: Use case for Ordinary user actor.........................................................................20 Figure 4-3: Use case for Editor user actor.............................................................................21 Figure 5-1: Deployment view ...............................................................................................23 Figure 5-2: JSP architecture..................................................................................................24 Figure 5-3: Web server .........................................................................................................24 Figure 5-4: Sequence diagram for rating article ....................................................................25 Figure 5-5: Adding a category in the portal application ........................................................27 Figure 5-6: JSP code for category_add_action.jsp.................................................................27 Figure 6-1: The portal GUI front page ...............................................................................30 Figure 6-2: The portal GUI view article .............................................................................31 Figure 6-3: The portal GUI comment and rate article.........................................................32 Figure 6-4: The portal GUI view comment ........................................................................32 Figure 6-5: The portal GUI recommend article ..................................................................33 Figure 6-6: The portal GUI forum......................................................................................33 Figure 6-7: The portal GUI front page of admin.................................................................34 Figure 6-8: The portal GUI category overview ..................................................................35 Figure 6-9: The portal GUI article overview ......................................................................36 Figure 6-10: The portal GUI proposal overview ................................................................37 Figure 6-11: The portal GUI portal logging .......................................................................37

TABLE OF TABLES
Table 3-1: JSP versus ASP ...................................................................................................15 Table 4-1: Functional requirements summary list .................................................................19 Table 4-2: Non-functional requirements summary list ..........................................................22 Table 5-1: Database tables details.........................................................................................29 Table 7-1: Implementation of the functional requirements ....................................................40

1 INTRODUCTION
1.1 THE PROJECT TASK 1.1.1 The task assignment
Telenor Research & Development assigns the project task originally called "Cooperative Technology - Online researcher portal" because they need a system to support knowledge management. An important purpose of knowledge management is capturing the knowledge created by the researchers as they do the research work and make it available to a larger community of colleagues.

1.1.2 Motivation for the task

By the time, the researchers at Telenor Research & Development don have a system to t support knowledge management. The motivation and the aim of this project task are developing a system to support knowledge management for the researchers. The system shall support collaboration and provide resources and information related to the research work. The research work that address to the aspect of the task is described briefly in section 1.4.2.

1.1.3 Problem definition

We define two main problems related to the task: P1: Inexperienced researchers are novice with research work; they need therefore a support system to provide them resources and information related to the research work. P2: The knowledge about the research work that possess among the researchers are an important asset; the researchers need therefore a system to capture the useful knowledge and provide collaboration and knowledge exchange.

1.1.4 Objectives
We define three objectives related to the problem definitions: Objective 1: Constructing a resource centre to gives researchers access to information and resources related to research work in an industry environment. This objective attempts to solve P1. Objective 2: Constructing a discussion forum to provide knowledge exchange and promote communication and learning among researchers. This objective attempts to solve P2. Objective 3: In the context of knowledge management: constructing an editor tool to give the editor quality assurance support to establish, control and manage the information.

1.2 THE PROJECT EXECUTION 1.2.1 Project results

The results of this project give the following contributions: It contributes an application: We have designed and implemented an application that consists of user functionality and an editor tool. User functionality consists of pointers to resources and information related to research work, it also consists a discussions forum, which allows user to collaborate and exchange knowledge with each other. The editor tool gives the editor quality assurance support to establish, control and manage the information in the application.

It contributes the following specification documents: A requirements specification document: This document presents the requirements of the application, collected and elicited through informal customer requirements and through revisions of the prototype application, respectively. A comprehensive architecture document: This document provides a comprehensive architectural overview of the application using a number of different architectural views to show different aspects of the application. It also captures and conveys the significant architectural decisions that have been made.

1.2.2 Project execution

Figure 1-1 illustrates how the project was executed. It involves four main phases: preliminary requirements phase, state-of-the-art study, preparatory study, and at last, the construction phase.

Figure 1-1: Project execution

The first phase, preliminary requirements, involves mainly in collecting of the preliminary customer requirements by informal oral interview and conversation with the researchers at Telenor R&D. The requirements collected are used as input to state-of-the-art study and preparatory study. The second phase of the project execution, state-of-the-art study, gives an introduction to the state-of-the-art to the field that concerns the project task.

3 The third phase, preparatory study, examines different potential solutions to how the project task should be solved. It involves in studying different kinds of technologies to see if they could comply with the requirements of the task. The construction phase involves in design the proposed solution based on the preparatory study and customer requirements.

1.2.3 Prototyping development model

In the context of software development, prototyping has been used as a development model to develop the system. Prototyping [1] is a technique that constructs and experiments with a mock-up version of the software system, in order to gain some understanding of the functionality and behavior required from it. The prototyping development model has been used explicit in this project of the following reasons: ? To understand the functionality and behavior from the system ? ? To understand the requirements for the user interface ? ? To elicit requirements from the user ? The prototyping development model (shown graphically in Figure 1-2) starts with an initial phase, informal requirements, which involves understanding of the users needs through elicitation of preliminary requirements from the user; it is achieved by oral interview and conversation with the researchers at Telenor R&D. The next phase, prototyping, implements the prototype application based on the informal requirements. Elicitation of more requirements and feedback is achieved by involving researchers in experimental use of the prototype in the revision phase. In the last phase, the prototype is refined into a final system after a number of necessary revisions.

Figure 1-2: Schematic representation of the prototype model

1.3 CUSTOMER REQUIREMENTS

This section presents preliminary customer requirements. The requirements collected are informal, archived by oral conversation with the researchers at Telenor R&D, and aimed at describing the high-level requirements of the system, to use as input to prototyping. The customer requirements are summarized as below:

1.3.1 High-level functional requirements

User related requirements: ? User shall be able to get information from the system. ? ? User shall be able to contribute information to the system. ? ? Classification and grouping of information shall be possible. ? Editor related requirements: ? The system shall give the editor quality assurance support to ? manage and control the information in the system.

1.3.2 High-level non-functional requirements

? The system shall be implemented with open technologies. ? ? The system shall require no installation on the client side. ? ? The system shall be easy available from everywhere. ? ? The system shall be easy to maintain. ? ? The system shall be user-friendly. ? ? The system shall be extendible. ?

Figure 1-3 illustrates high-level requirements that have consequence on the project:

Figure 1-3: High-level requirements

1.4 TELENOR RESEARCH & DEVELOPMENT 1.4.1 About Telenor Research & Development
Telenor Research & Development (Telenor R&D) is the largest private research establishment in Norway within the area of Information and Communication Technology. It employs approximately 350 researchers nationwide involved in internal, national and international research projects. Research activities in Telenor are largely carried out in collaboration with other establishments within research and development. The activities are divided into the following main areas: national R&D, international R&D, standardization, incubator, alliances and strategic collaboration [2].

1.4.2 About the research work

The research work at Telenor R&D is made up of a number of research processes. As figure 1-4 illustrates, there are four processes involving in the research process: research preparing, research proposal, research execution and research presentation. The research preparation involves mainly in conceiving potential ideas for doing a research project. The researchers brainstorm and look closely at the ideas, decide what is important, analyze the issues and narrow their topic to make it manageable, and plan how they are going to do the research. The next phase deals with research proposal. A research proposal is a document seeking external approval of funding or other resource support for, a potential research project. Researchers usually need financial support in order to do research, writing research proposals is therefore a primary importance task because it submits for acceptance or rejection. Secondary importance tasks shall involving in searching and identify potential funding agencies. On condition that the research proposal is accepted and the researchers obtain financial support from a funding agency, the third phase shall deal with research execution, which means doing the research. Research presentation deals with presenting the research findings. Research presentation can be presented as oral presentation or in written form. Research presentation aims in preparation and delivery of research paper, talks or conference presentation for a research audience.

Figure 1-4: The research process

1.5 THE STRUCTURE OF THE REPORT

The report is mainly organized as follows: Section 1: Introduction This section gives an introduction to this report including background, motivation, definition of the problem, and also objectives and the results of the project. Section 2: State-of-the-art This section gives an introduction to the theoretical and technical background to the field that concerns the project. Section 3: Preparatory study This section presents the solution intended for the system implementation. Section 4: Portal requirements specification This section presents the requirements of the implemented system, collected and elicited through informal preliminary customer requirements and through revisions of the prototype application, respectively. Section 5: The Portal architecture This section describes the complete architecture of the implemented system; it provides a comprehensive architectural overview of the system using a number of different architectural views to show different aspects of the system. Section 6: The Portal This section presents the Graphical User Interface of the implemented system. It also presents a scenario of usage.

2 STATE-OF-THE-ART
2.1 THEORETICAL BACKGROUND 2.1.1 The term portal
The term portal is used quite ambiguously, especially because it evolved over time and became commonplace. Portals started as web applications, providing a single point of access to information, resources, applications and people. Portals are defined with respect to a community of users who share common task and interests. Portals can be categorized in four categories [3] according to the users they serve and the services they offer: Public portals, such as Yahoo, bring together information from various sources, applications, and people, offering personalization for arbitrary users. Marketplace portals are trading hubs that connect sellers and buyers. Enterprise portals give employees access to organization specific information and resources, while specialized portals, offer an access path to specific application. Specialized portals in the corporate sector are sometimes called vortals, for vertical portals, since they provide in-depth capabilities that are highly focused on a vertical segment of an organization or field. The portal presenting in this report is definite a vertical portal since it focuses on a segment (Research & Development) of an organization (Telenor).

2.1.2 Web portal services

Web portal share a few common set of services. A description [3] of the services are summarized as below: Customization recognizes different users and offers them specific content configured to their need. The service is based on gathering information about users and users communities and delivering the right content at the right time. Content aggregation prepares content from different sources for different users. It requires the user specific context through the security service authentication call, and the customization s service personalization call. s Content syndication gathers content from different sources. The syndication service talks to attached backend system via the appropriate protocol. Multidevice support prepares content for different interaction channels, such as those for wired and wireless phones, pagers, and faxes, by considering their characteristic capabilities. The multidevice service requires a transcoding service to filter content. Single sign-on services let the syndication service access back-end systems and retrieve user specific information without user authentication each time.

8 Portal administration determines how users see the portal by enable administrators to define user groups, interaction channels, and authorization information as well, depending on the portal s nature. Portal user management varies depending on the portal audience. Administrators must therefore categorize s portal users into groups, so that the portal can be present content specific to a user s role, interests, location, function, or position.

2.2 TECHNICAL BACKGROUND

Portals are largely based on existing Web application technology, such as Web servers and Java 2 Platform Enterprise Edition (J2EE). To implement common services, many portal implementations use similar architecture concepts, including portlets, portal server architectures, and portal integration with remote portlets.

2.2.1 Portlets and Portlet Containers

Content providers make content available to users as portlets. A portlet is a piece of code that runs on the portal server and provides content to be embedded into portal pages. J2EE supports both portlet design and portlet interaction with run-time environments and therefore is one of most widely known models for making components available on a server. In J2EE, server-side components live in specialized containers. The container is the serverside components run-time environment; it calls the component and provides component specific service, such as user information. In comparison, JavaServer Pages (JSP) lives in a JSP container, and servlets live in a servlet container. Likewise, portlets live in portlet containers. The portlet API: The portlet API defines the interface between the portlet and the portlet container. Important elements of the portlet API include: ? request and response, which provides and receives information specific to the portlet ? invocation; ? session, which stores information across portlet invocations; ? ? config objects, which contain configuration information about the user and portlet ? context; and ? actions, which enable interaction between multiple portlets. ? Portlets modes: Portlets are available in several modes. Users can view present content, launch help for a particular view, or edit the view to customize it to their preferences, and administrators can configure the portal to customize services. The mode users select determines which portlet interface they see. The view can be in one of several states, including normal, ll maximized, minimized, closed, and so on.

9 Additional properties: Like servlet deployment descriptors, portlet descriptors contain deployment-related properties for each portlet. In addition to the portlet container, a portal server must provide portlet services such as syndication services, which cache content from unreliable content providers, and persistence services, which let portlets store information to a persistence medium. The most important portlet service is the user info service, which gives portlets access to userrelated information including preferences and customization information. Figure 2-1 (provided by [3]) shows the typical building of a portal server built as a servlet application. The portal engine receives the servlet request from the servlet container and transforms the request into a portlet that it dispatches to the appropriate portlet. The portlet must retrieve the content using the portlet services provided by the portal server. The portal engine then aggregates the multiple portlet response and returns a servlet response to the user.

Figure 2-1: Building blocks of a portal server (provided by [3])

2.2.2 Remote Portlets

Portals draw information and content from many sources, including in-house systems and Internet-based content and application providers. To integrate new sources, portal providers must adapt the content to a format the portal understands. Portal providers can reduce their integration effort in two ways. The first approach: In the first approach, external service providers deliver content in a format that is directly consumable by a clipping portlet, typically HTML or WML. The drawback is that this approach limits the portal ability to prepare content specific to the user interaction s s channel.

10 The second approach: In the second approach, the portal provider installs a portlet in the external service provider s portal server. The portlet then consumes the content in its specific format to render it as part of the overall portal page. Putting third-party code on the portal server can open both stability and security holes. For example, an employee portal might provide access to Internet-based weather information and a human resource application in the corporate enterprise resource-planning system. To provide such access, administrators run the portlets locally on the portal server, as Figure 2-2 (provided by [3]) shows.

Figure 2-2: Portlets run on the local portal server (provided by [3])

2.2.3 Web Services for Remote Portals

Web services for remote portals (WSRPs) are visual, user-facing Web service components that plug-and-play with portals or other intermediary Web applications that aggregate content from different sources. Content or application providers implement their service as a remote portal Web service and publish it in a globally accessible directory, such as the Universal Description, Discovery, and Integration registry (UDDI). The directory lets portal providers easily find a desired service. Directory entries, published in Web Services Description Language (WSDL) format, briefly describe the WSRP component and offer details about the services. The portlet proxy binds to the WSRP component through Simple Object Access Protocol (SOAP), and the remote portlet invocation (RPI) protocol ensures the proper interaction between both parties. Figure 2-3 shows (provided by [3]) an example of how a portal finds and integrates a remote portlet.

Figure 2-3: Locating remote portlets (provided by [3])

11

2.2.4 Portal Server Standardization

Most portal server products today are Java/J2EE-based. Portal server technology is still a young and fragmented field, but specific standards are currently in the works. There are ongoing standardization efforts in two important areas of portal server technology: the portlet API and Web Services for Remote Portals. Portlet API: Experts within the Java Community Process are currently extending the J2EE standard within a Java Standardization Request, with the goal of unifying several open-source projects and products from different portal vendors. In addition to unification, the group wants to ensure that the portlet API will be based on open standards. The specification will comprise the portlets themselves, the portlet API, and the deployment descriptor format. Web Services for Remote Portals: A technical committee from the Organization for the Advancement of Structured Information Standards (Oasis) is currently developing a standard for Web services for remote portals. WSRP will allow plug-and-play interoperation of visual, user-facing Web services with portals and other intermediary Web application. It will also let providers implement remote portlets in any technology, e.g. J2EE, .NET, or any SOAP-accessible service.

2.2.5 Web portal solution

There are a number of commercial web portal solutions available on the market; e.g. IBM EIP, Hyperwave and BEA Weblogic. However, since this project has no financial support, we exclude the commercial solutions, and focus only on non-commercial solutions, mainly in Jetspeed and Zope.

2.3 NON-COMMERCIAL SOLUTIONS 2.3.1 Jetspeed

Jetspeed is an Open Source implementation of an Enterprise Information Portal, using Java and XML. A portal makes network resources (applications, databases and so forth) available to end-users. The user can access the portal via a web browser, WAP-phone, pager or any other device. Jetspeed acts as the central hub where information from multiple sources are made available in an easy to use manner [10]. Jetspeed lets you focus on building connections to outside resources, such as Web services, databases, and content feeds. It features built-in services for user interface customization, caching, persistence, and user authentication. As a portal developer, you don't have to build any of those services yourself; instead, you can concentrate on retrieving external data and displaying it. Jetspeed doesn't place any restrictions on what resources portlets may access.

2.3.2 Zope
Zope is a leading open source application server, specializing in content management, portals, and custom applications. Zope enables teams to collaborate in the creation and management of dynamic web-based business applications such as intranets and portals [11].

12 Zope is a framework for building web applications. Unlike ASP or PHP, Zope is a highly object-oriented Web development platform. It provides clean separation of data, logic and presentation, an extensible set of built-in objects and a powerful integrated security model. The Zope infrastructure relieves the developer of most of the onerous details of Web application development such as data persistence, data integrity and access control, allowing you to focus on the problem at hand Zope consists of several different components that work together to help you build web applications; Zope comes with a Web server, a Web based interface, an object database, relation and scripting language support. An object database provides a simple, familiar way to manage objects that resembles the way many common file managers work, while relational integration offer integration with other databases, such as Oracle, PostgreSQL, Sybase, MySQL and many others. Scripting language support allows you to write web applications in a number of different languages, like Python and Zope's own Document Template Markup Language (DTML). These are just some of the compelling features that Zope offer. Zope's best feature of all is its friendly, open source license. This means that not only is Zope free of cost for you to download, but you are also free to use Zope in your own products and applications without paying royalties or usage fees. Zope's open source license also means that all of the "source code" for Zope is available for you to look at, understand, and extend. Zope does not lock you into a proprietary solution that could hold you and your web users hostage.

2.4 CONCLUSION
Despite the features that Zope and Jetspeed offer, none of them are adequate because of the following reasons: ? Time feasibility: due to the project duration, which takes about three months, it is ? important to choose a technology that is easy to learn. We have experienced that both Zope and Jetspeed are quite difficult to maintain and demanding to install. It implicates a high learning threshold. ? Cost of complexity: Jeetspeed and Zope are motivated for large application and many ? users, while the purpose of the application for the project will only be used for a small group of researchers at Telenor R&D. ? Resource availability: Jetspeed is currently in development, a final product version is ? anticipated shortly, but document supports are limited. Because of these reasons, Zope and Jetspeed are therefore excluded for the portal implementation. A study of enabling technology is adopted in preparatory study.

13

3 PREPARATORY STUDY
3.1 INTRODUCTION
JavaServer Pages (JSP), Hypertext Preprocessor (PHP), Active Server Page (ASP) and Common Gateway Interface (CGI) are enabling technologies that are applicable to implementing the portal application. However, we have chosen JavaServer Pages (JSP) for the portal implementation of the following main reasons: ? Time feasibility ? JavaServer Pages is based on Java technology, since we are quite familiar with Java, JSP serve a great benefit because we can focus on other importance issues than to learn a new technology, which is quite time-consuming. ? Technical feasibility ? The ability to run the implemented application on different platforms is a benefit. JSP technology is platform independent, the implemented system can be run in Windows or Unix system. This section presents mainly JSP, which is compared to CGI, PHP, and ASP.

3.2 JAVASERVER PAGES (JSP) 3.2.1 JSP Definition

JavaServer Pages , termed as JSP, is the Java 2 Platform, Enterprise Edition (J2EE) technology for building applications for generating dynamic web content, such as HTML, DHTML, XHTML and XML. The JavaServer Pages technology enables the easy authoring of web pages that create dynamic content with maximum power and flexibility [4].

3.2.2 JSP Advantages

According to [4], JavaServer Pages technology offers the following benefits: Write Once, Run Anywhere properties JSP technology is platform independent in its dynamic web pages, its web servers, and its underlying server components. JSP pages may be authored on any platform, run on any web server or web enabled application server, and accessed from any web browser. Server components can be built on any platform and run on any server. High quality tool support Platform independence allows the JSP user to choose best-of-breed tools. Additionally, an explicit goal of the JavaServer Pages design is to enable the creation of high quality portable tools.

14 Separation of Roles JSP supports the separation of developer and author roles: Developers write components that interact with server-side objects. Authors put static data and dynamic content together to create presentations suited for their intended audiences. Each group may do their job without knowing the job of the other. Each role emphasizes different abilities and, although these abilities may be present in the same individual, they most commonly will not be. Separation allows a natural division of labor. A subset of the developer community may be engaged in developing reusable components, intend to be used by authors. Reuse of components and tag libraries The JavaServer Pages technology emphasizes the use of reusable components such as JavaBeans components, Enterprise JavaBeans components, and tag libraries. These components can be used with interactive tools for component development and page composition, yielding considerable development timesavings. In addition, they provide the cross-platform power and flexibility of the Java programming language or other scripting languages. Separation of dynamic and static content The JavaServer Pages technology enables the separation of static content in a template from dynamic content that is inserted into the static template. This greatly simplifies the creation of content. The separation is supported by beans specifically designed for the interaction with server-side objects, and by the tag extension mechanism. Support for scripting and actions The JavaServer Pages technology supports scripting elements as well as actions. Actions encapsulate useful functionality in a convenient form that can be manipulated by tools. Scripts provide a mechanism to glue together this functionality in a per-page manner. Web access layer for N-tier enterprise application architecture(s) The JavaServer Pages technology is an integral part of the J2EE. The J2EE platform brings Java technology to enterprise computing. You can now develop powerful middle-tier server applications that include a web site using JavaServer Pages technology as a front end to Enterprise JavaBeans components in a J2EE compliant environment.

3.3 TECHNOLOGIES COMPARISON 3.3.1 JSP versus CGI

The CGI (Common Gateway Interface) is a standard for interfacing external applications with information servers, such as HTTP or Web servers [5]. CGI is a conventional web technology and still widely used in development of web sites. However, CGI has many disadvantages like poor efficiency when users increasing, difficult for programming and maintaining, and high resource occupation.

15

3.3.2 JSP versus PHP

PHP (officially "PHP: Hypertext Preprocessor") is a server-side HTML-embedded scripting language [6]. PHP is also a good web application development technology. It can be used on different platforms and perfectly cooperate with MySQL. But once concerning performance PHP cannot compare with JSP. PHP does not provide a uniform database connective interface while JSP has a powerful JDBC technology supported.

3.3.3 JSP versus ASP

Active Server Pages or ASP is a web technology that is offered by Microsoft and widely used in NT servers. Comparisons shown by the following table provided by [7]: JSP Most popular web servers including Apache, Netscape, and Microsoft IIS can be easily enabled with JSP. Platform independent. Runs on all Java-enabled platforms. ASP Native support only within Microsoft IIS or Personal Web Server. Support for select servers using third-party products. Is fully supported under Windows. Deployment on other platforms is cumbersome due to reliance on the Win32-based component model. Uses the Win32-based COM component model.

Web Server Support

Platform Support

Component Model

Scripting Security Database Access Customizable Tags

Relies on reusable, crossplatform components like JavaBeans, Enterprise JavaBeans, and custom tag libraries. Can use the Java programming language or JavaScript. Works with the Java security model. Uses JDBC for data access. JSP is extensible with custom tag libraries.
Table 3-1: JSP versus ASP

Supports VBScript and JScript for scripting. Can work with the Windows NT security architecture. Uses Active Data Objects for data access. Cannot use custom tag libraries and is not extensible.

Although JSP and ASP are fairly similar in the functionality that they provide, they are fundamentally different technologies. From the table, we can see that JSP has many advantage over ASP.

16

4 PORTAL REQUIREMENTS SPECIFICATION

4.1 INTRODUCTION
This section presents functional and non-functional requirements of the portal application.

4.2 OVERALL DESCRIPTION

Figure 4-1 shows all the actors that will interact with the application. The actor Ordinary user and the actor Editor user represent real users. The privileges associated to each kind of user are described in more detail in the next section, which gives a presentation of functional requirements related to each of the actors.

User

Ordinary user

Editor

Figure 4-1: Users in the system

Ordinary user An ordinary user represents all the people that may use the application. An ordinary user is authorized to view categories, articles, comments and forum messages to the application. In addition the user may add forum topics and forum messages to the application forum, the user can also give contributions by sending proposals to the application. Editor user Editor user is a user that has editor properties to manage the application. The editor can view available categories, articles and incoming proposals. In addition the editor has the rights to manage (add, remove and modify) the categories and articles in the application.

17

4.3 FUNCTIONAL REQUIREMENTS 4.3.1 Ordinary user actor related requirements

Read article: The user shall be able to click on an article URL, and read the article. The user shall be able to give a personal comment to the article. Other users can access this comment. The user shall be able to rate an article after (s)he has read it. An average rating will then be presented along with the article. The user shall be able to give contributions to the article section. These contributions will be laid in a closed section, and the administrator can check these out later and decide if they should be made public. The user shall be able to recommend an article to a college by e-mail after (s)he has read it. The user shall be able to read contributions from other users in the forum. The user shall be able to write/reply in the forum. The user shall be able to sort the view of articles for a chosen category. The user shall be able to search the portal for needed data.

Comment article:

Rate article:

Propose article:

Recommend article:

Read in the forum:

Write in the forum: Sort articles:

Search the portal:

18

4.3.2 Editor user actor related requirements

Log in: The editor must log in before (s)he can get the administrator properties. The editor shall be able to add (main) categories for articles. The editor shall be able to add subcategories for articles. The editor shall be able to edit category or subcategory. The editor shall be able to delete a (sub)category from the database. The editor shall be able to unpublish a category so that it will not show in the category list for ordinary users. The editor shall be able to publish articles (owns, or from the contribution section). The editor shall be able to edit the data of a pre-added article. The editor shall be able to delete an article from the database. The editor shall be able to archive articles that no longer are relevant. He can also, as he publishes an article, set a date for when this article automatic should be marked as archived. Archived articles are not public to ordinary users. The editor shall be able to view all available articles, archived or not, for all categories. The editor shall be able to get a list over all incoming proposals in the article section. The editor shall be able to approve a proposed article, so that it is published under an existing category in the portal. The editor shall be able to delete/deny a proposed article, so that it is deleted from the database. The editor should be able to add logging to a site and view a log overview for the sites in the portal.

Add category: Add subcategory: Edit (sub)category: Delete (sub)category:

Unpublish a category:

Add article:

Edit article description: Delete article: Archive article:

View available articles:

View proposals:

Approve article:

Delete proposals:

Portal logging:

19

4.3.3 Functional requirements summary list

Table 4-1 is a summary of all functional requirements made to the portal application. Ordinary user actor F1 Read article F2 Comment article F3 Rate article F4 Propose article F5 Recommend article F6 Read in the forum F7 Write in the forum F8 Sort articles F9 Search the portal F10 Log in F11 Add category F12 Add subcategory F13 Edit (sub)category F14 Delete (sub)category F15 Unpublish a category F16 Add article F17 Edit article description F18 Delete article F19 Archive article F20 View available articles F21 View proposals F22 Approve article F23 Delete proposals F24 Portal logging

Editor user actor

Table 4-1: Functional requirements summary list

20

4.4 USE CASES

This section presents use cases related to the functional requirements.

4.4.1 Use case for Ordinary user actor

Read article

Comment article

uses Rate article uses

uses

Recommend an article

uses

uses Propose article uses

Ordinary user

uses Read in forum uses uses Write in forum

Sort articles

Search the portal

Figure 4-2: Use case for Ordinary user actor

21

4.4.2 Use case for Editor user actor

Add category

Unpublish a category

Add article

uses

Archive article

extends

uses uses View available articles

extends extends

uses

extends

uses

View proposals

extends

uses Approve porposal uses uses Editor Delete proposals

extends

uses

extends

Log in extends

uses

extends

uses Edit article description

extends

uses

extends

uses Edit (sub)category

extends

uses

extends

uses Add subcategory

extends

Delete article

Delete (sub)category

Portal logging

Figure 4-3: Use case for Editor user actor

For more detail use case descriptions, please read Appendix A.

22

4.5 NON-FUNCTIONAL REQUIREMENTS

This section presents the non-functional requirements, which are related directly to the qualities of the application developed. Open technology: The system shall be implemented with open technologies since the project has no financial support. The system shall require no installation on the client side. The system shall be easy available from everywhere. The system shall be easy to maintain. The system shall be user-friendly. The system shall be extendible. It should not be possible for unauthorized users to delete or modify documents or other data from the system. In addition it should not be possible to access the authorized pages for others than the editor. The system must be able to run under both Microsoft Windows and Unix operating systems. Java shall be used as the programming language because we are quite familiar with Java.

No installation: Availability: Maintainability: User friendly: Modifiability: Security:

Portability:

Programming language:

4.5.1 Non-functional requirements summary list

Table 4-2 is a summary of all non-functional requirements made to the portal application. NF1 NF2 NF3 NF4 NF5 NF6 NF7 NF8 NF9 Open technology No installation Easy available Maintainability Availability Maintainability User friendly Modifiability Security

Table 4-2: Non-functional requirements summary list

23

5 PORTAL ARCHITECTURE
5.1 INTRODUCTION
This section provides a comprehensive architectural overview of the portal application, using a number of different architectural views to show different aspects of the application. It captures and conveys the significant architectural decisions that have been made.

5.2 DEPLOYMENT VIEW

This section describes the physical network configurations.

5.2.1 Overview

Figure 5-1: Deployment view

As the Figure 5-1 illustrates, the application uses a three-tiered architecture; the Client tier, the Web tier and the Data tier. The Client tier The client tier is responsible for presenting data to user and interacting with the user. In the application there is one client, namely the Web client. The Web client consists of HTML pages and computers with web browsers capable of showing these pages. The Web tier The Web tier is used to serve Web clients. The Web tier is responsible for performing all Web-related processing, such as serving HTML and formatting JSP pages for display by browsers. A Web server is used to perform these tasks. The Data tier The Data tier consists of tables with data in a database. This tier is used to store data.

5.2.2 JSP architecture of the portal

JSP are built on top of SUN Servlet technology. JSP are essential an HTML page with s special JSP tags embedded. These JSP tags can contain Java code. The JSP file extension is .jsp rather than .htm or .html. The JSP engine parses the .jsp and creates a Java servlet source file. It then compiles the source file into a class file, this is done the first time and this

24 why the JSP is probably slower the first time it is accessed. Any time after this the special compiled servlet is executed and is therefore returns faster. The architecture is shown in Figure 5-2:

Figure 5-2: JSP architecture

5.2.3 The web server

The web server works like this: - It gets requests/input from the user through the client. - A JSP file at the server processes the request/input. - If it is a request (for example: show me all articles in a specific category), the JSP file gets needed data from the database and creates a page that can be displayed in the client (browser). - If it is input from the user (for example comments to an article), the JSP file puts the data into the database. This is often done like this: There is one file which receives the input data by means of a form. This file sends the input that the user wrote in the form to another file which then puts the data into the database.

Figure 5-3: Web server

25 Here is an example sequence diagram (rate article):

Client Web Server Database

Rate article

Rating form

Rating data

Rating data Rating data

Confirm

Figure 5-4: Sequence diagram for rating article

Here the user has clicked on a link in the portal initiating that (s)he wants to give a rating to an article. The web server receives the request and a jsp file creates a html-page including an input form which is then displayed in the users browser (client). The user types in the rating data in to the form and clicks the OK-button when (s)he is finished. The jsp file at the server gets the input and passes it to another jsp file. This second file puts the rating data into the database, and then assures the user that the transaction went all right by a confirming message (html-page).

5.2.4 JSP application platform

For running and debugging a JSP application, a JSP environment must be firstly set up. Normally JSP environment has three types: Application Server, JSP Engine and JSP Engine, plus Web Server. Since JSP came into being, many famous companies developed different application platforms for it. Here the project chose Apache solution, Apache Tomcat. s Tomcat is a Servlet container and JSP implementation. It may be used stand alone, or in conjunction with several popular web servers and it provides very stable and fast speed as a JSP Engine.

26

5.2.5 JSP Syntax Basics

JSP syntax is fairly straightforward, and can be classified into directives, scripting elements, and standard actions. Directives JSP directives are messages for the JSP engine. They do not directly produce any visible output, but tell the engine what to do with the rest of the JSP page. JSP directives are always enclosed within the <%@ ... %> tag. The two primary directives are page and include. Page Directive Typically, the page directive is found at the top of almost all of your JSP pages. There can be any number of page directives within a JSP page, although the attribute/value pair must be unique. Unrecognised attributes or values result in a translation error. Include Directive The include directive separates the content into more manageable elements, such as those for including a common page header or footer. The page included can be a static HTML page or more JSP content. Declarations JSP declarations define page-level variables to save information or define supporting methods that the rest of a JSP page may need. Declarations are found within the <%! ... %> tag. Always end variable declarations with a semicolon, as any content must be valid Java statements: <%! int i=0; %> Expressions With expressions in JSP, the results of evaluating the expression are converted to a string and directly included within the output page. JSP expressions begin within <%= ... %> tags and do not include semicolons:
<%= fooVariable %> <%= fooBean.getName() %>

Scriptlets JSP code fragments or scriptlets are embedded within <% ... %> tags. This Java code is run when the request is serviced by the JSP page. Any valid Java code can be defined within a scriptlet, and is not limited to one line of source code. For example, the following displays the string "Hello" within H1, H2, H3, and H4 tags, combining the use of expressions and scriptlets:
<% for (int i=1; i<=4; i++) { %> <H<%=i%>>Hello</H<%=i%>> <% } %>

Comments HTML comments can be included in JSP pages, users can view these if they view the page's source. A most useful feature of JSP comments is that they can be used to selectively block out scriptlets or tags from compilation. Thus, they can play a significant role during the debugging and testing process.

27 Figure 5-6 shows the requested JSP code when the page in Figure 5-5 is executed.

The user clicks OK here

Figure 5-5: Adding a category in the portal application

This JSP code is executed when OK is clicked

Figure 5-6: JSP code for category_add_action.jsp

28

5.3 DATA VIEW

This section is a description of the persistent data storage perspective of the portal application.

5.3.1 Design of the database

In figure below the design of the database is shown. The database is a MySql database. It contains the necessary data for the portal application. Table category and table article have an extra attribute named cat_publish and art_archived, respectively. This is used in order to remove tuples without deleting them physically from the database.

subcategory subcat_id: int subcat_name: varchar(50) subcat_publish: bool subcat_pid: int

category cat_id: int cat_name: varchar(50) cat_publish: bool

logg site_name: varchar(50) site_filename: varchar(50) site_count: int

messages message_id: int message_parent_id: integer cat_id: integer topic: varchar(50) author: varchar(50) message: text date_entered: datetime comment com_id: int com_comment: varchar(250) com_author_name:varchar(30) com_author_mail: varchar(50) art_id: int

article art_id: int art_name: varchar(100) art_url: varchar(100) art_description: varchar(250) art_owner: varchar(30) art_owner_mail: varchar(50) art_rating: int art_rating_count: int art_archived: bool art_contribution: bool art_expire_date: date cat_id: int subcat_id: int

29

5.3.2 Database table details

Table 5-1 shows the details of the database. Table category cat_id cat_name cat_publish Table subcategory subcat_id subcat_name subcat_publish subcat_pid Table article art_id art_name art_url art_description art_owner art_owner_mail art_rating art_rating_count art_archived art_contribution art_expire_date cat_id subcat_id Table comment com_id com_comment com_author_name com_author_mail art_id Table logg site_name site_filename site_count Table messages message_id message_parent_id cat_id topic author message date_entered
Table 5-1: Database tables details

int unsigned varchar(50) bool int unsigned varchar(50) bool int unsigned int unsigned varchar(100) varchar(100) varchar(250) varchar(30) varchar(50) int int bool bool date int unsigned int unsigned int unsigned varchar(250) varchar(30) varchar(50) int unsigned varchar(50) varchar(50) int int integer integer varchar(50) varchar(50) text datetime

not null auto_increment primary key

not null auto_increment primary key

not null references category(cat_id) not null auto_increment primary key

not null references category(cat_id) not null references subcategory(subcat_id) not null auto_increment primary key

not null references article(art_id)

auto_increment primary key

30

6 THE PORTAL
This section presents Graphical User Interface (GUI) the portal application. The last section presents a scenario of usage.

6.1 GRAPHICAL USER INTERFACE (GUI) OF THE PORTAL 6.1.1 GUI of the front page
Figure 6-1 presents the front page of the portal. The front page offers these high-level functionalities: (1) Quality assurance support: Give the editor quality assurance support to manage and control the information in the portal. (2) Classification and grouping of information: Categories and subcategories for articles can be grouped. (3) Contribute information: The user can contribute information to the portal. (4) Get information: The user can get information from the portal.
(2) (3) (1)

(4)

(3)

Figure 6-1: The portal GUI front page

31

6.1.2 GUI related to user

Figure 6-2 presents the page when the user clicks on a casual category link in the Kategorier menu, in this case: clicking on the link with the name Ske p prosjekter. This page offers these common functionalities: (5) Read article: The user can read an article by clicking on an article URL (6) Sort articles: The user can sort the view of articles for a chosen category

(6)

(5)

(7)
Figure 6-2: The portal GUI view article

(8)

(7) Comment and rate article: The user can give a personal comment to an article, and rate an article after reading. (8) Read comment: The user can read comment written by other users

32 Figure 6-3 presents the page when the user wants to comment and rate an article, while Figure 6-4 presents the page that other users have written comments for an article.

The user can write comment in this field The user can rate the article from 1 to 6

Figure 6-3: The portal GUI comment and rate article

Figure 6-4: The portal GUI view comment

33 Figure 6-5 presents the page when the user wants to give contributions to the article section. These contributions will be laid in a closed section, and the editor can check these out later and decide if they should be made public.

The user clicks on Anbefale en artikkel to contribute an article

Figure 6-5: The portal GUI recommend article

Figure 6-6 presents the Forum page. This page offers these comment functionalities: (9) Write in the forum: The user can write and reply in the forum. (10) Read in the forum: The user can read contributions from other users in the forum.

(9)

(10)

Figure 6-6: The portal GUI forum

34

6.1.3 GUI related to editor

This section present GUI related to the editor. Figure 6-7 presents the editor front page. This page offers these common functionalities: (11) View proposals: The editor can get a list over all incoming article proposals (12) View available categories: The editor can view all available categories. (13) Add category: The editor can add (main) categories for articles. (14) Add subcategory: The editor can add subcategories for articles. (15) View available articles: The editor can view all available articles, archived or not, for all categories. (16) Add article: The editor can chose to publish articles. (17) Portal logging: The editor can add logging to a site and view a log overview for the sites in the portal.

(11)

(12), (13) and (14)

Figure 6-7: The portal GUI front page of admin.

(17)

(15) and (16)

35

Figure 6-8 presents the page when the editor wants to view all available categories, by clicking on Se alle kategorier. This page offers these functionalities:

(18) Edit (sub)category: The editor shall be able to edit the data of a pre-added category/subcategory. (19) Delete (sub)category: The editor shall be able to delete a (sub)category from the database. (20) Unpublish a category: The editor shall be able to unpublish a category so that it will not be show in the category list for ordinary users.

Figure 6-8: The portal GUI category overview

(18), (19) and (20)

36 Figure 6-9 presents the page when the editor wants to view all available articles for all categories, by clicking on Se alle artikler. This page offers these functionalities: (21) Edit article description: The editor can edit the data of a pre-added article. (22) Delete article: The editor can delete an article from the database. (23) Archive article: The editor can choose to archive articles that no longer are relevant. He can also, as he publishes an article, set a date for when this article automatically should be marked as archived. Archived articles are not public to ordinary users.

Figure 6-9: The portal GUI article overview

(21), (22) and (23)

37 Figure 6-10 present the page when the editor wants to get a list over all incoming proposals in the article section, by clicking on the link Se innkomme forslag. This page offers these functionalities: (24) Delete proposals: The editor can choose to delete/deny a proposed article, so that it is deleted from the database. (25) Approve article: The editor can approve an article so that it displays on the article section.

(24) and (25)

Figure 6-10: The portal GUI proposal overview

Figure 6-11 presents the page portal-logging page: The editor can add logging to a site and view a log overview for the sites in the portal.

Figure 6-11: The portal GUI portal logging

38

6.2 SCENARIO OF USAGE 6.2.1 Inexperienced user

Hans Hansen got a job at Telenor FoU just a few days ago, and now he is up for his first research project. His first task is to write a research proposal where he applies for economic backing for his project. Now that he is new to this job, he has never written this kind of a paper before. But this is clearly an important artifact since he needs the money to get the project started. So he figures that he should seek for help in writing the paper this first time. A fellow colleague of Hansen recommends him to take a look in the internal research portal Research@work. Hansen opens his web-browser and browses into the portal. There he finds several categories for different stages of the research process. He also finds a category named Applying for projects. He clicks on the category, and a list over articles on the subject is displayed. And all the articles have a rating and comments from other researchers. Just what Hansen needs. He clicks on the button Sort highest rating, and the easily picks out the supposed best article in the list. He clicks on the button View comments and a list with comments on the article from other researchers appears. They all find the actual report very good and useful. Hansen thinks that this is promising and clicks on the article link and read the article. After he has read the article he has got a lot of tips and input on how he should write his research proposal paper, and is eager to start. When the artifact is done, Hansen himself writes in a positive comment on the article that helped him getting started. This he does by browsing to the list over the articles on the topic/category, and clicks on the button Add comment at the actual article.

6.2.2 Experienced user

Ole Olsen started working at Telenor FoU 25 years ago, and considers himself as an experienced researcher. He has finished several research projects. But now he has started on a new project and is researching on a technology he is not familiar with, so he needs some input to get deeper in the process. He is also recommended to take a look in the internal portal Research@work. So he does. Just as Hans Hansen he actually gets what he looks for and is very pleased with the portal. Olsen also sees that there is a possibility for recommending articles to the portal. As he is an experienced researcher he has read many good articles, and therefore has many good contributions to the portal. He clicks on the button/link Propose article in the left menu of the portal, and types in the requested data. When he is done he gets a confirm message from the system saying that the editor of the portal will soon see through his proposals and decide if they should be made public in the portal.

39

7 EVALUATION OF THE RESULT

This section provides evaluation of the results achieved in this report. The factors to be evaluated are related to: ??The objectives ??The requirements fulfilments ??The scenario of usage

7.1 OBJECTIVES ACHIEVEMENT

The following objectives were stated in the introduction to this report: Objective 1: Constructing a resource centre to gives researchers access to information and resources related to research work in an industry environment. Objective 2: Constructing a discussion forum to provide knowledge exchange and promote communication and learning among researchers. Objective 3: In the context of knowledge management, constructing an editor tool to give the editor quality assurance support to establish, control and manage the information.

All objectives have its fulfilment through the portal application (as presented in section 6.1.):

Fulfilment of objective 1: The portal consists of web pages with pointers to resources and information related to research work. Researchers can easily access the information by browsing through the portal and select and get desired information. Fulfilment of objective 2: The portal enables knowledge exchange and promotes communication and learning among researchers; this is achieved through the discussion forum where the researchers can post messages, and read contributions from other users. Fulfilment of objective 3: The portal consists of an editor tool for the editor. This is a tool that enable editor to control and manage the information in the portal.

40

7.2 REQUIREMENTS FULFILMENT

The functional requirements are evaluated using a table that shows which functional requirements are implemented. All of the functional requirements that are implemented has been tested through use and found to be working correct. Table 7.1 shows which functional requirements are implemented in the portal application. Status Implemented Implemented Implemented Implemented Implemented Implemented Implemented Implemented Not implemented Implemented Implemented Implemented Implemented Implemented Implemented Implemented Implemented Implemented Implemented Implemented Implemented Implemented Implemented Implemented

Requirements related to user

Requirements related to editor

F1 Read article F2 Comment article F3 Rate article F4 Propose article F5 Recommend article F6 Read in the forum F7 Write in the forum F8 Sort articles F9 Search the portal F10 Log in F11 Add category F12 Add subcategory F13 Edit (sub)category F14 Delete (sub)category F15 Unpublish a category F16 Add article F17 Edit article description F18 Delete article F19 Archive article F20 View available articles F21 View proposals F22 Approve article F23 Delete proposals F24 Portal logging

Table 7-1: Implementation of the functional requirements

All functional requirements are implemented successfully, except F9 Search the portal, this functional requirement is not implemented due to time limit. This functional requirement may be realized at further work by using a third party software component.

41

7.3 EVALUATION OF SCENARIOS

The scenarios of usage presented in section 6.2 demonstrated that the portal application is capable to serve its purpose for both experienced and inexperienced users. However, there are some issues need to mention: Editor can become a bottleneck: Users can give contributions to the portal by sending proposals to editor. The editor can become a bottleneck because many contributions will be laid in the portal waiting for acknowledgement, it a possibility that the editor don have time to check all s t proposals to decide if they should be denied or accepted. Information abundance: Users may be confused of the information abundance in the portal. However, the portal enables classification and grouping of information, which is an attempt to damp the feeling of confusion. Categories in the portal can be divided and grouped into subcategories. Personalization: When users access the portal for the first time, the portal offers common information to all users. Consideration of information, the users may need information related to theirs context. An aspect of information delivery is understanding what the user is trying to accomplish with the content in the application and then delivering the right content in the form best suited to accomplishing that task.

42

8 CONCLUSIONS
8.1 SUMMARY
From the achievements and results presented in this report, we conclude that the project is successful and worthwhile. The Telenor R&D has got a portal application that will aid them in their daily work. The application is evaluated with respect to three factors: the objectives achievement, the requirements fulfilments, and the scenario of usage. All objectives have its fulfilment through the portal application, all main functional requirements are successfully implemented and have been tested through use and found to be working correct, and the scenarios of usage demonstrated that the application is capable to serve its purpose. The prototyping model as experienced in this project, presents a promising alternative to the traditional waterfall model of development. We constructed first a prototype application and involved some researchers in experimental use of the prototype. The prototype is improved and refined into a final application after a number of necessary revisions based on feedback from some researchers who have used the prototype.

8.2 FURTHER WORK

The search engine The searching engine is not implemented in the portal application. A possible solution is implementing a searching engine using a third party software component. Usability testing The portal application has not been exposed for a thorough usability test. A usability test of the portal shall be adopted by involving the user in the experimentation. The human factor The human factor is an importance issue when introducing a new application to employees at Telenor R&D. The portal application is just a tool that will aid the researchers in their daily work. A possible aspect seems to be how to motivate employees to make use of the portal once it is in place when they may not see why its use is necessary. An assessment on making use of the portal shall be adopted, by presenting some scenarios to exemplify how the portal could be used to accomplish a task.

43

9 REFERENCES
[1] Floyd C. (1984) A systematic look at prototyping. In Budde R. (Ed) Approaches to Prototyping. Springer-Verlag, Berlin Website to Telenor Research & Development, About Telenor R&D [Online], Available: http://www.telenor.com/rd/index.shtml Wege, C., Portal Server Technology, 2002, IEEE Internet computing. JSP 1.2 specification Proposed Final Draft. SUN Microsystems, Inc, April 27, 2001. CGI Introduction, CGI Basics [Online], Available: http://hoohoo.ncsa.uiuc.edu/cgi/intro.html PHP Manual The PHP Documentation, PHPbuilder.com[Online], Available: http://www.phpbuilder.com/manual/ jGuru, (2001) JavaServer Pages Fundamentals. JGuru.com [Online], Available: http://developer.java.sun.com/developer/onlineTraining/ Trail: JavaBeans The Java Tutorial, Java.sun.com [HTML Book, Online], Available: http//java.sun.com/docs/books/tutorial/index.html Fundamentals of JavaTM Servlets, Java.sun.com [Online], Available: http://developer.java.sun.com/developer/onlineTraining The Apache Jakarta Project, Jakarta.apache.org [Online], Available: http://jakarta.apache.org/jetspeed/site/index.html Zope Community, Zope.org [Online], Available: http://www.zope.org/ Preece J., Human-Computer Interaction, 1999, Addison Wesley.

[2]

[3] [4] [5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

44

10 GLOSSARY
This section explains the meaning of the most important terms and words that is used in this report. HTML HTML, the Hyper Text Markup Language, is the lingua franca for publishing hypertext on the World Wide Web. It is a non-proprietary format based upon SGML, and can be created and processed by a wide range of tools, from simple plain text editors - you type it in from scratch- to sophisticated WYSIWYG (what you see is what you get) authoring tools. HTML uses tags to structure text into headings, paragraphs, lists, images, hypertext links and various kinds of tags combination. Java technology Java technology is a simple, robust, object-oriented, platform-independent multi-threaded, dynamic general-purpose programming language and environment. It's best for creating applets and applications for the Internet, intranets and any other complex, distributed network. XML technology XML, Extensible Markup Language, is a text-based markup language for data interchange on the Web. As with HTML, it identifies data using tags. But unlike HTML, XML tags identify the data, rather than specifying how to display it. In addition, XML is platform independent. The Java programming language and XML combined complement the portability of both technologies. WML WML, Wireless Markup Language, is a markup language based on XML, and is intended for use in specifying content and user interface for narrowband devices, including cellular phones and pagers. J2EETM J2EE, The Java 2 Platform, Enterprise Edition, defines the standard for developing multi-tier enterprise applications. The J2EE platform manages the infrastructure and supports the Web services to enable development of secure, robust and interoperable business applications. J2SETM J2SE, Java 2 Standard Edition, the most popular model used to develop Enterprise level applications. J2EE is supported by software giants like Sun Microsystems, BEA, Oracle and IBM. JDBCTM Technology JDBCTM Technology is an API that enable invoking SQL commands to create database tables, access the data stored in a table, and create and manage distributed transaction. The J2SETM 1.4 and all versions of the J2EETM platforms provide these APIs. JavaBeans API The JavaBeans API makes it possible to write component software in the Java programming language. Components are self-contained, reusable software units that can be visually

45 composed into composite components, applets, applications, and servlets using visual application builder tools. JavaBean components are known as Beans [8]. Servlet Servlets are pieces of JavaTM source code that add functionality to a web server in a manner similar to the way applets add functionality to a browser. Servlets are designed to support a request/response computing model that is commonly used in web servers. In a request/response model, a client sends a request message to a server and the server responds by sending back a reply message [9]. MySQL MySQL is a database management system. Usability testing Determines whether a system meets a pre-determined, quantifiable level of usability for specific types of user carrying out specific tasks [12]. Waterfall model Waterfall model is a characterization of the software development process as consisting of a number of processes and representations which are produced in an essentially linear fashion [12]. Functional requirements What the system (both human and computer) has to be capable of doing [12].

User interface The totality of surface aspects of a computer system, such as its input and output devices, the information presented to or elicited from the user, feedback presented to the user, the system behavior, its documentation and associated training programmes, and the user s s actions with respect to these aspects [12].

46

11 APPENDIX A USE CASE DESCRIPTIONS

11.1 ORDINARY USER USE CASES
Use case name Summary Ordinary path Read article The user shall be able to click on an article URL, and read the article. 1. The user clicks on a category/subcategory. 2. The user clicks on an article URL 3. The article is opened for reading in another window N/A N/A

Alternate path Exception path

Use case name Summary

Comment article The user shall be able to give a personal comment to the article. Other users can access and read this comment. 1. On the article overview for a (sub)category, the user clicks on the link Comment/rate this article. 2. The user writes his/her comment. 3. The user clicks the OK-button. N/A N/A

Ordinary path

Alternate path Exception path

Use case name Summary

Rate article The user shall be able to rate an article after (s)he has read it. An average rating will then be presented along with the article. 1. On the article overview for a (sub)category, the user clicks on the link Comment/rate this article. 2. The user gives his/her rating. 3. The user clicks the OK-button N/A N/A

Ordinary path

Alternate path Exception path

47

Use case name Summary

Propose article The user shall be able to give contributions to the article section. These contributions will be laid in a closed section, and the editor can check these out later and decide if they should be made public. 1. On the left main menu, the user clicks on the link Recommend article. 2. The user fills out the form. The recommended articles name, URL, etc. 3. The user clicks the OK-button. N/A N/A

Ordinary path

Alternate path Exception path

Use case name Summary

Recommend article The user shall be able to recommend an article to a college by e-mail after (s)he has read it. 1. On the article overview for a (sub)category, the user clicks on the link Comment/rate this article. 2. Then the user clicks on the link Recommend this article to a colleague by mail 3. A mail is being created by the users default mail program. 4. The user writes the colleagues mail address and sends the mail (this is being done in the default mail program) N/A N/A

Ordinary path

Alternate path Exception path

Use case name Summary

Read in the forum The user shall be able to read contributions from other users in the forum. 1. The user clicks on the link Forum in the main menu at the top of the site. 2. Then the user clicks on a topic/thread (s)he would like to read more closely. N/A N/A

Ordinary path

Alternate path Exception path

48 Use case name Summary Ordinary path Write in the forum The user shall be able to write/reply in the forum. 1. The user clicks on the link Forum in the main menu at the top of the site. 2. The user clicks on the button Create thread. 3. Then the user writes in the name of the thread and finally his/her message. 1. The user clicks on the link Forum in the main menu at the top of the site. 2. The user clicks on the topic/thread (s)he would like to respond to. 3. The user clicks on the button Reply. 4. The user writes in the name/subject of his/her reply and finally the reply. N/A

Alternate path

Exception path

Use case name Summary

Sort articles The user shall be able to sort the view of articles for a chosen category. 1. The user clicks on a category in the left menu. 2. To re-sort the articles that appear for the chosen category, the user clicks on the sort-links at the top of the list (Newest first, Highest rating). N/A N/A

Ordinary path

Alternate path Exception path

Use case name Summary Ordinary path

Search the portal (NOT IMPLEMENTED) The user shall be able to search the portal for needed data. 1. The user types in a search-word in the search-form in the portal. 2. The user clicks on the button Search. 3. A list over articles/categories that includes the actual searchword is displayed for the user. N/A N/A

Alternate path Exception path

49

11.2 EDITOR USER USE CASES

Use case name Summary Ordinary path Log in The editor must log in before (s)he can get the editor properties. 1. The editor clicks on the link Admin in the main menu at the top of the site. 2. Then the editor types in (correct) username and password. 3. At last (s)he clicks on the button Log in. N/A //After step 3 in the ordinary path. 1. The username and/or the password were incorrect, and the editor must re-type the (correct) username and password.

Alternate path Exception path

Use case name Summary Ordinary path

Add category The editor shall be able to add (main) categories for articles. 1. In the admin-section, the editor clicks on the link Add category on the left menu. 2. The editor types in the category data. 3. The editor clicks the button OK. N/A N/A

Alternate path Exception path

Use case name Summary

Unpublish a category The editor shall be able to unpublish a category so that it will not be show in the category list for ordinary users.

Ordinary path

// Precondition use case: View available categories. 1. On the category overview, the editor clicks on the link/button change N/A N/A

Alternate path Exception path

50 Use case name Summary Ordinary path Add article The editor shall be able to publish articles. 1. The editor clicks on the link Add article on the left menu. 2. The editor types in the article data. 3. The editor clicks the button OK. N/A N/A

Alternate path Exception path

Use case name Summary

Archive article The editor shall be able to archive articles that no longer are relevant. He can also, as he publishes an article, set a date for when this article automatically should be marked as archived. Archived articles are not public to ordinary users. // Precondition use case: View all available articles. 1. At the article overview, the editor clicks on the link/button change. // Precondition use case: Add article (to step 2). 1. When the editor types in the article data, (s)he sets an expire date for the article. When this date arrives, the article automatically gets archived. 2. The editor clicks the button OK. N/A

Ordinary path

Alternate path

Exception path

Use case name Summary

View available articles The editor shall be able to view all available articles, archived or not, for all categories. 1. The editor clicks on the link View all articles on the left menu. N/A N/A

Ordinary path

Alternate path Exception path

51 Use case name Summary View proposals The editor shall be able to get a list over all incoming proposals in the article section. 1. The editor clicks on the link View proposals on the left menu. N/A N/A

Ordinary path

Alternate path Exception path

Use case name Summary

Approve article The editor shall be able to approve a proposed article, so that it is published under an existing category in the portal. // Precondition use case: View proposals. 1. The editor clicks on the link/button Approve/deny. 2. The editor checks the info on the suggested article, and changes any of it if needed. 3. The editor clicks on the button OK (approve). N/A N/A

Ordinary path

Alternate path Exception path

Use case name Summary

Delete proposals The editor shall be able to delete/deny a proposed article, so that it is deleted from the database. // Precondition use case: View proposals. 1. The editor clicks on the link/button Approve/deny. 2. The editor clicks on the button Delete. N/A N/A

Ordinary path

Alternate path Exception path

Use case name Summary Ordinary path

Add subcategory The editor shall be able to add subcategories for articles. 1. In the admin-section, the editor clicks on the link Add subcategory on the left menu. 2. The editor types in the subcategory data. 3. The editor clicks the button OK. N/A N/A

Alternate path Exception path

52 Use case name Summary Ordinary path Edit article description The editor shall be able to edit the data of a pre-added article. // Precondition use case: View all articles. 1. In the article overview, the editor clicks on the link/button edit. 2. The editor edits the article data. 3. The editor clicks on the button OK. N/A N/A

Alternate path Exception path

Use case name Summary

Edit (sub)category The editor shall be able to edit the data of a pre-added category/subcategory. // Precondition use case: View all categories. 1. 1.In the category overview, the editor clicks on the link/button edit. 2. The editor edits the (sub)category data. 3. The editor clicks on the button OK. N/A N/A

Ordinary path

Alternate path Exception path

Use case name Summary Ordinary path

Delete article The editor shall be able to delete an article from the database. // Precondition use case: View all articles. 1. In the article overview the editor clicks on the link/button delete for the chosen article. 2. To confirm the delete the editor clicks on the button Yes. N/A N/A

Alternate path Exception path

Use case name Summary Ordinary path

Delete (sub)category The editor shall be able to delete a (sub)category from the database. // Precondition use case: View all categories. 1. In the category overview, the editor clicks on the link/button delete for the chosen (sub)category. 2. To confirm the delete the editor clicks on the button Yes. N/A N/A

Alternate path Exception path

53

Use case name Summary

Portal logging The editor should be able to add logging to a site and view a log overview for the sites in the portal. 1. In the admin section the editor clicks on the link/button Add new log in the left menu. 2. The editor types in the name and the filename of the site that is to be logged. 3. The editor adds the necessary code to the actual file (instructions are available). 4. Then the editor clicks on the link/button Log overview in the left menu. 5. A log overview is displayed for the editor. N/A N/A

Ordinary path

Alternate path Exception path

54

12 APPENDIX B CUSTOMER FEEDBACK

Fra Babak: - Jeg syns vi burde kunne editere elementer som allerede er lagt inn. For eksempel det kan vre ndvendig endre navn p en kategori eller en artikkel. Kan dette la seg gjre? - Nr det gjelder on/off p view sidene til kategorier og artikler kan det vre en bedre lsning ha en "update" knapp nede i siden, slik at man kan endre status for s mange elementer man vil og trykke update kun en gang? - Kan det vre en ide bruke ikoner (e.g. terninger) nr det gjelder rating? Gir strre effekt! ogs vise antall ratings. Generelt syns jeg p oversiktsidene er det ndvendig jobbe med utseende/design for gi litt mer informasjon p en mer oversiktlig mte. - Nr det gjelder dato kan det vre en ide ha et allerede innfylt felt (e.g. satt til 01.01.9999) som man kan endre dersom artikkelen skal ha en deadline. Og hvis man endrer deadline kan det vre greit vise deadline p oversiktsiden. - I forum oversikt trenger vi et felt som viser antall meldinger. Ogs en knapp for arkivering av threads. - Er det lett lage en videreinndeling av kategorier? et trestruktur? - Er det mulig slippe logge inn som admin etter frste plogging? Haldor (tlf: 99286854 ) sier: - I diskusjonsforumet hadde det vrt greit om subjektet ble automatisk kopiert og lagt til "Re: " eller lignende nr man svarer p et innlegg. Slik det er n s m man fylle ut subjektfeltet for hnd.

Bodil (tlf: 99286870) sier: - Hei, For det frste, kan dette bli kunnskap/diskusjon/gode art.referanser.... Ellers syns jeg: - Det er for liten skrift p forsiden - Blander engelsk/norsk i overskrifter

et

fint

forum

for

utveksling

av

Flere krav fra Babak m.fl.: - Kan det la seg gjre at vi fr en kontekst-linje som viser hvor man er (over Home og Forum) - Det blir etterhvert ndvendig ha en delete i tillegg til on og off for kategorier og artikler. - Vi trenger en videre inndeling av artikkel. Vi kan begynne med ha et type-felt som man kan skrive inn selv (kanskje med noen predefinerte linjer e.g. call for papers, conference, journal, online bibliography...) som brukeren kan enten velge eller skrive egen typedef. - Skefunksjon? - Det er ogs nskelig kunne reorganisere rekkeflgen p artikler og kategorier. Kategorier kan det vre admin som setter rekkeflgen. - Artikler i hver kategori burde kunne sorteres etter kriterier som best rangert, nyest frst, mest lest, etc. - Vi m ogs snakke om generell logging av systemet, for lage statistikker rundt hva som blir lest etc. - Fildelingsomrde..?