Source-derived document; reported behaviour, inference and evidence gaps are identified in the text.

C07 — System Context and Components

Diagram coverage

Context and entry points

The supplied evidence describes a desktop order-management demonstration centered on customers, orders, stock and reports. The current Java application is configured through com.ais.fc.ix.application.Application.properties to use com.ais.fc.ix.swing.application.GUIApplication, while D4_Main.main creates an application through AppFactory.create("D4_Main", args) and starts the D4_Main module. These facts support a Swing-oriented desktop boundary, although the implementation of the com.ais.fc.ix framework is not included and its lifecycle behavior cannot be independently confirmed. E0001 E0002

D4_Main.run() is the principal application coordinator. It selects database alias stores7 through _app.getDB("stores7"), configures the Swing look and feel, and exposes commands for Customer, Orders, Stock, Reports and Exit. It also registers an exclamation-mark command that passes user input to _app.execute(true, Str.valueOf(cmd)), and a demo command that reaches D4_Demo. The command path is a direct application call, not merely a relationship inferred from files in the same directory. Its effective permissions and execution semantics remain dependent on the unavailable Application implementation. E0001 E0012

The repository also contains a separate 4GL source boundary. demo/source/d4_main.4gl defines a main menu, loads states and stocks, and dispatches to customer, order, stock and report routines. rundemo.sh invokes com.ais.demo.D4_Main with demo/bin and supporting libraries on the classpath, while the README describes the repository as an Informix 4GL-to-Java migration example. These artifacts establish related source and execution materials, but do not by themselves prove that every 4GL routine and Java class is used in one runtime path or that the Java code is semantically equivalent to the 4GL source. E0007 E0014 E0010

Application components and responsibilities

D4_Main provides coordination rather than the detailed implementation of each business area. It retrieves shared modules, loads reference data, manages the main menu and returns control to the desktop application. D4_Globals supplies application-level shared values through Application.GLOBALS_KEY, including p_customer, p_orders, arrays for p_items, p_stock and p_state, counters and print_option. Other modules retrieve this shared module through _app.getModule("com.ais.demo.D4_Globals"). This is direct evidence of shared mutable state across module calls; persistence, thread safety and cross-session scope are not established. E0002 E0012

D4_Cust is the customer component. The supplied Java implementation evidence attributes to it customer entry, query and browse, update, deletion, help and state selection. query_customer() builds a customer query and provides Next, Previous, First, Last, Select and Quit browsing actions; update_customer() issues an update for the selected customer; and delete_customer() checks related orders before allowing removal. A local analysis reported only ID4_Cust.java and not D4_Cust.java, but other supplied evidence positively describes the implementation, so the narrower conclusion is that customer behavior is evidenced in the broader material while some work-unit views could not cross-check it. E0002 E0011

The customer component depends on generated record and form classes. Customer.java under demo/bin/com/ais/demo/record/stores7/.svn/text-base extends Record and defines customer_num, fname, lname, company, address1, address2, city, state, zipcode and phone. Custform.java, Custcur.java, Customer.java, and related form artifacts use Form, ScreenRecord, FieldGroup, TextBox, MaskedTextBox and Swing layout classes. The phone mask and field mappings are directly represented in the form sources; the framework behavior behind those controls is not. E0007 E0004

D4_Orders owns order creation, line-item collection, customer-based order retrieval and invoice initiation. add_order() calls customer selection or creation, gathers order header values, accepts item rows through GridInputArray, starts a database transaction, inserts the order, obtains the generated serial value, inserts items, commits and then invokes invoice generation. get_order() retrieves orders for a customer and displays associated items, with a stated limit of ten displayed items. update_order() and delete_order() are present as component methods and menu entries, but the supplied Java implementation reports "This option has not been implemented" for both. Their presence therefore establishes an exposed component surface, not delivered update or delete behavior. E0002 E0011

The order component depends on stock lookup and generated order forms. Orderform.java uses JXTable and a GridColumnModel for item number, stock number, manufacturer code, description, quantity, price and total. P_Orders.java, P_Items.java, P_Stock.java and X_Invoice.java provide record-like structures for order, item, stock, manufacturer and invoice data. Stock_Sel.java and State_List.java provide selection-oriented forms. These are direct structural dependencies; the evidence does not prove that every form artifact is loaded in every order journey. E0006 E0013

D4_Stock supplies the stock menu and handlers add_stock(), query_stock(), update_stock() and delete_stock(). Each Java handler reports that the option has not been implemented. The 4GL source has the same menu-level separation and the same unimplemented messages. Stock records are nevertheless loaded by D4_Main.get_stocks() and used for order item lookup, so reference-data consumption must not be confused with stock CRUD capability. E0002 E0007

D4_Report owns report selection and output coordination. print_labels() and print_ar() contain implementation evidence and support file, printer and screen choices through print_option values "f", "p" and "s". print_backlog() and print_stock() are explicit stubs. The report methods create report objects, emit rows and call finishing methods, but the implementations of Report.start(), Report.execute() and related output classes are absent; exact buffering and completion behavior remain unresolved. E0002 E0012

External and supporting dependencies

The Java database boundary is represented by _app.getDB("stores7"), JDBC classes, PreparedStatement, ResultSet and record wrappers. default.properties names com.informix.jdbc.IfxDriver and gives a localhost Informix URL for stores7; demo/source/demo.properties contains a different host, port, server and password. These may represent different project and runtime configurations, but precedence and actual use are unresolved. Configuration values alone do not establish deployment of a component to a host. E0007 E0008

The generated record classes depend on com.ais.fc.ix.lang types such as Char, Date, Money and Record, while UI classes depend on com.ais.fc.ix.swing and external SwingX libraries. The runtime scripts identify swingx-all-1.6.4.jar, ifxjdbc.jar, jfclix.jar and itext-2.1.7.jar as classpath dependencies. This establishes declared execution prerequisites for the supplied launch scripts, not a verified production topology or host assignment. E0013 E0014

The application also depends on help resources such as helpdemo.properties or helpdemo.src. D4_Cust maps customer fields to help identifiers, and D4_Demo registers commands that call _wm.showHelp for identifiers such as 2001–2008. The help sources document capabilities and historical 4GL examples, but discrepancies exist between help text and executable source, including form names and window coordinates. Help therefore functions as a related resource dependency, not authoritative proof of current Java behavior. E0007 E0008

Boundary qualifications

The evidence supports a component relationship in which D4_Main coordinates modules, D4_Globals supplies shared state, D4_Cust, D4_Orders, D4_Stock and D4_Report implement or expose operational areas, and framework/database/report classes provide services. It does not establish that similarly named 4GL programs, generated Java classes, binary .frm files and target Java modules are one-for-one runtime components. Several .frm files contain unsupported binary content, and the relationship between those files and .per definitions remains unresolved. E0009 E0010

Detailed data structures and field representations belong in C06, interface and database exchange details in C08, command-execution and credential concerns in C09, and launch prerequisites and configuration handling in C10. The component evidence itself establishes responsibilities and calls, but not a target architecture or a verified deployment map.

Expandable topic detail

Browse all topic detail.

System context

Browse diagrams and evidence gaps.

Component cooperation

Browse diagrams and evidence gaps.