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

Actors and Value Streams

Diagram coverage

Human actors and their responsibilities

The primary human actor is an interactive application operator using the desktop menus. In the Java application, D4_Main.run() presents Customer, Orders, Stock, Reports, and Exit commands, with additional ! and X commands. This makes the operator responsible for selecting the business activity, supplying search and maintenance information, choosing output destinations, and responding to confirmations or interruption prompts. The source identifies the application as Swing-based through com.ais.fc.ix.swing.application.GUIApplication, although the supplied evidence does not establish how many operational user roles are deployed in practice. E0001

Within that broad operator role, the source supports several practical responsibilities:

• A customer-maintenance operator creates, searches, updates, and deletes customer records through D4_Cust.java. Customer data includes names, company, addresses, city, state, ZIP code, and phone. Deletion requires a selected customer and confirmation, and is blocked when the customer has counted orders. The precise meaning of “active” in the user message is unresolved because the SQL shown counts orders without an explicit active-status predicate. E0007 E0002
• An order-entry operator selects or creates a customer, enters order-header information and line items, looks up stock and manufacturer information, and completes a new order. The implemented Java path is D4_Orders.add_order(). It supports line-item entry, item totals, order insertion, item insertion, commit, and invoice generation. E0002 E0011
• An order-inquiry operator uses D4_Orders.get_order() to find orders for a customer and inspect their associated items. This is a viewing and selection responsibility, not evidence of general order maintenance. In particular, D4_Orders.update_order() and delete_order() display “This option has not been implemented.” E0002 E0012
• A report operator selects mailing-label or accounts-receivable reporting and chooses file, printer, or screen output through print_option. The source implements these two report paths, while backlog and stock-list report functions remain stubs. E0007 E0002
• A privileged operator exists in a separate legacy flow, menu1.4gl.main. That program asks whether the user has privileged status and exposes all menu options to a privileged user; a nonprivileged user sees only Query, Detail, Switch, and Exit. This role model belongs to menu1.4gl.main and should not be silently assigned to the Java D4_Main menu, for which equivalent authorization behavior is not established. E0009

The evidence also shows an operator using state and stock selection as supporting activities rather than independent business outcomes. State selection can open state_list, and order entry can open a stock-selection view when the operator needs to identify a stock number and manufacturer code. These interactions support customer address completion and order-line completion, but the supplied material does not establish that they constitute separately authorized roles. E0007 E0009

Customers and manufacturers are business participants in the records, but they are not evidenced as direct users of the desktop application. A customer is selected, created, or maintained by an operator and becomes the owner of orders and accounts-receivable entries. Manufacturers and stock records provide reference information for order lines. The source contains manufacturer unload data and stock records, but does not show a manufacturer-facing interaction. E0009

System actors and external participants

The Java application runtime coordinates menus, forms, shared state, database calls, reports, and help. D4_Main creates the application through AppFactory, obtains the stores7 database through _app.getDB("stores7"), loads state and stock reference arrays, and starts the main menu. D4_Globals exposes shared objects such as p_customer, p_orders, p_items, p_stock, p_state, counters, and print_option. This is evidence of application-wide mutable state, but not of persistence, session isolation, or thread safety. E0002 E0012

The stores7 database is the principal persistence actor. The Java evidence shows JDBC-oriented operations against tables including customer, orders, items, stock, manufact, and state; the legacy 4GL sources likewise declare and query stores7. The database supplies customer, order, item, stock, manufacturer, and state data, generates identifiers used through SQLCA.SQLERRD[2], and participates in order transactions. The exact schema, constraints, and deployment precedence are unresolved. In particular, one configuration points to a local Informix JDBC endpoint while another points to [internal hostname redacted]; these may represent different contexts, but the evidence does not establish which configuration is active. E0007 E0008

The report/output subsystem acts as a downstream participant. Report code sends rows to a file, printer, or screen according to print_option; invoice generation follows successful order creation. The report framework’s lifecycle is not included, so the source establishes intended calls to start, emit, and finish reports but not the exact completion semantics. E0002 E0012

