Functional specifications are useful to explain to users what the system is meant to do.
Model Reader System | Native Data Structures | Record Model Factory | Functional Specification System
Each section is structured to address purpose, description, design considerations, scope of effect, and relevant code packages.
|Purpose||To coordinate the reading of the XML Schema and the Configuration File.|
|Description||This system is a construct for classification of coding areas that are found within the
We wanted a system that was capable of supporting a replacement of the Schema Reader. This can be accomplished by having the rest of the system interact with an abstract interface rather than a specific implementation something that interprets schemas. We needed a system that could extract information about data structures from the schema and another thing to extract information about form properties that were related to that schema. This system's role as a whole is to obtain enough information/properties to drive form generation.
|Scope of Effect||
Nothing else uses this as it's an abstract concept but parts of it will be used in other places as in the case of the Configuration Reader. The components of the Model Reader System are used to synthesise Native Data Structures that are then used by the rest of the program. Most of the rest of the programme will only use the Configuration Reader.
|Relevant Code Packages||
Back to top
|Purpose||The native data structures are an in-memory representation of an XML data set.|
The basic native data structure in Project35 is the
Inheritance Hierarchy for Data Field Classes Supported in Project35
All fields will have properties such as:
The two kinds of fields are
There are four kinds of
Aggregation Relationships for Project35 Native Data Structures
The most popular utility class in the
There is a strong relationship between properties of the XML schema and properties of the native data structures. The following tables list the attributes of native data structures that should be set with values derived from a schema:
|Design Considerations||During the early development of the code base, there was a great
temptation to make the application hold all its data in DOM objects. This was because the main I/O routines were written using the DOM parser and the result of the activity was a complete in-memory tree of DOM objects. There could have been some benefit in having Project35 rely on a generic data structure that was used in other projects. However, the DOM object model had shortcomings. The generic data objects had generic means of accessing and changing data. The task of finding specific fields within a record was cumbersome and required a great deal of looping constructs. The cumbersome nature of the DOM API led me to develop a collection of native data structures that could hold better cater for operations supported by the application.
This proved to be a good decision because the application later failed to perform satisfactorily when it loaded large data files. Performance improved dramatically when the file reading routines switched from using the DOM to SAX parser. The SAX parser did not produce DOM objects, so it would have not made sense for the rest of the code base to depend on the generic data structures.
Initially the native data structures held information about both the model and view aspects of records and fields. This later caused severe performance problems because Swing-based field views were created for each field whether they were being viewed or not. The structures were later reworked in a way that rigidly separated model and view aspects. View components were only ever generated for fields in the currently displayed record.
The next problem with the native data structures related to
serialisation. The copy and paste feature in the application required
that all objects and the objects they referenced are serialisable.
This worked well until serialisation encountered things like
In the revised approach, the form generation facility would receive a form field, look up properties in the configuration reader, and instantiate services when the fields were actually displayed on the screen.
Still, many of the native data structures had too much code. Many of them such as
The result is that the data structures now hold mostly data and not information about views and services. The exception is how
|Scope of Effect||Project35's native data structures are used ubiquitously in all tools in the Project35 suite.|
|Relevant Code Packages||All of the model classes are defined in the
Back to top
|Purpose||To create instances of template records that have been defined by the Model Reader System.|
|Description||The Record Model Factory is used to instantiate instances of template records which have been defined by the Model Reader System. The instances are used for two purposes. First, the instances can be used to hold form data created by an end-user. Second, different parts of the application, such as the Form Generation System, can interrogate them to determine application properties associated with concepts defined in the XML schema.|
|Design Considerations||Early in the development of the software, there was a need to centralise the creation of container objects used to hold form data.|
|Scope of Effect||The Record Model Factory is used throughout the code base, both to create new records and to inspect the properties of template data structures that have been synthesised by the Model Reader System.|
|Relevant Code Packages||
The Record Model Factory is a single class
Back to top
|Purpose||To generate human-readable functional specifications based on information contained in the XML Schema and the Configuration File for a data entry tool.|
This system generates a functional specification based on the current state of the XML schema and configuration file options associated with a given data entry tool. Application designers may generate functional specifications during any time they edit a configuration file for their model. The feature is intended to help Project35 support a rapid prototyping activity which can let non-technical project leaders better understand the features that are supposed to be supported by a data entry tool. The specifications can be used to inform the specifications of the final data entry tool product, whether that tool is generated by Project35 or developed from scratch.
The package uses two main sources of information to produce the specification:
Project35 interrogates the
However, there are some properties of records and fields
which are not described by the templates. Over the years, the
software evolved so that definitions of services associated with forms
(eg: ontology services, validation services, etc) were managed through
a look-up mechanism in
The last property determines which data sets the generated data entry tool can import. Each data set that is produced by Project35 is stamped with a schema. If the schema stamp matches the schema being used to generate the data entry forms, the tool will be able to load that data set. Otherwise, the tool will indicate to the user that the schema used to create the data set doesn't match the schema being used by the data entry tool.
In many modelling efforts, a schema may contain definitions of records which themselves are imported from a smaller schema. For example, consider a data entry tool that is generated from a large complex schema describing a patient record. One of the record forms defined for the model may describe laboratory results. The definition of record fields for a laboratory result may be managed by some standards committee that specifically focus on laboratory results. If the patient record model subsumes the smaller laboratory result model, then the data entry tool should be able to import data sets that are made with the schema that just defines laboratory results.
The functional specification will include the list of compatible schemas which describe the kinds of data sets the generated data entry tool can import.
The XML Schema and Configuration File developed for a project describe the features which will be supported by a generated data entry tool. This system was developed to present the information as a functional specification that could be evaluated by non-technical stake holders of a project.
Most of the code was developed to present configuration options in HTML files that could be printed out and marked-up by people who were reviewing a demonstration of the generated application.
|Scope of Effect||
The scope of effect of the system is limited to the "Generate Functional Specifications" feature of the Project35 Configuration Tool. Changing aspects of this system should not impact any other part of the code base.
|Relevant Code Packages||The main package for the functional specification system is
Back to top