Saturday, November 14, 2009

Memories of IT - IEF and Action Diagrams

So, you have a data model detailed with all entities, relationships and attributes, and a set of elementary processes that mainly CRUD all that data. The specifics of those CRUD functions would then be detailed using a rigorous logic called Action Diagrams (AD) . You would define your input data, what the process would do with the data, and the output. The rigor of this logic was that all data used had to be in the data model, and the AD would use views of the data model to define input, output, and of course CRUDs of the data in the model. The AD also enforced the rules in the data model, such as the example in the previous post. If you did not specify it correctly, IEF gave you an error, The whole AD was supported in IEF as selection of logic phrases from only what was actually valid at the point you are defining the logic. This ensured that when you had finished the AD logic for a process, IEF could generate code free of execution errors. You could still define the wrong logic for the process, but it would run.

Last point: IEM/IEF defined a Process as a logical activity. When you wanted to use that process, you would create a Procedure, either an online procedure or a batch procedure, and these would use processes as needed, the key thing being that a process, defined once, would be used as many times as needed within all the procedures, like an online transaction for Add Customer, or a batch program that would get a file of data and use Add Customer as many times as was needed.

So, you have Procedures that use Processes that use the Data Model, all in IEF. The tool has assisted you in specifying all these things to avoid execution-errors, and it also had other validation capabilities that would ensure that all the pieces you have work together. Once all the pieces have been validated, select Code Gen and IEF created all the code for your application: DDL for creating the database, code for execution of process and procedure, and online transactions or job control language for the procedures. Send all that to the various compilers for the languages you have generated, and out comes your executable. No hand-coding needed; you can literally not look at and even throw away the generated code away.

IEF first generated COBOL, DB2 and CICS for mainframe systems. As client-server emerged in the early 90รข€™s, they added generation of C, Oracle and Unix to run on PCs and servers.

Next time: So why aren't we all using IEF?

No comments:

About Me

Ontario, Canada
I have been an IT Business Analyst for 25 years, so I must have learned something. Also been on a lot of projects, which I have distilled into the book "Cascade": follow the link to the right to see more.