WO2016181368A1 - Método implementado por computador que expone aplicaciones tipo software a partir de especificaciones de diseño - Google Patents

Método implementado por computador que expone aplicaciones tipo software a partir de especificaciones de diseño Download PDF

Info

Publication number
WO2016181368A1
WO2016181368A1 PCT/IB2016/052806 IB2016052806W WO2016181368A1 WO 2016181368 A1 WO2016181368 A1 WO 2016181368A1 IB 2016052806 W IB2016052806 W IB 2016052806W WO 2016181368 A1 WO2016181368 A1 WO 2016181368A1
Authority
WO
WIPO (PCT)
Prior art keywords
models
visual
functional
components
software
Prior art date
Application number
PCT/IB2016/052806
Other languages
English (en)
French (fr)
Inventor
Nadia Analía HUEBRA
Mariano HUEBRA
Original Assignee
Huebra Nadia Analía
Huebra Mariano
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
Priority to BR112017024159-5A priority Critical patent/BR112017024159B1/pt
Priority to CN201680040249.2A priority patent/CN107851001B/zh
Priority to DK16792290.5T priority patent/DK3296866T3/da
Priority to CA2985954A priority patent/CA2985954A1/en
Priority to ES16792290T priority patent/ES2936090T3/es
Priority to MX2017014472A priority patent/MX2017014472A/es
Application filed by Huebra Nadia Analía, Huebra Mariano filed Critical Huebra Nadia Analía
Priority to JP2017559053A priority patent/JP6725535B2/ja
Priority to FIEP16792290.5T priority patent/FI3296866T3/fi
Priority to EP16792290.5A priority patent/EP3296866B1/en
Publication of WO2016181368A1 publication Critical patent/WO2016181368A1/es
Priority to IL255563A priority patent/IL255563B/en
Priority to CONC2017/0011542A priority patent/CO2017011542A2/es

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • 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/35—Creation or generation of source code model driven
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating

Definitions

  • the present invention is a system and method implemented by computer to automatically produce fully operable software-type applications from software design specifications.
  • the system allows class designs and screen designs (software design specifications) to be entered through an input / output device.
  • the processor applies two protocols to automatically create functional and visual models that are stored in a database memory. Then, it combines these models with graphic components, and automatically instance software-type applications, without compiling code generation, that are presented to the user to be operated and produce information as a result.
  • Architect defines the application's layer architecture taking into account the environment in which users will operate. Examples of architectures are SOA (services oriented architecture), Client Server, etc.
  • Database programmer builds the structures where the data that the user generates with the use of the application will be stored. There are tools called database engines of different technologies but currently working with common standards already established.
  • Application programmer writes the program code in a defined language (Java, C #, Vbnet, etc.) which is then compiled to obtain the object code that the computer will execute, providing the final application for user access.
  • a defined language Java, C #, Vbnet, etc.
  • User interface builder builds screens, visual components and graphic style templates that allow the computer program to present itself to the user in a more friendly and usable way.
  • Document US2006 / 0015839 discloses a system and a method generates compiling J2EE source code, from two possible sources, a database where all the parameters, tables and architecture of the system to be developed are specified in detail, that is to say that requires as input the detailed knowledge of the technical design. From this detailed definition builds an XML file that can be intervened by the user to adjust the design.
  • the final XML document is processed by a framework tool (framework) that automatically generates the J2EE code and the system architecture.
  • a forms tool automatically generates the user interface forms, also based on the structures defined in the source XML document.
  • a deployment tool of the system integrates the source database and the program code into a compilable structure thus achieving the resulting software application.
  • document US2006 / 00115839 generates compilable J2EE code and requires prior knowledge of the detailed computer architecture of the system to be developed and of the structure of the database, parameters object and field tables. It also requires a detailed knowledge of XML and in some cases the introduction of code directly, to execute some actions not performed by the configuration and editing programs presented.
  • document US2002 / 0077823 discloses a method and system for creating software applications that can operate on multiple client platforms, particularly including voice-interacting platforms, which implies a method for recognizing voice and interpreting it as input data.
  • a user of a mobile device with screen or keyboard limitations can receive information from a web page in audio format, and can interact with the web page using spoken words and phrases instead of written ones.
  • This document is limited to analyzing the spoken language to transform it into text, which is subsequently analyzed as any input data of an application. Unlike the present invention, said document is not intended to build a software model, nor its architecture and specification documents, automatically.
  • This document is supported by VoiceXML, the standard language for specifying voice components.
  • VoiceXML the standard language for specifying voice components.
  • To interpret the received commands it uses manually modifiable voice conversation templates, which are manual scripts with which the programmer must characterize the flow of the received commands and the responses that the application must provide.
  • To define those oral commands or phrases that the application can recognize when they are spoken by the user the developer must create a 'grammar' that is an explicit characterization of the expected spoken commands and serves to restrict the entries to those commands, to a number Small allowed word sequences.
  • the system proposed in this patent also includes a mechanism for the programmer to define "grammar in natural language", which is another facility to train the application with the type of expected answers, supported by templates, with their own phrases. Then it is necessary for the programmer to manually link the spoken components identified with application variables to be subsequently processed. Finally, to ensure that said spoken components are correctly identified, it is necessary to have a database of acoustic patterns and pronunciations.
  • This document provides a mechanism to receive voice commands and transform them into input variables of an application, and in an equivalent way extrapolate the reverse case to expose output variables as self-generated voice commands.
  • document US2012 / 0210296 discloses a method for creating BPM (Business Process Management) software applications. It uses pre-created software modules, which represent different process-related functionalities and are assembled to achieve the resulting software application, based on the selection a user makes, using predefined natural language words and associated with the modules in a goal. -data.
  • the user can choose the processes from a list of terms that is exposed and managed by the system linked to the existing and available modules.
  • the user can also implement functions that are not initially available in the list, but which he defines as a combination of existing modules and are added to the list of terms.
  • the present invention unlike US2012 / 0210296, does not use pre-created process functionalities, allows the use of free natural language and from it builds functionality by creating models that are instantiable as a software application, not only for solutions BPM, but for all types of solutions that can be described in natural language.
  • the present invention does not imply a method of compiling code generation, nor does it limit the results to a finite list of functionalities.
  • US2012 / 0210296 does not operate on the structure of language, but uses language to facilitate the selection of technical components of functional programs.
  • the present invention replaces the programming process with a machine that produces software automatically from a design of classes and screens that represent a case of software type application to be built, given as input of the process.
  • the present invention solves the central edges of the industry problem as follows:
  • the present invention produces the result automatically without generating program code, from the functional and visual models stored in a database memory, achieved by applying the protocols of the present invention to the designs of classes and screens provided as input by an user.
  • interpreters In the state of the art inventions that are interpreters are reported. In the software industry, interpreters differ from compilers or assemblers in that while they translate a program from its description into a programming language into the system machine code, the interpreters only perform the translation as necessary. , typically, instruction by instruction, and usually do not save the result of such translation as code.
  • the present invention is a model instantiator because it does not solve the software from the real-time compilation of each of the instructions in a program. In the present invention there is no need to program the program instructions, since they are replaced by models stored in a database which, when invoked by a model instantiating engine, by executing multiple program instructions compiled as part of the engine, create in memory the functionalities represented by the models.
  • the program flow is under the control of the user and the recurring invocation of some models with others, which is materialized from the instructions compiled in the engine.
  • the model instantiating engine of the present invention is not limiting the resolution of any particular case, it is capable of instantiating from any set of models referring to any functionality, the modification of said functionality is made by adding or removing models of the database, without the need to modify a compiled program. This is easier and faster than creating new programs for new functionalities and does not require program testing.
  • interpreters or compilers to solve the functionality, it is necessary to perform program testing with the impact that this activity generates in the iterations until a quality software is achieved. 4.
  • the user interface is the means by which the user can communicate with a machine, a computer or a computer, and comprises all the points of contact between the user and the equipment.
  • Software application it consists of two parts: the set of conceptual models that describe the business and determine the rules of functional behavior of the solution, and the set of visualization models that will make it possible for this functionality to materialize in a user interface , with which a user interacts.
  • Programming Computer programming should be understood as the process of coding, debugging and maintaining the source code of computer programs. The source code is written in a programming language. The purpose of programming is to create programs that exhibit desired behavior. The process of writing code frequently requires knowledge in several different areas, in addition to mastery of the language to be used, specialized algorithms and formal logic. Programming does not necessarily involve other tasks such as the analysis and design of the application (but the design of the code), although they are usually merged into the development of small applications.
  • Object Oriented Programming Paradigm It is the most commonly used programming paradigm.
  • the central nucleus of this paradigm is the union of data and processing in an entity called "object”, in turn related to other entities "object”.
  • object In turn related to other entities "object”.
  • Traditionally data and processing have been separated into different areas of software design and implementation. This caused that big developments had problems of reliability, maintenance, adaptation to the changes and scalability.
  • Metaclasses In the OO paradigm a metaclass is a class whose instances are classes. This concept is applied in the functional specification protocol of the present invention with some particularities.
  • Program code is the set of instructions and data to be processed by a computer, written in a language that the computer can interpret and execute.
  • the computer code can be binary or source code written in a higher level language.
  • Procedural code this is the name of the program code generated in the structured programming style. This style is based on structuring the code of a program in components, which are called procedures, sub-tunnels or functions.
  • interpreter In computer science, interpreter is a computer program capable of analyzing and executing other programs. Interpreters differ from compilers or assemblers in that while they translate a program from its description in a programming language to the system machine code, interpreters only perform translation as necessary, typically instruction by instruction. , and usually do not save the result of such translation.
  • Compiler A compiler is a computer program that translates a written program into a programming language into machine language. This translation process is known as compilation.
  • System in the present invention it should be understood as a set of electronic or opto-electronic elements that interact with each other to display, in a visual device, software type applications based on design specifications.
  • UI component they are portions of code (HTML or other) that are used to visualize the exposure of information on a device of the monitor type or similar. These components are known as third-party component sets and are used in the software industry as complements in the development of software applications. 5. Brief description of the invention
  • the present invention discloses a system and a method that, based on the entry of logical information structures in an electronic device consisting of memory and processor, automatically produces outputs in visual devices, which can be operated to create business process information. , replacing software applications that are normally developed through traditional programming known in the software industry.
  • the method implemented by computer interprets and exposes software-type applications based on design specifications that include the steps of: loading via an Input / Output Device 120, the functional specification protocol (PEF), the visual specification protocol (PEV) and the UI resources and store them in a database memory 130;
  • the present invention comprises a system that instantiates and exposes operational software type applications based on software design specifications, comprising:
  • an input / output device 120 configured as CDF Interface 121, CDV Interface 122, Application Interface 123 to enter the software design specifications and expose the resulting software applications;
  • a central processing unit (CPU) 110 connected to the input / output device 120 containing: a general memory 140 is in communication with the input / output device 120, which interacts with the processor 150, configured to volatilely store the functional, visual and UI components; Y
  • processor 150 configured to receive at least one software design specification through the Input / Output device 120; said processor configured as a model validator 151 to validate the software design specification against the protocols of Stage A, and identify the corresponding functional and visual models;
  • said processor configured as a UI 152 sorter to combine the resulting software type application, combining the functional, visual models and UI resources; Y,
  • said processor configured as a model instantiator 153 to expose the resulting software type application in Application Interface 123; Y
  • a database memory 130 connected to the CPU 110, in communication with the processor 150, configured to store statically, the Visual PEV specification protocol in a logical structure PEV 131, the PEF functional specification protocol in a logical structure PEF 132 and UI resources in a logical structure Resources UI 133 and also configured to dynamically store visual models in a logical structure MV Models 134, functional models in a logical structure MF 135 Models and objects in a logical structure Objects 136. 6. Brief description of the figures
  • FIG. 1. shows the structure of the system of the present invention.
  • FIG. 1A shows the PEF functional specification protocol.
  • FIG. IB shows the visual specification protocol PEV.
  • FIG. 1 C shows the logical structure of the database memory MF Models.
  • FIG. ID. shows the logical structure of the database memory MV models.
  • FIG. 1E. shows the logical structure of the database memory Objects.
  • FIG. 2. shows the steps of the method of the present invention.
  • FIG. 2A shows the detail of sub-stages of Stage A.
  • FIG. 2B shows the detail of stage B sub-stages.
  • FIG. 2B1. shows an example of identification of functional components and types 00.
  • FIG. 2 C shows the detail of sub-stages of Stage C.
  • FIG. 2C1. shows an example of application of the PEF protocol on a class diagram
  • FIG. 2C2. shows an example of application of the PEV protocol on a screen diagram
  • FIG. 2D shows the detail of sub-stages of Stage D
  • FIG. 3A shows an additional embodiment of the steps of the method of the present invention.
  • FIG. 3B shows an additional embodiment of the steps of the method of the present invention.
  • the present invention corresponds to a system and method implemented by computer that allow storing class models, which represent the detailed design of a software application in a database memory, and expose the resulting software type applications, through a instantiation process of these models.
  • a model is the representation of a functional or visual design component, embodied in a database memory.
  • a system like the one described in Figure 1 is used, to enter the class and screen designs in an Input / Output Device 120.
  • the entered designs are transferred to general memory and then processed by Processor 150.
  • the processor is configured to validate, combine and instantiate existing models in Database memories 134 and 135.
  • the results of each processing function are set forth. to screens on an Input / Output Device 120.
  • Input / Output Device 120 is the device through which software designs are entered. It allows a processor to present in structures (screens, projectors, televisions, printers, monitors, mobile devices, among others) structures where the user can enter class and screen designs (such as those shown in Figure 2B) , and display the resulting software applications, using the following configurations:
  • CDF 121 interface it is a visual structure that allows the user to enter the functional design components of a software application from a class diagram, which are stored in Database Memory 130, in the logical configuration Models MF 135.
  • CDV 122 interface it is a visual structure that allows the user to load the visual design components of a software application from a screen diagram associated with a class diagram, which will be stored in Database Memory 130, in the logical configuration MV models 134.
  • Application Interface 123 This interface presents the visual structures of the resulting software application to the user, once Processor 150 installed the functional and visual models available in Database Memory 130.
  • CPU 110 is the processing device of system 100. This device is structured to perform the functions of validation of functional and visual models against the respective protocol, the combination of UI resources and instantiation of the software application from the previous steps. It contains the general memory that allows the exchange between the functions and the rest of the system components.
  • General Memory 140 it is a volatile storage that is used as an exchange device between the input / output device, the database memory and the processor. Performs the following functions according to your configuration:
  • Matrix of Components UI 141 it is the configuration of the General Memory that allows access to the existing UI resources in Database Memory 133 and provides them to be exposed by Processor 150 as part of the resulting software type application .
  • Matrix of MF 142 it is the configuration of the General Memory that makes it possible to process the Functional Models resident in the Database Memory 135 through the Processor 150 configured as the Model Installer 153, in correlation with the protocols stored in the base memories of data 131 and 132.
  • Matrix of MV 143 it is the configuration of the General Memory that enables the processing of the Visual Models resident in the Database Memory 134 through the Processor 150 configured as the Model 153 Instancer, in correlation with the protocols stored in the base memories of data 131 and 132.
  • Processor 150 is the device in which the processing and exchange tasks are carried out. Performs the following functions according to your configuration:
  • Model Validator 151 it is the configuration of the Processor that is mainly responsible for validating the functional models entered by the user against the protocols resident in database memories 131 and 132, for once validated store them in database memories 134 and 135 respectively.
  • UI 152 Sorter it is the configuration of the Processor that is mainly responsible for combining the UI resources resident in the database memory 133 with the visual models stored in the database memory 134, prior to the instantiation process.
  • Model Installer 153 it is the configuration of the Processor that is mainly responsible for instantiating the functional models and visual models already combined with the UI resources, resident in the logical configurations of the general memory 142 and 143, to automatically expose the software application resulting in Application Interface 123.
  • Database Memory 130 is a permanent memory that houses the data loaded by the user and generated by Processor 150 in its different configurations. This memory contains two storage configurations, a static configuration and a dynamic configuration.
  • the static configuration stores those necessary fixed data that are loaded only once for processing that are not typical of "the case”.
  • the dynamic configuration stores the "case" data that is loaded by each case.
  • Static Memory
  • PEF 131 configuration of Database Memory 130 that contains the rules used by Processor 150 to validate and instantiate the functional models, defined and loaded in this memory from the Visual Specification Protocol (VEP).
  • VEP Visual Specification Protocol
  • PEV 132 configuration of Database Memory 130 that contains the rules used by Processor 150 to validate and instantiate the functional models, defined and loaded in this memory from the Functional Specification Protocol (PEF).
  • PEF Functional Specification Protocol
  • Resources UI 133 configuration of the Database Memory 130 containing software components that allow the Processor 150 to display the visual models in the Application Interface 123, through user-operable screens. Dynamic Memory:
  • MV 134 models configuration of the Database Memory 130 containing the functional models loaded by the user through the CDV Interface 122 and validated by the Processor 150 against the Visual Specification Protocol (VEP).
  • VEP Visual Specification Protocol
  • Logical structure RenderAction b Logical structure RenderActionEditor
  • Logical structure RenderAttribute b.
  • Logical structure RenderAttributeBase c.
  • Logical structure RenderDiagramView
  • Logical structure RenderBaseViewInheritance Models MF 135 configuration of the Database Memory 130 containing the functional models loaded by the user through the CDF Interface 121 and validated by the Processor 150 against the Functional Specification Protocol (PEF).
  • PEF Functional Specification Protocol
  • Logical structure MoreRelationClass iii. Objects 136 configuration of the Database Memory 130 containing the objects that the user generates, based on the models instantiated through the software type application, by Processor 150 configured as Model Installer 153.
  • This memory consists of the following logical structures associated with the concepts of the Functional Specification Protocol, Object-Class quadrant, shown in Figure
  • Configurations associated with the AttributeValue concept a. Logical structure MoreObject AttributeValue b. Logical structure MoreObj ect Attribute ValueFileExtended c. Logical structure MoreRelationObj ectMoreObj ect AttributeRelation 2. Configurations associated with the Object concept
  • the present invention corresponds to the system described and a method implemented in computer that interprets and exposes software-type applications from design specifications.
  • the method of the present invention comprises the following steps:
  • Step A Load through the Input / Output Device 120 the Functional Specification Protocol (PEF) in the logical structure PEF 132 and the Visual Specification Protocol (PEV) with its corresponding UI resources in the logical structures PEV 131 and UI Resources 133 of Database Report 130.
  • PEF Functional Specification Protocol
  • PEV Visual Specification Protocol
  • Stage B From a class design, identify and load the functional design components detailed in the class diagram through the CDF Interface 121 and temporarily store them in General Memory 140, in the MF 142 Matrix logical structure. From the design of screens, associated with the design of classes, identify and load the detailed visual design components through the CDV Interface 122 and temporarily store them in General Memory 140, in the logical structure Matrix of MV 143.
  • Stage C Validate the functional and visual models created in Stage B, using Processor 150 in your Validator configuration of
  • Stage D Recover from the Database Memory 130 the Functional Models and Visual Models created in Stage C, the UI Resources loaded in Stage A and store them in General Memory 140 using Processor 150 configured as a UI 152 Sorter To combine the UI Resources with the functional and visual components stored in General Memory 140 and instantiate the combined models and expose the screens of a software application in the Input / Output Device 120, Application Interface 123, using the Processor 150 configured as Model Instancer 153.
  • Stage A Load the protocols into memory
  • This protocol is the norm that defines the behavior that Processor 150 will give to the functional components that the user loads from a class design diagram, from now on PEF components, which determine the logical structuring for the operation of System 100
  • the Architecture that defines the functionality of this Protocol can be seen in Figure 1A.
  • the PEF protocol defines Metaclasses that refer to classes whose instances are classes, according to OO.
  • classes that are instances of a Metaclass are known as Models (Instance-Class quadrant of Figure 1A).
  • the protocol also defines Object classes (Object-Class quadrant of Figure 1A). These classes of ModelObject and ModelAttributeValue objects are the components that the 100 system uses to store instances of the Instance-Object Quadrant Models.
  • the PEF Components are those belonging to the Model-Class and Object-Class quadrants. Within the Model-Class quadrant, there are: ModelClass, ModelRelationClass, ModelAttribute, Formula, Domain and FxCall. They are a set of Metaclasses that give rise to the functional Models that are stored in Database Memory 130, in the logical structure Models MF 135. Within the Object-Class quadrant are: ModelObject and ModelAttributeValue. They are a set of Classes that give rise to System Objects that are stored in Database Memory 130, logical structure Objects 136. These PEF components are described below:
  • ModelClass It is a metaclass component because its instances are models. This component models design structures that are classes in design diagram 00. A ModelClass can inherit from another ModelClass.
  • ModelClass It is a metaclass component that inherits from ModelClass.
  • the functionality that extends to the ModelClass adds to this metaclass the ability to relate two ModelClass, which can be of two types: association or composition, as defined in OO.
  • ModelRelationClass relates to
  • This relationship could be used to represent the employee relationship that exists between a Physical person and a Legal Person, or it could also specialize the Person ModelClass in ModelClass Physical Person and Person Legal, to then create the ModelRelationClass specialty "is employed by" which would inherit from the ModelRelationClass "relates to”.
  • ModelClass It is a metaclass component that makes up ModelClass.
  • a ModelClass has a list of ModelAttributes.
  • ModelAttribute is the representation of the attributes that will contain the models created as instances of ModelClass.
  • a ModelAttribute defines, among other things, the type of data of the attribute to which it is giving rise.
  • the protocol defines three classifications of data types for ModelAttribute.
  • ModelAttribute Simple simple types are those whose value instance does not involve instances of ModelObject.
  • ModelAttribute RelationObject these are attributes that exist in a ModelClass product that it participates in a ModelRelationClass. This type of attribute in its value instance, depending on the relationship, can have one or more instances of relationship objects. This determines the cardinality of the relationship.
  • ModelAttribute ObjectReference this type of data is similar to the previous one, except that there is no product that the ModelClass to which it belongs participates in a relationship.
  • the attribute itself is who knows the nature of the objects that will make up the instance of value for it.
  • a formula is an independent model that has an expression and a set of parameters to receive information from the Model that invokes it.
  • the formula when executed, always returns a value to the Model that calls it.
  • the resulting value can be a single instance or multiple instances as part of multidimensional arrays and arrays.
  • the functional specification protocol defines the formula component that is used to solve the logic that functionally requires the execution of mathematical operations that use model instances as arguments.
  • the formula provides all mathematical operators for algebraic, matrix or set operations and allows the expression to be defined using the existing arguments as model instances of the Model-Instance quadrant of Figure 1A.
  • Metaclass Formula The functionality that implies a mathematical resolution is implemented by a Metaclass Formula. Unlike traditional software design, where this type of functionality is implemented as a method in a class of model 00.
  • the domain is a component that declares conditions that allow you to select a subset of model instances (operations between sets).
  • a model instance can be found in Database memory 130, in the logical structure Objects 136, already validated and structured by Processor 150 based on the PEF protocol, or in an external unstructured memory based on the protocol. Consequently, Domains are classified as follows:
  • Objects 136 obtaining collections of instances that can then be processed by other models through formulas.
  • This component is responsible for associating any instance of ModelAttribute with the instances of Formula, when the value of the ModelAttribute instance comes from a Formula. It is a model that solves the evaluation of a formula expression and returns a result to the model that invokes it, sending the mathematical operators and the arguments that will be operated to the Processor 150. FxCall hydrates the argument values obtained from the instances, so that the invoked Formula requests resolution from Processor 150.
  • ModelObject is the concrete class that materializes the instances of objects modeled with ModelClass.
  • ModelAttribute Val ⁇ es ModelAttribute Val ⁇ es.
  • ModelAttributeValue is the specific class whose instances represent the value of the attributes of a ModelObject instance.
  • Example: The Model Article that is an instance of ModelClass has a specific instance of ModelObject "milk", whose ModelAttributeValue for the ModelAttribute name is "milk”.
  • Sub-stage A2. Load Visual Specification Protocol (VEP)
  • This protocol defines, as shown in Figure IB, the behavior that Processor 150 will give to the visual components that the user loads from a screen design diagram, from now on PEV components. These components determine the visual structuring that will be presented in the Input / Output Device 120, Application Interface 123 for the operation of System 100.
  • the Architecture that defines the visual presentation of this Protocol can be seen in Figure IB.
  • the Visual PEV Specification protocol defines how PEF components and PEV components are linked.
  • a PEV component exposes the functionality of one or more PEF components through Input / Output Device 120, Application Interface 123.
  • This definition of the protocol determines that it is possible to produce outputs on visual devices, which can be operated to create business process information without making a particular layer architecture design for each case, because the architecture is embedded in the PEF components.
  • PEV components not linked to PEF components are created, for example: a visual model that contains a link to a web page.
  • the PEV Components are: Application, ActionLink, AbmViewModel, ListViewModel, TreeViewModel, ReportViewModel.
  • the Application component visually structures a software application.
  • the protocol defines the Application component as a Model to specify an application.
  • An application defines as more important aspect the Menu through which the user will have access to the exposed functionality.
  • a Menu is a collection of MenuGroup models and arborized Menultem models, where MenuGroups can contain other MenuGroup or Menultem.
  • the Menultem are those that link the action that will be carried out when the user clicks on it.
  • An item is associated with one of the following display models (ViewModel): AbmViewModel, ListViewModel, TreeViewModel.
  • the ViewModel component is what allows you to expose instances of ModelObject, on visual devices.
  • a ViewModel component is composed of ActionLink components that allow the ViewModel to execute actions according to the ModelClass model of which it is an instance and the ViewModel class to which it refers.
  • a PEV component defines a layout (visual layout structure or template) that will be displayed on the Input / Output Device 120, Application Interface 123, from ViewModel and its characteristics.
  • ViewModel AbmViewModel, ListViewModel and TreeViewModel with different features and layout specifications.
  • the protocol defines the AbmViewModel component as a Model to specify the rendering of a screen that allows to Register, Delete or Modify a ModelObject Object.
  • the rendering of a screen exposes all or some of the ModelAttributeValues of an instance of ModelObject, according to the corresponding ModelClass model.
  • the AbmViewModel component is composed of ActionLink components for being a ViewModel and extends its functionality through the components
  • ControlViewType and the special features of AbmViewModel.
  • ControlViewType components expose the ModelAttributeValues according to the data type of the attribute.
  • attribute types is set forth: TextEditor: exposes ModelAttributeValues of type text.
  • DateTimeEditor exposes ModelAttributeValues of type date.
  • ObjectReferenceComboEditor exposes ModelAttributeValues of ModelObjects selector type.
  • ObjectReferenceListEditor exposes ModelAttributeValues of ModelObjects selector type.
  • the ActionLink components that make up the AbmViewModel are:
  • Save and New Save the ModelObject instance and create a new instance for the user to complete the values of their attributes, exposing it in the visual structure of the AbmViewModel.
  • actions are added that invoke other ViewModel.
  • AttributeRenderlnfo This model is used to indicate the rendering particularities of a control that represents the value of a certain attribute of a ModelObject instance.
  • ControlTemplate control selector to render a ModelAttribute.
  • ControlTemplate is the concept that allows to indicate with which of these possible options the attribute will be effectively rendered.
  • Container within AbmViewModel there is a container structure in order to organize the controls in a visual device. It is known as controls to each of the components that visually exposes an attribute. This container structure is tree-lined, that is, a container can include others. • ColumnViewModel: inside the containers, the controls are organized in columns and these internally have an order for the controls they contain.
  • the protocol defines the ListViewModel component as a Model to specify the rendering of a screen that allows you to list collections of ModelObject instances.
  • the rendering of this screen exposes the ModelAttributeValues that said ModelObject has according to the ModelClass model of which it is an instance, for a collection of ModelObject instances that are shown in a table where each ModelAttribute Valué occupies a cell, where the row corresponds to the instance and the column to the ModelAttribute.
  • the ListViewModel component is composed of ActionLink components as a ViewModel and extends its functionality through the SearchViewModel, ColumnViewModel, ObiectReferenceListGridEditor and the special features of the ListViewModel.
  • the ActionLink components that make up the ListViewModel are: New; Remove; Edit; To print; Run Formula
  • NewMDestino invokes the creation of a new ModelObject of the related model as the destination of the relationship.
  • NewMDestino YAsociar invokes the creation of a new ModelObject of the related model as the destination of the relationship, and materializes the relationship with the ModelObject that owns the relationship attribute.
  • RemoveMDestino in a relationship instance, delete the related ModelObject, as well as the relationship instance.
  • Herarchical view refers to the hierarchical structure representation of the graph of related objects using ModelRelationClass models.
  • InLine Edition support for modifying the attributes of an object on the same line in the list.
  • the protocol defines the TreeViewModel component as a Model to specify the rendering of a related ModelObjects tree using RelationObjects.
  • the rendering of this screen consists of the exposure of all or some of the ModelAttribute Values that said RelationObjects invokes from the ModelClass it relates.
  • a node in a tree, represented in a TreeNodeModel component then represents an instance of ModelObject and an instance of RelationObject, which is the relationship between the node in question and its parent node. Therefore, the nodes of the first level of the tree will not be represented by any instance of RelationObject since they do not relate to any parent node.
  • the TreeViewModel component is composed of ActionLink components as a ViewModel and extends its functionality through the special features of the TreeViewModel.
  • the ActionLink components that make up the TreeViewModel are:
  • Delete Deletes the instance of RelationObject that links the current node with its parent node.
  • NewMDestino invokes the creation of a new ModelObject instance that corresponds to the destination of the relationship for the corresponding ModelRelationClass model according to the tree display model for the node where the action is being invoked.
  • NewMDestinoYAsociar idem NuevoMDestino, only then create the RelationObject instance to link the new ModelObject with the ModelObject represented by the node on which the action was invoked.
  • RemoveMDestino removes the ModelObject instance represented by the current node.
  • EditMdestino edit the ModelObject instance represented by the current node.
  • ⁇ LoadOnDemand indicates if the tree should discover and load its nodes as the user interacts expanding the tree.
  • EditOnClick indicates that the edition of the object represented by a node must be invoked when the user clicks on it.
  • the ActionLink components define the actions that are available in the ViewModel to execute on ModelObject instances.
  • Each subclass of ViewModel has a different ActionLinks list, in relation to the functionality it exposes on the visual device.
  • a ReportViewModel contains the necessary specification so that Processor 150 configured as a Model Installer 153, can interact with any report delivery service, such as Reporting Services.
  • ModelObject instance repository is compatible with the query methods that these services implement, so that by using the visualization components that accompany these technologies, reports can be generated and integrated in a simple and simple way. with all the necessary reporting features.
  • Sub-stage A3. Load UI resources
  • the PEV Visual Specification Protocol is designed so that Processor 150 can combine visual components with UI resources.
  • the objective of this combination is that the Processor can quickly make these components available for modeling the User interface. This is achieved through the ControlViewType concept of the PEV Protocol loaded in Sub-stage A2, which is directly linked to a UI resource and allows from a ViewModel to indicate with which UI resource a certain portion of the user interface will be presented in the Device. Input / Output 120, Application Interface 123.
  • UI Resources are partial portions declared in some UI language (for example, HTML5) and whose appearance can be adjusted with cascading style sheets (for example, css). These resources are stored in Database Memory 130, logical structure UI Resources 133. Then, when Processor 150, configured as UI Sorter 152 executes its functions, links these UI Resources with an instance of the ControlViewType logical structure, resident in Database Memory 130, logical structure Models MV 134, leaving these conjugate models available for use in the software application.
  • UI Sorter 152 executes its functions, links these UI Resources with an instance of the ControlViewType logical structure, resident in Database Memory 130, logical structure Models MV 134, leaving these conjugate models available for use in the software application.
  • Design documents, as shown in Figure 2B, refer particularly to two types of diagrams known to define the functionality and visual structures that define a software type application:
  • Sub-stage Bl Identify the components of functional design
  • the method refers to a mathematical function equivalent to the set logic, which corresponds to a PEF Domain component, it may be external if it refers to data external to the system.
  • the user through the Input / Output Device 120, CD 121 Interface, loads the identified PEF components and the Processor 150, configured as Model 151 Validator, stores them in General Memory 140, MF Matrix logical structure 142. Sub-stage B2. Identify the components of visual design
  • the Visual Specification protocol loaded in Stage A is applied to identify the ModelClass type concepts and create the visual models defined by the PEV protocol (Application, AbmViewModel, ListViewModel, TreeViewModel), as well :
  • ModelRelationClass For each ModelRelationClass, it is determined that the following ViewModel should be created: ListViewModel, TreeViewModel c. To expose all PEF components, it is determined that an Application Model, a MenuViewModel model, a MenuGroup model and an ItemGroup model must be created for each ViewModel created in the previous steps.
  • the system 100 allows editing the visual models created to achieve the greatest similarity with the screen designs corresponding to the "case" available as input of the process.
  • the user through the Input / Output Device 120, CDV Interface 122, loads the identified PEV components and the Processor 150, configured as Model Validator 151, stores them in General Memory 140, logical structure MV Matrix 143.
  • Stage B Generate CF and CD from natural language.
  • this Stage B ' is a substitute for Stage B, as shown in Figure 3A.
  • the user generates CF and CD from natural language, for example, using as described in patent application No. 15 / 141,748, entitled “PROCESS AND SYSTEM FOR GENERATING FUNCTIONAL ARCHITECTURE DOCUMENTS AND SPECIFICATION DOCUMENTS OF ANALYSIS AND DESIGN OF AUTOMATIC SOFTWARE FROM NATURAL LANGUAGE ", incorporated as a reference in its entirety.
  • Processor 150 connects to the Database Memory, logical structure 172 identified in patent application No. 15 / 141,748, obtains the functional components of "the case” and stores them in the Matrix of MF 142.
  • Processor 150 runs through the list of functional components obtained in Sub-stage B 'l and applies the Visual Specification Protocol PEV defined in Sub-stage A2. Obtain one or more visual components from each functional component, as shown in Fig 2C2 and store them in the MV Matrix 143. Stage C. Create functional and visual models
  • the Processor 150 takes from the General Memory 140, logical structure Matrix of MF 142 the PEF components created in the Sub-stage Bl and executes the following sub-stages: Sub-stage Cl. Identify the PEF components and create the Models
  • Processor 150 identifies the PEF components available in General Memory 140, created in Sub-stage B 1 and makes the specification of PEF concepts according to the protocol loaded in Sub-stage Al. Then it creates Functional Models, which specify the functionality that Processor 150 will use to instantiate the software application for "the case.” Processor 150 performs the following steps: 1. Scroll through the list to identify which PEF Concept should be created based on the Specification Protocol for each Type 00 of the design components as determined in Sub-stage B l.
  • Processor 150 stores the Functional Models created in Database Memory 130, logical structure Models MF 135.
  • Processor 150 identifies the PEV components available in General Memory 140, created in Sub-stage B2 and makes the specification of PEV concepts according to the protocol loaded in Sub-stage A2. Then create the Visual Models, which specify the functionality that the Processor 150 will use to expose the software-type application for "the case" by presenting information structures in the Input / Output Device 120, Application Interface 123.
  • the Processor 150 leads to perform the following steps: 1. Scroll through the list of PEF Concept created in Sub-stage B2 based on what is determined in the visual specification protocol (VEP).
  • VEP visual specification protocol
  • Visual models are edited without modifying the link between the visual model and the functional model.
  • dimensions and locations of the components in the layout of the Input / Output 120 device are changed without altering the link between the visual Model and the respective functional model, as established by the protocols loaded in Stage A.
  • Processor 150 stores visual models in Database Memory 130, logical structure MV Models 134.
  • Stage C Incorporate functional and visual models.
  • this Stage C is a substitute for Stage C, as shown in Figure 3B.
  • Stage D Read and instantiate functional and visual models as an operable software type application
  • a conjugate model is a model that combines a Functional model MF (defined based on the PEF protocol) with a Visual MV model (defined based on the PEV protocol), therefore, represents the functionality and definition of the visual models associated with some UI Resource 133, combined in a single model that It is presented in Application Interface 123, as a software type application accessible and operable by a user.
  • Processor 150 configured as Model Installer 153, is presented by means of an interpretation and delivery service of software applications.
  • the first thing he receives is an application interface with which he can begin to interact.
  • the interpretation in the present invention, is a process that is executed as a service and by reading conjugated models (MF Models + MV Models + UI Resources), resolves against the user interaction, the actions that the user is executing on a software type application exposed in Input / Output Device 120, Application Interface 123.
  • conjugated models MF Models + MV Models + UI Resources
  • Processor 150 configured as Model 153 Instancer, performs the following sub-stages:
  • Sub-stage DI. Read and interpret MV visual models
  • the models are structures that respect the protocols loaded in Stage A, stored in Database Memory 130, logical structures PEF 132 and PEV 131 respectively.
  • Processor 150 configured as Model 153 Instancer, reads the visual models of Database Memory 130, logical structure MV 134 Models that are stored and validated according to the definitions of the PEV protocol loaded in Sub-stage A2 .
  • the system 100 builds a layout type structure that organizes the layout of the ModelObject and ActionLinks instances on the layout and stores that structure in General Memory 140, logical structure of Component Matrix UI 141.
  • Sub-stage D2. Read and interpret the MF functional models
  • Processor 150 in its role as Model Installer 153, reads the functional models of Database Memory 130, logical structure Models MF 135 that are stored and validated according to the definitions of the PEF protocol loaded in the Sub-stage Al.
  • Processor 150 of system 100 processes three types of functional models: calculation models, persisted data models and interactive data models:
  • Calculation models processes the expressions of the formula classes found in the MF repository by transporting the expression to the service that resolves it by returning the result as an instance of ModelAttribute through FxCall.
  • Persistent data models processes the access expression to the Database Memory 130 provided by the Domain classes, which act on the Object 136 repository, executing the one found in the MF repository.
  • Interactive data models processes the data that the user enters in the Application Interface 123, interactively through the ActionLinks of each ViewModel with which the user interacts.
  • Processor 150 of system 100 interprets and instantiates a business-type structure and stores it in General Memory 140, logical structure of Component Matrix UI 141, associated with the visual structure created in Sub-stage DI, where links between visual models and instantiated functional models respond to the logic of the protocols loaded in Stage A.
  • the UI Resources are the software components pre-hosted in the Database Memory 130, logical structure UI Resources, which when executed associated with a visual model allow the generation of the screen drawing in the Application Interface 123. They are the Processing definitions of visual models. Different sets of UI resources are marketed in the Software industry, which can be incorporated into the system as indicated in Sub-stage A3, to offer different display modes for the resulting software-like applications.
  • system 100 selects a component of Matrix MF 142, its corresponding component of Matrix MV 143 and a Resource UI 133 compatible with the type of MV selected.
  • Processor 150 configured as a UI Compactor 152, combines the selected components by providing as an argument of the functions of the UI Resource, the parts of the conjugate model (Model MF + Associated Model MV) that the component requires to function.
  • the Processor 150 exposes a conjugate component in the Input / Output Device 120, repeating the procedure for each of the components created for "the case".
  • An exposed component constitutes an operational screen of a software-type application that presents action buttons, boxes where the User can enter data and other functionalities that are encompassed by the conjugate model.
  • a Model Model Class that has a ModelAttribute name, is exposed in an AbmViewModel that defines a screen with a TextEditor to edit the MOdelAttribute Name instance. This screen defines a function for each ActionLink of the Model View.
  • the ViewModel specifies that it will use the UI Component called "3d TextBox control" to display the name, whereby the Processor 150 combines the mentioned component that is stored in the UI Resources Memory 133 to complete the conjugate model. This collation allows the name text box to be displayed on the Input / Output 120 device with a colored 3d appearance, depending on the characteristics of the "TextBox 3d control” component.
  • the TextEditor type component is combined with the 3D textbox UI Resource and is associated with the ModelAttribute functionality to make the Processor 150 install in the Application Interface 123 a box where a user can enter a text, which has a three-dimensional appearance and support the reception of the text and then persist the data in the Database Memory 130, logical structure Objects 136.
  • Processor 150 configured as Model Installer 153, obtains instances of the ModelObject associated with the conjugate model (ModelClass-ViewModel-Resource UI) that is exposed to the user.
  • the AttributeValues corresponding to the selected instance are sent to the Input / Output device 120, Application Interface 123 according to the layout defined in the conjugate model and thus an operable software type application screen is presented to the user.
  • Sub-stage D5. Receive and resolve user requests
  • Processor 150 configured as Model Installer 153, executes the function corresponding to the functional model that forms the conjugate model on which the user is operating, through an ActionLink or any of the existing functionalities, as defined in the PEF protocol loaded in Sub-stage Al.
  • Processor 150 configured as Model Installer 153, an instance update of the conjugate model that is exposed in the Input / Output device 120, Application Interface 123 occurs. Processor 150 takes the instance new and update the Input / Output 120 device with the changes produced.
  • This stage is considered the initialization of the system, given that the protocols are loaded only once and eventually UI Resources are added to the system.
  • Class 1 Attribute attribute Class2_Rel 1
  • ModelAttribute attribute Class2_Rel 1 ModelAttribute attribute Class2_Rel 1
  • FxCallReport Data_Rep
  • FxCallReport Data_Rep
  • Relationship 1 Relationship Relationship 1 ass Model Relationship 1
  • Class 1 ModelAttribute List Class 1
  • Class 3 Formula ABM View Model ABM Class 3
  • Class 3 Formula List View Model List Class 3
  • the Processor 150 configured as Model Validator 151, takes the list of functional components resident in General Memory 140, logical structure Matrix of MF 142 and exposes it in the Input / Output device 120, CDV interface 122, as it is shown in column 1 and 2 (Functional component, PEF Concept) of Table 2.
  • Processor 150 reads the PEV visual specification protocol loaded in Sub-stage A2, and completes columns 3 and 4 (PEF Concept, Visual Model a create) and update General Memory 140, logical structure Matrix of MV 143 with this data.
  • Stage C Create functional and visual models
  • Processor 150 identifies the PEF components available in General Memory 140, MF Matrix 142, corresponding to columns 3 and 4 (PEF Concept and Model Name to be created) in Table 1, and makes the specification of PEF concepts according to the protocol loaded in Sub-stage Al. Go through the list, identify the PEF concept, and create the components defined for mathematics in the methods that require it according to the definition of the PEF protocol. This specification implies identifying the PEF concept and its corresponding logical structures in Database Memory 130, to create the functional models and store them in the logical structure MF 135 Models. In the present example, the following list of functional models is obtained as a result of this stage, stored in Database Memory 130, logical structure Models MF 135:
  • ModelRelationClass Model Relationship 1 The technical structure for creating functional models can be seen in Figure 2C1, where each component of Table 3 is displayed, related to the concept of the PEF Protocol that corresponds to it.
  • Class 1 1 List View Model j List Class 1
  • Class 2 I List View Model j List Class 2
  • Class 3 1 ABM View Model and ABM Class 3
  • Class 3 1 List View Model and List Class 3
  • Class 4 1 ABM View Model and ABM Class 4
  • Class 4 1 List View Model j List Class 4
  • Class 5 Class 5
  • Sub-stage DI. Read and interpret MV visual models
  • Sub-stage DI of the invention is executed, starting from the list in the example of Table 4.
  • Sub-stage D2. Read and interpret the MF functional models
  • Sub-stage D2 of the invention is executed, starting from the list in the example of Table 3.
  • Sub-stage D5. Receive and resolve user requests

Abstract

El presente invento es un sistema y un método que, a partir de la entrada de estructuras lógicas de información en un dispositivo electrónico compuesto por memoria y procesador, produce de manera automática salidas en dispositivos visuales, que pueden ser operados para crear información de procesos de negocio, reemplazando a las aplicaciones de software que normalmente son desarrolladas mediante la programación tradicional conocida en la industria del software. Dada la información correspondiente a la estructura lógica de un diseño de software, esta información se ingresa en la máquina, que la almacena en una memoria en forma de modelos. Dichos modelos son interpretados por el sistema 100 que produce de manera automática estructuras en dispositivos visuales que permiten reemplazar a un software. El invento es el proceso que utiliza el sistema 100 para ingresar, almacenar, interpretar y producir las estructuras visuales y de lógica estructural que reemplazan a un software.

Description

MÉTODO IMPLEMENTADO POR COMPUTADOR QUE EXPONE APLICACIONES TIPO SOFTWARE A PARTIR DE ESPECIFICACIONES DE
DISEÑO 1. Referencia cruzada a solicitudes relacionadas
Esta solicitud reivindica los beneficios de la fecha de presentación de la solicitud de patente provisional U.S. N° 62/161,216 titulada "Método implementado por computador que expone aplicaciones tipo software a partir de especificación de diseño", que fue presentada el 13 de mayo de 2015, por los mismos inventores de esta solicitud. El contenido de dicha solicitud provisional se incorpora a la presente invención en su totalidad como referencia como si se expusiera en el presente documento.
2. Campo de la invención
El presente invento es un sistema y un método implementado por computador para producir automáticamente aplicaciones de tipo software completamente operables a partir de especificaciones de diseño de software. El sistema permite ingresar diseños de clases y diseños de pantallas (especificaciones de diseño de software) a través de un dispositivo de entrada/salida. El procesador aplica dos protocolos para crear automáticamente modelos funcionales y visuales que se almacenan en una memoria de base de datos. Luego, combina estos modelos con componentes gráficos, e instancia automáticamente aplicaciones de tipo software, sin generación de código compilable, que se presentan al usuario para ser operadas y producir información como resultado.
3. Descripción del estado del arte La industria del software propone como mecanismo de construcción de soluciones una serie de actividades entre las cuales se encuentran, la construcción de una base de datos y la codificación de un programa de computadora, que funcionan en el marco de una arquitectura que permitirá al software resultante operar en entornos de múltiples usuarios.
Estas tareas son realizadas por personas capacitadas para comprender el diseño de un software y a partir de allí desarrollar el programa. La naturaleza de las tareas determina que la construcción de un software sea llevada a cabo por un equipo de trabajo donde se destacan los siguientes perfiles especializados:
Arquitecto: define la arquitectura de capas de la aplicación teniendo en cuenta el entorno en el que operarán los usuarios. Ejemplos de arquitecturas son SOA (services oriented arquitectura), Cliente Servidor, etc.
- Programador de la base de datos: construye las estructuras donde serán almacenados los datos que el usuario genere con el uso de la aplicación. Existen herramientas llamadas motores de bases de datos de diferentes tecnologías pero que actualmente trabajan con estándares comunes ya establecidos.
Programador de la aplicación: escribe el código de programa en un lenguaje definido (Java, C#, Vbnet, etc) que luego es compilado para obtener el código objeto que la computadora va a ejecutar, proporcionando la aplicación final de acceso al usuario.
Constructor de la interface de usuario: construye pantallas, componentes visuales y plantillas de estilos gráficos que permiten al programa de computación presentarse ante el usuario de manera más amigable y usable.
Para llevar a cabo la construcción de un software, es necesario contar con un equipo profesional como el mencionado, ya que normalmente quien necesita hacer un software no tiene esta formación que demanda de varios años de estudio.
El problema que se presenta en la industria del software tiene varias aristas, a saber: i. La demanda de soluciones crece a nivel mundial con una velocidad mayor a la velocidad de formación de profesionales para esta disciplina. Así se puede observar una gran demanda de desarrollo no abastecida.
ii. El proceso de construcción del software es costoso en tiempo y dinero, lo cual implica a los sectores demandantes no poder cubrir en su totalidad las necesidades de manera oportuna y conveniente. iii. La multiplicidad de tecnologías (bases de datos, lenguajes de programación, arquitecturas, interfaces de usuario) que evolucionan a gran velocidad, generan en las aplicaciones ya desarrolladas un problema de obsolescencia tecnológica. Esto significa que cuando un software se encuentra operativo, normalmente aparecen nuevas tecnologías que los profesionales de la industria adoptan y la conversión de dicho software demanda un esfuerzo de re-ingeniería tan importante como su primera construcción.
iv. El cambio constante en las reglas de funcionamiento de los negocios en una economía global de interacción vertiginosa, demanda de adaptaciones y mejoras en las aplicaciones de software, que se vuelven inviables en muchas oportunidades debido la conjugación de los factores costo en tiempo/dinero y obsolescencia tecnológica. Por esta razón las aplicaciones de software no ofrecen evolución flexible y oportuna.
El arte previo divulga una pluralidad de sistemas y métodos para la generación automática de aplicaciones de software para reducir en tiempo y costos los ciclos de desarrollo de aplicaciones de software. El documento US2006/0015839 divulga un sistema y un método genera código fuente J2EE compilable, a partir de dos posibles fuentes, una base de datos en donde se especifican en detalle todos los parámetros, tablas y arquitectura del sistema a ser desarrollado, es decir que requiere como input el conocimiento detallado del diseño técnico. A partir de esta definición detallada construye un archivo XML que puede ser intervenido por el usuario para ajustar el diseño. El documento XML final es procesado por una herramienta marco (framework) que automáticamente genera el código J2EE y la arquitectura del sistema. Una herramienta de formas genera automáticamente las formas de interfaz de usuario, también basado en las estructuras definidas en el documento XML fuente. Una herramienta de despliegue (deployment) del sistema integra la base de datos fuente y el código del programa en una estructura compilable logrando así la aplicación de software resultante. A diferencia del presente invento, el documento US2006/00115839 genera código J2EE compilable y requiere de un conocimiento previo de la arquitectura informática detallada del sistema a ser desarrollado y de la estructura de la base de datos, parámetros objeto y de campo de tablas. También requiere de un conocimiento detallado de XML y en algunos casos de la introducción de código directamente, para ejecutar algunas acciones no realizadas por los programas de configuración y edición presentados. Así mismo, el documento US2002/0077823 divulga un método y un sistema para crear aplicaciones de software que puedan operar en múltiples plataformas cliente, particularmente incluyendo plataformas interactuadas mediante voz, lo que implica un método para reconocer voz e interpretarlo como datos de entrada. Por ejemplo, un usuario de un dispositivo móvil con limitaciones de pantalla o teclado puede recibir información de una página web en formato de audio, y de forma recíproca puede interactuar con la página web utilizando palabras y frases habladas en lugar de escritas. Dicho documento se limita a analizar el lenguaje hablado para transformarlo en texto, el cual es posteriormente analizado como cualquier dato de entrada de una aplicación. A diferencia de la presente invención, dicho documento no pretende construir un modelo de software, ni sus documentos de arquitectura y especificación, automáticamente. Dicho documento se apoya en VoiceXML, el lenguaje estándar de especificación de componentes de voz. Para interpretar los comandos recibidos, utiliza plantillas de conversación de voz modificables manualmente, que son guiones manuales con los cuales el programador debe caracterizar el flujo de los comandos recibidos y las respuestas que debe brindar la aplicación. Para definir aquellos comandos o frases orales que la aplicación puede reconocer cuando son hablados por el usuario, el desarrollador debe crear una 'gramática' que es una caracterización explícita de los comandos hablados esperados y sirve para restringir las entradas a esos comandos, a un número pequeño de secuencias permitidas de palabras.
El sistema planteado en esta patente también incluye un mecanismo para que el programador defina "gramáticas en lenguaje natural", que constituyen una facilidad más para entrenar la aplicación con el tipo de respuestas esperadas, apoyado en plantillas, con sus propias frases. Luego es necesario que el programador manualmente vincule los componentes hablados identificados con variables de la aplicación para ser subsiguientemente procesados. Finalmente, para asegurar que dichos componentes hablados son correctamente identificados, es necesario contar con una base de datos de patrones acústicos y pronunciaciones. Dicho documento proporciona un mecanismo para recibir comandos de voz y transformarlos en variables de entrada de una aplicación, y de una manera equivalente extrapolar el caso inverso para exponer variables de salida como comandos de voz autogenerados. Para ello, se apoya en la especificación de "gramáticas de lenguaje natural" y "modelos de lenguaje", pero, a diferencia del presente invento, no divulga la capacidad de analizar directamente el lenguaje natural de entrada, de manera libre y exhaustiva, para inferir automáticamente modelos de software, componentes funcionales o de diseño de una aplicación. Así mismo, el documento US2012/0210296 divulga un método para crear aplicaciones de software tipo BPM (Business Process Management). Utiliza módulos de software pre-creados, que representan diferentes funcionalidades referidas a procesos y se ensamblan para lograr la aplicación de software resultante, a partir de la selección que un usuario hace, utilizando palabras del lenguaje natural predefinidas y asociadas a los módulos en una meta-data. El usuario puede escoger los procesos de una lista de términos que es expuesta y manejada por el sistema vinculada a los módulos existentes y disponibles. El usuario puede también implementar funciones que no estén en principio disponibles en la lista, pero que define como combinación de módulos existentes y se agregan a la lista de términos.
El presente invento, a diferencia de la patente US2012/0210296, no utiliza funcionalidades de procesos pre-creadas, permite el uso del lenguaje natural libre y a partir de él construye la funcionalidad creando modelos que son instanciables como aplicación de software, no solo para soluciones BPM, sino para todo tipo de solución que pueda describirse en lenguaje natural. El presente invento no implica un método de generación de código compilable, ni limita los resultados a una lista finita de funcionalidades. La patente US2012/0210296 no opera sobre la estructura del lenguaje, sino que utiliza el lenguaje para facilitar al usuario la selección de componentes técnicos de programas funcionales.
De acuerdo con lo anterior, y a pesar de que existe arte previo que automatiza actividades de desarrollo, aún existe la necesidad de la intervención de profesionales expertos en el ciclo de desarrollo, en especial en la depuración de errores. De esta manera, el presente invento reemplaza el proceso de programación por una máquina que produce software de manera automática a partir de un diseño de clases y pantallas que representan un caso de aplicación tipo software a construir, dado como input del proceso. La presente invención resuelve las aristas centrales del problema de la industria de la siguiente manera:
permite crear aplicaciones de software sin la necesidad de realizar las tareas tradicionales de la industria, es decir, la construcción de una base de datos, programación del código compilable, construcción de una arquitectura específica, que actualmente se realizan de manera manual o automatizada en aquellas herramientas que generan código de programa a partir de especificaciones. El presente invento produce el resultado de manera automática sin generar código de programa, a partir de los modelos funcionales y visuales almacenados en una memoria de base de datos, logrados aplicando los protocolos del presente invento a los diseños de clases y pantallas provistos como input por un usuario.
reduce el alto costo en tiempo y dinero, obsolescencia tecnológica, desabastecimiento de la demanda, permite que el producto evolucione de manera flexible y oportuna.
En el estado del arte se reportan invenciones que son intérpretes. En la industria del software, los intérpretes se diferencian de los compiladores o de los ensambladores en que mientras estos traducen un programa desde su descripción en un lenguaje de programación al código de máquina del sistema, los intérpretes sólo realizan la traducción a medida que sea necesaria, típicamente, instrucción por instrucción, y normalmente no guardan el resultado de dicha traducción como código. La presente invención es un instanciador de modelos porque no resuelve el software a partir de la compilación en tiempo real de cada una de las instrucciones de un programa. En la presente invención no existe la necesidad de programar las instrucciones del programa, ya que son reemplazadas por modelos almacenados en una base de datos que, al ser invocados por un motor instanciador de modelos, mediante la ejecución de múltiples instrucciones de programa compiladas como parte del motor, crean en memoria las funcionalidades representadas por los modelos. El flujo del programa está bajo el control del usuario y la invocación recurrente de unos modelos con otros, que se materializa a partir de las instrucciones compiladas en el motor. Dado que el motor instanciador de modelos del presente invento no es limitativo a la resolución de algún caso en particular, éste es capaz de instanciar a partir de cualquier conjunto de modelos referidos a cualquier funcionalidad, la modificación de dicha funcionalidad se realiza agregando o quitando modelos de la base datos, sin necesidad de modificar un programa compilado. Esto es más fácil y más rápido que crear nuevos programas para nuevas funcionalidades y no requiere de testing de programa. Al utilizar intérpretes o compiladores para resolver la funcionalidad se hace necesario realizar testing de programa con el impacto que esta actividad genera en las iteraciones hasta lograr un software de calidad. 4. Glosario
Con el ánimo de facilitar la interpretación de los conceptos divulgados en esta patente, a continuación, se lista una serie de expresiones que indicarán el alcance de algunos conceptos utilizados en la presente invención.
Usuario Final: Es el actor que utilizará finalmente la solución a través de la interfaz de usuario proporcionada.
Interfaz de usuario: La interfaz de usuario es el medio con que el usuario puede comunicarse con una máquina, un equipo o una computadora, y comprende todos los puntos de contacto entre el usuario y el equipo.
Aplicación de software: se compone de dos partes: el conjunto de modelos conceptuales que describen el negocio y determinan las reglas de comportamiento funcional de la solución, y el conjunto de modelos de visualización que harán posible que esta funcionalidad se materialice en una interfaz de usuario, con la que un usuario interactúe. Programación: La programación informática, se deberá entender como el proceso de codificar, depurar y mantener el código fuente de programas computacionales. El código fuente es escrito en un lenguaje de programación. El propósito de la programación es crear programas que exhiban un comportamiento deseado. El proceso de escribir código requiere frecuentemente conocimientos en varias áreas distintas, además del dominio del lenguaje a utilizar, algoritmos especializados y lógica formal. Programar no involucra necesariamente otras tareas tales como el análisis y diseño de la aplicación (pero sí el diseño del código), aunque sí suelen estar fusionadas en el desarrollo de pequeñas aplicaciones.
Paradigma de Programación Orientado a Objetos (OO): Es el paradigma de programación actualmente más usado. El núcleo central de este paradigma es la unión de datos y procesamiento en una entidad llamada "objeto", relacionable a su vez con otras entidades "objeto". Tradicionalmente datos y procesamiento se han separado en áreas diferente del diseño y la implementación de software. Esto provocó que grandes desarrollos tuvieran problemas de fiabilidad, mantenimiento, adaptación a los cambios y escalabilidad. Con la orientación a objetos y características como el encapsulado, polimorfismo o la herencia se permitió un avance significativo en el desarrollo de software a cualquier escala de producción.
Metaclases: En el paradigma de OO una metaclase es una clase cuyas instancias son clases. Este concepto se aplica en el protocolo de especificación funcional de la presente invención con algunas particularidades.
Código de programa: es el conjunto de instrucciones y datos a ser procesados por un computador, escrito en un lenguaje que el computador puede interpretar y ejecutar. El código en computación puede ser binario o código fuente escrito en un lenguaje de nivel superior.
Código procedural: se llama así al código de programa generado en el estilo de programación estructurada. Este estilo está basado en estructurar el código de un programa en componentes, que reciben el nombre de procedimientos, subru tinas o funciones.
Intérprete: En ciencias de la computación, intérprete es un programa informático capaz de analizar y ejecutar otros programas. Los intérpretes se diferencian de los compiladores o de los ensambladores en que mientras estos traducen un programa desde su descripción en un lenguaje de programación al código de máquina del sistema, los intérpretes sólo realizan la traducción a medida que sea necesaria, típicamente, instrucción por instrucción, y normalmente no guardan el resultado de dicha traducción.
Compilador: Un compilador es un programa informático que traduce un programa escrito en un lenguaje de programación a lenguaje de máquina. Este proceso de traducción se conoce como compilación. Sistema: en el presente invento se debe entender como un conjunto de elementos electrónicos u opto-electrónicos que interactúan entre sí para exponer en un dispositivo visual, aplicaciones tipo software a partir de especificaciones de diseño.
Componente de UI: son porciones de código (HTML u otro) que se utilizan para dar forma visual a la exposición de información en un dispositivo de tipo monitor o similar. A estos componentes se los conoce como sets de componentes de terceros y son utilizados en la industria del software como complementos en el desarrollo de aplicaciones de software. 5. Breve descripción del invento
El presente invento divulga un sistema y un método que a partir de la entrada de estructuras lógicas de información en un dispositivo electrónico compuesto por memoria y procesador, produce de manera automática salidas en dispositivos visuales, que pueden ser operados para crear información de procesos de negocio, reemplazando a las aplicaciones de software que normalmente son desarrolladas mediante la programación tradicional conocida en la industria del software. El método implementado por computador interpreta y expone aplicaciones tipo software a partir de especificaciones de diseño que comprende las etapas de: cargar mediante un Dispositivo de Entrada/Salida 120, el protocolo de especificación funcional (PEF), el protocolo de especificación visual (PEV) y los recursos UI y almacenarlos en una memoria de base de datos 130;
identificar, validar contra los protocolos de la etapa a y almacenar componentes de diseño funcional y componentes de diseño visual a partir de especificaciones de diseño de software en la memoria de base de datos 140;
crear automáticamente modelos funcionales y modelos visuales a partir de los componentes de diseño funcional y visual identificados en la etapa b, y almacenar dichos modelos en la memoria de base de datos 130, estructuras lógicas Modelos MF 135 y Modelos MV 134 respectivamente; y
leer, instanciar y exponer automáticamente, en el Dispositivo de Entrada/Salida 120, Interface de Aplicación 123, mediante el procesador 150, configurado como instanciador de modelos 153, los modelos funcionales y visuales creados en la etapa c, conjugados con los recursos UI, siguiendo las normas de los protocolos almacenados en la Etapa A.
Adicionalmente, el presente invento comprende un sistema que instancia y expone aplicaciones tipo software operativas a partir de especificaciones de diseño de software, que comprende:
a. un dispositivo de entrada/salida 120 configurado como Interface de CDF 121, Interface de CDV 122, Interface de Aplicación 123 para ingresar las especificaciones de diseño de software y exponer las aplicaciones tipo software resultantes;
b. una unidad de procesamiento central (CPU) 110 conectada al dispositivo de entrada/salida 120 que contiene: una memoria general 140 está en comunicación con el dispositivo de entrada/salida 120, que interactúa con el procesador 150, configurada para almacenar de manera volátil los componentes funcionales, visuales y componentes UI; y
- un procesador 150 configurado para recibir al menos una especificación de diseño de software a través del dispositivo de Entrada/Salida 120; dicho procesador configurado como validador de modelos 151 para validar la especificación de diseño de software contra los protocolos de la Etapa A, e identificar los correspondientes modelos funcionales y visuales;
dicho procesador configurado como compaginador de UI 152 para compaginar la aplicación tipo software resultante, conjugando los modelos funcionales, visuales y recursos UI; y,
dicho procesador configurado como instanciador de modelos 153 para exponer la aplicación tipo software resultante en la Interface de Aplicación 123; y
c. una memoria de base de datos 130 conectada a la CPU 110, en comunicación con el procesador 150, configurada para almacenar en forma estática, el protocolo de especificación Visual PEV en una estructura lógica PEV 131, el protocolo de especificación funcional PEF en una estructura lógica PEF 132 y los recursos UI en una estructura lógica Recursos UI 133 y también configurada para almacenar en forma dinámica, modelos visuales en una estructura lógica Modelos MV 134, modelos funcionales en una estructura lógica Modelos MF 135 y objetos en una estructura lógica Objetos 136. 6. Breve descripción de las figuras
La FIG. 1. muestra la estructura del sistema del presente invento.
La FIG. 1A. muestra el protocolo de especificación funcional PEF.
La FIG. IB. muestra el protocolo de especificación visual PEV.
La FIG. 1C. muestra la estructura lógica de la memoria de base de datos Modelos MF. La FIG. ID. muestra la estructura lógica de la memoria de base de datos Modelos MV. La FIG. 1E. muestra la estructura lógica de la memoria de base de datos Objetos. La FIG. 2. muestra las etapas del método del presente invento.
La FIG. 2A. muestra el detalle de subetapas de la Etapa A.
La FIG. 2B. muestra el detalle de subetapas de la Etapa B.
La FIG. 2B1. muestra un ejemplo de identificación de componentes funcionales y tipos 00.
La FIG. 2C. muestra el detalle de subetapas de la Etapa C.
La FIG. 2C1. muestra un ejemplo de aplicación del protocolo PEF sobre un diagrama de clases
La FIG. 2C2. muestra un ejemplo de aplicación del protocolo PEV sobre un diagrama de pantallas
La FIG. 2D. muestra el detalle de subetapas de la Etapa D
La FIG. 3A. muestra una modalidad adicional de las etapas del método del presente invento.
La FIG. 3B. muestra una modalidad adicional de las etapas del método del presente invento.
7. Descripción detallada de la invención
El presente invento corresponde a un sistema y método implementado por computador que permiten almacenar modelos de clases, que representan el diseño detallado de una aplicación de software en una memoria de base de datos, y exponen las aplicaciones de tipo software resultantes, a través de un proceso de instanciación de dichos modelos.
Como se describe en la Figura 2, el proceso comienza con el almacenamiento de los diseños de software en la memoria de base de datos, y luego identifica los componentes de dicho diseño, utilizando las definiciones de protocolos pre-cargados en el sistema para resolver la instanciación de los modelos, que finalmente constituyen la aplicación tipo software. En el presente invento, un modelo es la representación de un componente de diseño funcional o visual, materializada en una memoria de base de datos.
Para ejecutar el método, se utiliza un sistema como el descripto en la Figura 1, para ingresar los diseños de clases y pantallas en un Dispositivo de Entrada/Salida 120. Los diseños ingresados se transfieren a la memoria general para luego ser procesados por el Procesador 150. El procesador se configura para validar, compaginar e instanciar los modelos existentes en las memorias de Base de Datos 134 y 135. Los resultados de cada función de procesamiento se exponen a pantallas en un Dispositivo de Entrada/Salida 120.
A continuación, se describen los componentes del sistema 100 de la Figura 1 :
1. Dispositivo de Entrada/Salida 120: es el dispositivo mediante el cual se ingresan los diseños de software. Permite a un procesador presentar en medios de visualización (pantallas, proyectores, televisores, impresoras, monitores, dispositivos móviles, entre otros) estructuras donde el usuario puede ingresar los diseños de clases y de pantallas (como los que se muestran en la Figura 2B), y visualizar las aplicaciones de tipo software resultantes, utilizando las siguientes configuraciones:
a. Interface de CDF 121: es una estructura visual que permite al usuario ingresar los componentes de diseño funcional de una aplicación de software a partir de un diagrama de clases, los cuales se almacenan en la Memoria de Base de Datos 130, en la configuración lógica Modelos MF 135.
b. Interface de CDV 122: es una estructura visual que permite al usuario cargar los componentes de diseño visual de una aplicación de software a partir de un diagrama de pantallas asociado a un diagrama de clases, que serán almacenados en la Memoria de Base de Datos 130, en la configuración lógica Modelos MV 134.
c. Interface de Aplicación 123: esta interface presenta al usuario las estructuras visuales de la aplicación de software resultante, una vez que el Procesador 150 instanció los modelos funcionales y visuales disponibles en la Memoria de Base de Datos 130.
2. CPU 110: es el dispositivo de procesamiento del sistema 100. Este dispositivo está estructurado para realizar las funciones de validación de los modelos funcionales y visuales contra el respectivo protocolo, la compaginación de recursos de UI y la instanciación de la aplicación de tipo software a partir de los pasos previos. Contiene la memoria general que permite el intercambio entre las funciones y el resto de los componentes del sistema.
a. Memoria General 140: es un almacenamiento volátil que se utiliza como dispositivo de intercambio entre el dispositivo de entrada/salida, la memoria de base de datos y el procesador. Realiza las siguientes funciones según su configuración:
i. Matriz de Componentes UI 141: es la configuración de la Memoria General que posibilita el acceso a los recursos de UI existentes en la Memoria de Base de Datos 133 y los dispone para ser expuestos por el Procesador 150 como parte de la aplicación de tipo software resultante.
ii. Matriz de MF 142: es la configuración de la Memoria General que posibilita el procesamiento los Modelos Funcionales residentes en la Memoria de Base de Datos 135 mediante el Procesador 150 configurado como Instanciador de Modelos 153, en correlación con los protocolos almacenados en las memorias de base de datos 131 y 132.
iii. Matriz de MV 143: es la configuración de la Memoria General que posibilita el procesamiento los Modelos Visuales residentes en la Memoria de Base de Datos 134 mediante el Procesador 150 configurado como Instanciador de Modelos 153, en correlación con los protocolos almacenados en las memorias de base de datos 131 y 132.
b. Procesador 150: es el dispositivo en el cual se llevan a cabo las tareas de procesamiento e intercambio. Realiza las siguientes funciones según su configuración:
i. Validador de Modelos 151: es la configuración del Procesador que se encarga principalmente de validar los modelos funcionales ingresados por el usuario contra los protocolos residentes en las memorias de base de datos 131 y 132, para una vez validados almacenarlos en las memorias de base de datos 134 y 135 respectivamente.
ii. Compaginador de UI 152: es la configuración del Procesador que se encarga principalmente de compaginar los recursos UI residentes en la memoria de base de datos 133 con los modelos visuales almacenados en la memoria de base de datos 134, previo al proceso de instanciación.
iii. Instanciador de Modelos 153: es la configuración del Procesador que se encarga principalmente de instanciar los modelos funcionales y modelos visuales ya compaginados con los recursos de UI, residentes en las configuraciones lógicas de la memoria general 142 y 143, para exponer automáticamente la aplicación tipo software resultante en la Interface de Aplicación 123.
Memoria de Base de Datos 130: es una memoria permanente que alberga los datos cargados por el usuario y generados por el Procesador 150 en sus diferentes configuraciones. Esta memoria contiene dos configuraciones de almacenamiento, una configuración estática y una configuración dinámica. La configuración estática almacena aquellos datos fijos necesarios que se cargan por única vez para el procesamiento que no son propios de "el caso". La configuración dinámica almacena los datos propios de "el caso" que se cargan por cada caso.
a. Memoria Estática:
i. PEF 131: configuración de la Memoria de Base de Datos 130 que contiene las reglas que utiliza el Procesador 150 para validar e instanciar los modelos funcionales, definidas y cargadas en esta memoria a partir del Protocolo de Especificación Visual (PEV). ii. PEV 132: configuración de la Memoria de Base de Datos 130 que contiene las reglas que utiliza el Procesador 150 para validar e instanciar los modelos funcionales, definidas y cargadas en esta memoria a partir del Protocolo de Especificación Funcional (PEF). iii. Recursos UI 133: configuración de la Memoria de Base de Datos 130 que contiene componentes de software que permiten al Procesador 150 exponer de los modelos visuales en la Interface de Aplicación 123, mediante pantallas operables por el usuario. Memoria Dinámica:
i. Modelos MV 134: configuración de la Memoria de Base de Datos 130 que contiene los modelos funcionales cargados por el usuario mediante la Interface de CDV 122 y validados por el Procesador 150 contra el protocolo de Especificación Visual (PEV). Esta memoria, consta de las siguientes estructuras lógicas asociadas a los conceptos del Protocolo de Especificación Visual que se muestra en la Figura IB:
1. Configuraciones asociadas al concepto ActionLink
a. Estructura lógica RenderAction b. Estructura lógica RenderActionEditor
c. Estructura lógica RenderAttributeBaseAction d. Estructura lógica RenderBaseViewAction
2. Configuraciones asociadas al concepto Application
a. Estructura lógica Application
3. Configuraciones asociadas al concepto AttributeRenderlnfo
a. Estructura lógica RenderAttribute b. Estructura lógica RenderAttributeBase c. Estructura lógica RenderDiagramView
d. Estructura lógica RenderMapView e. Estructura lógica RenderNavBarView
f. Estructura lógica RenderObjectReferenceAttribute g. Estructura lógica RenderPivotView h. Estructura lógica RenderReportView
i. Estructura lógica RenderWidgetAttribute
4. Configuraciones asociadas al concepto ColumnViewModel a. Estructura lógica RenderColumn
5. Configuraciones asociadas al concepto Container
a. Estructura lógica RenderContainer
6. Configuraciones asociadas al concepto ListViewModel a. Estructura lógica RenderFindView
b. Estructura lógica RenderGridAggregateColumn c. Estructura lógica RenderGridAttribute d. Estructura lógica RenderGridColumn
e. Estructura lógica RenderGridColumnAction f. Estructura lógica RenderGridView
7. Configuraciones asociadas al concepto Menú
a. Estructura lógica Menú
8. Configuraciones asociadas al concepto MenuGroup
a. Estructura lógica MenuGroup
9. Configuraciones asociadas al concepto TreeViewModel a. Estructura lógica RenderRelationView b. Estructura lógica RenderRelationViewAction c. Estructura lógica RenderTreeView
10. Configuraciones asociadas al concepto ViewModel
a. Estructura lógica PopUpEditor
b. Estructura lógica PrintConfiguration
c. Estructura lógica RenderBaseView
d. Estructura lógica RenderBaseViewInheritance Modelos MF 135: configuración de la Memoria de Base de Datos 130 que contiene los modelos funcionales cargados por el usuario mediante la Interface de CDF 121 y validados por el Procesador 150 contra el protocolo de Especificación Funcional (PEF). Esta memoria, consta de las siguientes estructuras lógicas asociadas a los conceptos del Protocolo de Especificación Funcional, cuadrante More-Class, que se muestra en la Figura 1A:
1. Configuraciones asociadas al concepto Dominio
a. Estructura lógica Domain 2. Configuraciones asociadas al concepto Formula a. Estructura lógica Fx
b. Estructura lógica MatchAttribute
c. Estructura lógica MatchFieldStrategy d. Estructura lógica Matchlnfo
e. Estructura lógica Match Valué
f. Estructura lógica Match ValueStrategy
3. Configuraciones asociadas al concepto FxCall
Argument
a. Estructura lógica FxCall
4. Configuraciones asociadas al concepto ModelAttribute a. Estructura lógica MoreClassAttribute
5. Configuraciones asociadas al concepto ModelClass
a. Estructura lógica MoreClass
b. Estructura lógica MoreClassInheritance
6. Configuraciones asociadas al concepto ModelRelationClass
a. Estructura lógica MoreRelationClass iii. Objetos 136: configuración de la Memoria de Base de Datos 130 que contiene los objetos que el usuario genera, basados en los modelos instanciados a través de la aplicación tipo software, por Procesador 150 configurado como Instanciador de Modelos 153. Esta memoria, consta de las siguientes estructuras lógicas asociadas a los conceptos del Protocolo de Especificación Funcional, cuadrante Object-Class, que se muestra en la Figura
1A:
1. Configuraciones asociadas al concepto AttributeValue a. Estructura lógica MoreObject AttributeValue b. Estructura lógica MoreObj ect Attribute ValueFileExtended c. Estructura lógica MoreRelationObj ectMoreObj ect AttributeRelation 2. Configuraciones asociadas al concepto Object
a. Estructura lógica MoreObject
3. Configuraciones asociadas al concepto RelationObject a. Estructura lógica MoreRelationObject
La presente invención corresponde al sistema descripto y un método implementado en computador que interpreta y expone aplicaciones tipo software a partir de especificaciones de diseño. Haciendo referencia a la Figura 2, el método de la presente invención comprende las siguientes etapas:
Etapa A. Cargar a través del Dispositivo de Entrada/Salida 120 el Protocolo de especificación funcional (PEF) en la estructura lógica PEF 132 y el Protocolo de especificación visual (PEV) con sus correspondientes recursos UI en las estructuras lógicas PEV 131 y Recursos UI 133 de la Memoria de Base de Datos 130.
Etapa B. A partir de un diseño de clases, identificar y cargar los componentes de diseño funcional detallados en el diagrama de clases a través de la Interface CDF 121 y almacenarlos temporalmente en la Memoria General 140, en la estructura lógica Matriz de MF 142. A partir del diseño de pantallas, asociado al diseño de clases, identificar y cargar los componentes de diseño visual detallados a través de la Interface CDV 122 y almacenarlos temporalmente en la Memoria General 140, en la estructura lógica Matriz de MV 143.
Etapa C. Validar los modelos funcionales y visuales creados en la Etapa B, utilizando el Procesador 150 en su configuración de Validador de
Modelos 151 para crear a partir de cada modelo cargado en la Memoria General 140, un modelo compatible con los protocolos PEF y PEV residentes en la Memoria de Base de Datos 130 almacenados en la Etapa A. Almacenar los modelos funcionales y resultantes, en la Memoria de Base de Datos 130, en sus configuraciones lógicas
Modelos MF 134 y Modelos MV 133 respectivamente. Etapa D. Recuperar de la Memoria de Base de Datos 130 los Modelos Funcionales y los Modelos Visuales creados en la Etapa C, los Recursos UI cargados en la Etapa A y almacenarlos en la Memoria General 140 utilizando el Procesador 150 configurado como Compaginador de UI 152. Compaginar los Recursos UI con los componentes funcionales y visuales almacenados en la Memoria General 140 e instanciar los modelos compaginados y exponer las pantallas de una aplicación tipo software en el Dispositivo de Entrada/Salida 120, Interface de Aplicación 123, utilizando el Procesador 150 configurado como Instanciador de modelos 153.
Recibir a través de la Interface de Aplicación 123 las peticiones de los usuarios y almacenar los objetos resultantes de la respuesta del Procesador 150 a la operación de la aplicación, en la Memoria de Base de Datos 140, estructura lógica Objetos 136.
A continuación, se describen en detalle las etapas del proceso: Etapa A. Cargar los protocolos en la memoria
En esta etapa, como se expone en la Figura 2A, se definen dos normas, llamadas protocolos, que se cargan en la Memoria de Base de Datos 130, por única vez. El Procesador 150 utiliza estos protocolos, en sus diferentes configuraciones, a lo largo del proceso: i) Protocolo de especificación funcional (PEF); y ii) Protocolo de especificación visual (PEV). Estos protocolos establecen el modo en que el Procesador 150 compaginará los componentes funcionales de un diagrama de diseño de clases de software (OO) y un diagrama de diseño de pantallas, para lograr una aplicación tipo software operativa de manera automática. En el presente invento, un diagrama de clases con su respectivo diagrama de diseño de pantallas se denomina "el caso". El diagrama de diseño de clases representa la funcionalidad de la aplicación de software (conformada por un conjunto de componentes funcionales) y el diagrama de pantallas representa la estructura visual (conformada por un conjunto de componentes visuales) que presenta la aplicación tipo software a sus usuarios. A continuación, se describen ambos protocolos: Subetapa Al. Cargar Protocolo de especificación funcional (PEF)
Este protocolo es la norma que define el comportamiento que el Procesador 150 dará a los componentes funcionales que el usuario cargue a partir de un diagrama de diseño de clases, de ahora en adelante componentes PEF, que determinan la estructuración lógica para la operación del Sistema 100. La Arquitectura que define la funcionalidad de este Protocolo se puede observar en la Figura 1A.
El protocolo PEF define Metaclases que se refieren a clases cuyas instancias son clases, según OO. En este protocolo, las clases que son instancias de una Metaclase se conocen como Modelos (cuadrante Instance-Class de la Figura 1A).
Con el uso de este protocolo PEF, la funcionalidad de la aplicación tipo software resultante se logra instanciando el significado del lenguaje implícito en un diseño de clases, por un lado y la lógica matemática por otro lado. En la parte semántica de "el caso", los métodos (OO) identificados en el diagrama de clases, a través del protocolo se convierten en clases, y en la matemática los métodos (OO) que denotan una funcionalidad matemática se convierten en fórmulas. En el protocolo de Especificación Funcional PEF, como se observa en la Figura 1A cuadrante Model-Class, existen tres componentes para resolver la semántica (ModelClass, ModelRelationClass y ModelAttribute) y cuatro componentes para resolver la matemática (Dominio, Dominio externo, Fórmula y FxCall).
El protocolo también define clases de Objetos (cuadrante Object-Class de la Figura 1A). Estas clases de objetos ModelObject y ModelAttributeValue son los componentes que utiliza el sistema 100 para almacenar las instancias de los Modelos del cuadrante Instance-Object. Los Componentes PEF son los pertenecientes a los cuadrantes Model-Class y Object- Class. Dentro del cuadrante Model-Class, se encuentran: ModelClass, ModelRelationClass, ModelAttribute, Fórmula, Dominio y FxCall. Son un conjunto de Metaclases que dan origen a los Modelos funcionales que se almacenan en la Memoria de Base de Datos 130, en la estructura lógica Modelos MF 135. Dentro del cuadrante Object-Class se encuentran: ModelObject y ModelAttributeValue. Son un conjunto de Clases que dan origen a los Objetos del Sistema que se almacenan en la Memoria de Base de Datos 130, estructura lógica Objetos 136. Estos componentes PEF se describen a continuación:
i. Metaclases que dan Origen a los Modelos funcionales de la aplicación de software (cuadrante Model-Class)
■ ModelClass
Es un componente metaclase porque sus instancias son modelos. Este componente modela estructuras de diseño que en el diagrama de diseño 00 son clases. Un ModelClass puede heredar de otro ModelClass.
Ejemplo: Podemos crear una metaclase Entidad Humana (ModelClass), otra metaclase Persona (ModelClass que hereda del ModelClass Entidad Humana). Las instancias de Persona pueden ser Personas Físicas o Personas Jurídicas. Tanto Persona Física como Persona Jurídica son Modelos que constituyen instancias de la Metaclase Persona.
■ ModelRelationClass
Es un componente metaclase que hereda de ModelClass. La funcionalidad que extiende al ModelClass, agrega a esta metaclase la capacidad de relacionar dos ModelClass, que puede ser de dos tipos: asociación o composición, según se define en OO.
Ejemplo: Si tomamos el ModelClass Persona Física y el ModelClass Persona Jurídica, podríamos pensar que una instancia de Persona Física (Juan Pérez) puede ser empleado de una instancia de Persona Jurídica (Empresa Google). Este caso, existe un ModelRelationClass que se llama "se relaciona con" que vincula al ModelClass Persona consigo mismo a nivel de metamodelo. Esta relación podría utilizarse para representar la relación de empleado que existe entre persona Física y Persona Jurídica, o también podría especializar el ModelClass Persona en ModelClass Persona Física y Persona Jurídica, para luego crear la especialidad de ModelRelationClass "es empleado de" que heredaría del ModelRelationClass "se relaciona con".
■ ModelAttribute
Es un componente metaclase que compone a ModelClass. Un ModelClass tiene una lista de ModelAttributes. ModelAttribute es la representación de los atributos que contendrán los modelos creados como instancias de ModelClass.
Un ModelAttribute define, entre otras cosas, el tipo de dato del atributo al cual está dando origen.
El protocolo define tres clasificaciones de tipos de dato para ModelAttribute.
o ModelAttribute Simple: los tipos simples son aquellos cuya instancia de valor no involucra instancias de ModelObject. Ejemplo: dato número, dato texto, dato imagen.
o ModelAttribute RelationObject: son atributos que existen en un ModelClass producto de que éste participe en un ModelRelationClass. Este tipo de atributo en su instancia de valor, dependiendo de la relación, puede tener una o más instancias de objetos de relación. Esto determina la cardinalidad de la relación. Ejemplo: Si tenemos un ModelRelationClass entre el ModelClass "Persona" y el ModelClass "Artículo", existe en el ModelClass Persona un ModelAttribute de tipo RelationObject que tendrá como instancia las Personas que se relacionen con Artículo. Y en la inversa, el ModelClass Persona tiene un ModelAttribute de tipo RelationObject que tendrá como instancias a los artículos que se relacionen con Persona.
o ModelAttribute ObjectReference: este tipo de datos es similar al anterior, solo que no surge producto de que el ModelClass al que pertenece participa en una relación. El atributo propiamente dicho es quien conoce la naturaleza de los objetos que oportunamente compondrán la instancia de valor para el mismo.
Ejemplo: al crear un ModelAttribute como parte de un ModelClass lo declaro
ObjectReference.
■ Fórmula Una fórmula es un modelo independiente que cuenta con una expresión y un conjunto de parámetros para recibir información del Modelo que la invoca. La fórmula, cuando se ejecuta, siempre retorna un valor al Modelo que la llama. El valor resultante puede ser una única instancia o múltiples instancias como parte de arreglos y arreglos multidimensionales.
El protocolo de especificación funcional define al componente fórmula que se utiliza para resolver aquella lógica que funcionalmente requiere de la ejecución de operaciones matemáticas que utilizan como argumentos instancias de modelos. La fórmula provee todos los operadores matemáticos para operaciones algebraicas, matriciales o de conjuntos y permite definir la expresión haciendo uso de los argumentos existentes como instancias de modelos del cuadrante Model-Instance de la Figura 1A.
La funcionalidad que implica una resolución matemática se implementa mediante una Metaclase Fórmula. A diferencia del diseño tradicional de software, donde este tipo de funcionalidades se implementa como un método en una clase del modelo 00.
Ejemplo: una fórmula que calcula el valor total de una venta, cuenta con la expresión algebraica que suma los importes vendidos y devuelve un único valor resultante en una instancia de ModelAttribute, siendo los importes vendidos una colección de instancias de ModelAtrribute.
■ Dominio
El dominio es un componente que declara condiciones que permiten seleccionar un subconjunto de instancias de modelos (operaciones entre conjuntos).
Una instancia de modelo se puede encontrar en la memoria de Base de Datos 130, en la estructura lógica Objetos 136, ya validada y estructurada por el Procesador 150 en base al protocolo PEF, o en una memoria externa no estructurada en base al protocolo. En consecuencia, los Dominios se clasifican de la siguiente manera:
Dominios Internos
Son los dominios que se resuelven sobre la memoria de Base de Datos 130, en la estructura lógica Objetos 136 obteniendo colecciones de instancias que luego podrán ser procesadas por otros modelos a través de fórmulas. Ejemplo: si existe un ModelClass Cliente, para recuperar sus instancias almacenadas en la base de datos se debe utilizar un Dominio Interno, donde solo se invoca el nombre del ModelClass y la condición que deben cumplir las instancias a recuperar.
Dominios Externos
Son los dominios que se resuelven sobre una memoria NO estructurada en base al protocolo PEF (datos en archivos externos). En estos casos el componente dominio externo accede a las instancias de objetos y el Procesador 150 las estructura en base al protocolo para que formen parte del espacio accesible por dominios internos. Ejemplo: Si existe un archivo externo que tiene 3 columnas de datos: nombre, edad y empresa, para recuperarlos se debe crear un dominio externo donde se indica que dichos datos son datos de un cliente y la correspondencia de columnas con los ModelAttribute (columna Nombre: ModelAttribute Nombre, columna edad: ModelAttribute edad, columna empresa: ModelAttribute Empresa). El ModelAttribute empresa es de tipo RelationObject donde Cliente se relaciona con empresa.
■ FxCall
Este componente es el responsable de asociar cualquier instancia de ModelAttribute con las instancias de Fórmula, cuando el valor de la instancia de ModelAttribute proviene de una Fórmula. Es un modelo que resuelve la evaluación de una expresión de fórmula y retorna un resultado al modelo que la invoca, enviando al Procesador 150 los operadores matemáticos y los argumentos que serán operados. FxCall hidrata los valores de argumentos obtenidos de las instancias, para que la Fórmula invocada solicite resolución al Procesador 150.
Clases que dan Origen a los Objetos de la aplicación de software (cuadrante Object- Class)
■ ModelObject
Las instancias de las clases instanciadas a partir de ModelClass, se conocen como ModelObjects. ModelObject es la clase concreta que materializa las instancias de objetos modelados con ModelClass. Ejemplo: El modelo Artículo que es instancia de ModelClass posee una instancia concreta de ModelObject "leche". Este objeto es a su vez la materialización de una instancia de ModelObject.
■ ModelAttributeValue
Las instancias de los modelos modelados con ModelAttribute se conocen como ModelAttribute Valúes. ModelAttributeValue es la clase concreta cuyas instancias representan el valor de los atributos de una instancia de ModelObject. Ejemplo: El modelo Artículo que es instancia de ModelClass posee una instancia concreta de ModelObject "leche", cuyo ModelAttributeValue para el ModelAttribute nombre es "leche". Subetapa A2. Cargar Protocolo de especificación visual (PEV)
Este protocolo define, como se muestra en la Figura IB, el comportamiento que el Procesador 150 dará a los componentes visuales que el usuario cargue a partir de un diagrama de diseño de pantallas, de ahora en adelante componentes PEV. Estos componentes determinan la estructuración visual que se presentará en el Dispositivo de Entrada/Salida 120, Interface de Aplicación 123 para la operación del Sistema 100. La Arquitectura que define la presentación visual de este Protocolo se puede observar en la Figura IB.
El protocolo de Especificación Visual PEV define el modo en que se vinculan los componentes PEF y los componentes PEV. Un componente PEV expone la funcionalidad de uno o más componentes PEF a través del Dispositivo de Entrada/Salida 120, Interface de Aplicación 123.
Esta definición del protocolo determina que es posible producir salidas en dispositivos visuales, que pueden ser operados para crear información de procesos de negocio sin hacer diseño de arquitectura de capas particular para cada caso, porque la arquitectura está embebida en los componentes PEF.
En otra modalidad del presente invento se crean componentes PEV no vinculados a componentes PEF, por ejemplo: un modelo visual que contiene un link a una página web.
Los Componentes PEV son: Application, ActionLink, AbmViewModel, ListViewModel, TreeViewModel, ReportViewModel.
■ Application
El componente Application estructura visualmente una aplicación de software.
El protocolo define el componente Application como un Modelo para especificar una aplicación. Una aplicación define como aspecto más importante el Menú mediante el cual el usuario tendrá acceso a la funcionalidad expuesta. Un Menú es una colección de modelos MenuGroup y modelos Menultem arborizada, donde los MenuGroup pueden contener a su vez otros MenuGroup o Menultem. Los Menultem son los que vinculan la acción que se llevará a cabo cuando el usuario haga click sobre el mismo. Un ítem tiene asociado alguno de los siguientes modelos de visualización (ViewModel): AbmViewModel, ListViewModel, TreeViewModel. Cuando el usuario ejecuta un Menultem, el Procesador 150 del sistema 100 recibe dicha petición a través de la Interface de Aplicación 123 y devuelve una estructura en la misma Interface que permite al usuario ejecutar funcionalidad del componente PEF invocado por el componente PEV asociado al Menultem.
■ ViewModel
El componente ViewModel es el que permite exponer instancias de ModelObject, en dispositivos visuales. Un componente ViewModel está compuesto por componentes ActionLink que permiten al ViewModel ejecutar acciones según el modelo ModelClass del cual es instancia y la clase de ViewModel a la que hace referencia.
Un componente PEV define un layout (estructura de disposición visual o plantilla) que será expuesta en el Dispositivo de Entrada/Salida 120, Interface de Aplicación 123, a partir de ViewModel y sus características.
Para exponer instancias de modelos, existen tres clases de ViewModel: AbmViewModel, ListViewModel y TreeViewModel con diferentes características y especificaciones de layout.
(1) AbmViewModel
El protocolo define el componente AbmViewModel como un Modelo para especificar el renderizado de una pantalla que permite dar de Alta, Baja o Modificar un Objeto ModelObject. El renderizado de una pantalla, expone todos o algunos de los ModelAttributeValues de una instancia de ModelObject, según el modelo ModelClass correspondiente.
El componente AbmViewModel, está compuesto por componentes ActionLink por ser un ViewModel y extiende su funcionalidad a través de los componentes
ControlViewType y las características especiales del AbmViewModel.
Los componentes ControlViewType exponen los ModelAttributeValues según el tipo de dato del atributo. En una modalidad del invento se expone la siguiente lista de tipos de atributos: TextEditor: expone ModelAttributeValues de tipo texto.
NumericEditor: expone ModelAttributeValues de tipo número.
DateTimeEditor: expone ModelAttributeValues de tipo fecha.
ObjectReferenceComboEditor: expone ModelAttributeValues de tipo selector de ModelObjects.
ObjectReferenceListEditor: expone ModelAttributeValues de tipo selector de ModelObjects.
Los componentes ActionLink que componen al AbmViewModel son:
Guardar: guarda la instancia de ModelObject en el repositorio Transaccional. - Cancelar: cierra la estructura visual expuesta por el AbmViewModel y descarta los cambios realizados por el usuario en la instancia de ModelObject.
Guardar y Nuevo: guarda la instancia de ModelObject y crea una nueva instancia para que el usuario complete los valores de sus atributos, exponiéndola en la estructura visual del AbmViewModel.
- Imprimir: Imprime los valores de los atributos de la instancia que se está modificando.
En alguna modalidad de la invención se agregan acciones que invocan a otros ViewModel.
Características especiales de un AbmViewModel:
· AttributeRenderlnfo: este modelo se utiliza para indicar las particularidades de renderizado de un control que representa el valor de determinado atributo de una instancia de ModelObject.
• ControlTemplate: selector de control para renderizar un ModelAttribute.
Dependiendo del tipo de dato del atributo, éste podrá ser representado de diversas formas acordes con la naturaleza del tipo. ControlTemplate es el concepto que permite indicar con cuál de todas esas posibles opciones será efectivamente renderizado el atributo.
• Container: dentro de AbmViewModel existe una estructura de contenedores a los efectos de poder organizar los controles en dispositivo visual. Se conoce como controles a cada uno de los componentes que expone visualmente un atributo. Esta estructura de contenedores es arborizada, es decir, puede un contenedor incluir a otros. • ColumnViewModel: dentro de los contenedores, los controles se organizan en columnas y éstas internamente tienen un orden para los controles que contienen.
(2) ListViewModel
El protocolo define el componente ListViewModel como un Modelo para especificar el renderizado de una pantalla que permite listar colecciones de instancias de ModelObject. El renderizado de esta pantalla, expone los ModelAttributeValues que dicho ModelObject posee según el modelo ModelClass del cual es instancia, para una colección de instancias del ModelObject que se muestran en una tabla donde cada ModelAttribute Valué ocupa una celda, donde la fila corresponde a la instancia y la columna al ModelAttribute.
El componente ListViewModel, está compuesto por componentes ActionLink por ser un ViewModel y extiende su funcionalidad a través de los componentes SearchViewModel, ColumnViewModel, ObiectReferenceListGridEditor y las características especiales del ListViewModel.
Los componentes ActionLink que componen al ListViewModel son: Nuevo; Eliminar; Editar; Imprimir; Ejecutar Fórmula
Adicionalmente, para listas de RelationObjects surgen las siguientes acciones:
• NuevoMDestino: invoca la creación de un nuevo ModelObject del modelo relacionado como destino de la relación.
• NuevoMDestino YAsociar: invoca la creación de un nuevo ModelObject del modelo relacionado como destino de la relación, y materializa la relación con el ModelObject propietario del atributo de relación.
• EliminarMDestino: en una instancia de relación, elimina el ModelObject relacionado, como así también la instancia de relación.
• EditarMdestino: invoca la pantalla de edición del ModelObject relacionado. Características especiales de un ListViewModel:
• Herarchical view: se refiere a la representación con estructura jerárquica del grafo de objetos relacionados mediante modelos ModelRelationClass. • InLine Edition: soporte para la modificación de los atributos de un objeto sobre la misma línea de la lista.
(3) TreeViewModel
El protocolo define el componente TreeViewModel como un Modelo para especificar el renderizado de un árbol de ModelObjects relacionados mediante RelationObjects. El renderizado de esta pantalla, consiste en la exposición de todos o algunos de los ModelAttribute Valúes que dicho RelationObjects invoca a partir de los ModelClass que relaciona. Un nodo de un árbol, representado en un componente TreeNodeModel, representa entonces una instancia de ModelObject y una instancia de RelationObject, que es la relación que existe entre el nodo en cuestión y su nodo padre. Por lo tanto, los nodos del primer nivel del árbol no tendrán representación de ninguna instancia de RelationObject ya que no se relacionan con ningún nodo padre.
El componente TreeViewModel, está compuesto componentes ActionLink por ser un ViewModel y extiende su funcionalidad a través de las características especiales del TreeViewModel.
Los componentes ActionLink que componen al TreeViewModel son:
- Nuevo: crea una nueva instancia de RelationObject basada en el
ModelRelationClass correspondiente según el modelo de visualización de árbol para el nodo donde se está invocando la acción.
Eliminar: Elimina la instancia de RelationObject que vincula al nodo actual con su nodo padre.
- Editar: edita la instancia de RelationObject que vincula al nodo actual con su nodo padre.
NuevoMDestino: invoca la creación de una nueva instancia de ModelObject que se corresponde con el destino de la relación para el modelo de ModelRelationClass correspondiente según el modelo de visualización de árbol para el nodo donde se está invocando la acción. NuevoMDestinoYAsociar: ídem NuevoMDestino, solo que luego crea la instancia de RelationObject para vincular el nuevo ModelObject con el ModelObject representado por el nodo sobre el que se invocó la acción.
EliminarMDestino: elimina la instancia de ModelObject representada por el nodo actual.
EditarMdestino: edita la instancia de ModelObject representada por el nodo actual.
Características especiales de un Tree ViewModel:
· LoadOnDemand: indica si el árbol debe ir descubriendo y cargando sus nodos a medida que el usuario interactúa expandiendo el árbol.
• ShowExpanded: indica que, al mostrarse el árbol, éste debe visualizarse con todos sus nodos expandidos.
• EditOnClick: indica que debe invocarse la edición del objeto representado por un nodo cuando el usuario hace click sobre el mismo.
(4) ActionLink
Los componentes ActionLink definen las acciones que están disponibles en el ViewModel para ejecutar sobre las instancias de ModelObject.
Cada subclase de ViewModel posee una lista de ActionLinks distinta, en relación con la funcionalidad que expone en el dispositivo visual.
(5) ReportViewModel
Un ReportViewModel contiene la especificación necesaria para que el Procesador 150 configurado como Instanciador de Modelos 153, pueda interactuar con cualquier servicio de entrega de reportes, como por ejemplo Reporting Services.
Esto es posible ya que el repositorio de instancias de ModelObject es compatible con los métodos de consulta q estos servicios implementan, de forma que haciendo uso de los componentes de visualización que acompañan a estas tecnologías, se pueden generar e integrar reportes de una forma simple y con todas las características de reporting necesarias. Subetapa A3. Cargar recursos de UI
El Protocolo de Especificación Visual PEV está diseñado de forma que el Procesador 150 pueda compaginar los componentes visuales con recursos de UI. El objetivo de esta compaginación es que el Procesador pueda rápidamente poner estos componentes a disposición para el modelado de la interfaz de Usuario. Esto se logra mediante el concepto de ControlViewType del Protocolo PEV cargado en la Subetapa A2, el cual se vincula directamente con un recurso de UI y permite desde un ViewModel indicar con qué recurso UI será presentada determinada porción de la interfaz de usuario en el Dispositivo de Entrada/Salida 120, Interface de Aplicación 123.
Los Recursos UI son porciones parciales declaradas en algún lenguaje de UI (ejemplo, HTML5) y cuya apariencia puede ajustarse con hojas de estilo en cascada (por ejemplo, css). Estos recursos, se almacenan en la Memoria de Base de Datos 130, estructura lógica Recursos UI 133. Luego, cuando el Procesador 150, configurado como Compaginador de UI 152 ejecuta sus funciones, vincula estos Recursos UI con una instancia de la estructura lógica ControlViewType, residente en la Memoria de Base de Datos 130, estructura lógica Modelos MV 134, dejando estos modelos conjugados disponibles para ser utilizados en la exposición de la aplicación tipo software.
Etapa B. Identificar y Almacenar componentes de Diseño
El diseño se describe porque resulta necesario como entrada al proceso abarcado por el invento.
Los documentos de diseño, como se muestran en la Figura 2B, se refieren particularmente a dos tipos de diagramas conocidos para definir la funcionalidad y las estructuras visuales que definen una aplicación de tipo software:
- los diagramas de clases (220) que representan el diseño funcional. Estos diseños serán utilizados para la creación de los modelos funcionales,
los diagramas de pantallas (221) que representan el diseño visual requerido. Estos diseños serán utilizados para la creación de los modelos visuales.
En esta etapa se parte del diseño funcional y el diseño de pantallas, y se llevan a cabo las siguientes subetapas: Subetapa Bl. Identificar los componentes del diseño funcional
A partir de un diseño de clases (220) que representa la lógica que se desea resolver, listar las clases que figuran en el diagrama. A partir del diagrama de clases identificar sus componentes teniendo en cuenta que el tipo de componente se define en base al paradigma 00 y hacerle corresponder un componente ModelClass, según establece el protocolo PEF cargado en la Subetapa Al. Identificar el nombre de cada componente identificado como se muestra en el Ejemplo de la Figura 2B1, y determinar el componente PEF que le corresponde, tal como se puede observar en el ejemplo de la Figura 2C1, así:
- Si el diagrama expone una clase, identificar un componente funcional tipo 00
Clase y determinar que le corresponde un componente PEF ModelClass.
Si el diagrama expone dentro de una clase un atributo, identificar un componente funcional tipo 00 Atributo y determinar que le corresponde un componente PEF ModelAttribute.
- Si el diagrama expone una relación, identificar un componente funcional tipo
00, Relación y determinar que le corresponde un componente PEF ModelRelationClass.
Si el diagrama expone un método dentro de una clase, identificar un componente funcional Tipo 00 Método y determinar:
o Si el método refiere a un cálculo matemático algebraico, que le corresponde un componente PEF Fórmula,
o Si el método refiere a una función matemática equivalente a la lógica de conjuntos, que le corresponde un componente PEF Dominio, pudiendo ser externo en caso de referir a datos externos al sistema.
- Si el diagrama expone una herencia, identificar un componente funcional tipo
00, herencia y determinar que le corresponde una relación de herencia entre dos ModelClass, como lo define el protocolo PEF en el cuadrante Model-Class.
El usuario, a través del Dispositivo de Entrada/Salida 120, Interface de CD 121, carga los componentes PEF identificados y el Procesador 150, configurado como Validador de Modelos 151, los almacena en la Memoria General 140, estructura lógica Matriz de MF 142. Subetapa B2. Identificar los componentes del diseño visual
Tomando como referencia el diseño de pantallas que representa el modo en que se desea ver e interactuar con la aplicación tipo software que construirá automáticamente el Procesador 150 configurado como Instanciador de Modelos 153, se describen a continuación los pasos a ejecutar para determinar los modelos visuales que se deben crear para exponer la aplicación tipo software para "el caso".
A partir de la lista de componentes PEF, se aplica el protocolo de Especificación Visual cargado en la Etapa A, para identificar los conceptos de tipo ModelClass y crear los modelos visuales que define el protocolo PEV (Application, AbmViewModel, ListViewModel, TreeViewModel), así:
a. Por cada ModelClass, se determina que se deberán crear los siguientes ViewModel: AbmViewModel, ListViewModel.
b. Por cada ModelRelationClass, se determina que se deberán crear los siguientes ViewModel: ListViewModel, TreeViewModel c. Para exponer la totalidad de los componentes PEF se determina que se deberá crear un Modelo Application, un modelo MenuViewModel,un modelo MenuGroup y un modelo ItemGroup por cada ViewModel creado en los pasos previos.
En una modalidad del presente invento el sistema 100 permite editar los modelos visuales creados para lograr la mayor similitud con los diseños de pantallas correspondientes a "el caso" disponibles como input del proceso. El usuario, a través del Dispositivo de Entrada/Salida 120, Interface de CDV 122, carga los componentes PEV identificados y el Procesador 150, configurado como Validador de Modelos 151 los almacena en la Memoria General 140, estructura lógica Matriz de MV 143. Etapa B\ Generar CF y CD a partir de lenguaje natural.
En una modalidad de la invención, esta Etapa B' es sustitivva de la Etapa B, como se muestra en la Figura 3A. En esta etapa, el usuario Genera CF y CD a partir de lenguaje natural, por ejemplo, utilizando como se describe en la solicitud de patente No. 15/141,748, titulada "PROCESO Y SISTEMA PARA GENERAR DOCUMENTOS DE ARQUITECTURA FUNCIONAL Y DOCUMENTOS DE ESPECIFICACIÓN DE ANÁLISIS Y DE DISEÑO DE SOFTWARE DE MANERA AUTOMÁTICA A PARTIR DE LENGUAJE NATURAL", incorporada como referencia en su totalidad.
En esta modalidad, se ejecutan las siguientes subetapas:
Subetapa B'l. Obtener componentes funcionales
El Procesador 150 se conecta a la Memoria de Base de Datos, estructura lógica 172 identificada en la solicitud de patente No. 15/141,748, obtiene los componentes funcionales de "el caso" y los almacena en la Matriz de MF 142.
Subetapa B'2. Identificar componentes visuales
El Procesador 150, recorre la lista de componentes funcionales obtenidos en la Subetapa B' l y aplica el Protocolo de Especificación Visual PEV definido en la Subetapa A2. Obtiene de cada componente funcional uno o más componentes visuales, tal como se muestra en la Fig 2C2 y los almacena en la Matriz de MV 143. Etapa C. Crear modelos funcionales y visuales
En esta etapa, el Procesador 150 toma de la Memoria General 140, estructura lógica Matriz de MF 142 los componentes PEF creados en la Subetapa Bl y ejecuta las siguientes subetapas: Subetapa Cl. Identificar los componentes PEF y crear los Modelos
Funcionales
En esta subetapa, como se muestra en la Figura 2C, el Procesador 150 identifica los componentes PEF disponibles en la Memoria General 140, creados en la Subetapa B 1 y realiza la especificación de conceptos PEF según el protocolo cargado en la Subetapa Al. Luego crea los Modelos Funcionales, los cuales especifican la funcionalidad que utilizará el Procesador 150 para instanciar la aplicación tipo software para "el caso". El Procesador 150 lleva a cabo los siguientes pasos: 1. Recorre la lista para identificar qué Concepto PEF corresponde crear en base al Protocolo de Especificación para cada Tipo 00 de los componentes del diseño según se determinó en la Subetapa B l.
2. Para aquellos componentes del diseño cuyo Concepto PEF asociado es una fórmula, crea los siguientes componentes PEF adicionales:
a. Crea un Componente PEF de tipo FxCall y lo vincula con el ModelAttribute que hace uso de la Fórmula dentro de la misma Clase. b. Si la lógica de la fórmula implica el uso de atributos que no pertenecen al componente de diseño dueño del método, crea un Concepto PEF de tipo Dominio para localizar los datos que actuarán como argumentos de la Fórmula. El Procesador 150 almacena los Modelos Funcionales creados en la Memoria de Base de Datos 130, estructura lógica Modelos MF 135.
La conversión del diseño de clases input del proceso, al aplicar el protocolo de especificación funcional PEF, derivan en el conjunto de modelos que luego son interpretados por el Procesador 150, configurado como Instanciador de Modelos 153.
Subetapa C2. Identificar los componentes PEV y crear los Modelos
Visuales
En esta subetapa, como se muestra en la Figura 2C2, el Procesador 150 identifica los componentes PEV disponibles en la Memoria General 140, creados en la Subetapa B2 y realiza la especificación de conceptos PEV según el protocolo cargado en la Subetapa A2. Luego crea los Modelos Visuales, los cuales especifican la funcionalidad que utilizará el Procesador 150 para exponer la aplicación tipo software para "el caso" presentando estructuras de información en el Dispositivo de Entrada/Salida 120, Interface de Aplicación 123. El Procesador 150 lleva a cabo los siguientes pasos: 1. Recorre la lista de Concepto PEF creados en la Subetapa B2 en base a lo determinado en el protocolo de especificación visual (PEV).
2. Para cada Concepto PEV identificado en el paso anterior, crea los modelos Visuales según se establece en el protocolo PEV.
3. Crear un modelo visual de tipo Aplication con un nombre representativo de "el caso".
4. Crear un modelo visual de tipo Menú con un nombre representativo y un Grupo de Menú por cada uno de los componentes de diseño, asignando al grupo el nombre del componente de diseño.
5. Crear dentro de cada grupo de Menú, dos Menú ítem, uno para cada modelo visual creado por componente de diseño. Ejemplo: para el componente clase 1, crear un grupo de Menú llamado "Clase" y luego dos Menú Item: uno llamado "ABM Clasel" y otro llamado "List Clase 1". Asociar a cada Menú Item el modelo visual correspondiente con su nombre.
Los modelos visuales se editan sin modificar el vínculo entre el modelo visual y el modelo funcional. Al editar un modelo visual se cambian dimensiones y ubicaciones de los componentes en el layout del dispositivo de Entrada/Salida 120 sin alterar el vínculo que existe entre el Modelo visual y el modelo funcional respectivo, según lo establecen los protocolos cargados en la Etapa A.
El Procesador 150 almacena los modelos visuales en la Memoria de Base de Datos 130, estructura lógica Modelos MV 134.
Etapa C\ Incorporar modelos funcionales y visuales.
En una modalidad de la invención, esta Etapa C es sustitutiva de la Etapa C, como se muestra en la Figura 3B.
En esta etapa, se incorporan modelos funcionales y visuales, creados por un usuario, aplicando manualmente los criterios de los Protocolos definidos en las Subetapas Al y A2. A través del dispositivo de Entrada/Salida 120, un usuario carga en la Memoria de Base de Datos 130, estructura lógica Modelos MF 135, los modelos funcionales creados manualmente. A través del dispositivo de Entrada/Salida 120, un usuario carga en la Memoria de Base de Datos 130, estructura lógica Modelos MV 134, los modelos visuales creados manualmente.
Etapa D. Leer e instanciar los modelos funcionales y visuales como una aplicación de tipo software operable
En esta etapa, el Procesador 150, configurado como Instanciador de Modelos 153 accede a la Memoria de Base de Datos 130 con el objetivo de construir modelos conjugados que aloja en la Memoria General 140. Un modelo conjugado, es un modelo que combina un modelo Funcional MF (definido en base al protocolo PEF) con un modelo Visual MV (definido en base al protocolo PEV), por lo tanto, representa la funcionalidad y la definición de los modelos visuales asociados con algún Recurso UI 133, conjugados en un único modelo que se presenta en la Interface de Aplicación 123, como una aplicación tipo software accesible y operable por un usuario.
El resultado producido por el Procesador 150 configurado como Instanciador de Modelos 153, se expone mediante un servicio de interpretación y entrega de aplicaciones de tipo software. Cuando un usuario se autentica en este servicio, lo primero que recibe es una interfaz de aplicación con la cual podrá comenzar a interactuar.
La interpretación, en el presente invento, es un proceso que se ejecuta como servicio y mediante la lectura de modelos conjugados (Modelos MF + Modelos MV + Recursos UI), resuelve frente a la interacción del usuario, las acciones que éste vaya ejecutando sobre una aplicación de tipo software expuesta en el Dispositivo de Entrada/Salida 120, Interface de Aplicación 123.
Como resultado principal de la ejecución del sistema 100 se obtiene: Una aplicación tipo software expuesta en la Interface de Aplicación 123.
Un set de información generada por el usuario, en interacción con la aplicación tipo software, comúnmente llamado "datos del usuario", que el Procesador 150 almacena en la Memoria de Base de Datos 130, estructura lógica Objetos 136.
Para lograr este resultado, el Procesador 150, configurado como Instanciador de Modelos 153, lleva a cabo las siguientes subetapas:
Subetapa DI. Leer e interpretar los modelos visuales MV
Los modelos (tanto funcionales como visuales) son estructuras que respetan los protocolos cargados en la Etapa A, almacenadas en la Memoria de Base de Datos 130, estructuras lógicas PEF 132 y PEV 131 respectivamente.
En esta subetapa, el Procesador 150, configurado como Instanciador de Modelos 153, lee los modelos visuales de la Memoria de Base de Datos 130, estructura lógica Modelos MV 134 que se encuentran almacenados y validados según las definiciones del protocolo PEV cargado en la Subetapa A2.
Una vez leído el modelo visual, el sistema 100 construye una estructura tipo layout que organiza la disposición de las instancias de ModelObject y ActionLinks sobre el layout y almacena dicha estructura en la Memoria General 140, estructura lógica Matriz de Componentes UI 141.
Subetapa D2. Leer e interpretar los modelos funcionales MF
En esta subetapa, el Procesador 150, en su función de Instanciador de Modelos 153, lee los modelos funcionales de la Memoria de Base de Datos 130, estructura lógica Modelos MF 135 que se encuentran almacenados y validados según las definiciones del protocolo PEF cargado en la Subetapa Al.
El Procesador 150 del sistema 100 procesa tres tipos de modelos funcionales: modelos de cálculo, modelos de datos persistidos y modelos de datos interactivos:
Modelos de cálculo: procesa las expresiones de las clases fórmula que se encuentran en el repositorio MF transportando la expresión al servicio que la resuelve devolviendo el resultado como una instancia de ModelAttribute a través de FxCall. Modelos de datos persistidos: procesa la expresión de acceso a la Memoria de Base de Datos 130 que proveen las clases Dominio, las cuales actúan sobre el repositorio de Objetos 136, ejecutando la que se encuentran en el repositorio MF.
Modelos de datos interactivos: procesa los datos que el usuario ingresa en la Interface de Aplicación 123, de manera interactiva a través de los ActionLinks de cada ViewModel con el cual interactúa el usuario.
Una vez leído el modelo funcional, el Procesador 150 del sistema 100 interpreta e instancia una estructura tipo business y la almacena en la Memoria General 140, estructura lógica Matriz de Componentes UI 141, asociada a la estructura visual creada en la Subetapa DI, donde los vínculos entre los modelos visuales y modelos funcionales instanciados responden a la lógica de los protocolos cargados en la Etapa A.
Subetapa D3. Seleccionar y Compaginar los Recursos UI
Los Recursos UI son los componentes de software pre-alojados en la Memoria de Base de Datos 130, estructura lógica Recursos UI, que al ejecutarse asociados a un modelo visual permiten la generación del dibujo de la pantalla en la Interface de Aplicación 123. Son las definiciones de procesamiento de los modelos visuales. En la industria del Software se comercializan distintos sets de recursos de UI, que pueden ser incorporados al sistema como se indica en la Subetapa A3, para ofrecer diferentes modos de visualización para las aplicaciones tipo software resultantes.
Para completar cada modelo conjugado, el sistema 100 selecciona un componente de la Matriz MF 142, su correspondiente componente de la Matriz MV 143 y un Recurso UI 133 compatible con el tipo de MV seleccionado. El Procesador 150, configurado como Compaginador de UI 152, compagina los componentes seleccionados entregando como argumento de las funciones del Recurso UI, las partes del modelo conjugado (Modelo MF + Modelo MV asociado) que el componente requiere para funcionar.
De esta manera el Procesador 150 expone un componente conjugado en el Dispositivo de Entrada/Salida 120, repitiendo el procedimiento para cada uno de los componentes creados para "el caso". Un componente expuesto constituye una pantalla operativa de una aplicación de tipo software que presenta botones de acción, casillas donde el usuario puede ingresar datos y otras funcionalidades que estén abarcadas por el modelo conjugado. Por ejemplo: Un ModelClass Artículo que tiene un ModelAttribute nombre, se expone en un AbmViewModel que define una pantalla con un TextEditor para editar la instancia del MOdelAttribute Nombre. Esta pantalla define una función por cada ActionLink del Model View.
El ViewModel especifica que utilizará el Componente UI llamado "control TextBox 3d" para mostrar el nombre, por lo cual el Procesador 150 compagina el componente mencionado que se encuentra almacenado en la Memoria Rcursos UI 133 para completr el modelo conjugado. Esta compaginación permite que la casilla de texto nombre se muestre en el dispositivo de Entrada/Salida 120 con una apariencia 3d coloreada, según las características del componente "control TextBox 3d". El componente de tipo TextEditor, se conjuga con el Recurso UI textbox 3D y se asocia con la funcionalidad ModelAttribute para lograr que el Procesador 150 instancie en la Interface de Aplicación 123 un cuadro donde un usuario pueda ingresar un texto, que tenga una apariencia tridimensional y soporte la recepción del texto para luego persistir el dato en la Memoria de Base de Datos 130, estructura lógica Objetos 136.
Subetapa D4. Resolver las instancias de ModelClass invocadas
Una vez resuelta la compaginación en la Subetapa D3, se encuentran en la Memoria General 140, estructura lógica Matriz de Componentes UI 141, los modelos conjugados que formarán la aplicación de tipo software resultante. El Procesador 150, configurado como Instanciador de Modelos 153, obtiene las instancias del ModelObject asociado al modelo conjugado (ModelClass- ViewModel-Recurso UI) que se expone al usuario. Los AttributeValues correspondientes a la instancia seleccionada se envían al dispositivo de Entrada/Salida 120, Interface de Aplicación 123 según el layout definido en el modelo conjugado y de este modo se presenta ante el usuario una pantalla de aplicación tipo software operable.
Subetapa D5. Recibir y resolver peticiones de usuario
Una vez expuesta la visualización en el dispositivo de Entrada/Salida 120, Interface de Aplicación 123, el usuario acciona presionando algún botón, ingresando algún dato en alguna de las casillas, desplegando alguna lista de opciones, o accediendo a alguna de las estructuras visuales disponibles. Cuando esto sucede, el Procesador 150, configurado como Instanciador de Modelos 153, ejecuta la función correspondiente al modelo funcional que conforma el modelo conjugado sobre el cual está accionando el usuario, a través de un ActionLink o cualquiera de las funcionalidades existentes, según se define en el protocolo PEF cargado en la Subetapa Al.
Subetapa D6. Exponer Instancias de ModelClass actualizadas
Una vez resuelto el modelo conjugado, el Procesador 150, configurado como Instanciador de Modelos 153, se produce una actualización de instancia del modelo conjugado que está expuesto en el dispositivo de Entrada/Salida 120, Interface de Aplicación 123. El Procesador 150 toma la instancia nueva y actualiza el dispositivo de Entrada/Salida 120 con los cambios producidos.
Ejemplo de Aplicación del Método:
Dado un caso, que consta de un diagrama de clases como el que se expone en la Figura 2C1 y un diagrama de pantallas como el que se expone en la Figura 2D, se ejecutan las etapas del método, así: ■ Etapa A. Cargar los protocolos en la memoria
Esta etapa es considerada la inicialización del sistema, dado que por única vez se cargan los protocolos y eventualmente se agregan Recursos UI al sistema.
■ Etapa B. Identificar y Almacenar componentes de Diseño
En esta etapa se toman el diseño de clases y el diseño de pantallas de "el caso" y se realizan las siguientes subetapas:
(i) Subetapa Bi. identificar los componentes del diseño funcional
Por cada uno de los componentes del diagrama de clases, se identifican los correspondientes componentes PEF, aplicando el protocolo de especificación funcional PEF, cargado en la Subetapa Al, así:
Tabla 1
Component
e del diseño TipoOO Nombre Concepto PEF Nombre Modelo a crear
Clase 1 Clase Clase 1 ModelClass Modelol Clase 1 Atributo Atributo 1 ModelAttribute Modelo Atributo 1
Modelo
Clase 1 Atributo atributoClase2_Rel 1 ModelAttribute atributoClase2_Rel 1
Clase 2 Clase Clase 2 ModelClass Modelo Clase 2
Clase 2 Atributo Atributoó ModelAttribute Modelo Atributoó
Clase 2 Atributo Atributo7 ModelAttribute Modelo Atributo7
Modelo
Clase 2 Atributo atributoClase 1 _Rel 1 ModelAttribute atributoClase l_Rel 1
Clase 3 Clase Clase 3 ModelClass Modelo 3
Clase 3 Atributo Atributo 1 ModelAttribute Modelo Atributo 1
Clase 3 Atributo Atributo2 ModelAttribute Modelo Atributo2
Clase 3 Método Calcular Formula Calcular
Clase 3 Método Validar(Datos_Validar) Formula Validar(Datos_Validar)
Clase 3 No existe Datos_Validar Dominio Datos_Validar
Clase 3 No existe FxCallCalcular FxCall FxCallCalcular
Clase 3 No existe FxCallValidar FxCall FxCallValidar
Clase 4 Clase Clase 4 ModelClass Modelo 4
Clase 4 Atributo Atributo3 ModelAttribute Modelo Atributo3
Clase 4 Método Buscar(Datos_Buscar) Formula Buscar(Datos_Buscar)
Clase 4 No existe Datos_Buscar Dominio Datos_Buscar
Clase 4 No existe FxCallBuscar FxCall FxCallBuscar
Clase 5 Clase Clase 5 ModelClass Modelo 5
Clase 5 Atributo Atributo9 ModelAttribute Atributo9
Clase 5 Método Reportar Formula Reportar
Clase 5 No existe Datos_Reportar Dominio Datos_Reportar
FxCallReportar:Datos_Rep FxCallReportar:Datos_Rep
Clase 5 No existe ortar FxCall ortar
Relación 1 Atributo Atributo 8 ModelAttribute Modelo Atributo 8
Modelo
Relación 1 Atributo RatributoClase l_Rel 1 ModelAttribute RatributoClase l_Rel 1
Modelo
Relación 1 Atributo RatributoClase2_Rel 1 ModelAttribute RatributoClase2_Rel 1
ModelRelationCl
Relación 1 Relación Relación 1 ass Modelo Relación 1
El usuario ingresa esta lista, columnas 1, 2 y 3 (Componentes del diseño, Tipo 00 y Nombre) de la Tabla 1, a través del Dispositivo de Entrada/Salida 120, interface de CDF 121 y el Procesador 150 la almacena en la Memoria General 140, estructura lógica Matriz de MF 142. Luego, el Procesador 150, configurado como Validador de Modelos 151, lee el protocolo de especificación funcional PEF cargado en la Subetapa Al, completa las columnas 3 y 4 (Concepto PEF y Nombre del modelo a crear) de la Tabla 1, y actualiza la Memoria General 140, estructura lógica Matriz de MF 142 con estos datos.
(ii) Subetapa B2. Identificar los componentes del diseño visual
Por cada uno de los componentes del diseño de pantallas, se identifican los correspondientes componentes PEV, aplicando el protocolo de especificación visual PEV, cargado en la Subetapa A2, así:
Tabla 2
Componente funcional Concepto PEF Concepto PEV Modelo Visual a crear
Clase 1 ModelClass ABM Clase 1
ABM View Model
Clase 1 ModelAttribute List Clase 1
List View Model
Clase 1 ModelAttribute
Clase 2 ModelClass
Clase 2 ModelAttribute ABM View Model ABM Clase 2
Clase 2 ModelAttribute List View Model List Clase 2
Clase 2 ModelAttribute
Clase 3 ModelClass
Clase 3 ModelAttribute
Clase 3 ModelAttribute
Clase 3 Formula ABM View Model ABM Clase 3
Clase 3 Formula List View Model List Clase 3
Clase 3 Dominio
Clase 3 FxCall
Clase 3 FxCall
Clase 4 ModelClass
Clase 4 ModelAttribute
ABM View Model ABM Clase 4
Clase 4 Formula
List View Model List Clase 4
Clase 4 Dominio
Clase 4 FxCall
Clase 5 ModelClass ABM View Model ABM Clase 5 Clase 5 ModelAttribute List View Model List Clase 5
Clase 5 Formula
Clase 5 Dominio
Clase 5 FxCall
Relación 1 ModelAttribute
Relacionl ModelAttribute List View Model List View Relación 1
Relación 1 ModelAttribute Tree View Model Tree View Relacionl
Relacionl ModelRelationClass
El Procesador 150, configurado como Validador de Modelos 151, toma la lisa de componentes funcionales residente en la Memoria General 140, estructura lógica Matriz de MF 142 y la expone en el dispositivo de Entrada/Salida 120, interface de CDV 122, tal como se muestra en la columna 1 y 2 (Componente funcional, Concepto PEF) de la Tabla 2. El Procesador 150, lee el protocolo de especificación visual PEV cargado en la Subetapa A2, y completa las columnas 3 y 4 (Concepto PEF, Modelo visual a crear) y actualiza la Memoria General 140, estructura lógica Matriz de MV 143 con estos datos. ■ Etapa C. Crear modelos funcionales y visuales
Para los componentes funcionales y visuales identificados en la Etapa B del presente ejemplo, se realizan las siguientes subetapas:
(iü) Subetapa Cl. Identificar ios componentes PEF crear ios Modelos Funcionales
El Procesador 150 identifica los componentes PEF disponibles en la Memoria General 140, Matriz de MF 142, correspondientes a las columnas 3 y 4 (Concepto PEF y Nombre del modelo a crear) de la Tabla 1, y realiza la especificación de conceptos PEF según el protocolo cargado en la Subetapa Al . Recorre la lista, identifica el concepto PEF, y crea los componentes definidos para la matemática en los métodos que así lo requieren según la definición del protocolo PEF. Esta especificación implica identificar el concepto PEF y sus correspondientes estructuras lógicas en la Memoria de Base de Datos 130, para crear los modelos funcionales y almacenarlos en la estructura lógica Modelos MF 135. En el presente ejemplo, se obtiene como resultado de esta etapa la siguiente lista de modelos funcionales, almacenados en la Memoria de Base de Datos 130, estructura lógica Modelos MF 135:
Tabla 3
Concepto PEF Nombre Modelo MF
ModelClass Modelo 1
ModelAttribute Modelo Atributol
ModelAttribute Modelo atributoClase2_Rell
ModelClass Modelo Clase 2
ModelAttribute Modelo Atributoó
ModelAttribute Modelo Atributo7
ModelAttribute Modelo atributoClasel_Rell
ModelClass Modelo 3
ModelAttribute Modelo Atributol
ModelAttribute Modelo Atributo2
Formula Calcular
Formula Validar(Datos_Validar)
Dominio Datos_Validar
FxCall FxCallCalcular
FxCall FxCallValidar
ModelClass Modelo 4
ModelAttribute Modelo Atributo3
Formula Buscar(Datos_Buscar)
Dominio Datos_Buscar
FxCall FxCallBuscar
ModelClass Modelo 5
ModelAttribute Atributo9
Formula Reportar
Dominio Datos_Reportar
FxCall FxCallReportar: Datos_Reportar
ModelAttribute Modelo Atributo 8
ModelAttribute Modelo RatributoClasel_Rell
ModelAttribute Modelo RatributoClase2_Rell
ModelRelationClass Modelo Relación 1 La estructura técnica de creación de los modelos funcionales se puede observar en la Figura 2C1, donde cada componente de la Tabla 3, se exhibe, relacionado con el concepto del Protocolo PEF que le corresponde.
(iv) S betapa C2. Identificar los componentes PEV y crear los Modelos Visuales El Procesador 150 identifica los componentes PEV disponibles en la Memoria General 140, Matriz de MV 143, correspondientes a las columnas columnas 3 y 4 (Concepto PEF, Modelo visual a crear) de la Tabla 2, y realiza la especificación de conceptos PEV según el protocolo cargado en la Subetapa A2.
En el presente ejemplo, se obtiene como resultado de esta etapa la siguiente lista de modelos visuales, almacenados en la Memoria de Base de Datos 130, estructura lógica Modelos MV 134:
Tabla 4
Componente funcional i Concepto PEV i Modelo Visual a crear
" ΑΒΜ~ν ε™ΜοΤεΓ~~~~~™
Clase 1 1 List View Model j List Clase 1
Clase 1
Clase 2 i ABM View Model j ABM Clase 2
Clase 2 I List View Model j List Clase 2
Clase 2
Clase 2
Clase 3 1 ABM View Model i ABM Clase 3
Clase 3 1 List View Model i List Clase 3
Clase 3
Clase 3
Clase 3
Clase 3
Clase 3
Clase 3
Clase 4 1 ABM View Model i ABM Clase 4
Clase 4 1 List View Model j List Clase 4
Clase 4
Clase 4
Clase 4
Clase 5 j ABM View Model j ABM Clase 5
Clase 5 i List View Model j List Clase 5
Clase 5 :
Clase 5 : Clase 5
Relación 1 List View Model i List View Relación 1
Relación 1 Tree View Model j Tree View Relacionl
Relación 1
Relación 1
■ Etapa D. Leer e instanciar los modelos funcionales y visuales como una aplicación de tipo software operable
Subetapa DI. Leer e interpretar los modelos visuales MV
Se ejecuta el proceso indicado en la Subetapa DI del invento, partiendo de la lista del ejemplo de la Tabla 4.
Subetapa D2. Leer e interpretar los modelos funcionales MF
Se ejecuta el proceso indicado en la Subetapa D2 del invento, partiendo de la lista del ejemplo de la Tabla 3.
Subetapa D3. Seleccionar y Compaginar los Recursos UI
Se compaginan los recursos UI seleccionados para mostrar las pantallas requeridas en el diseño de pantallas, hasta lograr un diseño visual como el de la Figura 2D asociada. Subetapa D4. Resolver las instancias de ModelClass invocadas
A medida que el usuario opera sobre la Interface de Aplicación, es sistema resuelve, ejecutando las acciones enumeradas en la Subetapa D4 del presente invento.
Las siguientes subetapas se producen en la medida que el usuario interactúa con la aplicación resultante del ejemplo:
Subetapa D5. Recibir y resolver peticiones de usuario
Subetapa D6. Exponer Instancias de ModelClass actualizadas
Se debe entender que la presente invención no se halla limitada a las modalidades descritas e ilustradas, pues como será evidente para una persona versada en el arte, existen variaciones y modificaciones posibles que no se apartan del espíritu de la invención, el cual solo se encuentra definido por las siguientes reivindicaciones.