The application framework supplies UI objects, input handling, database helpers, error handling, report objects, and module lookup. Classes such as Application, DBHelper, ErrorHandler, Construct, and report implementations are used but not fully supplied. Consequently, status-code interpretation, rollback behavior after unexpected exceptions, query construction safety, and command execution scope remain framework-dependent questions. These dependencies are described in more detail in C07 and C08.

A separate command-execution path is exposed by the ! or bang command. D4_Main.bang() accepts a command and passes it to _app.execute(true, Str.valueOf(cmd)). The source provides no allowlist or input restriction. This makes the interactive operator a potential initiator of commands beyond ordinary business processing, while the exact permissions of Application.execute() remain unresolved. Security implications belong in C09, not in the ordinary value-stream description. E0001 E0012

Customer maintenance value stream

The customer-maintenance stream converts operator-supplied identity and contact information into a persisted customer record that can be reused by order entry, browsing, labels, and accounts receivable. The Java evidence supports creation through input_cust() and insertion into customer, query and browse by customer fields, update by customer_num, and guarded deletion. The browse function supports directional navigation and selection, allowing the operator to establish the current customer context for subsequent work. E0007

The stream has two different evidence bases that should remain distinct. demo/source/d4_cust.4gl directly describes the legacy 4GL functions add_customer(), query_customer(), update_customer(), and delete_customer(), while demo/target/java/src/com/ais/demo/D4_Cust.java provides corresponding Java behavior in the supplied recovery. The evidence does not prove that the Java class is a one-to-one translation of every displayed 4GL source. E0010

State lookup supports this stream when the operator enters an invalid or missing state code. The operator can select from state codes and names through state_list; the resulting code is placed back into the customer record. Whether every Java input path wires this callback identically remains unresolved. Detailed validation and data rules are covered in C05 and C06. E0009

Order-entry and invoice value stream

The order-entry stream joins an existing or newly created customer with order-header data and one or more stock-based line items. The operator supplies the order date, purchase-order number, shipping instructions, stock and manufacturer selections, and quantities. Stock lookup supplies description and unit price; item totals are calculated from quantity multiplied by unit price. The implemented D4_Orders.add_order() then inserts the order and items within explicit transaction branches, commits on success, and invokes invoice generation. E0007 E0011

This stream produces several outputs: a persisted order header, persisted item rows, an order number, and an invoice routed to the selected output destination. If an order or item insertion reports failure, rollback is attempted and the operator receives an error. The source does not prove that every exception after transaction start causes rollback, because the framework exception path is not present. E0012

The total presented during order processing has a qualified interpretation. order_total() applies a 1.1 multiplier, while invoice logic separately calculates 6.5% sales tax and 3.5% shipping. These figures suggest a common ten-percent intention, but rounding and whether the interactive and invoice totals are exactly equivalent remain unresolved. The detailed monetary conditions belong in C05 and C06. E0012

The legacy ordmenu.4gl.main describes a distinct order flow with Add, Query, Modify, Delete, and Exit, including replacement of order items. It must not be merged with the Java D4_Orders flow: the Java implementation explicitly leaves update and delete unimplemented, whereas ordmenu.4gl.main reports Modify and Delete behavior. The relationship between these artifacts and their runtime use is unresolved. E0009 E0002

Reporting and receivables value stream

The reporting stream turns selected customer or order data into operational output. Mailing labels use customer query-by-example criteria and order results by ZIP code; accounts receivable selects orders whose paid_date is null and groups customer and order information for output. The operator can direct output to a file, printer, or screen, with file paths defaulting to names such as labels.out or ar.out in the legacy source. E0007

Backlog and stock-list options remain visible in the report menus but are not delivered capabilities in the Java implementation: print_backlog() and print_stock() report that they have not been implemented. The help material independently describes those options as incomplete. Their presence in interfaces, menus, or documentation therefore represents intended surface area rather than a completed value stream. E0002 E0004

The current actor/value-stream boundary is consequently uneven: operators can maintain customers, create and inspect orders, and produce two report types, while stock maintenance, order update/delete, and two report types terminate in explicit unimplemented paths. Journey conditions, state changes, and failure handling are detailed in C04, while operational prerequisites and output handling are covered in C10.

Actor workflow / activity

Browse diagrams and evidence gaps.

Related lifecycle state machine

Browse diagrams and evidence gaps.