Design Model

The design model contains an expression of the logical structure and behavior of the application's main objects. At the highest level, the design model is partitioned into architectural tiers (i.e., client, presentation, business, and data).

Client Tier

The client tier is limited to the objects and collaborations that execute in the client browser. Each Web page in this application contains a pop-up menu implemented with JavaScript. The menu is modeled by the «client script object» menu. Most pages define two instances of the menu: one main menu (actionMenu) and one submenu (browseMenu).

The Menu class contains member variables of type Array, shown in Figure E-7 as associations to the JavaScript Array object. The complete JavaScript 1.3 object model is included in this application's model as a reference.

Figure E-7. Use of menu «client script object» Menu class

Presentation Tier

The majority of the work in this application is in the presentation tier. In this application, the navigational control is left to the individual pages; there is no single controller, as might be found in MVC-based applications. This application uses custom JSP tags extensively. The tag library is modeled as a «tag library» stereotyped subsystem and is seen in Figure E-8 modeled by the Entry Tags subsystem. In this diagram, the server pages index.jsp and listing.jsp both use the library.

Figure E-8. Web pages involved in Browse use case

The Entry Tags library contains three tag definitions: EntryList, EntryLoop, and Entry. Figure E-9 shows the «JSPTag» stereotyped elements with stereotyped dependencies to their implementation classes. Each tag defined here also defines several scripting variables that can be used in the tag body. These variables are modeled as «scripting variable» stereotyped attributes. The other attributes of the «JSPTag» elements are the tag attributes, the legal attributes that can be specified when using a JSP custom tag. For example, in the following code fragment, the Entry tag specifies the entryid and convertLineBreaks tag attributes and uses the term and description scripting variables in the body's tag. A detailed view of the classes that make up the tag implementation classes is shown in Figure E-10. The TEI classes are required for all tags that define scripting variables.

Figure E-9. JSP tag definitions

Figure E-10. Entry Tag's implementing classes

The JSP interacts with the entity tier through the tag implementation classes. All communication to the entity-tier components is via the custom tags (Figure E-11). This allows the JSP source to have a minimal amount of Java code and instead contain mostly HTML or HTML-like code.

Figure E-11. EntryListTag interacting with entity-tier objects

The EntryList tag is required in every JSP that uses the tags and must be a parent tag to the other two tags: EntryLoop and Entry. The EntryList tag is responsible for connecting to the Glossary entries, which are then made available by the other two tags. The EntryLoop tag is used to get entry values that are part of a list, as would be the case when browsing. The Entry tag is used when only one entry is required, as is the case in the entry view and editing pages.

The tags are also responsible for ensuring that the encodings of the entity values are appropriate for HTML. This means that string values in entry attributes should convert less-than and greater-than characters to the appropriate HTML: < and >.

Entity Tier

The entity tier in this application has only one true entityEntryand one entity managerGlossary. An additional class acts as a wrapper for an entry query. This class combines all the search criteria information and makes it easier to cache and to pass along to the Glossary. An instance of this class is cached in the user's session (HttpSession) in the presentation tier. The interfaces for the main entity-tier classes are shown in Figure E-12, and the classes that implement them are shown in Figure E-13.

Figure E-12. Key entity-tier interfaces

Figure E-13. Main entity classes

Data Tier

The logical data model is very simple and was intended to use only a minimal number of database features, in order to be portable across many relational databases. In this reference application, the mySQL database was used, but this application has also been successfully used with SQL Server, Oracle 8, and even MS Access. The only real requirement is to support standard SQL and to have a JDBC (Java Database Connectivity)-compliant driver.

Figure E-14 shows the database diagram, which contains two tables: PK and Entry. The PK table is simple and is used for primary key creation. One column in this table contains the name of another database tablein this case, there is only one row for the Entry table. The other column is an integer-type column that keeps the value of the next primary key for the table. To get a new primary key, the application must lock the row, get its value, increment it by 1, and then unlock the row.

Figure E-14. Logical data model diagram

The Entry table contains all the attributes of the glossary entry. Versions are managed by a self-referential foreign key (FK). When this FK is null, the entry row is considered to be the current version. When this row is updated, the columns in the row are not updated; rather, another row is inserted into the database, and the FK of the original row is set to the new row. This simple mechanism for versioning database rows works well enough for an application like this, with an expected low volume of use.