Instance Diagrams and Examples

The principal features of the model will be explained through a graduated set of examples, as well as the instances of data that would be required to implement them. The examples do not follow exactly the attribute names on the class diagram for compactness of representation; the mapping should be clear.

Conventions Used

This topic presents diagrams of a number of concepts involving workflows and activities, and the associated table content giving corresponding instance diagrams. When possible, diagram elements are color coded to the table used to represent them. The descriptions for the tables and attributes can be found in later topics.

In the tables representing database table contents, many columns not germane to the point being described are omitted. In particular, all of these tables include an Id column for a surrogate key allowing unique row identification. When a link is made from table A to another table, B, table A is shown with a column named B_Id, and values for this column appear like Id(name), where name identifies a row in the B

table. For convenience, Id references in the table entries as they appear below are annotated for clarity in curly brackets {like this}.

Seabed Representation of Workflow Simple_Gridder

The simple_gridder program was purchased to implement part of the earth model interpretation workflow. Simple gridder produced an output time or depth grid based on a nonempty set of well picks, an optional time to depth velocity model, and a mandatory polyline defining an area of interest.

Part of the installation process is to register simple_gridder as a workflow so that it can be activated by normal framework procedures, and composed into higher-level workflows in a workflow editor. Here is a schematic representation of simple_gridder showing its inputs and outputs:

The example is color-coded to the entries in the Workflow (blue - basic workflow definition) and Act_Tmpl_Data_Role (red - workflow inputs and outputs) tables:

Activity_Template Table

Act_Tmpl_Data_Role Table

Note that the role names can be decided by the application, and need not match the candidate Entity_Type of objects that can satisfy a required role. A second point is that the data roles shown here are all strictly input or strictly output. The case of a program defining input/output roles is handled by having tow rows in this table for the named role, where one would have a Role_Type indicating input, and the other would have a Role_Type indicating output.

The marketing appeal of simple_gridder is that it provides good performance and implements local grid refinement and coarsening when justified by the input data. A drawback of the program is that does not handle faulted models well, and the simple structure of the grids used does not support multivalued grids, such as might result from reverse or over thrust faulting. Here is part of the resulting Best_Practice_Act_Tmpl (workflow fitness for purpose) table capturing these aspects of Simple_Gridder, and a couple for Another_Gridder for comparison.

Best_Practice_Act_Tmpl Table

The Best_Practice_Act_Tmpl entries stand on their own. They can exist whether or not there is an installed and registered component. This allows a system to identify a desired workflow so it can then go out and purchase it, or find and use it as a Web service, and so on. In addition to registering marketing claims for products, Best_Practice_Act_Tmpl is intended as a repository for information about what is determined through experience to work in a given situation. In this sense, it is a bridge to knowledge management.

Activity Corresponding to Workflow Simple_Gridder

Assume now that earth model expert, Sarah Henley (account name Sarah), has decided to activate the Simple_Gridder workflow, either because she browsed available workflows (which might appear in a list of installed components) and picked it from a list, or because she determined through analysis of the Best_Practice_Act_Tmpl table that it was preferred in her situation. The process of activating the workflow creates an object structure that is very similar to the workflow structure:

In this case, the program is started with inputs (shown in orange): four instances of Well_Marker, and one instance of a Polyline. The program does not receive a Velocity_Model as input (note that it was optional in the workflow definition). It creates one output (cyan), which is instance of a Grid. Before the program runs, the markers and polyline exist:

Well_Marker Table

Polyline Table

After the workflow is activated and run, new entries appear in the Grid, Generic_Activity and Assoc tables:

Grid Table

Generic_Activity Table

Generic_Activity_Ref (View on Assoc Table Specific to Entity_Type=Generic_Activity)

The internal Assoc table has a number of interesting properties: it can represent many-to-many relations, it can make relations to instances in multiple tables (which is why the Property_Types vary above), and its update views maintain the Update_Date attribute transparently. Notice that the Update_Date for the Grid is later than that for the input associations. Presumably, these inputs were written at an even earlier time, and these too will be recorded in the Assoc table for the activity that created or modified them before this execution of Simple_Gridder. If those same objects are again updated later, then Assoc contains all the information needed to determine that the Simple_Gridder output Grid 0040 becomes stale, and probably needs to be recomputed.

Although this example shows the result of activating the Simple_Gridder workflow, there is still an issue with the exact order that things happen, and which agent is responsible for each action. For example, in some cases, the application framework could bind and associate all application inputs, and create the empty output grid object along with the association of the grid to the activity record for the application. Alternatively, the framework might create only the associations for input data, and leave the creation of the outputs, and the necessary activity associations to the responsibility of the application itself.