27. document component design...

27. Document Component Design (1) file:///C:/Documents%20and%20Settings/glushko/My%20Documents/Lectures/243-S2008/24...

1 of 37 4/23/2008 8:39 AM

27. Document Component Design

DE + IA (INFO 243) - 23 April 2008

Bob Glushko


2 of 37 4/23/2008 8:39 AM

Plan for Today's Class

Improving the Design for Consolidated Components

Aggregate Components

Identifying Aggregates Via Normalization


3 of 37 4/23/2008 8:39 AM

After Consolidation, Then What?

We have now reached the point where we have captured the business rules and content components of the domain / document inventory in which we're working

We have separated the Presentational, Structural and Content Components

We have developed a conceptual model of our consolidated and essential "atomic" content components -- semantic equivalence classes

We will have some sense of the distribution of the content components and can distinguish those that are "core" -- that appear in all or almost all contexts in the domain -- from those that are more context-dependent

Now we have to ensure that we can reuse these components when we assemble document models from them


4 of 37 4/23/2008 8:39 AM

Why Analysis Models Aren't Good Enough

Document artifacts differ a great deal in how they combine content, structure, and presentation components

Some combinations are idiosyncratic and ad hoc or represent compromises between incompatible requirements that make structures less than optimal

If we are completely constrained by the artifacts as they exist in our component model, we will preserve both their good and bad aspects

So our analysis models of components and aggregates may need to be revised to allow alternative ways of satisfying our requirements


5 of 37 4/23/2008 8:39 AM

Design and Re-design with Conceptual Models

The component model may present many attractive options for re-design and reuse of our content components

Design means changing our model, not simply improving the way we view it. This is when we actually get to apply our insights about reuse and patterns

During design we can devise more consistent component names, remove repeating or reoccurring content and structure, increase reuse of standard patterns or components, replace implicit components with explicit ones, and otherwise create a more abstract, concise, and context-free representation of the essential characteristics


6 of 37 4/23/2008 8:39 AM

Analogy: The Build-to-Order Computer Factory

Designing a factory that makes "build-to-order" computers:

You might start with some collection of computers and take them apart to see what pieces are needed to assemble them (ANALYSIS)

Because you want to be able to make these items with reasonable quality but atless cost and at greater efficiency, you redesign the computers to use standard components (DESIGN FOR REUSE)

You organize the components and the assembly lines to make it easy to locate components when you get an order (ORGANIZE FOR REUSE)


7 of 37 4/23/2008 8:39 AM

Analogy: Designing a Flexible Domain Model

Analyze a set of hand-crafted applications with printed or online data entry forms to identity pieces of information each contains (ANALYSIS)

You want the complete "enterprise model" for the domain to be able to represent any application or form with less cost and at greater efficiency, you redesign the pieces of information from analysis to be more standard and context-free (DESIGN FOR REUSE)

Organize the components to make it easy to locate the components for the specific contextualized model for an application or form (ORGANIZE FOR REUSE)


8 of 37 4/23/2008 8:39 AM

Generalizing and Specializing Components

You can add a context qualifier to specialize a component rather than defining acompletely new one (this reuses the "base" component type and gives semantically similar components similar names)

In the Engineering Compendium both Figures and Tables have Captions, and the Caption is similar enough in both to allow it to be re-used by both.

This suggests components for FigureCaption, TableCaption

You can also "factor out" context to define a more general or abstract component that can be used more broadly

"Delivery Date" and "Ship Date" suggest a "Date" component


9 of 37 4/23/2008 8:39 AM

The Contextualization Continuum

Your set of components has to find a balance between precision and generality (or flexibility)

You want a set of components that can be reused across related document types in some context (or group of related contexts)

Contexts fit into a continuum

At one end is an extremely specific context in which component definitions are suitablefor a very narrow class of documents

At the other end is an extremely loose or general context, suitable for a very broad class of documents


10 of 37 4/23/2008 8:39 AM

Components: A Reminder

Components – the units of content

Any piece of information that has a unique label or identifier is a candidate component

Any piece of information that is self-contained and comprehensible on its own is a candidate component

A component is a logical unit, with no presentation implied; it may be organized structurally

These definitions are very helpful for finding (aggregate) components in some types of documents but less so in others

