SourceForge Logo
An OpenFuture project
License
Downloads
Requirements
Sources, Binaries
CVS Repository
Installation
Build
Installing Binaries
Configuration
Documentation
Manual
Concepts
Testing Bug Base
Release Notes
Links
OpenFuture
BugBase Home
Project page at SourceForge

Bug Base: Concepts


Architecture

click to show image

Bug Base has a web based architecture using four servlets, a set of JSPs as web frontend and two applets for managing bug reports and administrating Bug Base.

The main servlet is BugBaseServlet. This servlet receives a serialized request object. Depending upon the query type is the behaviour of the servlet. It executes the desired query and returns the result wrapped into a query result object.

The persistency of Bug Base is realized with relational databases. Currently, two databases are supported: Hypersonic SQL for small sites and MySQL for sites with more bug traffic. For Hypersonic SQL, an own servlet is provided due to a design weakness. In the current version 1.6.0 of org.hsqldb.Serlvet, the database filename is not configurable, but it has to be set fixed in the constructor. This does not fit to the servlet API. Hence, we import the sourcecode of org.hsqldb.Serlvet in the hope, that this will be fixed in the future.

The communication with the main servlet is handled by BugBaseServletClient. This client is used both in the two applets and for the JSPs.

The JSP architecture follows the MVC paradigma. As central controller, the struts action servlet is used. Attributes that are used through the whole application are initialized by BugBaseJspServlet.

User Model

All bug reports of Bug Base have to be submitted by registered users. This allows a reliable answer channel to the author of a bug report.

For each installation of Bug Base, a set of user groups can be defined. Each bug report belongs to a certain user group. A user may only view those bug reports where he is member of the report's group. This way the access to bug reports can be controlled and restricted.

Each Bug Base installation contains at least three groups:

  • admin: Members of this group have access to the administration applet of Bug Base. Initially, the user 'admin' (with empty password) is member of this group.
  • doctors: Members of this group have access to the Bug Base Applet and may manage bug reports.
  • users: This is the default group. All users should be member of this group though this is currently not guaranteed by Bug Base.

Bug Reports

Bug Base can manage bug reports of different projects in the same instance. For each project a set of packages can be defined to enable fine grained control of the bug report subject.

The main entries of a bug report are the bug report title (which cannot be modified by the project team) and the report description. The project team has access to the description text and can use it to document the progress of the bug management.

Currently, bug reports have a very simple state model:

  • reported: This is the initial state, when a bug report has been newly submitted.
  • started: The project's team has started the bug fix.
  • fixed: The reported bug is fixed.
  • rejected: The reported bug is rejected by the project's team.
In the underlying model, bug reports have four date attributes for the bug status. From these date attributes, the state is derived:
  • If a date for rejected exists, the bug status is rejected.
  • Otherwise, if a date for fixed exists, the bug status is fixed.
  • Otherwise, if a date for started exists, the bug status is started.
  • Otherwise, the bug status is reported (this date should always exist).
Bug reports have also to be classified by the bug level:
  • severe: This bug report has to be managed with highest priority. The reported bug has severe impact in the project's functionality: loss of data, missing major functionality.
  • disturbing: The system is running and no data will be lost because of this bug.
  • nice to have: This is a bug, but the bug fix has low priority.
  • new feature: A modification of the specification.

Updates

During the development, the database structure may change. Hence, the database knows its own version. A version manager contains all updates, but only those updates may be executed, that belong to a newer version than the database version.

Database updates are very sensitive changes. Hence, updates are executed as transactions. If the transaction fails due to implementation errors of the update, a rollback of the transaction will be executed.


The Bug Base Project

Last modified: Sun Oct 28 18:56:00 2001