Re: Process Model
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 19 May 2006 14:39:10 GMT
Message-ID: <iMkbg.9816$A26.243595_at_ursa-nb00s0.nbnet.nb.ca>
>>David Cressey wrote:
>>
>>
>>>"The underlying strategy of functional decomposition consists of
>>>the processing steps and sub-steps anticipated for a new system.
>>>As far as I can tell, functional decomposition results in a process
>>>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
>>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.
Date: Fri, 19 May 2006 14:39:10 GMT
Message-ID: <iMkbg.9816$A26.243595_at_ursa-nb00s0.nbnet.nb.ca>
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. >>>>models were implicit and non verbalized, but they were models
>>>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
>>>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 not surprising really. The self-aggrandizing ignorants don't understand conventional terminology and don't really care about it either. Their goal is not to communicate but to sell horseshit. Received on Fri May 19 2006 - 16:39:10 CEST