It depends on the presence of, and relationships with, the structural and presentational information


11 of 37 4/23/2008 8:39 AM

Motivating Aggregate Components

ATOMIC components that hold individual pieces of information

Especially in transactional documents,where atomic components have a natural representation as primitive data types or as datatypes that are derived from these by restriction

DOCUMENT components that assemble smaller components into the set ofinformation needed to carry out a self-contained purposeful activity

Especially in transactional contexts, where documents have a natural correspondence to some unit of work that initiates, records, or responds to a clearly-defined event

It is much more difficult to define the components of "in between" sizes, especially as you move away from the transactional end of the document type spectrum


12 of 37 4/23/2008 8:39 AM

Motivating Aggregate Components [2]

AGGREGATE components are composed of atomic ones and are reused in theassembly of document components

They are easier to identify in transactional contexts because they are often the key information that flows from one document to another

"Address" or "Person" are obvious examples of aggregates composed of smaller ones

Two key questions:

How do we select and group atomic components into aggregates?

How many aggregates should we create?


13 of 37 4/23/2008 8:39 AM

Identifying Two Kinds of Component Aggregates

Structural Aggregates -- sets of components defined by parent-child or containment relationships

One way to do this is by putting all the unique components on index cards and then sort them into clumps or clusters. First sort all the components that go together because of containment or structural rules (X contains Y and Z).

Conceptual Aggregates -- sets of components that "go together" because oflogical dependency

After you've identified all the structural aggregates, you can start to further cluster those intermediate clusters on the basis of dependency rules - what things "go together" logically


14 of 37 4/23/2008 8:39 AM

Identifying Aggregate Components in Non-Transactional Documents [1]

Aggregates are more elusive on the narrative end of the DTS because there arelimits to the rigor with which components can be grouped

"Mixed content" models arise when there are few or weak constraints on where atomic components can appear

Presentation often masks the atomic components in potential aggregates

Structures are often based on conventions for organization and presentation than on semantic relationships

But there will still generally be components that "go together" to form reusable structures


15 of 37 4/23/2008 8:39 AM


Aggregates can be created in two "bottom-up" ways that focus on the atomic components:

The first is by rebuilding or making explicit the structures that we took apart in document analysis

The second is by creating structure in "blobs" of poorly structured information written in an overly narrative style

A more modular style for the information will increase its regularity and reusability; it will eliminate content that has little value to users and reinforce its use as "boilerplate" or via links


16 of 37 4/23/2008 8:39 AM

Home Blueprint: Analysis Model

The layout doesn't reinforce the idea of reusable components and aggregates...

Every house has an exterior view, and an interior view for each floor

Each of these views has a caption/annotation

houseplan(theme,views,specs), view, (illustration+), illustration(figure,description+)


17 of 37 4/23/2008 8:39 AM

House Plan Redesign - Logical Aggregates


18 of 37 4/23/2008 8:39 AM

House Plan Redesign - Revised Presentation


19 of 37 4/23/2008 8:39 AM

Extracting Repetitions

Different aggregates might have the same components

"Contract" and "Shipment" might both have "Start Date," "End Date" and "Duration"

The repeated components can be extracted and created as a reusable aggregate

In this example we might call the common pattern the "Period"


20 of 37 4/23/2008 8:39 AM

Reuse of Existing or External Patterns [1]

Many of the patterns that you might identify as repetitions would have also beenidentified in a previous analysis of your domain or context

You should determine if their analysis yielded components for you to reuse

Pay particular attention to "standards" if they come from credible sources


21 of 37 4/23/2008 8:39 AM

Reuse of Existing or External Patterns [2]

But don't accept someone else's analysis and models if you don't understand them

And NEVER assume that a component model is appropriate solely on the basis of its name because:

Names aren't "self-describing"

Otherwise, why are we bothering to collect all the bits of metadata about each candidate component?


22 of 37 4/23/2008 8:39 AM


We also can identify aggregates via a kind of reverse engineering of the document models required or suggested by the context

We call this CORE PLUS CONTEXTS -- factoring a set of related documentmodels into the aggregates that are needed to assemble them


23 of 37 4/23/2008 8:39 AM

Identifying Aggregates in More Formal Ways

The heuristic and informal approach we just followed was called "document analysis" in the SGML/publishing/content management tradition

