JP2000502198A - Object Oriented System with Shared Persistence Class Pattern Specification - Google Patents

Abstract

(57) [Summary] An object-oriented system includes a base class and related derived classes. The state selector class provides state selection to the base class. The class of the operational object is related to the base class through a set. Each operational object includes an internal object having a pair of internal objects having an internal state and a selector performing an operation of switching between them according to the derived class.

Description

DETAILED DESCRIPTION OF THE INVENTION Object Oriented System with Shared Persistence Class Pattern Specification Field of the invention The present invention relates generally to object-oriented programming and object-oriented software systems, and in particular, to providing improved control over encapsulated data within system objects. Background of the Invention Object-oriented programming and systems differ from more traditional software systems in that they use multiple software objects as the basic logic building blocks of the system, rather than the more traditional programming data flows and algorithmic relationships. Form. Object-oriented systems have been written by Grady Book and published by Benjamin / Comming Publishing Company, Inc. ISBN 0-8035-0091-0. It is described and taught in a number of publicly available textbooks, such as published object-oriented modeling and design. As described in the above references, object-oriented programming generally organizes a program as a cooperative collection of objects, each of which represents an instance of a class, and these classes are connected by inheritance relationships. It is defined as an implementation method that can be a member of a class hierarchy. An object-oriented programming language may be generally described as a language that supports objects, which are abstract concepts having a specified interface of operations and hidden local states. The object has an associated type or class, and the type or class may inherit attributes from a supertype or superclass. Each object in an object-oriented system owns, ie, is defined by, an interface and an implementation. Basically, the interface relates to the appearance of the object, including an abstraction of the operation of the object. Conversely, the implementation represents abstractions in addition to the mechanisms within the object that achieve the desired behavior. Essentially, the interface represents a specification of the function of the object. An implementation is a collection of detailed information within an object necessary to perform its operation, effectively hidden from other objects and the rest of the system. According to the key operational feature elements of an object-oriented system, the implementation of the object is insulated from other objects or subsystems in the rest of the system, according to a principle commonly known as encapsulation or information hiding. Be concealed. This encapsulation principle is fundamental to object-oriented systems and makes it easy to reliably modify a program with little effort. The principle of encapsulation also prevents the data in the object from being contaminated during interaction with the rest of the system, since the data is not directly accessible. Essentially, an object is known to the rest of the system by the functions or operations it performs. For example, a representative object in an object-oriented system may be required to be provided with a count of certain activities (ie, operation as a counter). Giving this count is essentially the definition of the object to the system external to the object. As a result, providing the count comprises an abstraction of the operation of the object. The functional operations typically allowed on such objects may include a number reading (measurement) function, a number reset function, a number increase function, or a number decrease function. Objects in the system may perform some or all of the above functions. However, the implementation of the object, ie how the counts are represented in memory, how to limit the range, and the exact means of manipulating the counts are internal, and the principle of encapsulation , You cannot access other objects. As a result, in this example, objects in the system do not have access to the implementation of the counting object, i.e., the mechanism for performing the counting, and errors or contamination by loading to a new or different number may result. There is no danger. Objects in object-oriented systems are also defined by their three properties. These properties are behavior, state and identity. Behavior is how an object acts or reacts. Actions also describe the actions that the object can take in response to data in its internal state. Thus, the state of an object includes all of the attributes of the object and all of the current values of each of these attributes. The identity of the object is unique to the object and in its attributes distinguishes the object from all other objects of the same class or type. In practice, it corresponds to its assigned location in memory. In view of the logical building block arrangement of an object-oriented system, objects exist in an object-oriented system according to an architecture defined by a combination of classes and subclasses. In essence, a class is defined as the type of an object. In the example described above, the object providing the count is an instance of a class that can be described as a counter. If the system has other objects that are counters, these objects belong to the same class as the objects described above, but have different identities, although they may have different current counts. , All mean to act the same. Subclasses exist within the class of an object and inherit the attributes or features of the class from which they are derived. Thus, in a typical object-oriented system, there are objects that are of a class and / or subclass and conform to the inheritance hierarchy of the class and subclass relationships in the system. Analogously, in object-oriented systems, the relationships between objects in the hierarchy and classes and subclasses are, in these classifications, generally in a hierarchy described by common words with types and sub-type layers. Corresponding. Object-oriented systems offer practical advantages in programming and in the construction of complex systems, with emphasis on programming methods for complex systems, mainly from programming methods that focus on the appropriate and effective use of particular language mechanisms. Shift to design methods that emphasize proper and effective configurations. The design process in object-oriented design includes the process of correlating functionally defined objects in the system. In essence, object-oriented analysis and design emphasize the construction of "real-world models" that use an object-oriented view of the system. Encapsulation of the internal activity of each object simplifies the interacting operations of the objects in the system. In essence, objects at a higher level of the abstraction are protected from lower level implementation details. Objects can be thought of as a mechanism to achieve the desired behavior that simply relates each object to an external property or interface of another object. This encapsulation not only simplifies the design, but also allows each object to protect its internal state and its internal mechanisms, as well as the data that accomplishes its individual operation or implementation. Despite the crucial advantages provided by object-oriented systems, the need to preserve and maintain encapsulation within objects imposes significant limitations on system operation. For example, the preservation of encapsulation crucial to object-oriented design hinders the ability of the system to manipulate the internal state of all objects in the system that perform a function as a whole. Among these functions is the preservation or retention of internal state during periods of system shutdown. In addition, similar problems are encountered when the system requires the storage of multiple copies of the internal state of a set of objects. There may be a system requirement that the internal state of a set of objects must be switched to a command by a system operator. From the above, it is clear that objects usually encapsulate these internal states, so they have no direct access to other objects and cannot be stored externally. Such exposure of the internal state of the object violates the main principle of encapsulation and compromises the system. Thus, there remains a need in the art for an object-oriented system that retains its encapsulation and its benefits, while at the same time providing fully collective access to the object's internal state and promoting greater flexibility in system operation. is there. Summary of the Invention Accordingly, a general object of the present invention is to provide an improved object oriented system. It is a more specific object of the present invention to provide an improved object-oriented system that retains object internal state encapsulation while providing collective access to the internal state data of system objects. It is a more specific object of the present invention to provide an improved object-oriented system that provides data persistence and point state management, while at the same time facilitating operations such as simplified control and internal state switching. It is. The present invention operates on the limitations of the object-oriented system described above without violating the encapsulation and provides a shared persistence class pattern that provides persistence and the ability to manage the system state set through one interface. Overcome by. The class pattern specifies an object interaction consisting of an inheritance hierarchy. System objects can form instances of subclasses in the hierarchy, which can be used instead of their internal state. The base class (or superclass) establishes a common structure and abstraction common operations for each subclass, implements and hides the persistence plan, and provides an interface to control the state selection of the whole system. Each subclass collects all the data needed by the system object "owner" into one data segment, and for each of the data members in said segment, a public observer or "get" operation and a private modifier or "set". "Operation and give. The system object owner is given access to the private modifier of the subclass and thus has the ability to modify its data. All other system objects are forced to use the subclass data members only by their public read-only observer. According to the present invention, a plurality of classes each having an internal object defining a plurality of internal states and means for switching between them, a base class and a state selection class related to giving a state selection command to this base class, A derived class that is related to the base class through an inheritance hierarchy and that can be controlled by the base class in the inheritance hierarchy, wherein the base class determines an internal state of the internal object based on the entire system based on the state selection class. An object-oriented system is provided that operates to switch according to a shared persistent object-oriented class pattern. BRIEF DESCRIPTION OF THE FIGURES Features of the invention which are believed to be novel are set forth with particularity in the appended claims. The invention, together with other objects and their advantages, can best be understood by referring to the following description taken in conjunction with the accompanying drawings. In some of these figures, like reference numbers indicate like elements. FIG. 1 shows a generalized embodiment of the invention in Rambo notation. FIG. 2 shows a state switching application embodiment of the present invention. FIG. 3 shows a diagram in Rambo notation of the application embodiment of FIG. Description of the preferred embodiment FIG. 1 shows a general embodiment of the object-oriented system of the present invention in Rambo notation. Rambo Notation is described in textbooks written by Rambo and is a generally recognized standard notation system for graphically illustrating object-oriented software systems. In the general pattern of Rambo notation, consistent with FIG. 1, these elements indicate the class that forms the object, including the class name, a number of class attributes, and a number of operations performed by objects within the class. Includes a rectangle divided into three parts. The connecting lines between the class rectangles in Rambo notation indicate the relationships that exist between the connected classes. These notations indicate, except for any additional symbols, the relationship between the connected classes of the type specified by the text accompanying the line. In addition, it gives a number of symbols indicating the nature of the relationships between the connected classes. These symbols include a base class vs. derived class symbol consisting of triangles such as symbol 24, a rhombus symbol such as symbol 40 indicating the union of relationships, and a symbol 54 adjacent to the class rectangle and indicating a set or combination of classes. Including small diamonds. In addition, a circle symbol, such as symbol 64, adjacent to the class indicates a relationship having a multiplicity of zero or one. Multiplicity specifies how many instances of a class may be involved in one instance of the class concerned. Symbols such as symbol 66 indicate the multiplicity of one or more classes with respect to other classes connected by the associated line. With particular reference to the system of FIG. 1, the system according to the invention comprises a base class 10 having a class name 11, system data and a number of attributes 12, and an operation 13. Attribute 12 indicates internal state data of base class 10, and operation 13 indicates various functions that base class 10 can perform on data in the class object. In addition, the operation part 13 of the base class 10 exhibits some abstract functions such as state management {abstract}. Similar abstract operations are shown in operation portion 13 as display, copy state, and state change behavior, all including abstract indicia. The meaning of such an abstract notation in the operation part 13 of the base class 10 is to provide a pattern or template to a class derived from the base class. In view of the effects on other classes derived from the base class 10, such abstract notation imposes the requirement that each class derived from the base class must have these operations therein. That is, they must implement these operations through the interface specified by the base class. As will be appreciated below, the operations abstracted in the base class 10 for state management, display, replication state and state change behavior are all found in the operation part 20 in the derived class 20. In addition, base class symbol 24 is shown coupled between base class 10 and derived class 20. The meaning of the base class symbol 24 is to indicate an inheritance relationship between the base class 10 and the derived class 20. The derived class 20 includes a class name 21 indicating “state”, a set of attributes 22, and a set of operations 23. As described above, operation 23 of derived class 20 is abstracted in operation portion 13 of base class 10, consistent with the base / derived class relationship between classes 10 and 20. In addition, an association line 25 and an association line 26 are shown between the base class 10 and the derived class 20. These relationships indicate an operational relationship between the base class 10 and the derived class 20. In the example selected in FIG. 1, the associated line 25 indicates the relationship by which the base class 10 can control the overall system data state selection. The associated line 26 shows the relationship in which the system data class of the base class 10 functions to provide memory segment availability to the derived class 20 with the additional cooperation of the class 36. FIG. 1 also shows a class 30 having a class name 31 of the mode selector, a set 32 of attributes not listed, and a set 33 of operations. Association line 34 extends between class 30 and base class 10. Similarly, the class 35 includes a class name 36, an unlisted attribute set 37, and an operation set 38. The associated line 39 extends between the class 35 and the base class 10. The owner class 50 includes a class name 51, an attribute set 52, and an operation part 53. Owner class 50 is shown in relation to derived class 20 through association line 55, through combination symbol 40 and through collection symbol 54. The combination symbol 40 indicates a simple combination of relationships, and the collection symbol 54 indicates that the class 20 is included in the class 50 and the internal state of the class 20 can be changed by an operation in the class 50 by an application modifier of the class 20. The relationship between objects of class 50 and objects of derived class 20 is shown. Essentially, the associated line 55 is a read / write relationship between classes 20 and 50. Class 60 is, in the context of the present invention, a class type referred to as “non-owner”, and in the association indicated by symbol 64 with class 60 in association line 65, class 60 may include class 20. Although good, operations in class 60 can only read the internal state of class 20 by class 20 application observers. In essence, relationship line 65 is a read-only relationship between classes 20 and 60. The class 60 includes a name 61, a set of attributes 62, and a set of operations 63 shown in blank. In the generalized example according to the present invention shown in FIG. 1, the system provides an object-orientation useful in providing persistent non-volatile memory sharing between classes in an object-oriented class pattern that provides collective state switchability. Provide system. FIGS. 2 and 3 described below provide a more specific example of such a state switching application of the present invention. As should be appreciated, the purpose of the system of FIG. 1 is to protect data encapsulation, provide persistence and the possibility to manage a set of states through one interface. Thus, class 30 provides an object that manages the operation of the select key in the host system and selects between two available modes, indicated as modes 1 and 2. Thus, class 30 is indicated as a mode selector and includes operations to enter mode 1 or enter mode 2. According to the present invention, the selection of modes 1 and 2 corresponds to the selection of a set of selective states in various system objects. Thus, the line 34 indicating the relationship between the class 30 and the base class 10 is confirmed according to the state selection. The base class 10 called system data includes attributes related to the active state and sub-objects. In the operation 13, the class 10 includes operations related to the active state, the copy state, and the belonging segment. The function of the base class 10 is to abstract the operation of the derived class 20 and to hide the method and procedure for accessing the system shared memory through the class 30. Base class 10 functions with respect to providing data segments. Embody each subclass. Each subclass instantiation of the same general knowledge is bound to the same shared memory area. The base class performs the function of constructing the data segment. If necessary, the shared memory area is initialized with previously stored data. When data changes, the contents of the shared memory area are automatically saved. Since the data segment is bound, the pointer to the subclass is also registered in the state selection control. The selection of a particular state set is triggered by calling one base class member function. This function is repeated through all registered sub-objects, triggering the actions required to change the state set. A class 20, called a state, includes attributes 22, shown as segments having object types and states. The object 20 also includes in operation 23 operations corresponding to abstractions for state management, display, and state change behavior, all with their derived class relationships to the base class 10. The operation 23 further includes an operation of observing the internal state data and a so-called modifier that can change the internal state data. Therefore, the derived class 20 inherits all the operations of the base class 10. In addition, derived class 20 has access to the memory segments provided by base class 10 and implements all the abstracted operations in base class 10. In practice, the derived class 20 uses an operation (attachment segment) to gain access to the non-volatile shared memory of the system. Class 50 is described as an owner class having the name class, indicating that it is generally related to an owner class having an internal setting in attribute 52, which is an internal state within the class. As described above, the set symbol 54 indicates that the derived class 20 is included in the class 50 and can change or change the internal state of the class 20. The operation 53 of the class 50 may include a virtual operation, but is left blank indicating that nothing is required in the generalized example of FIG. Class 60 is described as a "non-owner" class with the name user and the attributes indicated as settings. As with the class 50, the operation 63 of the class 60 remains blank indicating that a virtual operation may be placed in the class 60. Important for the relationships to be understood in FIG. 1 is the use of the symbol 64 to relate the class 60 to the class 20 and to indicate any use or suppression of the class 20 within the class 60. The non-owner class 60 cannot change or change the internal data state of class 20, and is limited to reading or observing them. Thus, what is shown in FIG. 1 is a generalized diagram that uses the Rambo notation of the shared persistence class pattern object-oriented system, where the base class establishes a common structure and abstracts the common behavior for each subclass. And implement and hide the sustainability plan. The base class also provides an interface to control the state selection of the whole system. Each subclass gathers all the data needed by the system object owner into one data segment and provides both a public observer and a private modifier for each of the data members in the segment. Object owners are given private access to subclass elements. Private access is characterized by the ability to change the data in the subclass, so that members of the subclass can be used through its modifiers. All other system objects that use subclasses are restricted from using subclass data members only through read-only observers. As a result, the present invention provides operations by replacing the internal state of all system objects with other states, which would otherwise violate encapsulation. This additional object in all system objects is part of the inherited hierarchy that can be controlled by the base class. This allows the base class to control the internal state of the objects in the system on a system-wide basis while maintaining object encapsulation. System power and flexibility are dramatically expanded, with one instruction for the base class being the entire system without having to individually instruct each required object in the system to initiate a state switch or other state manipulation. Change state. The system also reads and addresses concurrently by giving each instance or event of the formed class access to the same data object. The write concurrency problem is managed by built-in mutual exclusion in the implementation. FIG. 2 shows an application embodiment of the object-oriented system of the present invention using a shared persistence class pattern in a typical application of state switching in a broadcast control panel. For illustrative purposes only, three functions are shown by operation in a system that includes audio gain adjustment, a video transition mixer, and a panel composer. However, it will be apparent to those skilled in the art that the system of the present invention described above is equally applicable to even more complex systems, and that the three objects are shown merely for illustration. More particularly, the state switching system generally referenced by the numeral 70 includes an audio controller object 75 having a gain control 76 coupled to a knob switch input 71. The regulator 76 includes a scaled gain output 72 coupled to the input 111 of the output interface 110. In accordance with an important aspect of the present invention, audio modulator object 75 includes internal objects that form gain state object 77. The gain state object 77 can switch the gain state input applied to the adjuster 76 by operating the switching function 80. The video transition mixer object 90 includes a fade control 95 coupled to a fade rate input 96, a take input 97, and an output black mix 98 coupled to an input 112 of the interface 110. Further in accordance with the present invention, video transition mixer object 90 includes an internal object comprising a rate state object 91 including a pair of states 92 and 93 selectable by state selector 94. A state selector 94 is coupled to the input of the fade control 95. Therefore, the rate state of the object 95 can be selected by the selector 94 between the rates 92 and 93. Panel composer object 100 includes a control 105 having an input 106 coupled to scaled gain output 72 and an output 107 coupled to input 113 of interface 110. Further in accordance with the present invention, panel composer object 100 includes an internal object 101 that forms a db state object having db states 102 and 103. The internal object 101 includes a selector 104 for selecting one of the db states to be applied to the control 105. Further in accordance with an important aspect of the present invention, each of the internal objects within objects 75, 90 and 100 is controlled by state manager class 120. The state manager class 120 includes a switch state input unit 124 and a response switch selector 121. Object 120 further includes a read / write function 122 coupled to input 125 and shared non-volatile memory 123. The non-volatile memory 123 is shared, and a data segment for each of the objects is provided in the shared memory 123. The switch function 121 makes a collective selection of the internal states within each of the objects 77, 91 and 101 to be used for controlling them. Therefore, it should be understood that selector 121 controls the selection function of selectors 80, 94 and 104 within internal objects 77, 91 and 101. In accordance with the present invention, state manager class 120 selects between gain states 78 and 79 of audio controller object 75 and rate states 92 and 93 of mixer object 90 in response to a state selection input via input 124. The selection and the selection between the db states 102 and 103 of the composer object 100 are performed simultaneously. Thus, the use of internal objects 77, 91 and 101 provides for state selection without violating the encapsulation of data in the system. To control each internal object in the system by the hierarchical system by the state manager class 120, one select input to the state manager class 120 simultaneously selects the gain, rate, and db state to use for the system through the output interface 110. You. This use of internal objects for the internal states of the audio controller object, video transition mixer object, and panel composer object is an important aspect of the present invention in maintaining the encapsulation of internal states for objects in the system. Each change used for states in internal objects 77, 91 and 110 is propagated by the state manager class 120 to their assigned segments in shared memory, thus providing system persistence in shared memory. FIG. 3 shows a diagram in Rambo notation of the system of FIG. It will be apparent that the system of FIG. 3 includes a base class 10, a mode selection class 30, and a memory class 35, substantially similar to classes 10, 30, and 35 found in FIG. Therefore, it should be understood that the base class 10, the mode selection class 30, and the memory class 35 are actually interrelated, as described above with respect to FIG. Note that, in addition to and in addition to the generalized system of FIG. 1, base class 10 is related to the remaining classes in the system through base / derived class symbols 24, as described in FIG. Should. Thus, it should be understood that the same overall control of the example system shown in FIG. 3 as provided in the generalized system in FIG. 1 continues in the system of FIG. In essence, the derived classes and the classes related to the base class 10 are described more specifically in FIG. 3 than in the generalized diagram of FIG. Thus, the system of FIG. 3 includes a gain state class 140, a rate state class 160, and a db state class 170, all of which relate to base class 10 as a derived class of base class 10. Thus, one will recall that hierarchies and inheritance relationships have been found in such base class to derived class relationships used for derived classes 140, 160 and 170. Therefore, the gain state class 140 includes a state name 141, a gain segment attribute 142, and an operation part 143. Similarly, rate state class 160 includes state name 161, attribute 162, and operation 163. Finally, the db state class 170 includes a state name 171, an attribute part 172, and an operation part 173. An audio controller class 144 having a class name 145, an attribute portion 146, and an operation portion 147 is related to the gain state class 140 through a set symbol 148. Thus, it should be understood that the audio controller class 144 can change the data state in the gain state class 140. The hardware driver class 149 includes a class name 150, an attribute part 151, and an operation part 152. The hardware driver class 149 is related to the audio controller class 144. In particular, a scaled gain information relationship is provided between classes 149 and 144. The video transition mixer class 164 includes a class name 165, an attribute part 166, and an operation part 167. Video transition mixer class 164 is related to rate state class 160 through set symbol 168. Therefore, note that video transition mixer class 164 can change the internal state of the data in class 160. Class 164 further pertains to hardware driver class 150. In particular, black mix information is communicated between them. The panel composer class 175 includes a class name 176, an attribute part 177, and an operation part 178. The panel composer class 175 is related to the db state class 170 through the collective symbol 179. Therefore, it should be noted that the panel composer class 175 can change the internal state of the data in the db state class 170. Class 175 is further related to class 149 and, in particular, exchanges information on scaled gain and db display information. The panel input class 153 includes a panel name 154, an attribute part 155, and an operation part 156. Panel input class 153 is related to class 144 for the exchange of knob delta information. Class 153 further relates to class 164 for exchanging process take information and class 30 for exchanging process bypass information. The operation of the system shown in FIG. 3 involves the possibility of selecting the gain state, rate state and db state of the audio controller class 144, video transition mixer 164 and panel composer class 175 by operating one mode selection class 30. give. This possibility is provided by providing the gain state class 140 in the audio controller class 144, the rate state class 160 in the video transition mixer 164, and the db state class 170 in the panel composer class 175 in accordance with an important aspect of the present invention. Given by giving to. Each of the classes 140, 160 and 170 is associated with a respective one of the classes 144, 164 and 175 through the set, as indicated by the symbols 148, 168 and 179. This set represents a relationship between the classes that can change the internal state of classes 140, 160, and 170, comprising the internal state of classes 144, 164, and 175. With reference to FIG. 2, it will be recalled that the internal objects for the gain state, rate state and db state have been provided in the audio controller object, the video transition mixer object and the panel composer object. Thus, in accordance with an important aspect of the present invention, selection between the internal states of classes 140, 160 and 170 is facilitated depending on their relationship to base class 10. In this way, the encapsulation of the internal state for classes 144, 164 and 175 is preserved, while the internal state data is available to and controlled by base class 10. This hierarchy of class patterns facilitates the control of multiple state selections of the present invention through a single interface and maintains the encapsulation of data within system objects. Shown is a shared persistent object-oriented class pattern that maintains encapsulation of object internal state and provides state switching and persistence by a single interface controller. The system can be used for a variety of applications where one wants to switch between multiple sets of internal states in response to one panel command or the like.

