professional report - ben johnson final report (with diagrams).doc · web viewcontent access &...

AccessibleAccessible

Accessible Content Access & Authoringby Ben R. E. Johnson, BSc Computation with

IE, 2002

UNIVERSITY OF MANCHESTER INSTITUTE OF SCIENCE & TECHNOLOGY JKH

1 Abstract

The Accessible Content Access & Authoring project applied Jacobson et al‘s Object-Orientated Software Engineering (OOSE) methodology to produce a web-based system allowing children of upper-primary/secondary school age to create and maintain a page (or pages) on the Internet, using a standard web browser at school and at home. Solving this problem required the development of a system that facilitates the viewing and authoring/editing of server-side structured data (e.g., web page information) by a variety of web-enabled clients.

The project centred around two key design problems: the technical problem of how to provide data storage and retrieval services to a range of web clients with widely differing capabilities and the usability problem of designing a user interface

that allows the young target users to take advantage of these services. Design techniques used to capture and solve these problems included Petrounias’s Non-Functional Requirements (NFR’s) Elicitation & Specification method and Nielsen’s five dimensions of usability.

The resulting ACAA system comprises Active Server Pages (for easily maintainable scripting of application flow logic) and Component Object Model (COM) objects (encapsulating core system data and services) arranged in a 3-tier (‘N-tier’) client-server architecture. The system operates from any standard Internet Information Server (IIS) platform and utilises SQL Server 2000 and XSL ISAPI Filter as the key components of its Data and Presentation layers, respectively.

This project represents a culmination of skills and techniques studied as part of the UMIST BSc Computation degree syllabus, including:

■ Requirements Capture & Modelling (CT318)■ Software Analysis & Design (CT203)■ Emerging Technologies in Information Systems (CT321) ■ Project Management (CT311)■ Distributed Systems & Internet Technology (CT337)

ACCESSIBLE CONTENT ACCESS & AUTHORING CHAPTER 1 / PAGE 1

1

■ Human Computer Interaction (CT204)■ Network and Open Systems (CT211) ■ Database Theory (CT213)


2 AcknowledgementsThe author would like to express his thanks to the supervisor of this project, Dr Donal Flynn, who was responsible for ensuring a practical outlook was maintained throughout its progress; his assistance was invaluable in driving analysis of the problem area beyond theoretically musing and into consideration of real world issues that would affect ACAA were it deployed as described.

Warm thanks are also due to the author’s family; four younger brothers, one little sister and a mother from the teaching profession have ensured no shortage of eager interviewees while seeking a more realistic outlook on the problem. Their assistance was gratefully (and at times grudgingly, in the case of more demanding requirements!) received.


2

3 Table of Contents1 ABSTRACT.............................................................................................................................................1

2 ACKNOWLEDGEMENTS....................................................................................................................2

3 TABLE OF CONTENTS........................................................................................................................3

4 REPORT INTRODUCTION..................................................................................................................4

5 PROBLEM BACKGROUND.................................................................................................................5

6 PROJECT PLANNING & APPROACH...............................................................................................6

6.1 DESIGN METHODOLOGY & RATIONALE.............................................................................................6

7 REQUIREMENTS SPECIFICATION...................................................................................................9

7.1 OBJECT INVENTORY..........................................................................................................................97.2 STAKEHOLDERS & ASSOCIATED OUTLINE REQUIREMENTS...............................................................107.3 USE-CASE MODEL...........................................................................................................................117.4 ENVIRONMENTAL FACTORS & CONSTRAINTS (NFR’S).....................................................................13

8 ANALYSIS & DESIGN........................................................................................................................14

8.1 IDEAL-OBJECT MODEL....................................................................................................................148.2 SYSTEM ARCHITECTURE DESIGN & RATIONALE...............................................................................188.3 REAL-OBJECT MODEL.....................................................................................................................20

9 IMPLEMENTATION & TESTING.....................................................................................................22

9.1 IMPLEMENTATION APPROACH..........................................................................................................229.2 ISSUES ENCOUNTERED & THEIR RESOLUTION..................................................................................239.3 TESTING STRATEGY & RESULTS......................................................................................................24

10 EVALUATION & CONCLUSIONS....................................................................................................25

10.1 KEY SYSTEM FEATURES & BENEFITS...............................................................................................2610.2 FURTHER WORK..............................................................................................................................27

11 REFERENCES......................................................................................................................................28

12 BIBLIOGRAPHY.................................................................................................................................30

13 APPENDICES.......................................................................................................................................31

A USE CASE DESCRIPTIONS.................................................................................................................32B IDEAL-OBJECT MODELS FOR INDIVIDUAL USE CASES.......................................................................36C TECHNOLOGY DESIGN RATIONALE..................................................................................................37D Requirements Traceability...............................................................................................................41

List of Figures FIGURE 4-A - CORRELATION BETWEEN REPORT CHAPTERS & PHASES OF THE WATERFALL MODEL...4 FIGURE 7-A - USE-CASE MODEL FOR ACAA........................................................................................12 FIGURE 8-A - ENTITY-RELATIONSHIP DIAGRAM FOR ACAA..................................................................15 FIGURE 8-B - IDEAL-OBJECT MODEL FOR ACAA.................................................................................17 Figure 8-C - Real-Object Model for ACAA.......................................................................................21


3

Chapter 10 Evaluation & Conclusions

Chapter 9 Implementation

& TestingImplem

entation & Testing

Chapter 8 Analysis &

Design

Chapter 7Requirements Specification

Chapter 6 Project

Planning & Approach

Chapter 5 Problem

Background

Evaluation

Implementation

DesignRequirements

Planning

Brief

ACAA

4 Report IntroductionThis chapter presents an introduction to the layout of this report.

Each chapter of this report features an introduction explaining its contribution toward the project. Starting from the current point in the report, Chapters 5 through to 10 each correspond to a phase in the standard software development life cycle (‘waterfall’) model, as illustrated by Figure 4-A below and discussed in greater detail in Chapter 6, “Project Planning & Approach”:


4

Figure 4-A - Correlation Between Report Chapters & Phases of the Waterfall Model

Chapter 11 presents a list of references for the report, giving full details of every publication and online resource referenced in the main text (e.g., “[Jacobson et al, 1996]” ), while chapters 12 and 13 present the report bibliography and appendices, respectively.


5 Problem BackgroundThis chapter describes the problem scenario that ACAA aims to solve.

Accessible Content Access & Authoring aims to provide schoolchildren with the means to single-handedly create and maintain a web presence that would otherwise be out of their reach due to the level of technological skill required to author and publish material on a server. Even if existing web development tools such as FrontPage are used, the barrier to entry for young children is too high, due to the time and skills required to use such solutions.

An alternative might be thought to lie with one of the many personal web page hosting providers, such as GeoCities or Tripod. Investigation into the support for younger users provided by these services reveals most only go as far as offering web development tutorials. Sites such as Webmonkey For Kids, Web Genies and Classroom Tripod make an admirable effort to teach skills such as HTML to school kids. Ultimately, however, aspiring young webmasters would need a teacher’s assistance to complete such a course and upload their site to a web server, which is a requirement that ACAA seeks to avoid.

A few combination web page authoring/hosting services exist that take support for children a step further by providing a simple step by step interface for creating basic web pages, meaning no technical skills – such as Hypertext Mark-up Language (HTML) – are required. Examples include AlphaDesk FunPages and MatMice, which both do a good job of guiding the user through a simple content creation and style selection process. However, the current range of services of this type suffers from the following problems:

■ Page content is entered using a web form (i.e., a series of fields for items such as page title, author, etc.), making it difficult for the child to visualise their page as they write

■ Once the page design has been chosen, it often cannot be changed. This is due to pages being created as static HTML documents containing content mixed with presentation information such as layout tables, text colour, etc

■ Some services – including AlphaDesk – do not allow page content to be changed (without editing the raw HTML code) once they have been generated

■ Advanced web page features (e.g., animated page elements) would only be possible by manually editing the page HTML and inserting special code; writing this code (particularly code that works in all web browsers) would be beyond children of the target age

■ In order to edit, link to or insert an image into a particular web page, the young webmaster has to know the correct URL / filename


5

ACAA aims to fill the gap in this range of options, by providing the young webmaster with an easy to use page authoring/editing interface that does not suffer the above problems and which can be used by the child at home and at school to keep their web site up-to-date, regardless of their means of web access.


6 Project Planning & ApproachThis chapter presents a literary review of systems engineering techniques to be applied during the course of this project, ranging from Flynn’s web development framework and Jacobson’s OOSE software design methodology to Petrounias’s NFR Capture & Specification method and Nielsen’s Usability Assessment Criteria.

6.1 Design Methodology & RationaleFlynn’s “Method for Web Site Development” [Flynn, 2002] provides a guideline framework for web development, based around the ubiquitous software development life cycle (‘waterfall’ model) but tailored to the context of developing web applications. It presents a sensible set of recommended activities, such as stakeholder-orientated requirements gathering, without placing unnecessary constraint on design technique or implementation technology. This project will adhere to this framework, but will also employ a range of additional techniques and methodologies, as follows.

The underlying functional requirements of ACAA are relatively simple; we need a container that allows us to put information in and get it back again later. This is the “Content Access & Authoring” part of the project title; ‘Accessible’ is where the challenge lies. In the problem context, accessibility refers to two design problems:

