WO2016099317A1 - Способ и система визуального управления данными - Google Patents

Способ и система визуального управления данными Download PDF

Info

Publication number
WO2016099317A1
WO2016099317A1 PCT/RU2014/000958 RU2014000958W WO2016099317A1 WO 2016099317 A1 WO2016099317 A1 WO 2016099317A1 RU 2014000958 W RU2014000958 W RU 2014000958W WO 2016099317 A1 WO2016099317 A1 WO 2016099317A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
visual
interface
instances
instance
Prior art date
Application number
PCT/RU2014/000958
Other languages
English (en)
French (fr)
Inventor
Сергей Анатольевич ГОРИШНИЙ
Анатолий Александрович КОНДРИК
Original Assignee
Сергей Анатольевич ГОРИШНИЙ
Анатолий Александрович КОНДРИК
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Сергей Анатольевич ГОРИШНИЙ, Анатолий Александрович КОНДРИК filed Critical Сергей Анатольевич ГОРИШНИЙ
Priority to US15/536,757 priority Critical patent/US20170352174A1/en
Priority to PCT/RU2014/000958 priority patent/WO2016099317A1/ru
Publication of WO2016099317A1 publication Critical patent/WO2016099317A1/ru

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T11/00—2D [Two Dimensional] image generation
    • G06T11/60—Editing figures and text; Combining figures or text
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/904—Browsing; Visualisation therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range