Claims (1)

[Claims] 1. Internal object that defines multiple internal states and the means to switch between them A plurality of classes each having     The base class and give the base class a state selection command. The state selection class involved,     Related to the base class through an inheritance hierarchy, and With a derived class that can be controlled by the source class,     The base class is, depending on the state selection class, the internal object The internal state of a shared persistent object-oriented class An object-oriented data processing system that operates to switch according to turns M 2. 2. The object-oriented system according to claim 1, wherein the state selection Lass responds to the state selection input by a data segment for each of the internal objects. Includes a state manager object that contains shared non-volatile memory for storing comments , Object oriented system. 3. 3. The object-oriented system according to claim 2, wherein the plurality of   Is     Audio regulator class,     Video transition classes,     An object-oriented system including a panel composer class. 4. 4. The object-oriented system according to claim 3, wherein the audio A regulator class internal object includes a plurality of audio gain states, The transition class internal object contains multiple rate states and the panel Object inside the composer class contains multiple display scaled gain states , Object oriented system. 5. 2. The object-oriented system according to claim 1, wherein the plurality of Is     Audio regulator class,     Video transition classes,     An object-oriented system including a panel composer class. 6. 6. The object-oriented system according to claim 5, wherein the audio A regulator class internal object includes a plurality of audio gain states, The transition class internal object contains multiple rate states and the panel Object inside the composer class contains multiple display scaled gain states , Object oriented system. 7. 7. The object-oriented system according to claim 6, wherein the state selection Lass responds to the state selection input by a data segment for each of the internal objects. Includes a state manager object that contains shared non-volatile memory for storing comments , Object oriented system. 8. Each having an encapsulated selective internal state, said selective internal state A plurality of system objects, each containing means for switching without violating the encapsulation In an object-oriented system having objects, System     In the plurality of system objects each defining the selective internal state Multiple internal objects,     Each of the internal objects is related by an inheritance hierarchy, and And controls the selection of internal objects within said system object. An object-oriented system with a lath object. 9. 9. The object-oriented system according to claim 8, wherein a user input is received. The base class object in response to one user input. System manager, which controls to give the entire system state change of the project An object-oriented system, including objects. 10. 10. The object-oriented system according to claim 9, wherein the plurality of systems The stem object is     An audio controller object,     A video transition object,     An object oriented system including a panel composer object. 11. 11. The object-oriented system according to claim 10, wherein the audio A video controller object comprising a plurality of audio gain states, The condition object includes a plurality of rate states and the panel composer object Object-oriented system in which the object includes multiple display scaled gain states . 12. Maintain data encapsulation while maintaining persistence and state sets in a common interface. In an object-oriented system that provides the ability to manage The object-oriented system     Encapsulates a set of selective internal states of a system object and A system object that contains each or any of the internal objects that are parts A derived class forming a subclass of the base class having     Establish common structure, abstract common behavior for each of the derived classes, A base class that controls the inheritance hierarchy,     A mode selection for selecting the selective internal state using the internal object; An object-oriented system with alternative classes.