Claims

REIVINDICACIONES
Un método implementado por computador que instancia automáticamente y expone aplicaciones tipo software operativas a partir de especificaciones de diseño de software, que comprende las etapas: a. cargar mediante un Dispositivo de Entrada/Salida 120, el protocolo de especificación funcional (PEF), el protocolo de especificación visual (PEV) y los recursos UI y almacenarlos en una memoria de base de datos 130;
b. identificar, validar contra los protocolos de la etapa a y almacenar componentes de diseño funcional y componentes de diseño visual a partir de especificaciones de diseño de software en la memoria de base de datos 140;
c. crear automáticamente modelos funcionales y modelos visuales a partir de los componentes de diseño funcional y visual identificados en la etapa b, y almacenar dichos modelos en la memoria de base de datos 130, estructuras lógicas Modelos MF 135 y Modelos MV 134 respectivamente; y
d. leer, instanciar y exponer automáticamente, en el Dispositivo de Entrada/Salida 120, Interface de Aplicación 123, mediante el procesador 150, configurado como instanciador de modelos 153, los modelos funcionales y visuales creados en la etapa c, conjugados con los recursos UI, siguiendo las normas de los protocolos almacenados en la Etapa A.
El método de la reivindicación 1 donde la etapa b comprende las subetapas: a. identificar los componentes del diseño funcional a partir de un diseño de clases cargados desde memorias o dispositivos de entrada; y
b. identificar los componentes del diseño visual a partir del diseño de pantallas cargados desde memorias o dispositivos de entrada.
El método de la reivindicación 1 donde la etapa c comprende las subetapas: a. procesar mediante una unidad de procesamiento central el protocolo de especificación funcional (PEF) para identificar sus componentes, y; b. procesar mediante una unidad de procesamiento central el protocolo de especificación visual (PEV) para identificar sus componentes y crear los modelos visuales, dichos modelos visuales será almacenados en una memoria de bases de datos;
El método de la reivindicación 1 donde la etapa d comprende las subetapas: a. leer y procesar mediante una unidad de procesamiento central los modelos visuales;
b. leer y procesar mediante una unidad de procesamiento los modelos funcionales;
c. realizar el procesamiento mediante una unidad de procesamiento central de los modelos funcionales para seleccionar y compaginar con los componentes de la interface de usuario;
d. procesar mediante una unidad de procesamiento central los componentes de los modelos funcionales para resolver las instancias de las metaclases invocadas por el usuario mediante su interacción a través de dispositivos de entrada y salida;
e. recibir y resolver las peticiones de usuario realizadas a través de dispositivos de entrada y salida y procesarlas por una unidad de procesamiento central; y
f. exponer en dispositivos de visualización las instancias de la metaclases actualizadas.
El método de la reivindicación 2 donde la subetapa a, comprende los pasos: a. procesar mediante una unidad de procesamiento central los diagramas funcionales almacenados en la memoria para identificar las clases incluidas en dicho diagrama, y;
b. identificar el nombre de cada clase y almacenarlo en la memoria de base de datos.
El método de la reivindicación 2 donde la subetapa b comprende los pasos: a. crear los modelos visuales a partir de las clases identificadas aplicando el protocolo de especificación visual y almacenarlo en la memoria de base de datos; y
b. editar la apariencia de los modelos visuales creados y almacenados en la memoria de base de datos utilizando dispositivos de entrada y salida en caso de ser requerido;
El método de la reivindicación 3 donde la subetapa a comprende los pasos: a. procesar mediante una unidad de procesamiento central la lista de modelos funcionales para crear los objetos incluidos en dichos modelos funcionales siguiendo el protocolo de especificación funcional cargados en la memoria permanente para cada uno de los componentes; y b. procesar mediante una unidad de procesamiento central los componentes de los diagramas funcionales que están asociados a una fórmula matemática para crear componentes adicionales que permitan la ejecución de dicha fórmula y almacenarlo en la memoria de base de datos.
El método de la reivindicación 3 donde la subetapa b comprende los pasos: a. procesar a través de una unidad de procesamiento central la lista de conceptos funcionales almacenada en la memoria de base de datos para definir para cada concepto funcional un concepto del protocolo de especificación visual (PEV);
b. crear los modelos visuales para cada concepto funcional y almacenarlo en la memoria de base de datos;
c. crear un modelo visual para la aplicación con un nombre representativo del caso y almacenarlo en la memoria de base de datos; y
d. crear un modelo visual de tipo menú con un nombre representativo y un grupo de menú por cada uno de los componentes de diseño, asignando al grupo el nombre del componente de diseño y almacenarlo en la memoria de base de datos.
9. Un sistema que instancia y expone aplicaciones tipo software operativas a partir de especificaciones de diseño de software, que comprende:
a. un dispositivo de entrada/salida 120 configurado como Interface de CDF 121, Interface de CDV 122, Interface de Aplicación 123 para ingresar las especificaciones de diseño de software y exponer las aplicaciones tipo software resultantes;
b. una unidad de procesamiento central (CPU) 110 conectada al dispositivo de entrada/salida 120 que contiene:
. una memoria general 140 está en comunicación con el dispositivo de entrada/salida 120, que interactúa con el procesador 150, configurada para almacenar de manera volátil los componentes funcionales, visuales y componentes UI; y
. un procesador 150 configurado para recibir al menos una especificación de diseño de software a través del dispositivo de Entrada/Salida 120; dicho procesador configurado como validador de modelos 151 para validar la especificación de diseño de software contra los protocolos de la Etapa A, e identificar los correspondientes modelos funcionales y visuales;
dicho procesador configurado como compaginador de UI 152 para compaginar la aplicación tipo software resultante, conjugando los modelos funcionales, visuales y recursos UI; y,
dicho procesador configurado como instanciador de modelos 153 para exponer la aplicación tipo software resultante en la Interface de Aplicación 123; y
c. una memoria de base de datos 130 conectada a la CPU 110, en comunicación con el procesador 150, configurada para almacenar en forma estática, el protocolo de especificación Visual PEV en una estructura lógica PEV 131, el protocolo de especificación funcional PEF en una estructura lógica PEF 132 y los recursos UI en una estructura lógica Recursos UI 133 y también configurada para almacenar en forma dinámica, modelos visuales en una estructura lógica Modelos MV 134, modelos funcionales en una estructura lógica Modelos MF 135 y objetos en una estructura lógica Objetos 136.
10. El sistema de la reivindicación 9 donde la unidad de procesamiento central se caracteriza por:
a. recuperar los modelos de diseño almacenados en el dispositivo de entrada y hacer el procesamiento de validación de dichos modelos de diseño contra los protocolos de validación funcional (PEF) cargados en la memoria permanente;
b. recuperar los modelos de diseño de interfaces de usuario almacenados en el dispositivo de entrada y hacer el procesamiento de validación de dichos modelos de diseño de interfaces de usuario contra los protocolos de validación visual (PEV) cargados en la memoria permanente;
c. realizar el procesamiento de interpretación de modelos funcionales y almacenarlos en la memoria de base de datos;
d. realizar el procesamiento de interpretación de modelos visuales y almacenarlos en la memoria de base de datos;
e. recuperar de la memoria de base de datos los modelos funcionales y los modelos visuales, realizar el procesamiento de compaginación e interacción entre ellos, crear la interfaces de usuario, almacenar dichas interfaces de usuario en la memoria permanente y presentar la aplicación tipo software en los dispositivos de entrada y salida
11. El sistema de la reivindicación 9 donde el dispositivo de entrada se caracteriza por:
a. permitir ingresar los diagramas funcionales a una memoria general que serán recuperados por la unidad de procesamiento central para crear los modelos funcionales;
b. permitir ingresar los diseños de pantallas a una memoria general que serán recuperados por la unidad de procesamiento central para crear los modelos visuales.
PCT/IB2016/052806 2015-05-13 2016-05-13 Método implementado por computador que expone aplicaciones tipo software a partir de especificaciones de diseño WO2016181368A1 (es)

