Browse Prior Art Database

Method for creating a cohesive data model for a pattern based design

IP.com Disclosure Number: IPCOM000201079D
Publication Date: 2010-Nov-08
Document File: 3 page(s) / 87K

Publishing Venue

The IP.com Prior Art Database

Abstract

This article describes how a cohesive data model can be built for a pattern-based design. The problem solved is how to build a single, cohesive, self contained data model for a design consisting of many pattern applications . Such a design is difficult to use because designers must merge the duplicate data from the different pattern applications, and must absorb extraneous information from pattern applications when examining the data fields. The core of the solution is to require descriptive pattern documents to declare objects and fields that are required for applications of the pattern; to update a single data model when applying patterns, either adding objects and data fields, or resolving references to existing objects/fields and augmenting them; and to store pattern applications in such a way that they hold references to the central data model

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 01 of 3

Method for creating a cohesive data model for a pattern based design

Overview

    This article describes how a cohesive data model can be built for a pattern-based design. The following description assumes that a tool exists for building pattern based designs, through the iterative application of design patterns into a single design document.

    The problem solved is how to build a single, cohesive, self contained data model for a design consisting of a selection of patterns (a.k.a pattern applications or pattern instances ). In such a design, pattern applications require the capture of data so the resulting design is useful to a designer - for example when selecting the COMMAND pattern (as originally described in Design Patterns: Elements of Reusable Object Oriented Software by Gamma et al), a designer may wish to know the name of the command that is needed, or an indication of whether the command should be undo-able. But associating data with each pattern application means duplication of the same data objects and fields within a design, and means there is no single source of data.

    Such a design is difficult to use because designers must merge the duplicate data from the different pattern applications, and must absorb extraneous information from pattern applications when examining the data fields. This leads to confusion and reduced productivity - for example if the data model is required for other development activities it must go through an error prone and time consuming extraction and merge process.

The core of the solution is to:
require descriptive pattern documents to declare objects and associated fields that are required for applications of the pattern
update a single data model when applying patterns, either adding objects and data fields, or resolving references to existing objects/fields and augmenting them.
finally, store pattern applications in such a way that they hold references to the central data model
There are two novel aspects to this invention, specifically:
(a) the creation of a cohesive, central data model for a pattern-based design, which is referred to from many pattern applications within that design
(b) an object resolution and augmentation process, where a central, distinct data model is gradually "augmented" or "grown" as patterns are applied
Known solutions: none known.

Related prior art: "Pattern-based Software Design", US patent 7197740 describes a technique for application development through patterns, but does not describe how a single cohesive data model for such a design is constructed
Detailed Description
(1) Pattern descriptions, in the form of XML-based documents that describe patterns, should declare the data that should be captured when the pattern is applied.

This declaration should include a type name and name-value pairs.

    E.g. the following may appear in the declaration of the COMMAND design pattern, indicating that a "CommandData" object with fields "Name" and "Undoable" should be captured whenever...