ATLAS Framework

From ATLASWARES

ATLAS WARES Co. provides the ATLAS Framework to the OpenInsight developer community as an open distribution, open source program under the following License.

Contents 1 Foundation of ATLAS Framework 2 ATLAS Framework Components 3 ATLAS Object Depository 4 ATLAS Foundation Classes 5 ATLAS Menu Event Handling 6 Process Class 7 Extending Process Concepts 8 Reports Process Class 9 Schedules Class 10 Rules Class 11 Summary

Foundation of ATLAS Framework

This Framework is based on common software design principles of Object-Oriented Programming. First is the use of an Integrated Development Environment, or IDE. The OpenInsight database from Revelation Software provides the IDE foundation for the ATLAS Framework. OpenInsight incorporates a database which is variously described as multivalued, post-relational, or Pick-like. OpenInsight's BASIC language has been extended with primitives for Windows(tm) functions and .dll calls. In addition, it uses a component repository with designers for menus, popups, window forms, dialogs, and other objects.

When a programming system which includes database capabilities is described in the terminology of objects, the system becomes object-oriented. OpenInsight is object-oriented if its data structuring and programming are described as representing object variable states and program method behaviors. An object class in OpenInsight is defined by a table's dictionary and the subroutines which interact with that data table. Methods are defined by program subroutine calls and parameters, or by symbolic dictionaries. Object variables are defined by a table's data columns. OpenInsight lacks formal methods to extend the set of object classes in the Repository or to provide inheritance of class design.

ATLAS Framework Components

ATLAS Framework is a complete OpenInsight application including components which may be categorized in five groups.

1. Promoted Event handlers – routines to handle event messages for ATLAS,
2. MFS posting dispatcher – data controls for object-oriented posting,
3. Object Depository – object storage with module inheritance,
4. ATLAS Foundation Classes – Codes, Configures, Controls, Documents, Filters, Help, Messages, Notes, Processes, Programs, Reports, Rules, and Schedules,
5. Utility method programs – Query In Forms, Zoom Text, Popout Codes, Configure Forms, Copy Columns, and so forth.

ATLAS Object Depository

The Depository is central to object-oriented development in the ATLAS Framework, just as the Repository is central to development in OpenInsight. Developers define object classes and specify module inheritance using the depository. A module is a grouping of components in an application or a complete application inheriting from the ATLAS application. Some capabilities of the object depository are as follows.

• Depository objects are data defined and not compiled,
• Users may make local changes to modify objects,
• Users may add new objects to existing classes,
• Local changes inherit from depository definitions,
• Local changes are unaffected by depository updates,
• Local programming changes are unaffected by repository updates,
• Object checkout and release versions are provided,
• Archival copies of changed objects are maintained.

A new object class is added to the depository in four steps:

1. define a data table for the object,
2. add DEPOSIT_MFS to the data table,
3. design an entry form for the table, and
4. program the object method subroutines.

Using the depository is the same as adding a data table and its programming, with the addition of installing DEPOSIT_MFS on the table. When DEPOSIT_MFS is installed on a table, the depository management menu is added to the data table's entry forms.

ATLAS Foundation Classes

Foundation classes are the definitions provided to kick-start development in an object-oriented system. Foundation classes usually focus on the user interface, and ATLAS provides interface tools, but this article discusses ATLAS foundation classes which provide program control. These are:

• Configures – Configuration objects specify the relationship between data entry values and the control states in an entry window. Customary programming practice is to associate a commuter module with an entry form. In the commuter module, lostfocus event routines modify the states of various controls based on the value of an entry. Configuration objects replace this compiled program code with state specifications which are applied during create, read, and lostfocus promoted events.
• Processes – An object defining the sequence of subroutines in a complete menu selection or program operation, along with the security restrictions and other control information which apply to the operation.
• Reports – An object defining the sequence of subroutines in a complete report operation, along with security restrictions, printer assignment, and other control information.
• Rules – The rule object defines the calendaring and user input for a process or series of processes or reports, as well as the sequence and dependencies of a series of rules.
• Schedules – An object defining the Date/Time schedule for executing a Process or Report, along with user and access control information.

ATLAS Menu Event Handling

Users generate messages to system objects through menu selections. Using a Mutiple-Document Interface (MDI) frame design concept, ATLAS separates menus into application selections for the MDI frame and entry selections for the MDI child windows. MDI child windows are further broken into data entry windows and input collector windows. ATLAS menus are defined through the following standard forms.

• MDI frame application menu for the current account, e.g., MENU_ATLAS,
• MDI child menu for input collector forms, e.g., MENU_COL,
• MDI child menu for data entry forms, e.g., MENU_DBW,
• MDI child menu for data entry forms using the depository, e.g., MENU_DEPOSIT.

A promoted CREATE event handler refines a form's menu before display according to the following rules.

• Application menu items are defined by Process records,
• Process and Report groups are expanded to include all defined items,
• Access restrictions are analyzed to remove prohibited items,
• MENU_DEPOSIT is used if the form's data table has DEPOSIT_MFS applied,
• Child form menu items are merged with standard menu items.

Methods for application menu items are generally defined by process objects. Methods for standard MDI child window menu items are built into the promoted menu event handler.