Priority Applications (11)

Application Number Priority Date Filing Date Title
CN201680040249.2A CN107851001B (zh) 2015-05-13 2016-05-13 用于基于设计规格显示软件型应用程序的计算机应用的方法
DK16792290.5T DK3296866T3 (da) 2015-05-13 2016-05-13 Fremgangsmåde implementeret af en computer, der præsenterer software-lignende applikationer baseret på designspecifikationer
CA2985954A CA2985954A1 (en) 2015-05-13 2016-05-13 Computer-applied method for displaying software-type applications based on desing specifications
ES16792290T ES2936090T3 (es) 2015-05-13 2016-05-13 Método implementado por computador que expone aplicaciones tipo software a partir de especificaciones de diseño
MX2017014472A MX2017014472A (es) 2015-05-13 2016-05-13 Metodo implementado por computador que expone aplicaciones tipo software a partir de especificaciones de diseño.
BR112017024159-5A BR112017024159B1 (pt) 2015-05-13 2016-05-13 Método implementado por computador e sistema que apresenta aplicações tipo software baseado em especificações de projeto
JP2017559053A JP6725535B2 (ja) 2015-05-13 2016-05-13 設計仕様書に基づきソフトウェアタイプアプリケーションを表示するコンピュータに実装された方法
FIEP16792290.5T FI3296866T3 (fi) 2015-05-13 2016-05-13 Tietokoneella toteutettava menetelmä, joka esittää ohjelmistotyyppisiä sovelluksia suunnittelumääritysten mukaisesti
EP16792290.5A EP3296866B1 (en) 2015-05-13 2016-05-13 Method implemented by a computer that presents software-type applications based on design specifications
IL255563A IL255563B (en) 2015-05-13 2017-11-09 A method implemented using a computer that displays software-type applications based on designed specifications
CONC2017/0011542A CO2017011542A2 (es) 2015-05-13 2017-11-10 Método implementado por computador que expone aplicaciones tipo software a partir de especificaciones de diseño

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562161216P 2015-05-13 2015-05-13
US62/161,216 2015-05-13

