Software Architecture & Design

Epi Info 7Software Architecture & DesignVersion 2.0.0 Draft2/27/09VERSION HISTORY

Version #Implemented

ByRevision

DateApproved

ByApproval

DateReason

0.0.1Victor Natic03/25/2006Initial Draft

0.0.2Donna Davis04/07/2006QA Review; formatting accuracy; editing

0.0.3Victor Natic04/18/2006Significant changes to Process View and Visio designs

0.0.4Donna Davis04/21/2006Formatting and grammatical editing

0.0.5Donna Davis06/28/2006Updated document to reflect Epi Info 7 vs. Epi Info .NET.

0.0.6Asad Islam02/21/2007Updated document to reflect changes to the software architecture.

0.1.6Donna Davis02/27/2007QA Review

1.2.6Donna Davis03/12/20072nd QA Review after management review.

1.2.7Kishore Meduri03/15/2007Modified the introduction, purpose and goals sectionsUpdated the list of data models.

Modified description of Collected data model.

1.2.8Kishore Meduri06/04/2007Removed Data View. Referenced Data model document;Updated References list

1.2.9Kishore Meduri08/03/2007Consolidated Data Model, Implementation Model and Design Model.

1.2.10Estrelita Jones08/03/2007Added Target Folder Structure to document and Table of Figures

1.2.11Estrelita Jones08/07/2007Added all figures to Table of Figures; Made capitalization corrections

1.2.12Estrelita Jones08/13/2007Added Target Folder Structure Diagram 2 created by Meng Shu and text regarding setup program

1.2.13Kishore Meduri08/17/2007Organized Process model by module

1.2.14Estrelita Jones08/17/2007Added verbiage for second diagram of Targer folder structure

1.2.15Meng Shu08/17/2007Added description of Menu module process sequence diagram

1.2.16Kishore Meduri08/20/2007Reformatted Architectural Goals and Constraints section

1.3.6SC Jones04/15/2008Formatting, Grammar and QA Review.

2.0.0Kishore Meduri2/27/09Removed CDC logo

Formatted for community edition

Executive SummaryThe Epi Info Development Software Architecture and Design document will provide details regarding the architectural approach and design details of Epi Info 7. The software architecture is a blueprint of the software system. The architecture composition and the functionality that it provides is a guide to be used by the development team during product development.TABLE OF CONTENTS

11Introduction

11.1Purpose

11.2Scope

11.3Definitions, Acronyms, and Conventions Used

21.4References

31.5Overview

32Architectural Representation

43Architectural Goals

43.1Extensibility of the Product

43.2Migration to .NET

43.3Support for Multiple Database Engine Types

43.4Separation of Metadata from Collected Data

43.5Support for Standard Vocabulary and SRTs

43.6Web-Enablement

53.7Componentization and Integration with Other Systems

53.8Backward Compatibility

54Architectural Strategy

55Architectural Constraints

56Use Case Model

67Implementation Model

67.1Application Tiers

77.2Components & Subsystems

77.2.1Components and subsystems to be implemented

97.3Target Folder Structure

98Data Model

108.1Project Data

108.1.1Project Information

118.1.2Metadata

118.1.3Collected Data

128.2Application Static Data

138.3Configuration Data

148.4Translation Data

149Logical Model

149.1System Class Diagrams

159.1.1Projects & Views - Class Diagram

169.1.2Fields - Class Diagram

179.1.3Data Sources - Class Diagram

189.1.4Data Access Layer - Class Diagram

199.1.5User Interfaces - Class Diagram

209.1.6Command Processing - Class Diagram

209.1.7Framework Commands - Class Diagram

219.1.8Analysis Commands - Class Diagram

229.1.9Analysis Command Processing

239.1.10Analysis Command Processor Hierarchy

249.1.11Translation Mechanism Class Diagram

259.1.12Make View GUI - Business Logic Separation - Class Diagram

2510Process Model

2610.1Process Model - Make View Module

2610.1.1Form Rendering - Sequence Diagram

2610.1.2Control Interaction - Sequence Diagram

2710.1.3Field Updating - Sequence Diagram

2710.1.4Delete Page - Sequence Diagram

2810.2Process Model - Analysis Module

2810.2.1PGM Execution - Sequence Diagram

2910.3Process Model - Menu Module

2910.3.1MENU Module Process - Sequence Diagram

TABLE OF figures

6Figure 1: Epi Info Application Tiers

8Figure 2: Epi Info 7 Component Model Diagram