Definitions

  • the invention relates to the field of human interaction with a computer, system and methods for visualizing information and visual data management. More specifically, the invention relates to user interfaces in general, as well as to the structure, internal organization, methods of creating user interfaces and methods of interaction of a user interface with data in particular.
  • information data is carried out through a visual interface, using a graphical information display device, and data management and input tools, such as a mouse and a computer keyboard.
  • data management and input tools such as a mouse and a computer keyboard.
  • the source of the actual informational data is the data management system.
  • the data management system and user interface to this system are traditionally isolated from each other for many reasons.
  • various software tools and technological methods were used, and moreover, these components can be (and usually) implemented by different manufacturers.
  • data and interface are spatially separated, and are implemented on different computers connected to the network.
  • the present invention overcomes the limitations of the prior art, and makes it possible to create interfaces of arbitrary complexity in a high-performance way of direct visual design without resorting to writing program codes and their subsequent compilation.
  • the subject of the invention is the creation of a universal way to implement visual and non-visual user interfaces, which are an integral part of a data management system.
  • a method for uniformly associating a user interface with data is disclosed, as well as a method for visually constructing interfaces based on this association by navigationally combining instances of natural forms of representing subjects of metadata of a data management system.
  • the second aspect of the present invention describes a visual data management system formed by a combination of instances of the data component on the data side and instances of visual components on the interface side, in which the interaction of all subjects, including metadata subjects, is strictly unified and is based on a declarative basis.
  • the present invention discloses the advantages of creating a graphical interface based on the smallest possible set of elementary graphical components, and contains a description of their nomenclature and functional composition.
  • the visual graphical interface is formed in a software manner, is multi-windowed (multi-document), and is implemented by a set of instances derived from unified visual components combined into a system library.
  • one part of the instances performs the functions of a passive visual design, the other part is interactively connected with the information values of the system
  • the information values of the data management system may also not be visual.
  • any subject area is described by a finite set of conceptual entities, and all the information values (data) of the subject area are instances derived from these entities and their characteristics.
  • Conceptual entities Data Classes
  • characteristics of conceptual entities Class Attributes
  • Application Model a Domain Data Model
  • the Classes and Attributes that make up the Application Model are user instances derived from system entities of a higher level of abstraction — the meta-Class and meta-Attributes, respectively, which are the subjects of the Meta-model of the data management system.
  • the level of the Meta-model of the system itself there are three levels: 1) the level of the Meta-model of the system itself; 2) application metadata level; and 3) the level of the final information values. It is important to note that all of the listed subjects of the first two levels, in the most general case, represent some declarative description that exists in a machine-readable form suitable for long-term storage.
  • the data management system uses declarative entities to create derived instances of the underlying level on their basis, and does this in a unified manner, using built-in methods.
  • Representations of metadata subjects used in various combinations determined by the needs of interaction should be formed by visual Representations of metadata subjects used in various combinations determined by the needs of interaction, including in combination with visual components of interface decoration.
  • the Representations mentioned are instances derived from system entities of a higher level of abstraction, such as various meta representations of the basic subjects of the meta-Model of the data management system - meta-Class and meta-Attribute.
  • meta-representations of the underlying entities are instances of an even more general abstract meta-representation, which defines the basic set of entities and characteristics that provide a unified relationship between metadata subjects and the interface component, and is the owner of the basic methods for implementing this relationship. It is important to note that meta-views, and
  • the copies derived from them belong to the first and second mentioned levels of abstraction, and represent some declarative description that exists in a machine-readable form suitable for long-term storage.
  • the data management system uses the predefined meta-representations of the basic entities to create derived instances of the next level (specific representations in the created interface) on their basis, and does this in a unified manner that does not require additional coding.
  • a separate conceptual entity of a domain can be considered from a variety of interface points of view, each of which includes one or another combination of characteristics of an entity that together form a specific interface set .
  • the user Class as a declarative subject of metadata, can have an arbitrary set of its own independent Views.
  • a separate independent Class Representation hereinafter referred to as the Class Form, will be formed by an instance of the meta-Representation of the meta-Class, and include a set of Representation Attributes and Events of the class. In this way,
  • multi-window visual interface of the application can be formed including a combination of various independent Form classes describing the subject application area
  • the independent Class Form can be used as an interface both with respect to the only instance of the Class — a data object derived from the Class, and to the set of such instance objects, in the form of their sequential enumeration.
  • the Form of the class object (unitary) and
  • the Meta-Set has systematic methods for controlling an arbitrary abstract set, including but not limited to the method of obtaining the set, navigation in the set, providing the set in the form of a selective enumeration of its members, and others.
  • the set can be represented including a list, the elements of which are key-value pairs.
  • a Class Form includes a collection of Class Attributes and Events.
  • the Event is not an instance of the Meta-model level, but is a virtual subject of metadata that permanently exists for each Data Class, and
  • the Class Event view can be associated with the Form of the class on which this Event is implemented (for example, creating a data object with assigning values to its attribute attributes).
  • the only characteristic of a Class Attribute that uniquely defines its interface aspect is the functional type of the Attribute, which sets the type of information value derived from the Attribute and belongs to one of two groups.
  • the first group consists of natural material types, such as Numeric, String, Logical, Date, Image, etc, which have their own natural form
  • the second group is formed by the so-called reference (user) types, and this group includes all the attributes that implement the relations (quantitative interaction) of the Classes.
  • the value of the reference attribute is a pointer to a data object, typed, like the attribute itself, by the identifier of the target Relationship Class (recall that each Data Class is actually a uniquely identifiable user type).
  • the Meta-model level there are several specialized meta-Views for the entire group of reference attributes, each of which corresponds to one of the following interface aspects:
  • An abstract meta-representation includes two components: the definition of an abstract service entity, hereinafter referred to as the Data component, as well as the definition of an interface tuple — a collection of abstract unified instances of Interface components.
  • the abstract data component provides a unified association with
  • An abstract Interface component as a separate element of an interface tuple, provides a unified connection of a specific instance of a system interface component with an instance of a Data component, and for this purpose includes at least the following characteristics, the values of which are specified in its derivatives: 1) identifier of the target instance of the data component; 2) type identifier of the system interface component; 3) the identifier of the derived instance of the system interface component.
  • Each private meta-representation of a particular subject of metadata is an instance derived from an abstract meta-representation in which
  • each interface component of the tuple is the identifier of the system interface component.
  • the meta-representation of the subject of metadata may include more than one interface component.
  • the interface components, exchanging mutual pointers, use the characteristics of the parent-child, and in this case one of the components becomes the root, that is, plays the role of a common "parent".
  • the application interface is formed by instances of the Data component and instances of the Interface components, derived from meta-representations of entities involved in the formation of this interface.
  • information values displayed by the interface will be consistent and logically related. For example, information values (instances of Attributes) must belong to the same object (an instance of the Class). That is, with respect to the Class, in the interface you can place only your own Attributes or Events of this Class, but at the same time the reference attribute belonging to the Class is then considered as another Class, with respect to which its Attributes and Events can be placed.
  • the starting point of the process of creating an instance of a Meta-View is an external impact - an event of a user who wants to include another element in the interface.
  • the recipient of this impact will be a valid instance of the interface component that will request an instance of the Recipient-Data identified by it, and that, in turn, will request the source metadata subject associated with it to obtain a list of entities (Attributes or Events) that can be placed in this location of the interface relative to the original subject. If the specified list is not empty, then it is offered to the user who makes his choice in a visually convenient form of a list of named elements.
  • the user is offered an additional a selection dialog, otherwise the only possible option is used by default. Moreover, if the selected meta-Representation is associated with a User Event requiring the opening of a new Class Form, an additional dialog will be offered for selecting the Class Form.
  • the constructor creates instance declarations derived from the Data and Interface components of its meta-View, assigning them unique identifiers of their own, as well as identifiers of the corresponding source components as a pointer to the parent component.
  • an instance of the Data Component gets
  • the created instances fix a chain of reciprocal pointers: Interface component—> Data component—> ⁇ metadata subject, and are integrated into parent-child relationship systems that combine the declarations of the Data component and
  • Interface components into two conditionally independent data structures: Data resource and Interface resource. It should be noted that if at the level of the Meta-model of data the declaration of the meta-Representation acted
  • the starting point for the process of creating the interface discussed above is the open Form of the class, which, as an instance of the Meta-View of the Meta-Class, includes instances of the Data and Interface components, which are de facto root in the parent-child relationship system that forms the contents of the Data- and Interface resources of the Class Form.
  • a class form is automatically created, when the name of a new Form is abstractly created in a unified system dialog for selecting a form.
  • the dialog is called when the Class Form is assigned to the created (or existing) Class Event View, for which the interface type of the Form (visual, printed, ...) is already predefined at the meta-View level of the Event. That is, when a uniform form selection dialog is called, the required interface type is indicated to it, and accordingly, the dialog displays only Forms of the specified type, and if the Form is created, it automatically receives the specified type.
  • the data management system uses derived objects of the Forms utility data class, whose existence is hidden from the user. Moreover, as
  • the unique identifier of the Form uses the identifier of the object that stores the declaration of the Form.
  • Attributes are predefined in the Forms class, in instances of which all significant characteristics of the Form declaration are placed in the data objects of the Forms class, such as: Class identifier; class interface type identifier; custom name of the Form; structured set of declarations Date-component (Date-resource); structured collection of interface component declaration (interface resource).
  • a new Forms class object is created when you create a new Class Form in
  • the structured sets of declarations of the Data- and Interface components are automatically serialized and stored in the data object both when creating a new View on the Form, and when closing the Form after its modification.
  • the window identifier remains on the data side, and the Interface resource, also marked with the window identifier, is transferred to the interface side, after which between them begins the exchange of data, organized according to the following rules.
  • the components of the Data resource sequentially, starting from the root Data component, use the stored identifiers of the metadata subjects to access the Data Model in order to extract instances (data objects and information values) derived from the addressed entities from the data management system.
  • the extraction process is navigational in nature, since the subject-instance pair,
  • each value placed in the Selection is marked with a unique identifier for the Data component that extracted this value, and each enumeration element
  • the data sample thus formed is serialized, marked with the window identifier of the interface, and transmitted to the user interface side.
  • the window identifier in the Data Sample is used to address and initiate a specific Interface resource. Initiated in this way, the components of the Interface resource sequentially, starting from the root Interface component, begin the formation of the contents of the interface window of the corresponding interface type, and use stored
  • identifiers A data component for retrieving information values displayed by the interface from a Data Sample.
  • user interface components (completed data entry or event triggering) is processed as follows. User initiated
  • the interface component creates a data structure called the Interface event, marks the structure with the interface window identifier and the stored identifier of the Data component, supplements the structure with the information value entered by the user (if any), and transfers the interface event thus formed to the data side.
  • the received Interface Event is dispatched to the target component of the Data Resource.
  • the Data component initiated in this way uses, as applied to its stored declarations, the method of processing the event inherited from the meta-Representation, including including the transmission of the information value to the associated metadata subject. If necessary, after completion processing a user event, the Data component initiates the entire Data resource to form a new Data Sample to the interface address.
  • the declaration of a separate Data Class (instance of a meta-Class), including the declarations of class Attributes (instances of a meta-Attribute), can also be a data object that is derived from some utility class - a Super-class.
  • buttons or menu items which initiate the opening of all subsequent windows.
  • the role of such a window can be played by the Form of the aforementioned Super-class, relative to which Class representations are placed, having the interactive form of a button (or buttons grouped in a menu) to which the required Forms are assigned by a unified dialog.
  • Another aspect of the present invention is a progressive method of organizing a system library of visual components. This aspect is closely related to the foregoing, since the interface components of any visual
  • Representations are instances of the components of the system library in the declarative form of their expression, including including the determination of the values of their particular visual characteristics.
  • the system library of visual components forms the basis of any system for developing and implementing graphic visual interfaces.
  • the obvious advantage of such a library is the mutual consistency of properties, display methods and methods of behavior of all its components.
  • a significant drawback of the libraries proposed for use is their extensive component composition.
  • Libraries contain a large number of components, including functionally complex ones, in order to satisfy all conceivable interface needs of an application. Meanwhile, in practice, such needs are always and constantly met that one way or another, but go beyond the capabilities of both single library components and their combinations. These needs have to be met by changing the program code of the standard library components, which gives rise to new versions of the library with a potential conflict of versions, and is also very costly and unsafe, since in this case the library itself must be presented in an open form, suitable for making changes.
  • a relatively simple and massively used interface component such as a visual Button.
  • the button includes, among other things, a visual image (Icon) and an inscription (Text).
  • buttons All visual characteristics of the button, including its shape, color, frame, as well as the display, position and composition of the Icon and Text, are defined and controlled in a standard way. But in order to add an additional design element to the button, you will have to create another component of the library by inheriting from the Button, and make changes to its program code.
  • Administering the properties of visual components is also a difficult task due to their multiplicity and diversity.
  • the abundance of component types and their properties forces us to use the universal Property Inspector, which displays all properties in the form of a linear enumeration, as the main tool for visual administration.
  • the complexity of their administration by the Inspector obviously increases progressively. If for a simple Text component that displays a simple label, you can count about ten properties requiring administration, then for the relatively simple Button component (which also includes Text), there are more than forty such properties.
  • Another difficulty in using existing visualization systems is that they were originally developed in isolation from data management systems.
  • Each of the listed elementary graphic entities-Primitives has at least one unique property, in relation to which it uses its own original way of creating a graphic image, as well as a method for implementing interactive interaction with the user.
  • the unique property and the method of its formation by the user are hereinafter referred to as the basic property and the basic method of the Primitive.
  • the minimal component composition of the library allows each Primitive to have a separate fixed visual dialogue for managing its properties.
  • the dialog contains few visual control organs.
  • This dialogue is organized taking into account the requirements of visibility and ergonomics in such a way as to provide the most visual perception with minimal user actions in the process of managing individual properties. And to further facilitate access to the dialogue, it should be made "pop-up" near the Primitive selected for management.
  • the use of a dialogue based on such principles significantly increases the productivity of the process of visual administration of the user interface, and eliminates the more time-consuming use of the universal property inspector, or the now popular dashboards.
  • the visual components of the interface are actually derived from the metadata entities, and automatically, without writing program codes, receive declarative association with the data when they are created as part of a new instance of the submission of the metadata subject.
  • This association is expressed in the fact that the interface component owns the identifier of the Data component on the data side, which allows it both to receive data from the Selection for display and to respond to user actions by broadcasting its Data component.
  • the same association mechanism can be fully used for unified association with data of all particular properties of any visual Primitive, and also does not require writing
  • each property of the Primitive from the system library, which could potentially be dependent on data, in its structure has a place to place the identifier of the Data component. Accordingly, in control bodies, the value of such a property also includes a method of calling
  • the specified dialog initiates the creation of the Data component on the data side, its inclusion in the Data resource, and returns the identifier obtained when the Data component was created, for its subsequent storage in the Primitive property.
  • Boolean value uses either the primary or alternative value.
  • the declaration of an alternative property has a complex structural composition, and in addition to the main value includes an alternative value, as well as the identifier of the Data component. If an alternative value is specified, then it becomes possible (and mandatory) to associate with the metadata subject
  • the two-dimensional graphical interface is primarily characterized by the rectangular geometry of all instances of the graphic components that display it. Even if there is a visual rounding on the screen (Oval button, as an example), then this is just a way of drawing a component in which part of the original i rectangle is not covered by the image. Therefore, all components
  • a system library can be generated from a common ancestor, who uses four coordinates to describe geometry — two for each ordinate axis.
  • the coordinate declaration has a complex structure, and each of the four coordinates can be considered as an instance of the declarative definition
  • the Text primitive is used to display arbitrary text in the form
  • the basic property of the Text primitive operates with an information value representing a sequence of character codes in any possible encoding common to the entire set, and the basic method is a traditional visual text editor.
  • the displayed text is characterized by the static properties Font, Size (Font size), the number of Lines, Line spacing, Align, Shadow, Outline font, and also
  • the basic property of Text can be either static (the primitive is used as an element of decorating the interface) or dynamic.
  • the displayed text is characterized by the Editable property, and can be either plain text or contain HTML markup tags.
  • the primitive Image is used to display an arbitrary image.
  • the basic property of the Image primitive operates with an information value representing a raster or vector image in any computer format used for storing images, with or without compression.
  • the basic property of the Image primitive can be static (the primitive is used as an element of decorating the interface), alternative or dynamic. In the latter case, the image is characterized by the static property Editable, permanently allowing or prohibiting the use of the basic method for changing the image.
  • the image is characterized by the static properties Transparency and Scalability, which allows / blocks the resizing of the original size.
  • the basic method is a visual dialog for selecting an image source, which can be either a file or a device (for example, a camera).
  • the Canvas primitive is used to display a rectangular area consisting of two main parts: the Background area and the Border area.
  • the Background area includes the Header area and the Enum area.
  • the Background area exists and is displayed permanently, and the use and display of the Framing, Header, and Listing areas is optionally set in the corresponding management properties of the same name.
  • the basic Canvas property is not visual, but interactive, and consists in the ability to perceive the direct impact of the user on the Canvas visual area. Accordingly, for these purposes
  • the Canvas primitive is characterized by static Transparency and dynamic Visibility.
  • Transparency is defined as the degree of transparency of the final canvas display. Canvas visibility allows you to situationally control the displayed component composition of the interface from the application side.
  • the Background area is characterized by an alternative color fill (Filling), uniform, or with a gradient.
  • a more complex background pattern can be implemented by overlaying the Image primitive.
  • the Framing Area on four sides visually limits the Background area, and can be one of two types: graphic or linear.
  • graphic or linear A predefined, and expandable as needed, a set of graphic Framing allows
  • Linear Framing is displayed as a continuous or broken line with optional thickness and color. Unlike graphic, linear Framing allows you to separately control the display of each individual side, and can be used to display both single lines and tabular structures. All Framing properties are static, with the exception of the color scheme of linear Framing, which is an alternative. Setting the line thickness to zero for linear Framing is equivalent to excluding Framing from the display.
  • the Heading area is not characterized by its own visual properties, and is intended for placement on its surface of child primitives forming the headings of Tables and Forms. If there are no child primitives, the Header area is excluded from the display.
  • the Enumeration area is intended for placement on its surface of child primitives forming the rows of the Tables, as well as Charts and Diagrams, and
  • the Enumeration display is controlled by an array of records in which each record contains a complete set
  • the display itself is formed by the Enumeration line by line, in the direction of the enumeration Vector specified, for each entry in the control array, the Enumeration initiates the display of child primitives in the remaining free space of the region, providing them with the contents of the record for selecting information values. Accordingly, child primitives group on the surface of the region
  • the Enumeration Manager array of records is a conditional "selection window" from the associated set.
  • the fixed size of the array in the records is calculated automatically based on the ratio of the sizes of the Enumeration area and the enumeration line in the direction of the Vector so that the area space is completely filled.
  • Enumeration provides its own interactivity.
  • the List has its own interactive behavior, the need for association with a multitude, and the convenience of creating a primitive, as Representations of the plural aspect of the metadata subject, make it possible to extract it from Canvas
  • the Canvas primitive is allowed to place child primitives on its surface, with automatic parent-child communication, which is the basis for the implementation of a potentially infinite combination of primitives.
  • the child primitives come into coordinate interaction with the parent Canvas, and such general Canvas properties as Transparency and Visibility apply to them.
  • this rule manifests itself in such a way that the part of the display of the child primitive that goes beyond the parent Canvas is forcibly cut off.
  • Canvas has the static properties Expandability and Scroll, which act separately for each X and Y axis, and are optionally controlled by setting flags of the same name. If the ordinate is turned on for the selected axis
  • the child primitives can change the size of the Canvas (in the direction of increase) by an amount sufficient to fully display them, while this change can be limited by the static sizes of the older parent Canvas.
  • Scrolling is enabled for the selected ordinate axis, then the size of the Canvas surface for this axis is considered to be conditionally infinite, and the active Background region with fixed coordinates acts as a "window" to this surface.
  • Canvas automatically includes a visual control for positioning the window adjacent to one of the coaxial sides of the Background area, and is known as the Scroll bar.
  • the Extensibility and Scroll properties for the common ordinate axis are mutually exclusive.
  • the Scroll property coaxial with the Enumeration Vector
  • any of the coordinates of any primitive can be associated with an external source of value - an attribute of the class that controls information values of a numerical type, including values of the data-time type.
  • the indicated association of the coordinate with the Attribute allows you to build Graphs, Charts, as well as visually link the display of the primitive to a specific point on the map or diagram.
  • a necessary condition for creating an association of the coordinate of a primitive with an Attribute is the availability of a method for converting a numerical information value into a display coordinate and vice versa.
  • Such a method for its child primitives is provided by the Canvas primitive in the form of one of its own updated properties - Scale or Map.
  • Each of these properties when updated, will contain a pointer to the same auxiliary non-visual component that owns the corresponding image, as well as some numerical values corresponding to the boundaries of this image along the ordinates.
  • the presence of the specified boundary values allows the child primitive, using a simple proportion, to convert the numerical value of the coordinate to the coordinate value of the display relative to the parent Canvas, then used by the primitive to form its final display on the Canvas surface.
  • the Scale property uses the contents of the associated component as a visual decoration and calculation base for the implementation of Charts and Diagrams. In this case, the actual display is carried out by the child primitives Text and Image, using the Enumeration property, if necessary.
  • the Scale property is used by the Canvas primitive in relation to the Framing area, and
  • the Scale property can be set simultaneously for only two mutually orthogonal sides of the Canvas Framing area.
  • the Map property is used by the Canvas primitive in relation to the Background area.
  • the auxiliary components Scale and Map can be grouped into homogeneous collections. The purpose of such a union is to use the collection to dynamically scale the resulting display of a Graph or Chart.
  • the Scale and Map components themselves can be data objects derived from the utility class of the data management system, and the Scale and Map properties of the Canvas primitive can have a unified association with this form of storage of components.
  • an Enumeration's own property such as an Enumeration Vector
  • an Enumeration Vector indicates the direction of placement of derived mappings of child components, and, in the vast majority of cases, by default, this Vector is directed downward.
  • the Transfer Vector can have any orientation, and moreover, to establish not only linear, but also radial-angular character of formation of the final display. The latter circumstance allows us to use the Enumeration not only to create linear columnar, but also pie charts.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Data Mining & Analysis (AREA)
  • Stored Programmes (AREA)

