Induction programming – strategies for solving software problems

Many software and hardware producers pride themselves on the accelerating pace of technological change, but for users and consumers of their products and services, rapid technology obsolescence often means increased costs, frustrations, and unfulfilled promises. Corporate America expects to make capital investments in goods and facilities that will have to last for five, ten years, or twenty years, but the age of just eighteen months to invest in software and hardware is not uncommon.

Reducing the costs of developing new software solutions or extending the life of software applications are two complementary ways to tackle technological change. These goals can often be accomplished by following an advertising strategy when designing software systems independent of the programming methodology used.

Problems with determinist programming

Most programming projects today use the inevitable method of programming. The developers write a sequence of operations in a language, such as C ++, Java, Visual Basic, etc., that implement an algorithm or recipe to execute tasks. The task algorithm mixes logical or relational statements about the task to be solved and controls expressions about how the solution is calculated. Logical statements describe "what" to an account, while control phrases describe "how" to an account. The correction of the algorithm consists of checking the accuracy of logical data and repairing control statements, if necessary.

There are many problems with the inevitable approach. The sequence of operations essentially determines the validity of the algorithm. Unexpected execution sequences through an algorithm resulting from user input procedures or real-time events in a multi-tasking environment may lead to a hidden or catastrophic algorithm failure. Writing control logic is the responsibility of the programmer and, therefore, subject to implementation errors. Understanding the software algorithm is often difficult for other developers without metadata or comprehensive code review and beta tracking of program implementation using sample data. Software validation consumes a large part of the development effort, but it also fails to detect a large number of flaws.

To address the problems associated with necessary programming, the computer industry has developed and advocated many approaches. Structured programming and campaigns against the "go to" phrases address some of the problems discovered in custom control structures and data. Modularization Initiatives stress decomposition techniques on the premise that humans can understand, interpret, and preserve smaller parts of the code. Object Oriented Programming calls for software creation using reusable components, libraries, and frameworks. The School of Pattern Programming emphasizes similarities with other areas, such as architecture, by creating programs using well-designed solutions or patterns, and it is repeated in many programming contexts.

What is induction programming? ?

Induction programming separates the logic of an algorithm or its control from the control or algorithm. The programmer still defines logic or equations that determine problem relationships, but the programming system is responsible for controlling, or how the logic is evaluated. The most common examples are spreadsheets and query languages ​​for relational databases. The user, or the programmer, specifies a mathematical relationship as a query, for example in SQL, what to retrieve, while the database engine determines how the query is executed against the database.

There are many advantages to declarative programming in the necessary style. In declarative languages, programmers do not define the sequence of operations, but only the definitions or equations that define relationships. Unlike deterministic programming, the logic relationships in declarative programming are an independent implementation matter, free of evaluation side effects, and clearly visible for visual inspection.

The declared family of programming languages ​​has a long history in the academic computer science community and specialized areas of commercial application, such as compiler creation, expert systems, and databases. Expositive languages ​​have two major family trees. Logical definition languages, such as Prolog, are based on first-order calculus, which generalizes concepts of true or false Aristotelian values ​​to data, or predictions, that involve relationships between any entities. The other family branch consists of functional advertising languages, such as Miranda, Haskell, and SML. Functional declarative languages ​​rely on the calculus developed by the mathematician, Alonso Church in 1930. L-Calculus formalizing recursive concepts of pure functions of computational problems. And if not so widely known, the latest programming style, XSLT, the language of XML format extendable style pages, is also a functional advertising language.

Despite the theoretical advantages of declarative programming languages, they are not widely used in commercial programming practice despite an attempt by Borland in 1980 to market a computer version of Prolog alongside the very famous Turbo Pascal. There are many factors that contribute to the rare use of declarative languages. The major contributor is the lack of group training in declarative languages, but the embarrassing syntax for some languages, ineffective translators, operating times, and areas prohibited from the applicability of generalized "qualitative" mechanisms are all contributions.
Using induction strategies in commercial programs

