Re: Process Model

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:9en0k3-6af.ln1_at_pluto.downsfam.net...
> David Cressey wrote:
>
> >
> > "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.
>
> It seems to me the process model is not strictly necessary for the
> foundation of a system. When a programmer speaks of "process steps" they
> usually start talking about reading data, doing calculations, then writing
> data.
>
> IMHO, if you can define derivations as part of the table design, you
> eliminate the need for most processes. The only exceptions I've run
across
> are certain processes like ERP allocation where each row write affects
> tables in such a way that a loop is apparently required. Also in some
> import/export routines where the desired target format makes it more
> economical to write up some code than to dream up a generalized solution.
>
> But in your classical processes like billing and cash posting, the ability
> to specify derived values can eliminate posting processes entirely.
>
> So, once the process is recast as table definitions, outside process code
> becomes more like UI code, something that can easily cobbled together to
> trigger events in the database, but its not a foundation design element
> anymore.
>
> I should also point out that I've considered making use of table
> specifications to generate server-side processes, so that automatic
> derivations can be delayed and run on-demand. It seemed like a good idea
> for comleteness, but nobody yet has asked me to do it, so it just sits on
> the shelf as an idea.

Funny you should be the one to reply. I was thinking of Andromeda when I wrote the above, but neglected to mention it.

It's clear, from your prior writings and from others', that a process model can be expressed as data. In fact, if one allows the notion that the contents of an executable file are "data", it's always expressed as data. A data model can also be expressed as process, e.g. "CREATE TABLE ...". Expressing a process model not only as data, but also in the form of tables, is, IMO, an advance.

Oddly enough, I got exposed to this concept about ten years before I got exposed to the RDM. It was referred to as "table driven programming". The tables were coded in assembler, or DATA statements, or whatever, and were memory resident. But "table driven programming" was clearly an antecedent to the ideas you have been developing, IMO.

The only reason I even bothered to mention "process model" was as a contrast to "data model". Basically, in the early stages of problem analysis, people tend to sort themselves out into two camps, which can be called the "data centric camp" and the "process centric camp". I see the object oriented paradigm, in one sense, as a way of intertwining those world views. But I'm a lot more impressed with what the OOP people have done with object description than with what they've done with message description. I've found most OOP work on messages to be sloppy and primitive, compared with what the database people have done. That, of course, may just be the subset of OOP work that I've been exposed to, or my subjective reaction to it.

OTOH, I think the data centric camp has been overly critical of the way OOP deals with process.

Now, about this thread. It's not my purpose to insist on novel and idosyncratic terminology. If there is a standard term for the concept I'm trying to express, I'm willing to use it, in place of "process model". OTOH, I'm not going to censor myself to the extent that whenever I combine words in ways that others have not, I'm going to suppress my own expression. That's stultifying and counterproductive. Received on Fri May 19 2006 - 15:39:04 CEST