Abstract

Изобретение описывает систему визуального управления данными, включающую в себя универсальный способ конструирования пользовательских интерфейсов путем навигационного комбинирования экземпляров естественных форм представления субъектов метаданных с использованием ограниченного набора графических примитивов. Техническим результатом изобретения является существенное повышение скорости создания пользовательских интерфейсов прикладных программ за счет использования методов декларативного программирования.

Description

СПОСОБ И СИСТЕМА ВИЗУАЛЬНОГО УПРАВЛЕНИЯ ДАННЫМИ
ОБЛАСТЬ ТЕХНИКИ
Изобретение относится к к области взаимодействия человека с компьютером, системе и способам визуализации информации и визуального управления данными. Более конкретно, изобретение относится к интерфейсам пользователя вообще, а также к структуре, внутренней организации, способам создания интерфейсов пользователя и способам взаимодействия интерфейса пользователя с данными в частности.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
В компьютерной системе, интерактивное взаимодействие пользователя с
информационными данными осуществляется через визуальный интерфейс, с использованием устройства отображения графической информации, и средств управления и ввода данных, таких как манипулятор мышь и клавиатура компьютера. Источником же собственно информационных данных при этом является система управления данными.
Для больших и сложных прикладных задач создание и модернизация функционально сложных пользовательских интерфейсов к данным становится существенной проблемой, требующей больших трудовых и финансовых затрат для ее решения.
Являясь составными частями общего приложения, система управления данными, и пользовательский интерфейс к этой системе, по многим основаниям традиционно изолированы друг от друга. Как правило, при их создании были использованы различные программные средства и технологические приемы, и более того, эти составные части могут быть (и как правило) реализованы разными производителями. К тому же, в традиционной архитектуре сервер-клиент, данные и интерфейс разделены пространственно, и реализуются на разных компьютерах, связанных в сеть.
Взаимная изоляция приводит к тому, что взаимодействие интерфейса с данными осуществляется через различные промежуточные программные слои и модули, с использованием широкого спектра различных протоколов обмена. Связанное с этим написание (и отладка) большого объема программных кодов существенно замедляет создание приложений, и делает интерфейсную часть все более дорогостоящей. Кроме того, эксплуатационным изменениям чаще всего подвержен именно интерфейс пользователя, а любое, даже самое мелкое изменение интерфейса влечет за собой выпуск новой версии приложения. Также свой вклад в увеличение трудоемкости процесса разработки интерфейсов вносит использование обширных системных библиотек визуальных компонент, обладающих неудобными универсальными
средствами администрирования частных свойств компонент.
Необходимость сокращения затрат и времени на разработку интерфейсного
программного обеспечения и привели к созданию настоящего изобретения.
РАСКРЫТИЕ ИЗОБРЕТЕНИЯ
Настоящее изобретение преодолевает ограничения предшествующего уровня техники, и делает возможным создание интерфейсов произвольной сложности высоко- производительным способом прямого визуального конструирования, не прибегая при этом к написанию программных кодов, и последующей их компиляции. Предметом изобретения является создание универсального способа реализации визуальных и не визуальных пользовательских интерфейсов, которые являются неотъемлемой частью системы управления данными.
В первом аспекте настоящего изобретения раскрывается способ унифицированной ассоциации интерфейса пользователя с данными, а также основанный на этой ассоциации способ визуального конструирования интерфейсов путем навигационного комбинирования экземпляров естественных форм представления субъектов метаданных системы управления данными.
Второй аспект настоящего изобретения описывает систему визуального управления данными, образованную комбинацией экземпляров дата-компонент на стороне данных и экземпляров визуальных компонент на стороне интерфейса, в которой взаимодействие всех субъектов, включая субъекты метаданных, строго унифицировано и строится на декларативной основе.
Помимо этого, настоящее изобретение раскрывает преимущества создания графического интерфейса на основе минимально возможного набора элементарных графических компонент, и содержит описание их номенклатуры и функционального состава.
Важной особенностью всех аспектов настоящего изобретения является декларативный характер их реализации, который позволяет создавать прикладные интерфейсы не прибегая к написанию программных кодов в любой их форме, и тем самым делает эти интерфейсы полностью кросс-платформенными. При этом стоит упомянуть, что настоящее изобретение имеет практическую программную реализацию и использование в платформе быстрой разработки приложений Visual Data.
Перечисленные и другие особенности и преимущества настоящего изобретения будут очевидны из следующего описания и формулы изобретения.
ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
Из предшествующего уровня известно, что в самом общем случае визуальный графический интерфейс формируется программным образом, является многооконным (много-документным), и реализуется совокупностью экземпляров, производных от унифицированных визуальных компонент, объединенных в системную библиотеку. При этом одна часть экземпляров вьшолняет функции пассивного визуального оформления, другая часть интерактивно связана с информационными значениями системы
управления данными. В еще более общем случае, внешний интерфейс к
информационным значениям системы управления данными может также быть и не визуальным. Например интерфейс отчетов, используемый для отображения
информационных значений в печатный документ, или файловый интерфейс, используемый для вывода данных в файл, или импорт данных из файла. Но и в этих случаях интерфейс требуемого типа может быть реализован по такому же принципу. Настоящее описание далее рассматривает визуальный интерактивный графический интерфейс (как наиболее сложный тип интерфейса), но все сказанное в полной мере применимо и к не визуальным интерфейсам, также входящим в предмет настоящего изобретения.
Из предшествующего уровня также известно, что в самом общем случае реализуемая компьютером система управления данными манипулирует машиночитаемыми информационными значениями, принадлежащими некоторой целевой предметной области автоматизации.
Рассмотрим место и роль субъектов системы управления, описывающих данные.
На понятийном уровне абстракции любая предметная область описывается конечной совокупностью понятийных сущностей, и все информационные значения (данные) предметной области являются экземплярами, производными от этих сущностей и их характеристик. Понятийные сущности (Классы данных), и характеристики понятийных сущностей (Атрибуты классов), являются субъектами метаданных, и совокупно образуют Модель данных предметной области, далее именуемую Модель приложения. Важно подчеркнуть, что в системе управления данными извлечение и модификация данных, включая их создание и удаление, осуществляются только через обращение к соответствующим субъектам метаданных методами этих субъектов.
Классы и Атрибуты, образующие Модель приложения, в свою очередь являются пользовательскими экземплярами, производными от системных сущностей более высокого уровня абстракции— мета-Класса и мета- Атрибута соответственно, которые являются субъектами Мета-модели системы управления данными.
Таким образом, в системе управления данными можно вьщелить три уровня: 1) уровень Мета-модели самой системы; 2) уровень метаданных приложения; и 3) уровень конечных информационных значений. При этом важно отметить, что все перечисленные субъекты первых двух уровней, в самом общем случае представляют собой некоторое декларативное описание, существующее в машиночитаемом виде, пригодном для долговременного хранения. Система управления данными использует декларативные субъекты для создания на их основе производных экземпляров низ-лежащего уровня, и делает это унифицированным образом, встроенными методами.
Рассмотрим субъекты метаданных с точки зрения их интерфейсного аспекта.
В предметной области понятийные сущности и их характеристики обладают некоторой естественной формой их человеческого восприятия, причем для однородных и однотипных субъектов метаданных эта форма унифицирована. Так числовое или строковое значение унифицированно воспринимается в виде текста, логическое или медиа-значение— в виде образа, множество элементов - в виде некоторого их перечисления, множество числовых значений— в виде графика, и так далее. Эти формы восприятия далее будем именовать визуальными Представлениями субъектов, и попутно отметим, что визуальное Представление является частным случаем более общего абстрактного понятия Представление сущности. По своей сути Представление сущности является реализацией интерфейсного аспекта сущности, который в свою очередь может принимать самые различные формы, и в том числе: визуальные, событийные, печатные или файловые.
С точки зрения интерфейсного аспекта очевидно, что визуальный интерфейс
взаимодействия пользователя с данными должен быть образован визуальными Представлениями субъектов метаданных, использованными в различных комбинациях, определяемых потребностями взаимодействия, и в том числе в комбинации с визуальными компонентами декоративного оформления интерфейса. При этом упомянутые Представления являются экземплярами, производными от системных сущностей более высокого уровня абстракции, таких как различные мета- Представления базовых субъектов мета-Модели системы управления данными - мета- Класса и мета- Атрибута.
Следует предположить, что различные мета-Представления базовых субъектов (которые ниже будут рассмотрены подробнее), в свою очередь являются экземплярами еще более общего абстрактного мета-Представления, которое определяет основной набор сущностей и характеристик, обеспечивающих унифицированную связь субъектов метаданных и компонент интерфейса, и является владельцем базовых методов реализации этой связи. При этом важно отметить, что мета-Представления, и
производные от них экземпляры, принадлежат первому и второму упомянутым уровням абстракции, и представляют собой некоторое декларативное описание, существующее в машиночитаемом виде, пригодном для долговременного хранения. Система управления данными использует предопределенные мета-Представления базовых субъектов для создания на их основе производных экземпляров следующего уровня (конкретных Представлений в создаваемом интерфейсе), и делает это унифицированным образом, не требующим дополнительного кодирования.
Рассмотрим особенности Представлений различных субъектов метаданных.
В самом общем случае и независимо от типа интерфейса (визуальный, отчетный, файловый ), отдельная понятийная сущность предметной области может быть рассмотрена с самых различных интерфейсных точек зрения, каждая из которых включает в себя ту или иную комбинацию характеристик сущности, совокупно образующих конкретный интерфейсный набор. Из этого в частности следует, что пользовательский Класс, как декларативный субъект метаданных, может обладать произвольным множеством собственных независимых Представлений. При этом отдельное независимое Представление Класса, далее именуемое Формой класса, будет образовано экземпляром мета-Представления мета-Класса, и включать в себя совокупность Представлений Атрибутов и Событий класса. Таким образом,
многооконный визуальный интерфейс приложения может быть образован в том числе совокупностью различных независимых Форм классов, описывающих предметную область приложения.
Следует сразу обратить внимание, что независимая Форма класса может быть использована в качестве интерфейса как применительно к единственному экземпляру Класса— производному от Класса объекту данных, так и ко множеству таких экземпляров-объектов, в виде их последовательного перечисления. Иначе говоря, существует две разновидности Формы класса— объектная (унитарная) и
множественная (перечислимая), для создания которых в Мета-модели данных для каждого типа интерфейса изначально предусмотрено два одноименных мета- Представления мета-Класса. При этом очевидно, что множественная Форма класса отличается от объектной тем, что дополнительно включает в себя Представление (экземпляр мета-Представления) мета-Множества, - декларативной сущности уровня Мета-модели данных, ассоциированной с абстрактным множеством. Мета-Множество обладает системными методами управления произвольным абстрактным множеством, включающими в себя в том числе способ получения множества, навигацию во множестве, предоставление множества в форме выборочного перечисления его членов, и прочие. При этом множество может быть представлено в том числе и списком, элементами которого являются пары ключ-значение.
Как было упомянуто выше, Форма класса включает в себя совокупность Представлений Атрибутов и Событий класса. В отличие от Атрибута класса, Событие не является экземпляром уровня Мета-модели, а представляет собой виртуальный субъект метаданных, перманентно существующий для каждого Класса данных, и
предназначенный для реализации интерактивного аспекта Класса как "фабрики" производных объектов данных. Тем не менее, визуальное Представление События класса на Форме является вполне конкретным экземпляром, производным от мета- Представления еще одного, не упомянутого ранее, члена Мета-модели системы управления данными— мета-События. Не вдаваясь в рассмотрение различных типов событий Класса, выделим главное— мета-Событие обладает по меньшей мере одним мета-Представлением для каждого функционального типа события. При этом
Представление События класса может быть ассоциировано с Формой класса, на которой реализуется это Событие (например, создание объекта данных с присвоением значений его характеристикам-атрибутам). Единственной характеристикой Атрибута класса, однозначно определяющей его интерфейсный аспект, является функциональный тип Атрибута, который устанавливает тип информационного значения, производного от Атрибута, и относится к одной из двух групп.
Первую группу образуют естественные вещественные типы, такие как Numeric, String, Logical, Date, Image, etc, которые обладают собственной естественной формой
интерфейсного представления, выраженной в виде текста или изображения. На уровне Мета-модели системы управления данными, для каждого типа Атрибута - члена этой группы существует по меньшей мере одно соответствующим образом
специализированное мета-Представление .
Вторая группа образована так называемыми ссылочными (пользовательскими) типами, и в эту группу входят все атрибуты, реализующие отношения (количественное взаимодействие) Классов. Значением ссылочного атрибута является указатель на объект данных, типизированный, как и сам атрибут, идентификатором целевого Класса отношения (вспомним, что каждый Класс данных фактически представляет собой уникально идентифицируемый пользовательский тип). На уровне Мета-модели для всей группы ссылочных атрибутов существует несколько специализированных мета- Представлений, каждое из которых соответствует одному из перечисленных ниже интерфейсных аспектов:
1) мета-Представление События, ассоциированного с множественной Формой класса, которое используется для выбора из списка объекта целевого Класса отношения, и присвоения идентификатора объекта данных в качестве значения ссылочному атрибуту;
2) мета-Представление События, ассоциированного с вызовом объектной Формы класса;
3) мета-Представление собственно целевого Класса отношения;
4) мета-Представление Перечисления объектов целевого Класса, которое ассоциировано с атрибутом обратной ссылки ( на стороне "один-" отношения "многие-к-одному").
Рассмотрим подробнее внутреннюю структуру мета-Представлений.
Абстрактное мета-Представление, общий предок всех остальных мета-Представлений, включает в себя две составные части: определение абстрактной служебной сущности, далее именуемой Дата-компонент, а также определение интерфейсного кортежа— коллекции абстрактных унифицированных экземпляров Интерфейсных компонент. Абстрактный Дата-компонент обеспечивает унифицированную ассоциацию с
субъектами метаданных, и с этой целью включает в себя по меньшей мере следующие характеристики, значения которых конкретизируются в производных от него
экземплярах: 1) идентификатор функционального типа субъекта Мета-модели; 2) идентификатор типа интерфейса; 3) идентификатор целевого экземпляра субъекта метаданных.
Абстрактный Интерфейсный компонент, как отдельный элемент интерфейсного кортежа, обеспечивает унифицированную связь конкретного экземпляра системного интерфейсного компонента с экземпляром Дата-компонента, и с этой целью включает в себя по меньшей мере следующие характеристики, значения которых конкретизируются в производных от него экземплярах: 1) идентификатор целевого экземпляра Дата- компонента; 2) идентификатор типа системного интерфейсного компонента; 3) идентификатор производного экземпляра системного интерфейсного компонента.
Помимо указанных свойств, и Дата-компонент, и Интерфейсный компонент,
обеспечивают в своих производных экземплярах унифицированную связь типа родитель-ребенок, и с этой целью включают в себя указатель на "родительский" экземпляр, а также список "дочерних" экземпляров.
Каждое частное мета-Представление конкретного субъекта метаданных является экземпляром, производным от абстрактного мета-Представления, в котором
неопределенная ранее часть характеристик конкретизируется, то есть получает конечные значения. Так Дата-компонент фиксирует в своих декларациях
идентификаторы функционального типа субъекта и типа интерфейса, а каждый интерфейсный компонент кортежа— идентификатор системного интерфейсного компонента. При этом следует обратить внимание, что мета-Представление субъекта метаданных может включать в себя более одного интерфейсного компонента. В этом случае интерфейсные компоненты, обмениваясь взаимными указателями, задействуют характеристики родитель-ребенок, и при этом один из компонент становится корневым, то есть играет роль общего "родителя".
Для целей настоящего изобретения важно подчеркнуть, что все мета-Представления субъектов мета-Модели в системе управления данными на момент начала создания пользовательского интерфейса как правило уже существуют в некоторой заранее предопределенной форме. Но это не является препятствием для создания
дополнительных мета-Представлений в процессе создания интерфейса, что может быть обусловлено в том числе и расширением системной библиотеки интерфейсных компонент.
Также важно отметить, что декларативное определение частного мета-Представления содержит набор сущностей и характеристик, обеспечивающих связь субъекта
метаданных и компонент интерфейса, а производные от него экземпляры Дата- компонент и Интерфейсного кортежа в процессе создания интерфейса реализуют эту связь на физическом уровне исполнения, при этом обеспечивая требуемое поведение, которое основано на унаследованных у частного мета-Представления
предопределенных унифицированных методах.
Рассмотрим создание и взаимодействие экземпляров Представлений подробнее.
Как уже упоминалось, интерфейс приложения формируется экземплярами Дата- компонент и экземплярами Интерфейсных компонент, производными от мета- Представлений сущностей, участвующих в образовании этого интерфейса.
В любом месте создаваемого интерфейса, независимо от его типа, логика создания нового Представления - экземпляра мета-Представления, строго унифицирована, и реализуется навигационным методом. Суть навигационного метода состоит в том, что между существующим и новым Представлениями должна существовать очевидная связь, декларированная на уровне Модели приложения. Только в этом случае
отображаемые интерфейсом информационные значения будут непротиворечивы и логически связаны. К примеру - информационные значения (экземпляры Атрибутов) должны принадлежать одному и тому же объекту (экземпляру Класса). То есть, относительно Класса в интерфейсе можно разместить только собственные Атрибуты или События этого Класса, но при этом принадлежащий Классу ссылочный атрибут далее рассматривается уже как другой Класс, относительно которого можно размещать его Атрибуты и События.
Отправной точкой процесса создания экземпляра мета-Представления является внешнее воздействие - событие пользователя, желающего включить в состав интерфейса очередной его элемент. Получателем такого воздействия будет некий действующий экземпляр интерфейсного компонента, который запросит идентифицируемый им экземпляр Дата-получателя, а тот, в свою очередь, запросит ассоциированный с ним исходный субъект метаданных, на предмет получения перечня субъектов (Атрибутов или Событий), допустимых к размещению в данном месте интерфейса относительно исходного субъекта. Если указанный перечень не пуст, то он в визуально удобной форме списка именованных элементов предлагается пользователю, который делает свой выбор. Если у выбранного субъекта существует более одного мета-Представления, то для выбора создаваемого мета-Представления пользователю предлагается дополнительный диалог выбора, иначе по умолчанию используется единственно возможный вариант. При этом, если выбранное мета-Представление ассоциировано с Событием пользователя, требующим открытия новой Формы класса, то дополнительно будет предложен диалог выбора Формы класса.
Выбор пользователем конкретного мета-Представления завершает диалог, после чего запускается конструктор выбранного мета-Представления. Конструктор создает декларации-экземпляры, производные от Дата- и Интерфейсных компонент своего мета- Представления, с присвоением им уникальных собственных идентификаторов, а также идентификаторов соответствующих исходных компонент в качестве указателя на родительский компонент. Кроме того, экземпляр Дата-компонента получает
идентификаторы выбранного субъекта метаданных и (опционально) Формы класса, а экземпляр Интерфейсного компонента - идентификатор Дата-компонента. Тем самым, созданные экземпляры фиксируют цепочку взаимных указателей: Интерфейсный компонент— > Дата-компонент— >· субъект метаданных, и встраиваются в системы отношений родитель-ребенок, объединяющие декларации Дата-компонента и
Интерфейсных компонент в две условно независимых друг от друга структуры данных: Дата-ресурс и Интерфейсный ресурс. При этом стоит обратить внимание, что если на уровне Мета-модели данных декларация мета-Представления выступала как
самостоятельная декларативная сущность, объединяющая Дата- и Интерфейсные компоненты, то на уровне Модели приложения создавать экземпляр собственно мета- Представления уже нет необходимости. Свою принадлежность к конкретному мета- Представлению производные экземпляры Дата- и Интерфейсных компонент фиксируют в своих декларациях в виде идентификатора родительского мета-Представления.
Таким образом, не прибегая к написанию программных кодов, используя только методы наследования и фундаментальные свойства отношения родитель-ребенок, а также унифицированные визуальные диалоги выбора (субъекта метаданных, Представления субъекта, Формы класса), можно и далее конструировать требуемый интерфейс.
Очевидно, что исходным местом для рассмотренного выше процесса создания интерфейса, является открытая Форма класса, которая, как экземпляр мета- Представления мета-Класса, включает в себя экземпляры Дата- и Интерфейсного компонента, которые де-факто являются корневыми в системе отношений родитель- ребенок, образующей содержимое Дата- и Интерфейсного ресурсов Формы класса. Форма класса автоматически создается, при абстрактном создании имени новой Формы в унифицированном системном диалоге выбора формы. В свою очередь указанный диалог вызывается при назначении Формы класса создаваемому (или уже существующему) Представлению События класса, для которого интерфейсный тип Формы (визуальная, печатная,...) предопределен уже на уровне мета-Представления События. То есть, при вызове унифицированного диалога выбора формы, ему указывается требуемый интерфейсный тип, и, соответственно, диалог отображает только Формы указанного типа, и если Форма создается, то она автоматически получает указанный тип.
Для организации хранения и управления декларативными Формами классов, система управления данными использует производные объекты служебного класса данных Forms, существование которого скрыто от пользователя. При этом в качестве
уникального идентификатора Формы используется идентификатор объекта, хранящего декларации Формы.
В классе Forms предопределены атрибуты, в экземплярах которых в объектах данных класса Forms размещаются все значимые характеристики декларации Формы, такие как: идентификатор Класса; идентификатор типа интерфейса класса; пользовательское наименование Формы; структурированная совокупность деклараций Дата-компонент (Дата-ресурс); структурированная совокупность декларация Интерфейсных компонент (интерфейсный ресурс).
Новый объект класса Forms создается при создании новой Формы класса в
унифицированном системном диалоге выбора формы, при этом в нем фиксируются идентификаторы Класса и типа интерфейса. Структурированные совокупности деклараций Дата- и Интерфейсных компонент автоматически сериализуются и сохраняются в объекте данных как при создании нового Представления на Форме, так и при закрытии Формы после ее модификации.
Рассмотрим организацию обмена данными между различными компонентами
Представления в процессе исполнения.
При открытия нового окна интерфейса на основе деклараций Формы, этому окну присваивается уникальный идентификатор, после чего из объекта данных Forms извлекаются Дата-ресурс и Интерфейсный ресурс. Дата-ресурс, помеченный
идентификатором окна, остается на стороне данных, а Интерфейсный ресурс, также помеченный идентификатором окна, передается на сторону интерфейса, после чего между ними начинается обмен данными, организованный по следующим правилам. Компоненты Дата-ресурса последовательно, начиная с корневого Дата-компонента, используют хранимые идентификаторы субъектов метаданных для обращения к Модели данных с целью извлечения из системы управления данными экземпляров (объектов данных и информационных значений), производных от адресуемых субъектов. Процесс извлечения носит навигационный характер, так как пара субъект-экземпляр,
относительно которых осуществляется единичное извлечение, всегда однозначно детерминирована. Извлеченные таким образом информационные значения сохраняются в отдельной структуре данных, именуемой Выборка данных. При этом каждое размещаемое в Выборке значение помечается уникальным идентификатором Дата- компонента, который извлек это значение, а каждый элемент перечисления
дополнительно помечается порядковым номером в перечислении. Сформированная таким образом Выборка данных сериализуется, помечается идентификатором окна интерфейса, и передается на сторону интерфейса пользователя.
На стороне интерфейса идентификатор окна в Выборке данных используется для адресации и инициации конкретного Интерфейсного ресурса. Инициированные таким образом, компоненты Интерфейсного ресурса последовательно, начиная с корневого Интерфейсного компонента, начинают формирование содержимого окна интерфейса соответствующего интерфейсного типа, и при этом используют хранимые
идентификаторы Дата-компонент для извлечения из Выборки данных отображаемых интерфейсом информационных значений.
В случае интерактивного интерфейса визуального типа, любое воздействие
пользователя на компоненты интерфейса (завершенный ввод данных или инициация события) отрабатывается следующим образом. Инициированный пользователем
Интерфейсный компонент создает структуру данных, именуемую Событие интерфейса, помечает структуру идентификатором окна интерфейса и хранимым идентификатором Дата-компонента, дополняет структуру введенным пользователем информационным значением (при наличии такового), и передает сформированное таким образом Событие интерфейса на сторону данных.
На стороне данных полученное Событие интерфейса диспетчерируется целевому компоненту Дата-ресурса. Инициированный таким образом Дата-компонент использует применительно к своим хранимым декларациям унаследованный у мета-Представления метод обработки события, включая в том числе и передачу информационного значения ассоциированному субъекту метаданных. При необходимости, после завершения обработки события пользователя, Дата-компонент инициирует весь Дата-ресурс на формирование новой Выборки данных в адрес интерфейса.
Таким образом, используя исключительно визуальный конструктор, оперирующий декларативными Представлениями субъектов метаданных, и ограниченный набор предопределенных системных методов, можно создать многооконный и
многофункциональный интерфейс взаимодействия с пользователем произвольной сложности, не прибегая при этом к традиционному программированию в виде написания программных кодов.
При этом, отдельное окно класса полностью описывается декларативной Формой класса, которая с одной стороны является объектом данных, производным от
служебного класса, а с другой стороны является субъектом метаданных интерфейсного типа. При этом, с определенной точки зрения декларация отдельного Класса данных (экземпляр мета-Класса), включающая в себя декларации Атрибутов класса (экземпляры мета- Атрибута), также может являться объектом данных, производным от некоторого служебного класса - Супер-класса .
Для открытия многих окон необходимо одно исходное окно приложения, на котором расположены органы управления (кнопки или элементы меню), инициирующие открытие всех последующих окон. Роль такого окна может играть Форма упомянутого Супер-класса, относительно которой размещаются Представления классов, имеющие интерактивную форму кнопки (или кнопок, сгруппированных в меню), которым унифицированным диалогом назначены требуемые Формы.
Еще одним аспектом настоящего изобретения является прогрессивный способ организации системной библиотеки визуальных компонент. Этот аспект тесно связан с предшествующим, так как Интерфейсные компоненты любого визуального
Представления представляют собой экземпляры компонент системной библиотеки в декларативной форме их выражения, включающей в себя в том числе и определение значений их частных визуальных характеристик.
Системная библиотека визуальных компонент, из экземпляров которых и формируется конкретный интерфейс пользователя, составляет основу любой системы разработки и реализации графических визуальных интерфейсов. Очевидным преимуществом такой библиотеки является взаимная согласованность свойств, способов отображения и методов поведения всех входящих в ее состав компонент.
Существенным же недостатком предлагаемых к использованию библиотек является их обширный компонентный состав. Библиотеки содержат большое число компонент, и в том числе функционально сложных, для того, чтобы удовлетворить всем мыслимым интерфейсным потребностям прикладной задачи. Между тем, на практике, всегда и постоянно встречаются такие потребности, которые так или иначе, но выходят за рамки возможностей как одиночных компонент библиотеки, так и их комбинации. Эти потребности приходится удовлетворять за счет изменения программного кода стандартных компонент библиотеки, что порождает новые версии библиотеки с потенциальным конфликтом версий, а также весьма затратно и небезопасно, так как в этом случае сама библиотека должна быть представлена в открытой форме, пригодной для внесения изменений. В качестве примера рассмотрим такой относительно несложный и массово используемый компонент интерфейса, как визуальная Кнопка (Button). Кнопка включает в себя в том числе визуальный образ (Икону) и надпись (Текст). Все визуальные характеристики кнопки, включая ее форму, цвет, рамку, а также отображение, положение и состав Иконы и Текста, определяются и управляются стандартным образом. Но для того, чтобы добавить в состав кнопки дополнительный элемент оформления, придется создавать путем наследования от Кнопки еще один компонент библиотеки, и вносить изменения в его программный код.
Помимо этого, большое количество компонент в библиотеке требует соответствующего объема специальных знаний об особенностях их реализации, использования и взаимного взаимодействия, что очевидным образом также создает трудности в процессе создания прикладных интерфейсов.
Администрирование свойств визуальных компонент также представляет собой непростую задачу в силу их многочисленности и разнохарактерности. Обилие видов компонент и их свойств заставляет использовать в качестве основного инструмента визуального администрирования универсальный Инспектор свойств, который отображает все свойства в виде некоторого линейного перечисления. При этом, с возрастанием функциональной сложности системных компонент, трудоемкость их администрирования Инспектором очевидным образом возрастает прогрессивно. Если для простого компонента Text, отображающего простую надпись, можно насчитать порядка десяти требующих администрирования свойств, то для приведенного в качестве примера относительно простого компонента Кнопка (в состав которого входит также и Text) таких свойств уже больше сорока. Еще одна трудность использования существующих систем визуализации заключается в том, что они изначально разрабатывались изолировано от систем управления данными. Эта изоляция обусловлена в том числе и тем, что в большинстве случаев система визуализации не является составной частью системы управления данными (как в предыдущем аспекте настоящего изобретения), а разрабатывалась для использования совместно с самыми различными системами управления данными. Естественной платой за такую самостоятельность является трудоемкость взаимного сопряжения компонент двух совершенно разных систем (управления данными и визуализации), которая осуществляется исключительно путем написания объемных программных кодов.
Перечисленные проблемы, характерные для всех существующих систем визуализации, можно частично или полностью устранить, и тем самым существенно снизить трудоемкость разработки визуальных интерфейсов, если пересмотреть принципы организации системной библиотеки визуальных компонент.
Если проанализировать любое двумерное графическое изображение произвольной сложности, используемое в качестве интерфейса пользователя, то станет очевидным, что его можно сформировать, комбинируя различным образом изображения, формируемые всего тремя графическими субъектами: Text, Image и Canvas. Так упомянутая в качестве примера визуальная Кнопка, может быть реализована не одним монолитным
компонентом, а комбинацией субъектов Canvas+Text+Image. Таким образом, основная проблема систем визуализации - обширность компонентного состава при перманентной его функциональной неполноте, может быть успешно решена путем потенциально бесконечной комбинаторики элементарных компонент визуализации, далее именуемых Примитивами. При этом важно подчеркнуть, что собственно комбинирование подразумевает связывание субъектов отношением типа родитель-ребенок.
Каждый из перечисленных элементарных графических субъектов-Примитивов обладает по меньшей мере одним уникальным свойством, в отношении которого использует свой собственный оригинальный способ создания графического изображения, а также метод реализации интерактивного взаимодействия с пользователем. Уникальное свойство и метод его формирования пользователем далее именуются базовым свойством и базовым методом Примитива.
Минимальный компонентный состав библиотеки позволяет для каждого Примитива иметь отдельный фиксированный визуальный диалог управления его свойствами. При этом, так как набор собственных свойств Примитива весьма ограничен, то и органов визуального управления диалог содержит немного. Этот диалог организуется с учетом требований наглядности и эргономики таким образом, чтобы обеспечить максимально наглядное восприятие при минимальных действиях пользователя в процессе управления отдельными свойствами. А чтобы еще более облегчить доступ к диалогу, его следует сделать "всплывающим" вблизи выбранного для управления Примитива. Использование диалога, основанного на таких принципах, существенно повышает производительность процесса визуального администрирования интерфейса пользователя, и позволяет отказаться от более трудоемкого в использовании универсального инспектора свойств, или столь популярных сейчас инструментальных панелей.
При рассмотрении предыдущего аспекта настоящего изобретения подчеркивалось, что визуальные компоненты интерфейса, фактически производны от субъектов метаданных, и автоматически, без написания программных кодов, получают декларативную ассоциацию с данными при своем создании в составе нового экземпляра Представления субъекта метаданных. Эта ассоциация выражается в том, что интерфейсный компонент владеет идентификатором Дата-компонента на стороне данных, что позволяет ему как получать данные из Выборки для отображения, так и реагировать на воздействие пользователя, транслируя его Дата-компоненту. Для целей настоящего изобретения важно подчеркнуть, что тот же самый механизм ассоциации может быть в полной мере использован и для унифицированной ассоциации с данными всех частных свойств любого визуального Примитива, и при этом также не требует написания
дополнительного программного кода в процессе администрирования интерфейса. То есть, каждое свойство Примитива из системной библиотеки, которое потенциально может быть поставлено в зависимость от данных, в своей структуре имеет место для размещения идентификатора Дата-компонента. Соответственно, в органах управления значением такого свойства предусмотрен в том числе и способ вызова
унифицированного (для всех без исключения свойств) диалога выбора субъекта метаданных для создания ассоциации. При выборе требуемого субъекта, указанный диалог инициирует создание Дата-компонента на стороне данных, его включение в Дата-ресурс, и вернет полученный при создании Дата-компонента идентификатор, для его последующего сохранения в свойстве Примитива.
Так как многие визуальные свойства (например, цвет) используются только для визуального выделения отображаемого в общей интерфейсной картине, то значение этих свойств не имеет смысла извлекать из системы управления данными в явном виде, а следует воспользоваться методом альтернативного выделения. Суть альтернативного выделения заключается в том, что в зависимости от внешнего управляющего
логического значения используется либо основное, либо альтернативное значение.
Соответственно, декларация альтернативного свойства имеет сложный структурный состав, и помимо основного значения включает в себя альтернативное значение, а также идентификатор Дата-компонента. Если задано альтернативное значение, то становится возможна (и обязательна к реализации) ассоциация с субъектом метаданных
логического типа. При формировании экземплярами визуальных компонент итогового I отображения, альтернативное значение свойства экземпляра будет использовано взамен основного, если соответствующий Дата-компонент через Выборку вернет значение "истина" (True).
Таким образом важно подчеркнуть, что с точки зрения способа управления и получения значения, все свойства Примитивов можно разделить на статические, динамические и альтернативные. Статические свойства в принципе не имеют ассоциации с субъектами метаданных, и их значения могут быть изменены только через унифицированный диалог управления свойствами Примитива. Динамическим будет считаться свойство, для которого установлена прямая ассоциация с субъектом метаданных в виде владения идентификатором Дата-компонента.
I
Двухмерный графический интерфейс в первую очередь характеризуется прямоугольной геометрией всех отображающих его экземпляров графических компонент. Даже если на экране присутствует визуальное закругление (Кнопка овальной формы, в качестве примера), то это всего лишь способ рисования компонента, при котором часть исходного i прямоугольника не покрывается изображением. В силу этого, все компоненты
системной библиотеки могут быть порождены от общего предка, который для описания геометрии использует четыре координаты— по две для каждой оси ординат. При этом, как будет показано ниже, декларация координаты имеет сложную структуру, и каждая из четырех координат может рассматриваться как экземпляр декларативного определения
) мета-Координаты.
Непосредственное взаимодействие графических компонент, и в том числе координатное, реализуется через систему их отношений родитель-ребенок. Более того, графический компонент (экземпляр) может существовать только относительно какого-то другого экземпляра графического компонента. Даже условно независимая Форма окна тем не менее существует относительно общей визуальной Сцены, которая также является экземпляром. Соответственно, декларация отношения родитель-ребенок также определена на уровне общего предка всех компонент.
Рассмотрим подробнее свойства отдельных примитивов.
Примитив Text применяется для отображения произвольного текста в виде
последовательного набора визуальных образов составляющих его символов.
Соответственно, базовое свойство примитива Text оперирует информационным значением, представляющим собой последовательность кодов символов в любой возможной кодировке, общей для всего набора, а базовый метод представляет собой традиционный визуальный редактор текста.
Визуально, отображаемый текст характеризуется статическими свойствами Шрифт (Font), Размер (Font size), количество Строк (Lines), меж-строчный Интервал (Line spacing), Выравнивание (Align), Тень (Shadow), Контур (Outline font), а также
альтернативными свойствами визуального выделения Цвет (Color), Полужирный (Bold), Курсив (Italic), Подчеркивание (Underline), Перечеркивание (Striking out).
Базовое свойство Text может быть как статическим (примитив используется как элемент декорирования интерфейса), так и динамическим. В последнем случае отображаемый текст характеризуется свойством Редактируемый (Editable), и может быть как простым текстом, так и содержать в себе теги HTML-разметки.
Примитив Image применяется для отображения произвольного изображения.
Соответственно, его базовое свойство оперирует информационным значением, представляющим собой растровое или векторное изображение в любом используемом для хранения изображений компьютерном формате как со сжатием, так и без. Базовое свойство примитива Image может быть статическим (примитив используется как элемент декорирования интерфейса), альтернативным или динамическим. В последнем случае изображение характеризуется статическим свойством Редактируемый (Editable), перманентно разрешающим или запрещающим использование базового метода для изменения изображения.
Визуально, изображение характеризуется статическими свойствами Прозрачность (Transparency) и Масштабируемость (Scalability), которое разрешает/блокирует изменение исходного размера. Базовый метод представляет собой визуальный диалог выбора источника изображения, в качестве которого может выступать как файл, так и устройство (например, камера).
Примитив Canvas применяется для отображения прямоугольной области, состоящей из двух основных частей: области Фона (Background) и области Обрамления (Border). В свою очередь, область Фона включает в себя область Заголовка (Header) и область Перечисления (Enum). В составе Canvas область Фона существует и отображается перманентно, а использование и отображение областей Обрамления, Заголовка, и Перечисления задается опционально в соответствующих одноименных свойствах управления.
В отличие от Image и Text, базовое свойство Canvas является не визуальным, а интерактивным, и заключается в способности воспринять прямое воздействие пользователя на визуальную область Canvas. Соответственно, для этих целей
динамическое базовое свойство должно иметь ассоциацию с таким субъектом
метаданных, как Событие, и тогда базовый метод будет заключаться в трансляции воздействия пользователя этому субъекту. Если же такой ассоциации нет, то Canvas теряет свою интерактивность, и используется исключительно как элемент
декорирования интерфейса.
Визуально целиком, примитив Canvas характеризуется статической Прозрачностью (Transparency) и динамической Видимостью (Visibility). Прозрачность задается в виде степени прозрачности итогового отображения Canvas. Видимость Canvas позволяет ситуационно управлять отображаемым компонентным составом интерфейса со стороны приложения.
Визуально, область Фона характеризуется альтернативной цветовой заливкой (Filling), равномерной, или с градиентом. Более сложный рисунок Фона можно реализовать наложением примитива Image.
Область Обрамления с четырех сторон визуально ограничивает область Фона, и может быть одного из двух видов: графического или линейного. Предопределенный, и расширяемый по мере надобности, набор графических Обрамлений позволяет
реализовать закругленное (вплоть до овального) или рельефное отображение Canvas. Линейное Обрамление отображается в виде непрерывной или прерывистой линии с опционально задаваемой толщиной и цветом. В отличие от графического, линейное Обрамление позволяет раздельно управлять отображением каждой отдельной стороны, и может использоваться для отображения как одиночных линий, так и табличных структур. Все свойства Обрамления являются статическими, за исключением цветовой раскраски линейного Обрамления, которое является альтернативным. Установка нулевой толщины линии линейному Обрамлению эквивалентно исключению Обрамления из отображения.
Область Заголовка не характеризуется собственными визуальными свойствами, и предназначена для размещения на ее поверхности дочерних примитивов, формирующих заголовки Таблиц и Форм. При отсутствии дочерних примитивов область Заголовка исключается из отображения.
Область Перечисления предназначена для размещения на ее поверхности дочерних примитивов, формирующих строки Таблиц, а также Графики и Диаграммы, и
перманентно ассоциируется с множеством объектов. Отображением Перечисления управляет массив записей, в котором каждая запись содержит полный набор
информационных значений дочерних примитивов Перечисления. Собственно отображение формируется Перечислением построчно, в направлении заданного Вектора перечисления, при этом для каждой записи управляющего массива, Перечисление инициирует отображение дочерних примитивов в оставшемся свободном пространстве области, предоставляя им содержимое записи для выборки информационных значений. Соответственно, дочерние примитивы группируют на поверхности области
Перечисления таким образом, чтобы их совокупность образовывала визуальную строку перечисления. Управляющий Перечислением массив записей представляет собой условное "окно выборки" из ассоциированного множества. Фиксированный размер массива в записях рассчитывается автоматически, исходя из соотношения размеров области Перечисления и строки перечисления в направлении Вектора таким образом, чтобы пространство области было полностью заполненным. Для изменения положения "окна выборки" в ассоциированном множестве под воздействием навигационных Событий пользователя, Перечисление предоставляет собственную интерактивность. Для целей настоящего изобретения следует подчеркнуть, что наличие у Перечисления собственного интерактивного поведения, необходимость ассоциации со множеством, а также удобство создания примитива, как Представления множественного аспекта субъекта метаданных, обуславливают возможность выделения из Canvas его
естественной способности к перечислению в отдельный самостоятельный примитив, именуемый Enum, и образованный прямым наследованием от Canvas. Важно обратить внимание, что в отличие от примитивов Image и Text, примитиву Canvas разрешено размещать на своей поверхности дочерние примитивы, с автоматическим образованием связи родитель-ребенок, что и является основой для реализации потенциально бесконечного комбинирования примитивов. При этом дочерние примитивы вступают в координатное взаимодействие с родительским Canvas, и на них распространяются такие общие свойства Canvas как Прозрачность и Видимость.
Координатное взаимодействие в отношениях родитель-ребенок выражено
ограничительным правилом: "ребенок не может покинуть пределы области родителя". При изменении геометрии примитивов, данное правило проявляет себя явным образом, запрещая перемещение дочернего примитива за пределы родительского, а также соответствующим образом ограничивая уменьшение размеров родительского
примитива. При отображении данное правило проявляет себя таким образом, что та часть отображения дочернего примитива, которая выходит за пределы родительского Canvas, принудительно отсекается. Для преодоления данного ограничения, и
достижения более гибкого управления отображением дочерних примитивов, Canvas обладает статическими свойствами Расширяемость (Expandability) и Прокрутка (Scroll), которые действуют отдельно для каждой оси X и Y, и опционально управляются установкой одноименных флагов. Если для выбранной оси ординат включена
Расширяемость, то по этой оси дочерние примитивы могут изменять размер Canvas (в сторону увеличения) на величину, достаточную для их полного отображения, при этом указанное изменение может быть ограничено статическими размерами более старшего родительского Canvas. Если для выбранной оси ординат включена Прокрутка, то размер поверхности Canvas для этой оси считается условно бесконечным, и действующая область Фона с фиксированными координатами выступает в качестве "окна" к этой поверхности. При этом, для доступа к отображениям дочерних примитивов, выходящих за пределы окна видимости, Canvas автоматически включает визуальный орган управления положением окна, прилегающий к одной из соосных сторон области Фона, и известный под названием Полоса прокрутки (Scroll bar). Свойства Расширяемость и Прокрутка для общей оси ординат являются взаимоисключающими. У производного от Canvas примитива Enum, свойство Прокрутки (соосное с Вектором перечисления) включено перманентно.
Для целей настоящего изобретения важно обратить внимание, что при соблюдении определенного условия любая из координат любого примитива может быть ассоциирована с внешним источником значения - Атрибутом класса, управляющим информационными значениями численного типа, включая значения типа дата-время. Указанная ассоциация координаты с Атрибутом позволяет строить Графики, Диаграммы, а также осуществлять визуальную привязку отображения примитива к конкретной точке на карте или схеме.
Необходимым условием для создания ассоциации координаты примитива с Атрибутом является наличие способа конвертации численного информационного значения в координату отображения и обратно. Такой способ для своих дочерних примитивов предоставляет примитив Canvas в виде одного из актуализированных собственных свойств - Шкала (Scale) или Карта (Map). Каждое из этих свойств при его актуализации будет содержать указатель на одноименный вспомогательный не визуальный компонент, владеющий соответствующим изображением, а также некоторыми численными значениями, соответствующими границам этого изображения по осям ординат. Наличие указанных граничных значений позволяет дочернему примитиву, используя простую пропорцию, преобразовать численное значение координаты в значение координаты отображения относительно родительского Canvas, далее используемое примитивом для формирования своего итогового отображения на поверхности Canvas.
Свойство Шкала использует содержимое ассоциированного компонента в качестве визуальной декорации и расчетной базы при реализации Графиков и Диаграмм. При этом собственно отображение осуществляется дочерними примитивами Text и Image, с использованием свойства Перечисления при необходимости. Свойство Шкала используется примитивом Canvas применительно к области Обрамления, и
устанавливается раздельно для каждой ее стороны. Изображение, заимствованное у компонента Шкала, замещает собой (с масштабированием изображения, при
необходимости) графическое отображение стороны обрамления, а граничные значения применяются к соосной оси ординат. Очевидно, что свойство Шкала можно установить одновременно только для двух взаимно-ортогональных сторон области Обрамления Canvas.
Свойство Карта используется примитивом Canvas применительно к области Фона.
Изображение, заимствованное у компонента Карта, замещает собой (с
масштабированием, при необходимости) заливку области Фона, а граничные значения применяются к соответствующим осям ординат. Тем самым реализуется визуальная и расчетная основа для схематического или картографического позиционирования отображений дочерних примитивов, с использованием Перечисления, или без. При этом представляется очевидным, что одновременное использование свойств Шкала и Карта невозможно.
В самом общем случае вспомогательные компоненты Шкала и Карта могут быть сгруппированы в однородные коллекции. Целью такого объединения является использование коллекции для динамического изменения масштаба результирующего отображения Графика или Диаграммы. При этом сами компоненты Шкала и Карта могут являться объектами данных, производными от служебного класса системы управления данными, а свойства Шкала и Карта примитива Canvas - обладать унифицированной ассоциацией с такой формой хранения компонент.
Стоит обратить внимание, что такое собственное свойство Перечисления, как Вектор перечисления, указывает направление размещения производных отображений дочерних компонент, и, в подавляющем большинстве случаев, по умолчанию, этот Вектор направлен сверху вниз. Но в самом общем случае, Вектор перечисления может иметь любую направленность, и более того— устанавливать не только линейный, но и радиально-угловой характер формирования итогового отображения. Последнее обстоятельство позволяет использовать Перечисление не только для создания линейно- столбчатых, но также и круговых Диаграмм.
Рассмотренный выше набор примитивов и их частных свойств, в сочетании со способом унифицированного управления данными, позволяет создавать самые сложные прикладные визуальные и не визуальные интерфейсы пользователя, не прибегая при этом к написанию программных кодов, а используя исключительно производительные и наглядные методы прямого визуального конструирования.
При этом важно подчеркнуть, что для целей описания настоящего изобретения рассматривались только наиболее значимые характеристики примитивов, и наиболее значимое их поведение. Вместе с тем различные модификации упомянутого могут быть сделаны и без отступления от сущности и объема настоящего изобретения, который ограничивается только формулой изобретения и ее эквивалентами.