■ Technical – How do we ensure that as wide a range of client devices - and therefore users - as possible can make use of ACAA’s services?

■ Usability – Having made ACAA’s services available, how do we ensure they are ‘user-friendly’ enough literally for a child to use them?

Technical ProblemThe outline requirements state that the system must provide information storage and retrieval services to a wide range of web client devices. Some of these may support powerful client-side processing features and the latest mark-up standards such as HTML 4 and Cascading Style Sheets; some won’t even have graphical capabilities, e.g., mobile devices. Some may not even be under human control; the school may have other systems that wish to interact with ACAA automatically.

Each client type will need to interact with the system using different interface technologies.1 At the same time, the function of the system - once communication

1 Standard Internet communication protocols - Transfer Control Protocol/Internet Protocol (TCP/IP) for transport and Hypertext Transfer Protocol (HTTP) for message formatting – establish a means of basic communication between client and server that is used by all web clients when accessing a web site [Marshall]. These protocols have remained almost unchanged since their inception. HTTP, for example, was proposed by an Internet Engineering Task Force (IETF) working group in 1996 [Berners-Lee et al, 1996] and standardised as HTTP 1.1 in 1997; only minor revisions have been made since then and the World Wide Web Consortium (W3C) standards body has declared the standard to be stable.


6

and presentation issues have been handled – does not change. Users need to store and retrieve the same information regardless of their means of access, so the underlying processes remain the same.

To achieve this, it is likely that the system will require a layered or component-based architecture design, where the presentation logic is kept separate from processes common to all clients, such as data access and security rules. In some cases it may even be possible to take advantage of advanced functionality in newer clients and have them handle presentation processing themselves in order to relieve strain on the server [Microsoft Corp., 2001].

If we are to divide the system into more than one distinct component in this way, it is vital that the responsibilities of each component are modelled closely before implementation starts. I have experience with previous client-server projects (namely the cdXP system for British Telecommunications PLC) where poor component design (or lack thereof!) caused problems later in the project; it was discovered that data encapsulated in the presentation layer of the system was needed elsewhere, but was difficult to access because the need had not been anticipated during the inadequate design phase.

The design methodology selected to prevent similar problems is Jacobson’s OOSE approach, as described in “Object-Orientated Software Engineering: A Use Case Driven Approach” [Jacobson et al, 1992]. Jacobson – co-author of the Unified Modelling Language standard [Booch et al, 1998] – demonstrates in his text how effectively the functional requirements of a system can be captured through simple descriptions of the desired interactions between user and system (use cases).

Using these use-cases as the basis for the rest of the design process, Jacobson then illustrates how entity, control and interface objects can be found (Ideal-Object Model), mapped to real-world implementation technologies (Real-Object Model) and finally described in detail through Class / Interaction Diagrams. The individual steps of this process are described in greater detail in individual chapter introductions.

Usability ProblemUsability may be defined as “the quality of a user’s experience when interacting with a product or system” [Nielsen, 2001]. If the ACAA system successfully managed to conquer the discrepancies of every client type in popular use, but failed to meet its goal of being simple enough for a child to use, it would be useless as a real-world application. Therefore, ACAA must aim to excel in the following dimensions of usability, according to Nielsen:

In order to represent the displayable web content itself, however, a mark-up language such as Hypertext Mark-up Language (HTML), Wireless Mark-up Language (WML) or eXtensible Mark-up Language (XML) is needed. Unlikely TCP/IP and HTTP, however, these standards have undergone constant revision by the W3C in order to keep up with technological change and pressure from software vendors such as Microsoft and Netscape to integrate new functionality, such as increased control over the presentation of content on the user’s machine, into the specification.

Different client types offer varying support for mark-up languages and their versions, as well as exhibiting often radically different interpretation of the standards. For example, in the case of the two most popular web clients in current use, Microsoft Internet Explorer 5.x and Netscape Communicator 4.x browsers for the PC [EWS] , both support HTML 4, JavaScript 1.2 and CSS 1.0 with widely different interpretation and maturity, with IE5+ additionally supporting XML 1.0 and eXtensible Stylesheet Language (XSL/XSLT). This creates a nightmare spectrum of interface responsibilities for web applications such as ACAA.


■ Ease of Learning – How fast can a user who has never seen the user interface before learn it sufficiently well to accomplish basic tasks?

■ Efficiency of Use – Once an experienced user has learned to use the system, how fast can he or she accomplish tasks?

■ Memorability – If a user has used the system at some earlier date, can he or she remember enough to use it more effectively next time (or does the user have to start over again learning everything every time)?

■ Error Frequency & Severity – How often do users make errors while using the system, how serious are these errors, and how easy is it to recover from a user error?

■ Subjective Satisfaction – How much does the user actually LIKE using the system?

Nielsen’s study of web usability for children [Nielsen, 2002] and UMIST researcher Cassaigne’s techniques for ensuring web usability [Cassaigne, 1999] will be considered and applied during the user interface design process in order to maximise these usability measurements.

Some usability aspects cannot be ensured through simple user interface design, however. A key finding of Nielsen’s study was the lack of patience held by younger users; unfortunately, no amount of graphics pruning and hand-crafted HTML code can alleviate the problem of an under-performing database on the server. A step toward ensuring this situation does not arise is to include a ‘non-functional’ requirement for pages to display quickly. But how quick is quick?

UMIST researcher Petrounias’s methodology for the elicitation and specification of Non-Functional Requirement (NFR’s) [Petrounias, 2001] provides a formal means of gathering and representing environmental factors and constraints that can be traced and evaluated in the finished system. This project will use this methodology to create an NFR Repository (section 7.4) containing quantitative functional constraints such as “content pages must load in under 10 seconds”.


7 Requirements SpecificationThis chapter defines the behaviour and characteristics required of the finished ACAA system. It does this by considering the stakeholders expected to interact with the system (section 7.2), then building a Use-Case Model of typical interactions between these users and the system (7.3). From this we build a comprehensive picture of the ACAA’s responsibilities. Section 7.4 completes this picture by building a Non-Functional Requirements repository, containing measurable behavioural constraints the completed system is expected to adhere to, e.g., performance requirements.

7.1 Object InventoryThe following presents an inventory of real-world objects relevant to the ACAA problem. Its main purpose is a glossary for the problem domain, to clarify the meaning of references used during the course of this project.

■ Client - A web-enabled device such as a web browser or WAP phone that is capable of requesting and viewing web pages

■ Content Item – Content on an ACAA web site, e.g., a document or image■ Document - A content item that contains modifiable text information, i.e. a web

page (but note that a document may be displayed as several pages on some clients)

■ Group Web – A collection of ACAA web sites under the control of one or more group web administrators

■ Group Web Administrator – A system user who administrates a particular group web and therefore has elevated privileges within that web

■ Home Page - The default page displayed when accessing an ACAA web site■ School - Educational institution (typically Primary/Secondary level) that makes

use of the ACAA system and is responsible for one or more group webs■ School Web Site – Special ACAA web site representing the school itself■ System User – A person who owns an ACAA web site and is therefore registered

on the system, complete with username and password■ Visitor – A person requesting ACAA services, who may or may not be a system

user■ Web Site - A collection of content items associated with a particular user■ Web Site Owner - The single system user associated with an ACAA web site.


7

7.2 Stakeholders & Associated Outline RequirementsACAA’s stakeholders are those groups of people who will either interact with ACAA directly, or who will be affected significantly by it in some way. By ‘groups’, we refer to some role that real people play at some time; it is important to note that a real person may switch between different roles according to how they interact with the system.

The following presents a list of identified stakeholders - each classified as Primary, Secondary or Tertiary according to how directly they interact with, or are affected by, the system – and their outline requirements of the system.

1 Group Web Administrator (Primary/Tertiary)Responsible for keeping the school web site up to date, performing standard ACAA maintenance duties and administrating individual user web sites as necessary. Would typically be a normal member of teaching staff, who has a reasonably competent understanding of PC’s and typical Windows applications such as word processing packages and web browsers. May also have some experience with more complicated concepts such as URL formation and file management; possibly even basic knowledge of HTML authoring.

1a) Create and delete user web sites and associated user accounts1b) Export the information from a user’s web site so it can be used in another

system1c) List web sites in the Group Web and administrate any one as if they were the

owner

2 Web Site Owner (Primary)Typically pupil users in 9-16 age group wishing to create and maintain web site content. Normally familiar with basic Windows-based PC usage, including mouse, keyboard and basic applications such as a web browser. Often impatient, so need pages to display quickly and be kept up to date with progress. Also likely to run into difficulties, so need consistent and obvious means of accessing help specific to their current task.

Unlikely be confident with directory structures and server paths, so should be able reference other web sites and content on own web site without needing to know physical location. Very unlikely to have advanced knowledge such as writing HTML code.

2a) Create and edit document content items on their web site2b) Rename, copy and delete content items on their web site2c) Customise the appearance of their web site (e.g., colour scheme)2d) Enable other people to visit their web site, e.g., by sharing an URL


3 Visitor (Secondary)Person wishing to view web site content. Examples include students visiting friends’ / their own web site from a web browser at school, or a casual surfer visiting the main school web site.

3a) View or print a web page from an ACAA web site3b) Register themselves as system users in order to set up an ACAA web site


7.3 Use-Case Model“[Use-cases] capture an information system’s functional requirements. A use-case model defines a system through a set of use cases” [Jacobson et al, 1995]

