In this report we describe Time Calendar (TC) — a framework for visualizing and manipulating time information. The framework is being developed within the FRED (Framework Editor for Java) project to be used as an example framework when studying CASE tools supporting framework construction and usage (see, e.g., [Vil97] and [HHT97]). As in any real world case we expect the framework and its documentation to evolve in the future.
TC was designed to support work flow managing and reporting systems, such as the Work Flow Calendar — WFC, originally sketched by Carl-Erik Wikström (Major Blue Company). The main purpose of WFC is to make it easy for workers to write down hours they have spent consulting customers. Each worker uses a client application for updating her records. For the managers WFC provides basic database table management, various reports, and invoicing of customers. WFC utilizes a relational database.
We started developing TC by first implementing parts of WFC. We created the necessary database tables and a module for work flow reporting. For modifying and viewing other data in the database we implemented a component that can be used to manipulate the tables directly a row at a time. After that, we looked for possible framework topics within the application. We decided to develop the time information insertion, modification, and visualization as the main part of the framework. In addition, we created a separate framework to support simple client/server applications and message based communication. We also implemented a component to manage relational databases through a JDBC interface. The component can be extended to handle arbitrary database requests.
These mini framework components formed the core for two versions of the actual TC framework: the first can be used to visualize, modify, and update calendar information (related to the particular user) obtained from a local database. The other is a distributed client/server based framework in which several calendar clients communicate with a remote database server.
In the following, we first outline the purpose and data of the WFC application in order to illustrate possible extensions of TC. After that we describe the mini frameworks that TC utilizes, and finally we represent the two main versions of TC (the local and the remote version) derived from the core TC components. Because the difference between an application and a framework is often vague, these runnable systems can also be considered as applications.
The data stored in the WFC database are illustrated as an OMT class diagram in figure 1. Each class roughly corresponds to a database table. Each attribute and association could be implemented as a column. As usual when objects are stored in a relational database, some additional administrative columns are needed to represent object identities (e.g., product codes and contract numbers).
The attributes of a Worker include her name, ssn, and contact information. A
Worker can be a member in one or more Projects. The
Worker also has some abilities, i.e. she can provide some consulting services that can
be sold to the Customers. Each Worker must have at least one
UserAccount to access the WFC system.
A Customer is a company with name and contact information. There can be
Contracts associated with a Customer. If a
Product is subject to a Contract, a special pricing is used. A
Product in this case is always some form of consulting service provided by a
Worker. Every Product has a name, a description, a list price, and
a unit of measure (e.g., one consulting hour).
A Project is a unified effort of some Workers (project's
members) to provide a certain service for a Customer. A Project
has a name and description. Between the Project's start and end dates some
consulting work will be done for the Customer.
The WorkDone table represents provided consulting service. Every
WorkDone row associates a period of time with a Marker, which
in turn denotes a specific Worker (the one who did the work), a
Project (in which the work was done), and a Product (the
description of the service).
Figure 2 shows the client side user interface derived from the TC framework. The main window represents the time grid of the client. Its appearance can be parameterized differently for each application. In this case, the columns represent days and the rows hours in a day.
Each cell in the grid represents a potential time slice that can be associated with one or more markers. The semantics of the available markers depend on the application. In the case of figure 2, markers are the valid combinations of the service the user can provide and the projects that she is working on. Each marker has its own color. A time slice in the time grid is filled with the colors of the markers associated with it.
The user can add a new time slice by choosing the desired marker and selecting the necessary cells. Similarly, the user may modify and remove existing time slices. Modifications can be stored in the database. If the user wishes to edit the start and end times of a time slice in more detail, she may do that using the modification dialog (see figure 2). All commands are invoked from the calendar component's popup menu. Data is loaded from the database only as needed, i.e. when the user chooses to view dates whose contents are not yet loaded.
In this chapter we represent an overview of the TC framework (see figure 3). It provides functionality for handling time slices and markers: fetching them from the database, passing them as messages through sockets, and visualizing, editing and modifying them. An application developer can easily extend TC so that it handles any data needed to be associated with markers. Application developer can also provide parsers for importing time information from various formats, such as the vCalendar — The Electronic Calendaring and Scheduling Exchange Format [Ver96].
TC consists of mini frameworks each dedicated to some fairly independent subtask. All these mini
frameworks are implemented as separate Java packages. The calendar package
provides the basic time related concepts such as time slice, time grid, and marker. It can be
parameterized for different calendar granularities (e.g., hours in a day or days in a week). Also other
things such as the number of rows and columns visible at a time for the user and the amount of data
fetched from database at a time can be parameterized.
The ui package includes all the necessary user interface widgets and dialogs to
implement calendar applications. It makes use of the standard AWT widgets as well as the
GridControl class from Borland's JBCL library. On the user interface side,
the application developer can either use the provided calendar component without any modification, or
she can extend it with, for example, specialized dialogs to show marker data.
The database package uses the DataSet framework from JBCL library to
implement the database queries and to transform the results into Java objects. A separate
connection package provides reliable socket-based message passing connection
between remote hosts. The message package extends it by defining necessary
messages and their handlers to transfer time slices and other information between clients and a server.
The application package contains the local and remote versions of TC. They both
use the previously mentioned mini frameworks (the local version does not utilize the
message and connection packages) and form a platform for
specialized local and remote calendar applications.
In the future, the framework could utilize the Command pattern [GHJ95] to implement undo buffer for the user's edits. Also, some functionality needed in time table planning and resource allocation could be included in TC by combining it with the Time Manager framework described in [HTA97].
In figure 4 there is a snapshot from a running application derived from the remote version of the TC framework. The components of the system are represented as rectangles. The upper part of a rectangle lists the basic parameterized features provided by the core framework and the lower part the extensions the application developer have provided.
The server part of the TC system runs on a remote host waiting for clients. When a client connects the server via a socket the server starts a new thread for handling the communication between the client and the database. Client and server send each other messages over a socket connection. The core TC framework implements the basic message passing mechanism together with messages related to connection management, time slices, and markers. The application developer may also have defined new messages, e.g., for sending additional marker data.
Each client holds a time grid which consists of time slices. A time slice denotes a period of time and a
marker who owns the time slice. The client uses a dedicated user interface component
(CalendarPanel) to edit and visualize this information.
Back to the
Main Page of Time Calendar