[go: up one dir, main page]

WO2014090514A1 - Procédé de création de simulateur de configuration client - Google Patents

Procédé de création de simulateur de configuration client Download PDF

Info

Publication number
WO2014090514A1
WO2014090514A1 PCT/EP2013/074093 EP2013074093W WO2014090514A1 WO 2014090514 A1 WO2014090514 A1 WO 2014090514A1 EP 2013074093 W EP2013074093 W EP 2013074093W WO 2014090514 A1 WO2014090514 A1 WO 2014090514A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
rules
user
inference
manufacturing
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/EP2013/074093
Other languages
English (en)
Inventor
Charles BENSOUSSAN
Alain Bensoussan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
TECHFORM
Original Assignee
TECHFORM
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by TECHFORM filed Critical TECHFORM
Publication of WO2014090514A1 publication Critical patent/WO2014090514A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming

Definitions

  • the present invention relates to the field of software simulation methods.
  • It relates more particularly to a software application generation method for manipulating variable data linked together, in a manner consistent with coherence rules.
  • the invention aims first and foremost at a method of creating a custom integrated software application for a mobile computer comprising means of communication to an Internet-type data exchange network,
  • said application comprising a man-machine interface of the Model View Controller (MVC) type, consisting on the one hand of a data model, on the other hand of a visual interface and finally an event logic controller, said method comprising graphical means for enabling a user to develop said software application without directly writing computer code.
  • MVC Model View Controller
  • the event logic controller imposes relationships between the data of the model and the elements of the visualization according to a configurable set of coherence rules and rules of inference between these data, called "business rules" and defining an inference engine applied to model data and visualization elements.
  • the method includes a module for defining the user of these business rules without requiring the user to write lines of computer code directly.
  • the data on which the consistency rules are to be applied are visually designated on the human-machine interface by the user, and mathematical link rules between various data, or maximum or minimum thresholds are defined by the user.
  • Another aspect of the invention is a method for creating a software simulator of a product that can be configured according to different variants according to data defining the needs and constraints of a client, said method being intended to be implemented by a computer comprising means of communication to an Internet-type data exchange network,
  • said application comprising a man-machine interface of the MVC type, comprising:
  • said method comprising first graphical means for defining logical links between the data, to enable a user to develop said software simulator without directly writing computer code,
  • the invention is a method for creating and adapting custom built applications for PC media, mobile terminal or web network to allow a user to design, develop and deploy an application on computer terminal (tablet PC , smartphone, PC), said application allowing, in real time or in disconnected mode, to users professional customers (for example carpenters resellers, designers of electrical cabinets ..), commercial users, marketing or the office and Production, configure, manage, edit on screen, print and generate structured data to their databases (ERP, MRP, PDM) from configurable product and service information obtained in real time through choice of options and variants.
  • the method implements a display tree, in which the user chooses to display only part of a data schema on which he wants to work and the method applies links and rules of simple coherence and inference only on the elements constituting this part.
  • the method comprises a step of generating a set of data called "manufacturing data", generated from the display data and a set of manufacturing rules, previously defined.
  • the business rule definition module includes consistency rules applicable to these business rules, so as to highlight the possible conflicts between some of these rules during their generation by the user.
  • Another aspect of the invention is a method of manufacturing a product that can be configured according to different variants according to data defining the needs and constraints of a customer, comprising a method for creating a software simulator of a product such as as explained above.
  • the invention aims in yet another aspect a product / computer program adapted to implement a method as described above.
  • Figure 1 a schematic view of the elements involved in the implementation of a method according to the present description
  • FIG. 2 a flowchart of the different steps of the process.
  • the method is intended to be implemented in software by a set of computer systems.
  • the method comprises firstly a phase 100 of creation, by a company 32, provider of products or services, of an application configured according to a set of information presentation rules and calculation rules, these rules being specific to the business 32, and usually referred to as business rules (see Figures 1 and 2).
  • This phase of creation 100 is also called in the following description "software configuration", the method then being referred to as the "client configuration simulator creation method”.
  • this is an algorithmic modeling of the business rules of the company 32, and their presentation in an ergonomically clever and playful form to a user 22 to use data representative of variables related to the business of the business. enterprise 32.
  • the goal is to achieve a simulation system usable by a user 22, not expert in the business of enterprise 32, and yet complies with all its consistency rules.
  • the company 32 may be a manufacturer of portals. These portals are achievable according to various options, for example in a number of different materials, shapes and textures, and in various variants, for example variable width and height. In a more detailed example, they are possibly divisible into two doors, the sum of the widths corresponds to a portal location width. Different materials can be used for the doors, to the extent of the respect of certain constraints techniques. The heights of the two side edges of the gate may vary, within construction limits.
  • the purpose here is to propose a portal configuration simulator, enabling a potential customer 22 of the company 32 to configure a portal that corresponds to his specific data and his desires, without ever having to worry about the rules. which govern the relationships of the variables defining the portal between them.
  • a configurator must make it possible to vary as continuously as possible the parameters available to the user 22.
  • an implementation cost variable can be associated in real time with each configuration.
  • a second aim is to then correctly generate a manufacturing specification formatted according to the data presentation rules relevant for the manufacturer 32.
  • This first phase 100 of the method therefore accepts as inputs various business rules and a graphical representation mode of the data, and outputs a source code corresponding to a software configurator achieving the specified goals higher, that is to say by for example a software for defining a portal configuration that meets the particular needs and constraints of customers 22.
  • the method involves a first computer system 10, here called development server.
  • This development server 10 comprises a display screen 1 1, and hosts one or more software applications.
  • the application server 10 is for example a PC type computer, known per se. It may have conventional means of communication to the network, wired and / or radio. It is adapted to host in memory and execute a software application representing the part of the method implemented by said development server 10.
  • the method comprises secondly a phase 200 of use of the software application created, this use being carried out for example but not limited to the premises of the company 32. This use is similar, as has been said, performing a simulation process.
  • This simulation method makes it possible, for example, to configure a product intended for manufacturing according to the specific needs of a customer 22, and integrating the business rules of the company 32, that is to say, for example, manufacturing rules and sizing.
  • the method involves first, for this second phase 200, a computer system 15, here called application server (see Figure 1).
  • This application server 15 comprises a display screen 1 1, and hosts one or more software applications.
  • the application server 15 is for example a PC type computer, known per se. It has conventional means of communication to the network, wired and / or radio. It is adapted to host in memory and to execute a software application representing the part of the method implemented by said application server 15.
  • This application server 15 houses in particular the software application (called configurator) generated during the phase of the application. software configuration.
  • the second phase 200 of the method furthermore involves at least one second computer system, here called the user terminal 20.
  • this user terminal 20 is of PC type.
  • the user terminal 20 comprises calculation means (for example microprocessor), memory devices, and communication means 16 to the radio network. It is adapted to download and execute a software application containing the part of the method implemented by said user terminal 20.
  • Such a user terminal 20 is of a type known per se, and is therefore not detailed further here.
  • the user terminal 20 accesses via an Internet-type network to an application server 15, on which the application corresponding to the business rules of the company 32 is executed.
  • the user terminal 20 and the application server 15 are combined into a single machine, on which the software application (the configuration simulator) is executed. It will be understood that this second phase 200 of the method may involve several user terminals 20, or numerous application servers 15 whose applications (configuration simulators) may be totally different and relating to products independent of the company 32.
  • the method also implements an ERP enterprise data management server 30, associated with a set of terminals 35.
  • the data modified by the actions on the user terminals 20 on the application server 15 are transferred to the ERP server 30, for example in the form of manufacturing data.
  • Figure 2 illustrates a flowchart of the steps of a method according to an embodiment of the invention.
  • the configurator creation process is a hierarchical structure modeller of the enterprise data 32.
  • Data representation and manipulation module The following are the main modules involved in the implementation of the configuration method.
  • Data representation and manipulation module The following are the main modules involved in the implementation of the configuration method.
  • the data used in the configuration process is stored and manipulated as one or more hierarchical data structures.
  • the hierarchical data structure is the basic structure of the configuration engine. This hierarchical data structure is the one used in the inference engine implemented in the method.
  • the hierarchical data structure uses data access modules and links between the data for its assignment and the sets of definitions of each value.
  • the hierarchical data structure makes it possible to store and manipulate all the data of the company 32 with the same logic without worrying about its physical persistence and how it is formatted on the screen.
  • Each hierarchical data structure has a name in relation to its data schema, that is, a list of strongly typed fields, and a set of other data structures, possibly of different types.
  • variables are not dynamic as in Javascript (registered trademark), they have a strict type (integer, character string, date).
  • the configuration method secondly uses a schema describing the rules that govern a hierarchical structure of data.
  • a rules scheme is defined here as the description of the structure and set of rules that define a hierarchical structure of data.
  • An XSD format schema can be derived from a rule schema and can thus be used in http exchanges over an Internet type data communications network.
  • Inference rules associated with each simple type variable make the data structure active for value changes.
  • the hierarchical structure of data can be associated with an inference engine that allows the propagation and the resolution of the induction caused by the two rules associated with each simple type.
  • a change rule functions as an event when changing the value of a variable in a hierarchical data structure, so this rule is an explicit rule. It should be noted that there is not cascading here as in computer (the rule modifying in turn other variables which trigger in turn their explicit rule), one respects on the contrary the steps of the engine of inference. Unlike the definition rules (see below), a change rule only executes if the value of the variable has been modified, it does not take into account relationships with other variables, in inference steps the rule change is calculated before the definition rules.
  • a definition rule is used to define the value of a variable in a hierarchical data structure, depending on its environment. We recall here that a definition rule is the basis of inference, it is a rule that defines the value of the variable according to other variables.
  • This unique reference identifier Uri is the address of the variable in a hierarchical structure.
  • a set of write rules on these identifiers are defined.
  • a search method "Find” makes it possible to find an element according to its unique identifier of reference, a particular syntax makes it possible to search a hierarchical structure of data according to the value of one of its fields.
  • the unique reference identifier Uri serves to know the address of the associated variable.
  • Complex algorithms are of the WebRules or BusinessRules type, they are algorithmic rules that make it possible to link structures to each other, for example to transform a structure of configuration data into a structure for printing, or for injection into a type of software ERP, etc.
  • An extension is optionally made to a hierarchical data structure to add one or more search indexes in the case of a set of data, and to rely on the method known per se "Link".
  • a hierarchical data structure is a set of data that can only persist in memory.
  • a generic tool is used in the present configuration method for storing these collections of data structures in persistent memory. This generic tool is a collection of persistent data structures.
  • a collection of hierarchical data structures is associated with a single rule schema that describes the behavior of all elements (hierarchical data structures) in the collection.
  • a collection of data structures is also associated with a set of data providers (content providers made available for making configurations) that allow the physical storage of the collection according to different storage strategies.
  • a collection of data structures must be stored on disk, database, delocalized storage services (“cloud”), or other according to the strategy, and each strategy to its provider.
  • cloud delocalized storage services
  • conventional data providers are used, in memory, in the database, but other providers may be envisaged, such as the storage of data in lists of a type known per se under the name of SharePoint -the trademark- , in remote storage services (Cloud) or external data storage centers (Datacenters).
  • the method further comprises a module for representing the data manipulated in the previous module, in a format compatible with a display on computers connected to an Internet type network.
  • This exhibition is in the form of web services using the Microsoft architecture (IIS 7.0, WCF, .Net 3.5) (registered trademarks).
  • the REST architecture uses standards, in particular: URI as a universal syntax for addressing resources, HTTP a stateless protocol with a very limited number of operations,
  • Hyperlinks in (X) HTML and XML documents to represent both the content of the information and the transition between states of the application
  • the technological choices for implementation of the web service are an IIS 7.0 (registered trademark) server as a hosting platform for the service (application server 15), and in a non-limiting example of implementation of the method, a writing of the Windows Communication Foundation (WCF) service by using an object link to communicate the data model and the specific "binding" view that exposes (ie generates a visual interface) this service. respecting the REST architecture.
  • WCF is a package of Microsoft (registered trademark) that encloses communication protocols, this package is used in the present process for Silverlight (registered trademark), but not for html5.
  • the web server implemented in the present method offers services in the format compliant with the REST (Representational State Transfer) constraints in XML or JSON, or possibly another format known to those skilled in the art.
  • REST Representational State Transfer
  • the data is obtained from a web service to be linked (in the sense of the object link to communicate the data model and the user -binding) to the visual controls.
  • the method also includes a web service that supports the persistence and management of current configurations. It is built around an architecture of configurable caches, in order to give this Web service a great fluidity of use.
  • This web service contains temporary objects that allow the execution of different configurations, each is identified by a ticket whose life is managed by a strategy based on conditions specific to the application or client considered.
  • the method uses a set of descriptions of the data structure collections that make up the configuration.
  • the method further uses descriptors of collections of hierarchical structures of data sharing the same rule scheme (ie associated with the same inference engine).
  • Each collection of hierarchical data structures has its own customer data provider. Remember that a collection must be stored on disk, database, cloud, or other according to the strategy, and each strategy to its provider.
  • the method works on a set of basic variables (intended to be accessible to a user of the configurator).
  • a change in the value of a base variable causes the inference engine to start (the data manipulation module, ie the rule schema).
  • This module makes it possible to define rules in the databases which cause an event (example an addition, a modification). This event is related to the data cache (update) or the inference engine (modification of a definition rule).
  • a base variable is associated with constraints defined in the schema and rules verified by the inference engine. Some basic variables are associated with a parameter that defines their set of possible values.
  • the method retains, in the present nonlimiting example of implementation, at least one chronological list describing the basic variables modified by the user or the inference engine.
  • Each basic variable is described in particular by the location of the basic variable as well as its value, or by a set of key pairs / possible values for a base variable, this list defines the set of possible values of a base variable according to the state of a hierarchical data structure.
  • a configuration performed for a client 22 is a series of operations performed within a flow of data similar to a workflow.
  • the purpose of the configurator creation process is to propose a certain number of logical operator models and graphical objects that can be assembled within a parameterizable flow.
  • the method of creating a configurator uses the data and functionality of the data manipulation module, and the technologies known as Wpf, Wcf, Wf.
  • the method of creating an online configurator is based on an architecture of the type known as Multi-Tier (Multilevel Architecture), which means that some logical graphical objects are hosted in Web Services.
  • Multi-Tier Multilevel Architecture
  • the configurator creation method described here by way of example, provides a means of generating a client / server configurator in a simple and accessible manner.
  • the models proposed must be flexible to answer all the configurations.
  • the method includes configuration sessions on the associated server, and at each data modification the method makes a call to the associated session (cookie) which infers and returns the result to the client terminal 20.
  • a rule of the WebRule type is called which injects data from one session to another respecting a set of rules, so no calculation and no data is stored at the client 20 (according to a philosophy of "thin client").
  • the graphic objects are developed in Wpf language
  • the parameterization of the graphic objects is done by a simple push of a component and a link of the objects between them (binding) for allow communication between the data model and user visualization) semi automatic to the hierarchical structure of data within the Studio (registered trademark).
  • these hierarchical structures are (dynamic) data models.
  • the method comprises a data presentation module.
  • This data presentation module has the function of presenting the data (color, customer language, associated label, type of control), and modifying them using a graphic tool in the Studio (registered trademark).
  • a display is generated (frame) in the display technology used (Xaml or html5, or other to come) by applying the link objects between them (binding).
  • the method implements a step that makes it possible to navigate from a first data presentation module to a second data presentation module, in following the process desired by the customer. In this step, it ensures the passage of session identifiers, the return to the previous and the communication between the data presentation modules.
  • the display follows the flow of the data presentation modules by activating the associated "frame" (form or userControl).
  • Style sheets are provided for setting up configurations, allowing customization of the configuration in a few clicks.
  • the method uses several types of distinct elements:
  • command descriptor an object that allows (or causes) the transition of the data flow from a graphic object to another graphic object or a logical operator.
  • a command causes through a rule the passage of a data presentation module to another, or the call of a WebRule (calculation on the server)
  • a first step 1 10 of the phase 100 of software configurator creation the company 32 proceeds to the identification of the variables making it possible to define the products that it wants its customers to configure.
  • the inference rules are identified, then in a third step 130, the modes of representation of the variables are defined.
  • the system then proceeds, in a step 140, to a consistency check of the inference rules defined above. It then generates, in a step 150, a visual interface for users 22 of the configurator.
  • manufacturing rules are defined by the company 32, based on the variables defined in step 1 10.
  • the system displays, for the user 22, at least part of a data schema.
  • the user 22 modifies data according to his own needs, and the inference engine propagates the modifications to the other variables linked by inference rules.
  • the engine passes through several states that cycle cyclically until the stabilization of the data set or the detection of recurrence of cyclic data.
  • a first step 220 the system is waiting for modifications from a user 22 of the method.
  • the system Upon receipt of such a change, in a step 222, the system executes the relevant change rules.
  • the change rules are executed for all values in the edit stack, each change rule can change other data that is in turn stored in the next change stack.
  • the system searches for the use cases of the definition rules.
  • the search for the use cases is made in several states: first, all the definition rules are executed to determine the data used for each rule, subsequently only the rules related to the modified values are executed.
  • the definition rules are executed according to the modification stack and the use cases.
  • Each edit rule updates the relevant data that is added to the edit stack if it is really different from the previous value.
  • the system updates, in a step 228, all the data. All modified data is stored in a modification stack before being stored and compared to a data history. This edit stack is used to prevent the data set from being changed during the execution of the different rules. Each rule is executed from the same definition set, which avoids the problem execution of code on a set of data in modification.
  • the new configuration is displayed in a step 230 on the user interface.
  • the stabilization of the data set is obtained when there is no more modified data (variation below a predetermined threshold).
  • a cycle data does not converge to a set of values, but regularly returns to the same set of values
  • another strategy is deployed taking into account the history of the modifications.
  • it is sought, when updating the data, if an identical set has existed in the past.
  • selection rules previously entered by the company 32, are used to determine the best set of data among the sets returning regularly during the execution of the inference engine.
  • a step 240 the system generates the manufacturing data of the product defined by the user 22 and corresponding to its own needs and constraints.
  • the system transfers calculation data to an ERP server 30 of the enterprise 32.
  • the operating principle of the method described here differs from the prior art in which one looks at a configuration such as the opening of a plug through code located behind buttons.
  • a configuration is an application flow whose data is transported by hierarchical structures of data and the change of state (graphic object or logical operator) caused by commands.
  • the streams can multiply and merge in some logical operator, which gives the possibility of having multiple states at the same time, i.e., several graphic objects at a time.
  • This graph shows the flow of the configuration,
  • the graphic object passes the hand to the logical operator through a command, possibly subject to user rights.
  • the process uses a basic graphical environment that hosts all the other components, it consists of three areas: - an interactive and contextual Office 2007 (registered trademark) type banner
  • the basic graphical environment is optimized to work both on a workstation and in an internet explorer.
  • the basic graphical environment is not required in a configuration, but it is often the starting object, and it contains the basic commands that start the application flow.
  • the basic graphical environment hosts basic graphics objects.
  • Each such graphic object contains a workspace, and a portion of ribbon (a ribbon is a user interface element, introduced by Microsoft -tag file-, which replaces or supplements the previously known menu buttons and allows grouping commands associated to find them more easily) that will complete the ribbon of the basic graphical environment.
  • ribbon is a user interface element, introduced by Microsoft -tag file-, which replaces or supplements the previously known menu buttons and allows grouping commands associated to find them more easily
  • the ribbon associated with the graphic object is an assembly of group and descriptors of commands which makes it possible to respect the mechanism MVC (Model View Controller, in English "Model View Control”) and it is the commands associated with each button which make it possible to navigate from graphic object to graphic object.
  • MVC Model View Controller, in English "Model View Control”
  • MVC is a method of human-machine software interface design.
  • the human-machine interface comprises on the one hand a data model, on the other hand a visual interface, finally an event logic controller. It is clear that, in implementation variants, the method can also use other methods than MVC to navigate between the graphic objects.
  • Graphical objects are specialized to solve specific problems, but remain parameterizable through the rules associated with their hierarchical structure of data, and adaptable through Microsoft's StackPanel -posted marks- (command allowing to reorganize secondary elements in a hierarchy of elements, on a single line that can be oriented horizontally or vertically) which are enriched with components by dragging and dropping actions of available elements of the hierarchical data structure, in the form of a control.
  • Each logical operator is a linking component between two graphical objects or logical operators. There may be mentioned, for example but not limited to, logical operators of the type sending an email, writing to a file, searching for information in a Web Service.
  • a library of logical operators is provided in the method. This library of logical operators evolves over time.
  • the processed data in a logical operator is a hierarchical structure of data, and the flow continues through commands that are executed by triggers or programmable conditions.
  • An injection of a hierarchical structure of data takes place for the creation of the nomenclature in the ERP. Injection is the term used to transfer data from one structure to another. As a clarification, we can have a complex structure for the configuration of an object, and come and inject the result (significant data) into another structure (a quote instance for example). Once the operation is complete, a command is triggered to continue the flow.
  • the method uses a set of command descriptors. Each command is associated with an image, a state, a description and an implementation.
  • the command descriptors are grouped in an independent command manager. For the purposes of this method, a command descriptor uses the context of the current graphical object as input and provides context for the next graphical object. Because graphical objects can stack in certain configurations, some commands cause the simple closing of a graphic object.
  • An order may be the opening of a customer record, the order must extract the customer code from the current context to position the customer's edition graphic object on the right person.
  • the transport of data in the stream is through hierarchical structures (or containers) of data, the data can transit either through memory or through persistent collections of hierarchical data structures.
  • the software configuration method makes it possible to define the schemas of much easier than current database management systems (DBMS), and to implicitly validate data and inference relationships between data.
  • DBMS database management systems
  • the designer 32 thus more easily manipulates a logical tree; it's easier and more intuitive than making eye-to-eye comparisons.
  • An innovative first part of the process concerns the logical method of modeling business rules ordered in hierarchical structure in different schemas.
  • the intelligent data that represents the business rules is described in the diagram and is based on visualization and connection interfaces.
  • An innovative second part concerns the inference engine that governs the configuration schemas and the associated thousands of rule combinations, in real time at each change of state of the product data introduced by the end user.
  • An innovative third part concerns the automatic generation of computer code allowing the generation of applications of business configurations through a fun studio for non-IT experts.
  • An innovative fourth part concerns the dynamic design of business forms driven by schemas. These forms are generated based on the target platform of client computers (Silverlight, Windows8, HTML5 - registered trademarks).
  • This engine and the rules associated with the schemas are resident on web servers in the CLOUD and are accessible to laptops or user tablets in Windows, Android and IPAD (registered trademarks) multi-platform mode.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention vise un procédé de création d'une application logicielle intégrée sur mesure pour ordinateur comportant des moyens de communication à un réseau d'échange de données de type Internet, ladite application comportant une interface homme-machine de type MVC, constituée d'une part d'un modèle de données, d'autre part d'une interface visuelle, enfin d'un contrôleur de logique des événements, ledit procédé comportant des moyens graphiques pour permettre à un utilisateur de développer ladite application logicielle sans écrire directement de code informatique, le contrôleur logique d'événements imposant des relations entre les données du modèle et les éléments de la visualisation selon un ensemble paramétrables de règles dites "règles métier", également définies par l'utilisateur sans nécessiter l'écriture directe de lignes de code informatique.

Description

PROCÉDÉ DE CRÉATION DE SIMULATEUR DE CONFIGURATION CLIENT
La présente invention relève du domaine des procédés de simulation logicielle.
Elle concerne plus particulièrement un procédé de génération d'application logicielle permettant de manipuler des données variables liées entre elles, de façon conforme à des règles de cohérence.
Exposé de l'invention
L'invention vise en premier lieu un procédé de création d'une application logicielle intégrée sur mesure pour ordinateur mobile comportant des moyens de communication à un réseau d'échange de données de type Internet,
ladite application comportant une interface homme-machine de type MVC (Model View Controller, méthode de conception d'interface homme- machine de logiciel), constituée d'une part d'un modèle de données, d'autre part d'une interface visuelle, enfin d'un contrôleur de logique des événements, ledit procédé comportant des moyens graphiques pour permettre à un utilisateur de développer ladite application logicielle sans écrire directement de code informatique.
Le contrôleur logique d'événements impose des relations entre les données du modèle et les éléments de la visualisation selon un ensemble paramétrable de règles de cohérence et de règles d'inférence entre ces données, dites "règles métier" et définissant un moteur d'inférence appliqué aux données du modèle et aux éléments de visualisation.
Avantageusement, le procédé comporte un module de définition par l'utilisateur de ces règles métier sans nécessiter l'écriture directe par ledit utilisateur de lignes de code informatique. Les données sur lesquelles doivent s'appliquer les règles de cohérence sont désignées visuellement sur l'interface homme-machine par l'utilisateur, et des règles de lien mathématique entre diverses données, ou de seuils maximums ou minimums sont définis par l'utilisateur. L'invention vise sous un autre aspect un procédé de création d'un simulateur logiciel d'un produit pouvant être configuré selon différentes variantes selon des données définissant les besoins et contraintes d'un client, ledit procédé étant destiné à être mis en œuvre par un ordinateur comportant des moyens de communication à un réseau d'échange de données de type Internet,
ladite application comportant une interface homme-machine de type MVC, comportant :
- un modèle de données,
- une interface visuelle,
- un contrôleur de logique des événements,
ledit procédé comportant des premiers moyens graphiques de définition de liens logiques entre les données, pour permettre à un utilisateur de développer ledit simulateur logiciel sans écrire directement de code informatique,
le contrôleur logique des événements imposant des relations entre les données du modèle et les éléments de la visualisation selon un ensemble paramétrables de règles dites "règles métier", définies par des seconds moyens graphiques de définition de liens logiques entre les données.
On comprend que les produits cités ici peuvent comprendre plusieurs pièces et / ou mécanismes dont les dimensions ou caractéristiques respectives dépendent les unes des autres.
On comprend que l'invention est un procédé permettant de créer et adapter des applications intégrées sur mesure pour les supports PC, terminal nomade ou réseau web pour permettre à un utilisateur de concevoir, de développer et de déployer une application sur terminal informatique (tablette PC, smartphone, PC), ladite application permettant, en temps réel ou en mode déconnecté, à des utilisateurs clients professionnels (par exemple des revendeurs de menuiserie, des concepteurs d'armoires électriques..), des utilisateurs commerciaux, du marketing ou du Bureau d'Etudes et Production, de configurer, gérer, éditer sur écran, imprimer et générer des données structurées vers leurs bases de données (ERP, MRP, PDM) à partir d'informations des produits et services configurables obtenues en temps réel à travers des choix d'options et de variantes.
Dans une mise en œuvre particulière, le procédé met en œuvre une arborescence d'affichage, dans laquelle l'utilisateur choisit d'afficher uniquement une partie d'un schéma de données sur laquelle il veut travailler et le procédé applique des liens et des règles de cohérence et d'inférence simples uniquement sur les éléments constituant cette partie. Avantageusement, le procédé comporte une étape de génération d'un ensemble de données dite "données de fabrication", générées à partir des données d'affichage et d'un ensemble de règles de fabrication, préalablement défini. Dans une mise en œuvre particulière, le module de définition de règles métier comporte des règles de cohérence applicables à ces règles métier, de manière à mettre en évidence les conflits éventuels entre certaines de ces règles lors de leur génération par l'utilisateur. L'invention vise sous un autre aspect un procédé de fabrication d'un produit pouvant être configuré selon différentes variantes selon des données définissant les besoins et contraintes d'un client, comportant un procédé de création d'un simulateur logiciel d'un produit tel qu'exposé plus haut. L'invention vise sous encore un autre aspect un produit / programme d'ordinateur adapté à mettre en œuvre un procédé tel qu'exposé plus haut.
Présentation des figures
Les caractéristiques et avantages de l'invention seront mieux appréciés grâce à la description qui suit, description qui expose les caractéristiques de l'invention au travers d'un exemple non limitatif d'application.
La description s'appuie sur les figures annexées qui représentent : Figure 1 : une vue schématique des éléments impliqués dans la mise en œuvre d'un procédé conforme à la présente description,
Figure 2 : un organigramme des différentes étapes du procédé.
Description détaillée d'un mode de réalisation de l'invention
Le procédé est destiné à être mis en œuvre de façon logicielle par un ensemble de systèmes informatiques.
Le procédé comporte en premier lieu une phase 100 de création, par une entreprise 32, offreur de produits ou de services, d'une application configurée selon un ensemble de règles de présentation d'information et de règles de calcul, ces règles étant spécifiques au métier de l'entreprise 32, et étant usuellement désignées sous le nom de "règles métier" d'une entreprise (voir figures 1 et 2). Cette phase 100 de création est également appelée dans la suite de la description "configuration logicielle", le procédé étant alors cité sous le terme de "procédé de création de simulateur de configuration client".
On comprend qu'il s'agit d'une modélisation algorithmique des règles métier de l'entreprise 32, et de leur présentation sous une forme ergonomiquement astucieuse et ludique à un utilisateur 22 devant utiliser des données représentatives de variables liées au métier de l'entreprise 32. Le but est de parvenir à un système de simulation utilisable par un utilisateur 22, non expert dans le métier de l'entreprise 32, et cependant conforme à toutes ses règles de cohérence.
A titre d'exemple purement explicatif et nullement limitatif, l'entreprise 32 peut être un fabricant de portails. Ces portails sont réalisables selon diverses options, par exemple en un certain nombre de matériaux, formes et textures différents, et selon diverses variantes, par exemple en largeur et hauteur variables. Dans un exemple plus détaillé, ils sont éventuellement divisibles en deux portes, dont la somme des largeurs correspond à une largeur d'emplacement d'implantation du portail. Différents matériaux peuvent être utilisés pour les portes, dans la mesure du respect de certaines contraintes techniques. Les hauteurs des deux bords latéraux du portail peuvent varier, dans des limites de construction.
On comprend que le but est ici de proposer un simulateur de configuration de portail, permettant à un client potentiel 22 de l'entreprise 32 de configurer un portail qui corresponde à ses données spécifiques et à ses envies, sans jamais avoir à se préoccuper des règles métier qui régissent les relations des variables définissant le portail entre elles. Un tel configurateur doit permettre de faire varier de façon aussi continue que possible les paramètres disponibles à l'utilisateur 22. Dans le même temps, une variable de coût de réalisation peut être associée en temps réel à chaque configuration.
Un second but est de générer ensuite de façon correcte un cahier des charges de fabrication mis en forme selon les règles de présentation des données pertinentes pour le fabricant 32.
Cette première phase 100 du procédé accepte donc en entrées des règles métier diverses et un mode de représentation graphique des données, et fournit en sortie un code source correspondant à un configurateur logiciel réalisant les buts spécifiés plus hauts, c'est-à-dire par exemple un logiciel de définition d'une configuration de portail répondant aux besoins et contraintes particulières de clients 22.
Dans cette phase 100 de création de configurateur logiciel, le procédé implique un premier système informatique 10, ici dit serveur de développement. Ce serveur de développement 10 comporte un écran d'affichage 1 1 , et héberge une ou plusieurs applications logicielles. Le serveur d'applications 10 est par exemple un ordinateur de type PC, connu en soi. Il dispose éventuellement de moyens classiques de communication au réseau, par voie filaire et/ ou radioélectrique. Il est adapté à héberger en mémoire et exécuter une application logicielle représentant la partie du procédé mise en œuvre par ledit serveur de développement 10. Le procédé comporte en second lieu une phase 200 d'utilisation de l'application logicielle créée, cette utilisation étant réalisée par exemple mais non limitativement dans les locaux de l'entreprise 32. Cette utilisation s'apparente, comme on l'a dit, à l'exécution d'un procédé de simulation. Ce procédé de simulation permet par exemple de configurer un produit destiné à la fabrication selon les besoins spécifiques d'un client 22, et intégrant les règles métier de l'entreprise 32, c'est à dire, par exemple, des règles de fabrication et de dimensionnement. Le procédé implique en premier lieu, pour cette seconde phase 200, un système informatique 15, ici dit serveur d'applications (voir figure 1 ). Ce serveur d'applications 15 comporte un écran d'affichage 1 1 , et héberge une ou plusieurs applications logicielles. Le serveur d'applications 15 est par exemple un ordinateur de type PC, connu en soi. Il dispose de moyens classiques de communication au réseau, par voie filaire et/ ou radioélectrique. Il est adapté à héberger en mémoire et exécuter une application logicielle représentant la partie du procédé mise en œuvre par ledit serveur d'applications 15. Ce serveur d'applications 15 héberge notamment l'application logicielle (dite configurateur) générée lors de la phase de configuration logicielle.
La seconde phase 200 du procédé implique en outre au moins un second système informatique, dit ici terminal utilisateur 20. Dans le présent exemple, ce terminal utilisateur 20 est de type PC.
Le terminal utilisateur 20 comporte des moyens de calcul (par exemple microprocesseur), des dispositifs mémoire, et des moyens de communication 16 au réseau par voie radioélectrique. Il est adapté à télécharger et exécuter une application logicielle reprenant la partie du procédé mise en œuvre par ledit terminal utilisateur 20.
Un tel terminal utilisateur 20 est de type connu en soi, et n'est donc pas détaillé plus avant ici.
Dans un premier mode de réalisation, le terminal utilisateur 20 accède via un réseau de type Internet à un serveur d'application 15, sur lequel est exécutée l'application correspondant aux règles métier de l'entreprise 32. Dans un second mode de réalisation, le terminal utilisateur 20 et le serveur d'application 15 sont confondus en une seule machine, sur laquelle est exécutée l'application logicielle (le simulateur de configuration). On comprend que cette seconde phase 200 du procédé peut impliquer plusieurs terminaux utilisateurs 20, ou de nombreux serveurs d'applications 15, dont les applications (simulateurs de configuration) sont éventuellement totalement différentes et relatives à des produits indépendants de l'entreprise 32.
Dans un mode particulier, le procédé met également en œuvre un serveur de gestion de données d'entreprises ERP 30, associé à un ensemble de terminaux 35. Dans cette mise en œuvre, les données modifiées par les actions sur les terminaux utilisateurs 20 sur le serveur d'application 15 sont transférées vers le serveur ERP 30, par exemple sous forme de données de fabrication.
Etapes du procédé
La figure 2 illustre un organigramme des étapes d'un procédé conforme à un mode de mise en œuvre de l'invention.
Le procédé de création de configurateur est un modélisateur de structures hiérarchiques des données de l'entreprise 32.
Il utilise en entrées une identification et une définition des variables à considérer dans l'application client, un ensemble de règles de relations entre ces variables (inférences, équations entre ces variables...), des choix de modes de représentation de ces variables pour un utilisateur 22 non spécialiste. Ces entrées sont demandées progressivement à l'entreprise 32 lors de la création du simulateur de configuration, avec une capacité permanente à revenir sur des entrées précédentes, et à modifier celles-ci, de façon interactive.
On définit ci-dessous les principaux modules entrant dans la mise en œuvre du procédé de configuration. Module de représentation et de manipulation des données
Structure hiérarchique de données
Les données utilisées dans le procédé de configuration sont stockées et manipulées sous la forme d'un ou plusieurs structures hiérarchiques de données. La structure hiérarchique de données est la structure de base du moteur de configuration. Cette structure hiérarchique de données est celle qui est utilisée dans le moteur d'inférence mis en œuvre dans le procédé.
La structure hiérarchique de données utilise des modules d'accès aux données et de liens entre les données pour son affectation et les ensembles de définitions de chaque valeur.
La structure de données hiérarchique permet de stocker et de manipuler toutes les données de l'entreprise 32 avec une même logique sans se soucier de sa persistance physique et de la manière dont cela est mis en forme à l'écran.
Chaque structure hiérarchique de données possède un nom en relation avec son schéma de données, c'est-à-dire une liste de champs fortement typés, et un ensemble d'autres structures de données, éventuellement de type différent.
On rappelle que, dans des champs fortement typés, les variables ne sont pas dynamiques comme en Javascript (marque déposée), elles ont un type strict (entier, chaîne de caractères, date).
Schéma de règles
Le procédé de configuration utilise en second lieu un schéma décrivant les règles qui régissent une structure hiérarchique de données.
Un schéma de règles est ici défini comme la description de la structure et de l'ensemble des règles qui définissent une structure hiérarchique de données. Un schéma au format XSD peut être déduit d'un schéma de règles et peut ainsi être utilisé dans les échanges http sur un réseau de communications de données de type Internet.
Dans cette figure, qui illustre un exemple non limitatif d'une partie du contenu d'un schéma de règles, on comprend qu'une variable d'un Type Complexe ici nommée « Toy » est composée d'occurrences d'une variable d'un Type Complexe « Board ». L'ensemble d'occurrence des variables « Board » forme un ensemble de données. Cet ensemble de données peut être représenté sous forme de tableau.
On peut maîtriser cet ensemble d'occurrences aux travers de contraintes, par exemple de valeur minimum ou maximum.
Des règles d'inférences associées à chaque variable de type simple permettent de rendre la structure de données active aux changements de valeur. En effet la structure hiérarchique de données peut être associée à un moteur d'inférence qui permet la propagation et la résolution de l'induction provoquée par les deux règles associées à chaque type simple.
Une règle de changement fonctionne comme un événement lors du changement de valeur d'une variable d'une structure de données hiérarchique, cette règle est donc une règle explicite. Il est à noter qu'il n'y a pas ici enchaînement en cascade comme en informatique (la règle modifiant à son tour d'autres variables qui déclenchent à leur tour leur règle explicite), on respecte au contraire les pas du moteur d'inférence. Contrairement aux règles de définition (voir plus bas), une règle de changement ne s'exécute que si la valeur de la variable a été modifiée, elle ne tient pas compte des relations avec les autres variables, dans les pas d'inférence la règle de changement est calculé avant les règles de définitions. Une règle de définition permet de définir la valeur d'une variable d'une structure de données hiérarchique, en fonction de son environnement. On rappelle ici qu'une règle de définition est à la base de l'inférence, c'est une règle qui définit la valeur de la variable en fonction des autres variables. Contrairement à une règle de changement, une règle de définition est implicite (c'est à dire que, par exemple, dans l'égalité v1 = v2 - v3, si v2 change v1 doit être recalculé). Elle doit déterminer son cas d'emploi pour pouvoir s'exécuter au moment opportun. Pendant un pas d'inférence toutes les règles sont calculées sur le même ensemble de valeur (équipotence entre les valeurs et le résultat), puis toutes les valeurs sont mises à jour, ainsi de suite jusqu'à la stabilisation de l'ensemble.
Identifiant unique de référence
Un identifiant unique de référence (URI=Unique Référence Identifier) permet d'obtenir de manière unique une structure de données hiérarchique ou une donnée particulière dans une structure complexe. Cet identifiant unique de référence Uri est l'adresse de la variable dans une structure hiérarchique.
Un ensemble de règles d'écriture sur ces identifiants sont définies.
Une méthode de recherche « Find » permet de retrouver un élément en fonction de son identifiant unique de référence, une syntaxe particulière permet de rechercher une structure hiérarchique de données en fonction de la valeur d'un de ses champs.
Les identifiants uniques de référence servent principalement pour les piles, l'association d'une entité graphique (TextBox) avec une variable du modèle ("binding") et l'accès aux données dans les algorithmes complexes.
L'identifiant unique de référence Uri sert à connaître l'adresse de la variable associée.
Les algorithmes complexes sont de type WebRules ou BusinessRules, ce sont des règles algorithmiques qui permettent de lier des structures entre elles, par exemple de transformer une structure de données de configuration en une structure pour l'impression, ou pour injection dans un logiciel de type ERP, etc.
Une extension est éventuellement faite à une structure hiérarchique de données pour y ajouter un ou plusieurs index de recherche dans le cas d'ensemble conséquent de données, et pour s'appuyer sur la méthode connue en soi « Link ».
Outil de stockage de structures hiérarchiques de données
Une structure hiérarchique de données, telle que définie précédemment, est un ensemble de données qui ne peut persister qu'en mémoire. Pour pouvoir sauvegarder toutes les structure hiérarchique de données qui composent une configuration (une configuration est représentable comme un ensemble de collections de structures de données), on utilise, dans le présent procédé de configuration, un outil générique pour le stockage de ces collections de structures de données en mémoire persistante. Cet outil générique est une collection de structures de données persistantes. Une collection de structures hiérarchiques de données est associée à un schéma de règles unique qui décrit le comportement de tous les éléments (structures hiérarchiques de données) de la collection.
Une collection de structures de données est également associée à un ensemble de fournisseurs de données (fournisseurs de contenus mis à disposition pour la réalisation de configurations) qui permettent le stockage physique de la collection en fonction de différentes stratégies de stockage.
Une collection de structures de données doit-être stockée sur disque, en base, dans des services de stockage délocalisés ("cloud"), ou autre suivant la stratégie, et chaque stratégie à son fournisseur (provider). On utilise ici par exemple des fournisseurs de données classiques, en mémoire, en base de données, mais d'autres fournisseurs peuvent être envisagés, comme le stockage de données dans des listes de type connu en soi sous le nom de SharePoint -marque déposée-, dans des services de stockage délocalisés (Cloud) ou des centres de stockage de données externes (Datacenters).
Module de gestion graphique et d'exposition sur le Web ("service web")
Le procédé comporte en outre un module de représentation des données manipulées dans le module précédent, selon un format compatible avec un affichage sur des ordinateurs reliés à un réseau de type Internet. Cette exposition se fait sous forme de services Web en utilisant l'architecture de Microsoft (IIS 7.0, WCF, .Net 3.5) (marques déposées).
Dans un premier mode de réalisation, non limitatif, on utilise un service web qui respecte l'architecture REST (de l'anglais Representational State Transfert), connue en soi.
L'architecture REST utilise des standards, en particulier : URI comme syntaxe universelle pour adresser les ressources, HTTP un protocole sans état (en anglais stateless) avec un nombre très limité d'opérations,
Des hyperliens dans des documents (X)HTML et XML pour représenter à la fois le contenu des informations et la transition entre états de l'application,
Les types MIME comme text/xml, text/html, image/jpeg, application/pdf, video/mpeg pour la représentation des ressources. Les choix technologiques d'implémentation du service web sont un serveur IIS 7.0 (marque déposée) comme plate-forme d'hébergement du service (serveur d'application 15), et, dans un exemple nullement limitatif de mise en œuvre du procédé, une écriture du service en WCF (Windows Communication Foundation) en utilisant un lien d'objets pour faire communiquer le modèle de données et la visualisation utilisateur ("binding") spécifique qui expose (c'est à dire génère une interface visuelle) ce service en respectant l'architecture REST. Il est à noter que WCF est un package de Microsoft (marque déposée) qui enferme des protocoles de communication, ce package est utilisé dans le présent procédé pour Silverlight (marque déposée), mais pas pour html5.
Le serveur WEB mis en œuvre dans le présent procédé propose des services au format conforme aux contraintes REST (Representational State Transfer) en XML ou JSON, ou éventuellement un autre format connu de l'homme du métier.
De façon résumée, les données sont obtenues d'un service Web pour être liées (au sens du lien d'objets pour faire communiquer le modèle de données et la visualisation utilisateur -binding-) aux contrôles visuels.
Le procédé comporte également un service web en charge la persistance et la gestion des configurations en cours. Il est bâti autour d'une architecture de caches configurables, de manière à donner à ce service Web une grande fluidité d'utilisation.
Ce service web contient des objets temporaires qui permettent l'exécution de différentes configurations, chacune est identifiée par un ticket dont la durée de vie est gérée par une stratégie fonction de conditions spécifiques à l'application ou au client considérée. Le procédé utilise un ensemble de descriptions des collections de structures de données qui composent la configuration.
Le procédé utilise en outre des descripteurs de collections de structures hiérarchiques de données partageant un même schéma de règles (c'est à dire associées au même moteur d'inférence). Chaque collection de structures hiérarchiques de données possède son propre fournisseur de données clients. On rappelle qu'une collection doit-être stockée sur disque, en base, sur le cloud, ou autre suivant la stratégie, et chaque stratégie à son fournisseur (provider).
Le procédé travaille sur un ensemble de variables de base (destinées à être accessibles à un utilisateur du configurateur).
Une modification de la valeur d'une variable de base entraîne le démarrage du moteur d'inférence (le module de manipulation de données, c'est à dire le schéma de règles). Ce module permet de définir des règles dans les bases de données qui provoquent un événement (exemple un ajout, une modification). Cet événement est lié au cache de données (mise à jour) ou au moteur d'inférence (modification d'une règle de définition).
Par exemple, à titre de clarification, si la valeur d'un stock est modifiée, les règles associées à la quantité restante sont mises à jour pendant la configuration.
Une variable de base est associée à des contraintes définies dans le schéma et à des règles vérifiées par le moteur d'inférence. Certaines variables de base sont associées à un paramètre qui définit leur ensemble des valeurs possibles.
Le procédé conserve, dans le présent exemple non limitatif de mise en œuvre, au moins une liste chronologique décrivant les variables de base modifiées par l'utilisateur ou le moteur d'inférence. Chaque variable de base est décrite notamment par la localisation de la variable de base ainsi que sa valeur, ou par un ensemble de paires clef / valeurs possibles pour une variable de base, cette liste définit l'ensemble des valeurs possible d'une variable de base en fonction de l'état d'une structure hiérarchique de données. Le procédé de création de configurateur
Une configuration effectuée pour un client 22 (par exemple conception d'un portail de dimensions et géométrie spécifiques) est une suite d'opérations effectuées au sein d'un flux de donnée semblable à un flux de travaux (en anglais workflow).
Certaines opérations sont de type logique et d'autres de type graphique
(formulaire). La demanderesse a constaté qu'en affinant la granularité, un grand nombre de formulaires présentent des fonctionnements similaires, seule change la logique permettant au client de gérer le schéma des règles de la structure hiérarchique de données.
En partant de ces observations, le procédé de création de configurateur a pour objectif de proposer un certain nombre de modèles d'opérateurs logiques et d'objets graphiques qui peuvent s'assembler au sein d'un flux paramétrable.
Le procédé de création de configurateur utilise les données et fonctionnalités du module de manipulation de données, et sur les technologies connues sous les noms Wpf, Wcf, Wf.
Le procédé de création de configurateur en ligne s'appuie sur une architecture de type connu sous le nom de Multi-Tier (architecture à plusieurs niveaux), ce qui signifie que certains objets graphiques logiques sont hébergés dans des Services web. Le procédé de création de configurateur, décrit ici à titre d'exemple, offre un moyen de générer un configurateur clients/Serveur d'une manière simple et accessible.
Les modèles proposés doivent être souples pour répondre à toutes les configurations. Pendant une configuration complexe, il peut avoir plusieurs structures en inférence. Etant donné qu'il n'y a pas de données stockées sur le terminal client 20, le procédé comporte des sessions de configuration sur le serveur associé, et à chaque modification de données le procédé fait un appel vers la session associé (cookie) qui infère et renvoie le résultat au terminal client 20. Dans une autre variante de mise en œuvre du procédé, on appelle une règle de type WebRule qui injecte des données d'une session à une autre en respectant un ensemble de règles, ainsi aucun calcul et aucune donnée ne se trouve stockée chez le client 20 (selon une philosophie de "client léger").
Dans un mode de mise en œuvre décrit ici à titre d'exemple non limitatif, les objets graphiques sont développés en langage Wpf, le paramétrage des objets graphiques se fait par un simple push de composant et un lien des objets entre eux (binding) pour permettre la communication entre le modèle de données et la visualisation utilisateur) semi automatique à la structure hiérarchique de données au sein du Studio (marque déposée).
Dans une autre mise en œuvre, ces structures hiérarchiques sont des modèles de données (dynamiques). Pour les associer à un affichage, le procédé comprend un module de présentation de données. Ce module de présentation de données à pour fonction de présenter les données (couleur, langue du client, étiquette associé, type de contrôle), et de les modifier à l'aide d'un outil graphique dans le Studio (marque déposée).
A partir de ce module de présentation de données, on génère un affichage (frame) dans la technologie d'affichage utilisée (Xaml ou html5, ou autre à venir) en appliquant le lien des objets entre eux (binding).
Pour lier tous les modules de présentation de données (associés chacun à une structure hiérarchique de données), le procédé met en œuvre une étape qui permet de naviguer d'un premier module de présentation de données à un second module de présentation de données, en suivant le processus désiré par le client. Dans cette étape, on s'assure du passage des identifiants de session, du retour au précédent et de la communication entre les modules de présentation de données.
L'affichage suit le flux des modules de présentation de données en activant la présentation ("frame") (formulaire ou userControl) associée.
Cette manière de paramétrer les formulaires permet de rendre accessible la technologie SilverLight (marque déposée) ou html5 (ou autre dans des variantes de mise en œuvre du procédé) très complexe et non accessible au non informaticien. Des feuilles de style sont fournies pour l'habillage des configurations, permettant la personnalisation de la configuration en quelques clics.
Le procédé utilise plusieurs types d'éléments distincts :
environnement graphique de base, muni d'un menu interaction et d'un espace de travail contenant des objets graphiques.
· objet graphique de base fourni dans une bibliothèque.
opérateur logique (objet de calcul) ayant une fonctionnalité précise.
descripteur de commande, objet permettant (ou provoquant) la transition du flux de données d'un objet graphique vers un autre objet graphique ou un opérateur logique. Une commande provoque au travers d'une règle le passage d'un module de présentation de données à un autre, ou l'appel d'une WebRule (calcul sur le serveur)
structure hiérarchique de données, objet permettant le stockage des données fournies par les différents composants
Fonctionnement du procédé
Le fonctionnement du procédé est illustré par l'organigramme de la figure
2.
Dans une première étape 1 10 de la phase 100 de création de configurateur logiciel, l'entreprise 32 procède à l'identification des variables permettant la définition des produits qu'elle veut faire configurer par ses clients 22. Dans une seconde étape 120, les règles d'inférence sont identifiées, puis dans une troisième étape 130, les modes de représentation des variables sont définis. Le système procède alors, dans une étape 140, à une vérification de cohérence des règles d'inférence définies précédemment. Il génère alors, dans une étape 150, une interface visuelle destinée aux utilisateurs 22 du configurateur. Dans une étape 160, des règles de fabrication sont définies par l'entreprise 32, sur la base des variables définies dans l'étape 1 10. Dans une étape 210 de la phase 200 d'utilisation du configurateur, le système affiche, à destination de l'utilisateur 22, au moins une partie d'un schéma de données.
Puis l'utilisateur 22 vient modifier des données en fonction de ses besoins propres, et le moteur d'inférence propage les modifications aux autres variables liées par des règles d'inférence.
Plus précisément, lors du fonctionnement du moteur d'inférence, le moteur passe à travers plusieurs états qui s'enchainent de manière cyclique jusqu'à la stabilisation de l'ensemble de données ou à la détection de la récurrence de données cycliques.
Dans une première étape 220, le système est en attente de modifications de la part d'un utilisateur 22 du procédé.
Lors de la réception d'une telle modification, dans une étape 222, le système exécute les règles de changement pertinentes. Les règles de changement sont exécutées pour toutes les valeurs se trouvant dans la pile de modification, chaque règle de changement peut changer d'autres données qui sont à leur tour stockées dans la prochaine pile de modification.
Puis dans une étape 224, le système recherche les cas d'emploi des règles de définition. La recherche des cas d'emploi se fait en plusieurs états : dans un premier temps toutes les règles de définitions sont exécutées pour déterminer les données utilisées pour chaque règle, par la suite ne sont exécutées que les règles liées aux valeurs modifiées.
Il exécute alors dans une étape 226 les règles de définition pertinentes. Les règles de définitions sont exécutées en fonction de la pile de modification et des cas d'emploi. Chaque règle de modification met à jour la donnée concernée qui vient s'ajouter dans la pile de modification si celle-ci est réellement différente de la valeur précédente.
Puis le système met à jour, dans une étape 228, l'ensemble des données. Toutes les données modifiées sont stockées dans une pile de modification avant d'être mémorisées et comparées à un historique des données. Cette pile de modification sert pour éviter que l'ensemble des données soit modifié pendant l'exécution des différentes règles. Chaque règle est exécutée à partir du même ensemble de définition, ce qui évite le problème d'exécution de code sur un ensemble de données en modification.
Lorsque ces données sont stabilisées, la nouvelle configuration est affichée dans une étape 230 sur l'interface utilisateur. La stabilisation de l'ensemble de données est obtenue quand il n'y a plus de données modifiées (variation inférieure à un seuil prédéterminé). Dans le cas de cycle (données ne convergent pas vers un ensemble de valeurs, mais revenant régulièrement sur un même jeu de valeurs) une autre stratégie est déployée en tenant compte de l'historique des modifications. Pour détecter les cycles, on recherche, lors de la mise à jour des données, si un ensemble identique a existé dans le passé. Dans ce cas, des règles de choix, préalablement entrées par l'entreprise 32, sont utilisées pour la détermination du meilleur ensemble de données parmi les ensembles revenant régulièrement lors de l'exécution du moteur d'inférence.
Dans une étape 240, le système génère les données de fabrication du produit défini par l'utilisateur 22 et correspondant à ses besoins et contraintes propres.
Enfin, dans une étape optionnelle 250, le système transfère des données de calcul à un serveur de type ERP 30 de l'entreprise 32.
Le principe de fonctionnement du procédé décrit ici se distingue de l'art antérieur dans lequel on regarde une configuration comme l'ouverture d'une fiche au travers de code se trouvant derrière des boutons.
On imagine qu'une configuration est un flux applicatif dont la donnée est transportée par des structures hiérarchiques de données et le changement d'état (objet graphique ou opérateur logique) provoqué par des commandes. Dans le procédé décrit ici, les flux peuvent se multiplier et fusionner dans certain opérateur logique, ce qui donne la possibilité d'avoir plusieurs états en même temps, c'est-à-dire plusieurs objets graphiques à la fois.
On observe sur ce graphique le flux de déroulement de la configuration, L'objet graphique passe la main à l'opérateur logique au travers d'une commande, éventuellement soumise à des droits utilisateur.
Le procédé utilise un environnement graphique de base qui héberge tout les autres composants, il est formé de trois zones : - un bandeau d'affichage type Office 2007 (marque déposée) interactif et contextuel,
- un objet de présentation sous forme d'onglet, et
- un espace de travail qui héberge les différents objets graphiques.
L'environnement graphique de base est optimisé pour fonctionner aussi bien sur un poste de travail que dans un explorateur internet.
L'environnement graphique de base n'est pas obligatoire dans une configuration, mais il est souvent l'objet de démarrage, et il contient les commandes de bases qui démarrent le flux applicatif.
L'environnement graphique de base héberge des objets graphiques de base. Chaque tel objet graphique contient un espace de travail, et une partie de ruban (un ruban est un élément d'interface utilisateur, introduit par Microsoft -marque déposée-, qui remplace ou complète les boutons des menus connus précédemment et permet de regrouper des commandes associées pour les retrouver plus facilement) qui complétera le ruban de l'environnement graphique de base.
Il existe une bibliothèque d'objets graphiques spécialisés (saisie de données, recherche, ...), un outil est proposé pour la conception d'un objet graphique, celui-ci étant associé à une structure hiérarchique de données, qui lui sert de contexte et une collection de structures hiérarchiques de données (associée à un schéma de règles unique) pour l'accès aux données, un mécanisme simple de push de composant est proposé au concepteur avec le minimum de variable de paramétrage.
Le ruban associé à l'objet graphique est un assemblage de groupe et de descripteurs de commandes qui permet de respecter le mécanisme MVC (Modèle Vue contrôleur, en anglais "Model View Contrôler") et ce sont les commandes associées à chaque bouton qui permettent de naviguer d'objet graphique en objet graphique. On rappelle que MVC est une méthode de conception d'interface homme-machine de logiciel. Dans cette méthode, l'interface homme-machine comporte d'une part un modèle de données, d'autre part une interface visuelle, enfin un contrôleur de logique des événements. Il est clair que, dans des variantes de mise en œuvre, le procédé peut également utiliser d'autres méthodes que MVC pour naviguer entre les objets graphiques.
Les objets graphiques sont spécialisés pour résoudre des problèmes spécifiques, mais restent paramétrables au travers des règles associées à leur structure hiérarchique de données, et aménageables au travers de StackPanel de Microsoft -marques déposées- (commande permettant de réorganiser des éléments secondaires dans une hiérarchie d'éléments, sur une seule ligne pouvant être orientée horizontalement ou verticalement) qui sont enrichies de composants par des actions de glisser / déposer d'éléments disponibles de la structure hiérarchique de données, sous forme de contrôle.
Chaque opérateur logique (objet de calcul) est un composant de liaison entre deux objets graphiques ou opérateurs logiques. On peut citer, par exemple mais non limitativement, des opérateurs logiques du genre envoi d'un mail, écriture dans un fichier, recherche d'information dans un Web Service.
Une bibliothèque d'opérateurs logiques est fournie dans le procédé. Cette bibliothèque d'opérateurs logiques évolue dans le temps.
La donnée traitée dans un opérateur logique est une structure hiérarchique de données, et la poursuite du flux se fait au travers de commandes qui sont exécutés par des déclencheurs ou des conditions programmables.
Dans l'exemple simple de création d'une nomenclature dans un logiciel de planification des ressources de l'entreprise (ERP), il existe un opérateur logique spécialisé pour cette opération, la structure hiérarchique de données en entrée est un extrait de la configuration, l'opérateur logique possède sa propre structure hiérarchique de données de nomenclature.
Une injection d'une structure hiérarchique de données a lieu pour la création de la nomenclature dans l'ERP. L'injection est le terme que l'on emploie pour transférer des données d'une structure à une autre. A titre de clarification, on peut avoir une structure complexe pour la configuration d'un objet, et venir injecter le résultat (données significatives) dans une autre structure (une occurrence de devis par exemple). Une fois l'opération terminée, une commande est déclenchée pour la poursuite du flux.
Le procédé utilise un ensemble de descripteurs de commande. Chaque commande est associée à une image, un état, une description et une implémentation. Les descripteurs de commande sont regroupés dans un gestionnaire de commande indépendant. Au sens du présent procédé, un descripteur de commande utilise en entrée le contexte de l'objet graphique courant et fournit un contexte à l'objet graphique suivant. Comme les objets graphiques peuvent s'empiler dans certaines configurations, certaines commandes provoquent la simple fermeture d'un objet graphique.
Pour clarifier la notion d'empilement des objets graphiques, on note que dans le procédé, on a un système de navigation dans lequel l'utilisateur peut avancer dans le processus, mais aussi revenir en arrière, ou au départ.
On a donc un fil d'Ariane (ou empilement) composé de module de présentation de données, et certaine commande permettent de manipuler ce fil, (suivant, retour, fin, revenir au début, ...)
Une commande peut-être l'ouverture d'une fiche client, la commande doit extraire le code du client du contexte courant pour positionner l'objet graphique édition du client sur la bonne personne.
Le transport des données dans le flux se fait au travers de structures (ou conteneurs) hiérarchiques de données, les données peuvent transiter soit par la mémoire, soit au travers de collections persistantes de structures hiérarchiques de données.
Avantages
Le procédé décrit plus haut présente plusieurs avantages :
Il permet de séparer les raisonnements sur les relations entre les données de l'affichage et du stockage physique. Tout cela en restant compatible avec les standards mondiaux XSD (XML schéma), ce qui permet une grande compatibilité avec les systèmes existants ou futurs.
Le procédé de configuration logicielle permet de définir les schémas de données d'une manière beaucoup plus aisée que les systèmes de gestion de bases de données (SGBD) actuels, et de valider de manière implicite les données et les relations d'inférence des données entre elles.
Le concepteur 32 manipule ainsi plus facilement un arbre logique ; c'est plus simple et plus intuitif que de faire des rapprochements de vue au moyen de jointure.
Dans un exemple de mise en œuvre réel du procédé, la demanderesse a constaté que certaines configurations comportent huit mille types dans un schéma, ces huit mille types étant liés de manière implicite (arborescence).
Dans le cas d'une utilisation d'un système de gestion de base de données pour travailler sur cet ensemble, cela se traduit par huit mille tables et beaucoup plus de jointures qu'il faut appréhender en bloc.
Au contraire, dans l'arborescence utilisée dans le procédé, on affiche uniquement la partie sur laquelle l'on veut travailler et on applique des liens et des règles simples (on divise et on structure) sur les éléments constituant cette partie, ce que ne propose aucun système de gestion de base de données, lesquels travaillent à plat avec des jointures.
La traduction d'un schéma peu complexe en UML, sous forme système de gestion de base de données, se traduirait, pour l'utilisateur, en un ensemble considérable de blocs et de traits se croisant, probablement incompréhensible car présenté dans son ensemble.
Une première partie innovante du procédé, visible par l'utilisateur expert de l'entreprise 32 non informaticien, concerne la méthode logique de modélisation de règles métiers ordonnées en structure hiérarchique dans différents schémas. Les données intelligentes qui représentent les règles métier sont décrites dans le schéma et s'appuient sur des interfaces de visualisation et de liaisons.
Une seconde partie innovante, concerne le moteur d'inférence qui régit les schémas de configuration et les milliers de combinaison de règles associées, en temps réel à chaque changement d'état des données produits introduite par l'utilisateur final. Une troisième partie innovante concerne la génération automatique de code informatique permettant ainsi la génération d'applications de configurations métiers à travers un studio ludique pour des experts métiers non-informaticiens.
Une quatrième partie innovante concerne la conception dynamique de formulaires métiers pilotés par les schémas. Ces formulaires sont générés en fonction de la plate-forme cible des postes clients (Silverlight, Windows8, HTML5 - marques déposées).
Ce moteur et les règles associées aux schémas sont résidents sur serveurs WEB dans le CLOUD et sont accessibles aux PC portables ou tablettes utilisateurs en mode multi-plateforme Windows, Androïd et IPAD (marques déposées).

Claims

REVENDICATIONS
1 . Procédé de création d'un générateur d'un ensemble de données dites "données de fabrication" d'un produit pouvant être configuré selon différentes variantes selon des paramètres définissant les besoins et contraintes d'un client (22), lesdits paramètres pouvant varier de façon continue,
ledit procédé étant destiné à être mis en œuvre par un ordinateur (20) comportant des moyens de communication à un réseau d'échange de données de type Internet,
ladite application comportant une interface homme-machine de type MVC, comportant
- un modèle de données,
- une interface visuelle,
- un contrôleur de logique des événements,
caractérisé en ce que ledit procédé comporte des premiers moyens graphiques de définition de liens logiques entre les données, pour permettre à un utilisateur (32) de développer ledit générateur de données de fabrication, le contrôleur logique des événements imposant des relations entre les données du modèle et les éléments de la visualisation selon un ensemble paramétrables de règles dites "règles métier", définies par des seconds moyens graphiques de définition de liens logiques entre les données.
2. Procédé selon la revendication 1 , caractérisé en ce que le procédé comporte un module de définition par l'utilisateur (32) de ces règles métier, les données sur lesquelles doivent s'appliquer les règles de cohérence étant désignées visuellement sur l'interface homme-machine par l'utilisateur (32), et des règles de lien mathématique entre diverses données, ou de seuils maximums ou minimums étant définis par l'utilisateur (32).
3. Procédé selon l'une quelconque des revendications 1 à 2, caractérisé en ce que le procédé met en œuvre une arborescence d'affichage, dans laquelle l'utilisateur (32) choisit d'afficher uniquement une partie d'un schéma de données sur laquelle il veut travailler et le procédé applique des liens et des règles de cohérence et d'inférence simples sur les éléments constituant cette partie.
4. Procédé selon l'une quelconque des revendications 2 à 3, caractérisé en ce que le module de définition de règles métier comporte des règles de cohérence applicables à ces règles métier, de manière à mettre en évidence les conflits éventuels entre certaines de ces règles lors de leur génération par l'utilisateur (32).
5. Procédé de fabrication d'un produit pouvant être configuré selon différentes variantes selon des paramètres définissant les besoins et contraintes d'un client, lesdits paramètres pouvant varier de façon continue, caractérisé en ce qu'il comporte un procédé de création d'un générateur de données de fabrication du produit, selon l'une quelconque des revendications 1 à 4.
6. Procédé selon la revendication 5, caractérisé en ce qu'il comporte des phases et étapes suivantes :
phase 100 de création d'un générateur de données de fabrication d'un produit,
- 1 10 : identification de variables permettant la définition de produits qu'on veut faire configurer par des clients 22.
- 120 : identification des règles d'inférence
- 140 : vérification de cohérence des règles d'inférence définies précédemment.
- 160 : définition de règles de fabrication, sur la base des variables définies dans l'étape 1 10.
phase 200 d'utilisation du configurateur,
- 210 : affichage à destination d'un utilisateur 22, au moins une partie d'un schéma de données,
- 220 : modification par l'utilisateur des données en fonction de ses besoins propres, et
- propagation par le moteur d'inférence des modifications aux autres variables liées par des règles d'inférence.
7. Procédé selon la revendication 6, caractérisé en ce que lors de l'étape de propagation d'une modification par le moteur d'inférence, le moteur passe à travers plusieurs états qui s'enchainent de manière cyclique jusqu'à la stabilisation de l'ensemble de données ou à la détection de la récurrence de données cycliques.
PCT/EP2013/074093 2012-12-11 2013-11-18 Procédé de création de simulateur de configuration client Ceased WO2014090514A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1261871 2012-12-11
FR1261871A FR2999314B1 (fr) 2012-12-11 2012-12-11 Procede de creation de simulateur de configuration client

Publications (1)

Publication Number Publication Date
WO2014090514A1 true WO2014090514A1 (fr) 2014-06-19

Family

ID=48771486

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/074093 Ceased WO2014090514A1 (fr) 2012-12-11 2013-11-18 Procédé de création de simulateur de configuration client

Country Status (2)

Country Link
FR (1) FR2999314B1 (fr)
WO (1) WO2014090514A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109858185A (zh) * 2019-03-08 2019-06-07 广东岭南职业技术学院 一种基于ar虚拟现实技术的室内装修设计方法
CN120567588A (zh) * 2025-08-04 2025-08-29 浪潮通用软件有限公司 一种基于规则链建模的物联网指标计算方法、设备及介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3061578A1 (fr) * 2016-12-30 2018-07-06 Techform Procede de generation d'application logicielle : un meta-configurateur de gestion de configuration client

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5844554A (en) * 1996-09-17 1998-12-01 Bt Squared Technologies, Inc. Methods and systems for user interfaces and constraint handling configurations software
WO2001029687A1 (fr) * 1999-10-15 2001-04-26 Officefree.Com Configurateur commande par table sur internet
US20070073763A1 (en) * 2005-09-23 2007-03-29 Christopher Betts Automated Creation of Model and View Code
US20100262902A1 (en) * 2009-04-08 2010-10-14 Microsoft Corporation Schema Based User Interface Mechanisms
WO2011104367A2 (fr) * 2010-02-25 2011-09-01 Sita Information Networking Computing Ireland Limited Outil de développement d'application logicielle

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5844554A (en) * 1996-09-17 1998-12-01 Bt Squared Technologies, Inc. Methods and systems for user interfaces and constraint handling configurations software
WO2001029687A1 (fr) * 1999-10-15 2001-04-26 Officefree.Com Configurateur commande par table sur internet
US20070073763A1 (en) * 2005-09-23 2007-03-29 Christopher Betts Automated Creation of Model and View Code
US20100262902A1 (en) * 2009-04-08 2010-10-14 Microsoft Corporation Schema Based User Interface Mechanisms
WO2011104367A2 (fr) * 2010-02-25 2011-09-01 Sita Information Networking Computing Ireland Limited Outil de développement d'application logicielle

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
P. T. HELO ET AL: "Citarasa driven vehicle configurator", 2007 IEEE INTERNATIONAL CONFERENCE ON INDUSTRIAL ENGINEERING AND ENGINEERING MANAGEMENT, 1 December 2007 (2007-12-01), pages 1302 - 1306, XP055089493, ISBN: 978-1-42-441529-8, DOI: 10.1109/IEEM.2007.4419403 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109858185A (zh) * 2019-03-08 2019-06-07 广东岭南职业技术学院 一种基于ar虚拟现实技术的室内装修设计方法
CN109858185B (zh) * 2019-03-08 2022-09-02 广东岭南职业技术学院 一种基于ar虚拟现实技术的室内装修设计方法
CN120567588A (zh) * 2025-08-04 2025-08-29 浪潮通用软件有限公司 一种基于规则链建模的物联网指标计算方法、设备及介质

Also Published As

Publication number Publication date
FR2999314B1 (fr) 2023-08-04
FR2999314A1 (fr) 2014-06-13

Similar Documents

Publication Publication Date Title
US10078818B2 (en) Work routine management for collaborative platforms
US20140047413A1 (en) Developing, Modifying, and Using Applications
US8694544B2 (en) Layering concept for a repository of a user interface framework for web applications
WO2013140077A1 (fr) Procede et systeme d'execution d'une application pour la consultation de contenus et services accessibles par navigation sur un reseau de telecommunication.
US10726036B2 (en) Source service mapping for collaborative platforms
EP2511842B1 (fr) Consultation de maquettes numériques à partir de postes légers
CN109478152A (zh) 云内容状态框架
Cetin et al. Legacy migration to service-oriented computing with mashups
EP2297681A1 (fr) Procede de gestion de donnees pour atelier oriente service collaboratif
Harrison et al. WS-RF workflow in Triana
EP3202115B1 (fr) Procédé et dispositif de mise en relations d'un ensemble d'informations
US11295273B2 (en) Normalized object exposure for collaborative platforms
WO2014090514A1 (fr) Procédé de création de simulateur de configuration client
EP2187321A1 (fr) Procédé et dispositif d'édition d'un objet représenté dans une page web
Bleisinger et al. Killing the PLM Monolith-the Emergence of cloudnative System Lifecycle Management (SysLM)
FR3061578A1 (fr) Procede de generation d'application logicielle : un meta-configurateur de gestion de configuration client
Vieira Designing hexagonal architecture with Java
Čechák Using GraphQL for content delivery in Kentico Cloud
CN106933543A (zh) 基于We3D的智能商务平台组件开发方法
FR3146748A3 (fr) Procédé et dispositif de génération automatique d’au moins deux ensembles d’instructions informatiques
FR3146747A1 (fr) Procédé et dispositif de génération automatique d’au moins deux ensembles d’instructions informatiques
Lee et al. I-typed dmml: A novel dsl for direct manipulation interaction with virtual objects
Bueringer Development of a Cloud Platform for Business Process Administration, Modeling, and Execution
EP2558932A1 (fr) Procédé d'enregistrement de données, dispositif, et produit programme d'ordinateur correspondant
WO2001095102A1 (fr) Procede de structuration, de transfert et d'interpretation d'un ensemble d'informations destinees a la conception d'interfaces graphiques

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13796022

Country of ref document: EP

Kind code of ref document: A1