Claims

ФОРМУЛА
1. Способ унифицированной ассоциации графического интерфейса пользователя с данными в программно реализуемой компьютером системе управления данными, включающей в себя по меньшей мере процессор, память и устройство отображения графической информации, в которой машиночитаемые данные являются экземплярами, производными от уникально идентифицируемых машиночитаемых субъектов метаданных, таких как абстрактные понятийные сущности и их частные
характеристики, включая характеристики отношений понятийных сущностей, а изолированный от данных графический интерфейс пользователя образован
экземплярами унифицированных визуальных компонент, отличающийся тем, что многооконный графический интерфейс реализуют без написания программного кода путем навигационного комбинирования экземпляров нативных форм визуального представления субъектов метаданных, при этом новый экземпляр представления создается простым выбором в диалоге действующего субъекта метаданных или унифицированного события субъекта.
2. Способ по п.1, отличающийся тем, что упомянутое представление ассоциировано с типом субъекта метаданных, и является декларативным субъектом системы
управления данными, включающей в себя в том числе экземпляр унифицированного не визуального компонента, именуемого дата-компонент, а также образцовый набор экземпляров визуальных компонент, совокупно образующих визуальный образ представления.
3. Способ по п.2, отличающийся тем, что упомянутый экземпляр представления создается выбранным в диалоге представлением субъекта метаданных, и включает в себя в том числе: на стороне данных— уникально идентифицируемый экземпляр дата- компонента; на стороне графического интерфейса— набор экземпляров визуальных компонент, полученный копированием образцового набора родительского
представления, при этом упомянутый экземпляр дата-компонента владеет
идентификатором упомянутого субъекта метаданных, который использует для извлечения или сохранения данных, производных от упомянутого субъекта, методами упомянутого субъекта, при этом упомянутые экземпляры визуальных компонент владеют идентификатором экземпляра дата-компонента, который используют для получения данных от упомянутого экземпляра дата-компонента, или для передачи упомянутому экземпляру событий пользователя и введенных данных.
4. Способ по п.1 , отличающийся тем, что упомянутое окно интерфейса является самостоятельным именованным представлением отдельной понятийной сущности, и содержит комбинацию представлений характеристик и событий этой сущности, при этом каждая отдельная понятийная сущность метаданных обладает произвольным множеством собственных именованных представлений.
5. Способ по п.1 , отличающийся тем, что упомянутое навигационное
комбинирование осуществляют в том числе выбором характеристики отношения, при этом создается экземпляр представления, унифицированный в соответствии с количественной мощностью отношения, и ассоциированный с целевой сущностью отношения.
6. Способ по п.1 , отличающийся тем, что упомянутый графический интерфейс реализуют в трехмерном виртуальном пространстве с использованием объемных визуальных компонент.
7. Система визуального управления данными в вычислительной среде, включающей в себя по меньшей мере процессор, память и устройство отображения графической информации, в которой машиночитаемые данные являются экземплярами,
производными от уникально идентифицируемых машиночитаемых субъектов
метаданных, таких как абстрактные понятийные сущности и их частные
характеристики, а изолированный от данных графический интерфейс пользователя образован экземплярами унифицированных визуальных компонент, отличающаяся тем, что многооконный графический интерфейс пользователя с функциями прямого управления данными образован комбинацией экземпляров нативных форм визуального представления упомянутых субъектов метаданных, каждый из которых включает в себя: на стороне данных— по меньшей мере один экземпляр унифицированного не визуального компонента, именуемого дата-компонент, который владеет
идентификатором субъекта метаданных; на стороне графического интерфейса— по меньшей мере один экземпляр упомянутого визуального компонента, который владеет идентификатором дата-компонента, при этом каждое окно упомянутого многооконного интерфейса является самостоятельным именованным представлением отдельной понятийной сущности, и содержит комбинацию представлений характеристик и событий этой сущности.
8. Система по п.7, отличающаяся тем, что упомянутое представление понятийной сущности является машиночитаемым экземпляром, именуемым ресурс интерфейса, и производным от служебной сущности метаданных, которая включает в себя по меньшей мере три характеристики, при этом множество экземпляров дата-компонент
упомянутого окна интерфейса связаны отношением родитель-ребенок, и совокупно образуют первую древовидную структуру данных, в которой каждый отдельный экземпляр обладает уникальной идентифицируемостью, при этом множество экземпляров визуальных компонент упомянутого окна интерфейса связаны отношением родитель-ребенок, и совокупно образуют вторую древовидную структуру данных, при этом первая и вторая структуры данных в сериализованной форме образуют значения первой и второй характеристик, а наименование упомянутого представления образует значение третьей характеристики служебной сущности в упомянутом ресурсе.
9. Система по п.8, отличающаяся тем, что упомянутый ресурс интерфейса ассоциирован с понятийной сущностью метаданных таким образом, что каждая отдельная понятийная сущность обладает произвольным множеством собственных именованных ресурсов интерфейса, образующим коллекцию ресурсов сущности.
10. Система по п.8, характеризующаяся тем, что значение первой характеристики упомянутого ресурса используют на стороне данных таким образом, что упомянутые экземпляры дата-компонент используют методы ассоциированных субъектов для извлечения производных от них значений данных, которые сохраняют в структуре данных, именуемых выборкой, таким образом, что каждое значение однозначно идентифицируется идентификатором соответствующего экземпляра дата-компонента, при этом значение второй характеристики упомянутого ресурса используют на стороне графического интерфейса таким образом, что визуальные компоненты извлекают значения из выборки, используя для этого идентификатор ассоциированного дата- компонента, при этом упомянутая выборка передается со стороны данных на сторону графического интерфейса по запросу, при этом упомянутая сторона данных, и упомянутая сторона графического интерфейса, в том числе существуют на разных компьютерах, взаимодействующих через сеть передачи данных.
11. Способ реализации визуальных интерфейсов пользователя в вычислительной среде, включающей в себя по меньшей мере процессор, память и устройство отображения графической информации, в которой графическое изображение формируется динамически программным способом экземплярами специализированных визуальных компонент, связанных отношениями родитель-ребенок, и при этом каждый экземпляр отображает себя на поверхности изображения, предоставленного
родительским по отношению к нему экземпляром, отличающийся тем, что
многооконный графический интерфейс произвольной сложности, реализуют без написания программного кода простым комбинированием экземпляров, производных от минимально возможного набора, состоящего из трех атомарных визуальных компонент, именуемых примитивами, при этом каждый из примитивов обладает по меньшей мере одним уникальным свойством, именуемым базовым свойством, отсутствующим у всех остальных примитивов, и способ ввода пользователя в это свойство именуется базовым методом, при этом каждый из примитивов обладает по меньшей мере одним
собственным уникальным визуальным диалогом управления его частными свойствами, при этом свойства примитивов имеют унифицированный способ ассоциации с источниками данных, внешними по отношению к графическому интерфейсу.
12. Способ создания визуальных интерфейсов по п.11 , отличающийся тем, что во множестве экземпляров примитивов, образующих визуальный интерфейс, управление частными свойствами с показом соответствующих диалогов одномоментно
осуществляют только для какого-то одного конкретного экземпляра.
13. Способ создания визуальных интерфейсов по п.11, отличающийся тем, что упомянутый минимально возможный набор включает в себя в том числе примитив "Text", экземпляры которого используют для визуализации произвольного текстового значения указанными в индивидуальных свойствах количеством строк, шрифтом, размером шрифта, цветом и всеми прочими способами визуального выделения изображений символов текста, и при этом упомянутое базовое свойство содержит или статически хранимый текст, или указатель на внешний источник динамического текстового значения, а базовый метод представляет собой визуальный текстовый редактор.
14. Способ создания визуальных интерфейсов по п.11 , отличающийся тем, что упомянутый минимально возможный набор включает в себя в том числе примитив "Image", экземпляры которого используют для визуализации произвольного
изображения указанным в индивидуальных свойствах способом масштабирования, причем собственно изображение может существовать в любом известном формате, и при этом упомянутое базовое свойство содержит или статически хранимое изображение, или указатель на внешний источник динамического изображения, а базовый метод представляет собой визуальный диалог выбора источника изображения.
15. Способ создания визуальных интерфейсов по п.11 , отличающийся тем, что упомянутый минимально возможный набор включает в себя в том числе примитив "Canvas", экземпляры которого используют для визуализации прямоугольной области и обработки событий пользователя в этой области, а также размещения в этой области дочерних экземпляров примитивов, причем указанная область состоит из двух частей: области Фона и области Обрамления, и при этом упомянутое базовое свойство опционально содержит указатель на внешний интерпретатор события, а базовый метод транслирует событие пользователя упомянутому интерпретатору, а также при этом в упомянутой области Фона взаимно независимыми свойствами Заголовок и
Перечисление опционально выделяют две специальные внутренние одноименные области, и при этом область Заголовок используют для визуализации заголовков таблиц и отдельных форм, а область Перечисления используют для визуализации содержимого таблиц, диаграмм и графиков, причем свойство Перечисление содержит ассоциацию с данными, имеющими форму перечислимого множества.
16. Способ создания визуальных интерфейсов по п.11 , отличающийся тем, что упомянутый минимально возможный набор визуальных компонент расширяют путем создания на базе примитива-предка "Canvas" специализированного примитива- наследника "Епшп", при этом унаследованное у предка свойство Перечисление становится базовым свойством наследника.
17. Способ создания визуальных интерфейсов по п.15, отличающийся тем, что упомянутый примитив Canvas обладает свойствами Шкала и Карта, использование которых позволяет дочерним по отношению нему примитивам установить ассоциацию координатных свойств с источниками данных, внешними по отношению к графическому интерфейсу, и преобразовать полученные извне значения в координаты относительно родительского Canvas.
18. Способ создания визуальных интерфейсов по п.11 , отличающийся тем, что упомянутое комбинирование экземпляров компонент осуществляют таким образом, что на визуальной поверхности уже существующего экземпляра создают группу из нескольких экземпляров примитивов, связанных отношением родитель-ребенок, причем упомянутая группа экземпляров описывается часто используемым шаблоном, и совокупно образует визуальный компонент произвольной функциональной сложности, и при этом упомянутый шаблон создают на основе уже существующей группы
экземпляров.
19. Машиночитаемый носитель информации, содержащий команды, которые при выполнении процессором, побуждают компьютер выполнять действия, которые включают в себя создание многооконного графического интерфейса без написания программного кода путем навигационного комбинирования экземпляров нативных форм визуального представления субъектов метаданных, при этом новый экземпляр представления создают простым выбором в диалоге действующего субъекта метаданных или унифицированного события субъекта, при этом упомянутый экземпляр
представления включает в себя: на стороне данных— по меньшей мере один экземпляр унифицированного не визуального дата-компонента, который владеет идентификатором субъекта метаданных; на стороне графического интерфейса— по меньшей мере один экземпляр визуального компонента, который владеет идентификатором упомянутого дата-компонента, при этом каждое окно упомянутого многооконного интерфейса является самостоятельным именованным представлением отдельной понятийной сущности, и содержит комбинацию представлений характеристик и событий этой сущности.
PCT/RU2014/000958 2014-12-19 2014-12-19 Способ и система визуального управления данными WO2016099317A1 (ru)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/536,757 US20170352174A1 (en) 2014-12-19 2014-12-19 Method and system for visual data management
PCT/RU2014/000958 WO2016099317A1 (ru) 2014-12-19 2014-12-19 Способ и система визуального управления данными

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/RU2014/000958 WO2016099317A1 (ru) 2014-12-19 2014-12-19 Способ и система визуального управления данными