Process Class

Processes are the foundation of ATLAS program control. (Here Process class means the set of definitions of program actions which comprise an application program. In general computer terminology Process is synonymous with Task.) The interface to processes consists of a subroutine call to PROCESS with the Process_Key as a parameter. Each menu selection or batch program in an application can be expressed as a process object.

In object terminology, the methods interface of a program are the variables of its process. Processes define a program's structure through three sequential execution phases.

• Collection – getting input specifications,
• Selection – determining the data domain of action,
• Execution – performing program update steps.

Processes control the dependencies that may exist between execution phases.

• Skipping collection when input data is present, allowing batch processing,
• requiring input collection data,
• requiring data selection records,
• batch versus interactive execution, allowing multiple engines,
• initiating, processing, and results messages.

Starting a process instance creates an audit record in the Actions table, and errors are recorded for actions. The Actions Viewer utility displays recent actions. The additional properties of processes are listed following.

• User access restriction – applied during menu create events,
• Execution restriction – checked when a process is instantiated,
• Control locks – process execution conflicts prevented by locking,
• Re-entrance – allows simultaneous processes during user collection,
• Auditing – each execution of a process is recorded in the Actions table,
• Error logs – Ermsg() error calls are recorded on Actions,
• Actions Viewer – a browser to review recent actions.

Extending Process Concepts

Expressing a program's methods interface as the variables of its process is not just a trick. OpenInsight is interpreted instead of compiled, so that translating data statements into program code at runtime is a fundamental capability of OpenInsight. The processes definition extends program interpretation to include input parameter substitution, execution dependencies, and auditing.

If processes extend VOC-like batch command programming, then what extends processes? In the terminology of object-oriented development, object definitions may be extended by inheritance or by creating new related classes of objects. Examples of these methods follow.

Reports Process Class

The Reports class inherits from Processes, which means that the dictionary for Reports is a superset of the Processes dictionary. (Another way to view this is that Processes and Reports are child classes of a Process superclass.) Reports add the following variable definitions:

• Dimensions – report width and height,
• Printer setup - printer name, orientation,
• Display control - View, Print, Capture, and associated inputs,
• Input collection,
• Data selection replacement,
• User messages.

Just as processes have a single method, PROCESS, reports have the single method REPORT which uses the report key as a parameter. The method subroutine for reports is similar to PROCESS, but it adds a user input step to specify if a report will be viewed, printed, or captured, to specify selection override, and to provide a fixed set of user collection options. Report execution also includes programming for assigning a print device on the fly, prompting to mount forms, and sending special instructions to the printer.

Schedules Class

Schedules are a class of objects which define the unattended or batch execution of processes. Schedule dates may be set by day of week, day of month, or day/date of year. Times are set either at a specific list of times or periodically within a starting and ending time interval.

Besides the date and time, a schedule may specify which user or users can run the schedule. Finally, the Skipped variable defines what to do when a user login has skipped a schedule execution: run the item, prompt the user to run the item, or simply ignore the skipped item.

Each schedule specifies a list of processes and/or reports to be performed in sequence. Input collection values or parameters for the processes are saved within the schedule. When a process is executed within a schedule, the collection phase of execution is skipped and the saved collection values are used instead.

Rules Class

Rules inherit their design from schedules. Each rule maintains a calendar and a sequence of processes. Schedules are independent from each other and run without user interaction. Rules are interdependent and execute interactively. As with schedules, each rule stores input collection values for the processes to be executed.

The calendar for a rule defines its execution dates through the following parameters.

• Everyday, Anyday, or Manydays,
• Weekdays – SUN, MON, TUE, WED, THU, FRI, SAT,
• Monthdays – FIRST, 1...31, LAST,
• Yeardates, Yeardays – FIRST, 1...365, LAST.

Each rule specifies a list of rules which depend on the current rule. Once a rule which has dependents has executed successfully, its dependent rules are enabled and the current rule is disabled. Rules form a procedural circuit when the last rule in a sequence has the first rule as its dependent. When rules form a circuit, typically only one rule can be executed at a time. When all rules in a circuit are exhausted, the first rule is re-enabled but is not active until the next calendar date for execution is reached.

Summary

OpenInsight allows us to transcend older programming paradigms and express application components as objects composed of variables and methods. With the Processes and Reports object classes, entire program selections are expressed as objects. Furthermore, the methods interface of a program becomes the data variables of its corresponding process. Process objects allow a developer to assemble line-of-business applications from menus, forms, and processes while writing and compiling a minimal amount of code.

Most line-of-business applications have batch update programs and complex interactive procedures. Schedules execute Processes and Reports in a batch or background mode. Rules specify the calendaring and procedural dependencies of application procedures. Again, these application elements can be specified through data objects instead of program code.

Additional tools such as the ATLAS Configures utility convert data entry relationships as data configuration, eliminating programming in entry forms as well. Using all these tools, the developer can eliminate a major portion of the compiled program code in an application.

With the ATLAS object Depository, an application can be modified locally while it is developed and supported globally. Individual sites and users can reconfigure aspects of an application to suit their own needs or to extend the program's capabilities. These modifications are run-time compatible, they do not require program compilation, and they can be performed by a user assisted by a developer.