The Urakawa Project

The UML Class Diagrams presented here are in the PNG image format. This graphical format is convenient for printing and for having a quick overview of the architecture of the data model, and of the language-neutral API. It is a nice addition to the standard HTML API-doc.

It is however an inaccessible format for blind and visually impaired users, so instead we recommend checking either the HTML API-doc, or the full model definition which is written in the Java programming language. Power-users (i.e. developers) may prefer this option as well, as it makes it possible to use a regular Java IDE to efficiently browse the object-oriented source code.

The source for the data model is browsable online, at this address. However, we recommend setting-up a SVN account to be able to checkout the full code and use it offline.

The UML class diagrams shown here use some additional notations to better meet our design requirements. Here is a summary of the specificities:

• The arrows in blue-ish color are dependency relationships, whereas other arrows in gray denote generalizations.
• The blue annotations on the dependency arrows (name and multiplicity) provide additional specification. For example, they can represent associations with the specified navigability and multiplicity, and the given role-name is either 'aggregation' or 'composition'. When multiplicity is indicated on the arrow start side, the uni-directional navigability becomes bi-directional. Another case is when using the 'create' role-name: this provides additional information as to what instance types the entity can create. This representation system is not UML-standard, and has been introduced in this design representation in order to address the shortcomings of interfaces, in particular the inability to have outward associations.
• The class names in red are just for highlighting purposes, for a reader to visually locate actual implementations in the diagram (remember, the design contract is mostly expressed using interfaces).
• Some operations may have an '{Exceptions AnException, AnotherException}' annotation. This is used to show the full method signature including thrown exceptions. These exceptions are mostly used for assertion on method arguments, and they should be implemented and raised according to the full specification available in the design comments (not shown in the class diagram, please see the Java source code). Implementations of this error checking paradigm may vary, depending on language and performance considerations. Implementors may choose to use real exceptions in order to obtain a full stack-trace when errors occur, which facilitate debugging.
• Some operations are decorated with an 'initialize' stereotype. This means that they should *only* be called at initialization time, usually right after construction time.

The core document tree is really the spine of the multimedia presentation.

The SDK offers a built-in framework for receiving notification events when the core document tree is changed. The basic change events are structure-centric, but this can be easily extended to add support for more complex operations (e.g. changes on attached node properties).

The top-most object to access the data model is the Project, which contains a Presentation. This diagram is a broad overview of the architecture, including MetaData.

A Presentation is the document container. It is a complex place-holder for several factories, managers, etc. It is basically the host for most of the multimedia document functionality. This is an overview.

A Presentation is the document container. It is a complex place-holder for several factories, managers, etc. It is basically the host for most of the multimedia document functionality. This is the detailed overview.

The concept of media "Channel" is a first class citizen in the data model: this is the standard way of adding media objects to the core document tree.

This is the abstract layer of the media architecture, which can be used as-is. However, the toolkit exposes the concept of managed "Media Data" as a first-class citizen, which offers native support for media resource management (see the other media diagram).

This is the more concrete layer of the media architecture, which exposes the concept of managed "Media Data" as a first-class citizen, and offers native support for media resource management.

XML "properties" can be attached to the core document tree. They provide support for basic XML elements, attributes, and text nodes.

The built-in Undo-Redo framework is based on the Commands design pattern.

The core document tree can be navigated using a "Navigator" interfaces which simulates a virtual tree, from a selection of original nodes based on a well-defined selection criteria.

The "Visitor" design pattern offers an easy and logical way to browse the core document tree. The tree parsing logic is based on a depth or breadth-first traversal.