Although explanatory programming languages ​​have not received widespread commercial use, the strategy of separating logic, or what, from control, or how, in the algorithm is a powerful and generalized technology to increase ease of use and extend the life of the program. Declarative technologies are particularly powerful in user interfaces and APIs that contain a rich and complex set of inputs across a relatively small range of implementation behaviors.

Two examples of commercial programs that demonstrate the applicability of declarative techniques are DriverLINX and ExceLINX in the areas of data acquisition and testing tool control.

Use ads to get data

DriverLINX is an API for controlling the data acquisition devices used to measure and generate analog and digital signals connected to all types of external adapters. Data acquisition applications include laboratory research, medical devices and industrial process control.

Traditionally, data acquisition device application programming interfaces (APIs) have modeled device design properties and have a large number of or more parameter functions to set up the device and control data flow across the system. Process sequencing was often necessary to properly program and control devices. Upgrading to new hardware to acquire data is often expensive because the changes that the device entails are in the order of playback sequences for the hardware programming required for expensive software changes.

To work around these issues, DriverLINX takes an abstract and illustrative approach to data acquisition programming. Instead of modeling specific board designs, DriverLINX extracts functional subsets of data acquisition devices in generalized features and capabilities. Programs require the measurement task they want to implement by specifying "service request" parameters. DriverLINX runtime determines how to satisfy the service request with available hardware and returns measurements as a packet stream current to the program. The data acquisition programmer is exempt from any responsibility for controlling the data acquisition algorithm.

Besides programmers' control of responsibility, the DriverLINX induction approach gives the program grammatical and semantic interchangeability when migrating to similar hardware products. An induction approach also helps to isolate a software vendor from the early technological obsolescence of change in the computer industry by focusing on the consistent logic of data acquisition relationships while control mechanisms vary with different software developments. DriverLINX has been a practical style in data acquisition programming for more than 12 years despite the market development from 16-bit Windows to .NET today.

Use of ads for test tools

Test tools, such as digital voltmeter and electrometer gauges, have evolved from simple devices equipped with a front-panel knob and display to advanced metering processors that perform dozens of measurement and control functions. Like data acquisition devices, developers usually send a carefully arranged series of commands to a measurement setup tool and then send additional command sequences to control the flow of measurement data from the tool. The above problems for developers who use the necessary approaches to control the tools greatly reduce ease of use and prohibit rapid hardware solutions to short-term measurement needs.

ExceLINX is an add-in for Microsoft Excel that allows quick identification of tool test settings using worksheet forms. Users determine or advertise channels, configurations, sampling rates, playback locations, and data for the measurements they want to make by filling out the Excel worksheet. When the user selects the "Start" button on the toolbar, ExceLINX translates the specification into the correct command sequence for the target tool, begins measuring, and flows the data back to the desired worksheet. Users can prepare and collect measurements themselves in minutes using logical specifications compared to days or weeks using programmer time to obtain the necessary specifications.

Internally, ExceLINX also uses a declarative approach to address the problem of validating complex fields for worksheet models. The tools have hundreds of parameters with a complex overlap between the parameters. To validate whether the tool supports the parameter specified by the user, ExceLINX maintains a dependency tree for the allowed, unauthorized, and unused parameters for each entry cell on the worksheet. Each tree node also maintains logical relationships between the set of specific parameters that ExceLINX evaluates at run time to override the validity of user input selections. Each supported tool model has different semantics for parameters, but ExceLINX can easily handle this complexity by switching model trees because the model logic specified in the validation tree is separate from the common control application of the ExceLINX code.

Corrective programming strategies that separate logic from controlling algorithms are powerful techniques that can be used with today's mandatory languages. These technologies can make the program more interchangeable, maintainable, usable, and endurable.

Copyright Roy Foreman, PhD, PhD 2005


    Leave Your Comment

    Your email address will not be published.*