Browse Prior Art Database

Model Behavior

IP.com Disclosure Number: IPCOM000120793D
Original Publication Date: 1991-Jun-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 1 page(s) / 39K

Publishing Venue

IBM

Related People

Baber, R: AUTHOR [+4]

Abstract

The introduction of object-oriented programming technology into the field of application software development causes the need for standardization of state and behaviors of classes. Since some of the classes of objects developed are designed to be reusable and placed in class libraries, that is, are part of an application framework, standard classes must be developed to handle certain states and behaviors. In a model-view schema, the model must exhibit a standard set of states and behaviors. A representation scheme for the model states is required.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 85% of the total text.

Model Behavior

      The introduction of object-oriented programming
technology into the field of application software development causes
the need for standardization of state and behaviors of classes. Since
some of the classes of objects developed are designed to be reusable
and placed in class libraries, that is, are part of an application
framework, standard classes must be developed to handle certain
states and behaviors. In a model-view schema, the model must exhibit
a standard set of states and behaviors. A representation scheme for
the model states is required.

      The approach provided uses a two-stack deterministic pushdown
automata to represent the three states of a model class in a Model-
View schema. The model class is the base class for all 'application
objects' in the system so they all inherit the same behavior.

      The three states of the model are:
1) State A - no instantiations of the model are present in the system
2) State B - the model has been instantiated but has no dependents
3) State C - the model has been instantiated and its contents are in
memory, i.e., the model has dependents

      There is a standard set of messages which cause the state
changes in the automata:
1) open    - causes the model to switch from state B to state C
2) close   - causes the model to switch from state C to state B
3) new     - causes model to switch from state A to state B
4) dispose - causes the model to switch from state B to state A

 ...