The Process pattern models continuous manufacturing processes. A good deal of manufacturing conforms to the discrete models of process that you usually find in work flow systems, with input objects moving along a path through transforming machines into new output states. Continuous manufacturing requires a different sort of model because it involves flows of materials such as oil or chemicals, not discrete items such as parts.
The Problem
Business models that model assets and part explosions are fine for modeling auto production or other manufacturing processes that produce bigger parts from smaller parts. Confronted with liquid flows as in a chemical production plant or sewage facility, these models fail. They are adequate to model the production facilities, machines, and pipes, but not to model the processes that result in products. For these processes, the concept of flow of material, and in particular the rate of flow, is the most important thing to model. As well, to ensure quality through process planning and measurement, you must distinguish between actual flows and potential flows. You want to measure what's supposed to happen as well as what actually does happen.
The Solution
Figure 8-11 is a rather complex representation of the Process pattern. It models a number of different aspects of the problem:
The process models (conditions and potential inputs and outputs for processes)
Process material requirements (products, flows, and constituents)
Facility structures (facilities, product inventories, fluid paths)
Figure 8-11: The Process Pattern
Note
The original pattern [Hay 1996, pp. 187-196] is very different from Figure 8-11. As I translated the original pattern, I discovered many problems moving from the CASE*Method
diagramming style into an OO style. In particular, the modeling of relationships as entities made it very difficult to translate Hays's pattern effectively. I have therefore taken the liberty of revising the pattern into a design that is more compatible with OO concepts.
This pattern is an example of an explicit, detailed pattern for a particular middle-level domain. The details of the pattern are clearly beyond what an abstract pattern would represent. Yet it still is quite general, and it can apply to any number of industries, not just firms in a specific industry. You can see how the levels of detail of patterns can vary between your particular problem, your company's problems, your industry's problems, your type of industry's problems, and generic problems.
The process is also an example of the transitive qualities of associations in a software system. Figure 8-11 has several association classes that represent realized relationships between classes:
ProductInventory: The relationship between Product and ProductionFacility; a facility contains an inventory of a product, which is a mixture of different materials
Constituent: The relationship between MaterialType and Product, the composition of the Product mixture
FluidPath: The relationship between two Production Facilities; literally, a pipe connecting two facilities that permits product to flow between processes
Condition: The relationship between a ProcessModel and a set of Variables; the variables control the conditions under which the processes modeled can proceed
Actual Flow: The relationship between ProductInventory and FluidPath; the actual flow of material mixtures (products) through the pipes (fluid paths)
Actual Flow is an example of a relationship on a relationship. The actual flow of materials from inventory to process follows the relationships between production facilities. Although seemingly complex in abstract form, you can easily see how all this works in the real world. You have mixtures of product in tanks. The product flows from the tanks
through production facilities that apply processes controlled by models to transform the input products into output products. These outputs in turn flow into yet other tanks, and potentially become the input to yet other processes.
Discussion
When you start seeing this kind of reliance on associations, you should think about OODBMS products and schemas instead of RDBMS or even ORDBMS schemas. Your application is almost certain to concern itself primarily with navigation along the paths and flows, not with class-extent queries over entity types. The navigational qualities of OODBMS sets are much more likely to provide the facilities you need in your application. In these systems, you typically want to follow the pipes or flows, not retrieve tabular data about them.
The constraints in a pattern of this complexity are hard to get right. Looking at Figure 8-11, how would you
automatically apply the process model to actual processes, for example? The model tells you what inputs a process expects and what outputs it produces, and it tells you the conditions of the variables under which it produces the product. Relating this to the production facilities means knowing where the inventories with the right mixtures are, what products can flow through which fluid paths at what capacities, and so on. The pattern contains the basic information, but there are many details still missing, such as scheduling of flows, tracking of samples and process measurements, and inventory management features. The Process pattern is a start at measuring the process relationships, but it doesn't provide everything you need for a continuous manufacturing domain by any stretch of the imagination.