A use case describes a typical user experience interacting with the system; it doesn’t attempt to account for every route through the system, nor does it try to anticipate every exception that may occur during the course of an interaction. Instead it models the expected behaviour of the system through example. Figure 7-B, over the page, illustrates a range of typical use cases, derived from the outline requirements.

Also shown on the model are system stakeholders, with arrows to illustrate communication with the use cases they are expected to wish to perform. Note also the inter-relationships between some use cases. To reduce the complexity of use case descriptions, it is possible to extract a set of steps common to several use cases and make it into a separate case that is ‘used’ by the cases that need it. Furthermore, a set of steps that are specific to one use case, but considered optional, may also be extracted to a separate use case, which is said to ‘extend’ the original.

Having listed the set of key use cases for ACAA, the next task is to describe each case in more detail, to clarify the scenario it refers to and roughly break down the steps involved in its execution, from the user’s perspective. Appendix A presents the list of descriptions for all use-cases in full; for illustration, the description for the use case ‘Identification’ is reproduced below:

IdentificationUser Goal: Provide and prove their identity

A User tries to perform an operation that has restricted accessB System checks whether user’s identity has already been obtained and confirmedC If not, system prompts user to enter their username and password; user providesD System checks username is valid and the password is correct; if not, user is re-

promptedE With the user’s identity confirmed, system checks whether they have permission

to perform the operationF If so, user is permitted to continue with operation, otherwise an error is shown

The combination of the complete set of use case descriptions like the one above and the Use-Case Model over the page gives us a comprehensive picture of ACAA’s responsibilities and how it is expected to behave in key scenarios. This functional specification model will form the basis of our requirements analysis in chapter 8.


Figure 7-B - Use-Case Model for ACAA


Identification

Specifying New Item Name

Choosing Content Item

Choosing Web Site

Creating Home Page

Saving Doc Changes

Editing Doc

Registering New User

Viewing Content Item

Administrating Group Web

Deleting User Web Site

Getting Help

Group Web Administrator

Web Site Owner /

Group Web Administrator

Visitor

Creating Doc

Copying/Renaming/Deleting Content Item

Administrating Web Site

Changing Web Site Style

Actors

Use Cases

Uses

Extends

Communication

7.4 Environmental Factors & Constraints (NFR’s)Enterprise World

■ Stretched teachers won’t have time to train pupils or themselves, so system must be pick up and go and administration requirements must be minimal

■ Tight budget unlikely to allow for purchasing additional hardware or software ■ Information created by pupils must be easily portable to another system, since

school may change its hardware or the pupil could change schools

System World■ Must be accessible from existing school/home hardware/software, i.e. reasonably

basic desktop PC. Pupil may have latest Pentium PC at home, but a donated relic at his or her primary school, or vice versa. Therefore, system should support at least the following clients: Major PC Browsers:

■ XML-enabled (IE5+, Netscape 6+)■ ‘Version 4’, HTML 4 and DHTML (CSS + JS) compatible (IE4+, Netscape

4.7+)■ HTML (up to version 3) only (older browsers)

■ System should also accommodate extensions to allow additional clients to be supported (e.g., WAP phones, Braille devices)

■ Modifying content using a particular method must not render it inaccessible to other clients

■ Since is academic environment, can assume internet connection. Bandwidth likely to vary considerably, however, depending on the speed of the modem, LAN connection, etc., used

Usage World■ Pupil users in 9-16 age group and are typically familiar with using basic PC

hardware devices, including a mouse and keyboard. They are also likely to have basic experience with Windows-based applications, including a web browser (typically either Netscape or Internet Explorer).

■ Staff are generally fully familiar with PC hardware and have a reasonably competent understanding of typical Windows applications such as word processing packages and web browsers. Some may have had limited experience with more complicated concepts such as URL formation and file management; some may even have basic knowledge of HTML authoring.

Development World■ Implementation explicitly restricted to single developer by UMIST rules■ Developer currently has programming expertise in web development

technologies such as ASP, DHTML and XML, as well as traditional C programming.


■ Available development hardware is modern PC with Windows 2000 (including IIS web server) and LAN internet connection.

■ Minimal funds available for investment in additional hardware / software


8 Analysis & DesignChapter 7 provided us with a detailed specification of the function and behavioural characteristics ACAA is expected to exhibit. In this chapter we will be continuing Jacobson’s method and constructing a conceptual model of the objects involved in the Use-Case Model (section 8.1), then applying a detailed Design Rationale method to decide how these objects can be realised into software (8.2). We will then be using Jacobson’s Real-Object Model (8.3) to lay out a detailed blue print for our system, ready for implementation.

8.1 Ideal-Object ModelIdeal design is concerned with developing a “structure for the information system that is robust when faced with change” [Jacobson et al, 1996]; this structure is then represented using the Ideal-Object model. The model disregards implementation issues such as the object implementation technology and its recommended practices, code optimisation and the practical organisation of system elements. Instead it identifies the core conceptual components of the system and how they interact.

Three types of object are permitted to appear in the Jacobson’s model:

■ Entity objects – Representing real-world ‘things’ of interest to the system■ Interface objects – Provide interaction with the system’s environment, e.g.,

users■ Control objects – Co-ordinate use case specific behaviour

The purpose of distinguishing between these object types is to increase the system’s adaptability to change. For example, changes to the user-interface of a system correctly composed of the above object types will typically only require modification of one or more Interface objects, with no changes to the rest of the system. Clearly this is vitally important in the case of ACAA, which is required to provide interfaces for a wide and constantly changing range of client devices.

Entity-Relationship ModelThe Entity-Relationship model, first proposed in 1976 by Peter Chen, is more usually used as a design step during the development of functional database-orientated systems based on Codd’s Relational Data Model (1970). However, it is in principle an implementation-independent tool that can be useful in defining the data responsibilities of the system, even if the identified entities do not correspond directly to Entity objects in the Ideal-Object model.


8

In the context of the E-R model, an entity is defined as a real-world (i.e., has an existence independent of the system) object (tangible or intangible) about which we are interested in storing information [Layzell]. In addition to showing these entities, the model shows the relationships between entities and the cardinality of those relationships (e.g., one-to-many, many-to-many), as well as key information to be stored for each entity.

Figure 7-B shows the E-R model produced for the ACAA problem domain, produced in accordance with the modelling guidelines presented in Dawson, 1999. It is worth noting that the while the E-R model identifies around 10 entities, two are so-called ‘weak’ entities that do not have true existence outside the system and five are ‘children’ of other entities, which may or may not require a separate existence from their parent in object terms. Aside from these details, we arrive at a list of three core entities: User, Web Site and Content Item.


Figure 8-C - Entity-Relationship Diagram for ACAA


has(0,N)

has(1,N)

held_by(1,1)

held_by(1,1)

admins(1,1)

admin_by(1,N)

owns(1,1)

owned_by(1,1)

contains(1,N)

part_of(1,1)

refs(1,1)

Default style for(0,1)

ref_by(0,N)

refs(1,1)

contains(0,N)

in(1,1)

User

Web Owner Administrator

User Web Site

Admin Role

Content Item

Style

Content Reference

Multimedia Item

Doc

Username

Password

Last modifiedDate Created

Last modified

Date Created

Content ID

Binary data

Type

Name

Expertise-level

D.O.B.

Markup text

Use Case Ideal-Object ModelsWith a possible list of Entity objects in mind, the next step is to model the set of objects needed to perform each of the use cases in section 7.3, using Entity objects to store and process data related to an item, Interface objects to interact with the environment (i.e., the user in this case) and Control objects to handle the use case’s flow logic. The resulting set of models, one for each use case, is presented in Appendix B.

Integrated Ideal-Object ModelBy integrating the set of models produced in the previous section, we build a complete picture of the list of objects needed to make up the system and the responsibilities that each object has, in order to make the system work. This stage gives rise to noticing any problems with certain objects being overlaid with too many responsibilities, or opportunities for adding additional objects or merging existing ones.

After several iterations of this process of refinement and cross-referencing with individual use cases, we do indeed arrive at a list of Entity objects corresponding to the main three identified during E-R modelling. In addition, we find a Control object for each of the use-cases - since there is little duplication between descriptions – plus a single Interface object, ‘UI’, which is to handle interaction with the user. The integrated model can be seen in Figure 8-D on the next page; a description of the responsibilities for each object in the model follows:

Ideal-Object DescriptionsEntity Objects

■ User – Provides information (including username/password) and functionality relating to an registered system user

■ Web Site – Represents a web site belonging to a registered user, storing information such as colour scheme information and providing access to its Content Item child objects

■ Content Item – Represents a viewable content item (be it a document, an image, etc.) on a registered user’s web site. Provides read and write access to content information

Interface Objects■ UI – Handles all communication with the user, taking care of presenting

information in a format tailored to the client type, and making available details about the current user

Control Objects■ ViewingContentItem – Responsible for allowing users to view content

information, tailored to their client type, by requesting the associated Content ID


■ GettingHelp – Responsible for displaying help text to user relevant to their current task

■ EditingDoc – Responsible for presenting user with the editing interface for a specified content item, tailored to the their client type, and allowing changes to be saved

■ And so forth …


Figure 8-D - Ideal-Object Model for ACAA


cons

ists

Of [

0..N

]

Con

tent

Item

s

cons

ists

Of [

1..1

]

Ow

ner

cons

ists

Of [

0..1

]

Aut

hent

icat

ed U

ser