Publications (1)

Publication Number Publication Date
WO2016181368A1 true WO2016181368A1 (es) 2016-11-17

Family

ID=57247885

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2016/052806 WO2016181368A1 (es) 2015-05-13 2016-05-13 Método implementado por computador que expone aplicaciones tipo software a partir de especificaciones de diseño

Country Status (14)

Country Link
US (1) US10379817B2 (es)
EP (1) EP3296866B1 (es)
JP (1) JP6725535B2 (es)
CN (1) CN107851001B (es)
BR (1) BR112017024159B1 (es)
CA (1) CA2985954A1 (es)
CO (1) CO2017011542A2 (es)
DK (1) DK3296866T3 (es)
ES (1) ES2936090T3 (es)
FI (1) FI3296866T3 (es)
IL (1) IL255563B (es)
MX (1) MX2017014472A (es)
PT (1) PT3296866T (es)
WO (1) WO2016181368A1 (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10831449B2 (en) 2015-04-28 2020-11-10 Lexica S.A.S. Process and system for automatic generation of functional architecture documents and software design and analysis specification documents from natural language
US10303441B2 (en) 2015-04-28 2019-05-28 Nadia Analía Huebra Process and system for automatic generation of functional architecture documents and software design and analysis specification documents from natural language
US10956681B2 (en) 2018-01-30 2021-03-23 Google Llc Creating apps from natural language descriptions
CN109343849A (zh) * 2018-09-25 2019-02-15 珠海格力电器股份有限公司 一种系统、系统ui的设计方法及工业触摸屏
CN109814480B (zh) * 2019-01-18 2021-10-08 广州宁基智能系统有限公司 Plc与线控程序之间的可视化交互方法及系统
US11762634B2 (en) * 2019-06-28 2023-09-19 Asg Technologies Group, Inc. Systems and methods for seamlessly integrating multiple products by using a common visual modeler
CN110428223A (zh) * 2019-07-23 2019-11-08 中国建筑第八工程局有限公司 建筑施工安全交底的方法、系统及bim+vr管理平台
CN112000318B (zh) * 2020-08-31 2022-02-08 中国科学院长春光学精密机械与物理研究所 光电对抗装备教学训练系统通用架构方法、设备及介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6289513B1 (en) * 1999-06-01 2001-09-11 Isaac Bentwich Interactive application generation and text processing
US20090183092A1 (en) * 2007-10-03 2009-07-16 Britesoft Solutions (M) Sdn Bhd Customizable application system
US20110088011A1 (en) * 2009-10-14 2011-04-14 Vermeg Sarl Automated Enterprise Software Development
US20120110558A1 (en) * 2010-10-29 2012-05-03 Microsoft Corporation Customized binaries on-the-fly
US8255869B2 (en) * 2008-06-30 2012-08-28 Rockwell Automation Technologies, Inc. Industry template customization and transclusion for use in industrial automation and information solutions

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08320784A (ja) * 1995-05-26 1996-12-03 Nec Corp プログラム作成方法
US6681383B1 (en) * 2000-04-04 2004-01-20 Sosy, Inc. Automatic software production system
US20020077823A1 (en) 2000-10-13 2002-06-20 Andrew Fox Software development systems and methods
US20030028579A1 (en) 2001-08-06 2003-02-06 Kulkarni Vinay Vasant Process for component-based application development
US7694272B2 (en) * 2002-10-21 2010-04-06 Sungard (Israel) Ltd Method, a language and a system for the definition and implementation of software solutions by using a visualizable computer executable modeling language
WO2004086222A2 (en) 2003-03-26 2004-10-07 Bizplus Limited Development of software systems
US8156469B2 (en) * 2005-12-29 2012-04-10 Sap Ag Single composition of pattern modules
CN100451954C (zh) * 2005-12-29 2009-01-14 吉林大学 框架定制的模型驱动软件生成方法
US20080016176A1 (en) * 2006-07-13 2008-01-17 Ofir Leitner System for development of games for mobile devices and distribution thereof
JP2008052356A (ja) * 2006-08-22 2008-03-06 Hitachi Software Eng Co Ltd ソースコード自動生成装置
US7734560B2 (en) * 2006-08-23 2010-06-08 Sap Ag Loose coupling of pattern components with interface regeneration and propagation
CN101004680B (zh) * 2006-11-23 2011-06-22 福建顶点软件股份有限公司 一种以直接对象模型定义为核心的灵活快捷的软件开发方法及支持系统
US20100160039A1 (en) * 2008-12-18 2010-06-24 Microsoft Corporation Object model and api for game creation
US8701080B2 (en) * 2010-04-05 2014-04-15 Accenture Global Services Limited Template components having constraints representative of best practices in integration software development
US20120210296A1 (en) 2011-02-14 2012-08-16 Microsoft Corporation Automatically creating business applications from description of business processes
JP2015026139A (ja) * 2013-07-24 2015-02-05 富士電機株式会社 プログラム生成装置、プログラム生成方法、およびプログラム生成用プログラム
US10303441B2 (en) 2015-04-28 2019-05-28 Nadia Analía Huebra Process and system for automatic generation of functional architecture documents and software design and analysis specification documents from natural language

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6289513B1 (en) * 1999-06-01 2001-09-11 Isaac Bentwich Interactive application generation and text processing
US20090183092A1 (en) * 2007-10-03 2009-07-16 Britesoft Solutions (M) Sdn Bhd Customizable application system
US8255869B2 (en) * 2008-06-30 2012-08-28 Rockwell Automation Technologies, Inc. Industry template customization and transclusion for use in industrial automation and information solutions
US20110088011A1 (en) * 2009-10-14 2011-04-14 Vermeg Sarl Automated Enterprise Software Development
US20120110558A1 (en) * 2010-10-29 2012-05-03 Microsoft Corporation Customized binaries on-the-fly

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3296866A4 *

Also Published As

Publication number Publication date
JP2018514878A (ja) 2018-06-07
DK3296866T3 (da) 2022-12-19
EP3296866B1 (en) 2022-09-14
EP3296866A1 (en) 2018-03-21
IL255563B (en) 2020-03-31
FI3296866T3 (fi) 2023-01-13
IL255563A (en) 2018-01-31
US20170068519A1 (en) 2017-03-09
CO2017011542A2 (es) 2018-01-31
CN107851001B (zh) 2021-11-23
BR112017024159A2 (pt) 2018-07-17
ES2936090T3 (es) 2023-03-14
US10379817B2 (en) 2019-08-13
JP6725535B2 (ja) 2020-07-22
CA2985954A1 (en) 2016-11-17
EP3296866A4 (en) 2019-01-16
CN107851001A (zh) 2018-03-27
BR112017024159B1 (pt) 2024-02-20
PT3296866T (pt) 2023-01-17
MX2017014472A (es) 2018-07-06

Similar Documents

Publication Publication Date Title
ES2936090T3 (es) Método implementado por computador que expone aplicaciones tipo software a partir de especificaciones de diseño
US10025565B2 (en) Integrated software development environments, systems, methods, and memory models
US7774745B2 (en) Mapping of designtime to runtime in a visual modeling language environment
US8527943B1 (en) System and method of application development
CA2819008C (en) Method and system for displaying selectable autocompletion suggestions and annotations in mapping tool
TWI577539B (zh) 用於運行時間系統的電腦實施方法、電腦可讀取儲存記憶體及系統
Lee Building environment rule and analysis (BERA) language
Marin et al. Generating native user interfaces for multiple devices by means of model transformation
Price C# 10 and. NET 6–Modern Cross-Platform Development: Build apps, websites, and services with ASP. NET Core 6, Blazor, and EF Core 6 using Visual Studio 2022 and Visual Studio Code
Günther et al. Design principles for internal domain-specific languages: A pattern catalog illustrated by ruby
Wojszczyk et al. The process of verifying the implementation of design patterns—used data models
Samoylov Learn Java 12 Programming: A step-by-step guide to learning essential concepts in Java SE 10, 11, and 12
Trivedi User interface implementation of environmental data integration system with React
Priya et al. CODE PRESENCE USING CODE SENSE.
Kimura Kanji Architectural Pattern
FERRERO LIGORRED Development of a large-scale flutter app
Löffelmann et al. Microsoft Visual Basic 2010 Developer's Handbook
Pigula et al. Unified compile-time and runtime java annotation processing
Osenkov Designing, implementing and integrating a structured C# code editor
De Carlos et al. Runtime translation of model-level queries to persistence-level
Soden Operational semantics for MOF metamodels
Meiser Visualization Techniques for Rule-based Reasoning in Uncertain Knowledge Bases
Liang Automatic generation of software applications: a platform-based MDA approach
Ráth et al. Automated model transformations in domain specific visual languages
Lee et al. Object-oriented design

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: 16792290

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 255563

Country of ref document: IL

ENP Entry into the national phase

Ref document number: 2017559053

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: NC2017/0011542

Country of ref document: CO

Ref document number: MX/A/2017/014472

Country of ref document: MX

ENP Entry into the national phase

Ref document number: 2985954

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016792290

Country of ref document: EP

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112017024159

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112017024159

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20171109