9Figure 3: Epi Info 7 Application Target Folder Structure

10Figure 4: Project Data

11Figure 5: Metadata

12Figure 6: Application Static Data

13Figure 7: Configuration Data

14Figure 8: Translation Data

15Figure 9: Projects & Views - Class Diagram

16Figure 10: Fields - Class Diagram

17Figure 11: Data Sources - Class Diagram

18Figure 12: Data Access Layer - Class Diagram

19Figure 13: User Interfaces - Class Diagram

20Figure 14: Command Processing - Class Diagram

20Figure 15: Framework Commands - Class Diagram

21Figure 16: Analysis Commands - Class Diagram

22Figure 17: Analysis Command Processing Diagram

23Figure 18: Analysis Command Processor Hierarchy Diagram

24Figure 19: Translation Mechanism - Class Diagram

25Figure 20: Make View GUI - Business Logic Separation - Class Diagram

26Figure 21: Form Rendering - Sequence Diagram

26Figure 22: Control Interaction - Sequence Diagram

27Figure 23: Field Updating - Sequence Diagram

27Figure 24: Delete Page - Sequence Diagram

28Figure 25: PGM Execution - Sequence Diagram

29Figure 26: MENU Module Process - Sequence Diagram

1 Introduction

This document details the software architecture that will be used to develop Epi Info 7. The software architecture follows the (4+1) RUP model and also includes details on the following: System structure of Epi Info 7. An overview of the software configuration of Epi Info 7. An overview of the system components, their functionality, interfaces, communication and organization.

The document outlines the architectural approach to the sponsor and project members, but most importantly provides the architectural foundation required by the development team to build and deliver the product functionality and meet overall system requirements.

1.1 Purpose

The purpose of this document is to define the software architecture of Epi Info 7 and capture design details. This document provides a comprehensive architectural overview of the system, using a number of different RUP models to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made. The document content will be used by the development team as a guide that will aid during the development, testing and deployment of Epi Info 7. This document will highlight the system components, communication and overall responsibility of each component with the objective to facilitate the planning and organizing of development activity, responsibility and overall execution of each phase of the project. 1.2 Scope

The Epi Info Development Software Architecture and Design document defines the software architecture of Epi Info 7. This document does not define interfaces to other applications but does establish a framework that can be used to enable subsequent integration to other systems such as World Health Organization (WHO) OpenHealth.1.3 Definitions, Acronyms, and Conventions UsedThe diagrams in this document are illustrated using the Unified Modeling Language (UML) 2.0 notation. The UML is a language for visualizing, documenting, and specifying software systems, particularly object-oriented systems. The Object Management Group (OMG) officially adopted the UML as a standard modeling language for software systems in 1997. BuildA version of a program or application.

ComponentA physical, replaceable part of a system that packages implementation and conforms to and provides the realization of a set of interfaces.

ExeA binary and executable file that acts as a program that performs tasks on a computer.

SubsystemA set of elements, which is a system itself, and is a part of the whole system.

Use caseA sequence of transactions between a system and an actor in response to a triggering event initiated by the actor. A use case typically represents a system function that provides a visible or measurable result for an actor. More formally, a use case defines a set of use case instances or scenarios.

XMLExtensible Markup Language is a W3C initiative that allows information and services to be encoded with meaningful structure and semantics that computers and humans can understand.

For definitions of other terms used in this document, see the Epi Info 7 - Glossary.doc.

1.4 References

Epi Info 7 Glossary.doc Epi Info 7 - International Localization Process.doc Object Management Group, OMG Unified Modeling Language Specification, Version 1.4, and September 2001.

Microsoft, Web Services Model, http://msdn.microsoft.com/webservices/understanding/default.aspx?pull=/msdnmag/issues/02/10/xmlfiles/default.aspx. Product Software Implementation Method

http://en.wikipedia.org/wiki/Product_software_implementation_method Defining the Implementation Model

http://safari.orielly.com/0321200195/ch05lev1sec4 Artifact: Implementation Model

http://www.yoopeedoo.org1.5 Overview

The Software Architecture and Design document describes the architecture of Epi Info 7 using the Unified Process five-view model of architecture. These five models include the Use Case Model, Logical Model, Process Model, Data Model and Implementation Model. The Use Case Model contains architecturally significant use cases that establish the need for each of the specific architecture components and addresses functional requirements of the system. The Logical Model describes the system, network and class level product structures. This includes the network topology, and low-level class specifications that will consist of building blocks for the entire system. The Process Model addresses process flow, concurrent aspects of the system at runtime, including process communications, threads and process interactions. The Data Model addresses the persistence requirements of the system. Finally, the Implementation Model describes the network topology and various runtime components and the organization of the software modules in terms of packaging, layering, and configuration management.Architectural Representation

