Bug Base: Concepts

• Architecture
• User Model
• Bug Reports
• Updates

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.

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.

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.

• 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).

• 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.

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.