Heads up! These docs are for Portofino 3, which is a legacy product. Check out Portofino 4!

Posted by Giampiero Granatella
on June 17, 2009


In this tutorial, I'll show you the data model of the ticket tracker inside the one-click-start portofino package. This can be useful to understand better that example application.

A ticket tracker is an application to keep track of reported bugs or issues related to a project. Users can enter tickets directly, and these are managed and assigned to developers, testers, etc., who wiil work on them.

To better follow the model, I suggest that you download the one-click-start portofino, extract the files and launch your_dir/one-click-start-portofino-2.0.16/apache-tomcat-6.0.18/bin/startup.sh (or .bat if you use Windows). Your ticket tracker wiil start at http://127.0.0.1:8080/tt (use admin/admin to log in).

The class diagram

The following picture shows the class diagram of the ticket tracker.

As you can see in the model, there are eight classes, each with a certain number of attributes. There are also several relationships: one (User_UserGrp) is a many-to-many, the others are one-to-many's.
The main class is "Ticket", both in a "semantic" sense and in terms of number of attributes/relationships. The ticket has a priority ('hign', 'normal' or 'low'), a resolution ('resolved', 'not to be solved', 'duplicate', etc.), a type ('problem', 'new feature', 'improvement', 'maintenance'), and is associated to a project.
Also, it is interesting to see that it has tree different relationships with "User" to specify who reported the ticket, who is assigned to it, and who is  the approver.
Another interesting class is "Project". A project is a containter of tickets (as we've already seen) and of versions. Also, a project has a user in the role of leader.
Finally, User, UserGrp and User_UserGrp are the basic user model common to all Portofino applications, which can be set up easily using the "create user management" functionality upstairs.

A detailed view of the classes follows.

Ticket

ATTRIBUTE TYPE RELATED TABLE NOTE
code TEXT   the ticket code
project RELATIONSHIP project the associated project
type RELATIONSHIP ticket type the ticket type
description TEXT   a brief description of the issue
priority RELATIONSHIP priority the priority (low, medium, high)
resolution RELATIONSHIP resolution the resolution
state WORKFLOW   one of the worflow states
creation date DATE   the creation date
update date DATE   the last update date
summary TEXT   A brief summary
assigned to RELATIONSHIP User The user that has to fix it
reported by RELATIONSHIP User The user who inserted the issue
expiry date DATE   the expiry date
approver RELATIONSHIP User The user that has to declare the resolution
close date DATE   The date when the issue is closed

Priority

ATTRIBUTE TYPE RELATED TABLE NOTE
name TEXT   e.g. 'high', 'normal', 'low'

Project

ATTRIBUTE TYPE RELATED TABLE NOTE
name TEXT   the project's name
url TEXT   the website url
description TEXT   a brief description
code TEXT   a short code
leader RELATIONSHIP User the project leader

Version

ATTRIBUTE TYPE RELATED TABLE NOTE
name TEXT   The version name
description TEXT   a brief description
planned date DATE   the planned date
actual date DATE   the actual date
project RELATIONSHIP project the related project

Ticket type

ATTRIBUTE TYPE RELATED TABLE NOTE
name TEXT   'Improvement', 'maintenance', 'new feature', 'problem'
description TEXT   a brief description

Resolution

ATTRIBUTE TYPE RELATED TABLE NOTE
name TEXT   a short name
description TEXT   a brief description

User

ATTRIBUTE TYPE RELATED TABLE NOTE
login TEXT   user's login
password TEXT   user's password
email TEXT   user's email

UserGrp

ATTRIBUTE TYPE RELATED TABLE NOTE
name    TEXT    The group name (e.g. 'Users', 'User admins')     

User_UserGrp (as a relationship)

ATTRIBUTE TYPE RELATED TABLE NOTE
user RELATIONSHIP User user reference
user group RELATIONSHIP UserGrp group reference

State Diagram

The following picture shows a state diagram of the workflow associated to a ticket (workflow attribute 'state' in class 'Ticket').

 

Briefly a ticket is 'open' when an user reported it. The ticket is then associated to a user, who'll work on it and change its state to 'work in progress'. When the ticket is resolved, it change is state to 'Resolved', if the approver is satisfed by the "resolution" it can close the ticket or alternatively it can bring it in the "Work in progress" state.
 

State
open
work in progress
resolved
closed

Transition from state to state
start work open work in progress
resolve ticket open resolved
close ticket open closed
reopen ticket work in progress open
resolve ticket work in progress resolved
start rework resolved work in progress
close ticket resolved closed
reopen ticket resolved open
reopen ticket closed open

Conclusions

This tutorial has shown the ticket tracker's data model and gave a quick glance at the workflow model. There is much more to say about the workflow model, but this will be the subject of another tutorial. So stay tuned!