Use

-Cas

e H

andl

ers

EditingDoc

RegisteringNewUser

ViewingContentItem

AdministratingGroupWeb

DeletingUserWebSite

GettingHelp

User

CreatingDoc

CopyingRenamingDeleting ContentItem

AdministratingWebSite

ChangingWebSiteStyle

UI

User

Content Item

Web Site

8.2 System Architecture Design & RationaleAppendix C models the detailed set of step-by-step design decisions that led to the choice of implementation technologies to be used in ACAA, using the ‘Reasoning Loop’ technique for design rationale (DR) as described in Petrounias, 2000. For example, well researched arguments for and against using a Java-based solution are evaluated in the context of the previously stated functional and non-functional requirements. The design rationale concludes with the following list:

C1 Implement ACAA using ASP + COM programming technologyC2 Use Microsoft SQL Server 2000 for handling user dataC3 Use XML for content storage and representationC4 Transform XML on server-side via XSL ISAPI FilterC5 Use Microsoft Internet Information Server (IIS) 5 on Windows 2000

Regarding the choice (C1) of Active Server Pages (with COM objects) over JavaServer Pages:

“[Active Server Pages] and [JavaServer Pages] deliver similar functionality. They both use component objects, tags to allow embedded code in an HTML page, session tracking, and database interaction. ASP uses ActiveX components, while JSP uses JavaBeans as the component architecture. Both also have their strengths and weaknesses. One edge ASP seemingly has over JSP is a gentler learning curve. .. While the fact that Java is object-oriented is largely responsible for the power of the language, it also raises the level of its complexity.”

The above quote from Eden et al‘s “Introducing JavaServer Pages” (2000) highlights the surface architectural similarity between the ASP and JSP platforms. Much of the literature available, excluding biased reviews from both vendors, emphasises the similarity between the two technologies rather than the differences; performance and features are much the same. For this reason, the choice of ASP over JSP came down more to personal preference for the simplified development experience offered by ASP’s type-less JScript implementation than serious deficiency in either technology.

Having identified ASP and COM as our main technologies, we can begin to describe ACAA’s architecture in real implementation terms. It was discussed way back in section 6.1 the apparent need for a layered architecture in order to separate presentation issues from the main application processing. In his article “Application Architecture: An N-Tier Approach”, Chartier identifies benefits that this kind of architecture can offer as including simplified business logic, reducing coupling between objects in separate layers (which helps to reduce the impact of change on the system) and the ability to re-use existing components as system layers, as is the case with our use of the XSL ISAPI Filter to handle the majority of ACAA’s presentation layer.

Having a presentation layer handle all communication with the user also allows us to enforce strict user interface policies, such as a uniformly located “Help” link and


consistent page appearance, as well as allowing changes and new functionality to be added to all pages generated by the system, simply by modifying a central component [Howlett & Dunmall]. This is something that simply is not possible in a system where components can write directly to the display. As discussed in the Design Rationale, it is also possible in some cases to reduce strain on the server by offloading presentation processing to client’s that support advanced functionality such as XSL transformations.

These arguments for the benefits of a presentation layer also apply to other layers we chose to include in the system. In total, ACAA will make use of three application layers (the so-called n-tier client-server approach):

■ Presentation Layer – Handles interaction with the user, ensures consistent and centrally controllable presentation of information through out the system

■ Business Logic Layer – Handles the ‘value-added’ logic of the system, i.e., use-case specific behaviour, information logic, application rules and policies, etc.

■ Data Access Layer – Provides an abstraction of the means of data storage

For example, by requiring data access throughout ACAA to be performed via the Data Access Layer, we are free to change to storage format of data, the location in which it is stored, or even port all content information stored in files into a database, all without affecting the other layers of the system. Suitable convinced that n-tier architecture is flavour of the month, we will now consider how to realise the objects in the Ideal-Object Model into ASP scripting/COM objects and in what layer of the application each should reside.


8.3 Real-Object ModelThe Real-Object Model is the means we use to express the realisation of the conceptual objects in the Ideal-Object Model to real components in our chosen ASP/COM implementation environment.

Integrated Real-Object ModelThere are no entity, control and interface objects in the Real-Object Model; all objects you see in Figure 8-E over the page represent actual components that will exist in the completed ACAA system. Arrows showing communication between objects reflect real message passing in order to complete the use cases in the Use-Case Model.

A convention to note: Lighter objects represent pre-existing objects belonging to our chosen implementation environment, whereas darker objects mark the components that needed to be implemented from scratch; for example, in the Presentation Layer at the top of the diagram, we can see our UI object from the Ideal-Object model sending messages to the XSL ISAPI Filter (which transforms information for display to the client), which in turn eventually passes it to the ‘Response’ object, which is ASP’s built-in object that sends data to the client.

All dark shaded objects will be implemented as COM objects in the final ACAA system, with the exception of the four ASP scripts, ‘content.asp’, ‘website.asp’, ‘admin.asp’ and ‘help.asp’, which are the implementation of the control objects in the Ideal-Object Model. Note that the number of handlers has dropped from 10 to 4; an ASP script for each use-case would be less practical to manage, so instead handlers have been clustered together according to the main entity they interact with.

Another component of note is the Error object. Developers with experience programming anything beyond the most basic of ASP systems, quickly come to appreciate the value of customisable, informative and intelligent error reporting. Having a dedicated Error object allows ASP scripts to capture detailed information about any errors that occur and to present this information in a manner appropriate to whether the system is being run in a debugging mode or a production environment.


Figure 8-E - Real-Object Model for ACAA


UI

Sess

ion

XSL

ISAP

I Fi

lter

Resp

onse

consistsOf

[1..1]

Requ

est

Pres

entat

ion La

yer

Busin

ess L

ogic

Laye

r

SQL Database

File System Object

MSXML DOMDoc SQL

Server

Data

Acce

ss La

yer

Error U

se-C

ase

Han

dler

s

consistsOf [0..1]

Error Information Handler

content.asp

website.asp

admin.asp

help.asp Gro

up W

eb O

bjec

ts

User

Web Site

Content Item

consistsOf [0..1]

Authenticated User

cons

ists

Of

consistsOf [0..1]

XML document

cons

ists

Of

[1..1] Owner

[0..N] Items

9 Implementation & TestingThis chapter describes the approach taken, techniques employed and issues encountered when implementing the design presented in the Real-Object Model in Chapter 8. The strategy used to test individual components and the overall system is also discussed.

9.1 Implementation ApproachOne of the appeals of text-based technologies such as ASP and XML is the freedom from being tied to a particular development environment that is afforded to developers. There are hundreds of quality text editors available to choose from, offering excellent value for money and an array of timesaving features that support ASP and/or XML coding. Rather then opting for the expense and sluggish performance of a Microsoft IDE, therefore, a straight text editor – UltraEdit 8.0 – was selected for its powerful features such as cross-file search and replace facilities.

The selected strategy was to exploit the componentised nature of the system design and construct it piece by piece, using dummy components where an object relied on other objects that had not yet been created. For example, in the early stages of implementation a dummy UI object simply output all messages it received directly to the display, meaning the output of other components under construction could be monitored in its rawest form. Soon after, however, the UI object was expanded to meet its responsibility to pass output to the XSL ISAPI Filter, not out of necessity, but because a filter could then be applied to output that generated useful debugging information, e.g., “success” if the output matched what was expected.

The implementation plan was identified as follows:

1 Construct basic Error, then UI, then SQL Database objects and test each individually

2 Construct User, WebSite and ContentItem core objects one by one, with integration testing after each is completed and expansion of UI etc objects as and when necessary

3 Create functional ASP use case handlers one by one, with integration testing after each

4 Create HTML mock-ups of page designs5 Construct XSL filters for generating page designs and conduct integration testing

alongside components that generate the output6 Conduct user-perspective integration testing of entire system


9

9.2 Issues Encountered & Their ResolutionHaving conducted testing of the capabilities and behaviour of the various system components ACAA was expected to interface with beforehand (whilst constructing arguments for the design rationale), implementation went as close to plan as could be expected, with the predictable exception of timescales. The time taken to learn the intricacies of the XSLT standard, the security model employed by SQL Server 2000 and the procedure for capturing events generated by COM components quickly caused implementation to overrun its original 5 week allocated period.

The implementation would have become even further overrun, had the brand new technology ‘Script COM’ not come to light. Script COM allows prototype COM objects to be developed in a fraction of the time required to author a full C / C++ COM object. Script COM objects behave exactly like real COM objects and can be directly replaced with real versions (yielding increased performance) at any time without affecting the rest of the system in any way. Plans to learn COM programming from scratch were shelved, therefore, for Script COM prototypes in the name of curbing spiralling implementation time.

The result was extremely satisfactory; faster than ASP script and offering all the encapsulation benefits of real COM, Script COM objects appeared to carry no noticeable performance penalty during final integration testing. Clearly in a production environment, however, where the user load would be substantially higher, Script COM objects would limit scalability and would need to be replaced with fully compiled COM objects.

Another significant problem encountered when developing using newly released technologies such as XSLT and Script COM was the limited amount of documentation, guidelines, examples and expertise available. Often there was uncertainty as to whether a technology was designed to cope with a particular creative way of using it, or a technology such as Script COM exhibited strange behaviour for no obvious reason, which later turning out to be due to an undocumented bug or incompatibility. This problem seems to be a permanent fixture in the field of web development, due to the prevalence of cutting edge technology.

