As mentioned earlier, OOSTD consist of set of design patterns, making application design easier and more intuitive. But there is more then that. OOSTD also deploys several ideas, which can be summarized as:
XDataInstance: is a component which converts any DataInstance into generic XML format. The DTD is a reflection of the DataInstance structure. It takes advantage of DataInstance's classification by DataClass. It uses the DataClass to retrieve the metadata information about the data being converted into XML.
DataView, XDataView: are components holding information about the way certain DataInstance or DataInstanceSet are displayed. This has dependence on the "model life cycle" described later on. The definition of the view is part of the model. The views are instantiated by ComponentInitializer and initialized by the information coming from the model. Therefore, if there is a modification of DataInstances metadata, such as added/changed/removed property, then such a modification is propagated from the model (created by visual modeling tool) into the model image file, which is being read by the ComponentInitializer, which in turn initializes the component with reflection to just performed modification.
Since this is all generic functionality, there is no code modification necessary and more, if the application is coded well, such a change can be done and deployed on the server without a need of server's restart.
Model's life cycle: is shown in figure 7.1. ModelerGUI is a visual tool used for model creation and modification. The model is stored in model image file which is in turn used in numerous ways. First, it is the input into the ComponentInitializer, described in section 7.1, which creates and initializes components used throughout application's life cycle. Some of the components are the DataClasses, Properties, Relations, etc. This has the already described advantage of propagating model changes into the application without a need of code modification. Next, the image can be used for generation of database creation or upgrade-tion scripts, EJB descriptor files, etc. The obvious advantage of such a life cycle is, that the model information is maintained centrally, by the visual modeling tool and then propagated whenever appropriate.
Contex: is a side product of the "Model's life cycle" and the generic view components. It is a content entry / modification tool, which uses the model as input information for creation of data entry forms, used for the data manipulation. Together with the object storage abstraction, described in chapter "Data storage technique generalization", is Contex able to manipulate data seamlessly from relational / object databases, with variety of object mapping schemas; from XML files, etc. And the best of all, to build tool which fits the specific scenario, there is no coding necessary. It is all driven by the information from the model. Contex can manipulate both the data entity and their relations. Context is also independent of used GUI. It can either be HTML based (client-server), or local JavaTM GUI application. Contex's data flow is shown in figure 7.2.

Figure 7.1: Data Flow Diagram: model life cycle

Figure 7.2: Data Flow Diagram: Contex