Structure of the documentation

Design documentation is provided to illustrate different aspects of the software. Each design document has the following structure:

  • Introduction: A short introduction into the functionality and why it is necessary
  • Requirements: Outlining the basic requirements
  • Design: Describing the overall solution principle and basic ideas without mentioning classes, only the functional solution.
  • Structure: Describes relevant class diagrams.
  • Dynamics: Describes the most important scenarios to illustrate the dynamic behavior of the system.
  • Design Rules: Describes the main attention points when using the described designs, something like the highlights of the user manual of the design

Available Documentation

The following design documentation is available:

  • Framework documentation: Documentation of the generic frameworks used.
  • Application documentation: General design of the application itself and a description of how the frameworks were used.

Framework Documentation

  • Caching: Explains the caching support utilities used for application-level caching.

  • Persistence: Explains the persistence support utilities to make Hibernate persistence easier to use.

  • Concurrency: Explains concurrency support.

  • Security: Explains the security requirements and how they are realized.

  • User Management: Explains user management design.

Application Documentation

  • Model: The model used for the application and how authorization is used for it.

Architectural Roadmap

  • Use of a generic authorization mechanism to restrict access to photo albums based on user identity.
  • The current implementation of the photo albums is done directly on a file system. This will move to an implementation where the albums are maintained in a database together with metadata for the photos and albums. The current implementation will just become a storage bin for photos. This is because it is convenient to have direct access to photos and because storing photos as big binary objects in a database is generally not that efficient.
  • Concurrency for photo albums is implemented using standard JVM locking. Concurrency will also be delegated to the database to make it ready for clustered environments.
  • Use of a workflow engine. This is required for screen navigation (Tapestry does not really provide anything, although Struts like navigation can be done in Tapestry) and for other tasks such as online registration.
  • More strict separation of presentation and business tier. Currently, the photo album API is used directly in the presentation layer and this can encourage the implementation of 'business functionality' in the presentation tier, which is not desired.