Finally, the hindsight to include a dedicated Error COM object reaped dividends in a system reliant on so many components. The final ACAA Error object captures all error information relating to the currently executing ASP script, looks up value-added information such as the function call-stack, then presents the information in a collapsible error display screen that allows effective drilling down to information about the source of the error. Furthermore, setting a single configuration flag transforms the display of errors to a more end-user friendly interface that conceals detailed information unless it is explicitly requested.


9.3 Testing Strategy & ResultsClear-box Component TestingACAA’s object-based architecture greatly simplified clear-box component testing; taking advantage of the encapsulated nature of each component, a dummy version of each was produced that mimicked the real version’s properties and methods, but performed no real processing to minimise the risk of it being the cause of an error. These dummy objects were then used to test individual COM objects and ASP scripts:

■ COM objects were tested using ASP scripts similar to the use case handler scripts, but designed to test each service provided by the object. Instead of being allowed to interact with other objects as normal (this would have introduced an element of unknown when errors occurred), the component was placed in an environment of dummies. This allowed errors originating directly from the component to be spotted immediately.

■ ASP scripts were tested by substituting all utilised COM objects with dummy objects, meaning the correct end result could be predicted before the test and errors spotted easily if a different result was reached.

A number of bugs were detected that had gone unnoticed during standard testing whilst developing, including:

■ UI object generated unhandled exception if XML document with unknown root node was passed to it for display; fixed to generate a helpful error message

■ References to deleted ContentItem objects not removed from parent WebSite object, meaning could delete same content item twice, causing unhandled exception

Black-box Integrated TestingBefore ACAA could be given a stamp of completion approval, it was required to allow the following sequence of use cases to be performed, designed to test major application paths, without an error message or unexpected results:

1 Registering New User2 Changing Web Site Style3 Creating Doc4 Viewing Content Item5 Administrating Web Site6 Copying/Renaming/Deleting Content Item7 Administrating Group Web8 Deleting User Web Site

To test ACAA’s cross-platform capabilities, the above use case sequence was performed in both an up-to-date copy of Microsoft Internet Explorer (6.0) and an aging copy of Netscape Communicator (4.75). No difference in the behaviour of the