The Software Architecture and Design of Epi Info 7 is represented following the recommendations of Rational Unified Process (RUP). The UML specification of the system has been divided into the following 4 views:

Use-Case Model Describes the actors and use cases for the system, this model presents the needs of the user and is elaborated further at the design level to describe discrete flows and constraints in more detail. This domain vocabulary is independent of any processing model or representational syntax (such as XML) or any specific technologies used to implement the use case model. Logical Model Describes the system, network and class level product structures. This includes the network topology and low-level class specifications that will consist of building blocks for the entire application. Process Model Describes the overall system functionality on a module by module basis. It contains the process flow interactions and the resulting components that each module will contain. Data Model Describes the storage layout of the following persistent data categories:1. Project data containing project information, Metadata (View definitions) and Collected data (data collected using Epi Info 7 views).2. Application static data - Static data deployed along with Epi Info 7.3. Configuration data containing dynamic data (Permanent variables, Current project, MRU projects etc.) and settings (Out-of-the-box as well as user changeable); key/value pairs that affect behavior and function of the software.4. Translation data Translation strings in various supported languages. Implementation Model Describes the components and their interactions.

Collectively, the above models form a complete UML specification of the system.

Architectural Goals

The following goals have prompted the redesign of Epi Info and have been taken into account during the design phase of the product architecture.1.6 Extensibility of the Product The product has evolved over the last 7 years and the architecture in place then as well as a number of changes implemented over that period of time has led to software that is difficult to maintain, enhance and ultimately limits the ability to support the growing demands of the business. The objective is to reorganize the product code eliminating redundancy and establish a reusable model that will facilitate product maintenance and product expansion.

1.7 Migration to .NET The product was initially a DOS based application subsequently migrated to VB6. Epi Info is a critical product suite to outbreak management and integrated surveillance. The growing demands for product integration have led to recognition of the need to migrate to the .NET framework. Additionally, the limitations of the current data consolidation strategy calls for the separation of the view metadata from the actual data collected. Doing so enables global sharing and distribution of outbreak management templates and centralization of information gathered and collected nationally and internationally.

1.8 Support for Multiple Database Engine Types Monitoring outbreaks requires a collaborative effort that generally involves multiple countries and locations globally. As the amount of data increases so does the need for a more robust database engine that can manage the volume of data collected and the daily transactions throughput. The Epi Info Development effort will expand the number of database engines that are supported by the product. This includes not only Microsoft Access 97 & 2000 but also Microsoft SQL Server 2000 as well as MSDE 2000.

1.9 Separation of Metadata from Collected Data One of the key objectives of the re-architecture is the separation of view Metadata from the epidemiological information collected. This is especially important to enable sharing of Epi Info applications which may have been defined in one location of the world with other countries/regions desire and need to monitor the same outbreak.1.10 Support for Standard Vocabulary and SRTs The Epi Info 7 architecture will take in consideration the ability to create fields that are compatible with standard vocabularies such as PHIN and state and local jurisdictions.

1.11 Web-Enablement

The ability to expand scope to provide a web-based user interface layer in future.1.12 Componentization and Integration with Other Systems

Significant advancements and changes in systems architecture capabilities and the wide adoption of web services as a standard for integration set forth the need for ensuring we are positioned for web services as an integration strategy long-term. Although the overall product architecture of Epi Info must facilitate the stand-alone implementation of the product in a low end hardware configuration, the need for long-term integration and cross-product communication certainly highlights the need for supporting and introducing a web services based architecture. Although this is not part of the base year deliverables, it must be kept at the forefront during the architectural design and during the development of the product.1.13 Backward Compatibility It is paramount to make sure that huge investments made by the partner groups are preserved and all applications developed to date can run on the new platform with little migration required if any.2 Architectural StrategyThe Software Architecture and Design will employ the following strategy to achieve the aforementioned goals: Introduction of XML schemas wherever applicable and feasible. Robust normalized data models that will position the product for scalability and expansion.

Restructure of the product to eliminate conflicting and simultaneous operations within the product such as the current ability to enter data while defining views.

Modularized development architecture that will facilitate development, maintenance and provide a building block approach to enable integration to other products and a basis for the Epi Info 7 suite of products evolution.

Module-by-module download capabilities that enable users to selectively choose the portions of the product they need.

3 Architectural ConstraintsThe product constraints consist of the following: ESRIs ArcGIS 9.2 mapping tool and the capabilities of the version of the software.

The common functionality available within Access 97, Access 2000, Microsoft SQL Server 2000 and MSDE 2000.

Use Case ModelThe Use Case Model describes the architecturally significant use cases in Epi Info 7 and the actors that interact with the system in each use case. Preconditions, post conditions, extension/inclusion points and special requirements are identified for each use case.

The Use case model is described in the Epi Info 7 Use Case Model.doc. Implementation Model

The Implementation Model shows an overview of the layers, subsystems, components, packages and all related diagrams.

3.1 Application Tiers

Figure 1: Epi Info Application Tiers3.2 Components & Subsystems

3.2.1 Components and subsystems to be implementedThe Implementation Model describes clearly defined responsibilities, behaviors and interfaces of various components of the system.

Components to be implemented within the system consist of executables, libraries (dlls), databases, XML files and source code files, etc. The Epi Info 7 Component Model Diagram depicts all components that will be implemented and/or used by the system. The following information will provide an overview of the components noted in the diagram -- each will be categorized according to its type:1. Executable files

The following executable files are to be implemented to provide end-users a mechanism for running individual modules independently instead of running the entire Epi Info 7 application: Analysis.exe, Enter.exe, MakeView.exe, and EpiMap.exe. The EpiInfo7.exe file will be implemented to allow users to run Epi Info 7 from its menu screen. 2. Libraries (dlls)

The following dlls are to be implemented: Epi.Analysis.dll, Epi.Map.dll, Epi.MakeView.dll, Epi.Enter.dll, Epi.Framework.dll, SystemEx.dll, Epi.Analysis.BusinessLogic.dll, and Epi.Enter.BusinessLogic.dll. Unlike executable files, dlls cannot be run directly, but are necessary to provide the availability to call upon smaller programs when called upon by an executable (exe) program that is currently running.

3. Database Objects

Database tables containing language translations and static information pertinent to the application will be implemented.

4. XML files

The XML file, EpiInfo.config, will be implemented as it houses the configuration settings for an end-users Epi Info 7 project.

5. Images

All images files (jpeg, gif, bmp, png, ico, tiff) utilized by Epi Info 7 will be implemented.Items that will also be implemented, but are not depicted on the diagrams in this document are the dlls and executables for modules, EpiReport and EpiGraph as well as menu file components. Dlls, GoldParserEngine.dll and Calithalib.dll, to be utilized with the parsing tool, Gold Parser, are also not depicted in the diagram but will be implemented because they are essential to the application. The aforementioned items will be included within the document in more detail as their roles within the Epi Info 7 application are more clearly defined.

Figure 2: Epi Info 7 Component Model Diagram

3.3 Target Folder Structure

In deploying the Epi Info 7 application, it is essential to designate where the files utilized by the application will be housed on user machines. The target folder structure of the Epi Info 7 application determines the extent to which content management responsibility is centralized and distributed. The application will be housed under the drive of the users choice. All files pertinent to the Epi Info 7 application will be placed in the directory: (drive:)\Program Files\Epi Info 7. Dlls and executable files are located in the main directory; whereas, configuration, database, image, language, and output files will be located within categorized folders under the aforementioned directory. By default, the Setup program will also install InstallShield add-on files for Java Virtual Machine and uninstaller files in folders: _isus, _jvm and _uninst under the directory: (drive:)\Program Files\Epi Info 7. The following diagram depicts Epi Info 7s target folder structure, where the C drive (C:) is assumed to be the users desired installation drive.

Figure 3: Epi Info 7 Application Target Folder Structure

Data Model

The following persistence requirements are identified in Epi Info 7 Use Case Model:

Project Data Includes Project Information, Metadata and Collected data

Application static data

Configuration data

Translation data

3.4 Project Data

3.4.1 Project Information

Project information is stored in an XML file. Information stored consists of the project ID, project name, project location, version and other pertinent details of the project. The following figure shows the schema of the project file.

Figure 4: Project Data

3.4.2 Metadata

The Metadata contains details about view definitions including fields, field formats, field types, location and pages. It also contains pre and post validations on pages, fields, records, and views, and all of the properties associated with the definition of a view.

Epi Info 7 creates Metadata databases at the time a project is created. The software defines and uses scripts for creating view Metadata databases in Access 97, Access 2000 and SQL Server 2000 (and MSDE 2000).

Figure 5: Metadata

3.4.3 Collected Data

The Collected Data is a relational database that contains all data collected using an Epi Info 7 view. This database is created at the time a project is created by the user. The software is capable of creating this database in Access 97, Access 2000 and SQL Server 2000 (and MSDE 2000)

This data model contains one table per view each containing all input fields of the view. In addition, each table contains the following two fields:

1. UniqueKey: GUID

2. RecStatus: Short

3.5 Application Static Data

The Application static data is deployed with Epi Info 7 and the user will not be able to change it. It is stored in an Access 2000 database.

Figure 6: Application Static Data

3.6 Configuration Data

Configuration data contains the following:

Settings (default, current and temporary)

Permanent variables

Current project

Recently used projects and views

Configuration data is stored in an XML file. The following figure shows the schema of the XML file:

Figure 7: Configuration Data

3.7 Translation Data

All translated text strings are stored in a Microsoft Access 2000 database called Translations.mdb. The database contains the following columns:

1. English: English strings to be translated.2. Instructions: Contains instructions to translators regarding context, meaning and tone of the specific term / string.

3. Scope: Contains names of all modules and applications the string is used. This file is null for strings used across many modules of Epi Info 7. For example, OK, Close, etc.

4. One column for each language supported. The language name is prefixed with lang_. For example, lang_Spanish, lang_French etc.

Figure 8: Translation Data

Logical ModelThe Logical Model focuses on the high-level technical class diagrams. This section is intended for a technical audience.3.8 System Class DiagramsThe system class diagrams comprise very low-level class structures that will be used throughout the development of the product. The class structures provide access to globally accessible system functionality and system information.3.8.1 Projects & Views - Class Diagram

Figure 9: Projects & Views - Class Diagram3.8.2 Fields - Class Diagram

Figure 10: Fields - Class Diagram

3.8.3 Data Sources - Class Diagram

Figure 11: Data Sources - Class Diagram3.8.4 Data Access Layer - Class Diagram

Figure 12: Data Access Layer - Class Diagram3.8.5 User Interfaces - Class Diagram

Figure 13: User Interfaces - Class Diagram3.8.6 Command Processing - Class Diagram

Figure 14: Command Processing - Class Diagram3.8.7 Framework Commands - Class Diagram

Figure 15: Framework Commands - Class Diagram

3.8.8 Analysis Commands - Class Diagram

Figure 16: Analysis Commands - Class Diagram3.8.9 Analysis Command Processing

Figure 17: Analysis Command Processing Diagram

3.8.10 Analysis Command Processor Hierarchy

Figure 18: Analysis Command Processor Hierarchy Diagram3.8.11 Translation Mechanism Class Diagram

Figure 19: Translation Mechanism - Class Diagram3.8.12 Make View GUI - Business Logic Separation - Class Diagram

Figure 20: Make View GUI - Business Logic Separation - Class Diagram

Process Model

This section describes architecturally significant process structures of the system. The process view describes the tasks (processes and threads) involved in the system's execution, their interactions and configurations, as well as the allocation of objects and classes to tasks.3.9 Process Model - Make View Module

3.9.1 Form Rendering - Sequence Diagram

Figure 21: Form Rendering - Sequence Diagram3.9.2 Control Interaction - Sequence Diagram

Figure 22: Control Interaction - Sequence Diagram3.9.3 Field Updating - Sequence Diagram

Figure 23: Field Updating - Sequence Diagram3.9.4 Delete Page - Sequence DiagramAnother functionality of Epi Info is the ability to delete pages from a view within the MakeView module. There are several methods and objects utilized to accomplish this task. The following diagram depicts the interactions between the objects and displays the methods used.

Figure 24: Delete Page - Sequence Diagram3.10 Process Model - Analysis Module

3.10.1 PGM Execution - Sequence Diagram

A significant function of Epi Info is the ability to read and execute program code provided by the user. This involves interaction with a third-party LALR Parser called Gold Parser. The following diagram describes the interactions between this third-party module and Epi Info command processing structures.

Figure 25: PGM Execution - Sequence Diagram3.11 Process Model - Menu Module

3.11.1 MENU Module Process - Sequence Diagram

Epi Info is a series of modules for public health surveillance system. Menu is usually the first module for professionals to start with the process. The Menu module is driven by Menu file that contains two major parts: screen definition section and command block definition section. Menu reads screen definition text to make Menu module user interface. Menu has the ability to read and execute command blocks requested by the user. The command process involves a third-party LALR Parser called Gold Parser. The following diagram describes the Menu screen creation and the command execution process structures.

Figure 26: MENU Module Process - Sequence Diagram

_1235218095.vsd

_1247651175.vsdStatic Structure

+Execute(in tokens : Token[], in results)+Command(in session : Session)

#currentSession : Session = null

Command

+Execute()+ReadCommand()#FormatOutput()

#table : IDataMember

ReadCommand

+Execute()+ReadFileSpecCommand()-OnCommandProcessingRequested()

ReadFileSpecCommand

+Execute()+SimpleReadCommand()-OnCommandProcessingRequested()

SimpleReadCommand

+Execute()+DefineGlobalVariableCommand()-OnCommandProcessingRequested()

DefineGlobalVariableCommand

+Execute()+DefineStandardVariableCommand()-OnCommandProcessingRequested()

DefineStandardVariableCommand

+Execute()+SetCommand()-OnCommandProcessingRequested()

SetCommand

+Execute()+FreqColumnsCommand()-OnCommandProcessingRequested()

FreqColumnsCommand

+Execute()+ListAllCommand()-OnCommandProcessingRequested()

ListAllCommand

_1247651309.vsdStatic Structure

+CommandProcessorResults()

+HtmlOutput : string = string.Empty+XmlOutput : XmlDocument = null

CommandProcessorResults

+FileBasedPgm(in filePath : string)+FilePath() : string

-filePath : string = string.Empty

FileBasedPgm

+GlobalVariable(in theName : string)

GlobalVariable

+JoinTable()+JoinTable(in table : IDataMember, in condition : string)+Table() : IDataMember+Condition() : string

-table : IDataMember = null-condition : string = string.Empty

JoinTable

+Pgm()+Pgm(in name : string)+Pgm(in programRow : DataRow[])+Name() : string+IsBlank() : bool+CreateDate() : DateTime+ModifiedDate() : DateTime+Text() : string

-name : string = string.Empty#createDate : DateTime#modifiedDate : DateTime#text : string = string.Empty

Pgm

+ProjectBasedPgm(in dataRow : DataRow[], in selectedProject : Project)+Author() : string+Comment() : string+Project() : Project

-author : string = string.Empty-comment : string = string.Empty-project : Project

ProjectBasedPgm

+Session()+AnalysisDataTable() : AnalysisDataTable+StandardVariables() : VariableCollection+GlobalVariables() : VariableCollection+GetAllVariablesAsDataTable(in includeColumns : bool, in IncludeStandard : bool, in includeGlobal : bool, in includePermanent : bool) : DataTable+GetGlobalVariablesAsDataTable() : DataTable+InitializeDataTable()

-dataTable : AnalysisDataTable = null-globalVariables : VariableCollection = null

Session

+StandardVariable(in theName : string)

StandardVariable

#Variable(in nam : string)+Name() : string+Value() : string+DataType() : DataType

-name : string = string.Empty-val : string = string.Empty-dataTypeId : DataType = Enum.DataType.Unknown-dataType : DataType = null#scope : VariableScope

Framework::Variable

+GlobalVariable(in theName : string)

Framework::GlobalVariable

+StandardVariable(in theName : string)

Framework::StandardVariable

_1269936025.vsdStatic Structure

+Results() : CommandProcessorResults+CommandProcessor()+RunCommand(in commandText : string) : CommandProcessorResults+RunPGM(in commandText : string) : CommandProcessorResults#GetCommandObject(in ruleId : int) : Command-Parser_OnReduce(in parser : LALRParser, in args : ReduceEventArgs)-parser_OnTokenError(in parser : LALRParser, in args : TokenErrorEventArgs)-parser_OnParseError(in parser : LALRParser, in args : ParseErrorEventArgs)-cmd_CommandProcessingRequested(in command : string)

-parser : LALRParser-results : CommandProcessorResults-shouldProcessSingleCommand : bool

CommandProcessor

+Results() : CommandProcessorResults#GetCommandObject(in ruleId : int) : Command+CommandProcessor(in theSession : Session)

-results : CommandProcessorResults-currentSession : Session = null

CommandProcessor

_1235218139.vsd

_1233484489.vsd

_1233558967.vsd

_1233576759.vsd

_1233492695.vsd

_1233484378.vsd