Re: Process Model

David Cressey wrote:

> The term "process model" seems to have raised a lot of questions, and not to
> have conveyed what I intended to convey.
>
> Here's an example that illustrates, roughly, what I mean by a "process
> model". This is a brief quote from "Object Oriented Analysis" by Coad and
> Yourdon.
>
> "The underlying strategy of functional decomposition consists of selecting
> the processing steps and sub-steps anticipated for a new system. Analysts
> use previous experience from similar systems, combined at times with an
> examination of required outputs. The focus is on what processing is
> required for the new system. The analyst then specifieas the processing and
> functional interfaces."
>
> As far as I can tell, functional decomposition results in a process model.
>
> Every information system I've dealt with was, at some stage of its
> development, described by a process model and a data model. Sometimes these
> models were implicit and non verbalized, but they were models nonetheless.

I will assume Coad and Yourdon used 'functional decomposition' in its engineering sense and not in the computing sense for dividing tasks for parallel execution.

One can functionally decompose a hammer into a handle and a head. One can further decompose the head into a strike surface and a peen.

When I look at a hammer, I don't see a process. Neither do I see a process when I look at a peen.

The result of a functional decomposition is a design and not a model. Normalization is another design process involving decomposition ie. non-loss decomposition using project/join.

The use of functional decomposition to design a process is orthogonal to both the data model and the computational model--and in fact to the field of engineering as well.

Object orientation has nothing new or useful to add to that design process. Received on Fri May 19 2006 - 16:37:11 CEST