system was observed between the two browsers, but a single logic flow problem became apparent for ‘EditingDoc’ (part of ‘CreatingDoc’ where changes to a page could be saved more than once, causing problems.


10 Evaluation & ConclusionsThis chapter assesses the Accessible Content Access & Authoring artefact produced by this project and reflects on the lessons learnt during its development.

ACAA doesn’t try to re-invent the wheel. Instead it provides a flexible interface to a number of existing standards and technologies with the aim to making viewing and authoring web content more accessible to groups less able to use existing tools. Technologies such as XML, XSL and Web Services are open standard and openly available, meaning developers would be foolish not to make use of them. A significant amount of development time was saved during this project by re-using freely available existing components, such as the XSL ISAPI Filter.

The resulting system provides an easy means for children to share their work with visitors around the country/globe and is intended to encourage increased creative output from students, e.g., stories, poems and scanned artwork. By providing a variety of editing interfaces (e.g., WYSIWYG, HTML data forms) to the same data, the system adapts to the user’s authoring ability, offering increased control and customisation possibilities as they grow in experience. The system also automates the laborious task of creating rich content viewable on many different client types, something that most traditional WYSIWYG applications are notoriously poor at achieving.

The project required comprehensive mastering and effective utilisation of a number of industry-standard technologies, including XML for data communication/storage, XSL/XSLT for XML data manipulation, HTML/CSS/Client-side Scripting for client-side presentation, SQL for Relational Database queries and ASP + COM for application logic.

A substantial amount of time was invested in following a solid design methodology; so much so in fact, that this evaluation chapter is significantly more abbreviated than the author would have liked. The author feels this investment reaped dividends, however, since this report has traced the progress of the originally stated requirements (effectively the Use-Case Model) step by step through the design process. It is difficult to forget or neglect requirements using a method where the system design is generated directly from the requirements. Appendix D traces the stakeholder requirements identified in section 7.2 through to features of the final ACAA system.

The next section provides a brief overview of the key benefits and features of the final ACAA system, but the author invites final judgement of the system to be drawn from the project demonstration, in which these features can be seen and experienced for real.


10

10.1 Key System Features & BenefitsACAA introduces a range of highly innovative usability and technical features rarely seen in web applications; this section describes a few of them for the benefit of users who have not tried the system for themselves.

Client Independent Service Provision■ Storage, retrieval and editing services available to virtually any common client

device, ranging from old browsers such as IE / Netscape 3.x to WAP devices■ Recent, up-to-date clients such as IE5+ and Netscape 6+ benefit from enhanced

server responsiveness thanks to client-side XSL transformation taking the place of equivalent processing on the server

■ Browsers with up-to-date DHTML implementations also benefit from advanced functionality not possible on more basic clients, e.g., WYSIWYG editing

WYSIWYG Editing of Web Page Content■ Invaluable to younger users, browsers such as IE5 are presented with a WYSIWYG

editing interface when editing a page, instead of a basic fields form■ Usability at its best; said users can click the “Edit this Page” link on a web page,

type their changes directly on to the web page, then save directly back to the server in a few clicks

Usable URLs■ Web in most basic form has intrinsically low usability; no reliance on central

service that can provide uniform presentation, behaviour, help, etc. Instead are communicating directly with web servers powered by wide range of software

■ Unhelpful and irregular error messages if type wrong URL; completely different types error message, depending on whether entered invalid/wrong domain name, invalid/wrong filename, invalid parameters

■ URLs are long and contain a large proportion of punctuation, which difficult to locate on keyboard for inexperienced users

■ ACAA’s innovative solution to the problem of helping younger users remember the URL of their web site is to allow users to use their e-mail address as their web site URL, e.g.:

http://[email protected]

■ Achieved by taking advantage of Basic Authentication notation that allows URLs like the above to be used in even the most basic of browsers

■ Idea came from observation that brothers often get the concept of an e-mail address and an Internet URL confused and try to visit their e-mail address in a web browser


Universal Help & Support■ Uniformly located help link on every page, plus F1 shortcut key in supporting

clients■ Uniformly located ‘Read This Page To Me’ link on every page, plus F12 shortcut

key in supporting clients; when activated, ACAA invokes a third party Lucent TSS Web Service that generates a sound file from specified text, allowing page to be read aloud to user

■ Helps when user has limited reading ability or visual impairment

Progress Feedback Status Bar■ Dynamically updated status bar showing server’s progress in processing request;

also useful for debugging and tracing system faults■ Total time spent serving request is shown, giving indication of current server

performance■ If server error occurs while processing a request, status bar shows the task that

caused it■ Works by sending back script to the browser that updates the status bar display

after major operations complete

10.2 Further WorkKey improvements and extensions to ACAA that could be made would include:

Technical■ Replacement of Script COM prototype components with real C/C++ COM objects

for increased speed and efficiency■ Add additional administration features such as SQL Server configuration panel■ Possible replacement of SQL Server with a less expensive but equally scalable

DBMS or a native XML database, to reduce Total Cost of Ownership for ACAA

Usability■ Usability trial using real school age users to identify flaws in the user interface

and use case flow logic with regards to young users■ Additional advanced editing interfaces such as voice-recognition authoring and

touch screen■ Improved on-line help documentation, better specialised to current user task■ Experiment with ‘kiosk-mode’ user interface that removes distracting browser

elements, making ACAA more usable for inexperienced users■ Improve user control over page presentation, e.g., advanced animation effects,

and support enhanced functionality such as an automatic word look-up glossary


11 ReferencesThis chapter presents details of the publications and on-line resources referenced elsewhere in the report, presented according to standard UMIST guidelines.

■ Berners-Lee T. et al (1996). “Hypertext Transfer Protocol—HTTP/1.0” [On-line], Available http://www.w3.org/Protocols/HTTP/1.0/spec.txt

■ Booch G. et al (1998). “The Unified Modelling Language User Guide”, Section 4. ISBN: 0201571684, Pub: Addison-Wesley

■ Cassaigne N., UMIST (1999). “Human Computer Interaction: Web Site Usability”. Pub: UMIST

■ Chartier R. (2001). “Application Architecture: An N-Tier Approach” [On-line], Available http://www.15seconds.com/issue/011023.htm

■ Eden T. & Ludke E. (2000). “Introducing JavaServer Pages” [On-line], Available http://www.devx.com/upload/free/features/javapro/2000/04apr00/te0004/te0004-1.asp

■ EWS (Engineering Workstations), University of Illinois (2002). “Browser Statistics” [On-line], Available http://www.cen.uiuc.edu/bstats/latest.html

■ Flynn D.J., UMIST (2002). “Method for Web Site Development”. Pub: UMIST■ Howlett S. & Dunmall J. (2001). “Beyond ASP: XML and XSL-based Solutions

Simplify Your Data Presentation Layer” [On-line], Available http://msdn.microsoft.com/msdnmag/issues/1100/BeyondASP/print.asp

■ Hunter J. (2000). “The Problems with JSP” [On-line], Available http://www.servlets.com/soapbox/problems-jsp.html

■ Jacobson I. et al (1992). “Object-Orientated Software Engineering: A Use Case Driven Approach”. Pub: ACM Press

■ Jacobson I. et al (1995). “The Object Advantage: Business Process Reengineering with Object Technology”, Chapter 9. ISBN: 0-201-42289-1, Pub: ACM Press

■ Layzell P., UMIST (1999). “Software Analysis & Design”. Pub: UMIST■ Marshall J. (1997). “HTTP Made Really Easy: A Practical Guide to Writing Clients

and Servers” [On-line], Available http://www.jmarshall.com/easy/http/ ■ Maylor H. (1999). “Project Management” 2nd Ed, Chapter 3. ISBN: 0-273-63829-7,

Pub: Prentice Hall■ Microsoft Corp. (2002). “The New System Design” [On-line], Available

http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/eadg6dv2.asp ■ Microsoft Corp. (2002). “XSL ISAPI Filter 2.2: Server-side XSL Formatting for

Multiple Client Types” [On-line], Available http://msdn.microsoft.com/library/en-us/dnxslgen/html/xslisapifilter.asp


11

http://msdn.microsoft.com/library/en-us/dnxslgen/html/xslisapifilter.asp

http://msdn.microsoft.com/library/en-us/dnxslgen/html/xslisapifilter.asp

http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/eadg6dv2.asp

http://www.jmarshall.com/easy/http/

http://www.servlets.com/soapbox/problems-jsp.html

http://www.theregister.co.uk/content/4/18996.html

http://www.cen.uiuc.edu/bstats/latest.html

http://www.devx.com/upload/free/features/javapro/2000/04apr00/te0004/te0004-1.asp

http://www.devx.com/upload/free/features/javapro/2000/04apr00/te0004/te0004-1.asp

http://www.15seconds.com/issue/011023.htm

http://www.w3.org/Protocols/HTTP/1.0/spec.txt

■ Nielsen J., Neilsen Norman Group (2001). “What is ‘Usability’?” [On-line], Available http://www.usablenet.com/accessibility_usability/usability.html

■ Nielsen J., Neilsen Norman Group (2002). “Kids’ Corner: Website Usability for Children” [On-line], Available http://www.useit.com/alertbox/20020414.html

■ Petrounias I., UMIST (2000). “The Way-of-Working: Design Rationale”. Pub: UMIST■ Petrounias I., UMIST (2001). “A Methodology for Specifying Non-Functional

Requirements”. Pub: UMIST■ Smith T. (2001). “Sun admits ASP better than Java for Web” [On-line], Available

http://www.theregister.co.uk/content/4/18996.html ■ Vowles R. (2000). “Java Server Pages FAQ” [On-line], Available

http://www.esperanto.org.nz/jsp/jspfaq.jsp

Online Service References■ AlphaDesk FunPages - http://www.alphadesk.net/fun/funpagemaker.html ■ GeoCities – http://www.geocities.com/ ■ MatMice - http://www.matmice.com/ ■ Tripod - http://www.tripod.com/ ■ Tripod Classroom - http://classroom.tripod.com/ ■ Web Genies - http://www.webgenies.co.uk/ ■ Webmonkey For Kids - http://hotwired.lycos.com/webmonkey/kids/


http://hotwired.lycos.com/webmonkey/kids/

http://www.webgenies.co.uk/

http://classroom.tripod.com/

http://classroom.tripod.com/

http://www.matmice.com/

http://www.geocities.com/

http://www.alphadesk.net/fun/funpagemaker.html

http://www.esperanto.org.nz/jsp/jspfaq.jsp

http://www.theregister.co.uk/content/4/18996.html

http://www.useit.com/alertbox/20020414.html

http://www.usablenet.com/accessibility_usability/usability.html

12 BibliographyThis chapter presents a selection from the publications and on-line resources used during the writing of this report, which were not explicitly referenced from the text.

■ Blaha M. & Premerlani W. (1998). “Object-Orientated Modelling & Design for Database Applications”. ISBN: 0-13-123829-9, Pub: Prentice Hall

■ Chorafas D. & Steinmann H. (1993). “Object-Orientated Databases”. Pub: Prentice Hall

■ Daly-Jones O. et al, NECTAR, European Journal of Engineering for Information Society Applications (1999). “INUSE 6.2: Handbook of User-Centred Design” [On-line], Available http://www.ejeisa.com/nectar/inuse/6.2/

■ Dawson R., Loughborough University (1999). “Relational Database Design and Use” 2nd Ed. ISBN: 1-874152-06-3, Pub: Group D Publications

■ Elmasri R. & Navathe S. (1994/2000). “Fundamentals of Database Systems” 2nd Ed. ISBN: 0-8053-1753-8, Pub: The Benjamin/Cummings Publishing Company Inc

■ Fowler M. & Scott K. (1999). “UML Distilled” 2nd Ed. ISBN 020165783, Pub: Addison-Wesley

■ Grosso P. & Walsh N. (2000). “XSL Concepts and Practical Use” In XML Europe 2000 Conference, Paris, France [On-line], Available http://www.nwalsh.com/docs/tutorials/xsl/

■ Kochmer C., JSP Insider (2000). “JSP VS ASP & ASP+ & .Net & ADO+” In JSP Buzz, Vol. 1, No. 7 [On-line], Available http://www.jspinsider.com/jspbuzz/2000/buzz_10_17_2000.view

■ Koulopoulos T. & Frappaalo C. (1995). “Electronic Document Management Systems”. Pub: McGraw-Hill Inc

■ Meng Lee W., Ngee Ann Polytechnic (2000). “Tailoring Content Using XML and XSL” In Wrox Professional Wireless Developer Conference (Europe), Amsterdam [On-line], Available http://www.wmlscript.com/Article_Arch/XMLXSLT.asp

■ Nielsen J., Neilsen Norman Group (2002). “Kids’ Corner: Website Usability for Children” [On-line], Available http://www.useit.com/alertbox/20020414.html

■ Post G. (1999). “Database Management Systems: Designing & Building Business Applications”. Pub: Irwin / McGraw-Hill Inc

■ Wirfs-Brock R. et al (1990). “Designing Object-Orientated Software”. Pub: Prentice Hall

■ World-Wide-Web Consortium, W3C (1999). “XSL Transformations (XSLT) - Version 1.0” [On-line], Available http://www.w3.org/TR/1999/REC-xslt-19991116

■ Zaslavsky A. (1999). “Client/Server Database Systems” [On-line], Available http://www.csse.monash.edu.au/courseware/cse5200/ddb-l-02s/index.htm


12

http://www.jmarshall.com/easy/http/

http://www.w3.org/TR/1999/REC-xslt-19991116

http://www.useit.com/alertbox/20020414.html

http://www.wmlscript.com/Article_Arch/XMLXSLT.asp

http://www.jspinsider.com/jspbuzz/2000/buzz_10_17_2000.view

http://www.nwalsh.com/docs/tutorials/xsl/

http://www.ejeisa.com/nectar/inuse/6.2/

13 AppendicesThis section presents diagrams, descriptions and models considered too large to be included directly within the main text without disrupting the flow of discussion.


13

A Use Case DescriptionsNotation: ‘USE-CASE USED’ = uses relationship , ‘EXTENSION USED’ = extends relationship

Viewing Content ItemUser Goal: View content such as a document or image

A User requests content by typing the content URL or following a linkB System retrieves content informationC System checks user’s client type, transforms content into most suitable format

and displays to user

Creating DocUser Goal: Create a new document on a web site

A User clicks ‘Create New Page’ linkB Use-case ‘Confirming Identity’ USED to confirm user is Owner/AdministratorC If a document name has not yet been specified, ‘Specify New Item Name’ USE-

CASE USEDD System creates a new document in the user’s web site with the specified nameE ‘Editing Doc’ USE-CASE USED for created document

Editing DocUser Goal: Edit a document content item

A User clicks ‘Edit This Page’ link on a content page or ‘Edit A Document’ link in their admin area

B ‘Confirming Identity’ USE-CASE USED to confirm user is Owner/AdministratorC If a document name has not yet been specified, ‘Choosing Content Item’ USE-

CASE USEDD System retrieves content informationE System checks user’s client type and displays a suitable editing interface for the

documentF User makes changes using the editing interfaceG Optionally, ‘Saving Doc Changes’ EXTENSION USED

Saving Doc ChangesA User clicks ‘Save Changes’ button on editing interfaceB ‘Confirming Identity’ USE-CASE USED to confirm user is Owner/AdministratorC System retrieves content, applies and saves changesD System displays confirmation message to user


Registering New UserUser Goal: Register a new user and create an associated web site

A User clicks ‘Register New User’ link on login screen or in group web admin areaB System prompts user for their details and desired user name and password; user

providesC System stores new user details and creates an empty web site for themD User asked whether they’d like to create a home page for the new web siteE If user approves, ‘Administrating Web Site’ USE-CASE USED

Administrating Web SiteUser Goal: View and change web site details and content

A User clicks ‘Administrate Web Site’ linkB ‘Confirming Identity’ USE-CASE USED to confirm user is Owner/AdministratorC If is user’s first visit to admin area, ‘Creating Home Page’ EXTENSION USEDD System displays list of all content items in web site and allows following use case

to be initiated for any item: ‘Viewing Content Item’ ‘Editing Doc’ ‘Copying/Renaming/Deleting Content Item’

E In addition, system displays UI elements allowing the following use cases to be triggered for current web site: ‘Creating Doc’ ‘Changing Web Site Style’ ‘Exporting Web Site’

F User selects an option, triggering the associated use case

Creating Home PageA User administrates their web site for the first timeB ‘Confirming Identity’ USE-CASE USED to confirm user is Owner, not

AdministratorC System creates a significantly named default document in the user’s web siteD System pre-populates document with sample content, e.g., help text introducing

the new user to the systemE ‘Editing Doc’ USE-CASE USED for newly created home page

Copying/Renaming/Deleting Content ItemUser Goal: Copy, rename or delete a content item

A User clicks a content item administration link in admin area or on content pageB ‘Confirming Identity’ USE-CASE USED to confirm user is Owner/AdministratorC If copying or renaming, ‘Specifying New Item Name’ USE-CASE USED


D If deleting, system requests confirmation from user; user approvesE System performs copy/delete/rename operationF System displays confirmation message to user

Administrating Group WebUser Goal: Administrate group web and associated web sites and users

A User clicks ‘Administrate Group Web’ linkB ‘Confirming Identity’ USE-CASE USED to confirm user is AdministratorC System displays list of all web sites in the group web and allows following use

case to be initiated for each: ‘Viewing Web Site Details’ ‘Viewing Content Item’ (for web site Home Page) ‘Deleting User Web Site’

D In addition, system displays UI elements allowing the following use cases to be triggered: ‘Registering User’ ‘Viewing Content Item’ ‘Editing Doc’ ‘Copying/Renaming/Deleting Content Item’

E User selects an option, triggering the associated use case

Deleting User Web SiteUser Goal: Remove a user’s details and their associated web site from the group web

A User clicks ‘Delete User Web Site’ link in group web administration areaB ‘Confirming Identity’ USE-CASE USED to confirm user is AdministratorC If a web site has not yet been specified, ‘Choosing Web Site’ USE-CASE USEDD System requests delete confirmation from user, offering to export the web site

firstE If user chooses to export web site, ‘Exporting Web Site’ USE-CASE USEDF User gives confirmation and system deletes user’s details and web siteG System displays confirmation message

Getting HelpUser Goal: Get help with current task

A User clicks ‘Help’ link or presses help shortcut key on any option screen or content page

B System displays documentation tailored to current task and screen

Changing Web Site StyleA User Goal: Change appearance of a web site


B User clicks ‘Change Web Site Style’ link in admin areaC ‘Confirming Identity’ USE-CASE USED to confirm user is Owner/AdministratorD System displays list of available web site stylesE User chooses a styleF System sets style as default for user’s web siteG System displays confirmation message

Helper Use Cases:

IdentificationUser Goal: Provide and prove their identity

A User tries to perform an operation that has restricted accessB System checks whether user’s identity has already been obtained and confirmedC If not, system prompts user to enter their username and password; user providesD System checks username is valid and the password is correct; if not, user is re-

promptedE With the user’s identity confirmed, system checks whether they have permission

to perform the operationF If so, user is permitted to continue with operation, otherwise an error is shown

Specifying New Item NameUser Goal: Specify name for a new content item that is unique within a web site

A System prompts user for new item nameB If user is Administrator, system also displays device allowing user to specify an

alternative destination web siteC User specifies new item name and optionally the destination web site (‘Choosing

Web Site’ USE-CASE USED)D System checks new item name is unique for the destination web site

Choosing Content ItemUser Goal: Choose an existing content item

A System displays list of content items in current web siteB System displays device allowing user to change current web site; if used, content

items list is updatedC User indicates their chosen content item

Choosing Web SiteUser Goal: Choose an existing web site

A System displays list of web sites in current group webB User indicates their choice from the selection


B Ideal-Object Models for Individual Use Cases


C Technology Design RationaleThis appendix presents a detailed explanation of the decision process by which the implementation technologies used for ACAA were decided, modelled using the Design Rationale ‘Reasoning Loop’ technique described in Petrounias, 2000.

The process involves taking the highest level goal, G0, and suggesting sub-goals and/or a range of hypothesis for meeting the goal. Each hypothesis is then met with a number of for and against arguments. Finally, zero, one or more of the hypothesis is chosen as having sufficient supporting arguments and is either accepted as a new goal (G1, G2 ..), or as a conclusion (C1, C2 ..) if there are no further decisions to be made about the hypothesis.

The result is a set of conclusions (C1..Cx) that adequately satisfy the originally stated goal, G0.

G0 Select the best suited implementation technologies for ACAAWhat combination of hardware, operating system, programming language, etc., would best suit the ACAA design, in the context of the stated functional and non-functional requirements?

■ Identify “Find best suited software technology” as G1■ Identify “Find best suited supporting hardware” as G6

G1 Find best suited software technologyWhat software implementation technology would best suit the ACAA design and underlying requirements? Selected technology should be easily maintainable and allow object-orientation.

H1a Full application programming languagee.g., C / C++ / VB ISAPI server extension, Java Servlet

+ Optimal performance speed due to compiled and optimised low-level code− Significantly high development time, code complexity and skills requirements− Increased potentially for serious server stability problems due to bugs+ More powerful and expressive programming constructs− Increased barrier-to-maintenance, due to skills requirements

H1b Server scripting language (standalone)e.g., Active Server Pages (ASP) or JavaServer Pages (JSP)

+ Simple and easy to use programming model, fewer syntactic complexities− Limited performance due to code being interpreted at run / conversion time+ Easy administration due to minimal external dependencies− Increased risk of creating spaghetti code that mixes logic with presentation+ Typically larger available skills base (due to reduced learning curve) means

reduced costs


+ Excellent availability of low-cost support tools, documentation and pre-written code

H1c Server scripting language and components/objectse.g., Active Server Pages with COM or JavaServer Pages with Enterprise JavaBeans

+ Best of both worlds approach – combines high performance compiled components encapsulating key application logic with easy to use scripting environment

+ Use Case flow logic controlled using by simple scripts, allowing quick and easy adaptation of system behaviour to meet changing user needs

− Overhead of accessing components can decrease performance, particularly if page execution time exceeds the time between requests to the server (‘blocking’)

+ Well designed components encapsulate behaviour and simplify scripting code− Components with poorly designed interfaces can INCREASE script complexity− Increased skill requirements for developing components compared with script+ Working to an interface specification allows developers close to the user to focus

on the use case scripts, while others take care of complex development behind components

+ Standalone components can be distributed across multiple servers to increase scalability and performance, or even off-loaded to the client to reduce strain on the server

■ Accept H1c as G2, “Find suitable server scripting language with object support”■ Identify “Find best suited data storage and manipulation technology” as G3

G2 Find suitable server scripting language with object supportWhat server-side object scripting language would best suit the needs of the ACAA design and underlying requirements? A crucial decision in determining the architecture of the project, selection criteria include performance, ease-of-use and maintainability, learning curve, object-orientation support, value-added technology features and quality of available development tools, support and documentation.

H2a JavaServer Pages + Enterprise JavaBeans (JSP + EJB)+ Strong support throughout for object-orientated concepts such as classes and

inheritance− Strongly typed language; everything in the language has a class type, leading to

more complex syntax, long-winded type conversion operations and slower coding time

− Cost of hiring or training staff with Java skills prohibitive to in-house system administration

+ Not tied to Windows platform; can be configured to run on almost any server / platform

− Substantially more limited hosting options; companies offering JSP + EJB web hosting are currently in very short supply, increasing hosting costs


+ Degree of performance benefit over ASP (the extent of which is a subject of debate), due to scripts being transformed into Java Servlets the first time they are requested, then compiled

− Above layered approach generally blamed for poor usability of JSP error messages, which are tend to be highly cryptic for even the simplest of syntactic errors

− Many JSP implementations unable to accept POST and GET data simultaneously, a limitation that does not occur with ASP

+ Open-standard specification promotes optimised compiler and server software− Current JDBC drivers don’t support XML transactions, unlike ASP’s ADO

H2b Active Server Pages + Component Object Model (ASP + COM)+ Not tied to a single language; any scripting language that meets the ECMA

standard (i.e., that supports object handling) can be used, including JScript (JavaScript), VBScript, Perl & Python

− Less established coding standards, due to variety of supported scripting languages

+ Wide availability of ASP programmers, due to ease of use, short training time and instant language familiarity to programmers used to C-style (including Java) or VB-style syntax

− Quasi-object-orientation; JScript and similar languages cannot be considered true O-O languages because they don’t support features such as classes and inheritance

+ Recent implementations of JScript offer near feature equivalence with Java (e.g., support for ‘try .. catch’ error handling, programmable and extensible objects, regular expressions)

+ Superior database interface components; ADO, OLE-DB and ODBC support all widely regarded as having increased ease of use and performance compared to JDBC drivers

− Considered less scalable than JSP if careful consideration not given to system design, due to threading issues not present in Java

+ Powerful and secure built-in support for Windows NT(+) Integrated Authentication, allowing Intranet users to be authenticated automatically without providing login credentials

− Most powerful language features (such as the above) tied to Window platform only

+ Direct upgrade path to ASP+, which is compiled, fully object-orientated and offers superior performance compared with JSP, due to routines optimised for the Windows platform, as well as advanced functionality such as built-in object / page result caching and XML support

+ Rapid prototyping of COM objects, using Script COM; complex components can be created using simple script, then replaced with real COM objects for increased performance


+ Sun stated in its own publicity material in 2001 that “ASP is faster and more effective for simple Web applications than Java” [Smith, 2001]

■ Conclude H2b as C1, “Implement ACAA using ASP + COM programming technology”

G3 Find best suited data storage and manipulation technologyWhat data technology - such as a Relational Database Management System (e.g., Microsoft SQL Server) or data storage format (e.g., XML) - would be most suitable for handling stored data (such as user data and content information) in the ACAA system? Must be scalable to cope with increased load should the system eventually serve one or more large schools and should offer high performance to avoid young users becoming impatient.

H3a Use Microsoft SQL Server 2000 for handling user data+ Provides high performance data access even when server many simultaneous

users− Complicated configuration and administration compared with smaller scale

product like Access+ Strong integration with Internet Information Server platform and Windows NT(+),

allowing advanced functionality such Integrated Windows NT Authentication+ Enforces data security locally as well as over the web; users must be granted

permission before they can access stored data, even if they have physical access to the database server

− Significant cost of full commercial version, although lower than similar products such as Oracle

+ Freely distributable, fully functional ‘Desktop Edition’ version included with Office 2000 and XP, fully licensed for development and testing (fully compatible with commercial version)

+ Built-in XML support and full text content indexing+ Supports the Open Database Connector (ODBC) standard, meaning replacing with

an alternative solution (e.g., Oracle, mySQL) in future requires minimal changes to applications

H3b Use IXIASOFT TeXtML Server for content storage and processingIXIASOFT TeXtML Server is a database server product tailored to handling large amounts of text-based information instead of traditional data such as figures and single words.

+ Better modelling of semi-structured mark up text and more efficient storage of long textual data than possible in RDBMS

+ Full text searching, including by tag name− Proprietary query language (no support for XQuery standard)+ Support for direct XSL transformation of data for display− No low-cost ‘personal edition’ package to assist developer testing− Small vendor company with limited support capabilities


H3c Use open web standards for content storage and processingUse open-standard technologies such as XML and XSLT for storage, representation and manipulation of content data.

+ Familiar editing software can be used instead of the ACAA interface, if desired+ Content information can be copied and manipulated using the normal operating

system− Accessing XML stored in a file on disk can be slower than accessing it in a

database+ Content is not tied to the ACAA system; content can still be easily accessed in the

event that ACAA fails to start+ Content can be re-used in future systems, for example if the user changes school

■ Conclude H3a as C2, “Use Microsoft SQL Server 2000 for handling user data”■ Accept H3c as G4, “Select web standards for content storage and processing”

G4 Select web standards for content storage and processingWhat data storage and manipulation standards are available that are suitable for handling web site content information in ACAA? Selected standards should ensure that content is not tied to a proprietary format that prevents information re-use in the event that ACAA is replaced.

H4a Use eXtensible Markup Language (XML) for content storage and representation+ International standard for representing structured and semi-structured

information as plain text consisting of a hierarchy of ‘mark-up tags’+ Easier read by machines, software and the human eye alike+ Supports UNICODE character encoding, meaning symbols from all languages can

be stored− More verbose in its syntax than some other encoding standards, although this is

compensated for by its high compressibility by network protocols during transport+ Unlike mark-up language like HTML, is no fixed set of mark-up tags, so can define

own; effectively creating a custom data structure− Encoding quirks exist that can cause confusion if unknown; for example, certain

symbols (such as “<”) must represented using special notation instead of including the character

+ Extremely wide-spread support in database software, servers and other applications, including easy to use support in ASP and SQL Server 2000

− No built-in security; content security relies on operating system permissions being set on the content file in order to prevent unauthorised users accessing it locally

H4b Use eXtensible Stylesheet Language (XSL) for transforming XML data into other formats+ High performance, powerful and flexible language for transforming XML into any

format


+ Pre-written XSL libraries offering prefixed transformations such as XML to WML [Grosso et al]

− Language syntax and approach can be difficult to learn and get used to+ XSL filters that output XML can be applied in any sequence, allowing modular

transformations

H4c Use the XML DOM to transform XML data through ASP script+ High level of transformation control+ No need to learn XSL language− Low winded manual processing of XML data− Reduced performance compared with XSL transformations

■ Conclude H4a as C3, “Use XML for content storage and representation”■ Accept H4b as G5, “Integrate XSL processing into system architecture”

G5 Integrate XSL processing into system architectureHaving selected XSL as a means of transforming XML content, in what ways can the transformation step fit into the ACAA design? The selected approach should provide a high degree of flexibility to cope with and take advantage of the spectrum of processing capabilities in existence in user clients. The approach should also aim to hide presentation issues from the rest of the system as thoroughly as possible.

H5a Transform XML on client-side using XSL+ Typically reduced size of transferred data, due to absence of presentation code

and the highly compressible nature of XML structures− Increased strain on client could decrease performance for under-powered devices+ On the flip-side, increases performance for devices that can handle the

transformation with ease, by reducing the load on the server, making it more responsive

H5b Transform XML on server-side using XSL via ASP+ Fine level of control over transformation logic− Requires long winded transformation routines to be called manually each time

content needs to be displayed

H5c Transform XML on server-side via XSL ISAPI Filter+ A user requesting an XML file causes the content information to be intelligently

presented according to detailed transformation logic based on content type and client capabilities

+ Allows dynamic choice between client or server-side presentation transformation, e.g., IE5 is sent a raw XML file with a style sheet reference, whereas Netscape 4 is served HTML generated from a server-side transformation

− Some basic IIS administrative knowledge required to set up initially (not a built-in feature)


+ Increased transformation performance thanks to low-level pipelined ISAPI framework

− Decreased fine control over transformation, due to use of 3rd party component+ Licensed for free distribution by Microsoft Corporation+ Rest of ACAA application can ignore presentation entirely and simply output XML

when they wish to display information to the user

■ Conclude H5c as C4, “Transform XML on server-side via XSL ISAPI Filter”

G6 Find best suited supporting hardwareH6a Use Microsoft Internet Information Server (IIS) 5 on Windows 2000

+ Free with Windows 2000 operating system, which is widely available within networked environments such as academic institutions

− Requires purchase of a Windows operating system if one is not already available; may even require investment in expensive Windows Server OS for high server load scenarios

+ Tight integration with the Windows platform, allowing it to take advantage of advanced functionality such as Integrated Windows NT Authentication

+ Possible to substitute with IIS4 for Windows NT with minimal system changes; Personal Web Server (PWS) for Windows 98 can even be used for basic development work (verified!)

− Regularly targeted by hackers looking for exploits and security holes, due to its universal popularity with Small to Medium Entity (SME) organisations who are seen as easy targets

+ Regular service pack updates and security fixes available for free from vendor+ Solid performance and extremely easy to use, meaning low administration costs

and reduced training requirements for schools and group administrators+ Strongest support for technologies used by ACAA, including COM, XML, ASP and

SQL Server

H6b Use Apache Server on RedHat Linux+ Freely available and widely (with varying quality) documented− Much higher barrier to entry presented by Linux Operating System, which

requires substantially higher technical ability to use than Windows+ Reported substantially increased stability over IIS− Less user-friendly Server tools harder to use for group administrators− No support for the needed Microsoft technologies such as COM and ASP

H6c Support touch-sensitive visual display unit (touch screen)Teaching staff spoken to during requirements investigation suggested use of touch screen to replace mouse (and optionally keyboard) as more user friendly interface for children.

+ Quicker selection speed for younger users compared with navigating with mouse


− Experienced users may prefer keyboard and mouse that are used to, particularly staff

+ Touch-screen equipment usually comes with software allowing it to be used to control existing software without modification

− Learning to use keyboard and mouse is important skill for users to learn, so their usage is education in itself.

− Young users tend to learn to use mouse and keyboard quickly; the author’s three year old sister is an accomplished player of Tweenies games involving mouse control

+ Lower barrier of entry to system for inexperienced younger users− Less precise selection control, slower data entry if also replaces keyboard− Unlikely to be available in school environment (and certainly not in home

environment) without additional expenditure− Explicit support not necessary at this stage, since would be trivial to add

supporting features such as extra large buttons and links later on

■ Conclude H6a as C5, “Use Microsoft Internet Information Server (IIS) 5 on Windows 2000”

Design Rationale ConclusionsC1 Implement ACAA using ASP + COM programming technologyC2 Use Microsoft SQL Server 2000 for handling user dataC3 Use XML for content storage and representationC4 Transform XML on server-side via XSL ISAPI FilterC5 Use Microsoft Internet Information Server (IIS) 5 on Windows 2000


D Requirements TraceabilityThe following section traces the stakeholder requirements identified in section 7.2 through to features in the final ACAA system, in the form of corresponding system use cases.

1a) Create and delete user web sites and associated user accounts■ Registering New User■ Deleting User Web Site

1b) Export the information from a user’s web site so can be used in other system■ Exporting Web Site

1c) List web sites in Group Web & administrate any one as if were the owner■ Administrating Group Web■ Administrating Web Site

2a) Create and edit document content items on their web site■ Creating Doc■ Editing Doc

2b) Rename, copy and delete content items on their web site■ Copying / Renaming / Deleting Content Item

2c) Customise the appearance of their web site (e.g., colour scheme)■ Changing Web Site Style

2d) Enable other people to visit their web site, e.g., by sharing an URL■ E-mail style ‘Usable URL’ feature

3a) View or print a web page from an ACAA web site■ Viewing Content Item

3b) Register themselves as system users in order to set up an ACAA web site■ Registering New User


professional report - ben johnson final report (with diagrams).doc · web viewcontent access &...

Documents