SlideShare ist ein Scribd-Unternehmen logo
1 von 32
Downloaden Sie, um offline zu lesen
DESIGN PATTERNS IN THE
ELECTRONIC DOCUMENT
MANAGEMENT DOMAIN
Copyright © 1998 Glen B Alleman, Niwot Ridge Consulting, Inc.
All Rights Reserved
The concept of a design pattern is based on the seminal work of Christopher Alexander
[Alex79], [Alex77]. The language of design was structuredinto patternsof design using a pattern
language. This pattern language concept was adopted by a group of computer science authors
referred to as the Gang of Four (GoF) [Gamm95]. These pioneers discovered the value of
isolated patterns thatcapture the wisdom of software design. Their patterns were more
structured and less interdependent than Alexander’surban planning concepts. After the GoF
book, there have been numerous texts, articles, and web sites dedicated to the creation and
analysis of patterns. Many of these publications areaimed at the analysisof the design process.
Recently the conceptof implementation and deployment using design patterns has moved into
the limelight [Gran98].
Design patterns capture the static and dynamic structures of soultions that occur repeatedly
when producing applications in a particular context. Becausethey address fundamental
challenges in software system development, design patterns are an important technique for
improving the quality of softwaresystems. Thesechallenges includethe communication of
architectural knowledge among the developers and system integrators, accommodating a new
design paradigm or architectural style, and avoiding development and deployment trapsand
pitfalls that are usually learnedonly by experience.
This White Paper describes the design patterns that are applicable to the ElectronicDocument
Management domain. These includeManagement of Change, Hypermedia Navigation,
Aggregated Relationships, Object to Relational Database Mapping, Compound Documents,
and Data Entry Management. The primary source of design patterns and the Frameworksthat
surround them is generated through the Pattern Language of Programs (PLoP) conference
series, which began in 1994. The patterns described here are a compendium of many of the
PLoP patterns, pattern language discussion groups, and a widerange of academicand industry
white paper. All of which have been adapted to the EDM System domain.
The primary motivation for this pattern-based approach is to codify the current EDM System
product domain into a vendor independent architecture. This architecture containsnot only the
essentialcomponents of a functionalsystem, but the subtle aspects of integrating document
management applications with line of business application such as ERP, PDM, and general
business control systems.
– 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 –
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 –
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 –
1.2 POSSIBLE SOLUTIONS
1.3 IMPACTS ON EDM SYSTEM ARCHITECTURE
– 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 –
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 –
 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 –
 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 –
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 –
 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 –
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 –
4 PROJECT MANAGEMENT PATTERNS
4.1 GENERATIVE DEVELOPMENT
4.2 SYSTEM TESTING PATTERNS
4.3 RISK MANAGEMENT PATTERNS
– 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 –
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 –
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 –
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 –
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 –
(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 –
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 –
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 –
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 –
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 –
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 –
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
– 26 –
SOLUTION
CONSEQUENCES
RELATED PATTERNS
6.7 NAVIGATING FOREIGN KEY TABLES AS OBJECTS
6.8 ERROR HANDLING PATTERNS
– 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 –
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 –
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 –
[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 –
[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 –
[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.

Weitere ähnliche Inhalte

Was ist angesagt?

Capabilities based planning
Capabilities based planningCapabilities based planning
Capabilities based planningGlen Alleman
 
Heliotropic Abundance
Heliotropic AbundanceHeliotropic Abundance
Heliotropic AbundanceGlen Alleman
 
Integrated master plan methodology (v2)
Integrated master plan methodology (v2)Integrated master plan methodology (v2)
Integrated master plan methodology (v2)Glen Alleman
 
Increasing the Probability of Project Success with Five Principles and Practices
Increasing the Probability of Project Success with Five Principles and PracticesIncreasing the Probability of Project Success with Five Principles and Practices
Increasing the Probability of Project Success with Five Principles and PracticesGlen Alleman
 
Integrated Master Plan and Integrated Master Schedule
Integrated Master Plan and Integrated Master ScheduleIntegrated Master Plan and Integrated Master Schedule
Integrated Master Plan and Integrated Master ScheduleGlen Alleman
 
Building the Performance Measurement Baseline
Building the Performance Measurement BaselineBuilding the Performance Measurement Baseline
Building the Performance Measurement BaselineGlen Alleman
 
Connecting it and business value
Connecting it and business valueConnecting it and business value
Connecting it and business valueGlen Alleman
 
Improving Project Performance in the DOE
Improving Project Performance in the DOEImproving Project Performance in the DOE
Improving Project Performance in the DOEGlen Alleman
 
Earned value, XP and government contracts
Earned value, XP and government contractsEarned value, XP and government contracts
Earned value, XP and government contractsGlen Alleman
 
A Gentle Introduction to the IMP/IMS
A Gentle Introduction to the IMP/IMSA Gentle Introduction to the IMP/IMS
A Gentle Introduction to the IMP/IMSGlen Alleman
 
Brownfields agile draft v11
Brownfields agile draft v11Brownfields agile draft v11
Brownfields agile draft v11tony1234
 
Build an integrated master plan and integrated master
Build an integrated master plan and integrated masterBuild an integrated master plan and integrated master
Build an integrated master plan and integrated masterGlen Alleman
 
Six ½ Day Sessions on the Road To Becoming a CAM
Six ½ Day Sessions on the Road To Becoming a CAMSix ½ Day Sessions on the Road To Becoming a CAM
Six ½ Day Sessions on the Road To Becoming a CAMGlen Alleman
 
DHS - Using functions points to estimate agile development programs (v2)
DHS - Using functions points to estimate agile development programs (v2)DHS - Using functions points to estimate agile development programs (v2)
DHS - Using functions points to estimate agile development programs (v2)Glen Alleman
 
The editors bookshelf
The editors bookshelfThe editors bookshelf
The editors bookshelfGlen Alleman
 
Establishing the Performance Measurement Baseline
Establishing the Performance Measurement BaselineEstablishing the Performance Measurement Baseline
Establishing the Performance Measurement BaselineGlen Alleman
 
Cure for cost and schedule growth
Cure for cost and schedule growthCure for cost and schedule growth
Cure for cost and schedule growthGlen Alleman
 
Establishing schedule margin using monte carlo simulation
Establishing schedule margin using monte carlo simulation Establishing schedule margin using monte carlo simulation
Establishing schedule margin using monte carlo simulation Glen Alleman
 
From arms race to green space
From arms race to green spaceFrom arms race to green space
From arms race to green spaceGlen Alleman
 

Was ist angesagt? (20)

Capabilities based planning
Capabilities based planningCapabilities based planning
Capabilities based planning
 
Heliotropic Abundance
Heliotropic AbundanceHeliotropic Abundance
Heliotropic Abundance
 
Integrated master plan methodology (v2)
Integrated master plan methodology (v2)Integrated master plan methodology (v2)
Integrated master plan methodology (v2)
 
Increasing the Probability of Project Success with Five Principles and Practices
Increasing the Probability of Project Success with Five Principles and PracticesIncreasing the Probability of Project Success with Five Principles and Practices
Increasing the Probability of Project Success with Five Principles and Practices
 
Integrated Master Plan and Integrated Master Schedule
Integrated Master Plan and Integrated Master ScheduleIntegrated Master Plan and Integrated Master Schedule
Integrated Master Plan and Integrated Master Schedule
 
Building the Performance Measurement Baseline
Building the Performance Measurement BaselineBuilding the Performance Measurement Baseline
Building the Performance Measurement Baseline
 
Connecting it and business value
Connecting it and business valueConnecting it and business value
Connecting it and business value
 
Improving Project Performance in the DOE
Improving Project Performance in the DOEImproving Project Performance in the DOE
Improving Project Performance in the DOE
 
Earned value, XP and government contracts
Earned value, XP and government contractsEarned value, XP and government contracts
Earned value, XP and government contracts
 
A Gentle Introduction to the IMP/IMS
A Gentle Introduction to the IMP/IMSA Gentle Introduction to the IMP/IMS
A Gentle Introduction to the IMP/IMS
 
Brownfields agile draft v11
Brownfields agile draft v11Brownfields agile draft v11
Brownfields agile draft v11
 
Build an integrated master plan and integrated master
Build an integrated master plan and integrated masterBuild an integrated master plan and integrated master
Build an integrated master plan and integrated master
 
WBS is Paramount
WBS is ParamountWBS is Paramount
WBS is Paramount
 
Six ½ Day Sessions on the Road To Becoming a CAM
Six ½ Day Sessions on the Road To Becoming a CAMSix ½ Day Sessions on the Road To Becoming a CAM
Six ½ Day Sessions on the Road To Becoming a CAM
 
DHS - Using functions points to estimate agile development programs (v2)
DHS - Using functions points to estimate agile development programs (v2)DHS - Using functions points to estimate agile development programs (v2)
DHS - Using functions points to estimate agile development programs (v2)
 
The editors bookshelf
The editors bookshelfThe editors bookshelf
The editors bookshelf
 
Establishing the Performance Measurement Baseline
Establishing the Performance Measurement BaselineEstablishing the Performance Measurement Baseline
Establishing the Performance Measurement Baseline
 
Cure for cost and schedule growth
Cure for cost and schedule growthCure for cost and schedule growth
Cure for cost and schedule growth
 
Establishing schedule margin using monte carlo simulation
Establishing schedule margin using monte carlo simulation Establishing schedule margin using monte carlo simulation
Establishing schedule margin using monte carlo simulation
 
From arms race to green space
From arms race to green spaceFrom arms race to green space
From arms race to green space
 

Ähnlich wie Design Patterns in Electronic Data Management

Developer's guide to customization
Developer's guide to customizationDeveloper's guide to customization
Developer's guide to customizationAhmed Farag
 
Dynamo with robot structural
Dynamo with robot structuralDynamo with robot structural
Dynamo with robot structuralTPHCM
 
Knowledge management and information system
Knowledge management and information systemKnowledge management and information system
Knowledge management and information systemnihad341
 
Why And Ontology Engine Drives The Point Cross Orchestra Engine
Why And Ontology Engine Drives The Point Cross Orchestra EngineWhy And Ontology Engine Drives The Point Cross Orchestra Engine
Why And Ontology Engine Drives The Point Cross Orchestra EngineKuzinski
 
Why And Ontology Engine Drives The Point Cross Orchestra Engine
Why And Ontology Engine Drives The Point Cross Orchestra EngineWhy And Ontology Engine Drives The Point Cross Orchestra Engine
Why And Ontology Engine Drives The Point Cross Orchestra EngineKuzinski
 
Software Architecture And Software Design
Software Architecture And Software DesignSoftware Architecture And Software Design
Software Architecture And Software DesignSamantha Randall
 
Deploying Customizations across Microsoft dynamics ax 2012 environments
Deploying Customizations across Microsoft dynamics ax 2012 environmentsDeploying Customizations across Microsoft dynamics ax 2012 environments
Deploying Customizations across Microsoft dynamics ax 2012 environmentsTariq Rafique
 
Mohan_Dissertation (1)
Mohan_Dissertation (1)Mohan_Dissertation (1)
Mohan_Dissertation (1)Mohan Bhargav
 
[EN] PLC programs development guidelines
[EN] PLC programs development guidelines[EN] PLC programs development guidelines
[EN] PLC programs development guidelinesItris Automation Square
 
Nt1310 Unit 5 Core Technologies
Nt1310 Unit 5 Core TechnologiesNt1310 Unit 5 Core Technologies
Nt1310 Unit 5 Core TechnologiesAshley Gomez
 
Microsoft Dynamics CRM - XRM Advantage for Solution Builders Whitepaper
Microsoft Dynamics CRM - XRM Advantage for Solution Builders WhitepaperMicrosoft Dynamics CRM - XRM Advantage for Solution Builders Whitepaper
Microsoft Dynamics CRM - XRM Advantage for Solution Builders WhitepaperMicrosoft Private Cloud
 
Architecture centered publishing systems
Architecture centered publishing systemsArchitecture centered publishing systems
Architecture centered publishing systemsGlen Alleman
 
A Software Factory Integrating Rational & WebSphere Tools
A Software Factory Integrating Rational & WebSphere ToolsA Software Factory Integrating Rational & WebSphere Tools
A Software Factory Integrating Rational & WebSphere Toolsghodgkinson
 
Decommissioning with cclm in solution manager sp12
Decommissioning with cclm in solution manager sp12Decommissioning with cclm in solution manager sp12
Decommissioning with cclm in solution manager sp12Felix Cid Vera
 
Project Plan For Software Project Management Plan
Project Plan For Software Project Management PlanProject Plan For Software Project Management Plan
Project Plan For Software Project Management PlanJackie Ramirez
 
Software architecture for developers
Software architecture for developersSoftware architecture for developers
Software architecture for developersChinh Ngo Nguyen
 

Ähnlich wie Design Patterns in Electronic Data Management (20)

Developer's guide to customization
Developer's guide to customizationDeveloper's guide to customization
Developer's guide to customization
 
Displacing the Programmers
Displacing the Programmers Displacing the Programmers
Displacing the Programmers
 
Dynamo with robot structural
Dynamo with robot structuralDynamo with robot structural
Dynamo with robot structural
 
Knowledge management and information system
Knowledge management and information systemKnowledge management and information system
Knowledge management and information system
 
Why And Ontology Engine Drives The Point Cross Orchestra Engine
Why And Ontology Engine Drives The Point Cross Orchestra EngineWhy And Ontology Engine Drives The Point Cross Orchestra Engine
Why And Ontology Engine Drives The Point Cross Orchestra Engine
 
Why And Ontology Engine Drives The Point Cross Orchestra Engine
Why And Ontology Engine Drives The Point Cross Orchestra EngineWhy And Ontology Engine Drives The Point Cross Orchestra Engine
Why And Ontology Engine Drives The Point Cross Orchestra Engine
 
Software Architecture And Software Design
Software Architecture And Software DesignSoftware Architecture And Software Design
Software Architecture And Software Design
 
Deploying Customizations across Microsoft dynamics ax 2012 environments
Deploying Customizations across Microsoft dynamics ax 2012 environmentsDeploying Customizations across Microsoft dynamics ax 2012 environments
Deploying Customizations across Microsoft dynamics ax 2012 environments
 
Mohan_Dissertation (1)
Mohan_Dissertation (1)Mohan_Dissertation (1)
Mohan_Dissertation (1)
 
Cloud view platform-highlights-web3
Cloud view platform-highlights-web3Cloud view platform-highlights-web3
Cloud view platform-highlights-web3
 
[EN] PLC programs development guidelines
[EN] PLC programs development guidelines[EN] PLC programs development guidelines
[EN] PLC programs development guidelines
 
Bslsg131en 1
Bslsg131en 1Bslsg131en 1
Bslsg131en 1
 
Nt1310 Unit 5 Core Technologies
Nt1310 Unit 5 Core TechnologiesNt1310 Unit 5 Core Technologies
Nt1310 Unit 5 Core Technologies
 
Microsoft Dynamics CRM - XRM Advantage for Solution Builders Whitepaper
Microsoft Dynamics CRM - XRM Advantage for Solution Builders WhitepaperMicrosoft Dynamics CRM - XRM Advantage for Solution Builders Whitepaper
Microsoft Dynamics CRM - XRM Advantage for Solution Builders Whitepaper
 
Architecture centered publishing systems
Architecture centered publishing systemsArchitecture centered publishing systems
Architecture centered publishing systems
 
A Software Factory Integrating Rational & WebSphere Tools
A Software Factory Integrating Rational & WebSphere ToolsA Software Factory Integrating Rational & WebSphere Tools
A Software Factory Integrating Rational & WebSphere Tools
 
Decommissioning with cclm in solution manager sp12
Decommissioning with cclm in solution manager sp12Decommissioning with cclm in solution manager sp12
Decommissioning with cclm in solution manager sp12
 
Achievement Archive
Achievement ArchiveAchievement Archive
Achievement Archive
 
Project Plan For Software Project Management Plan
Project Plan For Software Project Management PlanProject Plan For Software Project Management Plan
Project Plan For Software Project Management Plan
 
Software architecture for developers
Software architecture for developersSoftware architecture for developers
Software architecture for developers
 

Mehr von Glen Alleman

Managing risk with deliverables planning
Managing risk with deliverables planningManaging risk with deliverables planning
Managing risk with deliverables planningGlen Alleman
 
Increasing the Probability of Project Success
Increasing the Probability of Project SuccessIncreasing the Probability of Project Success
Increasing the Probability of Project SuccessGlen Alleman
 
Process Flow and Narrative for Agile+PPM
Process Flow and Narrative for Agile+PPMProcess Flow and Narrative for Agile+PPM
Process Flow and Narrative for Agile+PPMGlen Alleman
 
Practices of risk management
Practices of risk managementPractices of risk management
Practices of risk managementGlen Alleman
 
Principles of Risk Management
Principles of Risk ManagementPrinciples of Risk Management
Principles of Risk ManagementGlen Alleman
 
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...Glen Alleman
 
From Principles to Strategies for Systems Engineering
From Principles to Strategies for Systems EngineeringFrom Principles to Strategies for Systems Engineering
From Principles to Strategies for Systems EngineeringGlen Alleman
 
Building a Credible Performance Measurement Baseline
Building a Credible Performance Measurement BaselineBuilding a Credible Performance Measurement Baseline
Building a Credible Performance Measurement BaselineGlen Alleman
 
IMP / IMS Step by Step
IMP / IMS Step by StepIMP / IMS Step by Step
IMP / IMS Step by StepGlen Alleman
 
Making the impossible possible
Making the impossible possibleMaking the impossible possible
Making the impossible possibleGlen Alleman
 
Program Management Office Lean Software Development and Six Sigma
Program Management Office Lean Software Development and Six SigmaProgram Management Office Lean Software Development and Six Sigma
Program Management Office Lean Software Development and Six SigmaGlen Alleman
 
Policy and Procedure Rollout
Policy and Procedure RolloutPolicy and Procedure Rollout
Policy and Procedure RolloutGlen Alleman
 
Integrated Master Plan Development
Integrated Master Plan DevelopmentIntegrated Master Plan Development
Integrated Master Plan DevelopmentGlen Alleman
 
Project Management Theory
Project Management TheoryProject Management Theory
Project Management TheoryGlen Alleman
 
Seven Habits of a Highly Effective agile project manager
Seven Habits of a Highly Effective agile project managerSeven Habits of a Highly Effective agile project manager
Seven Habits of a Highly Effective agile project managerGlen Alleman
 
Paradigm of agile project management (update)
Paradigm of agile project management (update)Paradigm of agile project management (update)
Paradigm of agile project management (update)Glen Alleman
 
The 5 Immutable principles of project management
The 5 Immutable principles of project managementThe 5 Immutable principles of project management
The 5 Immutable principles of project managementGlen Alleman
 
Deliverables based planning handbook
Deliverables based planning handbookDeliverables based planning handbook
Deliverables based planning handbookGlen Alleman
 
Integrating cost, schedule, and technical performance
Integrating cost, schedule, and technical performanceIntegrating cost, schedule, and technical performance
Integrating cost, schedule, and technical performanceGlen Alleman
 
Writing Proposal Text
Writing Proposal TextWriting Proposal Text
Writing Proposal TextGlen Alleman
 

Mehr von Glen Alleman (20)

Managing risk with deliverables planning
Managing risk with deliverables planningManaging risk with deliverables planning
Managing risk with deliverables planning
 
Increasing the Probability of Project Success
Increasing the Probability of Project SuccessIncreasing the Probability of Project Success
Increasing the Probability of Project Success
 
Process Flow and Narrative for Agile+PPM
Process Flow and Narrative for Agile+PPMProcess Flow and Narrative for Agile+PPM
Process Flow and Narrative for Agile+PPM
 
Practices of risk management
Practices of risk managementPractices of risk management
Practices of risk management
 
Principles of Risk Management
Principles of Risk ManagementPrinciples of Risk Management
Principles of Risk Management
 
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
Deliverables Based Planning, PMBOK® and 5 Immutable Principles of Project Suc...
 
From Principles to Strategies for Systems Engineering
From Principles to Strategies for Systems EngineeringFrom Principles to Strategies for Systems Engineering
From Principles to Strategies for Systems Engineering
 
Building a Credible Performance Measurement Baseline
Building a Credible Performance Measurement BaselineBuilding a Credible Performance Measurement Baseline
Building a Credible Performance Measurement Baseline
 
IMP / IMS Step by Step
IMP / IMS Step by StepIMP / IMS Step by Step
IMP / IMS Step by Step
 
Making the impossible possible
Making the impossible possibleMaking the impossible possible
Making the impossible possible
 
Program Management Office Lean Software Development and Six Sigma
Program Management Office Lean Software Development and Six SigmaProgram Management Office Lean Software Development and Six Sigma
Program Management Office Lean Software Development and Six Sigma
 
Policy and Procedure Rollout
Policy and Procedure RolloutPolicy and Procedure Rollout
Policy and Procedure Rollout
 
Integrated Master Plan Development
Integrated Master Plan DevelopmentIntegrated Master Plan Development
Integrated Master Plan Development
 
Project Management Theory
Project Management TheoryProject Management Theory
Project Management Theory
 
Seven Habits of a Highly Effective agile project manager
Seven Habits of a Highly Effective agile project managerSeven Habits of a Highly Effective agile project manager
Seven Habits of a Highly Effective agile project manager
 
Paradigm of agile project management (update)
Paradigm of agile project management (update)Paradigm of agile project management (update)
Paradigm of agile project management (update)
 
The 5 Immutable principles of project management
The 5 Immutable principles of project managementThe 5 Immutable principles of project management
The 5 Immutable principles of project management
 
Deliverables based planning handbook
Deliverables based planning handbookDeliverables based planning handbook
Deliverables based planning handbook
 
Integrating cost, schedule, and technical performance
Integrating cost, schedule, and technical performanceIntegrating cost, schedule, and technical performance
Integrating cost, schedule, and technical performance
 
Writing Proposal Text
Writing Proposal TextWriting Proposal Text
Writing Proposal Text
 

Kürzlich hochgeladen

Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
AI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarAI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarPrecisely
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Commit University
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopBachir Benyammi
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 

Kürzlich hochgeladen (20)

Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
AI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarAI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity Webinar
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)
 
201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
20150722 - AGV
20150722 - AGV20150722 - AGV
20150722 - AGV
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 Workshop
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 

Design Patterns in Electronic Data Management

  • 1. DESIGN PATTERNS IN THE ELECTRONIC DOCUMENT MANAGEMENT DOMAIN Copyright © 1998 Glen B Alleman, Niwot Ridge Consulting, Inc. All Rights Reserved The concept of a design pattern is based on the seminal work of Christopher Alexander [Alex79], [Alex77]. The language of design was structuredinto patternsof design using a pattern language. This pattern language concept was adopted by a group of computer science authors referred to as the Gang of Four (GoF) [Gamm95]. These pioneers discovered the value of isolated patterns thatcapture the wisdom of software design. Their patterns were more structured and less interdependent than Alexander’surban planning concepts. After the GoF book, there have been numerous texts, articles, and web sites dedicated to the creation and analysis of patterns. Many of these publications areaimed at the analysisof the design process. Recently the conceptof implementation and deployment using design patterns has moved into the limelight [Gran98]. Design patterns capture the static and dynamic structures of soultions that occur repeatedly when producing applications in a particular context. Becausethey address fundamental challenges in software system development, design patterns are an important technique for improving the quality of softwaresystems. Thesechallenges includethe communication of architectural knowledge among the developers and system integrators, accommodating a new design paradigm or architectural style, and avoiding development and deployment trapsand pitfalls that are usually learnedonly by experience. This White Paper describes the design patterns that are applicable to the ElectronicDocument Management domain. These includeManagement of Change, Hypermedia Navigation, Aggregated Relationships, Object to Relational Database Mapping, Compound Documents, and Data Entry Management. The primary source of design patterns and the Frameworksthat surround them is generated through the Pattern Language of Programs (PLoP) conference series, which began in 1994. The patterns described here are a compendium of many of the PLoP patterns, pattern language discussion groups, and a widerange of academicand industry white paper. All of which have been adapted to the EDM System domain. The primary motivation for this pattern-based approach is to codify the current EDM System product domain into a vendor independent architecture. This architecture containsnot only the essentialcomponents of a functionalsystem, but the subtle aspects of integrating document management applications with line of business application such as ERP, PDM, and general business control systems.
  • 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
  • 26. – 26 – SOLUTION CONSEQUENCES RELATED PATTERNS 6.7 NAVIGATING FOREIGN KEY TABLES AS OBJECTS 6.8 ERROR HANDLING PATTERNS
  • 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.