The concept of a design pattern is based on the seminal work of Christopher Alexander
This White Paper describes the design patterns that are applicable to the Electronic Document Management domain. These include Management of Change, Hypermedia Navigation, Aggregated Relationships, Object to Relational Database Mapping, Compound Documents, and Data Entry Management.
2. – 2 –
TABLE OF CONTENTS
1 INTRODUCTON ................................................................................................. 4
1.1 PROBLEM DOMAIN ................................................................................................... 4
1.2 POSSIBLE SOLUTIONS................................................................................................ 5
1.3 IMPACTS ON EDM SYSTEM ARCHITCEUTRE............................................................... 5
2 PATTERNS AND THEIR USE IN COTS APPLICATIONS........................... 6
2.1 PATTERN DEFINITION .............................................................................................. 6
2.2 BENEFITSOF USING PATTERNS................................................................................. 8
2.3 A TEMPLATE FOR THE EDM DOMAIN...................................................................... 9
2.4 ANTI–PATTERNS..................................................................................................... 11
3 FRAMEWORKS AND COMPONENTS IN EDM SYSTEMS........................12
3.1 PATTERN LANGUAGES AND SYSTEM INTEGRATION................................................. 12
3.2 FRAMEWORKS FOR EDM SYSTEMS.......................................................................... 12
3.3 UML AND PATTERNS.............................................................................................. 12
4 PROJECT MANAGEMENT PATTERNS........................................................13
4.1 GENERATIVE DEVELOPMENT................................................................................. 13
4.2 SYSTEM TESTING PATTERNS.................................................................................... 13
4.3 RISK MANAGEMENT PATTERNS............................................................................... 13
5 SYSTEM ARCHITECUTURE PATTERNS.....................................................14
5.1 SOME GENERAL SYSTEM INTEGRATION PATTERNS................................................. 14
5.2 ESSAY BASED PARADIGMS FOR INFORMATION DELIVERY........................................ 14
5.3 CLIENT–DISPATCHER–SERVER: PRINT SERVERS AND THE LIKE............................... 14
5.4 LEGACY SYSTEM INTEGRATION USING MESSAGE QUEUES....................................... 14
6 SYSTEM DESIGN PATTERNS.........................................................................15
6.1 THE CATERPILLAR’S FATE....................................................................................... 15
6.2 LAZY OPTIMIZATION.............................................................................................. 20
6.3 ACCOUNT NUMBERPATTERN ................................................................................. 20
6.4 CHECKS PATTERN................................................................................................... 20
6.5 NEW CLIENTS WITH OLD SERVERS.......................................................................... 20
6.6 PATTERN LANGUAGES FOR OBJECT-RDMS INTEGRATION...................................... 20
6.6.1 Table Design Time: When to Layout the Tables? .......................................... 22
6.6.2 Representing Objects to Tables..................................................................... 24
6.6.3 Representing Object Relationships as Tables................................................. 24
6.6.4 Representing Inheritance in a Relational Database......................................... 24
6.6.5 Representing Collections in a Relational Database......................................... 25
6.6.6 Representing an Object’s Identity.................................................................. 25
6.6.7 Foreign Key References................................................................................ 25
6.6.8 Foreign Key Versus Direct Reference ........................................................... 25
6.7 NAVIGATING FOREIGN KEY TABLES ASOBJECTS.................................................... 26
6.8 ERROR HANDLING PATTERNS................................................................................. 26
7 EDM SYSTEM PATTERNS.............................................................................. 27
7.1 FRAMEWORK FOR THE EDM SYSTEM DOMAIN........................................................ 27
7.2 MANAGEMENT OF CHANGE PATTERNS................................................................... 27
7.2.1 Using the Observer Pattern for MoC Routing............................................... 28
3. – 3 –
7.2.2 Patterns for Managing State: Document State Control................................... 28
7.2.3 Managing Hypermedia Links: Walking the Links........................................... 28
7.2.4 Organizational Multiplexing: Dealing with Heterogeneous Businesses ........... 28
7.3 WORKFLOW PATTERNS........................................................................................... 28
7.4 USER INTERFACE PATTERNS................................................................................... 28
8 REFERENCES.................................................................................................... 29
4. – 4 –
1 INTRODUCTON
This White Paper is motivated by the following forces:
The EDM System vendors have moved many of the client functions to the browser-
based environment. The consequencesof this migration are not well understood yet.
The integration of Line of Business databasesis stillconsidered an issueoutside the
norm of EDM Systems. This is not the actual case in practice, but the majority of
vendors have pushed this issueoff to system integratorsand third parties.
The EDM System market place has discovered Java based clientapplications and the object
mystic associated with Java. The use of Java on the client takesmany forms, ranging
from simple applets to full implementations of client application in Java applications. In
some cases the entire system is implemented in Java, both clientand server
applications.
1.1 PROBLEM DOMAIN
The vendors of EDM System have moved from supplying integrated solutions to
document management needs to supplying infrastructure which can be used to meet
document management needs. The integration and deploymentof the systems has moved
from the product vendors to system integrators. These system integrators have vertical
market expertise thatis added to the foundation software to produce a complete product.
Although this makes the proper business sensefor the EDM System vendors as well as the
system integrators, there are now gaps in the delivered product.
With the advent of web centric client applications accessto Line of Business databases
has become problematic. In the traditionalclient/server environmenta well define set
of SQL table access tools were available. Thesetools were tightlycoupled to the
programming language (VisualBasic, Powerbuilder, C) and formed an integrated
architecturefor accessing data and presenting it to the user, who in turn selected the
appropriate documents to be displayed. In the web centric model the identification of
the appropriate document and its displayoperateswith the confines of HTML, HTTP,
Java, and Active-X domains.
5. – 5 –
1.2 POSSIBLE SOLUTIONS
1.3 IMPACTS ON EDM SYSTEM ARCHITECTURE
6. – 6 –
2 PATTERNS AND THEIR USE IN COTS APPLICATIONS
Patterns are good, proven solutions to problemsthat recuroverand over in varioussystems [Corf98]. The
notation of patterns is not tied to any specificmethodology, programming languageor
business application. The domain of patterns and pattern languages ranges from software
development, organizational aspects of the business thatdevelop and use software, to
operational and political aspects of complex organizations. A pattern is a solution to a
problem in a specific context [Copl94]. Design patterns capturethe staticand dynamic
structure of solutions that occur repeatedlywhen producing applications in a particular
context [Copl95a].
Many of the attributes of patterns based design are shared by COTS based system
deployment: [SEI COTS Papers]
Recurring functionalitydefined by the needs of the end users
Well defined external behaviors, with changing internalbehaviors
Integration with multipleexternalsystems through a formal set of interfaces
2.1 PATTERN DEFINITION
A pattern is simply a form of documentation. This may appear simple atfirst but the form
of the documentation can be as importantas the content. Patterns did not spring from a
theoreticalbasis theyare the artifacts of successfulsolutions to recurring problems in the
work place. A pattern is a attempt to capturethe best practicein a domain and transfer that
knowledge to other practitioners. Patterns do not express new ideas theyexpress the tried
and proven within a given domain. The importanceof patterns is based on the fact thatthe
problems faced in building software based systems recur throughout the lifecycle of a
business.
7. – 7 –
Much of the work on patterns is based on architectChristopher Alexander and his pattern
language for creating townsand neighborhoods, house, gardensand rooms [Alex77]. [1] Alexander
defines a pattern as:
Each pattern describesa problem whichoccurs over and overagainin our environment,
and then describesthe core of thesolution to that problem, in such a way that you can use
this solution a million timesover, without ever doing it the sameway twice [Alex77].
There are two distinct pattern styles non–generative and generative. Non–generative patterns are
descriptiveand passive. Thesepatterns don’t imply anyspecific rationale. Apply them to
general problems may not lead to desirable results. Patternsdesignedto shape system
architectureare calledgenerative. Thesepatterns are prescriptive and active.
The writing of patterns has become as process unto itself (hence thisWhite Paper on EDM
System patterns). Since patterns are considered literature, the style and format of the
pattern is important to the process of communicating the idea. Patterns are expressed in
many forms and styles, theseinclude: [2]
The Alexandrian Style[Alex77] – which presents an archetypalpictureof the pattern,
followed by an introductory text, which setsthe context.
The Gang of Four (GoF) Style [Gamm95] – which is comprised of four essential
elements:
The pattern name
1 In the 1960’s building architects were exploring issues in design using computerized building
design tools. The mainstream of this movement moved on to modular construction techniques.
Christopher Alexander broke with that movement, noting that the great architectures of history
were not made with rigorous, planned designs, but that their piece were custom–fit to each other
and the buildings surroundings. He found recurring themes in architecture and captured them in
description that he called patterns. Software designers have rediscovered analogies between
Alexandrian patterns and software architecture.
2 All of this discussion about the form and structure of the language may appear useless to the
practical programmer. There is more happening here than meets the eye (or at least the initial
eye). The language and semantics of patterns conveys the content and meaning of the pattern.
Since patterns are the vehicle by which the solutions to recurring problems are expressed, it is
vital that this expression be free of any ambiguities. The literary form of a pattern is for more
important than the limited use of documenting a tried–and–true pattern. It is through the
extension of the pattern that others can come to understand the meaning of the documentation
outside the author’s domain.
8. – 8 –
When to apply the pattern
The elements of the pattern that makeup the solution
The consequences and trade–off of applying the pattern.
PLoP and Meszaros – which was derived from the August 1994 conference of Pattern
Languages of Program Design (PLoP) [Copl95]. This style includes:
Problem – which states the specificproblem to be solved
Solution – which describes the various solution to the stated problem
Context – which describes the constraints on the solution implied by the situation
Forces – which describes the contradictoryconsiderations to be considered when
choosing a solution to the problem
Portland Form – named after the initial users of this pattern who were from Portland,
Oregon (Tektronix)
Coplien Form – named after Jim Coplien’s report on PLoP ’94 [Copl94]
Sane’s – Aamond Sane summarized the discussion within one group at PLoP ’95 of
pattern as a story telling process for design decisions [Sane95]
Beck – Kent Beck developed the concept of pattern writing as story telling.
Beck and Johnson – Kent Beck and Ralph Johnson describe a pattern form which
includes a set of preconditions, including:
Preconditions
Problem
Constraints
Solution
2.2 BENEFITS OF USING PATTERNS
The advantage of using patterns has not been quantifiedin any academicsense. It is
questionableif nay good experimentalmeans can be designedand implemented to verify
that the use of patterns adds or subtracts for any metrics of software development.
There is ample anecdotalevidencethatpatterns do have a positive influence on the
outcome of software projects [Schm95], [Helm95], [Corf98]:
9. – 9 –
Patterns enable designersto communicate – at abstractlevels. Patterns introducea new
vocabulary. Each pattern name representsa word in this vocabulary, carrying with it all
the details in the actualpattern description. Designers can discuss the design using this
vocabulary withoutbecoming bogged down with all the details. This enables the
designers to discuss design decision more easily. For the EDM System COTS process,
the vocabulary of the system design can be separatedfrom the vendor’s product
vocabulary. There is currently no standard vocabularyfor EDM Systems that spans
vendors and sanctioned by an officialbody (AIIM for example).
Patterns ease communicationof design issues – across integration and deploymentteams. The
pattern vocabulary allowsdesign and integration groups to share subsystem designs as
well as interfaces. Different groups willhave a better understanding of the subsystems
they are responsible for.
Patterns ease architectural design communication – among the integrators, developers,
managers and users. The common vocabularyallows the participants in less technical
roles to better understand the system architecture withoutbecoming mired in the
system details.
Pattern simplify documentation – the system architecture and design documentation willnot
need as much detail when the pattern name is used.
Patterns enable reuse of the architecture – patterns should be platform independent. This
means that an architecture and design using a specific pattern should also be
independent of the platform and remain stable even with major changes of the
underlying implementation mechanisms. Only the implementation of the architecture
and design should need porting.
Patterns giveexpert knowledge to non–experts – system architects, designers and project
personnel with less experiencewillhaveaccessto expert solutions that are proven in
the market place.
2.3 A TEMPLATE FOR THE EDM DOMAIN
Using the pattern templatesdescribed abovea derivativeof the AGCS pattern template is
used for the EDM System domain [AGS]:
Pattern Name – should describe the problem, its solutions, and consequences in a word
or two. The naming of a pattern increases the design vocabulary. It lets the reader
10. – 10 –
design at a higher level of abstraction. Having a vocabulary for patterns lets the designer
talk about the pattern with colleagues, in the documentation in a form not found in
normal software developmentprocesses [Risi98]
Aliases – any other names for the pattern
Problem – a statement of the problem that this pattern resolves. The problem may also
be stated as a question.
Context – describes the contextof the problem. The context describes the constraints
on the solution. These are often implied through a situation rather than statedexplicitly
in the problem description.
Forces – each solution considers certain forcesto be in play that createthe problem
and the need for the solution. The solution optimizessome of these forces and ignores
others. The relativeimportance of the forces is determined by the context of the
pattern.
Solution – describes the elements that makeup the design, the relationship,
responsibilities and collaborations between theseelements. [3]
Resulting Context – describes thecontext of the solution.
Rationale – explainsthe rationalebehind the pattern and its use to solvea specific
problem
Consequences – are the results and tradeoffs of applying the patterns. Though the
consequences are often omitted from traditionaldesign methods, they are criticalfor
evaluating design alternatives and for understanding the costs and benefits of applying
the pattern. These consequencesoften concern spaceand time tradeoffs. Since reuseis
a factor in object oriented programming, the consequences of the pattern includes the
impact on a system flexibility, extensibility, or portability.
Known Uses – describes the situations in which the pattern can be applied.
Related Patterns – patternswhich are relatedto this pattern in form, fit or function.
Sketch of the Pattern – a pictorial description of the pattern (usuallygiven in UML).
Authors of the Pattern – the authors names or the as told by names
Date – the date the pattern was written
3 These relationships, responsibilities and collaborations are closely related to the Class
Responsibility and Collaboration notation called CRC Cards. CRC Cards are a unique mechanism
for capturing and documenting object behaviors without the introduction of Object Oriented
engineering notations.
11. – 11 –
References – a list of references cited in the pattern
Example – an example of the implementation. This can be code, pseudo code and is
optional.
2.4 ANTI–PATTERNS
It is important to consider the fact that patterns and pattern languages are removed from the
everyday world of programming and system integration. Patterns are visualization tools for
the system designers and architects – in the same way drawings and models used by
building architects. Carefulconsideration must be given to the use of patterns to avoid
simplifying the problem to fit the modeling tools. The concept of anti patterns is a means of
addressing this issue.
12. – 12 –
3 FRAMEWORKS AND COMPONENTS IN EDM SYSTEMS
3.1 PATTERN LANGUAGES AND SYSTEM INTEGRATION
3.2 FRAMEWORKS FOR EDM SYSTEMS
3.3 UML AND PATTERNS
13. – 13 –
4 PROJECT MANAGEMENT PATTERNS
4.1 GENERATIVE DEVELOPMENT
4.2 SYSTEM TESTING PATTERNS
4.3 RISK MANAGEMENT PATTERNS
14. – 14 –
5 SYSTEM ARCHITECUTURE PATTERNS
5.1 SOME GENERAL SYSTEM INTEGRATION PATTERNS
5.2 ESSAY BASED PARADIGMS FOR INFORMATION DELIVERY
5.3 CLIENT–DISPATCHER–SERVER: PRINT SERVERS AND THE LIKE
5.4 LEGACY SYSTEM INTEGRATION USING MESSAGE QUEUES
15. – 15 –
6 SYSTEM DESIGN PATTERNS
The EDM System domain consistsof a set of business requirements, which drive the
selection of COTS application. These applications usually meetsome percentage of the
business requirements, but not all the requirements. There are always gaps in the COTS
products that are filled by system integration components or changes in the business
process.
The System Design Patterns provided in this section address severalissues of defining,
deploying, operating, and maintaining COTS based EDM Systems, including:
Requirements gathering through a variety of means.
System analysis and the transition to system design and deployment.
Line of Business databasemapping from the analysisenvironmentto the SQL table
specification.
Integrity of the database indices.
6.1 THE CATERPILLAR’S FATE
Caterpillar’s Fateis a generative pattern languageused to support the transformation from
system analysis to system design. Just as the caterpillar undergoes a metamorphosisto
emerge as a butterfly, the Caterpillar’s Fatepattern explores the same magicof constructing
a system of objects from an object–free analysis.
PROBLEM
In the EDM System domain, the use of Commercial Off The Shelf software has become
the dominate form of deployment. If the EDM System vendors are to be believed, the
analysis processcan be reduced to comparing features from the various productofferings
and picking a winning system. Fast Tracking this processhas become the current fashion on
the vendor–centric conference and tradeshow circuit. This is no different than driving
down the local boulevard of cars and selecting your next purchasefrom the comfort of your
current automobile.
Without some clear understanding of the requirementsfor the purchase, the buyer is
subject to the whims of the marketplace and skillsof the sales force. Acquiring technology
16. – 16 –
to solve complex (and even simple) businessprocessesis not for the faint of heart. Some
form of guidance is needed to protect the buyer from the seller during the initial
specification phases of the project.
By starting with the system analysisphase, the EDM System project can move to the
system design phase with as little salesinfluenceas possible. There are several benefits:
The resulting system can reflect the actual businessneeds rather the availableEDM
System features and functions.
The architectureis the resulting system can be based on the business processesrather
than the architecture of the EDM System vendor.
CONTEXT
The selection of an appropriate solution using the feature analysis methods rarelyresults in
matching the system with the requirements. By comparing features the selection processis
based on statisticalaverages. An exampleof this approach is the correct statement thatthe
average temperature in Cheyenne Wyoming is a balmy 64 degrees – the average between
highs in the mid 90’s in the summer and lows well below zero in the winter.
Even using weighted averages for the selection criteria, the process focuses on the
differences or commonality of COTS products rather than the actual need of the system
owners. At some point to owners of the EDM System must clearly and concisely statewhat
the requirements are for the system and the metrics by which these requirementswillbe
met – independent of any product offering.
FORCES
The EDM System market place is mature – the differentiation between productsis
difficult.
In many cases the EDM Systems have becomeinfrastructure – picking a point solution
for an infrastructure need, leadsto redeploymentof the system.
SOLUTION
The capturing of architectural and system design knowledge can be done thorough the
following questions and modeling techniques:
17. – 17 –
Analysis Question Modeling Technique
What information is important in the
problem domain?
Information Modeling, Class diagrams,
Use Cases, EntityRelation Diagrams. All
these notations can be used to elicitthe
information requirements from content
specialist.
How does this information change over
time, and what incidents cause itto
change
State diagrams and CRUD (Create, Read,
Update, and Delete)diagramswhich
define the transformation of the
documents and the metadata as its
passes through the business processes.
Who are the users, and what tasks do
they turn to the system to get
accomplished?
User Task List based in the CRUD
Diagram. Use Cases are one mechanism
for capturing this information and
connecting it to the information model
and the workflow model.
What is the data flow for each task and
what documents are attached to the data
flow?
Workflow diagrams using workflow
modeling tools or simple pencil and
paper analysis.
Exactly how does the User Interface
work?
Prototyping of the User Interface
through some programmatic means to
demonstrate the look and feel of the
custom interface BEFORE the technical
merits of any system are examined.
How do these requirements map to the
available COTSproducts?
System requirementsanalysis basedon
business processes and non–functional
capability analysis of the available
systems. This assumes thatthere are
three (3) COTS offerings that can not be
distinguished on technicalmerit alone.
In the Caterpillar’sFate pattern there are 21 sub–patterns thatcan be used to develop
answers to the analysis questions above:
(1) Concurrent Threads of Execution – when the system contains process that run
simultaneously or semi–simultaneously, carefulplanning is necessary. One exampleof
such simultaneousoperation is the managementof drawings that participate in
concurrent engineering workflow. The requirementsfor the system are often stated
18. – 18 –
as functions to be performed, but rarely do they stateexactlyhow these functions will
be made available to the concurrent processes.
Therefore the threads of execution must have the abilityto exist independently from
other threads. In some cases these threads may exist on different machines, each with
their own agenda. The thread synchronization is performed through the
Synchronization of Concurrent Threads pattern (2). This approach provides for the
separate of concerns between the thread’s role in the process and the synchronization
between threads.
(2) Synchronization of Concurrent Threads –
(3) Collaborative Work Packages –
(4) Work Package Contents –
(5) Work Package Status –
(6) Work Package Completion –
(7) Work Package Priority –
(8) Work Package Security –
(9) Shape of the Software System–
(10) System Citizens –
(11) Decision Makers’ Role –
(12) Workers’ Role –
(13) Interfaces’ Role –
(14) InformationRole –
(15) Small Family Systems –
(16) Work Accomplished Through Dialogs –
(17) Critical Region Protection –
(18) Event Acquisition –
(19) Event Routing –
19. – 19 –
(20) User InterfaceRole isa Special Interface Role – as the behaviorsof the system are
transformed from the general capabilitiesdefined in (9)to specific capabilities, the
User Interface will become localized to the problem domain. The User Interface is
key to providing information and directionsto an application. The mapping of the
User Interface behavior to the underlying COTS behavior is criticalto the success of
the system. Deciding whatshould be the responsibility of the User and what should
be the responsibility of the system is difficult, and fraughtwith errors in judgement, if
a clear understanding of the businessprocess is not available.
(21) Data Knows Its Roots – once the collaborativeworks packages (3)havebeen identified,
the sources of the data can be determined. Good systemslivefor a long time and
over time they change. Any metadata thatmay havebeen created by the EDM
System may persist beyond the life of the softwaresystem that currentlymanagesthe
metadata. By separating the metadata about documents from the metadata used to
manage the document within the Electronic Vault, the system can evolve with the
changes in the business processes.
CONSEQUENCES
By focusing on the system requirements and their transformation into a system design, the
easy pickins of selecting a product and putting it to work may be lost. There are several
consequences:
The resulting system may be based on an ill–conceived architecture, in which the
components may meet the system requirements, but not be based on a well–defined
architecture.
The project sponsors may be weary of the detailed design process and push for the
purchase of a complete COTS system which just been demonstrated to the Board of
Directors. This is sometimes referred to as the airline magazinesyndrome. It goes like this:
A senior member of the executive staff just returned from a businesstrip. In the seat
pocket was an airlinemagazine, in which was a article describing how to solve the
problem at hand in three to five easy steps. The executive returnsthe homeoffice with the
magazine in hand and questions as to why the project staff is taking all thistime and
spending all thismoney, when the solution can be purchased from Vendor X?
20. – 20 –
AUTHOR
Norman L. Kerth, “Caterpillar’sFate: A Pattern Languagefor the Transformation from
Analysis to Design, Pattern Languagesof Program Design, editedby J. Coplien and D. Schmidt,
Addison Wesley, 1995.
6.2 LAZY OPTIMIZATION
6.3 ACCOUNT NUMBER PATTERN
6.4 CHECKS PATTERN
6.5 NEW CLIENTS WITH OLD SERVERS
6.6 PATTERN LANGUAGES FOR OBJECT-RDMS INTEGRATION
Relationaldatabases for the basis for nearly modern business applications. In many
instances theyare the foundation for Object Oriented applications as well. [4] This occurs
because:
The relational databasemodel is considered a legacy system that cannot be removed
from production.
The technology foundation of the relationaldatabasesystem has proven to be reliable
through years of testing and operations.
The table paradigm has a formal mathematical theory.
The performance of the databasehas been optimized for the application. In many
instances the transactionsthat makeuse of the databaseare complex. Document
enabling the transaction requires detailedunderstanding of both the database and the
user interface.
The report and query processes are welldeveloped.
The business rules are usually built into the databaseschema.
4 This set of patterns is taken from Kyle Brown and Bruce Whitenacks’s Crossing Chasms – A Patterns
Language for Object-RDBMS Integration, Copyright 1995, Knowledge Systems Corporation. The
premise in their paper is the full use of relational databases in the object paradigm. In the majority
of cases, the legacy database cannot be used in this way, since the tables and their contents are
used by several applications concurrently. The multiple schemas add another dimension to the
problem that cannot be solved through the mapping of tables to objects.
21. – 21 –
There are several weaknesses however in the relationalmodel when it is used with OO
based applications:
The limited modeling capabilities of tables does not match the rich modeling
capabilitiesof object orientedprogramming languages.
When complex operations are requested the performanceof the relational model is
weak.
There is a semantic mismatch between objectorientedprogramming languagesand the
table based relational model. In the table model there is a limited number of data types.
In the object programming there is potentiallyan infinitenumber of data type. This
mismatch is calledan impedance mismatch.
The source language (Java, C++, Smalltalk)has a semantic mismatch as well.
The majority of business application databases have been de-normalized for
performance reasons. The data integrityis difficultto maintain in this de-normalized
form, if the table-to-object mapping is performed in a naïve manner.
The amount of code needed to connect the databaseand map the tablesto objects is
large. The schema definitions of the databasemust be maintained to assure correctness
of the tables semantics as well as thetablecontents. Thismust be done in a potentially
changing databasedesign. Verification of the object-to-table mapping is currently a
manual process, prone to errors.
In the EDM System paradigm, table based indexing schemes are the norm. They represent
the vast majority of databaseindexing processes in most business, for all the reasons stated
above. The primary issue becomeshow to integratethese table-base external Lineof Business
databaseswith the emerging object oriented documentmanagementsystems?
In many instances the LoB tables not only exist, but must remain in use due to regulatory
requirements, other business application (documentenabling business applications), or
simply archivalpurposes. The challenge becomes how to bridgethe chasm that exists between
object oriented system design and the traditional tables basedrelationaldatabase design.
The following patterns havebeen chosen from the literature for their applicability to the
EDM System integration domain [OO-RDBMS Papers]. This is a continuing area of
research, but the impact on EDM System integration is unavoidable. The vendor’sare
22. – 22 –
moving rapidly to object oriented clientapplications, while maintaining relational database
servers. This is changing and the object-to-table mapping problem willincrease.
Table Design – when should tables be designed?
Representing Objects in Tables – how can objects be placed in relational tableswith the
least impedancemismatch?
Representing Object Relationshipsin Tables – how can the connections between
objects be stored in relationaldatabase tables?
Representing Inheritancein Relational Tables – how can simple inheritance be
implemented in tables?
Representing Collectionsin a RelationalDatabase
Representing an Object’sIdentity – how can an object be stored in a relationaldatabase
as an object with an object identifier? How can these object identifiers be managed?
Foreign Key References – how can tables with foreign key be mapped to objects?
Transaction Processing – how can multiple databasetransactions be performed within a
transaction block?
6.6.1 Table Design Time: When to Layout the Tables?
During the requirements analysis of the ED System, legacy business applications will be
document enabled using the facilitiesof the EDM System and the information contained in the
legacy application.
PROBLEM
During the System Requirements Analysis phaseof an EDM project, the business
processes will be discovered. Thesewillmost likelybe based on existing relational database
technology. By attached documentmanagement to these existing businessprocess, the
financial gain required for the project can be achieved.
The question becomes, when to define the databasetablesfor the object oriented EDM System?
FORCES
If there were no existing relational(or for that matter object oriented) database, then the
design of the document and workflow indexing schemas can be changed to match the
23. – 23 –
business needs. Oncethe system requirements beginsto focus on the databasedesign, the
object model implemented by the application program, the data componentsof the objects
will take precedence over the behavior and responsibilityof the object’s methods. The
result is an object model that willhaveseparated data and control. Although this is an
explicit design goal of federated systems basedon client / server technology, it is not a
desirable goal of an object oriented system. This leads to a design thathas emphasison
control and less emphasis on data object, rather than a balanced emphasis on data and
control. The result is an object oriented system design thatlooks likea traditionalclient /
server / SQL based design.
24. – 24 –
SOLUTION
CONSEQUENCES
RELATED PATTERNS
6.6.2 Representing Objects to Tables
PROBLEM
FORCES
SOLUTION
CONSEQUENCES
RELATED PATTERNS
6.6.3 Representing Object Relationships as Tables
PROBLEM
FORCES
SOLUTION
CONSEQUENCES
RELATED PATTERNS
6.6.4 Representing Inheritance in a Relational Database
PROBLEM
FORCES
SOLUTION
CONSEQUENCES
RELATED PATTERNS
25. – 25 –
6.6.5 Representing Collections in a Relational Database
PROBLEM
FORCES
SOLUTION
CONSEQUENCES
RELATED PATTERNS
6.6.6 Representing an Object’s Identity
PROBLEM
FORCES
SOLUTION
CONSEQUENCES
RELATED PATTERNS
6.6.7 Foreign Key References
PROBLEM
FORCES
SOLUTION
CONSEQUENCES
RELATED PATTERNS
6.6.8 Foreign Key Versus Direct Reference
PROBLEM
FORCES
27. – 27 –
7 EDM SYSTEM PATTERNS
7.1 FRAMEWORK FOR THE EDM SYSTEM DOMAIN
Content Creation
Author a document
Create compound document
Markup and Edit a document
Scan documents into the system
Content Management
Management of Change
Line of Business Index Management
Server side printing
Multiple site index and vaultmanagement
Content Consumption
Web delivery
Client based delivery
Content based retrieval
Line of Business Index
View / markup
Workflow initiation
Client Side Printing
7.2 MANAGEMENT OF CHANGE PATTERNS
The EDM Systems role can be dividedinto three major domains:
Content creation
Content management
Content consumption
The management of the content in conjunction with the authoring cycleis a component of
Management of Change (MoC). The processesand data associated with MoC are dynamic and
directly related to the state of the document at the timeof use. This management of
28. – 28 –
document state and the multiple relationshipsbetween the documentobjects depending of
the state makes up the core behaviors of the MoC function.
7.2.1 Using the Observer Pattern for MoC Routing
7.2.2 Patterns for Managing State: Document State Control
7.2.3 Managing Hypermedia Links: Walking the Links
7.2.4 Organizational Multiplexing: Dealing with Heterogeneous Businesses
7.3 WORKFLOW PATTERNS
7.4 USER INTERFACE PATTERNS
29. – 29 –
8 REFERENCES
[AGS] AGCS web site http://www.agcs.com/patterns/index.html
[Alex77] A Pattern Language, C. Alexander, S. Ishikawa, S. Silverstein, with M. Jacobson,
I. Fiksdahl–King and S. Angle, Oxford University Press, 1977.
[Alex79] A Timeless Way of Building, C. Alexander, Oxford University Press, 1979.
[Beed97] “cOOherentBPR: A Pattern Language to Build AgileOrganizations,” M.
Beedle, Proceeding PLoP 97, 1997.
[Booc94] Object Oriented Analysis and Design withApplications, G. Booch, Benjamin
Cummings, 1994.
[Boyd96] “Patterns of Association Objectsin Large ScaleBusiness Systems,” L. Boyd,
EuroPLoP Proceedings, 1996.
[Brow96] “Crossing Chasms, A Pattern Language for Object-RDMS Integration,” K.
Brown and B. Whitenack, WhitePaper, KnowledgeSystem Corporation, 1995,
shortened version found in [Vlis98]
[Brow97] Anti Patterns: Refactoring Software, Architectures and Project in Crisis, W. Brown, R.
Malveau, H. McCormick, and T. Mowbray. John Wiley & Sons, 1997.
[Bush97] Pattern–Oriented Software Architecture: A System of Patterns, F. Buschmann, R.
Meunier, H. Rohnert, P. Sommerlad, and M. Stal, John Wiley & Sons, 1997.
[Catt92] “Object Operations Benchmark,” R. Catell and J. Skeen, Communicationsof the
ACM, 17, 3, pp. 1-31, 1992.
[Catt97] The Object Database Standard: ODMG 2.0, R. Cattell, et al, Morgan Kaufmann,
1997.
[Cock96] “A Medical Catalog of Project Management Patterns,” A. Cockburn,
http://members.aol.com.acockburn/
30. – 30 –
[Cold97] “Form-Based User Interfaces, J. Coldewey, ProceedingsEuroPLoP 97, 1997.
[Cold98] “User Interface Software,” J. Coldewey, ProceedingsPLoP 98, 1998.
[Copl94] “Generative Pattern Languages: Am Emerging Direction of Software Design,”
C. Coplien, C++ Report, pp. 18 – 22, 66 – 67.
[Copl95] Pattern Languages of Program Design, J. Coplien and D. Schmidt, Addison Wesley,
1995.
[Copl95a] “A GenerativeDevelopment ProcessPattern Language,” J. Coplien in
[Copl95].
[Corf98] “An Overviewof Patterns,” R. Corfman, in The Patterns Handbook: Techniques,
Strategies, and Applications, collected and introduced by L. Rising, SIGS Reference
Library, 1998, pp. 19 – 29.
[Date94] An Introductionto DatabaseSystems, 6h Edition, C. Date, Addison Wesley, 1994.
[DRDA] “Distributed Relational Database Architecture (DRDA): An Open Database
Solution,” http://www.software.ibm.com/data.drda.html.
[Gamm95] Design Patterns: Elementsof ReusableObject–Oriented Software, E. Gamma, R. Helm,
R. Johnson and J. Vlissides, Addison Wesley, 1995.
[Garl95] “Architectural Mismatch or Why It’s Hard to Build Systems out of Existing
Parts,” D. Garlan, 17th
International Conference on SoftwareEngineering, 1995.
[Gera96] “A Federated Database for Hypermedia Developmentfor the WWW,” D.
Germán and D. Cowan, Department of Computer Science, Universityof
Waterloo, Waterloo Ontario, Canada, N2L 3G1, September 30, 1996.
[Gold96] “A Training Experiencewith Patterns,” B. Goldfedder and L. Rising,
Communications of theACM, 39, 10, pp. 60 – 64.
31. – 31 –
[Gran98] Patterns in Java: Volume 1 A Catalog of ReusableDesign Patterns illustrated withUML,
M. Grand, John Wiley & Sons, 1998.
[Hay96] Data Model Patterns: Conventionfor Thought, D. Hay, Dorest House Publishing,
1996.
[Helm95] “Patterns in Practice,” R. Helm, OOPSLA ’95 ConferenceProceedings, Addison
Wesley, 1995.
[Hirs96] “Three Tier Distributed Architecture,” R. Hirschfled, ProceedingsPLoP 96, 1996.
[Kell96] “RelationalDatabaseAccess Layers: A Pattern Language,” W. Keller and J.
Coldewey, Proceedings PLoP 96, 1996.
[Kell97] “Mapping Objects to Tables: A Pattern Language,” W. Keller, Proceedings
EuroPLoP 97, 1997.
[Kicz96] “Behind the Black Box: Open Implementation,” G. Kiczales, IEEE Software,
13, 1, January 1996.
[Kilo94] InformationModeling: An Object-Oriented Approach, H. Kilov and J. Ross, Prentice
Hall, 1994.
[Marm98] Apply UML and Patterns: An Introductionto Object-Oriented Analysis and Design, C.
Larman, Prentice Hall, 1998.
[Mart98] Pattern Languages of Program Design, 3, edited by R. martin, D. Riehle, and F.
Buschman, Addison Wesley, 1998.
[McCar95] Dynamics of SoftwareDevelopment, J. McCarthy, MicrosoftPress, 1995.
[Parn72] “On the Criteria to be Used in Decomposing Systems into Modules,” D.
Parnas, Communications of the ACM, 15, 12, pp. 1053-1058, 1972.
[Pete94] “Stars: A Pattern Languagefor Query Optimization Schema,” S. Peterson,
Proceedings of PLoP 94, 1994.
32. – 32 –
[Pete97] “HierarchicalStar Schema,” S. Peterson, Proceedings of PLoP 97, 1997.
[Rein96] “Storing and Using Objects in a RelationalDatabase, B. Reinwald, T. Lehman,
H. Pirahesh, and V. Gottemukkala, IBM System Journal, 35, 2, 1996.
[Renz97] “Three Layer Architecture,” K. Renzeland W. Keller, in SoftwareArchitectureand
Design Patterns in Business Applications, edited by M. Broy, E. Denert, K. Renzel,
and M. Schmidt, Technical Report TUM-I9746, TechnischeUniversität
München, 1997
[Risi98] “Pattern Writing,” L. Rising, The PatternsHandbook: Techniques, Strategies, and
Applications, collected and introduced by L. Rising, SIGS ReferenceLibrary,
1998.
[Rumb91] Object-Oriented Modeling and Design, J. Rumbaugh, M. Blaha, W. Premerlani, F.
Eddy, and W. Lorenson, Prentice Hall, 1991.
[Schm95] “Using Design Patterns to Develop Reusable Object–Oriented Communication
Software,” D. Schmidt, Communications of theACM, 38, 10.
[Sess96] Object persistence, Beyond Object Oriented Databases, R. Sessions, PrenticeHall, 1996.
[Ston96] Object-Relational DBMS’s, The Next Great Wave, M. Stonebraker with D. Moore,
Morgan Kauffman, 1996.
[Vlis95] Pattern Languages of Program Design, 2, edited by J. Vlissides, J. Coplien, and N.
Kerth, Addison Wesley, 1995.
[Webs95] Pitfalls of Object–Oriented Development, B. Webster, M & T Books, 1995.
[Weir97] “Architectural Stylesfor Distribution: Using macro-Patternsfor System
Design,” C. Weir, ProceedingsEuroPLoP 97, 1997.
[Wilk95] Using CRC Cards, N. Wilkinson, SIGS Books, 1995.