Author(s):
Bob Glushko
glushko@ischool.berkeley.edu
Course: Document Engineering and Information Architecture (INFO 243)
Date: 28 April 2008
Title: Assignment 7: Aggregate Components and Document Model Assembly
This assignment gives you practice at identifying aggregate components and in assembling document models from your set of primitive and aggregate components.
This assignment is due on Wednesday May 7. This is the third and final progress report for your course project. Your final presentation will be on the following Monday, May 12, and you'll need to turn in all of your work products and a summary report by Friday May 16.
Identifying Aggregate Components. In Activities 2 and 3 of the Document Analysis assignment your project team came up with a consolidated set of content components and considered whether any existing standards or other specifications were appropriate design sources for these components.
ACTIVITY 1:
We've discussed several formal and informal methods for identifying aggregate components to enable more efficiency and consistency on assembling document models. You've seen many examples of presentation conventions that facilitate finding aggregates by highlighting the relationships among primitive components, like adjacency and in tables (but watch out for presentation conventions that mask component distinctions to create what looks like an aggregate that isn't). Identifying aggregate components by putting primitive components on index cards and then sorting them into groups that "go together" because of structural or logical considerations was briefly mentioned in the April 23 lecture. Cracraft and deLarios-Heiman also mention this technique in the reading assigned for April 16.
These are all "bottom-up" approaches that will yield the reusable building blocks you need when you assemble your document models. But they aren't deterministic, so if only one member of your project team does them, you can't be sure that you've identified a good collection of aggregates.
So two members of your projects should INDEPENDENTLY sort the primitive components into aggregates. Furthermore, each person should not do this sort in a single pass and simply settle for a single level of aggregates. Ideally you would create a set of aggregates, record the results, and then do it again on another day, comparing the two sorts and resolving any differences. This repetition will sharpen your justifications for the identified aggregates. Then, the two of you should compare your collection of aggregates and resolve any differences in their number, size, precision, hierarchy, etc.
The modeling artifact from this activity is a set of the primitive and aggregate components. A UML class diagram or similar notation is probably the best way to record this, but feel free to use any approach that you consider effective.
Assembling Document Models
ACTIVITY 2: In Activity 5 of the Document Analysis assignment you identified a set of documents that your application will need to carry out the transactions or information exchanges that you're proposing. Using the set of primitive and aggregate components you've created as a result of Activity 1 of the current assignment, you will now create assembly models for each of them (up to 10... if you have more than 10 documents and you can create 10 assembly models, you've gotten the point of this assignment).
Each of these assembly models should be depicted using a notation of your choice -- you've seen a couple different types in lectures and there are a few more at the end of Chapter 14. Feel free to invent your own if you can come up with one that is more effective.