But these techniques are shaped by the skill and biases of the document analyst; they don't yield uniform results and don't scale well

If there is to be a discipline of Document Engineering, we need a more formal and deterministic modeling approach that is consistent with classical document analysis


24 of 37 4/23/2008 8:39 AM

Data Modeling Principles for Designing Content Components

The more transactional our design situation is the more we can (and need) to apply additional rules or requirements that apply to "data-intensive" components

Data Integrity– the information must be correct

Referential Integrity – repeated data components (in an "information supply chain" or set of documents)must agree in values

Identification Integrity – the identify of data should be unambiguous

These three principles embody the concept of Essentiality – the model containsonly the essential information with no duplication

Relational Theory is the basis for identifying essential components


25 of 37 4/23/2008 8:39 AM

Relational Theory

Mother of all data modeling approaches (Codd, 1970s; Date, 1980s)

Relational theory gets its name from the fact it defines relations, two dimensional matrix views of data, which we know better as tables

The focus of relational theory is …

Keys (essential data identification) - uniquely referencing structures- prevents identification integrity problems

Functional Dependency (essential data aggregates) - aggregating data into logical groups or sets (or relations, tables, entities, object classes)- prevents referential integrity problems

Normalization – formal techniques for identifying and defining functional dependencies;yields a set of progressively more rigorous "normal forms"


26 of 37 4/23/2008 8:39 AM

Normalization

Normalization is a formal technique for identifying and defining functional dependencies

The result is a set of models that describe the network of relationships within and between groups of logical components in optimal ways that minimize redundancy (and prevent the loss or corruption of information when instances are added or deleted)

Six steps: 1NF, 2NF, 3NF, BCNF, 4NF, 5NF1NF= First Normal Form, etc. (BCNF = Boyce/Codd Normal Form)

Often 3NF is considered adequate, but full normalization gives greater understanding of semantics


27 of 37 4/23/2008 8:39 AM

First Normal Form

The consolidated list of unique candidate components is equivalent to 1NF in relational theory

Make all of the components discrete – only take a single value in their set

Remove repeating sets of data into their own (new) set

Identify components that are keys

For example, an Order may contain components for item descriptions, prices and quantities.

Because there can be many repetitions of these components, we need to introduce a component like LineItem as an aggregate data set that contains them

Now the model for Order is that it contains one of more unique LineItems (discrete withno repetition)


28 of 37 4/23/2008 8:39 AM

Second Normal Form

2NF separates all non-dependent components

Split off into separate (new) sets any components that do not wholly depend on the entire key

Focus on sets of components with composite keys

For example, for a given LineItem, the Description and Price may be the same each time, but the Quantity depends on the particular occurrence of a LineItem.

2NF would separate these non-dependent components into their own set, possibly called Product or Item


29 of 37 4/23/2008 8:39 AM

Third Normal Form

Ensure that all non-key components are independent of one another

As for 2NF but for components that are not keys.

For example, Order may contain a CustomerName and their AccountCode

These non-key values may have some dependency on each other and should be separated into another set, e.g. Customer.

3NF also involves removing any derived or calculated components


30 of 37 4/23/2008 8:39 AM

Normalization Example: Model of Lecture Notes

Assume we've analyzed my lecture notes to yield a set of candidate components

We can represent a populated set of content components for a lecture in a single data set (as a table or "relation'")


31 of 37 4/23/2008 8:39 AM

Content View of a Lecture Slide


32 of 37 4/23/2008 8:39 AM

Candidate Components from Lecture Slide


33 of 37 4/23/2008 8:39 AM

Candidate Components as Relation


34 of 37 4/23/2008 8:39 AM

Normalized Model


35 of 37 4/23/2008 8:39 AM

Representations of Normalized Model - Primary Key Path


36 of 37 4/23/2008 8:39 AM

The Primary Key Path shows how we can navigate among the relations /aggregates in the model

Representations of Normalized Models - UML Class Diagram

Transform the model into a UML Class Diagram (data sets/tables become Object Classes, individual components become Attributes, Primary Key Paths become Associations)


37 of 37 4/23/2008 8:39 AM

Reading for 28 April

Document Engineering, Chapter 14

REMINDER: No class on 30 April because of OASIS Symposium "field trip"