The Document pattern lets you model documents, including structured documents and their users.
The Problem
The librarian's problem is the infinite, as one of the most famous librarians has pointed out, dreaming (perhaps) of an infinite number of hexagonal rooms, poorly lit, with books containing all possible combinations of the alphabet [Borges 1962]. The problem is to find the document that contains the information that you want among the huge volume of such things. As different media take hold in the publishing world, the librarian's job just gets more challenging.
The Solution
The Document pattern lets you describe the universe of documents that you choose to collect in your library. Figure 8-12 shows the Document pattern.
The first aspect of this pattern is the modeling of document types. Instead of using generalization for this, the pattern models the document types as a separate class using the Metamodel pattern. Because there are potentially an infinite number of kinds of documents with very little to distinguish them in structure or behavior, this provides a way to classify documents without complicating your design model. In this case, each document has a single type for classification purposes.
Next, you must represent copies and versions of documents. A document is the abstract concept of the document; a copy is a real instance of this abstraction. For example, Mark Twain's Huckleberry Finn is a document; the dog-eared copy on the third shelf from the left in Room 23 is a copy of the document. The key elements of the copy are a way to identify it and a location.
A version of a document is an abstraction, but at a finer grain than the document itself. There are two kinds of versions: the amendment and the edition. An amendent adds a second document that extends the first one and becomes (usually legally) a part of it. An edition replaces the document with a revised version. Continuing the Mark Twain example, someone can publish the original edition with an amending preface that contains biographical and historical material that sets the context. Another example is a contract document and later amendments to that contract that change the terms of the contract after the signing of revision of Huckleberry Finn based on an extensive analysis of original manuscripts and author's notes that extensively revises and adds to the material in the original edition of the book. The pattern assumes that you can have multiple versions but only one predecessor. That is, you can produce multiple branches of versions, but each branch leads back to a single document.
Figure 8-12: The Document Pattern
The Document pattern lets you associate topics with documents however you like. You can find a particular topic in any number of documents, and a particular document may address any number of topics. The structure assumes that a document can address no topics. This lets you create a document without indexing it immediately; it also lets you store documents that you cannot access through the topic index.
Discussion
Obvious applications of the document pattern apply to areas such as knowledge management or World Wide Web content searching and other indexing functionality. Going beyond such indexing and searching, the next step in document management is managing work flow. You can add in the Party pattern and connect it through roles to show how documents move from role to role in a work flow process. One such role could replace the Author attribute with a relationship to a Party. Others could link a Person as the current owner of the document, the signer of the document, or any other related role. You would also record the history of the process as a series of role ownership records.
You might also choose to extend the Document class hierarchy with inheritance while still continuing to use the DocumentType objects. This would give you two ways to classify documents, one relating to structure and behavior and the other as a purely abstract categorization. Both may be useful at different times for different reasons. For example, you may have structured information available for a document that you want to use to search or otherwise process the data. Rather than adding extensive metamodeling, it might prove more efficient to create subclasses in the database for different kinds of documents. For example, the IdentificationDocument hierarchy might contain detailed data that you could use for query purposes, or you might have fingerprint documents with special category elements useful in quickly searching for records.
Summary
A design pattern is a reusable system that describes a design problem and its solution. The generic pattern contains a number of elements:
A name
A problem description
A solution description
An abstract pattern is a pattern of classes and relationships that describe a generic solution to a generic problem. This chapter gave several examples of abstract data model patterns:
Singleton: Ensures that a class has only one instance in the database
Composite: Represents a tree structure made up of different kinds of related objects, all of which share the same interface; a part-whole hierarchy or parts explosion in your database
Flyweight: Uses sharing to reduce redundancy in the system (normalization)
Metamodel: Represents data about data to enable flexible and extensible data modeling
An analysis pattern is a model of concrete, domain-specific objects generalized for reuse in different situations. This chapter gave several examples of analysis patterns:
Party: Jointly represents people and organizations (entities)
Geographic Location: Represents an extensive variety of physical places
Process: Represents a flow-oriented manufacturing process
Document: Represents an extensive variety of documents and searching features
Abstract patterns and analysis patterns give you a leg up on your data modeling. The next chapter shows you how to get a clue as to how big the horse is that you're mounting.
Chapter 9: Measures for Success
O mighty! Dost thou lie so low? Are all thy conquests, glories, triumphs, spoils, Shrunk to this little measure? Shakespeare, Julius Caesar III.i.148
Overview
I considered titling this chapter "Measures of Success." I thought about it a little and instead opted to use the word "for." Measuring is not passive. It is an active, indeed aggressive approach to forcing success to emerge out of a situation. At its essence, measuring is feedback. It is the process of obtaining information to use to guide your work to a successful conclusion.
Many of the measurement efforts in which I've participated have been passive measurement. Passive measurement collects data because that's what professionals do, or because a consultant recommended it, or because
somebody's read a book. This is making measurement into a magical talisman, an amulet you can wear to ward off evil spirits. Although amulets may have their place, software development isn't it.
To measure aggressively, you must first know why you are measuring. What kind of feedback are you trying to get? Are you trying to decide whether your approach is too complex? Are you hoping to improve the quality of your product through measuring defect rates? Are you hoping to improve productivity? Are you trying to understand the effectiveness of the systems you've put in place to get results? If you can't articulate a specific reason for measuring, you shouldn't be measuring because you won't use the results.