Java Tutorial - Java Script :
System Roles and Functions
The following roles are supported within the system supporting the use cases as described.
Visitor Role
A visitor is someone who has not yet registered to use the site. A visitor’s actions are limited to viewing selected informational content and participating in self-registration.
Alumnus Role
The alumnus is the primary user of the system and is a registered user of the site. The functions that can be performed by an alumnus are:
· Modifying user information
· Registering for reunion event
· Purchasing merchandise
· Viewing news
· Viewing the alumni address book
Administrator Role
The administrator is the privileged user of the system. An administrator can perform all the actions of all other roles. Additionally, the administrator has the ability to add classes and subgroups (for example, “marching band” or “cheerleaders”) that might receive specially targeted information.
Content Administrator Role
The content administrator has the ability to add, update, and delete content and news items.
Event Coordinator Role
The event coordinator’s primary functions are to add, modify, and remove events. Events may be ticketed, and tickets may be sold as merchandise.
Merchandise Administrator Role
The merchandise administrator can add, modify, and remove merchandise items from the merchandise catalogue.
System Interfaces
The Reunion Management System (RMS) has four interface points with external systems. The first interface point is a batch-initialization capability. This is to be provided through a standard set of XML files that can be used to initialize the databases in the system. The system must also be able to export these files so the information can be exported to other systems.
The next two interfaces are related to the fulfillment of merchandise sales.Many products that will be available for sale through the site are provided through external merchants. These merchants fall into two categories: those that can accept orders for single or bulk items using Web services and those that only accept bulk orders or do not have support for ordering through Web services.
The final interface is an interface to an email system. This allows confirmation of actions such as registration or purchase completion to be sent to an email address.
Platform Considerations
The Reunion Management System should support deployment in a J2EE 1.3 or later environment and should have minimal dependencies on the hardware or operating system for correct operation. The company does not want to purchase new equipment for development, so the developers will work on the existing desktop computers running the Window 2000 Professional operating system.
A Couple Final Notes
The following sections discuss a couple final notes that don’t fit anywhere else in the chapter, but that we wanted to impart to you anyhow.
A Word about Operating Systems
While it may seem that a book focused on development using open source tools should focus on Linux, the reality is that most companies use Windows on the desktop. Although support for Windows 9x platforms is not a requirement in our scenario, there is still a great demand for people who want to do J2EE development work on the Windows 9x platforms. We also recognize the large number of Linux devotees who will want to make certain that they can duplicate what we do in this book for their Linux platform. As we progress through this book and evaluate products, we will annotate any variations or dependencies on operating systems and strive to choose products that are not only the best open source products available for our needs but are also compatible with the widest variety of operating systems possible.
Changing Open Source Code
Afinal comment on using open source code: There may be many good reasons to change the code for a product. The product might not exactly meet your needs and you know that with a small change you can address this. You may have discovered a bug and decide to fix it. Or you may feel that the product should be modified to suit your particular purposes. This is all well and good, but remember that if you make a change and it is not accepted by the general user community, you will become dependant on a custom version of the product that no one else is willing or able to support. This, in turn, can affect your ability to integrate your application with other products or to upgrade it in the future. Most open source projects have a mechanism in place to implement changes to the products that consider the effects of those changes on the entire user community. If you feel that you must make a change to a product, try to work within the framework of the open source project and make your contributions to the community. This way, you will learn from their experience as they learn from yours.