Publications (1)

Publication Number Publication Date
WO2016099317A1 true WO2016099317A1 (ru) 2016-06-23

Family

ID=56127038

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2014/000958 WO2016099317A1 (ru) 2014-12-19 2014-12-19 Способ и система визуального управления данными

Country Status (2)

Country Link
US (1) US20170352174A1 (ru)
WO (1) WO2016099317A1 (ru)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111078169A (zh) * 2019-11-29 2020-04-28 武汉虹信技术服务有限责任公司 一种可视化大屏系统的前端装置及其搭建方法
CN111382483A (zh) * 2018-12-29 2020-07-07 比亚迪股份有限公司 站场图工程化方法、装置和设备
US11811681B1 (en) 2022-07-12 2023-11-07 T-Mobile Usa, Inc. Generating and deploying software architectures using telecommunication resources

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10817268B2 (en) * 2017-08-10 2020-10-27 Red Hat, Inc. Framework for modeling with domain model capabilities
US11520606B2 (en) * 2017-09-22 2022-12-06 Vmware, Inc. Dynamic generation of user interface components based on hierarchical component factories
US11693832B2 (en) * 2018-03-15 2023-07-04 Vmware, Inc. Flattening of hierarchical data into a relational schema in a computing system
CN111310429B (zh) * 2020-03-16 2023-08-18 青岛百洋智能科技股份有限公司 一种实现可定制化表单的方法及系统
CN116188626A (zh) * 2023-03-16 2023-05-30 中国测绘科学研究院 一种大比例尺地形图复杂符号的自动派生方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748974A (en) * 1994-12-13 1998-05-05 International Business Machines Corporation Multimodal natural language interface for cross-application tasks
US20090276730A1 (en) * 2008-03-04 2009-11-05 Alexandre Aybes Techniques for navigation of hierarchically-presented data
US8239226B2 (en) * 2005-11-02 2012-08-07 Sourcecode Technologies Holdings, Inc. Methods and apparatus for combining properties and methods from a plurality of different data sources
RU2519059C2 (ru) * 2011-02-10 2014-06-10 Сони Компьютер Энтертэйнмент Инк. Способ и устройство компактного графического интерфейса пользователя

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7631290B1 (en) * 2004-10-27 2009-12-08 Adobe Systems Incorporated Enhanced navigation for visual design editing
US7636163B2 (en) * 2007-07-23 2009-12-22 X-Rite, Inc. Color measurement device with error detection

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748974A (en) * 1994-12-13 1998-05-05 International Business Machines Corporation Multimodal natural language interface for cross-application tasks
US8239226B2 (en) * 2005-11-02 2012-08-07 Sourcecode Technologies Holdings, Inc. Methods and apparatus for combining properties and methods from a plurality of different data sources
US20090276730A1 (en) * 2008-03-04 2009-11-05 Alexandre Aybes Techniques for navigation of hierarchically-presented data
RU2519059C2 (ru) * 2011-02-10 2014-06-10 Сони Компьютер Энтертэйнмент Инк. Способ и устройство компактного графического интерфейса пользователя

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111382483A (zh) * 2018-12-29 2020-07-07 比亚迪股份有限公司 站场图工程化方法、装置和设备
CN111382483B (zh) * 2018-12-29 2023-03-31 比亚迪股份有限公司 站场图工程化方法、装置和设备
CN111078169A (zh) * 2019-11-29 2020-04-28 武汉虹信技术服务有限责任公司 一种可视化大屏系统的前端装置及其搭建方法
CN111078169B (zh) * 2019-11-29 2023-09-26 武汉虹信技术服务有限责任公司 一种可视化大屏系统的前端装置及其搭建方法
US11811681B1 (en) 2022-07-12 2023-11-07 T-Mobile Usa, Inc. Generating and deploying software architectures using telecommunication resources

