CN115904362A - Domain-driven-based component generation method, system, device and storage medium - Google Patents
Domain-driven-based component generation method, system, device and storage medium Download PDFInfo
- Publication number
- CN115904362A CN115904362A CN202211257680.6A CN202211257680A CN115904362A CN 115904362 A CN115904362 A CN 115904362A CN 202211257680 A CN202211257680 A CN 202211257680A CN 115904362 A CN115904362 A CN 115904362A
- Authority
- CN
- China
- Prior art keywords
- domain
- plan
- information
- sub
- planning
- 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.)
- Pending
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The embodiment of the application provides a method, a system, equipment and a storage medium for generating components based on domain drive, and belongs to the technical field of artificial intelligence. The component generation method comprises the following steps: acquiring service flow information and plan definition information; performing field division according to the service process information to obtain a plurality of sub-fields, and determining a plan sub-field in the plurality of sub-fields; identifying the business process information in the planning subdomain according to the plan definition information to obtain a plurality of business information texts of the business process; extracting field nouns of plan subdomains from each service information text; encapsulating domain nouns under the same boundary context in the boundary of the planning subdomain; and performing domain modeling based on the packaged plan subdomain to obtain a domain model, and generating a target plan component according to a code mapping relation of the domain model. By the target plan component generated in the embodiment of the application, the multiplexing capability of a system among channels can be improved, and the difficulty in development, operation and maintenance is reduced.
Description
Technical Field
The present application relates to the field of artificial intelligence, and in particular, to a method, a system, a device, and a storage medium for generating an assembly based on a domain driver.
Background
Planning is a process and a conclusion of analyzing and calculating how to achieve a goal in a specified period in the future and decomposing the goal into sub-goals, and a process of planning in each field in a channel and inserting planning management in a plurality of fields, wherein the planning management function exists in different systems in each field.
In the related technology, in the process of adapting to the construction of plan centers in different systems, the method often cannot adapt to the change situation of the service, the development process is complex, the multiplexing of the cross-channel system cannot be realized, and the difficulty of development and operation and maintenance is improved.
Disclosure of Invention
The embodiment of the application mainly aims to provide a method, a system, equipment and a storage medium for generating components based on domain driving, which can improve the multiplexing capability of a cross-channel system and reduce the difficulty of development and operation and maintenance.
To achieve the above object, a first aspect of an embodiment of the present application provides a method for generating a component based on domain driving, where the method includes: acquiring service flow information and plan definition information; performing field division according to the service flow information to obtain a plurality of sub-fields, and determining a plan sub-field in the plurality of sub-fields; identifying the business process information in the planning subdomain according to the plan definition information to obtain a plurality of business information texts of the business process; extracting field nouns of the plan subdomain from each service information text; encapsulating the domain nouns in the same boundary context within the boundaries of the plan subdomain; and performing domain modeling on the basis of the packaged plan subdomain to obtain a domain model, and generating a target plan component according to a code mapping relation of the domain model.
In some embodiments, the identifying the business process information in the planning sub-domain according to the plan definition information to obtain a plurality of business information texts of a business process includes: acquiring a preset plan meta-model, wherein the plan meta-model is established according to a composition relation among sample function modules in a sample business process; identifying a functional module related to the plan from the plan meta-model according to the plan definition information; and mapping the functional module and the service process information, and identifying and obtaining a plurality of service information texts of the service process according to a mapping result.
In some embodiments, the service information text includes event information, command information, member information, and input information, and the extracting the domain nouns of the plan sub-domain from each of the service information texts includes: establishing an event map according to the incidence relation among the event information, the command information, the member information and the input information; and extracting the domain nouns of the planning subdomain from the event map.
In some embodiments, encapsulating the domain nouns that are to be in the same bound context within the boundaries of the planning sub-domain includes: extracting general domain nouns from the domain nouns; and encapsulating the general domain nouns under the same boundary context in the boundary of the planning subdomain.
In some embodiments, encapsulating the domain nouns that are to be in the same bound context within the boundaries of the planning sub-domain includes: determining a bounding context from the plan definition information; encapsulating the domain nouns related to the project sub-domain functions within boundaries of the project sub-domain according to the boundary context.
In some embodiments, the performing domain division according to the service flow information to obtain a plurality of sub-domains, and determining a planning sub-domain among the plurality of sub-domains includes: performing domain division according to the service flow information to obtain a plurality of sub-domains; and determining the functional attribute in each sub-domain, and determining the sub-domain with the functional attribute of the general domain function as a planning sub-domain.
In some embodiments, the generating a target plan component from the code mapping relationships of the domain model comprises: obtaining a plurality of code objects according to each domain noun mapping in the domain model; a target plan component is generated from a plurality of the code objects.
To achieve the above object, a second aspect of an embodiment of the present application provides a domain-driven component generation system, including: the data acquisition module is used for acquiring the service flow information and the plan definition information; the domain division module is used for carrying out domain division according to the business process information and determining a planning sub domain in the plurality of sub domains; the information identification module is used for identifying the business process information in the planning subdomain according to the plan definition information to obtain a plurality of business information texts of the business process; a domain name extracting module, configured to extract domain names of the plan subdomain from each of the service information texts; the packaging module is used for packaging the domain nouns under the same boundary context into the boundary of the plan subdomain; and the component generating module is used for performing domain modeling on the basis of the packaged plan subdomain to obtain a domain model and generating a target plan component according to a code mapping relation of the domain model.
In order to achieve the above object, a third aspect of the embodiments of the present application provides an electronic device, which includes a memory and a processor, where the memory stores a computer program, and the processor implements the method of the first aspect when executing the computer program.
To achieve the above object, a fourth aspect of the embodiments of the present application provides a storage medium, which is a computer-readable storage medium, and the storage medium stores a computer program, and the computer program, when executed by a processor, implements the method of the first aspect embodiment.
The component generation method can be applied to a component generation system based on field driving, through an execution component generation method, business process information can be identified through plan definition information, after plan subdomains are obtained through division according to the business process information, a plurality of business information texts in the plan subdomains are identified, domain nouns of the plan subdomains are extracted, in order to further limit the limit, the definition of the limit context is applied in the field driving design in the embodiment of the application, the domain nouns under the same limit context are packaged in the boundary of the plan subdomains, all the domain nouns irrelevant to the subdomain function are excluded from the limit context, the uniqueness of the subdomain responsibility and the purity of a subsequent domain model are ensured, finally, a domain model is established based on the plan subdomain, the established domain model can be used as the input of micro-service design, a target plan component is finally generated according to the code mapping relation of the domain model, and the target plan component generated in the embodiment of the application can improve the multiplexing capacity of the system among cross channels and reduce the difficulty of development and operation and maintenance.
Drawings
FIG. 1 is a flowchart of a domain-driven component generation method according to an embodiment of the present disclosure;
fig. 2 is a flowchart of step S103 in fig. 1;
FIG. 3 is a schematic diagram of a plan meta-model provided by an embodiment of the present application;
fig. 4 is a flowchart of step S104 in fig. 1;
FIG. 5 is a schematic diagram of an event map of an activity interview plan provided by an embodiment of the present application;
fig. 6 is a flowchart of step S105 in fig. 1;
fig. 7 is a flowchart of step S105 in fig. 1;
FIG. 8 is a schematic diagram of various subdomains provided in an embodiment of the present application;
fig. 9 is a flowchart of step S102 in fig. 1;
fig. 10 is a flowchart of step S106 in fig. 1;
FIG. 11 is a functional block diagram of a domain modeling system provided by an embodiment of the present application;
fig. 12 is a schematic hardware structure diagram of an electronic device according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
It should be noted that although functional blocks are partitioned in a schematic diagram of an apparatus and a logical order is shown in a flowchart, in some cases, the steps shown or described may be performed in a different order than the partitioning of blocks in the apparatus or the order in the flowchart. The terms first, second and the like in the description and in the claims, and the drawings described above, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the application.
First, several terms referred to in the present application are resolved:
artificial Intelligence (AI): the method is a new technical science for researching and developing theories, methods, technologies and application systems for simulating, extending and expanding human intelligence; artificial intelligence is a branch of computer science that attempts to understand the essence of intelligence and produces a new intelligent machine that can react in a manner similar to human intelligence, and research in this field includes robotics, language recognition, image recognition, natural language processing, and expert systems, among others. The artificial intelligence can simulate the information process of human consciousness and thinking. Artificial intelligence is also a theory, method, technique and application system that uses a digital computer or a machine controlled by a digital computer to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use the knowledge to obtain the best results.
Domain Drive Design (DDD) is a software Design method based on model drive. The method takes the field as the core, analyzes the problems in the field and effectively solves the core complex problem in the field by establishing a field model. Only by continuous and deep knowledge of the field, a field model solving the core problem of the field can be obtained, and if the complexity of an application is not in the technical aspect, but in the field, namely, the service in the field is complex, the value of the field-driven design is higher for the application.
Planning is the process and conclusion of analyzing and calculating how to achieve a goal in a specified period of time in the future and decomposing the goal into sub-goals, the plan can be broken down or combined, the process and results can be tracked, and the tuples in the plan include purpose, quantifiable goal, time range, plan agent, execution step, budget, and strain measure.
The middle platform is an integrated full-channel platform and can also be called a channel middle platform, and is widely applied to the financial industry and the insurance industry, the middle platform is a 'big background', all service functions can be integrated in the big background, and all data use one or one set of database to get through each service, so that the problem of data isolated island is solved, the performance is improved, the interaction among different systems, interface conversion is reduced, and the expensive development, network delay and expenditure and unnecessary development workload brought when the transaction consistency of the data interaction among different systems is supported.
The channel middleboxes have plans in each field, and plan management processes are interspersed in multiple fields, for example, in the insurance industry, business processes of adding personnel, training, exhibition, activities and performance are interspersed in the plan management processes.
However, the applicant finds that the plan management function exists in different systems in each field, the same functional module can be subjected to product design and development again, and is limited by the service field, unified architecture design is not provided, chimney type construction is adopted, precipitation universality is not provided, repeated construction is provided, and service change cannot be flexibly adapted, so that the innovation of a service mode cannot be rapidly supported, and cross-channel system reuse cannot be achieved. However, when the micro-service development mode is adopted, the boundaries of services or applications cannot be clearly divided, so that the micro-service is excessively split or the project complexity is excessively high, and certain difficulty is caused to the online operation and the operation and maintenance.
Therefore, in the process of adapting to the construction of plan centers in different systems in the prior art, the change situation of the service can not be adapted, the development process is complex, the multiplexing of the system among channels can not be realized, and the difficulty of development and operation and maintenance is improved.
Based on this, the embodiment of the application provides a domain-driven-based component generation method, a domain-driven-based component generation system, a device and a storage medium, the component generation method can be applied to the domain-driven-based component generation system, and by executing the component generation method, the multiplexing capability of a cross-channel system can be improved, and the difficulty in development and operation and maintenance is reduced.
Specifically, the method, the system, the device, and the storage medium for generating a component based on a domain drive provided in the embodiments of the present application are described in the following embodiments, and first, the method for generating a component based on a domain drive in the embodiments of the present application is described.
The domain-drive-based component generation method in the embodiment of the present application can be explained by the following embodiments.
The embodiment of the application can acquire and process related data based on an artificial intelligence technology. Among them, artificial Intelligence (AI) is a theory, method, technique and application system that simulates, extends and expands human Intelligence using a digital computer or a machine controlled by a digital computer, senses the environment, acquires knowledge and uses the knowledge to obtain the best result.
The artificial intelligence infrastructure generally includes technologies such as sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technologies, operation/interaction systems, mechatronics, and the like. The artificial intelligence software technology mainly comprises a computer vision technology, a robot technology, a biological recognition technology, a voice processing technology, a natural language processing technology, machine learning/deep learning and the like.
The embodiment of the application provides a component generation method based on domain driving, and relates to the technical field of artificial intelligence. The method for generating the component based on the domain driver, provided by the embodiment of the application, can be applied to a terminal, a server side and software running in the terminal or the server side. In some embodiments, the terminal may be a smartphone, tablet, laptop, desktop computer, or the like; the server side can be configured into an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, and cloud servers for providing basic cloud computing services such as cloud service, a cloud database, cloud computing, cloud functions, cloud storage, network service, cloud communication, middleware service, domain name service, security service, CDN (content delivery network) and big data and artificial intelligence platforms; the software may be an application or the like that implements a domain-driven component generation method, but is not limited to the above form.
The application is operational with numerous general purpose or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
It should be noted that, in each embodiment of the present application, when data related to the user identity or the characteristic is related to and processed according to user information, user behavior data, user history data, user location information, and the like, permission or approval of the user is obtained first, for example, when data stored by the user and a cache data access request of the user are obtained, permission or approval of the user is obtained first. Moreover, the collection, use, and processing of such data, etc., will comply with relevant laws and regulations and standards in the relevant countries and regions. In addition, when the embodiment of the present application needs to acquire sensitive personal information of a user, individual permission or individual consent of the user is obtained through a pop-up window or a jump to a confirmation page, and after the individual permission or individual consent of the user is definitely obtained, necessary user-related data for enabling the embodiment of the present application to operate normally is acquired.
Fig. 1 is an alternative flowchart of a domain-driven component generation method provided in an embodiment of the present application, where the method in fig. 1 may include, but is not limited to, steps S101 to S106.
Step S101, acquiring service flow information and plan definition information;
for example, the domain-driven component generation method (may be simply referred to as a component generation method or method) in the embodiment of the present application may be applied to a domain-driven component generation system (may be simply referred to as a component generation system or system), in a process of executing the component generation method, business process information and plan definition information may be obtained first, the business process information includes specific information of a plurality of business processes, for example, processes including business addition, training, exhibition, activities, performance, and the like, the plan definition information is a definition of a plan in a process, and the plan in the business process may be defined by assistance of the plan definition information.
Step S102, dividing the field according to the service flow information to obtain a plurality of sub-fields, and determining a plan sub-field in the plurality of sub-fields;
in the embodiment of the application, the domains are divided according to the service flow information to obtain a plurality of sub domains, the sub domains can be divided into three types of sub domains according to the importance and the functional attributes of the sub domains, namely a core domain, a universal domain and a support domain, specifically, the sub domain determining the competitiveness of the product and the core is the core domain, the universal functional sub domain used by the sub domains is the universal domain, and the support domain is necessary and does not contain the function determining the competitiveness of the product and the core or the sub domain containing the universal function. In the embodiment of the application, a plurality of sub-domains are obtained, different functional attributes and importance of different sub-domains are distinguished through domain division, and one sub-domain is used as a planning sub-domain. Optionally, in the embodiment of the present application, any one of the sub-domains may be used as a planning sub-domain, and further, in the embodiment of the present application, a general domain is used as a planning sub-domain.
Step S103, identifying the business process information in the planning sub-domain according to the plan definition information to obtain a plurality of business information texts of the business process;
subsequently, in the embodiment of the application, the business process information in the planning sub-domain may be identified according to the plan definition information to obtain a plurality of business information texts of the business process, and the plan definition information may be a definition condition obtained by refining a channel middlebox methodology corresponding to the plan, so that identification of the planning related information in the business process may be improved. In the embodiment of the application, the business process or the business process section in the planning sub-domain can be subdivided through the field-driven designed event storm process and by combining with the design methodology of the middle station, so that the business text information in the whole process is obtained, and the business text information can represent each specific process or object in the business process and can be used for describing the business process. It should be noted that, in the event storm process in the embodiment of the present application, the system may obtain input information of the user, thereby obtaining business process information and plan definition information, and perform domain division and information identification through operation of the processor.
Step S104, extracting the domain nouns of the planning subdomain from each service information text;
for example, the embodiment of the present application may extract a domain noun of a planned subdomain from each service information text, where the domain noun in the embodiment of the present application is a domain object in a domain-driven design, or the domain noun corresponds to a domain object in the domain-driven design, and the domain object may be described by a noun in a preset language, such as a commodity, an order, etc., and corresponds to an entity object, and these domain objects correspond to service objects of a domain model, and each service object and domain object have a general noun term and are mapped one by one, and a verb in the preset language indicates an action or event, such as a commodity order being placed, an order being paid, etc., and corresponds to a domain event or a command. In the embodiment of the application, the service responsibility of the planning sub-domain is comprehensively considered once by extracting the field nouns of the planning sub-domain.
Step S105, encapsulating the domain nouns under the same boundary context in the boundary of the planning sub-domain;
for example, in the embodiment of the present application, comprehensive consideration is performed according to business responsibilities of implementing a planning sub-domain, and it is necessary to determine the planning sub-domain, or in other words, a responsibility boundary between a plurality of sub-domains.
It should be noted that, in the embodiments of the present application, a domain object is described by a domain noun, and nouns, that is, languages all have their semantic environments, in order to avoid ambiguity of the same concept or semantic in different context environments, the domain-driven design proposes a bound context concept on a strategic design to determine the domain boundary where the semantic exists. The bound context can be decomposed into two words of bound and context, the bound is the boundary of the domain, the context is the semantic environment, and the bound context of the domain can be communicated in a uniform domain boundary by using a uniform language, and the boundary can become the boundary of the final micro-service design.
And S106, performing field modeling based on the packaged plan subdomain to obtain a field model, and generating a target plan component according to a code mapping relation of the field model.
For example, in the embodiment of the present application, a domain modeling may be performed based on a packaged planning sub-domain to obtain a domain model, the domain model is a domain driving model, and the established domain model may implement micro-service landing, so the system in the embodiment of the present application may generate a target planning component according to a code mapping relationship of the domain model, where the target planning component may be a code model, or a set of multiple code files, to implement code landing, or a set of multiple software, and a planning center may be established through the target planning component, and the established planning center may be a platform, and is a channel middlebox in the embodiment of the present application, for performing planning management.
It should be noted that, in the component generation method according to the embodiment of the present application, service flow information may be identified through plan definition information, after a plan subdomain is obtained by dividing according to the service flow information, a plurality of service information texts in the plan subdomain are identified, and domain nouns of the plan subdomain are extracted, in order to further define a boundary, in the embodiment of the present application, a specification of a boundary context is applied in a domain-driven design, domain nouns under the same boundary context are encapsulated in a boundary of the plan subdomain, and all domain nouns irrelevant to the role of the subdomain are excluded from the boundary context, so that the unicity of subdomain responsibility and the purity of a subsequent domain model are ensured, and finally, a domain model is established based on the plan subdomain, and the established domain model may be used as an input of a microservice design, and a target plan component is finally generated according to a code mapping relationship of the domain model.
Referring to fig. 2, in some embodiments, step S103 may include, but is not limited to, step S201 to step S203:
step S201, acquiring a preset plan meta-model, wherein the plan meta-model is established according to a composition relation among sample function modules in a sample business process;
step S202, identifying a function module related to the plan from the plan meta-model according to the plan definition information;
step S203, mapping the functional module and the service process information, and identifying and obtaining a plurality of service information texts of the service process according to the mapping result.
Illustratively, in the process of subdividing the service flow in the planning sub-domain, the services may be disassembled according to a preset planning meta-model. Specifically, in the embodiment of the present application, a plan meta-model is preset, where the plan meta-model is a meta-model (Metamodel), the meta-model defines specifications of the model, specifically, the relationship between elements constituting the model, and in the embodiment of the present application, the relationship between elements in a plan is defined by the plan meta-model. The plan meta-model is established according to the composition relationship among the sample function modules in the business process template.
For example, as shown in fig. 3, in a business process sample provided in the embodiment of the present application, a corresponding business field of the business process sample is formed by combining a plurality of sample function modules, it can be understood that the system can obtain input information of a user to obtain a sample business process and a sample function module, the sample function module is a process in a corresponding business, the sample function module is each information in fig. 3, and the meta model of the business process formulated in the embodiment of the present application includes a plurality of concepts to describe the function modules, such as constraints, targets, subjects, relationships, objects, and the like. Wherein, a plurality of templates can be arranged under the constraint; the business process is disassembled to obtain targets, sub-targets and the like, and further, leaf sub-targets can be arranged under the sub-targets and can be formed by combining a plurality of target values; the main body can be combined by a planning main body; the relationship can be divided into various relationships such as formulation, monitoring and intervention, and represents the relationship condition among all the business processes in the plan management process; a plan can be obtained according to the corresponding relation between the objects, the plan comprises activities and risks, the activities are associated with leaf targets, and the risks are associated with templates under a plurality of constraints.
The functional modules are characterized according to the 5 main concepts (including constraints, targets, subjects, relations and objects) of the meta-model, and the meta-model for planning, execution, monitoring and intervention can be formed according to the business process related to plan management in the channel middle stage core domain docked by the plan center.
Illustratively, in the embodiment of the application, a general function module related to a plan is identified from a plan meta-model according to plan definition information, including planning, issuing the plan, tracking the plan, monitoring and warning, and mapping the function module and a business process one by one, disassembling the business process in a comprehensive view, inspecting whether the function module of a product design conforms to the concept in the plan meta-model, and covering the whole business process, identifying and obtaining each business information of the business process according to the mapping result, defining a general language based in the plan through the setting of the plan meta-model, and being capable of describing the problem and the solution in the plan.
Illustratively, the service information text includes event information, command information, member information and input information, the event information represents an event in the whole process, the command information represents a command in the whole process, the member information mainly represents a main situation in the plan management process, and the input information mainly represents a read model in the plan process.
Referring to fig. 4, in some embodiments, step S104 may include, but is not limited to, step S301 to step S302:
step S301, establishing an event map according to the association among the event information, the command information, the member information and the input information;
step S302, the domain nouns of the planning subdomain are extracted from the event map.
Illustratively, in the embodiment of the present application, according to plan definition information and business process information, through an event storm process designed by field drive, and in combination with a design methodology of a channel staging, business processes in a planning sub-domain can be subdivided, so as to identify events, commands, members (subjects), and inputs (reading models) in the whole process, simply, clearly, and accurately describe business meanings and rules, and form an event map.
For example, referring to fig. 5, an event map provided as an embodiment is an event map of an activity interview plan, where the content in the box is member information of "system" and "agent", the content in the box is blank and input information of "personal communication list, system push list", the content in the box is command information of "issue monthly interview target value", "circle potential client", "create interview plan", "generate interview two-dimensional code", and "record interview number", the content in the box is event information of "monthly interview target value issue", "potential client circled", "interview plan created", "interview two-dimensional code generated", and "interview number recorded", and "interview failed", and the event information, command information, member information, and input information may represent a flow in one plan, and in the event map, the previous plan management flow is next to the next flow, and thus called a map.
Referring to fig. 6, in some embodiments, step S105 may include, but is not limited to, step S401 to step S402:
step S401, extracting general domain nouns from domain nouns;
step S402, the general domain nouns under the same boundary context are packaged in the boundary of the planning subdomain.
For example, in the embodiment of the present application, all general domain terms in a planned sub-domain may be extracted from an event map, and are named uniformly to form a general business term unified by a project team, so as to obtain the general domain terms, and then, the role boundaries of the planned sub-domain are determined by comprehensively considering business roles of the planned sub-domain, and all general domain terms related to the realization of the function of the planned sub-domain are placed in the same boundary context boundary, while all domain terms unrelated to the function of the planned sub-domain are excluded from the context boundary.
It should be noted that the universal domain noun is a domain noun described by a universal language, the universal language is an agreed specification and rule, and the language capable of simply, clearly and accurately describing the business meaning and the rule in the event storm process is the universal language. The universal language comprises terms and use case scenes and can be directly reflected in codes, and nouns in the universal language can name domain objects, such as commodities, orders and the like, and correspond to entity objects; the verb represents an action or event, such as a commodity placed, an order paid, etc., corresponding to a domain event or command.
Referring to fig. 7, in some embodiments, step S105 may include, but is not limited to, step S501 to step S502:
step S501, determining a boundary context according to plan definition information;
step S502, according to the boundary context, the domain nouns related to the planned subdomain functions are packaged in the boundary of the planned subdomain.
Illustratively, the bounding context may be determined from plan definition information that describes what is a plan, and thus, the boundaries of the plan sub-domains may be further described by the plan definition information to arrive at the bounding context. In the embodiment of the present application, since a domain noun also has its context, in order to avoid ambiguity of the same concept or semantic in different context, in the domain-driven design, a bounding context concept is proposed to determine the domain boundary where the semantic is located. In the embodiment of the application, the general language and the domain object are packaged through the boundary context, the context environment is provided, and some terms, business related objects and the like in the domain have an exact meaning, so that the boundary defines the application range of the domain model and defines the content of a planning center in the domain model.
Referring to fig. 8, a schematic diagram of each sub-domain provided in this embodiment of the present application is shown, where domain terms related to the functions of the planned sub-domain may be packaged within the boundaries of the planned sub-domain through the boundary division of the boundary context, and the planned sub-domain corresponds to the plan management context (general domain) in fig. 8.
It should be noted that the bound context in the embodiment of the present application is a mandatory boundary, which can ensure the uniqueness of the sub-domain responsibilities and the purity of the subsequent domain model, that is, the bound context determines the micro-service splitting and design boundary, and lays the foundation for the domain modeling.
Referring to fig. 9, in some embodiments, step S102 may include, but is not limited to, step S601 to step S602:
step S601, dividing the field according to the business process information to obtain a plurality of subdomains;
step S602, determining the function attribute in each sub-domain, and determining the sub-domain whose function attribute is a general domain function as a planning sub-domain.
For example, as shown in fig. 8, in the embodiment of the present application, a plurality of sub-domains may be obtained by domain division, and finally, domain terms may be encapsulated in the corresponding sub-domains according to a boundary context, specifically, in the embodiment of the present application, a core domain, a general domain, and a support domain may be obtained by division, where the core domain may include sub-domains corresponding to an administrator plan management context, a training management context, and a performance management context which are obtained by division in fig. 8, the general domain is a sub-domain corresponding to a plan management context, the plan sub-domain in the embodiment of the present application is a general domain, that is, a sub-domain corresponding to a plan management context, and sub-domains corresponding to a interview management context, an approval management context, a financial management context, and a performance management context in fig. 8 are support domains.
It should be noted that, in the sub-field corresponding to the plan management context in fig. 8, the area term of the interview plan is included, and the interview plan includes the activity interview plan in the above embodiment.
Therefore, the finally generated target planning component in the embodiment of the application can generate a universal domain planning center in the field-driven design.
Referring to fig. 10, in some embodiments, step S106 may include, but is not limited to, step S701 to step S702:
step S701, a plurality of code objects are obtained according to the mapping of each domain noun in the domain model;
step S702, a target plan component is generated from the plurality of code objects.
Specifically, in the embodiment of the present application, a plurality of code objects may be obtained according to mapping of each domain noun in a domain model based on a code mapping relationship, a target plan component may be generated according to the plurality of code objects, the target plan component may be one code model, or may be a component generated according to the code model after the code model is generated according to the code object, and the domain objects, that is, mapping of the domain nouns and the code objects one by one, are established when the code model is designed, so that consistency between the domain model and the code model is ensured, and unification between a business language and a code language is achieved.
It can be understood that, in the embodiment of the present application, the domain model of the universal language is established as an input of the micro service design, the code model of the micro service is derived from the domain model, and the code objects of the code model are mapped one by one with the domain nouns in the domain model, so that the consistency between the service requirement and the system landing can be ensured only if the universal language is unified in the whole application construction process and the correct transmission and mapping are performed.
It should be noted that, in the embodiment of the present application, a target plan component is generated by a domain-driven design methodology through an execution component generation method, and a plan center can be built according to the target plan component, where the embodiment of the present application subdivides a business domain according to a certain rule, limits a problem to be solved within a specific boundary, performs fine-grained analysis on a plan sub-domain, identifies sharing capabilities in a plan business process, and precipitates the sharing capabilities into general capabilities.
Illustratively, the planning center finally obtained by the method in the embodiment of the application achieves that the service reusability reaches 28.13%, and the goals of cost reduction and efficiency improvement are achieved. On the other hand, through accumulation of the precipitation service and the IT knowledge, mutual understanding of service personnel and IT personnel is facilitated, the knowledge is better passed, and the work matching degree and the system satisfaction rate are improved. The system provides three-layer multiplexing capability of crossing entities, fields and channels for all channels, and realizes the effect of one-time research and development and multi-party benefit.
Referring to fig. 11, an embodiment of the present application further provides a domain-driven component generation system, which can implement the domain-driven component generation method, where the component generation system includes:
a data acquisition module 1101, configured to acquire service flow information and plan definition information;
a domain division module 1102, configured to perform domain division according to the service flow information, and determine a plan sub-domain among multiple sub-domains;
the information identification module 1103 is configured to identify the business process information in the planning sub-domain according to the plan definition information to obtain a plurality of business information texts of the business process;
a domain name extraction module 1104, configured to extract domain names of the planned sub-domains from the service information texts;
an encapsulating module 1105, configured to encapsulate domain terms in the same boundary context within the boundary of the planned subdomain;
and the component generating module 1106 is configured to perform domain modeling based on the encapsulated plan subdomain to obtain a domain model, and generate a target plan component according to a code mapping relationship of the domain model.
For example, in the component generation system in the embodiment of the present application, during the execution of the component generation method, business process information and plan definition information may be obtained first, where the business process information includes specific information of several business processes, for example, processes including business addition, training, exhibition, activity, and performance, and the plan definition information is a definition of a plan in a process, and the plan definition information may assist in defining the plan in the business process.
In the embodiment of the application, the domains are divided according to the service flow information to obtain a plurality of sub-domains, the sub-domains can be divided into three types of sub-domains according to the importance and the function attributes of the sub-domains, namely a core domain, a general domain and a support domain, specifically, the sub-domain determining the competitiveness of the product and the core is the core domain, the general function sub-domain used by the sub-domains is the general domain, and the support domain is necessary and does not contain the function determining the competitiveness of the product and the core or the sub-domain containing the general function. In the embodiment of the application, a plurality of sub-domains are obtained, different functional attributes and importance of different sub-domains are distinguished through domain division, and one sub-domain is used as a planning sub-domain. Optionally, in the embodiment of the present application, any one of the sub-domains may be used as a planning sub-domain, and further, in the embodiment of the present application, a general domain is used as a planning sub-domain.
Subsequently, in the embodiment of the application, the business process information in the planning sub-domain may be identified according to the plan definition information to obtain a plurality of business information texts of the business process, and the plan definition information may be a definition condition obtained by refining a channel middlebox methodology corresponding to the plan, so that identification of the planning related information in the business process may be improved. In the embodiment of the application, the business process or the business process section in the planning sub-domain can be subdivided through the field-driven designed event storm process and by combining with the design methodology of the middle station, so that the business text information in the whole process is obtained, and the business text information can represent each specific process or object in the business process and can be used for describing the business process. It should be noted that, in the event storm process in the embodiment of the present application, the system may obtain input information of the user, thereby obtaining business process information and plan definition information, and perform domain division and information identification through operation of the processor.
For example, the embodiment of the present application may extract a domain noun of a planned subdomain from each service information text, where the domain noun in the embodiment of the present application is a domain object in a domain-driven design, or the domain noun corresponds to a domain object in the domain-driven design, and the domain object may be described by a noun in a preset language, such as a commodity, an order, etc., and corresponds to an entity object, and these domain objects correspond to service objects of a domain model, and each service object and domain object have a general noun term and are mapped one by one, and a verb in the preset language indicates an action or event, such as a commodity order being placed, an order being paid, etc., and corresponds to a domain event or a command. In the embodiment of the application, the service responsibility of the planning sub-domain is comprehensively considered once by extracting the field nouns of the planning sub-domain.
In the embodiment of the present application, all the domain terms related to implementing the intelligence of the planning sub-domain are placed in the same boundary context and are encapsulated in the boundary of the planning sub-domain, and all the domain terms unrelated to the function of the planning sub-domain are dispatched outside the context boundary of the planning sub-domain.
It should be noted that, in the embodiments of the present application, a domain object is described by a domain noun, and nouns, that is, languages all have their semantic environments, in order to avoid ambiguity of the same concept or semantic in different context environments, the domain-driven design proposes a bound context concept on a strategic design to determine the domain boundary where the semantic exists. The bound context can be decomposed into two words of bound and context, the bound is the boundary of the domain, the context is the semantic environment, and the bound context of the domain can be communicated in a uniform domain boundary by using a uniform language, and the boundary can become the boundary of the final micro-service design.
For example, in the embodiment of the present application, a domain model may be obtained by performing domain modeling based on a packaged planning sub-domain, where the domain model is a domain driver model, and the established domain model may implement micro-service landing, and therefore, a system in the embodiment of the present application may generate a target planning component according to a code mapping relationship of the domain model, where the target planning component may be a code model or a set of multiple code files to implement code landing, or a set of multiple software, and a planning center may be established by the target planning component, where the established planning center may be a platform, and the planning center in the embodiment of the present application is a channel middleboard for planning management.
It should be noted that, in the component generation system according to the embodiment of the present application, when the component generation method is executed, the service flow information may be identified through the plan definition information, after the plan subdomains are divided according to the service flow information, a plurality of service information texts in the plan subdomains are identified, and the domain nouns of the plan subdomains are extracted, in order to further define the boundary, in the embodiment of the present application, the specification of the boundary context is applied in the domain-driven design, the domain nouns under the same boundary context are encapsulated in the boundary of the plan subdomains, and all the domain nouns irrelevant to the subdomain functions are excluded from the boundary context, so as to ensure the unicity of the subdomain responsibilities and the purity of the subsequent domain models, and finally, the domain model is established based on the plan subdomain, and the established domain model may be used as an input of the microservice design, and a target plan component is finally generated according to the code mapping relationship of the domain model.
The specific implementation of the domain modeling system is substantially the same as the specific implementation of the domain-drive-based component generation method, and is not described herein again. On the premise of meeting the requirements of the embodiment of the application, the domain modeling system can also be provided with other functional modules so as to realize the domain-drive-based component generation method in the embodiment.
The embodiment of the application further provides electronic equipment, the electronic equipment comprises a memory and a processor, the memory stores a computer program, and the processor executes the computer program to realize the component generation method or the cache reading method based on the domain drive. The electronic equipment can be any intelligent terminal including a tablet computer, a vehicle-mounted computer and the like.
Referring to fig. 12, fig. 12 illustrates a hardware structure of an electronic device according to another embodiment, where the electronic device includes:
the processor 1201 may be implemented by a general-purpose CPU (central processing unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits, and is configured to execute a relevant program to implement the technical solution provided in the embodiment of the present application;
the memory 1202 may be implemented in the form of a Read Only Memory (ROM), a static storage device, a dynamic storage device, or a Random Access Memory (RAM). The memory 1202 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1202 and called by the processor 1201 to execute the domain-based driver component generation method according to the embodiments of the present application;
an input/output interface 1203 for implementing information input and output;
the communication interface 1204 is used for realizing communication interaction between the device and other devices, and may realize communication in a wired manner (e.g., USB, network cable, etc.) or in a wireless manner (e.g., mobile network, WIFI, bluetooth, etc.);
a bus 1205 that transfers information between the various components of the device (e.g., the processor 1201, memory 1202, input/output interface 1203, and communication interface 1204);
wherein the processor 1201, the memory 1202, the input/output interface 1203 and the communication interface 1204 enable communication connections with each other within the device via the bus 1205.
An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the method for generating a component based on a domain driver is implemented.
The memory, which is a non-transitory computer readable storage medium, may be used to store non-transitory software programs as well as non-transitory computer executable programs. Further, the memory may include high speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory optionally includes memory located remotely from the processor, and these remote memories may be connected to the processor through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
According to the method, the system, the equipment and the storage medium for generating the component based on the domain drive, business process information can be identified through plan definition information, after plan subdomains are obtained through division according to the business process information, a plurality of business information texts in the plan subdomains are identified, domain nouns of the plan subdomains are extracted, in order to further limit the limit, in the embodiment of the application, the specification of a limit context is applied in the field drive design, the domain nouns under the same limit context are packaged in the boundary of the plan subdomains, all domain nouns irrelevant to the functions of the subdomains are excluded from the limit context, the unicity of subdomain responsibilities and the purity of subsequent domain models are guaranteed, finally, the domain model is built based on the plan subdomains, the built domain model can be used as input of micro-service design, a target plan component is finally generated according to the code mapping relation of the domain model, and the multiplexing capacity of a cross-channel system can be improved through the target plan component generated in the embodiment of the application, and the difficulty of development, operation and maintenance is reduced.
The embodiments described in the embodiments of the present application are for more clearly illustrating the technical solutions of the embodiments of the present application, and do not constitute a limitation to the technical solutions provided in the embodiments of the present application, and it is obvious to those skilled in the art that the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems with the evolution of technology and the emergence of new application scenarios.
It will be appreciated by those skilled in the art that the embodiments shown in the figures are not intended to limit the embodiments of the present application and may include more or fewer steps than those shown, or some of the steps may be combined, or different steps may be included.
The above-described embodiments of the apparatus are merely illustrative, wherein the units illustrated as separate components may or may not be physically separate, i.e. may be located in one place, or may also be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment.
It will be understood by those of ordinary skill in the art that all or some of the steps of the methods, systems, and functional modules/units in the devices disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof.
The terms "first," "second," "third," "fourth," and the like in the description of the application and the above-described figures, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
It should be understood that in the present application, "at least one" means one or more, "a plurality" means two or more. "and/or" to describe the association of associated objects, indicates that three relationships may exist, e.g., "A and/or B" may indicate: only A, only B and both A and B are present, wherein A and B may be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. "at least one of the following" or similar expressions refer to any combination of these items, including any combination of the singular or plural items. For example, at least one (one) of a, b, or c, may represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", wherein a, b, c may be single or plural.
In the several embodiments provided in the present application, it should be understood that the disclosed system and method may be implemented in other ways. For example, the above-described system embodiments are merely illustrative, and for example, the division of the above-described units is only one logical functional division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes multiple instructions for causing a computer device (which may be a personal computer, a server, or a network device) to perform all or part of the steps of the method of the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing programs, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.
The preferred embodiments of the present application have been described above with reference to the accompanying drawings, and the scope of the claims of the embodiments of the present application is not limited thereto. Any modifications, equivalents and improvements that may occur to those skilled in the art without departing from the scope and spirit of the embodiments of the present application are intended to be within the scope of the claims of the embodiments of the present application.
Claims (10)
1. A domain-driven-based component generation method, the method comprising:
acquiring service flow information and plan definition information;
performing field division according to the service flow information to obtain a plurality of sub-fields, and determining a plan sub-field in the plurality of sub-fields;
identifying the business process information in the planned subdomain according to the plan definition information to obtain a plurality of business information texts of the business process;
extracting field nouns of the plan subdomain from each service information text;
encapsulating the domain nouns in the same boundary context within the boundaries of the plan subdomain;
and performing domain modeling on the basis of the packaged plan subdomain to obtain a domain model, and generating a target plan component according to a code mapping relation of the domain model.
2. The method according to claim 1, wherein the identifying the business process information in the planned subdomain according to the plan definition information to obtain a plurality of business information texts of a business process comprises:
acquiring a preset plan meta-model, wherein the plan meta-model is established according to the composition relation among sample function modules in a sample business process;
identifying a functional module related to the plan from the plan meta-model according to the plan definition information;
and mapping the functional module and the service process information, and identifying and obtaining a plurality of service information texts of the service process according to a mapping result.
3. The method for generating a domain-driven-based component according to claim 1, wherein the service information texts include event information, command information, member information and input information, and the extracting domain nouns of the planning sub-domains from each of the service information texts includes:
establishing an event map according to the incidence relation among the event information, the command information, the member information and the input information;
and extracting the domain nouns of the planning subdomain from the event map.
4. The domain-driven-based component generation method of claim 1 or 3, wherein encapsulating the domain terms in the same boundary context within the boundaries of the planning sub-domains comprises:
extracting general domain nouns from the domain nouns;
and encapsulating the general domain nouns under the same boundary context in the boundary of the planning subdomain.
5. The domain-driven-based component generation method of claim 1, wherein encapsulating the domain nouns in the same boundary context within the boundaries of the planning sub-domains comprises:
determining a bounding context from the plan definition information;
encapsulating the domain nouns related to the project sub-domain functions within boundaries of the project sub-domain according to the boundary context.
6. The method for generating a domain-driven component according to claim 1, wherein the performing domain division according to the service flow information to obtain a plurality of sub-domains and determining a planned sub-domain among the plurality of sub-domains includes:
performing domain division according to the service flow information to obtain a plurality of sub-domains;
and determining the functional attribute in each sub-domain, and determining the sub-domain with the functional attribute of the general domain function as a planning sub-domain.
7. The method according to claim 1, wherein generating the target plan component according to the code mapping relationship of the domain model comprises:
obtaining a plurality of code objects according to each domain noun mapping in the domain model;
a target plan component is generated from a plurality of the code objects.
8. A domain-driven based component generation system, the system comprising:
the data acquisition module is used for acquiring the service flow information and the plan definition information;
the domain division module is used for carrying out domain division according to the business process information and determining a plan sub-domain in a plurality of sub-domains;
the information identification module is used for identifying the business process information in the planning subdomain according to the plan definition information to obtain a plurality of business information texts of the business process;
a domain name extracting module, configured to extract domain names of the plan subdomain from each of the service information texts;
the packaging module is used for packaging the domain nouns under the same boundary context into the boundary of the plan subdomain;
and the component generating module is used for performing field modeling on the basis of the packaged planning subdomain to obtain a field model and generating a target planning component according to a code mapping relation of the field model.
9. An electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the domain-driven component generation method according to any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium storing a computer program, wherein the computer program is executed by a processor to implement the domain-based component generation method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211257680.6A CN115904362A (en) | 2022-10-12 | 2022-10-12 | Domain-driven-based component generation method, system, device and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211257680.6A CN115904362A (en) | 2022-10-12 | 2022-10-12 | Domain-driven-based component generation method, system, device and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115904362A true CN115904362A (en) | 2023-04-04 |
Family
ID=86488698
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211257680.6A Pending CN115904362A (en) | 2022-10-12 | 2022-10-12 | Domain-driven-based component generation method, system, device and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115904362A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117348863A (en) * | 2023-09-06 | 2024-01-05 | 苏州数设科技有限公司 | Low-code development method and device for industrial software, electronic equipment and storage medium |
| CN118504543A (en) * | 2024-07-19 | 2024-08-16 | 蒲惠智造科技股份有限公司 | Fine granularity implementation plan generation method and system for SaaS software |
-
2022
- 2022-10-12 CN CN202211257680.6A patent/CN115904362A/en active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117348863A (en) * | 2023-09-06 | 2024-01-05 | 苏州数设科技有限公司 | Low-code development method and device for industrial software, electronic equipment and storage medium |
| CN117348863B (en) * | 2023-09-06 | 2024-09-10 | 苏州数设科技有限公司 | Low-code development method and device for industrial software, electronic equipment and storage medium |
| CN118504543A (en) * | 2024-07-19 | 2024-08-16 | 蒲惠智造科技股份有限公司 | Fine granularity implementation plan generation method and system for SaaS software |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Madhuri et al. | Challenges and issues of data analytics in emerging scenarios for big data, cloud and image mining | |
| CN115904362A (en) | Domain-driven-based component generation method, system, device and storage medium | |
| Lawrence | Data readiness levels | |
| Silva et al. | Using vistrails and provenance for teaching scientific visualization | |
| US20140282456A1 (en) | Methods, systems and computer-readable media for code profiling and migration effort estimation | |
| Reimann et al. | Road2CPS priorities and recommendations for research and innovation in cyber-physical systems | |
| van Heesch et al. | Does decision documentation help junior designers rationalize their decisions? A comparative multiple-case study | |
| Saheb et al. | Topical review of artificial intelligence national policies: A mixed method analysis | |
| CN113449046A (en) | Model training method, system and related device based on enterprise knowledge graph | |
| Letmathe et al. | Competence management in the age of cyber physical systems | |
| Malode | Benchmarking public large language model | |
| Dave et al. | Future Trends: The Impact of AI and ML on Regulatory Compliance Training Programs | |
| Costas-Jauregui et al. | Descriptive analytics dashboard for an inclusive learning environment | |
| Jadhav et al. | Artificial Intelligence-Based Model and Applications in Business Decision-Making | |
| Leroux et al. | Model-based systems engineering for systems simulation | |
| Ahonen et al. | An exploratory study of software engineering in heavy-duty mobile machine automation | |
| Winner | Challenges of automotive systems engineering for industry and academia | |
| Coda et al. | Big data on machine to machine integration’s requirement analysis within Industry 4.0 | |
| US10372849B2 (en) | Performing and communicating sheet metal simulations employing a combination of factors | |
| Kaneko et al. | STAMP S&S: Layered Modeling for the complexed system in the society of AI/IoT | |
| Hu et al. | Collaboration Based Simulation Model for Predicting Students’ Performance in Blended Learning | |
| Huddleston et al. | Design and Deployment of a Simulation Platform: Case Study of an Agent-Based Model for Youth Suicide Prevention | |
| Lehmann et al. | Verification, Validation, and Accreditation (VV&A)—Requirements, Standards, and Trends | |
| US20130143192A1 (en) | Method for calculating students' time spent answering questions in an on-line homework system | |
| Goppold et al. | The FRAM error model within a system theoretical work system to support conceptually the development of a technical learning system for learning from errors |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |