Issues Related to Programming

1. Identify the language-related requirements of the interface

Note: some of the requirements are described in details in Chuck's MOSES document 2. The corresponding requirements in his document are listed in square brackets after each of the requirements.

Following is a list of the possible language-related needs of the MOSES interface.

From the programmers' perspective:

P-1. support of basic graphic interface components (widgets): menu, toolbar, tree, etc. required by the MOSES screen views [R13]
P-2. commercial availability of common interface components: table, chart, etc. related to MOSES specific requirements [R13 & R14]
P-3. availability of in-house experiences/components/data structure: programmers' previous experiences; ready-to-use data structures; any components ready to transfer to MOSES (for example, map viewer)
P-4. Internet support: (a) the interface can be run under the browser; (b) allow the interface access other resources over the Internet [R6]
P-5. easy database access: ready to access local and remote databases, for example, NRCS's soil database [R6]
P-6. extensibility: easy to add new functions in the future. [R20]
P-7. flexible for changes: updating of one screen view won't affect other components, i.e. support plug-n-play components [R20]
P-8. single source-code: new code will not be required to port the MOSES software to a new computer environment [R17]
P-9. price: reasonable price for IDE, components, packages, etc.
P-10. training required: relative short learning curve
P-11. equipment required: other equipment
P-12. support interfacing to FORTRAN: WEPS and WEPP will be in FORTRAN [R4]
P-13. meet the deadlines of MOSES [R11]
P-14. a minimum of user time [R15]
P-15. documentation utilities [R16]
P-16. exert a positive influence on the quality of ARS software and its supporting documentation. [R19]
P-17. availability of installation package
P-18. availability of some object-oriented properties: for example hierarchy, inheritance
P-19. leverage MOSES effort by making it compatible with other work required of the individual projects

From the users' perspective (NRCS, FS, other scientists, etc.):

U-1. good performance: not fastest on the planet but acceptable to users on their common environments [R1 & R14]
U-2. stability: errors of the system won't crash the operating system [R14]
U-3. multi-platform support: the interface can be run on Windows 95/NT, Unix, OS/2, Mac OS, etc. [R3, R5 & R14]
U-4. accessibility: user can get it whenever they want it, for example, support mobile computer, Network Computer, etc. [R14]
U-5. reliability: right data for the right person at right time, right location, for example, use remote up-to-date databases at NRCS [R14]
U-6. maintainability: low cost on installation of various versions, on-line technical support, etc. [R14, R18 & R20]
U-7. compatibility with other tools: common look-n-feel, exchange data with other tools
U-8. multimedia support: this is helpful for on-line training, help system, etc.
U-9. tracability: easy to find the error when the system crashes
U-10. serviceability: relative shorter time to recover from the crash of the system; fault-tolerance

Following is a list of features that are related to the MOSES data structure (or overall architecture):

A-1. unit conversion: support displaying the data in different unit systems
A-2. flexible view (highly user-configurable screens): letting different audiences add, remove, rearrange, or rename controllers/views, graphics, folders, etc.
A-3. switching among models: the interface will be changed accordingly while switching from one model to another
A-4. connecting multiple views to the same data set: user has the option to display data in different ways (table view, chart view, etc.) and the data in different views are synchronized, i.e. data change through one view will reflect in another openning view
A-5. support industry standard component structure: support using "off the shelf" components as much as possible [R3]
A-6. controller/view hybrids: support the concept that one user's output parameter may be another user's input parameter
A-7. "variant" access to arrayed parameters: the ability of a parameter to exchange cumulative, internal, percentage, relative, or other variations of its data with controllers, views, or internal logic
A-8. science function "plug-ins": coding the actual erosion science algorithms as replaceable components
A-9. adaptive model structure: a model structure that "grows and prunes" itself automatically as views are requested or science plug-ins are swapped (similar to #3?)
A-10. dimensional dependence between parameters: parameters "know" on whom they depend spatially. This allows them to resize automatically and generate their own graphing instructions, including axis information.
A-11. adaptive persistent objects: i.e. my soil file/object needs to transparently work in your simulation. If it lacks parameters, it will gracefully degrade the functionality or prompt for additional parameters. If it has excess parameters, it will enhance the functionality or hide the excess.
A-12. grouping of related views/components: placing parameters with the same array dimension next to each other causes them to share a common scroll bar and allows them to be moved as a single table.
A-13. clear visual model hierarchy: layered object structure, with data details initially hidden. User drills-down via obvious paths (icons, buttons, ??).
A-14. user-input guidance: controls that in some way communicate to the user whether a value is provided, required, calculated, static, etc.

2. Identify the languages and tools that can be used to address these requirements

I believe it's impossible to find a solution that get the best result in every requirement category. As of language of choice, we will only focus on Microsoft Visual C++ and Java. If Windows 95/NT is the only targeting platform, then Visual Basic, Delphi and Borland C++ are also good choices. If multi-platform support is required, then PowerBuilder is an option. Based on programmers' previous experiences and some other reasons, these four options are not considered. HTML is also considered as a multi-platform option but it definitely won't meet most of the requirements listed above.

 

Tools related to Visual C++:

IDE:

Component data structures:

GUI framework:

 

Tools related to Java:

IDE:

Component data structures:

GUI framework:

 

Tools may be used (independent to languages):

 

3. Weight the requirements relative to their importance to the success of MOSES

Please refer to the weighting scheme for system requirements by Chuck Meyer.

 

4. Estimate how well each language or tool (or combinations of them) can meet each requirement

 

5. Recommend the best solution (MOSES architecture) to the group at large