Re: Process Model
Date: Fri, 19 May 2006 12:08:44 -0400
Message-Id: <4671k3-q7g.ln1_at_pluto.downsfam.net>
David Cressey wrote:
>
> "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.
Cool. We have the docs considerably updated now, and we are ironing out install issues on Red Hat.
>
> 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.
yeah i think this is easiest to see in Assembler. Is it data or is it code? You push a value onto the CPU's inputs and something appears on the outputs.
>
> 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.
Once I had substantially completed the Andromeda database builder and was building the UI framework, I found that most OOP concepts had become irrelevant. The central architectural element was the data dictionary, and when I fit the code to that I found simple old procedure libraries faster to write, simpler to debug, and easier and smaller overall.
But with the UI I tossed in a single class. I've met other programmers who feel as I do that OO is best deployed in user interfaces, but to each his own.
>
> 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.
Agreed completely, and I hope somebody pitches in and lets us know what the term is. Its easy enough to demonstrate that the stepwise description of a "process" can be mapped into the definitions of columns in tables, but is there a body of theory with a name that attempts to describe the stepwise stuff? Is there a proper way to talk about it in the same discussion as RM theory?
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Fri May 19 2006 - 18:08:44 CEST