Also Published As

Publication number Publication date
US20170352174A1 (en) 2017-12-07

Similar Documents

Publication Publication Date Title
WO2016099317A1 (ru) Способ и система визуального управления данными
US7096454B2 (en) Method for gesture based modeling
US7463263B2 (en) Declarative specification of model visualizations
US7486294B2 (en) Vector graphics element-based model, application programming interface, and markup language
US7196712B2 (en) Dynamic, live surface and model elements for visualization and modeling
Gosling et al. The NeWS book: an introduction to the network/extensible window system
RU2371758C2 (ru) Интерфейс программирования для компьютерной платформы
EP0712513B1 (en) Graphic editor framework system
US9582288B1 (en) Method for integrating software components into a spreadsheet application
US8386919B2 (en) System for displaying an annotated programming file
US20140115448A1 (en) Graphical data conversion/translation
JP2006107478A (ja) ワークフローを設計するための拡張可能フレームワーク
US9703443B2 (en) Method and system for creating a free-form visual user interface element
KR20050039551A (ko) 컴퓨터 플랫폼용 프로그래밍 인터페이스
US20130080879A1 (en) Methods and apparatus providing document elements formatting
US10984170B2 (en) Systems and/or methods for dynamic layout design
Lane User interface software structures
CN115691772A (zh) 运营可视化系统及相应计算机设备和存储介质
US20040068515A1 (en) System for integrating a plurality of database systems with a plurality of graphics-based document systems for connecting data therebetween to enable a user at a computer-based user interface to access these systems in a unified manner
JPH064280A (ja) ウィズィウィグ式エディターでオブジェクトをユーザ制御する機能を備えたグラフィカル・ユーザ・インターフェース
Plimmer et al. FreeForm: A tool for sketching form designs
Carr et al. Using interaction object graphs to specify graphical widgets
Liberty et al. Pro Windows 8.1 Development with XAML and C
JP2004537793A (ja) コントロール／ディスプレイ・ユニットのページ・ビルダ・ソフトウェア・ツール
CN117539575A (zh) 一种扩展展示资产视图的方法及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14908514

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15536757

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14908514

Country of ref document: EP

Kind code of ref document: A1