COE NewsNet – February 2007 – Knowledge Technology

“C is not math” was a comment heard in the midst of discussions about how engineers ought to express their knowledge or the intent of their design via the computer or ought to specify a problem for solution by computer. No doubt, mathematics has been a great enabler in engineering. One can do some engineering mathematics without computing; one cannot do all of engineering mathematics without computing.

Engineering user interfaces have evolved toward a highly graphical (GUI) environment, and none of these iconic mixes is anything near to that of a textual ‘code’ framework that is the how specifics of system implementation are conveyed. There is a wide conceptual gap between the GUI-based provides and what working with ‘code’ demands.

And, though computational improvements generally include increased user-interface techniques and seem to provide an ever-increasing support for application of these improvements, there is a non-static nature of engineering that drives requirements for extensions. How to realize the extensibility raises several questions such as whether there is the need to know a programming language (such as C, C++ or any peers) and whether such knowledge empowers the engineer or gets in the way. As an aside, we have seen that several computer languages have been successfully used by both the mathematician and the engineer.

The COE FORUM has a couple of sections that deal with what might be called ‘programming’ for engineering in the context of CATIA v5 (CAA), namely CATIA V5 Programming and KBE. In both of these discussion areas, VB and RADE play a large role. The KBE section has further discussions related to specific workbenches for KBE.

Paradigms of Computing

Eric Bowman described CAA and discussed the differences between VB and RADE in his Ask the Expert presentation. [1]

Now, in this context, it might be of interest to look at computing paradigms a little more closely. Recently, a Communications of the ACM article reported the results of a survey that took a look at what types of exposure a software developer ought to have during the academic experience. [2] Remember, this says ‘software developer’ and not engineer.

Essentially, the survey results ranked the five paradigms of computing in importance. For each of these paradigms, there will an associated language or accumulated library mixture. The following two sets show the paradigm order as ranked by the survey.

· 1) Imperative and 2) object-oriented programming, 3) concurrent/distributed computing

· 4) Functional programming, 5) logic and constraint logic programming

These two sets differ in several ways; one of these differences relates to the requirements of engineering computing and of how problems are solved. Definitely, the first set is of prime concern to computer science and to some engineering frameworks that are targeted to system development. The second set maps more closely with what we know about mathematics and, perhaps, offers more support for domain viewpoints that are needed by engineering problem solving.

Despite the obvious differences between VB and RADE, as delineated by Eric, they are of the same ilk as they are both members of the first set, Imperative and Object-oriented programming, respectively. Even extensions to VB that improve its object abilities will only bring these closer together.

Too, it is not material whether an interpretative scheme, such as scripting, is followed versus the compilation regime that is required by the lower-level languages. Issues related to the semantics of execution are important, but they are minor in comparison to what we need to consider for a ‘domain’ focus and knowledge.

What might this mean for KBE?

KBE (Knowledge Based Engineering) can be many things [3]; Brian Prasad used concepts such as ‘demand-driven’ and ‘high level’ in his description of what differentiates KBE from Automation. [4] In terms of the computing paradigms, the attributes of KBE are not usually associated with either the object-oriented or imperative paradigms, that is, not without fairly sophisticated extensions.

One difference between the two sets of paradigms involves semantics and expressional power. Walter W. Wilson, in his article, described the need for, and attempted to define, a declarative engineering design language (ESL). [5] One would expect that the syntax, as well as the semantics, for this approach would differ from that of VB or RADE, as the ESL would need to be more like the second set than the first.

There could be a sixth paradigm, and third set, in the list related to domain-specific approaches which is the area that KBE is helping to address by its expanding workbench configuration. The ESL ought to be of this set, and however it ends up, hopefully, the language would lift the focus toward a problem-solving thereby addressing the open issue of ‘faithful’ mappings between the GUI-enhanced session and a protocol suitable for bots.

An approach that causes a shift from the second (or higher) set to the first set, that is, too much of an imperative or object-oriented focus, might be considered counterproductive or retrogressive from the problem-solving viewpoint.

[1] Eric Bowman “The Basics of Creating a CAA Program” COE Ask the Expert, July 19, 2005

[2] Sami Surakka “What Subjects and Skills are important for Software Developers?” Communications of the ACM, January 2007, Vol. 50. No 1

[3] “Knowledge Based Engineering” Wikipedia (the free Encyclopedia)

[4] Brian Prasad “What distinguishes KBE from Automation COE NewsNet, June 2005

[5] Walter W. Wilson “A Proposal for CATIA V6” COE NewsNet, June 2006

To contact the author, use john.m.switlik@ieee.org.