WO2015044374A1 - Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung - Google Patents

Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung Download PDF

Info

Publication number
WO2015044374A1
WO2015044374A1 PCT/EP2014/070663 EP2014070663W WO2015044374A1 WO 2015044374 A1 WO2015044374 A1 WO 2015044374A1 EP 2014070663 W EP2014070663 W EP 2014070663W WO 2015044374 A1 WO2015044374 A1 WO 2015044374A1
Authority
WO
WIPO (PCT)
Prior art keywords
model
application
data
user
client
Prior art date
Application number
PCT/EP2014/070663
Other languages
English (en)
French (fr)
Inventor
Rudolf Markus PETRI
Original Assignee
Petri Rudolf Markus
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 Petri Rudolf Markus filed Critical Petri Rudolf Markus
Priority to US15/025,266 priority Critical patent/US10296305B2/en
Priority to EP14789530.4A priority patent/EP3049920A1/de
Publication of WO2015044374A1 publication Critical patent/WO2015044374A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques

Definitions

  • the present invention relates to a method and a computer-implemented device for the automated generation and provision of at least one client / server-based, preferably web-based software application with a user interface for a user.
  • the traditional creation and delivery of software applications for use is based on methods and techniques in which software applications are first created by programming and then installed and commissioned in an operating environment.
  • Model Driven Software Development creates the architecture of the application to be created as well as parts of the source code (class model) from a model (diagram in the graphical modeling language "Unified Modeling Language", UML diagram for short).
  • GUI graphical user interface
  • the source code must be translated into machine language after generation, deprogramming and supplementation with a compiler in order to make the program machine-readable and thus executable. Even with changes to existing software, the source code must be regenerated over and over again, bundled into a program and transferred to the runtime environment.
  • the created or changed software must be installed on a computer, if necessary configured and put into operation in order to be used by the users.
  • tools must first be used to program the source code of the application, which contains, among other things, the commands to the processor controlling the later application program.
  • the source code is translated with tools to machine-readable code and linked / compiled into an application program
  • the application program can be installed on a computer
  • the object of the present invention is to provide a method and a computer-implementable device with which a client / server-based, preferably web-based software application with a user interface can be generated automatically for a user and can be used for this Allow users to access data from a database without having to install the software application on a user's computer.
  • the software application should also be adaptable to the needs of the user in a particularly simple manner and require the least possible compilation effort.
  • a generated soft application does not have to be compiled or installed either on the (client) computer of a user or on a computer for the application platform, eg a (web) server. Rather, the transition from modeling to using a software application occurs without programming, compilation, and installation, so database building, application logic programming, or user interface configuration are not required to build new or change existing software applications.
  • a method according to the invention with which at least one client / server-based, preferably web-based software application with a user interface-preferably several software applications-is automatically generated and provided comprises at least the following steps: Provision of an application platform into which a user can log in via a network, such as the Internet or an intranet, Provision of at least one client-specific database in which data can be stored
  • the application model describes the mode of operation - and thus the subject matter, content and configuration - of the software application, a user interface and the data structure, and
  • model engine on the application platform for processing at least one application model and the access to data of the client-specific database, wherein in the inventive method further the model engine after logging in a user reads the application model at runtime and only at runtime based on the An application model generates a software application with application logic and user interface, wherein the application logic defines the processes that can be executed by the software application in operation and the user can access data from the client-specific database via the user interface, and
  • Commands of the user at the user interface concerning a particular data object are passed on to the model engine at runtime and the model engine accesses the user from the client-specific database using the application model and the application logic created at runtime in order to thereby in particular display and / or edit the data and / or enter and store new data.
  • the field of application of the present invention is thus the creation of (client / server-based, preferably web-based) software applications and their provision on an application platform for immediate use, eg as "software as a service”.
  • the application platform thus provides a runtime environment in which software components, such as the model engine, are executable to generate and provide the software application.
  • the application platform therefore has the task of using system tools to combine the software applications defined in application models via the respectively defined configuration with the functional application modules contained in the application platform, make them executable and ready for use. It is thus needed to create a software application at all and provide it to a user.
  • Client-specific here means that on a computer of the application platform, ie in particular on the same server, databases of multiple clients (customers) can be stored without the individual clients have access to each other databases.
  • a client-specific database with an application model to be read can thus be one of several client-specific databases that are stored in a central database of the application platform. Accordingly, several client-specific databases and / or several preconfigured application models can be stored in a database of the application platform.
  • a model engine is understood to mean a software component which makes it possible to link metadata elements of the application model with the data from the client-specific database.
  • a model engine can thus be used by a database management system to store, read, update, and delete data from a database.
  • the model engine has a translation and coordination function to generate from data elements of the application model specific data objects of the software application as well as to interpret commands on the user interface and process conditions stored in the application model, so that the command to access data the client-specific database and is displayed in the user interface.
  • the model engine is particularly capable of an application model that after logging in a user z.
  • the model engine can also be seen as an application generating device.
  • An application model thus completely describes the software application. It defines, among other things, access to the initial (root or start) interface of the software application after the user logs in, as well as how a command entered through the provided user interface and forwarded to the model engine the data in the client-specific database leads to thereby in particular display and / or edit the data and / or enter and store new data.
  • the application model can thus specify the object, content, configuration, and operation of the software application and serve to assemble, configure, and control software applications at runtime from provisioned application building blocks.
  • the application model is described in an XML document that can be read by the model engine to generate the software application at runtime.
  • the solution according to the invention thus makes it possible to use the limited resources of a data processing system more efficiently and to save additional, often very expensive resources. If many different (specialized) software applications are needed, many different software systems may need to be used. Since each software system requires its own system resources and, if necessary, its own technical configuration, the simultaneous operation of several different systems on a computer system is not efficient and may even be critical if the technical configurations are conflicting. For example, problems often occur with a change in the overall configuration of the DP system due to the replacement or release of components. Using the solution according to the invention, all software applications can be mapped only by means of application models and no different software systems have to be used. All applications (including individual applications) are operated on just one application platform.
  • the set of data belonging to the data object is read from the client-specific database before
  • a visualization of the object instances is generated depending on the read data on the user interface.
  • the application model preferably includes at least a meta-model and an application configuration model.
  • the meta-model defines generic metadata elements as well as data field structures for the user interface and / or attributes associated with the metadata elements.
  • the application configuration model specifies such a meta-model and defines data objects for the software application that derive from metadata elements of the meta-model by assigning concrete or all metadata elements specific roles to the software application to be created and deployed in the application configuration model.
  • the metadata elements are preferably self-referential, i. they can consist of additional metadata elements.
  • the meta model is preferably read at runtime and a class instance of a specific type and a attribute defined for each attribute for a metadata element are generated for each metadata element of a given hierarchy level ,
  • the meta-model may include a schema definition that describes metadata elements.
  • the meta-model in particular defines with which view types (views) a meta-element attribute, and thus in particular with which view types (views) a data field type can be represented.
  • view types and standardized user interface elements can be implemented as building blocks in the application platform.
  • the type of visualization of object instances generated by the model engine can also be predetermined by a view type defined for the data object in the application model.
  • any change in the meta-model can also lead to a change in the structure of the data provided from the client-specific database and possibly to a change of the software application at runtime.
  • an (XML) file which contains the meta-model is modified, whereby the data management is then changed in the case of an associated change in the specifications within the meta-model.
  • XML XML
  • the meta-model describes meta-data attributes for the metadata elements and associates them with standardized user interface elements and, in the client-specific database, data field types such that the meta-model for the software application data objects defines the representation of a data field structure in the user interface.
  • an application configuration model defines one or more software applications (eg, customer relationship management (CRM), product management, event management, music database management, etc.)
  • An application configuration model is assigned, which defines the possible deployable software application (s) and is stored in the client-specific database
  • a user account is also created, which assigns the user to one or more clients
  • the user after logging in automatically via a corresponding provided on the application platform client and rights management the intended for him application configuration model by the - preferably from at least one metamodel and at least one application configuration model built - application model could
  • certain functions of the software application may be described in a machine-readable manner that can be executed at runtime. Under such a function, e.g.
  • the application model includes, preferably in addition to a meta-model and an application configuration model Organization model in which at least one organizational structure of the organization, within which the software application to be generated at runtime is to be used, and / or a business process, which is to be mapped with the software application to be generated at runtime, are stored.
  • An organizational model thus includes, for example, a (static) structural model and, in this case, authorizes authorizations for processes and / or reporting structures provided by the generated software application.
  • an organization model may specify a business process model (dynamic, ie adapted for the respective software application within the same and the same organization) and hereby specifies the business processes which are to be technically supported by the generated software application.
  • the model engine comprises for the individual (sub) models of an application model, e.g. the metamodel, the application configuration model, and the organization model, different processing modules. So it can be provided that the model engine
  • the higher-level generation unit queries the first and second processing modules after loading the meta-model by means of the first processing module and after loading the application configuration model by means of the second processing module into a main memory for generating the software application and generates the software application at runtime.
  • the model engine has a (third) processing module for reading out an organization model which is contained in the application model and via which a check of the access rights to be granted in the software application is made possible at runtime.
  • the organizational model defines this, e.g. Users (groups) and structure information.
  • a first module the meta-model processing module (also called “Meta Model Manager”), reads the meta-model into memory and at runtime generates the concrete objects (instances), ie the concrete records
  • the application configuration model processing module reads the application configuration model into the memory, that is, the XML file that describes the application context of the software application.
  • a third module, the Organizational Model Processing Module reads out a functional organizational model, checks the access rights to applications, processes / workflows, data objects, etc.
  • the information required to generate the software application is queried by the three modules, ie which data objects are specifically assigned, how they are formed at runtime (inheritance), how the display is to be displayed on the user interface and which functions are used from the application platform etc.) and generates the software application at runtime.
  • different application models can be stored in a database of the application platform for different software applications, so that only one specific application model is read by the model engine at runtime to provide one of several different software applications and a user interface based on this application model is generated. in particular a first basic or start-up user interface that is displayed directly after a user logs in.
  • At least one client-specific database and / or at least one preconfigured application model is stored in a local database of a user, while the application platform is provided by a server system.
  • the application platform can thus be operated centrally, in particular in the "cloud", while the data storage for a software application of a user generated at runtime is locally stored there.
  • standard application models and / or standard meta-models may be stored on the application platform.
  • a standard application model or standard meta-model is then modifiable by an application-modeling device executable on the application platform to make it customizable for an individual software application.
  • a modified standard application model or meta-model is then storable via the application model creation device as another application model or metamodel.
  • an application model is formed only from a reference to a standard application model and possibly a special configuration model, wherein in the configuration model only any deviations from the respective standard application model are specified.
  • a standard application model is preferably kept here in an application model memory.
  • Such an application model memory is preferably stored in a central database in which the client-specific databases are also stored.
  • a further aspect of the present invention is a computer-implemented device for the automated generation and provision of at least one client / server-based, preferably web-based software application with a user interface for a user as claimed in claim 17.
  • a device which can be used on a computer, in particular a ( Web) server is installed, can be designed and provided in particular for carrying out a method according to the invention.
  • An inventive device comprises at least the following: an application platform into which a user, preferably via a network, can log in, at least one client-specific database on the application platform in which data can be stored, at least one application model stored in the client-specific database the generation of the at least one software application, wherein the application model describes the functioning of the software application, a user interface and the data structure are processable, and a model engine on the application platform for processing at least one application model and accessing data of the client-specific database.
  • the application model can be read out by means of the model engine, and based on the application model, also by means of the model engine, a software application can be generated that contains a user interface via which the user can access data from the client-specific Database can access.
  • the model engine is designed in such a way that commands of the user at the user interface of the software application that it relates to, which are related to a specific data object are passed on to the model engine at runtime and the model engine to the user using the application model Access to data belonging to the data object allowed.
  • the application platform can have a control device which loads the application model from the client-specific database after logging in of a user and loads it into the working memory of a computer on which the device is installed.
  • a device may comprise an application model creation device and / or an application model memory.
  • an easily manageable and variable possibility is provided to use any number of models at runtime simultaneously and / or in parallel, and thus to run any number of software applications based on any number of different application models on the same platform.
  • the models can also be optimized during runtime.
  • the application model of the software application is generated from an application-independent meta-model and an application-related configuration model. Subsequently, a client-specific database is created from an empty database and the application model. At runtime, one finally reads in the application platform
  • Application generating device the model engine used in the client application-specific database and automatically generates the immediately usable software application from the application logic and interface description contained therein as well as the generic views (GUI) and functions contained in the application platform.
  • GUI generic views
  • a computer program product for operating a computer, in particular a web server, which has machine-readable code which, when executed on the computer, is designed to cause the computer to carry out a method according to the invention.
  • a further aspect of the present invention is a machine-readable storage medium having machine-readable program code which is designed to be executed on a computer, in particular a web server, and to cause the computer to execute a method according to the invention when executing the program code.
  • a computer-implemented device for producing a computer program product by means of which a method according to the invention can be executed, in which an application model comprises at least one meta model and one application configuration model.
  • an application model comprises at least one meta model and one application configuration model.
  • Such a device according to the invention comprises at least:
  • a first generation module for creating a meta-model, wherein metadata elements are defined in the meta-model and data field structures for the user interface, attributes and / or functions associated with the metadata elements are defined, and
  • a second creation module for creating an application configuration model, wherein the meta-model is specified via the application configuration model and data objects for the software application are derived from metadata elements of the meta-model by providing concrete roles in the application configuration model for the software application to be created and deployed at runtime be assigned to.
  • At least one build module defines at least one graphical user interface through which an operator may create a meta-model and / or an application-configuration model.
  • an operator may create a meta-model and / or an application-configuration model.
  • the meta-model and / or the application configuration model include at least one XML document, and the first and / or second generation modules are provided to create and / or modify an XML document to create the respective model.
  • the model engine works with application models that are described exclusively in XML documents.
  • the device comprises, in addition to the first creation module (meta-model creation module) and the second creation module (application configuration model creation module), a third creation module for creating an organization model already mentioned above (organization model creation module).
  • the individual modules of the device thus serve here to create the corresponding submodels of the application model.
  • Fig. 1 is a flowchart for a variant embodiment
  • Fig. 2 is a schematic representation of a variant embodiment
  • Fig. 3 is a schematic representation of the generation of a graphic
  • 4B is a schematic representation of the generation of a
  • 4C is a schematic representation of the generation of a
  • 5A is a schematic representation of an instantiation at runtime according to a conventional object-oriented approach for developing a software application for the embodiment of FIG.
  • FIG. 5B shows a schematic representation of an instantiation at runtime according to the inventive method for the embodiment of FIG. 4A;
  • 6A is a schematic representation of the functions of a
  • 6B is a schematic representation of the functions of
  • FIG. 1 initially shows a flow chart for an embodiment variant of a method according to the invention for the automated generation and provision of a client / server-based, preferably web-based software application AW with a user interface GUI for a user.
  • the illustrated flowchart also includes phases for the creation of an application model AM and the assignment of user rights by a tenant management device CA (English, "serves administrator"), which in advance (Section I in Figure 1) by a provider the software application AW are to be made before it is automatically generated when needed at runtime (Section II) and provided for use, ie, is usable.
  • a tenant management device CA English, "serves administrator”
  • the core of the illustrated embodiment variant is the generation and provision of the software application at runtime without programming.
  • an application model designer AM (application model designer) of an application-independent meta-model MM and an application-related configuration model or application configuration model AKM generates a (here: data-oriented) application model AM of the application. not shown) and the application model AM a client-specific database CSD (engl., "serves specific database”).
  • a model engine ME reads out the application model AM lying in the client-specific database CSD.
  • This model engine generates the software application AW from an application logic AL described in the application model AM and a surface description OB also contained therein, as well as from generic functions and generic view types (views) for the graphical user interface GUI.
  • the generic functions and view types are implemented in an application platform on which, as the runtime environment, in particular the application model creation device AMD, the client management device CA and the model engine ME are executable.
  • FIG. 1 A variant embodiment of a computer-implemented device S1 according to the invention, with which the variant of a method according to the invention described with reference to FIG. 1 is executed, is illustrated in FIG.
  • the device S1 not only an automatic generation and provision of software applications at runtime on a preferably web-based application platform is possible, but also a creation of the software applications before a first use using the application model creation device AMD and the client management device CA.
  • the device S1 includes an application platform with a (generic) user interface GUI, the model engine ME and a central database DB, in which several client-specific databases CSDi .. x are stored. From these client-specific databases, the structure of two databases CSDi and CSDx is shown in greater detail by way of example, in which data sets DS are stored.
  • the device S1 comprises the client management device CA and the application model creation device AMD, which run as tools on the application platform. Using the AMD application model builder, concrete platform-dependent meta-models and application configuration models can be created and managed based on an abstract platform-independent meta-meta-model (not shown).
  • FIG. 2 shows an individual meta-model MMi of the client-specific database CSDi and a standard meta-model MMSTANDARD.1 which are stored in an application model repository AMR of the device S1 as part of a standard application model AMSTANDARD.I becomes.
  • a metamodel MMi or MMSTANDARD.I is a schema definition that describes building blocks in the form of metadata elements. From a meta model MMi or MMSTANDARD.I, a (client-specific) database model (without figure) is derived.
  • meta-model MMi or MMSTANDARD.I defines the representation of the data field structure of the data object types in the user interface GUI by describing meta-element attributes in the metamodel MMi or MMSTANDARD.I and the generic user interface GUI data field types and standardized user interface elements (eg input fields with cardinalities ) are assigned automatically.
  • the application configuration model AKMi or AKMSTANDARD I defines the remaining part of the surface. It defines for each data object of the application AW with which view types (views) it should be displayed in which contexts (eg single view, list view).
  • the view types and standardized user interface elements are each implemented as building blocks in the application platform.
  • the presentation on the user interface GUI can be subsequently modified by means of the application model creation device AMD.
  • An application configuration model AKMi or AKMSTANDARD I describes the structure and process organization basics and conditions of a software application AW the respective client-specific database CSDi or CSDx (ie organizational units, processes, roles, users, rights), the business processes to be supported and corresponding workflows, a concrete data storage DH (compare FIG.
  • the application configuration model in FIG. 2 by way of example AKMi or AKMSTANDARD.-I, accordingly specifies the subject, content, configuration and mode of operation of an application AW and serves to assemble the application AW at runtime from the application modules, to configure them and to control their behavior.
  • An application configuration model AKMi or AKM S TANDARD is also used to specify the respective meta-model MMi or MMSTANDARD, ie to form concrete objects from the abstract objects defined with the metamodel MMi or MMSTANDARDJ by filling the abstract objects with concrete data at runtime and thus concretized, typed and configured.
  • predefined attributes can also be modified via the respective meta-model MMi or MMSTANDARDJ.
  • a meta-model MMi or MMSTANDARDJ and an application configuration model AKMi or AKMSTANDARD together form an application model AMi or a standard application model AMSTANDARD.L
  • the respective application model AMi or AMSTANDARD.1 completely describes a software application.
  • a (software) application AW is not defined by a concrete professional class model that has to be programmed, but by an application model AMi or
  • An application model can be provided here as a standard application model AMSTANDARD or as an individual application model AMi. It accordingly describes a standard software application or an individual software application.
  • an application model AM 2 for the software application AW to be generated at runtime which consists only of references V-AMSTANDARD to the standard application model AMSTANDARD, I and possibly Deviations AB-AMSTANDARD is formed by the standard application model AMSTANDARD.
  • a standard application model AMSTANDARDJ can therefore be extended or modified at any time by additional configuration information created with the application model creation device AMD, the standard application models still being kept in the application model memory AMR.
  • a final determination is not associated with the original purpose of an application model as a standard or individual application.
  • a once created application model AMi or a standard application model AMSTANDARDJ can be used as often as desired by referencing or copying and optionally modified as a new application model (in a client-specific database CSDi .. x and / or the application model memory AMR) are stored. Consequently, the device S1 can simultaneously contain and use any number of application models.
  • a data storage DH of an application is created in advance with the aid of the client management device CA.
  • an empty database (not shown) is first created, the desired application model, e.g. AMi, passed to the database.
  • the database model i.e. the concrete data structure, is generated in which the actual data can then be stored.
  • the creation of an application and at the same time its provision for use takes place automatically at runtime.
  • a control unit of the application platform right-controlled loads the application model, e.g. AMi, and it loads in the main memory of the computer (without figure) on which device S1 is installed.
  • the model engine ME which reads out the instantiated application model AMi (eg for a CRM application), evaluates the configuration information from the application model AMi and, at runtime, the corresponding one
  • the object of the application is generated by converting abstract data model objects (such as "organization") into concrete objects (such as "customer (company)”) at runtime and assigning them to the application.
  • Object relationships (such as "belong to an organization (s) persons") are also at runtime using the Application configuration model AKM evaluated and typed (ie, for example, can be assigned to a "customer” only a "contact person (customer)” and not any person).
  • the Model Engine ME forwards the necessary parameters to the generic GUI blocks with which the user interface GUI is then generated.
  • the model engine ME thus provides the objects that are necessary for the processing and display of corresponding data. If a data record is to be processed by calling a function, the model engine ME generates the required object in the working memory at runtime. Objects have the class "model instance.” The class "model instance” consists of the class “ModelElement” and the parameter defined for this "ModelElement” in the application configuration model AKM. The model engine ME therefore generates model instances for further processing by means of factory methods and evaluation of the application model AM.
  • the model engine ME is implemented in such a way that it can map and manage any models or structures.
  • a functional class model of the model engine ME itself basically consists of two classes: nodes and attributes. Nodes can contain attributes. Furthermore, nodes can be linked to any other nodes. If an application model is transferred, the model engine ME is able to derive a framework of nodes with properties (attributes) from this model.
  • a specialized logic which must already be defined in the conventional software development during the programming, is given by this mechanism only at runtime in the form of the respective application model. This will be explained in more detail in particular in connection with the attached FIGS. 4C and 5B by means of an exemplary software application.
  • Application model AM dependent on defined conditions.
  • Each request or command e.g., "Show customer data" is first directed to the model engine ME.
  • Function module on (eg "Generate document") and provides the data according to the Application model AMi defined information, ie, with the corresponding view, on the user interface GUI.
  • the application platform automatically assigns each data area a list view and corresponding basic functions - such as display, add, edit, delete, copy - to.
  • each record DS may automatically be assigned, for example, a detail view and associated basic functions - such as add, edit, save, delete, copy.
  • view type is preferably already a basic configuration deposited, which is specified by information or specifications from the associated application configuration model AKMi or possibly even changed.
  • the basic configuration may include, for example, indexing, presentation as a table with empty column names (as transfer parameters), filter functions, basis functions, etc., which may be provided by the application configuration model in the form of data object information, assigning selected fields of the data object to columns of the table , the assignment of special functions, etc. is specified (see also Figure 3).
  • the model engine ME If the user requests e.g. From a list of objects (customers, prospects, contact persons, etc.) by selecting a data object (eg customer) the associated records DS (eg the customer data), the model engine ME reads the application model (eg AMi) and generates the object instances in memory. The model engine ME requests the values for the data object from the client-specific database (CSDi) via a database access layer (component of the database DB, not shown separately) and transfers the visualization of the object instances according to the information stored in the application model (AMi) via the associated view type (here: a list view) - to the generic user interface GUI.
  • a database access layer component of the database DB, not shown separately
  • the generic user interface GUI provides the view type and, according to the assignment made in the data model, the standardized user interface elements belonging to the data object and displays them on the user interface GUI.
  • the data field structure and representation in the user interface GUI is automatically removed from the Metamodel (MMi) derived.
  • functions of the (software) applications AW are preferably also implemented in the application platform as generic function modules and are specified and configured at runtime by the respective application model, eg AMi or AM 2 .
  • the application model defines whether a function should be displayed as a button or automatically triggered. If the latter should be the case, it is further specified which conditions should lead to an execution of the function.
  • a specific function is executed after saving a data set DS if the current date is "today.”
  • the application model stores which label the button receives and which preconditions If necessary, ie, whether the execution of the function should be dependent on the rights, it is also defined in an application model which data object (eg person, task, appointment) should be transferred from the data model as transfer parameter and which postconditions exist, ie For example, if and what should be done after the function has been executed, this means, for example, that an attribute "last contact" for a data object person is updated to "today" and a follow-up is created.
  • data object eg person, task, appointment
  • a solution according to the invention differs from the conventional methods of software development and provisioning in that it involves the transition from the model definition to the use of a software application AW without programming, compilation and installation.
  • the solution according to the invention also offers the possibility of simultaneously using any number of application models AM at runtime and thus to operate any number of applications AW based on any number of different meta models MM on the same platform.
  • the application models AM can also be optimized at runtime.
  • conventional methods require a rigid metamodel.
  • the aim is to create a database application AW (called "jukebox") for the management of audio and video CDs / albums, which in addition to the elementary functions such as displaying, editing, saving and deleting, also the sorting of the data records , which allows you to print out lists and search for data, display a list of the data objects contained in list views and display the information about a data object in the form of a detailed view.
  • AW database application
  • FIG. 4A the content of an application model AM (shown in abstract) for this embodiment of a software application with its meta-model MM and its application configuration model AKM is shown in excerpts.
  • the illustrated application model AM further defines certain rules, that is, in particular functions that are to be executed at runtime, as well as workflows.
  • FIG. 4B schematically shows the generation of a data storage DH for the software application "Jukebox" from the meta-model MM
  • FIG. 4C schematically illustrates the generation of a class model with classes and class attributes from the meta-model MM at runtime by a model engine ME.
  • FIGS. 5A and 5B compare the different instantiations at runtime in a conventional object-oriented approach and in the solution according to the invention for the software application "jukebox".
  • the application model builder AMD first builds the application model AM for the Jukebox application by selecting the meta-model MM and assigning it to the application by referencing inheriting the basic properties of the data objects, which can now be extended to meet specific application needs At the same time, inherited properties can also be marked, for example, to hide data fields at runtime.
  • the metamodel MM already defines the basic functions based on a schema definition and models the user interface of the application, since the metamodel MM specifications based on referencing automatically apply to the application model AM of the "Jukebox" application Metamodel MM was created by copying a standard metamodel MMSTANDARD I.
  • the application model creation device AMD now also describes an application configuration model AKM.
  • the model for the jukebox e.g. the following specifications have been made:
  • the application configuration model for the role "artist” is described as derived from the meta-role "person” of the metamodel MM.
  • the Role “Artist” is defined here by a parameter “Role” in the application configuration model AKM, which is to be assigned the value "Artist”, where the assignment to the meta role "Person” takes place via a path.
  • Role in the application configuration model AKM, which is to be assigned the value "Artist”, where the assignment to the meta role "Person” takes place via a path.
  • the application configuration model AKM defines that for each newly created person the role "Artist” is to be set and at the same time only those persons (in the list) are shown who also have the role "Artist”.
  • a data object "Artist” is derived via a parameter "Role” from the data area "Person” of the meta-model MM
  • An adaptation or extension of the data object "Artist” could take place via further parameters by means of the application configuration model AKM.
  • the artist data item could be expanded to include an artist name field that does not exist in the person metadata element.
  • the application “Jukebox” is completely described by the application model AW comprising the meta-model MM and the application configuration model AKM, in particular its database model DBM for the database DB standing behind it (compare FIG. 4B).
  • a database (without a figure) is created, the created application model AM is transferred to the database for the "Jukebox” application, and the specific data structure is automatically generated.
  • the generation of the "Jukebox” application at runtime after a user logs in is as already described above described.
  • the abstract objects “Person” and “Product” are specified by the roles “Artist” and “Album” respectively.
  • the meta-model MM is read in at runtime for this purpose.
  • a framework of nodes with properties is derived from this, in that links already defined in the meta-model MM are read in the same way and mapped in each case as ModelAttributes.
  • the user now wants to collect data about an album and assign it to an artist ("artist"), assuming that a record for an "artist” data object has already been created and the user has opened the list of albums.
  • the marking of the desired album record and the call of the function "show” (by pressing a button "Show") on the user interface GUI causes the corresponding request to be routed to the model engine ME.
  • the command is passed to the model engine ME, which in turn reads the application model AM, evaluates the user's rights, passes the command to release the record for processing to the database DB or the client-specific database CSD and the Command to change the display in the edit / input mode to the user interface GUI passes.
  • More complex commands and functions are mapped using the rules of the application model AM.
  • the rules are defined in the application model AM according to the standards usual for rule-based systems.
  • the execution of a command defined here is triggered by a condition and a trigger and is carried out automatically.
  • a “calculatesum” function defined under “Rules” in the application model AM for the "Jukebox” application calculates the total value of the album collection based on purchase prices of each album.
  • the model engine ME reads out the application model AM with the rules stored there, evaluates the conditions according to the application model AM, transfers the parameters to the other Execution of the respective command and accepts the result for further processing, ie, for example, for display on the user interface GUI.
  • GUI-FK of a user interface of a computer-implemented device for creating, in particular, an application model AM for a software application and the application platform on which a software application can run are illustrated by way of example with FIGS. 6A and 6B.
  • FIGS. 6A and 6B surface functions GUI-FK of a user interface of a computer-implemented device for creating, in particular, an application model AM for a software application and the application platform on which a software application can run are illustrated by way of example with FIGS. 6A and 6B.
  • FIGS. 6A and 6B surface functions GUI-FK of a user interface of a computer-implemented device for creating, in particular, an application model AM for a software application and the application platform on which a software application can run are illustrated by way of example with FIGS. 6A and 6B.
  • the generation and provision of a software application AW with support of stored business processes is possible by providing an organizational model OM in addition to a meta-model MM and an application configuration model AKM.
  • FIG. 6A shows system tools whose functions can be used by an operator via a user interface in order to generate an application model AM for a software application in a simple manner and without in-depth programming knowledge.
  • an application model AM should comprise a plurality of submodels or submodels in the form of a meta model MM, an application configuration model AKM and an organization model OM.
  • the device shown schematically in FIG. 6A now has inter alia an application model creation device AMD with several modules for the individual submodels of the application model, thus a meta-model creation module MMD, an organization model creation module OMD and an application configuration model creation module AKMD.
  • a rule creation module RD in addition to the application model creation device AMD, a rule creation module RD, a workflow creation module WFE, a test tool TS, and (standard) view building blocks VW are provided.
  • the surface functions GUI-FK realized by this will be described in more detail below.
  • the meta-model creation module MMD (English, "meta model designer") is used to describe the data storage DH of a software application AW and to manage the created meta-models Using a meta-model MM, the data objects and object relationships / structures of an application AW are to be defined with it For example, the metamodel is technically available as an XML schema file
  • the organizational models OM and application configuration models AKM are also described in XML documents: XML is not a programming language, but only a metalanguage, so XML documents themselves contain no commands and loops like a programming language (and therefore no instructions the processor, as is the case with conventional "hard-coded” applications.)
  • the documents will later be evaluated by the Model Engine ME to derive the commands to create.
  • the meta model MM already defines object-related rules (in particular plausibility checks) and models the user interface GUI of the application AW. In addition, it defines the representation of the data field structure of the data object types in the user interface GUI by automatically assigning standardized GUI elements of the generic user interface (for example input fields together with cardinalities) to the data field types described in the meta model MM.
  • the view types and standardized GUI elements are implemented as building blocks in the application platform.
  • the organizational model creation module OMD model organization designer
  • OMD is used to model both the process organization and the task-related, functional structures of an organization or project (as a time-limited organization) the software application AW to be created needs to be.
  • An organizational model OM therefore includes, for example, at least one structural model, a process model and a business process model separately.
  • the structural model and the process model lay a rather static view of an organization, as it depicts its organizational structure and the ideal process organization.
  • the information from a structural model can be used, for example, to assign structural, that is, task-oriented authorizations, evaluate reporting structures in the user company differentiated according to organizational units, manage components and functions in business management, in particular HR applications, or handle tasks arising in the context of business workflows Assign to editors.
  • a process model describes the ideal process structure of an organization, based on the classic division / categorization into core, management, and support processes. The processes are broken down hierarchically and displayed in more detail from level to level.
  • the business process model is dynamically oriented. It describes the concrete business processes that are to be technically supported, among others, by the software application AW to be created.
  • the individual process modules (activities) are selected from the (static) process model according to the business processes to be supported, brought into the desired sequences and combined with linking and execution rules.
  • the business processes depicted in this way will later be used as the basis for execution as workflows.
  • the application-specific configuration settings are bundled in the application configuration model AKM, which are managed using the application configuration model creation module.
  • an application configuration model AKM serves to specify the meta model MM, ie to form concrete objects from the abstract objects defined with the meta model MM by filling the abstract objects with concrete data at runtime and thus concretizing, typing and configuring them.
  • the predefined attributes can also be modified.
  • the application configuration model AKM also specifies and configures the functions implemented in the application platform as generic function modules.
  • a function for example, it is defined whether a function should be displayed as a button or automatically triggered. If the latter is to be the case, it is further specified which conditions should lead to an execution of the function (eg after saving a data record as well as if the current date is "today".) If the function is to be displayed as a button, then The created application model AM stores, which label the button receives and which preconditions exist, eg, whether the execution of the function should be dependent on the rights.Furthermore, it is defined which data object (eg person, task, appointment) from the meta model as transfer Parameter and which postconditions exist, ie, whether and after the execution of the Function is still to take place (eg "last contact” to "update today", create follow-up, etc.).
  • data object eg person, task, appointment
  • the application model creation device AMD furthermore also has overarching functionalities which serve to create the application model AM from the abovementioned submodels and the other application components (rules, etc.).
  • Such an application model AM is created by controlling the interaction of the submodels (MM, OM and AKM), model building blocks and application components and the concrete characteristics of the business objects via configuration.
  • the various configuration options of the individual submodels and application components are functionally combined in the application model creation device AMD.
  • Some application components are z. B. can be created separately by the rule creation module RD and the workflow creation module WFE.
  • Rule Authoring Module The role of Rule Authoring Module is to define and capture business rules and facts, and to enable centralized management, review, and deployment.
  • Business rules (such as "When the sun is shining, the ice cream costs 50 cents more.") Play an important role in almost all areas of the company, describing not only the organizational knowledge and control information relevant to these areas of business, but also the business logic of Software systems designed to support these business units determine how a software system or business process controlled by an AW software application should behave.
  • the business rules are preferably managed in a central repository, maintained and stored in a revision-proof manner, to make them available for the creation of applications AW, and also for the basic behavior of an application AW later on
  • the business rules can still be changed, simulated, checked and made available at runtime Structured tasks and processes, in particular the business processes defined in the organizational / process model, should also be processed with the help of a workflow Management "can be supported in terms of information technology and, if necessary, automated, for which the workflow creation module WFE is helpful.
  • a workflow is a workflow (alternatively business transaction or general operation) that is built up of individual activities that relate to parts of a business process or other organizational processes.
  • the workflow describes the operational-technical view of the (business) processes to be supported. Ideally, this description is made so precisely that the following activity is determined by the outcome of the preceding one. The individual activities are therefore dependent on each other.
  • a workflow has a defined start, an organized process and a defined end. He is the part of the (business) process that can be carried out with IT support. Workflows are characterized by a coordinative character.
  • a workflow is typically achieved by sequencing and parallelizing the work steps. Synchronous activities are strictly separated.
  • the workflow creation module WFE is used to model and configure concrete workflows. Here it can realize the following functions:
  • the test tool TS also provides functionalities for the constructive and analytical quality assurance in order to avoid any errors in the created application model AM or in a software application AW generated thereby, or at least to be able to determine them at an early stage.
  • the model engine ME functions provided by the application platform are outlined using different functional components, such as the model engine ME.
  • a rule engine RE a workflow engine WE
  • a function module FK a system administration module SYS
  • the model engine may include different processing modules for the submodels MM, OM, and AKM of an application model AM, eg, a meta-model processing module, an application configuration model processing module, and an organization model manager processing module.
  • rule engine RE comply with common standards for rule engines and consist of e.g. out:
  • the workflow engine WE is equipped, for example, with the following technological core components:
  • functions that can be used or can be called up within an application model are made available via the function module FK.
  • Functions essentially determine what a generated software application AW can do. For example, they serve to perform operations on data and to produce processing results. In practice, the operations can be composed of a wide variety of parameters and thus can be arbitrarily complex.
  • functions are implemented as standard functions, so that they can be combined at runtime with any application models AM and application components.
  • elementary functions are ever-recurring, basic functions from which other functions can be formed. Examples include saving, copying or deleting data or sending e-mail.
  • the complex functions are composed of elementary functions by means of basic operations, concatenation, differentiation or integration. They can also be model-specific configurable. Examples of complex functions are: - sorting and searching,
  • the configurable functions must be adapted to the specific application model. Examples of such functions are:
  • the functions are implemented in the application platform as generic function blocks, which must be developed conventionally.
  • the configurable functions can be specified and configured at runtime by the application model AM.
  • the application model AM for example, - as described above - defines whether a function should be displayed as a button or automatically triggered.
  • the system administration module is a central technical component of the application platform. Its task is to provide the administrative interfaces for setting up and managing the entire system and to support its smooth operation. It preferably provides the following functionalities:
  • the invention proposes a method and a technical device for automatically generating software applications AW without having to be able to program, compile and / or install.
  • Applications are preferably first defined / described with the help of appropriate tools in holistic models and then generated and configured model-driven with the necessary data structures (classes / data and business objects), business / application logic and views.
  • an application is only created at runtime, ie when the user logs in. Only at this time is an application model AM, for which the user is authorized, loaded into the cache of the web / application server and read into a model engine ME and processed.
  • the application AW itself is generated from the application logic AL and surface description contained in the application model AM and the generic application modules contained in the application platform.
  • the application model AM In this case, in the application model AM, all information relevant for an application AW is shown (including the application purpose or context, the roles and access rights of the user, etc.). After checking the roles and rights of the user, the appropriate startup screen is generated. Also with each further action in the application AW (whether executed by the user or automatically by the system), first the application model AM is read out and processed, which then specifies the further behavior of the application AW.
  • server and client-side operations must be performed.
  • Components of an overall system comprising at least one (web) server and at least one client are accordingly in a preferred embodiment:
  • a database is not necessarily required (eg for the storage of application models AM). It is also possible to work with file systems if only XML documents / files are used. However, if a database is used, a non- Relational database server considered advantageous (eg an XML database). Nevertheless, the use of other database technologies is basically possible.
  • Each client is set up its own database.
  • the databases can be assigned to any number of database servers. These in turn can be operated completely independently of the application platform and distributed as desired.
  • the application platform can also be parallel by addressing the various databases in which the different application models AM are located to provide any number of different applications.
  • a “cloud” solution based on the invention can be achieved, moreover, that a user in his own (individual or individualized) software applications know-how and its data for security reasons secured locally and thus stored locally, without on
  • the data management and the application models AM, in which the business / application logic AL of the software applications AWA is mapped, can be distributed arbitrarily, ie also to local resources.
  • V-AMSTANDARD Reference to standardized application model VW view building blocks

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

Die vorliegende Erfindung betrifft ein Verfahren und eine computerimplementierte Einrichtung zur automatisierten Erzeugung und Bereitstellung wenigstens einer Client-/Server-basierten, vorzugsweise webbasierten Softwareanwendung mit einer Benutzeroberfläche für einen Nutzer. Vorgesehen sind hierfür jeweils wenigstens: - eine Anwendungsplattform, in die sich ein Nutzer einloggen kann, - mindestens eine mandantenspezifische Datenbank (CSD), in der Daten abgespeichert werden können, - zumindest ein in der mandantenspezifischen Datenbank (CSD) gespeichertes Anwendungsmodell (AM) für die Erzeugung der wenigstens einen Softwareanwendung (AW), wobei mit dem Anwendungsmodell (AM) die Funktionsweise der Softwareanwendung (AW), eine Benutzeroberfläche (GUI) und die Datenstruktur maschinell verarbeitbar beschrieben sind, - und eine Modell-Engine (ME) auf der Anwendungsplattform für den Zugriff auf Daten der mandantenspezifischen Datenbank (CSD). Erfindungsgemäß wird vorgeschlagen, dass die Modell-Engine (ME) nach dem Einloggen eines Nutzers das Anwendungsmodell (AM) zur Laufzeit ausliest und erst zur Laufzeit auf Basis des Anwendungsmodells (AM) eine Softwareanwendung (AW) mit Anwendungslogik (AL) und Benutzeroberfläche (GUI) erzeugt, wobei die Anwendungslogik (AL) die von der Softwareanwendung (AW) im Betrieb ausführbaren Prozesse definiert und der Nutzer über die Benutzeroberfläche (GUI) auf Daten aus der mandantenspezifischen Datenbank (CSD) zugreifen kann, wobei Befehle des Nutzers an der Benutzeroberfläche (GUI) betreffend ein bestimmtes Datenobjekt zur Laufzeit an die Modell-Engine (ME) weitergegeben werden und die Modell-Engine (ME) dem Nutzer unter Rückgriff auf das Anwendungsmodell (AM) und die hieraus zur Laufzeit erstellte Anwendungslogik (AL) einen Zugriff auf zu dem Datenobjekt gehörende Daten aus der mandantenspezifischen Datenbank (CSD) gestattet.

Description

Verfahren und Einrichtung zur automatisierten Erzeugung und Bereitstellung wenigstens einer Softwareanwendung
Beschreibung
Die vorliegende Erfindung betrifft insbesondere ein Verfahren und eine computerimplementierte Einrichtung zur automatisierten Erzeugung und Bereitstellung wenigstens einer Client-/ Server-basierten, vorzugsweise webbasierten Softwareanwendung mit einer Benutzeroberfläche für einen Nutzer.
Die herkömmlichen Erstellung und Bereitstellung von Softwareanwendungen zur Nutzung basiert auf Verfahren und Techniken, bei denen Softwareanwendungen zuerst durch Programmierung erstellt und dann in einer Betriebsumgebung installiert und in Betrieb genommen werden.
Dabei beschreiben zunächst Softwareentwickler die fachliche Datenstruktur in einem konkreten Datenmodell (Klassenmodell), entwerfen die Architektur des Programms und formulieren bzw.„übersetzen" die zu verwendenden Algorithmen in Programmiersprache (Quellcode). Die Softwareentwickler werden in den einzelnen Phasen in der Regel durch Software-Technologien, -Verfahren und -Werkzeuge unterstützt, die die Abwicklung einzelner Schritte des Prozesses erleichtern oder zum Teil automatisieren.
Stand der Technik im Bereich der modellgetriebenen Entwicklung von Softwareanwendungen ist dabei zum Beispiel der sogenannte„Model Driven Software Development" (englisch für „Modellgetriebene Softwareentwicklung", kurz MDSD)-/ „Model Driven Architecture" (englisch für „Modellgetriebene Architektur", kurz MDA)- Ansatz, der häufig werkzeugsseitig durch Integrierte Entwicklungsumgebungen (IDE) oder Frameworks unterstützt wird. Beim Model Driven Software Development wird die Architektur der zu erstellenden Anwendung sowie Teile des Quellcodes (Klassenmodell), aus einem Modell (Diagramm in der grafischen Modellierungssprache„Unified Modeling Language", kurz UML-Diagramm) erzeugt. Frameworks stellen hierbei den Rahmen zur Verfügung, innerhalb dessen der Programmierer eine Anwendung erstellt, d.h. sie definieren in der Regel die Anwendungsarchitektur, den Kontrollfluss der Anwendung und die Schnittstellen für die konkreten Klassen, die vom Programmierer erstellt und registriert werden müssen. Die Struktur der individuellen Anwendung wird dabei unter anderem durch die in dem Framework verwendeten Entwurfsmuster beeinflusst. Die über das MDSD-Verfahren mit der IDE oder dem Framework erzeugten Teile des Quellcodes müssen nach ihrer Generierung noch ausprogrammiert sowie um Quellcode für die (grafische) Benutzeroberfläche (GUI), die Datenbank-Anbindung sowie die Schnittstellen ergänzt werden.
Der Quellcode muss nach Generierung, Ausprogrammierung und Ergänzung mit einem Compiler in Maschinensprache übersetzt werden, um das Programm maschinenlesbar und damit lauffähig zu machen. Auch bei Änderungen bestehender Software muss der Quellcode immer wieder neu generiert, zu einem Programm zusammengebunden und in die Laufzeitumgebung übernommen werden.
Schließlich muss die erstellte oder geänderte Software auf einem Rechner installiert, ggf. konfiguriert und in Betrieb genommen werden, um von den Anwendern genutzt werden zu können.
Zusammenfassend muss somit bei herkömmlichen Verfahren zur Entwicklung und Bereitstellung von Client-/ Server-basierten - vorzugsweise webbasierten - Anwendungen - mit Werkzeugen zunächst der Quellcode der Anwendung programmiert werden, der unter anderem die Befehle an den Prozessor enthält, der das spätere Anwendungsprogramm steuert,
- der Quellcode mit Werkzeugen zu maschinenlesbarem Code übersetzt und zu einem Anwendungsprogramm gebunden/ kompiliert werden,
- das Anwendungsprogramm auf einem Rechner installiert werden, und
- mit einer Laufzeitumgebung das Anwendungsprogramm zur Laufzeit gestartet und gesteuert werden. Allen aktuellen Verfahren und Techniken der Softwareentwicklung und -bereitstellung ist damit gemein, dass für die Erstellung oder Änderung von Softwareanwendungen eine Definition und Abbildung der Anwendungslogik einer Softwareanwendung erforderlich ist, bevor der Quellcode in Maschinensprache übersetzt und die dabei entstandene Softwareanwendung installiert und zur Nutzung bereitgestellt werden kann. Dieser Prozess ist häufig zeitaufwendig und auch nicht ohne Programmierkenntnisse und damit in der Regel nicht ohne Softwarespezialisten möglich. Eine größere Flexibilität und Anpassungsfähigkeit kann zwar durch Nutzung von sogenannten Geschäftsregeln („Business Rules") und/oder Expertensystemen erreicht werden. Mit deren Hilfe lässt sich in bestimmten Grenzen das Verhalten einer Softwareanwendung zur Laufzeit steuern und ohne Kompilierung ändern. Diese Möglichkeit ist jedoch auf das reine Anwendungsverhalten beschränkt. Die Steuerung aller anderen Bestandteile und Aspekte einer Anwendung - Datenhaltung, Anwendungslogik, Oberfläche - ist damit nicht möglich. Die hiermit erreichbare Flexibilität bezieht sich au ßerdem lediglich auf Softwareanwendungen, die bereits bestehen und in denen die regelbasierte Technologie implementiert ist. Die flexible Erzeugung gänzlich neuer Anwendungen ist damit nicht möglich.
Bei größeren Server- und Datenbank-basierten Softwaresystemen, z.B. häufig bei Unternehmenslösungen, kommt hinzu, dass neben dem Programmier-Knowhow auch für die Installation und Inbetriebnahme besondere IT-Kenntnisse erforderlich sind, die weitere IT-Spezialisten erfordern.
Seitens der Fachabteilungen und der Administration von Unternehmen jeglicher Größe entsteht jedoch angesichts der Notwendigkeit zu höherer Agilität zunehmend der Bedarf an einer schnellen Verfügbarkeit von Softwarelösungen für anliegende Aufgaben- und Problemstellungen - sei es durch gänzlich neue Anwendungen oder eine Anpassung bestehender Anwendungen an geänderte Anforderungen und Rahmenbedingungen. Dies gilt auch im Hinblick auf einen Bedarf an Lösungen, die nur kurzfristig benötigt werden bzw. nur interimsweise oder projektbezogen eingesetzt werden müssen.
Die Anwender sind in der Regel aber nicht in der Lage, die technischen Fragen zu lösen, die im Zusammenhang mit der Erstellung der Anwendungen, ihrer Bereitstellung und ihrem Betrieb stehen. Die bisherigen Verfahren und Technologien der Softwareerstellung und -bereitstellung sind demgemäß insbesondere für Unternehmen, die im zunehmenden Wettbewerb agil bleiben müssen, nur wenig geeignet.
Hiervon ausgehend liegt der vorliegenden Erfindung die Aufgabe zugrunde, ein Verfahren und eine computerimplementierbare Einrichtung bereitzustellen, mit dem bzw. der eine Client-/ Server-basierte, vorzugsweise webbasierte Softwareanwendung mit einer Benutzeroberfläche für einen Nutzer automatisiert erzeugt werden kann und nutzbar ist, um dem Nutzer einen Zugriff auf Daten einer Datenbank zu ermöglichen, ohne dass die Softwareanwendung hierfür auf einem Rechner des Nutzers installiert werden muss. Dabei soll die Softwareanwendung zudem in besonders einfacher Weise an die Bedürfnisse des Nutzers anpassbar sein und einen möglichst geringen Kompilierungsaufwand erfordern.
Diese Aufgabe wird insbesondere sowohl mit dem Verfahren des Anspruchs 1 als auch mit der Einrichtung des Anspruchs 15 gelöst.
Hiermit wird jeweils eine Möglichkeit vorgeschlagen, mit der automatisch aus einem fachlich orientierten Anwendungsmodell zur Laufzeit - das heißt, gänzlich ohne Programmierung, Kompilierung oder Installation - Client-/ Server-basierte, vorzugsweise webbasierte Softwareanwendungen erzeugt und in einer Laufzeitumgebung (auf einer Anwendungsplattform) zur Nutzung bereitgestellt werden können. Eine erzeugte Softanwendung muss hierbei weder auf dem (Client-)Rechner eines Nutzers noch auf einem Rechner für die Anwendungsplattform, z.B. einem (Web-)Server, kompiliert oder installiert werden. Ein Übergang von der Modellfunktion zur Nutzung einer Softwareanwendung erfolgt vielmehr ohne Programmierung, Kompilierung und Installation, so dass für den Aufbau neuer oder die Änderung bereits erstellter Softwareanwendungen ein Datenbank-Design, eine Programmierung einer Anwendungslogik oder die Konfiguration von Benutzeroberflächen nicht notwendig sind. Ein erfindungsgemäßes Verfahren, mit dem wenigstens eine Client-/ Server-basierte, vorzugsweise webbasierte Softwareanwendung mit einer Benutzeroberfläche für einen Nutzer - vorzugsweise mehrere Softwareanwendungen - automatisiert erzeugt und bereitgestellt wird, umfasst dabei wenigstens die folgenden Schritte: - Bereitstellung einer Anwendungsplattform, in die sich ein Nutzer über ein Netzwerk, beispielsweise das Internet oder ein Intranet, einloggen kann, Bereitstellung mindestens einer mandantenspezifischen Datenbank, in der Daten abgespeichert werden können,
Bereitstellung zumindest ein in der mandantenspezifischen Datenbank gespeichertes Anwendungsmodell für die Erzeugung der wenigstens einen Softwareanwendung, wobei mit dem Anwendungsmodell die Funktionsweise - und damit Gegenstand, Inhalt und Konfiguration - der Softwareanwendung, eine Benutzeroberfläche und die Datenstruktur maschinell verarbeitbar beschrieben sind, und
Bereitstellung einer Modell-Engine auf der Anwendungsplattform für die Verarbeitung mindestens eines Anwendungsmodells und den Zugriff auf Daten der mandantenspezifischen Datenbank, wobei bei dem erfindungsgemäßen Verfahren ferner die Modell-Engine nach dem Einloggen eines Nutzers das Anwendungsmodell zur Laufzeit ausliest und erst zur Laufzeit auf Basis des Anwendungsmodells eine Softwareanwendung mit Anwendungslogik und Benutzeroberfläche erzeugt, wobei die Anwendungslogik die von der Softwareanwendung im Betrieb ausführbaren Prozesse definiert und der Nutzer über die Benutzeroberfläche auf Daten aus der mandantenspezifischen Datenbank zugreifen kann, und
Befehle des Nutzers an der Benutzeroberfläche betreffend ein bestimmtes Datenobjekt zur Laufzeit an die Modell-Engine weitergegeben werden und die Modell-Engine dem Nutzer unter Rückgriff auf das Anwendungsmodell und die hieraus zur Laufzeit erstellte Anwendungslogik einen Zugriff auf zu dem Datenobjekt gehörende Daten aus der mandantenspezifischen Datenbank gestattet, um hierdurch insbesondere die Daten anzuzeigen und/oder zu bearbeiten und/oder neue Daten einzugeben und abzuspeichern.
Das Anwendungsgebiet der vorliegenden Erfindung ist somit die Erstellung von (Client-/ Server-basierten, vorzugsweise webbasierten) Softwareanwendungen und deren Bereitstellung auf einer Anwendungsplattform zur sofortigen Nutzung, z.B. als„Software as a Service". Mit der Anwendungsplattform wird folglich eine Laufzeitumgebung bereitgestellt, in der Softwarekomponenten, wie die Modell-Engine lauffähig sind, um die Softwareanwendung zu erzeugen und hierin bereitzustellen. Die Anwendungsplattform hat mithin die Aufgabe, mit Systemwerkzeugen die in Anwendungsmodellen definierten Softwareanwendungen über die jeweils festgelegte Konfiguration mit den in der Anwendungsplattform enthaltenen funktionalen Anwendungsbausteinen zu kombinieren, ablauffähig zu machen und zur Nutzung bereitzustellen. Sie wird also benötigt, um eine Softwareanwendungeft überhaupt entstehen zu lassen und einem Nutzer bereitzustellen. Mandantenspezifisch bedeutet hierbei, dass auf einem Rechner der Anwendungsplattform, also insbesondere auf demselben Server, Datenbanken mehrerer Mandanten (Kunden) abgespeichert werden können, ohne dass die einzelnen Mandanten untereinander Zugriff auf die Datenbanken haben. Eine mandantenspezifische Datenbank mit einem auszulesenden Anwendungsmodell kann somit eine von mehreren mandantenspezifischen Datenbanken sein, die in einer zentralen Datenbank der Anwendungsplattform hinterlegt sind. Dementsprechend können auch mehrere mandantenspezifische Datenbanken und/oder mehrere vorkonfigurierte Anwendungsmodelle in einer Datenbank der Anwendungsplattform hinterlegt sein.
Unter einer Modell-Engine wird eine Softwarekomponente verstanden, die eine Verknüpfung von Metadatenelementen des Anwendungsmodells mit den Daten aus der mandantenspezifischen Datenbank ermöglicht. Eine Modell-Engine kann somit von einem Datenbankmanagementsystem benutzt werden, um Daten einer Datenbank zu speichern, auszulesen, zu aktualisieren und zu löschen. Hierbei hat die Modell-Engine eine Übersetzungs- und Koordinierungsfunktion inne, um aus Datenelementen des Anwendungsmodells konkrete Datenobjekte der Softwareanwendung zu generieren sowie Befehle an der Benutzeroberfläche zu interpretieren und über in dem Anwendungsmodell hinterlegte Bedingungen zu verarbeiten, so dass der Befehl zu einem Zugriff auf Daten der mandantenspezifischen Datenbank führt und auf der Benutzeroberfläche angezeigt wird. So ist die Modell-Engine insbesondere dazu in der Lage, ein Anwendungsmodell, das nach dem Einloggen eines Nutzers z. B. über eine Steuerungseinheit der Anwendungsplattform in einen Arbeitsspeicher eines Rechners, durch den die Anwendungsplattform bereitgestellt wird, geladen wurde, auszulesen und anschließend aus den in dem Anwendungsmodell hinterlegten Modell-Informationen eine Benutzeroberfläche zu generieren und anzuzeigen. Die Modell-Engine kann dementsprechend auch als Anwendungserzeugungsvorrichtung gesehen werden. Ein Anwendungsmodell beschreibt somit die Softwareanwendung vollständig. Sie definiert unter anderem, die Darstellung der anfänglichen (Grund- oder Start-) Benutzeroberfläche der Softwareanwendung nach dem Einloggen des Nutzers sowie darüber hinaus wie ein Befehl, der über die bereitgestellte Benutzeroberfläche eingegeben und an die Modell-Engine weitergegeben wird, zu einem Zugriff auf die Daten in der mandantenspezifischen Datenbank führt, um hierdurch insbesondere die Daten anzuzeigen und/oder zu bearbeiten und/oder neue Daten einzugeben und abzuspeichern. Das Anwendungsmodell kann folglich Gegenstand, Inhalt, Konfiguration und Funktionsweise der Softwareanwendung vorgeben und dazu dienen, Softwareanwendungen zur Laufzeit aus bereitgestellten Anwendungsbausteinen zusammenzusetzen, zu konfigurieren und ihr Verhalten zu steuern. Vorzugsweise ist das Anwendungsmodell in einem XML-Dokument beschrieben, welches von der Modell- Engine ausgelesen werden kann, um zur Laufzeit die Softwareanwendung zu erzeugen.
Die erfindungsgemäße Lösung gestattet somit, die beschränkten Ressourcen einer Datenverarbeitungsanlage (DV-Anlage) effizienter zu nutzen und zusätzliche, oftmals sehr teure Ressourcen zu sparen. Wenn viele unterschiedliche (fachspezifische) Softwareanwendungen benötigt werden, müssen unter Umständen viele unterschiedliche Softwaresysteme eingesetzt werden. Da jedes Softwaresystem eigene Systemressourcen und gegebenenfalls eine eigene technische Konfiguration erfordert, ist der gleichzeitige Betrieb mehrerer unterschiedlicher Systeme auf einer DV-Anlage nicht effizient und gegebenenfalls sogar kritisch, sofern die technischen Konfigurationen konfliktär sind. Probleme treten hier z.B. häufig bei einer Änderung der Gesamt- Konfiguration der DV-Anlage durch Austausch oder Release-Wechsel von Komponenten auf. Unter Nutzung der erfindungsgemäßen Lösung können alle Softwareanwendungen lediglich mittels Anwendungsmodellen abgebildet werden und es müssen keine unterschiedlichen Softwaresysteme eingesetzt werden. Alle Anwendungen (auch Individual-Anwendungen) werden auf nur einer Anwendungsplattform betrieben. Dabei können beliebig viele unterschiedliche Anwendungen gleichzeitig bereitgestellt werden, ohne dass eigenständige Software installiert werden muss. Dies ist möglich, da zum einen nur Datenbank und Anwendungsmodell von Mandant zu Mandant bzw. von Softwareanwendung zu Softwareanwendung unterschiedlich sind und zum anderen vom System beliebig viele unterschiedliche Anwendungsmodelle parallel verarbeitet sowie beliebig viele Datenbanken parallel angesprochen werden können. Ein solches System schont somit Systemressourcen, weil z.B. Redundanzen bei der System Verwaltung vermieden und Ressourcen gemeinsam genutzt bzw. effizient verteilt werden. Au ßerdem werden Konflikte aufgrund unterschiedlicher technischer Konfigurationen, die bei gleichzeitigem Betrieb unterschiedlicher Softwaresysteme notwendig sein können, verhindert. Derart wird bei einer Ausführungsvariante eines erfindungsgemäßen Verfahrens für den Zugriff eines Nutzers auf einen in der mandantenspezifischen Datenbank gespeicherten Satzes von Daten (Datensatz) eines Datenobjekts durch die Modell-Engine
- zunächst das Anwendungsmodell ausgelesen,
- dann eine Objektinstanz zu dem Datenobjekt in einem Arbeitsspeicher (des Rechners, der die Anwendungsplattform bereitstellt) generiert und
- der zu dem Datenobjekt gehörende Satz von Daten aus der mandantenspezifischen Datenbank ausgelesen, bevor
- eine Visualisierung der Objektinstanzen in Abhängigkeit von den ausgelesenen Daten an der Benutzeroberfläche erzeugt wird.
Um die Flexibilität zur Bereitstellung unterschiedlicher Softwareanwendungen zu vergrößern, umfasst das Anwendungsmodell bevorzugt wenigstens ein Metamodell und ein Anwendungskonfigurationsmodell. In dem Metamodell sind generische Metadatenelemente definiert sowie zu den Metadatenelementen gehörige Datenfeldstrukturen für die Benutzeroberfläche und/oder Attribute festgelegt. Über das Anwendungskonfigurationsmodell wiederum ist ein solches Metamodell spezifiziert und sind Datenobjekte für die Softwareanwendung definiert, die sich von Metadatenelementen des Metamodells ableiten, indem in dem Anwendungskonfigurationsmodell einzelnen oder allen Metadatenelementen konkrete Rollen für die zur Laufzeit zu erzeugende und bereitzustellende Softwareanwendung zugewiesen werden. Die Metadatenelemente sind vorzugsweise selbstreferentiell, d.h. sie können aus weiteren Metadatenelementen bestehen.
Bei der kompilierungsfreien Erzeugung der Softwareanwendung aus einem Anwendungsmodell mit Metamodell und Anwendungskonfigurationsmodell wird bevorzugt zur Laufzeit das Metamodell eingelesen und es werden - ebenfalls zur Laufzeit - zu jedem Metadatenelement einer vorgegebenen Hierarchieebene eine Klasseninstanz eines bestimmten Typs und zu jedem für ein Metadatenelement definierten Attribut ein Klassenattribut erzeugt.
Das Metamodell kann beispielsweise eine Schema-Definition umfassen, die Metadatenelemente beschreibt. In einer bevorzugten Variante der Erfindung ist in dem Metamodell insbesondere definiert, mit welchen Ansichtentypen (Views) ein Metaelement-Attribut, und damit insbesondere mit welchem Ansichtentypen (Views) ein Datenfeldtyp dargestellt werden kann. Hier können Ansichtentypen (Views) und standardisierte Benutzeroberflächenelemente als Bausteine in der Anwendungsplattform implementiert sein. So kann auch die Art der Visualisierung von durch die Modell-Engine erzeugten Objektinstanzen durch einen in dem Anwendungsmodell definierten Ansichtentyp (View) für das Datenobjekt vorgegeben sein. Ferner kann jede Veränderung des Metamodells auch zu einer Veränderung der Struktur der bereitgestellten Daten aus der mandantenspezifischen Datenbank und gegebenenfalls zu einer Veränderung der Softwareanwendung zur Laufzeit führen. Hierbei wird beispielsweise eine (XML-) Datei, welche das Metamodell enthält, modifiziert, wodurch dann bei einer damit verbundenen Veränderung der Vorgaben innerhalb des Metamodells die Datenhaltung verändert wird. Eine solche dynamische Anpassung der Softwareanwendung kann insbesondere während der Laufzeit erfolgen, so dass das von der Modell-Engine ausgelesene Anwendungsmodell nach der Erzeugung der Softwareanwendung und während der Nutzung derselben veränderbar ist. In dem Metamodell sind beispielsweise Metaelement-Attribute für die Metadatenelemente beschrieben und diesen standardisierte Benutzeroberflächenelemente und - in der mandantenspezifischen Datenbank - Datenfeldtypen zugeordnet, so dass das Metamodell für die Datenobjekte der Softwareanwendung die Darstellung einer Datenfeldstruktur auf der Benutzeroberfläche definiert.
In dem Anwendungskonfigurationsmodell kann wiederum maschinell, d.h. von der Anwendungsplattform, lesbar beschrieben sein, wie die nach dem Einloggen des Nutzers darzustellende Benutzeroberfläche der Softwareanwendung aus den standardisierten Benutzeroberflächenelementen aufgebaut werden soll.
In einem Anwendungskonfigurationsmodell ist zum Beispiel wenigstens festgelegt,
- zu welcher Rolle (zu welchem Typ) ein Metadatenelement in der Softwareanwendung ausgeprägt wird, so dass die Funktionalität eines Metadatenelements einem bestimmten Datenobjekt der Softwareanwendung zukommt, und
- wie Objektinstanzen eines Datenobjekts auf der Benutzeroberfläche dargestellt werden. Gegebenenfalls hierin auch festgelegt sein, über welche Zugriffsrechte eine Rolle verfügt.
Ein Anwendungskonfigurationsmodell definiert beispielsweise eine oder mehrere Softwareanwendungen (z.B. für die Dokumentation und Verwaltung von Kundenbeziehungen („Customer-Relationship-Management", kurz CRM), für eine Produktverwaltung, für ein Veranstaltungsmanagement, für die Verwaltung einer Musikdatenbank etc.). Jedem Mandant ist ein Anwendungskonfigurationsmodell zugeordnet, das die mögliche(n), bereitstellbare(n) Softwareanwendung(en) definiert und in der mandantenspezifischen Datenbank abgelegt ist. Für jeden Nutzer ist zudem ein Benutzerkonto angelegt, über das der Nutzer einem oder mehreren Mandanten zugewiesen ist. Derart erhält der Nutzer nach dem Einloggen automatisch über eine entsprechende auf der Anwendungsplattform vorgesehene Mandanten- und Rechteverwaltung das für ihn vorgesehene Anwendungskonfigurationsmodell. Durch das - vorzugsweise aus wenigstens einem Metamodell und wenigstens einem Anwendungskonfigurationsmodell aufgebaute - Anwendungsmodell können ferner bestimmte Funktionen der Softwareanwendung maschinell lesbar beschrieben sein, die zur Laufzeit ausführbar sind. Unter eine derartige Funktion fiele z.B. das Speichern des Datums des letzten Zugriffs auf die mandantenspezifische Datenbank in der Datenbank, wenn die Softwareanwendung beendet wird, oder die Ausführung mathematischer Operationen mit bestimmten oder allen Datensätzen einer Datenbank, wie z.B. die Berechung und Speicherung der Summe aller in der Datenbank gespeicherten Instanzen eines bestimmten Datenobjektes (zum Beispiel die Gesamtanzahl aller Alben einer Musikdatenbank). Hierfür sind beispielsweise in dem Anwendungsmodell bestimmte Regeln und/oder Workflows vordefiniert.
In diesem Zusammenhang wird es als vorteilhaft erachtet, generische Funktionsbausteine in der Anwendungsplattform zu implementieren, die zur Laufzeit durch das Anwendungsmodell spezifiziert und konfiguriert werden, um die ausführbaren Funktionen bereitzustellen. Derart wird insbesondere die Erstellung neuer Anwendungsmodelle für auf der Anwendungsplattform angebotene Softwareanwendungen erleichtert, indem z.B. bei vergleichbaren Funktionen stets die generischen Funktionsbausteine genutzt werden können und gegebenenfalls nur geringfügig angepasst werden müssen.
In einem Ausführungsbeispiel umfasst das Anwendungsmodell - bevorzugt in Ergänzung zu einem Metamodell und einem Anwendungskonfigurationsmodell - ein Organisationsmodell, in dem wenigstens eine Organisationsstruktur der Organisation, innerhalb derer die zur Laufzeit zu erzeugende Softwareanwendung genutzt werden soll, und/oder ein Geschäftsprozess, der mit der zur Laufzeit zu erzeugenden Softwareanwendung abgebildet werden soll, hinterlegt sind. Ein Organisationsmodell umfasst somit beispielsweise ein (statisches) Strukturmodell und gibt hierüber Berechtigungen für durch die erzeugte Softwareanwendung bereitgestellten Prozesse und/oder Berichtsstrukturen vor. Alternativ oder ergänzend kann ein Organisationsmodell ein (dynamisches, d.h., für die jeweilige Softwareanwendung innerhalb derselben und gleichbleibenden Organisation angepasstes) Geschäftsprozessmodell und gibt hierüber die Geschäftsprozesse vor, die von der erzeugten Softwareanwendung technisch unterstützt werden sollen.
In einem Ausführungsbeispiel umfasst die Modell-Engine für die einzelnen (Teil-) Modelle eines Anwendungsmodells, z.B. das Metamodell, das Anwendungskonfigurationsmodell und das Organisationsmodell, unterschiedliche Verarbeitungsmodule. So kann vorgesehen sein, dass die Modell-Engine
- ein erstes Verarbeitungsmodul für die Verarbeitung des Metamodells,
- ein zweites Verarbeitungsmodul für die Verarbeitung des Anwendungskonfigurationsmodells und
- eine übergeordnete Generierungseinheit
umfasst, wobei die übergeordnete Generierungseinheit nach dem Laden des Metamodells mittels des ersten Verarbeitungsmoduls und nach dem Laden des Anwendungskonfigurationsmodells mittels des zweiten Verarbeitungsmoduls in einen Arbeitsspeicher zur Generierung der Softwareanwendung notwendige Informationen von den ersten und zweiten Verarbeitungsmodulen abfragt und zur Laufzeit die Softwareanwendung generiert.
In einem Ausführungsbeispiel weist die Modell-Engine ein (drittes) Verarbeitungsmodul für das Auslesen eines Organisationsmodells auf, welches in dem Anwendungsmodell enthalten ist und über welches zur Laufzeit automatisiert eine Prüfung der in der Softwareanwendung zu vergebenden Zugriffsrechte ermöglicht ist. Das Organisationsmodell definiert hierfür z.B. Benutzer(gruppen) und Strukturinformationen.
So liest z.B. ein erstes Modul, das Metamodell-Verarbeitungsmodul (auch als „Meta Model Manager" bezeichnet), das Metamodell in einen Arbeitsspeicher ein und erzeugt zur Laufzeit die konkreten Objekte (Instanzen), d.h., die konkreten Datensätze. Ein zweites Modul, das Anwendungskonfigurationsmodell-Verarbeitungsmodul („Application Configuration Model Manager") wiederum liest das Anwendungskonfigurationsmodell in den Arbeitsspeicher, d.h. beispielsweise, die XML-Datei, die den Anwendungskontext der Softwareanwendung beschreibt. Ein drittes Modul, das Organistationsmodell- Verarbeitungsmodul („Organisation Model Manager"), liest ein fachliches Organisationsmodell aus, prüft anhand der dort definierten Rollen und Strukturinformationen die Zugriffsrechte auf Applikationen, Prozesse/Workflows, Datenobjekte, usw. der Softwareanwendung. Über die übergeordnete Generierungseinheit der Modell-Engine werden die zur Generierung der Softwareanwendung benötigten Informationen von den drei Modulen abgefragt, d.h., welche Datenobjekte konkret zugeordnet sind, wie sie zu Laufzeit ausprägen (Vererbung), wie die Darstellung an der Benutzeroberfläche erfolgen soll und welche Funktionen aus der Anwendungsplattform genutzt werden, usw.) und generiert zur Laufzeit die Softwareanwendung.
Wie bereits erwähnt, können für unterschiedliche Softwareanwendungen unterschiedliche Anwendungsmodelle in einer Datenbank der Anwendungsplattform hinterlegt sein, so dass zur Bereitstellung einer von mehreren unterschiedlichen Softwareanwendungen lediglich ein bestimmtes Anwendungsmodell durch die Modell-Engine zur Laufzeit ausgelesen wird und eine Benutzeroberfläche auf Basis dieses Anwendungsmodells generiert wird, insbesondere eine erste Grund- oder Start-Benutzeroberfläche, die direkt nach dem Einloggen eines Nutzers angezeigt wird.
In einer Variante ist mindestens eine mandantenspezifische Datenbank und/oder mindestens ein vorkonfiguriertes Anwendungsmodell in einer lokalen Datenbank eines Nutzers hinterlegt, während die Anwendungsplattform durch ein Serversystem bereitgestellt ist. Die Anwendungsplattform kann somit insbesondere in der „Cloud" zentral betrieben werden, während die Datenhaltung für eine zur Laufzeit erzeugte Softwarenanwendung eines Nutzers bei diesem lokal gespeichert ist.
Um die Bereitstellung von Anwendungsmodellen für die einzelnen Nutzer und/oder Mandanten zu erleichtern, können auf der Anwendungsplattform Standard- Anwendungsmodelle und/oder Standard-Metamodelle hinterlegt sein. Ein Standard- Anwendungsmodell oder ein Standard-Metamodell sind dann durch eine auf der Anwendungsplattform lauffähige Anwendungsmodellerstellungsvorrichtung modifizierbar, um hierüber eine Anpassung für eine individuelle Softwareanwendung vornehmen zu können. Ein modifiziertes Standard-Anwendungsmodell oder Metamodell ist dann über die Anwendungsmodellerstellungsvorrichtung als weiteres Anwendungsmodell oder weiteres Metamodell speicherbar. Alternativ oder ergänzend kann vorgesehen sein, dass ein Anwendungsmodell lediglich aus einem Verweis auf ein Standard-Anwendungsmodell und gegebenenfalls einem besonderen Konfigurationsmodell gebildet wird, wobei in dem Konfigurationsmodell nur etwaige Abweichungen von dem jeweiligen Standard-Anwendungsmodell spezifiziert sind.
Ein Standard-Anwendungsmodell wird hierbei vorzugsweise in einem Anwendungsmodellspeicher vorgehalten. Ein solcher Anwendungsmodellspeicher ist vorzugsweise in einer zentralen Datenbank hinterlegt, in der auch die mandantenspezifischen Datenbanken abgelegt sind.
Ein weiterer Aspekt der vorliegenden Erfindung ist eine computerimplementierte Einrichtung zur automatisierten Erzeugung und Bereitstellung wenigstens einer Client-/ Server-basierten, vorzugsweise webbasierten Softwareanwendung mit einer Benutzeroberfläche für einen Nutzer nach dem Anspruch 17. Eine solche Einrichtung, die auf einem Rechner, insbesondere einem (Web-)Server installiert ist, kann insbesondere zur Durchführung eines erfindungsgemäßen Verfahrens ausgebildet und vorgesehen sein.
Eine erfindungsgemäße Einrichtung umfasst dabei wenigstens das Folgende: eine Anwendungsplattform, in die sich ein Nutzer, vorzugsweise über ein Netzwerk, einloggen kann, mindestens eine mandantenspezifische Datenbank auf der Anwendungsplattform, in der Daten abgespeichert werden können, zumindest ein in der mandantenspezifischen Datenbank gespeichertes Anwendungsmodell für die Erzeugung der wenigstens einen Softwareanwendung, wobei mit dem Anwendungsmodell die Funktionsweise der Softwareanwendung, eine Benutzeroberfläche und die Datenstruktur maschinell verarbeitbar beschrieben sind, und eine Modell-Engine auf der Anwendungsplattform für die Verarbeitung mindestens eines Anwendungsmodells und den Zugriff auf Daten der mandantenspezifischen Datenbank. Zur Laufzeit - nach dem Einloggen eines Nutzers - ist das Anwendungsmodell mittels der Modell-Engine auslesbar und auf Basis des Anwendungsmodells, ebenfalls mittels der Modell-Engine, ist eine Softwareanwendung erzeugbar, die eine Benutzeroberfläche beinhaltet, über die der Nutzer auf Daten aus der mandantenspezifischen Datenbank zugreifen kann. Die Modell-Engine ist hierfür derart ausgeführt, dass Befehle des Nutzers an der von ihr generierten Benutzeroberfläche der Softwareanwendung, die ein bestimmtes Datenobjekt betreffen, zur Laufzeit an die Modell-Engine weitergegeben werden und die Modell-Engine dem Nutzer unter Rückgriff auf das Anwendungsmodell einen Zugriff auf zu dem Datenobjekt gehörende Daten gestattet.
Die Anwendungsplattform kann eine Steuereinrichtung aufweisen, die nach dem Einloggen eines Nutzers das Anwendungsmodell aus der mandantenspezifischen Datenbank lädt und in den Arbeitsspeicher eines Rechners lädt, auf dem die Einrichtung installiert ist.
Indem eine erfindungsgemäße Einrichtung zur Durchführung eines erfindungsgemäßen Verfahrens ausgebildet und vorgesehen ist, sind die obig für ein erfindungsgemäßes Verfahren erläuterten Vorteile und Merkmale ebenfalls für eine erfindungsgemäße Einrichtung gültig und umgekehrt.
So kann eine erfindungsgemäße Einrichtung beispielsweise eine Anwendungsmodellerstellungsvorrichtung und/oder einen Anwendungsmodellspeicher umfassen.
Wie obig bereits kurz dargestellt wird eine einfach handhabbarere und variable Möglichkeit bereitgestellt, gleichzeitig bzw. parallel beliebig viele Modelle zur Laufzeit zu nutzen und damit beliebig viele Softwareanwendungen basierend auf beliebig vielen unterschiedlichen Anwendungsmodellen auf derselben Plattform zu betreiben. Die Modelle können dabei auch zur Laufzeit noch optimiert werden.
Im Vorfeld wird beispielsweise aus einem anwendungsunabhängigen Metamodell und einem anwendungsbezogenen Konfigurationsmodell das Anwendungsmodell der Softwareanwendung erzeugt. Anschließend wird aus einer leeren Datenbank und dem Anwendungsmodell eine mandantenspezifische Datenbank erzeugt. Zur Laufzeit liest schließlich eine in der Anwendungsplattform integrierte
Anwendungserzeugungsvorrichtung, die Modell-Engine, das in der mandantenspezifischen Datenbank liegende Anwendungsmodell aus und erzeugt aus der darin enthaltenen Anwendungslogik und Oberflächenbeschreibung sowie den in der Anwendungsplattform enthaltenen generischen Views (GUI) und Funktionen automatisch die sofort nutzbare Softwareanwendung.
Darüber hinaus wird ein Computerprogrammprodukt zum Betreiben eines Rechners, insbesondere eines Webservers, vorgeschlagen, das maschinenlesbaren Code aufweist, der, wenn er auf dem Rechner ausgeführt wird, ausgebildet ist, den Rechner zu veranlassen, ein erfindungsgemäßes Verfahren durchzuführen.
Ein weiterer Aspekt der vorliegenden Erfindung ist ein maschinenlesbares Speichermedium, das maschinenlesbaren Programmcode aufweist, der ausgestaltet ist, auf einem Rechner, insbesondere einem Webserver ausgeführt zu werden und den Rechner bei der Ausführung des Programmcodes zu veranlassen, ein erfindungsgemäßes Verfahren durchzuführen.
Des Weiteren wird eine computerimplementierte Einrichtung zur Erstellung eines Computerprogrammprodukts vorgeschlagen, mittels dem ein erfindungsgemäßes Verfahren ausführbar ist, bei dem ein Anwendungsmodell wenigstens ein Metamodell und ein Anwendungskonfigurationsmodell umfasst. Eine solche Einrichtung umfasst erfindungsgemäß wenigstens:
- ein erstes Erstellungsmodul für die Erstellung eines Metamodells, wobei in dem Metamodell generische Metadatenelemente definiert und zu den Metadatenelementen gehörige Datenfeldstrukturen für die Benutzeroberfläche, Attribute und/oder Funktionen festgelegt sind, und
- ein zweites Erstellungsmodul für die Erstellung eines Anwendungskonfigurationsmodells, wobei über das Anwendungskonfigurationsmodell das Metamodell spezifiziert ist und Datenobjekte für die Softwareanwendung definiert sind, die sich von Metadatenelementen des Metamodells ableiten, indem in dem Anwendungskonfigurationsmodell Metadatenelementen konkrete Rollen für die zur Laufzeit zu erzeugende und bereitzustellende Softwareanwendung zugewiesen werden.
Zur Erleichterung der Erstellung eines Anwendungsmodells mit Metamodell und Anwendungskonfigurationsmodell definiert wenigstens ein Erstellungsmodul mindestens eine grafische Benutzeroberfläche, über die eine Bedienperson ein Metamodell und/oder ein Anwendungskonfigurationsmodell erstellen kann. Derart ist die Erstellung und damit insbesondere die Konfiguration einer erst zur Laufzeit erzeugten Softwareanwendung auch ohne detaillierte Programmierkenntnisse auf Basis an der Benutzeroberfläche generierbarer Bestandteile des später zur Laufzeit von der Modell-Engine auszulesenden Anwendungsmodells möglich.
In einem Ausführungsbeispiel umfassen das Metamodell und/oder das Anwendungskonfigurationsmodell mindestens ein XML-Dokument und das erste und/oder zweite Erstellungsmodul sind zur Erzeugung und/oder Veränderung eines XML- Dokuments vorgesehen, um das jeweilige Modell zu erstellen. Dabei kann insbesondere vorgesehen sein, dass die Modell-Engine mit Anwendungsmodellen arbeitet, die ausschließlich in XML-Dokumenten beschrieben sind. Technisch werden hier somit bei der Erzeugung eines Anwendungsmodells lediglich XML-Dateien erzeugt und/oder verändert. In einer Variante umfasst die Einrichtung neben dem ersten Erstellungsmodul (Metamodell-Erstellungsmodul) und dem zweiten Erstellungsmodul (Anwendungskonfigurationsmodell-Erstellungsmodul) ein drittes Erstellungsmodul für die Erstellung eines oben bereits erwähnten Organisationsmodells (Organistationsmodell- Erstellungsmodul). Die einzelnen Module der Einrichtung dienen somit hier der Erstellung der entsprechenden Teilmodelle des Anwendungsmodells.
Weitere Vorteile und Merkmale der vorliegenden Erfindung werden bei der nachfolgenden Beschreibung von Ausführungsbeispielen anhand der Figuren deutlich werden.
Hierbei zeigen:
Fig. 1 ein Ablaufdiagramm für eine Ausführungsvariante
erfindungsgemäßen Verfahrens;
Fig. 2 eine schematische Darstellung einer Ausführungsvariante
erfindungsgemäßen Einrichtung;
Fig. 3 eine schematische Darstellung der Erzeugung einer grafischen
Benutzeroberfläche zur Laufzeit durch eine Modell-Engine auf Basis eines Anwendungsmodells; auszugsweise der Inhalt eines Anwendungsmodells für ein Ausführungsbeispiel einer Softwareanwendung;
Fig. 4B eine schematische Darstellung der Erzeugung einer
Datenhaltung aus einem Metamodell für das Ausführungsbeispiel der Fig. 4A;
Fig. 4C eine schematische Darstellung der Erzeugung eines
Klassenmodell mit Klassen und Klassenattributen zur Laufzeit durch eine Modell-Engine aus einem Metamodell für das
Ausführungsbeispiel der Fig. 4A;
Fig. 5A eine schematische Darstellung einer Instanziierung zur Laufzeit gemäß einem üblichen objektorientierten Ansatz zur Entwicklung einer Softwareanwendung für das Ausführungsbeispiel der Fig.
4A;
Fig. 5B eine schematische Darstellung einer Instanziierung zur Laufzeit gemäß dem erfindungsgemäßen Verfahren für das Ausführungsbeispiel der Fig. 4A;
Fig. 6A eine schematische Darstellung der Funktionen einer
Benutzeroberfläche einer Einrichtung zur Erstellung insbesondere eines Anwendungsmodells für eine Softwareanwendung;
Fig. 6B eine schematische Darstellung der Funktionen der
Anwendungsplattform, auf der auf Basis der erfindungsgemäßen Lösung eine Softwareanwendung lauffähig ist.
In der Figur 1 ist zunächst ein Ablaufdiagramm für eine Ausführungsvariante eines erfindungsgemäßen Verfahrens zur automatisierten Erzeugung und Bereitstellung einer Client-/ Server-basierten, vorzugsweise webbasierten Softwareanwendung AW mit einer Benutzeroberfläche GUI für einen Nutzer gezeigt. Dabei schließt das dargestellte Ablaufdiagramm auch Phasen für die Erstellung eines Anwendungsmodells AM und die Vergabe von Nutzerrechten durch eine Mandantenverwaltungsvorrichtung CA (engl, „dient administrator") ein, die im Vorfeld (Abschnitt I in der Figur 1 ) durch einen Anbieter der Softwareanwendung AW zu leisten sind, bevor diese bei Bedarf zur Laufzeit (Abschnitt II) automatisiert erzeugt und zur Nutzung bereitgestellt, d.h., nutzbar ist.
Kern der dargestellten Ausführungsvariante ist die Erzeugung und Bereitstellung der Softwareanwendung zur Laufzeit ohne Programmierung.
Dabei wird vorliegend über eine Anwendungsmodellerstellungsvorrichtung AMD (engl, „application model designer") aus einem anwendungsunabhängigen Metamodell MM und einem anwendungsbezogenen Konfigurationsmodell bzw. Anwendungskonfigurationsmodell AKM ein (hier: datenorientiertes) Anwendungsmodell AM der Anwendung erzeugt. Anschließend erzeugt Mandantenverwaltungsvorrichtung CA aus einer leeren Datenbank (nicht dargestellt) und dem Anwendungsmodell AM eine mandantenspezifische Datenbank CSD (engl, „dient specific database"). Zur Laufzeit liest eine Modell-Engine ME das in der mandantenspezifischen Datenbank CSD liegende Anwendungsmodell AM aus. Diese Modell-Engine erzeugt die Softwareanwendung AW aus einer in dem Anwendungsmodell AM beschriebenen Anwendungslogik AL und einer darin ebenfalls enthaltenen Oberflächenbeschreibung OB sowie aus generischen Funktionen und generischen Ansichtentypen (Views) für die grafische Benutzeroberfläche GUI. Die generischen Funktionen und Ansichtentypen sind dabei in einer Anwendungsplattform implementiert, auf der als Laufzeitumgebung insbesondere die Anwendungsmodellerstellungsvorrichtung AMD, die Mandantenverwaltungsvorrichtung CA und die Modell-Engine ME lauffähig sind.
Eine Ausführungsvariante einer erfindungsgemäßen computerimplementierten Einrichtung S1 , mit der die mit der Figur 1 beschriebene Variante eines erfindungsgemäßen Verfahrens ausgeführt wird, ist in der Figur 2 veranschaulicht. Mit der Einrichtung S1 ist dabei nicht nur eine automatische Erzeugung und Bereitstellung von Softwareanwendungen zur Laufzeit auf einer vorzugsweise webbasierten Anwendungsplattform möglich, sondern auch eine Erstellung der Softwareanwendungen vor einer ersten Nutzung mithilfe der Anwendungsmodellerstellungsvorrichtung AMD und der Mandantenverwaltungsvorrichtung CA .
Die Einrichtung S1 beinhaltet eine Anwendungsplattform mit einer (generischen) Benutzeroberfläche GUI, der Modell-Engine ME und einer zentralen Datenbank DB, in der mehrere mandantenspezifische Datenbanken CSDi..x abgelegt sind. Von diesen mandantenspezifischen Datenbanken ist exemplarisch der Aufbau zweier Datenbanken CSDi und CSDx in größerem Detail gezeigt, in denen unter anderem Datensätze DS abgespeichert sind. Darüber hinaus umfasst die Einrichtung S1 die Mandantenverwaltungsvorrichtung CA und die Anwendungsmodellerstellungsvorrichtung AMD, welche als Tools auf der Anwendungsplattform laufen. Mit der Anwendungsmodellerstellungsvorrichtung AMD können, basierend auf einem abstrakten plattformunabhängigen Meta-Metamodell (ohne Abbildung), konkrete plattformabhängige Metamodelle und Anwendungskonfigurationsmodelle erstellt und verwaltet werden. Exemplarisch zeigt die Figur 2 hierfür ein individuelles Metamodell MMi der mandantenspezifischen Datenbank CSDi und ein Standard-Metamodell MMSTANDARD.1 , das in einem Anwendungsmodellspeicher AMR (engl,„application model repository") der Einrichtung S1 als Teil eines Standard-Anwendungsmodells AMSTANDARD.I vorgehalten wird.
Ein Metamodell MMi oder MMSTANDARD.I ist eine Schema-Definition, die Bausteine in Form von Metadatenelementen beschreibt. Aus einem Metamodell MMi oder MMSTANDARD.I wird ein (mandantenspezifisches) Datenbankmodell (ohne Abbildung) abgeleitet.
Mit einem Metamodell MMi oder MMSTANDARD.I wird au ßerdem bereits ein Teil der Oberfläche der (Software-)Anwendung AW modelliert. Das Metamodell MMi oder MMSTANDARD.I definiert dabei die Darstellung der Datenfeldstruktur der Datenobjekt-Typen auf der Benutzeroberfläche GUI, indem im Metamodell MMi oder MMSTANDARD.I Metaelement-Attribute beschrieben sind und diesen Datenfeldtypen und standardisierte Benutzeroberflächenelemente der generischen Benutzeroberfläche GUI (z.B. Eingabefelder mitsamt Kardinalitäten) automatisch zugeordnet werden.
Das Anwendungskonfigurationsmodell AKMi oder AKMSTANDARD I definiert den restlichen Teil der Oberfläche. Es legt dabei zu jedem Datenobjekt der Anwendung AW fest, mit welchen Ansichtentypen (Views) es in welchen Kontexten dargestellt werden soll (z.B. Einzelansicht, Listenansicht). Die Ansichtentypen und standardisierten Benutzeroberflächenelemente sind jeweils als Bausteine in der Anwendungsplattform implementiert. Hierbei kann vorliegend die Darstellung an der Benutzeroberfläche GUI mittels der Anwendungsmodellerstellungsvorrichtung AMD nachträglich noch modifiziert werden. Ein Anwendungskonfigurationsmodell AKMi oder AKMSTANDARD I beschreibt die aufbau- und ablauforganisatorischen Grundlagen und Rahmenbedingungen einer Softwareanwendung AW der jeweiligen mandantenspezifischen Datenbank CSDi oder CSDx (d.h. Organisationseinheiten, Prozesse, Rollen, Benutzer, Rechte), die zu unterstützenden Geschäftsprozesse und entsprechende Workflows, eine konkrete Datenhaltung DH (vergleiche Figur 4B), die fallbezogene Konfiguration der aus Basiselementen (Views) bestehenden generischen Benutzeroberfläche GUI, das Zusammenwirken aller Modellkomponenten sowie das Verhalten der Softwareanwendung AW (unter anderem über Regeln). Das Anwendungskonfigurationsmodell, in der Figur 2 exemplarisch AKMi oder AKMSTANDARD.-I , gibt demnach Gegenstand, Inhalt, Konfiguration und Funktionsweise einer Anwendung AW vor und dient dazu, die Anwendung AW zur Laufzeit aus den Anwendungsbausteinen zusammenzusetzen, zu konfigurieren und ihr Verhalten zu steuern.
Ein Anwendungskonfigurationsmodell AKMi oder AKMSTANDARD,idient au ßerdem dazu, das jeweilige Metamodell MMi oder MMSTANDARD ZU spezifizieren, d.h., aus den mit dem Metamodell MMi oder MMSTANDARDJ definierten abstrakten Objekten konkrete Objekte zu bilden, indem die abstrakten Objekte zur Laufzeit mit konkreten Daten gefüllt und damit konkretisiert, typisiert und konfiguriert werden. Dabei können auch über das jeweilige Metamodell MMi oder MMSTANDARDJ vordefinierte Attribute noch modifiziert werden. Jeweils ein Metamodell MMi oder MMSTANDARDJ und ein Anwendungskonfigurationsmodell AKMi oder AKMSTANDARD bilden zusammen ein Anwendungsmodell AMi oder ein Standard-Anwendungsmodell AMSTANDARD.L Durch das jeweilige Anwendungsmodell AMi oder AMSTANDARD.1 wird eine Softwareanwendung vollständig beschrieben. Im Gegensatz zur herkömmlichen Softwareentwicklung wird dabei eine (Software-) Anwendung AW nicht durch ein konkretes fachliches Klassenmodell definiert, das programmiert werden muss, sondern durch ein zur Laufzeit übergebenes Anwendungsmodell AMi oder
AMsTANDARD -
Ein Anwendungsmodell kann hierbei als ein Standard-Anwendungsmodell AMSTANDARD oder als individuelles Anwendungsmodell AMi vorgesehen sein. Es beschreibt dementsprechend eine Standardsoftwareanwendung oder eine individuelle Softwareanwendung.
In dem Beispiel der Figur 2 ist für die mandantenspezifische Datenbank CSDX eine Möglichkeit veranschaulicht, hierin ein Anwendungsmodell AM2 für die zur Laufzeit zu erzeugende Softwareanwendung AW zu hinterlegen, das lediglich aus Verweisen V- AMSTANDARD auf das Standard-Anwendungsmodell AMSTANDARD, I und etwaigen Abweichungen AB-AMSTANDARD von dem Standard-Anwendungsmodell AMSTANDARD gebildet ist. Ein Standard-Anwendungsmodell AMSTANDARDJ kann folglich jederzeit durch - mit dem Anwendungsmodellerstellungsvorrichtung AMD erstellte - zusätzliche Konfigurationsinformationen erweitert oder modifiziert werden, wobei die Standard- Anwendungsmodelle weiterhin in dem Anwendungsmodellspeicher AMR vorgehalten werden.
Hierbei ist zu beachten, dass eine endgültige Festlegung mit der ursprünglichen Zweckbestimmung eines Anwendungsmodells als Standard- oder Individualanwendung jedoch nicht verbunden ist. Ein einmal erstelltes Anwendungsmodell AMi oder ein Standard-Anwendungsmodell AMSTANDARDJ kann durch Referenzierung oder Kopieren beliebig häufig verwendet und gegebenenfalls modifiziert als neues Anwendungsmodell (in einer mandantenspezifischen Datenbank CSDi..x und/oder dem Anwendungsmodellspeicher AMR) gespeichert werden. Folglich kann auch die Einrichtung S1 gleichzeitig beliebig viele Anwendungsmodelle enthalten und verwenden.
Eine Datenhaltung DH einer Anwendung wird im Vorfeld mit Hilfe der Mandantenverwaltungsvorrichtung CA erstellt. Dazu wird zunächst eine leere Datenbank (ohne Abbildung) angelegt, das gewünschte Anwendungsmodell, z.B. AMi , an die Datenbank übergeben. Dort wird aus dem im Anwendungsmodell enthaltenen Metamodell, für das Anwendungsmodell AMi aus dem Metamodell MMi , das Datenbankmodell, d.h., die konkrete Datenstruktur, generiert, in der dann die eigentlichen Daten gespeichert werden können. Die Erzeugung einer Anwendung und gleichzeitig ihre Bereitstellung zur Nutzung erfolgt automatisch zur Laufzeit. Nach dem Einloggen eines Benutzers in die Einrichtung S1 lädt eine Steuerungseinheit der Anwendungsplattform (ohne Abbildung) rechtegesteuert zunächst das Anwendungsmodell, z.B. AMi , und lädt es in den Arbeitsspeicher des Rechners (ohne Abbildung), auf der die Einrichtung S1 installiert ist.
Will der Benutzer ein Geschäftsobjekt (z.B. Kunde) bearbeiten, wird die entsprechende Anfrage an die Modell-Engine ME geleitet, die das instanziierte Anwendungsmodell AMi (z.B. für eine CRM-Anwendung) ausliest, die Konfigurationsinformationen aus dem Anwendungsmodell AMi auswertet und zur Laufzeit das entsprechende Objekt der Anwendung erzeugt, indem sie zur Laufzeit abstrakte Datenmodell-Objekte (wie z.B. „Organisation") in konkrete Objekte (wie z.B. „Kunde (Unternehmen)") wandelt und der Anwendung zuweist. Objektbeziehungen (wie z.B. „zu einer Organisation gehören (n) Personen") werden dabei ebenfalls zur Laufzeit anhand des Anwendungskonfigurationsmodells AKM ausgewertet und typisiert (d.h. beispielsweise lässt sich zu einem„Kunden" nur ein„Ansprechpartner (Kunde)" zuordnen und nicht etwa eine beliebige Person). Zur Darstellung des Objekts gibt die Model Engine ME die notwendigen Parameter an die generischen GUI-Bausteine weiter, mit denen dann die Benutzeroberfläche GUI generiert wird.
Die Modell-Engine ME stellt mithin die Objekte bereit, die für die Verarbeitung und Darstellung entsprechender Daten notwendig sind. Soll ein Datensatz durch den Aufruf einer Funktion verarbeitet werden, generiert die Modell-Engine ME zur Laufzeit im Arbeitsspeicher das dafür notwendige Objekt. Objekte haben dabei die Klasse „Modellnstanz". Die Klasse„Modellnstanz" setzt sich aus der Klasse„ModelElement" und der für dieses „ModelElement" im Anwendungskonfigurationsmodell AKM definierten Parameter zusammen. Die Modell-Engine ME erzeugt durch Fabrikmethoden und mittels Auswertung des Anwendungsmodells AM demnach Modell-Instanzen für die weitere Verarbeitung.
Die Modell-Engine ME ist so realisiert, dass sie beliebige Modelle bzw. Strukturen abbilden und verwalten kann. Ein fachliches Klassenmodell der Modell-Engine ME selbst besteht im Kern aus zwei Klassen: Knoten und Attributen. Knoten können Attribute beinhalten. Des Weiteren können Knoten mit beliebigen anderen Knoten verknüpft werden. Wird ein Anwendungsmodell übergeben, so ist die Modell-Engine ME in der Lage, aus diesem Modell ein Gerüst aus Knoten mit Eigenschaften (Attributen) abzuleiten. Eine Fachlogik, die in der herkömmlichen Softwareentwicklung schon während der Programmierung festgelegt werden muss, wird durch diesen Mechanismus erst zur Laufzeit in Form des jeweiligen Anwendungsmodells übergeben. Dies wird insbesondere im Zusammenhang mit den beigefügten Figuren 4C und 5B anhand einer beispielhaften Softwareanwendung noch näher erläutert werden.
Das Ausführen von Funktionen und die Anzeige weiterer Ansichten an der Benutzeroberfläche GUI zur Laufzeit sind von den Aktionen des Nutzers oder im
Anwendungsmodell AM definierten Bedingungen abhängig. Dabei wird jede Anfrage bzw. jeder Befehl (z.B.„Zeige Kundendaten an") zunächst in die Modell-Engine ME geleitet.
Diese wertet die Anfrage auf Basis des Anwendungsmodells, z.B. AMi , aus, holt die zum betroffenen Datenobjekt gehörigen Daten aus der Datenbank des Mandanten CSDi , ruft zur Ausführung der in dem Objekt definierten Operationen ggf. einen speziellen
Funktionsbaustein auf (z.B.„Dokument generieren") und stellt die Daten gemäß den im Anwendungsmodell AMi definierten Angaben, d.h., mit der entsprechenden View, auf der Benutzeroberfläche GUI dar.
Die Anwendungsplattform ordnet dabei beispielsweise jedem Datenbereich automatisch eine Listenansicht und entsprechende Grundfunktionen - wie anzeigen, hinzufügen, bearbeiten, löschen, kopieren - zu. Auch können jedem Datensatz DS automatisch zum Beispiels eine Detailansicht und zugehörige Grundfunktionen - wie hinzufügen, bearbeiten, speichern, löschen, kopieren - zugewiesen sein. Zu jedem Ansichtentyp (View) ist vorzugsweise bereits eine Grundkonfiguration hinterlegt, die durch Informationen bzw. Vorgaben aus dem zugehörigen Anwendungskonfigurationsmodell AKMi konkretisiert oder ggf. noch geändert wird. Die Grundkonfiguration kann beispielsweise eine Indexierung, die Darstellung als Tabelle mit leeren Spaltennamen (als Übergabeparameter), Filterfunktionen, Basisfunktionen etc. umfassen, die durch das Anwendungskonfigurationsmodell zum Beispiel in Form von Datenobjekt-Informationen, der Zuweisung von ausgewählten Feldern des Datenobjekts zu Spalten der Tabelle, der Zuordnung von Spezialfunktionen etc. konkretisiert wird (vgl. hierzu auch Figur 3).
Fordert der Benutzer z.B. aus einer Liste von Objekten (Kunden, Interessenten, Ansprechpartner etc.) durch Auswahl eines Datenobjekts (z.B. Kunde) die zugehörigen Datensätze DS an (z.B. die Kundendaten), so liest die Modell-Engine ME das Anwendungsmodell (z.B. AMi) und generiert die Objektinstanzen im Arbeitsspeicher. Die Modell-Engine ME fordert über eine Datenbank-Zugriffsschicht (Bestandteil der Datenbank DB, nicht separat abgebildet) die Werte zu dem Datenobjekt aus der mandantenspezifischen Datenbank (CSDi) an und übergibt die Visualisierung der Objektinstanzen - entsprechend den im Anwendungsmodell (AMi) hinterlegten Informationen über den zugehörigen Ansichtentyp (hier: eine Listenansicht) - an die generische Benutzeroberfläche GUI. Zur eigentlichen Visualisierung stellt die generische Benutzeroberfläche GUI den Ansichtentyp sowie - entsprechend der im Datenmodell getroffenen Zuordnung - die zum Datenobjekt gehörenden standardisierten Benutzeroberflächenelemente zur Verfügung und stellt sie an der Benutzeroberfläche GUI dar. Die Datenfeldstruktur und -darstellung in der Benutzeroberfläche GUI wird dabei automatisch aus dem Metamodell (MMi) abgeleitet.
Neben den generischen Benutzeroberflächenelementen sind bevorzugt auch Funktionen der (Software-)Anwendungen AW in der Anwendungsplattform als generische Funktionsbausteine implementiert und werden zur Laufzeit durch das jeweilige Anwendungsmodell, z.B. AMi oder AM2, spezifiziert und konfiguriert. In dem Anwendungsmodell ist dazu z.B. definiert, ob eine Funktion als Button dargestellt oder automatisch getriggert werden soll. Sofern letzteres der Fall sein soll, ist weiter spezifiziert, welche Bedingungen zu einer Ausführung der Funktion führen sollen. So kann beispielweise definiert sein, dass eine bestimmte Funktion nach dem Speichern eines Datensatzes DS ausgeführt wird, wenn das aktuelle Datum „heute" ist. Soll die Funktion als Button angezeigt werden, so ist im Anwendungsmodell hinterlegt, welche Beschriftung der Button erhält und welche Vorbedingungen ggf. existieren, d.h., z.B. ob die Ausführung der Funktion rechteabhängig sein soll. Des Weiteren ist in einem Anwendungsmodell definiert, welches Datenobjekt (z.B. Person, Aufgabe, Termin) aus dem Datenmodell als Übergabe-Parameter übergeben werden soll und welche Nachbedingungen bestehen, d.h., z.B. ob und was nach dem Ausführen der Funktion noch erfolgen soll. Hierunter wird beispielsweise verstanden, dass ein Attribut "letzter Kontakt" für ein Datenobjekt Person auf „heute" aktualisiert und ein Follow-up angelegt wird.
Eine erfindungsgemäße Lösung unterscheidet sich von den herkömmlichen Verfahren der Softwareentwicklung und -bereitstellung zusammenfassend darin, dass bei ihr der Übergang von der Modelldefinition zur Nutzung einer Softwareanwendung AW ohne Programmierung, Kompilierung und Installation erfolgt. Die erfindungsgemäße Lösung bietet au ßerdem die Möglichkeit, gleichzeitig beliebig viele Anwendungsmodelle AM zur Laufzeit zu nutzen und damit beliebig viele Anwendungen AW basierend auf beliebig vielen unterschiedlichen Metamodellen MM auf derselben Plattform zu betreiben. Die Anwendungsmodelle AM können dabei auch zur Laufzeit noch optimiert werden. Bei den herkömmlichen Verfahren muss dagegen mit einem starren Metamodell gearbeitet werden.
Mit der erfindungsgemäßen Lösung lassen sich folglich erhebliche Vorteile für die Anwendungserstellung und -bereitstellung erzielen. Hierunter fallen unter anderem:
- Hohe Flexibilität, Schnelligkeit, Sicherheit und Wartbarkeit - neue Anwendungen oder Änderungen und Erweiterungen an bestehenden Anwendungen AW, z.B. in den Datenobjekten und -strukturen, lassen sich ohne Programmierung umsetzen und sind sofort verfügbar, da hierfür nur die (fachlichen) Anwendungsmodelle AM erstellt bzw. bearbeitet werden müssen, was auch zur Laufzeit erfolgen kann;
- Anwendungserstellung, -bereitstellung und -betrieb erfolgen integriert auf der vorzugsweise webbasierten Anwendungsplattform - Quellcode-Kompilierung, Installation und Ähnliches sowie sonstige Entwicklungswerkzeuge, Betriebs- oder Laufzeitumgebungen usw. sind nicht notwendig;
Reduktion der Abhängigkeit von schwer verfügbarem IT-Knowhow - technisches Wissen wird für die Erstellung von Softwareanwendungen AW nicht mehr benötigt, da Fachanwender neue Anwendungen selbst erstellen und sofort nutzen können.
An einem mit den Figuren 4A-4C und 5A-5B veranschaulichten Ausführungsbeispiel soll die Funktionsweise der erfindungsgemäßen Lösung noch näher erläutert werden. Es soll eine Datenbank-Anwendung AW („Jukebox" genannt) zur Verwaltung von Audio- und Video-CDs/-Alben erstellt werden. Die Anwendung soll neben den Elementarfunktionen, wie z.B. anzeigen, bearbeiten, speichern und löschen, auch das Sortieren der Datensätze, das Ausdrucken von Listen und das Suchen nach Daten ermöglichen. Sie soll eine Aufstellung der enthaltenen Datenobjekte jeweils in Listenansichten anzeigen sowie die Informationen zu einem Datenobjekt jeweils in Form einer Detailansicht darstellen.
In der Figur 4A ist hierfür auszugsweise der (abstrakt dargestellte) Inhalt eines Anwendungsmodells AM für dieses Ausführungsbeispiel einer Softwareanwendung mit seinem Metamodell MM und seinem Anwendungskonfigurationsmodell AKM dargestellt. Das dargestellte Anwendungsmodell AM definiert dabei des Weiteren noch bestimmte Regeln, d.h., insbesondere Funktionen, die zur Laufzeit ausgeführt werden sollen, sowie Workflows. In der Figur 4B ist schematisch die Erzeugung einer Datenhaltung DH für die Softwareanwendung„Jukebox" aus dem Metamodell MM dargestellt, während die Figur 4C schematisch die Erzeugung eines Klassenmodell mit Klassen und Klassenattributen aus dem Metamodell MM zur Laufzeit durch eine Modell-Engine ME veranschaulicht. Mit den Figuren 5A und 5B werden die unterschiedlichen Instanziierungen zur Laufzeit bei einem üblichen objektorientierten Ansatz und bei der erfindungsgemäßen Lösung für die Softwareanwendung„Jukebox" einander gegenübergestellt.
Es wird davon ausgegangen, dass es bereits ein Metamodell MM mit den abstrakten Datenobjekten„Person" und„Produkt" gibt, das genutzt werden kann. Mit dem Anwendungsmodellerstellungsvorrichtung AMD wird nun zunächst das Anwendungsmodell AM für die Anwendung„Jukebox" erstellt, indem das Metamodell MM ausgewählt und der Anwendung durch Referenzierung zugewiesen wird. Dabei werden die Grundeigenschaften der Datenobjekte vererbt. Sie können nun anwendungsspezifisch erweitert werden - hier beispielsweise um einen Künstlernamen in den Personendaten. Gleichzeitig können auch vererbte Eigenschaften markiert werden, um z.B. Datenfelder zur Laufzeit auszublenden.
Mit dem Metamodell MM sind bereits auf Basis einer Schema-Definition die Grundfunktionen festgelegt und die Oberfläche der Anwendung modelliert, da die Festlegungen des Metamodells MM aufgrund der Referenzierung automatisch auch für das Anwendungsmodell AM der Anwendung„Jukebox" gelten. Dies gilt gleichermaßen, sofern das Metamodell MM durch Kopieren eines Standard-Metamodells MMSTANDARD I angelegt wurde.
Neben dem Metamodell MM wird mit dem Anwendungsmodellerstellungsvorrichtung AMD nun auch ein Anwendungskonfigurationsmodell AKM beschrieben. Hier werden im Modell für die Jukebox z.B. folgende Festlegungen getroffen: Für die Datenhaltung DH:
■ Datenobjekt„Person": soll konkretisiert werden durch die Rolle„Artist"
■ Datenobjekt„Produkt": soll konkretisiert werden durch die Rolle„Album"
Für die Darstellung auf der Benutzeroberfläche GUI:
■ Listenansicht für„Artist": Anzeige der Spalten„Künstlername",
„Geburtsdatum",„Genre" usw.
■ Anzeigename des Datensatz-Typs
(z.B. für die Anzeige bei Referenzierungen): Künstlername Für die Benutzerverwaltung:
■ Rollen: Jukebox- Verwalter
■ Rechte: Jukebox- Verwalter darf alle Funktionen auf allen
Daten ausführen
■ Benutzer: Peter Müller, erhält die Rolle Jukebox- Verwalter
Konkret ist beispielsweise in dem Anwendungskonfigurationsmodell für die Rolle„Artist" beschrieben, dass sie sich von der Metarolle„Person" des Metamodells MM ableitet. Die Rolle „Artist" definiert sich hier durch einen Parameter „Rolle" in dem Anwendungskonfigurationsmodell AKM, der mit dem Wert „Artist" belegt werden soll. Über einen Pfad findet hier die Zuordnung zur Metarolle„Person" statt. In dem dargestellten Beispiel gibt es also für Anwendung„Jukebox" einen Datenbereich, der „Artists" lautet, in dem über einen bestimmten in dem Anwendungskonfigurationsmodell AKM definierten Ansichtentyp - z.B. eine Listenansicht
- für „Artist" alle Datensätze des Typs „Artist" aufgelistet werden. Das Anwendungskonfigurationsmodell AKM definiert dabei, dass für jede neu angelegte Person die Rolle„Artist" zu setzen ist und gleichzeitig nur die Personen (in der Liste) angezeigt werden, die auch die Rolle „Artist" innehaben. Hier wird demzufolge ein Datenobjekt „Artist" über einen Parameter „Rolle" vom Datenbereich „Person" des Metamodells MM abgeleitet. Eine Anpassung oder Erweiterung des Datenobjekts„Artist" könnte über weitere Parameter mittels des Anwendungskonfigurationsmodell AKM erfolgen. Beispielsweise könnte das Datenobjekt „Artist" über das Anwendungskonfigurationsmodell AKM um ein Feld „Künstlername" erweitert werden, das in dem Metadatenelement„Person" nicht vorhanden ist.
Durch das das Metamodell MM und das Anwendungskonfigurationsmodell AKM umfassende Anwendungsmodell AW ist die Anwendung „Jukebox" vollständig beschrieben, insbesondere ihr Datenbankmodell DBM für die dahinter stehende Datenbank DB (vgl. Figur 4B).
In dem Anwendungsmodell AM ist zum Beispiel außerdem definiert, dass eine Funktion „Datensatz verknüpfen" als Button mit der Bezeichnung „Datensatz verknüpfen" dargestellt werden soll. Eine Verknüpfung soll zwischen den Datenobjekten„Produkt" und „Person" möglich sein. Nachbedingungen sind nicht definiert. Das Recht zur Ausführung der Funktion wurde dem Jukebox-Verwalter zugeordnet. Die Datenhaltung DH der Anwendung„Jukebox" wird im Vorfeld - nicht durch den Nutzer
- mit Hilfe des Mandantenverwaltungsvorrichtung CA erstellt. Dazu wird eine Datenbank (ohne Abbildung) angelegt, das erstellte Anwendungsmodell AM für die Anwendung „Jukebox" an die Datenbank übergeben und die konkrete Datenstruktur automatisch generiert. Die Erzeugung der Anwendung „Jukebox" zur Laufzeit nach dem Einloggen eines Nutzers erfolgt wie bereits obig allgemein beschrieben. Dabei werden die abstrakten Objekte „Person" und „Produkt" durch die Rollen „Artist" bzw. „Album" spezifiziert. Wie insbesondere mit der Figur 4C dargestellt ist, wird hierfür zur Laufzeit das Metamodell MM eingelesen. Dabei wird zu jedem in dem Metamodell MM definierten Metadatenelement, welches auf einer definierten Hierarchieebene liegt und auf eine bestimmte Art und Weise identifiziert ist, eine neue Klasseninstanz eines bestimmen Typs erzeugt, in der Figur 4C eine Klasse vom Typ„ModelElement". In dem gezeigten Ausführungsbeispiel trifft dies auf die Metadatenelemente„Person" und„Product" zu, die beide auf der gleichen Ebene liegen. Da ein ModelElement beliebig viele Attribute haben kann, wird zu jedem Metadatenelement auf einer unteren Ebene (z.B. „Nachname" oder „ID") ein entsprechendes ModelAttribute für die Klasseninstanz erzeugt. Auf diese Weise können alle Metadatenelemente aus dem Metamodell MM eingelesen und als Klasseninstanz für die Softwareanwendung„Jukebox" angelegt werden.
Über die Modell-Engine ME wird hieraus ein Gerüst aus Knoten mit Eigenschaften (Attributen) abgeleitet, indem bereits im Metamodell MM definierte Verknüpfungen auf dieselbe Weise eingelesen und jeweils als ModelAttribute abgebildet werden. Der Benutzer will nun z.B. Daten zu einem Album erfassen und diesem auch einen Künstler („Artist") zuordnen. Es sei unterstellt, dass ein Datensatz für ein Datenobjekt „Artist" bereits angelegt ist und der Nutzer die Liste der Alben aufgerufen hat. Die Markierung des gewünschten Album-Datensatzes und der Aufruf der Funktion„anzeigen" (durch Betätigung eines Buttons„Anzeigen") auf der Benutzeroberfläche GUI führt dazu, dass die entsprechende Anfrage in die Modell-Engine ME geleitet wird. Diese liest aus dem Anwendungsmodell AM unter anderem die Angaben zum Datenobjekt„Album", zu den Rechten des Nutzers und zur Darstellung auf der Benutzeroberfläche GUI, generiert die Instanz zum Datenobjekt„Album" im Arbeitsspeicher, fordert über die Datenbank- Zugriffsschicht die Daten zum ausgewählten Album aus der (mandantenspezifischen) Datenbank CSD an und übergibt die Daten zwecks Anzeige auf der Benutzeroberfläche GUI an die gemäß Anwendungsmodell AM für die Anzeige von einzelnen Datenobjekten festgelegte View„Detailansicht". Der Nutzer aktiviert daraufhin durch Betätigung eines „Bearbeiten"-Buttons die Funktion„Datensatz bearbeiten". Der Befehl wird an die Modell- Engine ME geleitet, die wiederum das Anwendungsmodell AM liest, die Rechte des Nutzers auswertet, den Befehl zur Freigabe des Datensatzes für die Bearbeitung an die Datenbank DB bzw. die mandantenspezifische Datenbank CSD übergibt sowie den Befehl zur Änderung des Anzeige- in den Bearbeitungs-/ Eingabemodus an die Benutzeroberfläche GUI übergibt.
Der Nutzer kann nun die Daten eingeben und durch Betätigung eines Buttons„Datensatz verknüpfen" die entsprechende Funktion ausführen. Dabei wird - gemäß den oben bereits geschilderten Mechanismen und dem im Anwendungsmodell AM definierten Festlegungen - zunächst die Liste der verknüpfbaren Datenobjekte angezeigt, d.h. hier „Artist". Nach Markieren des Datenobjekts „Artist", Ausführen der Funktion „anzeigen" und Anzeige der zu „Artist" vorhandenen Datensätze in einer Liste mit den Spalten „Künstlername", „Geburtsdatum" und „Genre kann der gewünschte „Artisf-Datensatz ausgewählt und dem „AlburrT'-Datensatz zugeordnet werden. Mit dem Speichern des „Album"- Datensatzes in der mandantenspezifischen Datenbank CSD durch Ausführen einer Funktion„speichern" ist die Verknüpfung hergestellt. Das Speichern von Daten erfolgt hierbei durch die aus dem Datenhaltungsschema generierte Datenhaltung DH. Aufgrund des bearbeiteten Datensatzes (z.B.„Artist") und aufgrund des der Modell-Engine ME bekannten Metamodells MM kann der Datensatz an die entsprechende Stelle in der Datenhaltung DH geschrieben werden (hier dann unter „Persons").
Komplexere Befehle und Funktionen werden mit Hilfe der Regeln des Anwendungsmodells AM abgebildet. Die Regeln sind in dem Anwendungsmodell AM entsprechend den für regelbasierte Systeme üblichen Standards definiert. Die Ausführung eines hierüber definierten Befehls wird von einer Bedingung und einem Auslöser angestoßen und erfolgt automatisch.
Beispielsweise wird durch eine unter„Regeln" in dem Anwendungsmodell AM definierte Funktion „calculatesum" für die Anwendung „Jukebox" ein Gesamtwert der Album- Sammlung anhand von Einkaufspreisen der einzelnen Alben errechnet. Diese Funktion „calculatesum" summiert die Einkaufspreise aller Alben und aktualisiert damit einen vormals ermittelten und in der mandantenspezifischen Datenbank CSD gespeicherten Gesamtwert der Album-Sammlung wenn ein neues Album (Album ID="neu") der Sammlung hinzugefügt wird und der entsprechende Datensatz DS für das neue Album abgespeichert wurde. Die Modell-Engine ME liest hierbei wie bereits beschrieben das Anwendungsmodell AM mit den dort hinterlegten Regeln aus, wertet die Bedingungen gemäß dem Anwendungsmodell AM aus, übergibt die Parameter zur weiteren Ausführung des jeweiligen Befehls und nimmt das Ergebnis zwecks Weiterverarbeitung, d.h., z.B. zur Anzeige auf der Benutzeroberfläche GUI, entgegen.
Obwohl mit den Figuren 4A-4C und 5A-5B lediglich eine Ausführungsvariante für eine bestimmte Softwareanwendung „Jukebox" im Detail veranschaulicht wurde, ist die erfindungsgemäße Lösung hierauf selbstverständlich nicht beschränkt. Wie insbesondere unter Bezugnahme auf die Figuren 1 und 2 dargelegt wurde, können in einer Datenbank DB der Anwendungsplattform vollkommen unterschiedliche Anwendungsmodelle für verschiedene Softwareanwendungen AW und für verschiedene mandantenspezifischen Datenbanken CSDi..x hinterlegt sein. Es können somit unterschiedliche (vorzugsweise webbasierte) Softwareanwendungen auf einer Anwendungsplattform, z.B. als„Software as a Service", ohne Programmierung und Kompilierung nicht nur in einfacher Weise erstellt, sondern auch automatisch zur Laufzeit erzeugt und zur sofortigen Nutzung bereitgestellt werden.
Mit den Figuren 6A und 6B sind des Weiteren exemplarisch Oberflächenfunktionen GUI- FK einer Benutzeroberfläche einer computerimplementierten Einrichtung zur Erstellung insbesondere eines Anwendungsmodells AM für eine Softwareanwendung sowie der Anwendungsplattform, auf der eine Softwareanwendung lauffähig ist, dargestellt. Hierbei ist in einer Weiterbildung des insbesondere in der Figur 1 dargestellten Ausführungsbeispiels die Erzeugung und Bereitstellung eine Softwareanwendung AW mit einer Unterstützung hinterlegter Geschäftsprozesse möglich, indem zusätzlich zu einem Metamodell MM und einem Anwendungskonfigurationsmodell AKM ein Organisationsmodell OM vorgesehen ist.
Die Figur 6A zeigt hierbei Systemwerkzeuge, deren Funktionen über eine Benutzeroberfläche durch eine Bedienperson nutzbar sind, um insbesondere ein Anwendungsmodell AM für eine Softwareanwendung in einfacher Weise und ohne vertiefende Programmierkenntnisse zu erzeugen. Ein Anwendungsmodell AM soll hierbei mehrere Sub- oder Teilmodelle in Form eines Metamodells MM, eines Anwendungskonfigurationsmodells AKM und eines Organisationsmodells OM umfassen.
Das Metamodell MM
- definiert die Datenobjekte und ihre Beziehungen/ Strukturen sowie die Darstellung auf der Oberfläche und
- beschreibt damit die Datenhaltung inkl. ihrer Visualisierung. Das Organisationsmodell OM
- beschreibt die für die Anwendung relevanten aufbauorganisatorischen Grundlagen und Rahmenbedingungen, d.h. Organisationseinheiten, Aufgaben, Stellen und Stellenbesetzungen/ Benutzer (u. a. aus einem Strukturmodell, das Teil des Organisationsmodells ist, leiten sich später z.B. Benutzerrechte ab)
- bildet das für das Anwendungsgebiet relevante Prozessmodell mit den idealtypischen Prozessen, Aktivitäten, zugehörigen, Rollen, Inputs und Outputs/ Ergebnistypen u. a. ab und
- beschreibt die von der Anwendung zu unterstützenden Geschäftsprozesse (als Basis für eine Workflow-Unterstützung).
Das Anwendungskonfigurationsmodell AKM
- definiert die Anwendung (Metadaten der Anwendung) und den Kontext
- spezifiziert das Metamodell MM
- konkretisiert und ändert ggf. eine bereits hinterlegte Grundkonfiguration sowie
- spezifiziert und konfiguriert generische, durch die Anwendungsplattform bereitgestellte Funktionen.
Die in der Figur 6A schematisch dargestellte Einrichtung verfügt nun unter anderem über eine Anwendungsmodellerstellungsvorrichtung AMD mit mehreren Modulen für die einzelnen Teilmodelle des Anwendungsmodells, mithin ein Metamodell-Erstellungsmodul MMD, ein Organisationsmodell-Erstellungsmodul OMD und ein Anwendungskonfigurationsmodell-Erstellungsmodul AKMD. Darüber hinaus sind zusätzlich zu der Anwendungsmodellerstellungsvorrichtung AMD ein Regel- Erstellungsmodul RD, ein Workflow-Erstellungsmodul WFE, ein Testwerkzeug TS und (Standard-) Ansichtsbausteine VW bereitgestellt. Die hierüber realisieren Oberflächen- Funktionen GUI-FK sollen nachfolgend näher beschrieben werden.
Das Metamodell-Erstellungsmodul MMD (engl, „meta model designer") dient zum Beschreiben der Datenhaltung DH einer Softwareanwendung AW und zum Verwalten der erstellten Metamodelle. Unter Nutzung eines Metamodells MM sollen mit ihm die Datenobjekte und Objektbeziehungen/ -strukturen einer Anwendung AW definiert werden können. Das Metamodell liegt beispielsweise technisch als XML-Schema-Datei vor. Die Organisationsmodelle OM und Anwendungskonfigurationsmodelle AKM werden ebenfalls in XML-Dokumenten beschrieben. XML ist keine Programmiersprache, sondern lediglich eine Metasprache. XML-Dokumente enthalten dementsprechend selbst z.B. keine Befehle und Schleifen wie eine Programmiersprache (und damit keine Anweisungen an den Prozessor, wie dies bei herkömmlichen, „fest" programmierten Anwendungen der Fall ist). Um anhand der XML-Dokumente dennoch Anwendungen erzeugen, bereitstellen und steuern zu können, werden die Dokumente später durch Modell-Engine ME ausgewertet werden, um daraus die Befehle zu erzeugen.
Mit dem Metamodell MM werden bereits objektbezogene Regeln definiert (insbesondere Plausibilitätsprüfungen) und die Benutzeroberfläche GUI der Anwendung AW modelliert. Au ßerdem definiert es die Darstellung der Datenfeldstruktur der Datenobjekt-Typen auf der Benutzeroberfläche GUI, indem den im Metamodell MM beschriebenen Datenfeldtypen standardisierte GUI-Elemente der generischen Benutzeroberfläche (z.B. Eingabefelder mitsamt Kardinalitäten) automatisch zugeordnet werden. Die Ansichtentypen und standardisierte GUI-Elemente sind jeweils als Bausteine in der Anwendungsplattform implementiert. Das Organisationsmodell-Erstellungsmodul OMD (engl. „Organisation model designer") dient dem modellhaften Beschreiben sowohl der Ablauforganisation als auch der aufgabenbezogenen, funktionalen Strukturen einer Organisation oder eines Projekts (als zeitlich begrenzter Organisation). Ein solchermaßen umfänglich abgebildetes Organisationsmodell OM kann insbesondere zur Steuerung der zu erstellenden Softwareanwendung AW benötigt sein.
Ein Organisationsmodell OM umfasst daher beispielsweise separat wenigstens ein Strukturmodell, ein Prozessmodell sowie ein Geschäftsprozessmodell. Das Strukturmodell und das Prozessmodell legen dabei eine eher statische Sicht auf eine Organisation, indem sie deren Aufbauorganisation und die idealtypische Ablauforganisation abbilden. Die Informationen aus einem Strukturmodell können dafür genutzt werden, um z.B. strukturelle, d.h. aufgaben-orientierte Berechtigungen zu vergeben, Berichtsstrukturen im Anwenderunternehmen differenziert nach Organisationseinheiten auszuwerten, in betriebswirtschaftlichen, insbesondere personalwirtschaftlichen Anwendungen Komponenten und Funktionen zu steuern oder im Rahmen von Business Workflows anfallende Aufgaben zuständigen Bearbeitern zuzuweisen. Ein Prozessmodell beschreibt z.B. die idealtypische Prozessstruktur einer Organisation, ausgehend von der klassischen Aufteilung/Kategorisierung in Kern-, Management- und Support-Prozesse. Die Prozesse werden hierarchisch aufgegliedert und von Ebene zu Ebene detaillierter dargestellt. Die so definierten Detailschritte eines Prozesses dienen nicht nur der Dokumentation, sondern können z.B. als Prozessbausteine auch in anderen Kontexten wiederverwendet werden. Im Gegensatz zum Strukturmodell oder zum Prozessmodell ist das Geschäftsprozessmodell dynamisch orientiert. Es beschreibt die konkreten Geschäftsprozesse, die unter anderem von der zu erstellenden Softwarenanwendung AW technisch unterstützt werden sollen. Zur modellhaften Abbildung der Geschäftsprozesse werden die einzelnen Prozessbausteine (Aktivitäten) entsprechend den zu unterstützenden Geschäftsabläufen aus dem (statischen) Prozessmodell ausgewählt, in die gewünschten Abfolgen gebracht und mit Verknüpfungs- und Ausführungsregeln kombiniert. Die so abgebildeten Geschäftsprozesse werden dann später als Basis für die Ausführung als Workflows genutzt.
Die anwendungsspezifischen Konfigurationseinstellungen werden in dem Anwendungskonfigurationsmodell AKM gebündelt bzw. abgebildet, welches mithilfe des Anwendungskonfigurationsmodell-Erstellungsmoduls verwaltet werden. Ein Anwendungskonfigurationsmodell AKM dient im Einzelnen dazu, das Metamodell MM zu spezifizieren, d.h. aus den mit dem Metamodell MM definierten abstrakten Objekten konkrete Objekte zu bilden, indem die abstrakten Objekte zur Laufzeit mit konkreten Daten gefüllt und damit konkretisiert, typisiert und konfiguriert werden. Dabei können auch die vordefinierten Attribute noch modifiziert werden. Das Anwendungskonfigurationsmodell AKM konkretisiert und ändert gegebenenfalls - wie zuvor im Detail beschrieben - au ßerdem die bereits hinterlegte Grundkonfiguration (Index, Tabelle mit leeren Spalten-Namen (als Übergabeparameter), Filterfunktionen, Basisfunktionen) eines Ansichtentyps (View), der einem Datenbereich zugeordnet ist (z.B. durch Datenobjekt-Informationen, Spalten der Tabelle (= ausgewählte Felder des Datenobjekts), Zuordnung von Spezialfunktionen etc.). Das Anwendungskonfigurationsmodell AKM spezifiziert und konfiguriert darüber hinaus die in der Anwendungsplattform als generische Funktionsbausteine implementierten Funktionen. Dazu wird im finalen Anwendungsmodell AM z.B. definiert, ob eine Funktion als Button dargestellt oder automatisch getriggert werden soll. Sofern Letzteres der Fall sein soll, ist weiter spezifiziert, welche Bedingungen zu einer Ausführung der Funktion führen sollen (z.B. nach dem Speichern eines Datensatzes sowie, wenn das aktuelle Datum„heute" ist). Soll die Funktion als Button angezeigt werden, so ist in dem erstellten Anwendungsmodell AM hinterlegt, welche Beschriftung der Button erhält und welche Vorbedingungen ggf. existieren, d.h., z.B. ob die Ausführung der Funktion rechteabhängig sein soll. Des Weiteren wird definiert, welches Datenobjekt (z.B. Person, Aufgabe, Termin) aus dem Metamodell als Übergabe-Parameter übergeben werden soll und welche Nachbedingungen bestehen, d.h., ob und was nach dem Ausführen der Funktion noch erfolgen soll (z.B. "letzten Kontakt" auf „heute" aktualisieren, Follow-up anlegen, etc.).
Die Anwendungsmodellerstellungsvorrichtung AMD verfügt ferner noch über übergreifende Funktionalitäten, die dazu dienen, aus den vorgenannten Teilmodellen und den sonstigen Anwendungskomponenten (Regeln etc.) das Anwendungsmodell AM zu erstellen. Eine solche Erstellung eines Anwendungsmodells AM erfolgt, indem das Zusammenwirken der Teilmodelle (MM, OM und AKM), Modellbausteine und Anwendungskomponenten und die konkrete Ausprägung der Geschäftsobjekte über Konfiguration geregelt werden. Die verschiedenen Konfigurationsmöglichkeiten der einzelnen Teilmodelle und Anwendungskomponenten (vom Metamodell bis hin zur Geschäftslogik der zu erstellenden Anwendung AW) werden in der Anwendungsmodellerstellungsvorrichtung AMD funktional zusammengeführt. Einige Anwendungskomponenten sind dabei z. B. gesondert durch das Regel- Erstellungsmodul RD und das Workflow-Erstellungsmodul WFE erstellbar.
Das Regel-Erstellungsmodul RD hat dabei die Aufgabe, die Geschäftsregeln und Fakten zu definieren bzw. zu erfassen und ihre zentrale Verwaltung, Prüfung und Bereitstellung zu ermöglichen. In nahezu allen Unternehmensbereichen spielen Geschäftsregeln (z.B. „Wenn die Sonne scheint, dann kostet das Eis 50 Cent mehr.") und Fakten eine große Rolle. Sie beschreiben nicht nur das in diesen geschäftlichen Bereichen relevante Organisationswissen und die Steuerungsinformationen, sondern auch die Geschäftslogik von Softwaresystemen, die diese Unternehmensbereiche unterstützen sollen. Sie determinieren mithin, wie sich ein Softwaresystem oder Geschäftsprozess, der durch eine Softwareanwendung AW gesteuert wird, verhalten soll.
Die Geschäftsregeln sind dabei bevorzugt in einer zentralen Ablage (engl,„repository") verwaltet, gepflegt und revisionssicher gespeichert werden, um sie zum einen für die Erstellung von Anwendungen AW verfügbar zu machen. Zum anderen kann hiermit das grundlegende Verhalten einer Anwendung AW auch später im Rahmen der Nutzung der Anwendung AW noch definiert und können die Geschäftsregeln geändert, simuliert, geprüft und zur Laufzeit bereitgestellt werden. Strukturierte Aufgaben und Prozesse, insbesondere die im Organisations-/ Prozessmodell definierten Geschäftsprozesse, sollen ferner mit Hilfe eines „Workflow Management" informationstechnisch unterstützt und ggf. automatisiert werden können. Hierfür ist das Workflow-Erstellungsmodul WFE hilfreich.
Ein Workflow ist ein Arbeitsablauf (alternativ Geschäftsvorfall oder allgemein Vorgang), der aus einzelnen Aktivitäten aufgebaut ist, die sich auf Teile eines Geschäftsprozesses oder andere organisatorische Vorgänge beziehen. Der Arbeitsablauf beschreibt dabei die operationell-technische Sicht auf die zu unterstützenden (Geschäfts-)Prozesse. Idealerweise erfolgt diese Beschreibung so exakt, dass die folgende Aktivität durch den Ausgang der jeweils vorangehenden determiniert ist. Die einzelnen Aktivitäten stehen demnach in Abhängigkeit zueinander. Ein Workflow hat einen definierten Anfang, einen organisierten Ablauf und ein definiertes Ende. Er ist dabei der Teil des (Geschäfts- )Prozesses, der IT-gestützt durchgeführt werden kann. Workflows zeichnen sich mithin durch einen koordinativen Charakter aus. Ein Workflow wird typischerweise durch die Sequentialisierung und Parallelisierung der Arbeitsschritte erreicht. Synchrone Aktivitäten laufen strikt getrennt ab.
Das Workflow-Erstellungsmodul WFE dient zur Modellierung und Konfiguration konkreter Workflows. Hierbei kann es folgende Funktionen realisieren:
- Übernahme der zu unterstützenden Geschäftsprozesse/ Arbeitsabläufe aus dem Organisationsmodell OM,
- Graphische Ausmodellierung'/ Konkretisierung und Spezifikation der Workflows (z.B.
Differenzierung in unterschiedliche Arbeitsabläufe je nach Rechten und Rollen der Benutzer),
- Verifikation der Arbeitsabläufe (z.B. ob ein Ereignis zu einem bestimmten Zeitpunkt im Arbeitsablauf überhaupt vorgesehen ist),
- Simulation der Arbeitsabläufe/ Workflows sowie
- Konfiguration der Rechte und Rollen der Benutzer.
Das Testwerkzeug TS stellt ferner Funktionalitäten für die konstruktive und analytische Qualitätssicherung bereit, um etwaige Fehler im erstellten Anwendungsmodell AM bzw. in einer hiermit erzeugten Softwareanwendung AW vermeiden bzw. zumindest frühzeitig ermitteln zu können.
Aus der Figur 6B sind durch die Anwendungsplattform bereitgestellten Funktionen anhand unterschiedlicher Funktionskomponenten, wie der Modell-Engine ME, skizziert. Hierbei sind neben der Modell-Engine ME, eine Regel-Engine RE, eine Workflow-Engine WE, ein Funktionsmodul FK und ein Systemadministrationsmodul SYS vorgesehen. Entsprechend den obigen Erläuterten kann die Modell-Engine unterschiedliche Verarbeitungsmodule für die Teilmodelle MM, OM und AKM eines Anwendungsmodelle AM aufweisen, z.B. ein Metamodell-Verarbeitungsmodul („Meta Model Manager"), ein Anwendungskonfigurationsmodell-Verarbeitungsmodul („Application Configuration Model Manager") sowie ein Organistationsmodell-Verarbeitungsmodul („Organisation Model Manager") umfassen.
Die technischen Komponenten der Regel-Engine RE entsprechen den gängigen Standards für Regel-Engines und bestehen z.B. aus:
- Rule Interpreter,
- Core Rules Execution und
- Rules Set (Anzahl der unterschiedlichen Klassen von Regeln). Die Workflow-Engine WE ist beispielsweise mit folgenden technologischen Kernkomponenten ausgestattet:
- Workflow-GUI (notwendige Klassen für die Darstellung des grafischen Workflows),
- Core Workflow Engine (zur Verwaltung, Ausführung und Erzeugung von Workflows) und
- Worklist-Handler (regelt die Zusammenarbeit der einzelnen Prozessteilnehmer).
Über das Funktionsmodul FK werden ferner innerhalb eines Anwendungsmodells nutzbare bzw. mit diesem aufrufbare Funktionen bereitgestellt. Funktionen bestimmen hierbei wesentlich mit, was eine erzeugte Softwareanwendung AW leisten kann. Sie dienen beispielsweise dazu, Operationen auf Daten auszuführen und Verarbeitungsergebnisse zu erzeugen. Die Operationen können sich in der Praxis aus verschiedensten Parametern zusammensetzen und mithin beliebig komplex sein. Im Rahmen eines erfindungsgemäßen Ausführungsbeispiels sind Funktionen als Standardfunktionen realisiert, so dass sie zur Laufzeit mit beliebigen Anwendungsmodellen AM und Anwendungskomponenten kombiniert werden können. Dabei wird zwischen Elementarfunktionen, komplexen Funktionen und konfigurierbaren Funktionen unterschieden. Elementarfunktionen sind immer wieder auftauchende, grundlegende Funktionen, aus denen sich andere Funktionen bilden lassen. Beispiele sind Speichern, Kopieren oder Löschen von Daten oder E-Mail senden. Die komplexen Funktionen werden aus Elementarfunktionen mittels Grundrechenarten, Verkettung, Differentiation oder Integration zusammengesetzt. Sie können au ßerdem modellspezifisch konfigurierbar sein . Beispiele für komplexe Funktionen sind: - Sortieren und Suchen,
- Im- und Export von Daten sowie
- Up- und Download von Dateien.
Die konfigurierbaren Funktionen müssen an das spezifische Anwendungsmodell angepasst werden. Beispiele für solche Funktionen sind:
- Definition eines Schemas für die Rechnungsnummernvergabe oder
- Wandlung eines Objekts in ein anderes Objekt (z.B. eines Angebots in einen Auftrag und letztlich in eine monatlich wiederkehrende Rechnung). Die Funktionen sind in der Anwendungsplattform als generische Funktionsbausteine implementiert, die herkömmlich entwickelt werden müssen. Die konfigurierbaren Funktionen können jedoch zur Laufzeit durch das Anwendungsmodell AM spezifiziert und konfiguriert werden. Im Anwendungsmodell AM ist dazu z.B. - wie oben bereits beschrieben - definiert, ob eine Funktion als Button dargestellt oder automatisch getriggert werden soll.
Das Systemadministrationsmodul ist eine zentrale technische Komponente der Anwendungsplattform. Es hat die Aufgabe, die administrativen Schnittstellen für eine Einrichtung und Verwaltung des Gesamtsystems bereitzustellen und ihren reibungslosen Betrieb zu unterstützen. Es stellt bevorzugt folgende Funktionalitäten bereit :
- Verwaltung und Konfiguration von allgemeinen Systemparametern,
- Setup und Verwaltung von Mandanten (manuelles Anlegen, Mandanten kopieren, automatisches Anlegen von Standard-Mandanten und vorkonfigurierten Lösungen etc.) und Mandanten-Typen (Produktiv-Vorbereitungsmandanten, Mandanten-Modelle u. a.),
- Benutzer- und Benutzergruppen-Verwaltung und
- Rollen- und Rechteverwaltung.
Zusammenfassend schlägt die Erfindung ein Verfahren und eine technische Einrichtung vor, um Softwareanwendungen AW automatisch zu erzeugen, ohne dass programmiert, kompiliert und/oder installiert werden können muss.
Dabei werden Anwendungen bevorzugt zunächst mit Hilfe von entsprechenden Werkzeugen in ganzheitlichen Modellen definiert/beschrieben und dann mit den notwendigen Datenstrukturen (Klassen/ Daten- und Geschäftsobjekte), Geschäfts-/ Anwendungslogik sowie Ansichten modellgetrieben erzeugt und konfiguriert. Im Gegensatz zu herkömmlichen Softwareanwendungen, deren Kontext fest im Quellcode definiert ist, entsteht eine Anwendung erst zur Laufzeit, d.h. beim Einloggen des Benutzers. Erst zu diesem Zeitpunkt wird ein Anwendungsmodell AM, für das der Benutzer berechtigt ist, in den Cache des Web-/Anwendungsservers geladen sowie in eine Modell-Engine ME eingelesen und verarbeitet. Die Anwendung AW selbst wird dabei aus der im Anwendungsmodell AM enthaltenen Anwendungslogik AL und Oberflächenbeschreibung sowie den in der Anwendungsplattform enthaltenen generischen Anwendungsbausteinen erzeugt. Hierbei sind im Anwendungsmodell AM alle für eine Anwendung AW relevanten Informationen abgebildet (inkl. des Anwendungszwecks bzw. -kontexts, der Rollen und Zugriffsrechte des Benutzers usw.). Nach der Prüfung der Rollen und Rechte des Benutzers wird der passende Startbildschirm generiert. Auch bei jeder weiteren Aktion in der Anwendung AW (gleich ob vom Benutzer oder automatisch vom System ausgeführt) wird zunächst das Anwendungsmodell AM ausgelesen und verarbeitet, das dann das weitere Verhalten der Anwendung AW vorgibt.
Zwischenzeitliche Änderungen des Anwendungsmodells AM führen beim nächsten Einloggen des Benutzers automatisch zu einer entsprechenden Aktualisierung der Anwendung AW.
Um die Anwendungen AW erstellen und nutzen zu können, müssen Server- und clientseitige Operationen ausgeführt werden. Komponenten eines Gesamtsystems aus mindestens einem (Web-) Server und mindestens einem Client sind demgemäß in einem bevorzugten Ausführungsbeispiel:
- Serverseitig:
o Datenbanken,
o Web-Server,
o Anwendungsplattform und
o Erstellungsmodule (Werkzeuge) für die Erstellung der Modelle sowie
- Clientseitig:
o Browser (in dem Berechnungen über in Java Script realisierte Funktionen ausgeführt werden)
Bei der technischen Umsetzung eines erfindungsgemäßen Verfahrens wird nicht zwangsläufig eine Datenbank benötigt (z.B. zur Ablage von Anwendungsmodellen AM). Es kann auch mit File-Systemen gearbeitet werden, wenn nur XML-Dokumente/ -dateien verwendet werden. Sofern jedoch eine Datenbank zum Einsatz kommt, wird ein nicht- relationaler Datenbank-Server als vorteilhaft erachtet (z.B. eine XML- Datenbank). Dennoch ist auch die Nutzung anderer Datenbank-Technologien grundsätzlich möglich. Je Mandant wird eine eigene Datenbank eingerichtet. Die Datenbanken können beliebig vielen Datenbank-Servern zugeordnet werden. Diese wiederum können völlig unabhängig von der Anwendungsplattform und beliebig verteilt betrieben werden. So ist es unter anderem möglich, nur die Anwendungsplattform zentral (z.B. in der„Cloud") zu betreiben, während die Datenhaltung jeweils lokal erfolgt. Die Anwendungsplattform kann dabei durch das Ansprechen der verschiedenen Datenbanken, in denen die unterschiedlichen Anwendungsmodelle AM liegen, außerdem parallel beliebig viele unterschiedliche Anwendungen bereitstellen.
Bei einer„Cloud"-Lösung auf Basis der Erfindung kann im Übrigen erreicht werden, dass ein Nutzer sein in (individuellen oder individualisierten) Softwareanwendungen liegendes Know-how und seine Daten aus Sicherheitsgründen vor Ort gesichert und somit lokal gespeichert haben kann, ohne dass auf die Vorteile einer zentralen Datenverarbeitung verzichtet werden muss. Die Datenhaltung und die Anwendungsmodelle AM, in der die Geschäfts-/ Anwendungslogik AL der Softwareanwendungen AWA abgebildet ist, können beliebig, d.h. auch auf lokale Ressourcen, verteilt werden.
Bezugszeichenliste
AB-AMSTANDARD Abweichungen vom standardisierten Anwendungsmodell
AKM Anwendungskonfigurationsmodell
AKMSTANDARD Standard-Anwendungskonf igurationsmodell
AKMD Anwendungskonfigurationsmodell-Erstellungsmodul
AL Anwendungslogik
AM Anwendungsmodell
AMD Anwendungsmodellerstellungsvorrichtung
AMR Anwendungsmodellspeicher
AMSTANDARD Standard-Anwendungsmodell
AW (Software-) Anwendung
CA Mandantenverwaltungsvorrichtung
CSD Mandantenspezifische Datenbank
DB Datenbank
DBM Datenbankmodell
DH Datenhaltung
DS Datensätze
FK Funktionsmodul
GUI Benutzeroberfläche
GUI-FK Oberflächenfunktionen
ME Modell-Engine
MM Metamodell
MMSTANDARD Standard-Metamodell
MMD Metamodell-Erstellungsmodul
OB Oberflächenbeschreibung
OM Organisationsmodell
OMD Organisationsmodell-Erstellungsmodul
PL-FK Plattformfunktionen
RD Regel-Erstellungsmodul
RE Regel-Engine
S1 Einrichtung zur automatisierten Erzeugung und Bereitstellung wenigstens einer Softwareanwendung
SYS Systemadministrationsmodul
TS Testwerkzeug
V-AMSTANDARD Verweis auf standardisiertes Anwendungsmodell VW Ansichtsbausteine
WE Workflow-Engine
WFE Workflow-Erstellungsmodul

Claims

Ansprüche
1 . Verfahren zur automatisierten Erzeugung und Bereitstellung wenigstens einer Client-/ Server-basierten Softwareanwendung mit einer Benutzeroberfläche für einen Nutzer, wobei wenigstens das Folgende bereitgestellt wird: eine Anwendungsplattform, in die sich ein Nutzer einloggen kann, mindestens eine mandantenspezifische Datenbank (CSD), in der Daten abgespeichert werden können, zumindest ein in der mandantenspezifischen Datenbank (CSD) gespeichertes Anwendungsmodell (AM) für die Erzeugung der wenigstens einen Softwareanwendung (AW), wobei mit dem Anwendungsmodell (AM) die Funktionsweise der Softwareanwendung (AW), eine Benutzeroberfläche (GUI) und die Datenstruktur maschinell verarbeitbar beschrieben sind, und eine Modell-Engine (ME) auf der Anwendungsplattform für den Zugriff auf Daten der mandantenspezifischen Datenbank (CSD), wobei die Modell-Engine (ME) nach dem Einloggen eines Nutzers das Anwendungsmodell (AM) zur Laufzeit ausliest und erst zur Laufzeit auf Basis des Anwendungsmodells (AM) eine Softwareanwendung (AW) mit Anwendungslogik (AL) und Benutzeroberfläche (GUI) erzeugt, wobei die Anwendungslogik (AL) die von der Softwareanwendung (AW) im Betrieb ausführbaren Prozesse definiert und der Nutzer über die Benutzeroberfläche (GUI) auf Daten aus der mandantenspezifischen Datenbank (CSD) zugreifen kann, und wobei Befehle des Nutzers an der Benutzeroberfläche (GUI) betreffend ein bestimmtes Datenobjekt zur Laufzeit an die Modell-Engine (ME) weitergegeben werden und die Modell-Engine (ME) dem Nutzer unter Rückgriff auf das Anwendungsmodell (AM) und die hieraus zur Laufzeit erstellte Anwendungslogik (AL) einen Zugriff auf zu dem Datenobjekt gehörende Daten aus der mandantenspezifischen Datenbank (CSD) gestattet.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass das
Anwendungsmodell (AM) wenigstens ein Metamodell (MM) und ein Anwendungskonfigurationsmodell (AKM) umfasst, wobei in dem Metamodell (MM) generische Metadatenelemente definiert und zu den Metadatenelementen gehörige Datenfeldstrukturen für die Benutzeroberfläche (GUI), Attribute und/oder Funktionen festgelegt sind, und über das Anwendungskonfigurationsmodell (AKM) das Metamodell (MM) spezifiziert ist und Datenobjekte für die Softwareanwendung (AW) definiert sind, die sich von Metadatenelementen des Metamodells (MM) ableiten, indem in dem Anwendungskonfigurationsmodell (AKM) Metadatenelementen konkrete Rollen für die zur Laufzeit zu erzeugende und bereitzustellende Softwareanwendung (AW) zugewiesen werden.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass das Metamodell (MM) eine Schema-Definition umfasst, die die Metadatenelemente beschreibt, und/oder in dem Anwendungskonfigurationsmodell (AKM) definiert ist, mit welchen Ansichtentypen (Views) ein Metadatenelement dargestellt werden kann.
Verfahren nach einem der Ansprüche 2 bis 3, dadurch gekennzeichnet, dass zur Laufzeit das Metamodell (MM) eingelesen wird sowie zu jedem Metadatenelement einer vorgegebenen Hierarchieebene eine Klasseninstanz eines bestimmten Typs und zu jedem für ein Metadatenelement definierten Metaelement-Attribut ein Attribut erzeugt werden.
Verfahren nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet, dass in dem Anwendungskonfigurationsmodell (AKM) wenigstens festgelegt wird,
- zu welcher Rolle ein Metadatenelement in der Softwareanwendung (AW) ausgeprägt wird, so dass die Funktionalität eines Metadatenelements einem bestimmten Datenobjekt der Softwareanwendung zukommt,
- wie Objektinstanzen eines Datenobjekts auf der Benutzeroberfläche (GUI) dargestellt werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Anwendungsmodell (AM) ein Organisationsmodell (OM) umfasst, in dem wenigstens eine Organisations- und Prozessstruktur der Organisation, innerhalb derer die zur Laufzeit zu erzeugende Softwareanwendung genutzt werden soll, und/oder ein Geschäftsprozess, der mit der zur Laufzeit zu erzeugenden Softwareanwendung abgebildet werden soll, hinterlegt sind.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für den Zugriff eines Nutzers auf einen in der mandantenspezifischen Datenbank (CSD) gespeicherten Satzes von Daten (DS) eines Datenobjekts die Modell-Engine (ME)
- das Anwendungsmodell (AM) ausliest,
- eine Objektinstanz zu dem Datenobjekt in einem Arbeitsspeicher generiert,
- den zu dem Datenobjekt gehörenden Satz von Daten (DS) aus der mandantenspezifischen Datenbank (CSD) ausliest und
- eine Visualisierung der Objektinstanzen in Abhängigkeit von den ausgelesenen Daten an der Benutzeroberfläche (GUI) erzeugt.
8. Verfahren nach einem der vorhergehenden Ansprüche, soweit rückbezogen auf den Anspruch 2, dadurch gekennzeichnet, dass die Modell-Engine (ME)
- ein erstes Verarbeitungsmodul für die Verarbeitung des Metamodells (MM), - ein zweites Verarbeitungsmodul für die Verarbeitung des Anwendungskonfigurationsmodells (AKM) und
- eine übergeordnete Generierungseinheit
umfasst, wobei die übergeordnete Generierungseinheit nach dem Laden des Metamodells (MM) mittels des ersten Verarbeitungsmoduls und nach dem Laden des Anwendungskonfigurationsmodells (AKM) mittels des zweiten Verarbeitungsmoduls in einen Arbeitsspeicher zur Generierung der Softwareanwendung notwendige Informationen von den ersten und zweiten Verarbeitungsmodulen abfragt und zur Laufzeit die Softwareanwendung generiert. 9. Verfahren nach den Ansprüchen 6 und 8, dadurch gekennzeichnet, dass die Modell-Engine (ME) zusätzlich ein drittes Verarbeitungsmodul für die Verarbeitung des Organisationsmodells (OM) umfasst und die übergeordnete Generierungseinheit zusätzlich zur Generierung der Softwareanwendung auch Informationen von dem dritten Verarbeitungsmodul abfragt, nachdem das Organisationsmodell (OM) mittels des dritten Verarbeitungsmoduls in einen Arbeitsspeicher geladen wurde, und zur Laufzeit die Softwareanwendung generiert.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass durch das Anwendungsmodell (AM) bestimmte Funktionen der Softwareanwendung (AW) maschinell lesbar beschrieben sind, die zur Laufzeit ausführbar sind.
1 1 . Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass generische Funktionsbausteine in der Anwendungsplattform implementiert sind, die zur Laufzeit durch das Anwendungsmodell (AM) spezifiziert und konfiguriert werden, um die ausführbaren Funktionen bereitzustellen.
12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mehrere mandantenspezifische Datenbanken (CSD) und/oder mehrere vorkonfigurierte Anwendungsmodelle in einer Datenbank (DB) der Anwendungsplattform hinterlegt sind.
13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens eine mandantenspezifische Datenbank (CSD) und/oder mindestens ein vorkonfiguriertes Anwendungsmodell (AM) in einer lokalen Datenbank (DB) eines Nutzers hinterlegt ist und die Anwendungsplattform durch ein Serversystem bereitgestellt ist.
14. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für unterschiedliche Softwareanwendungen (AM) unterschiedliche Anwendungsmodelle in einer Datenbank (DB) der Anwendungsplattform und/oder einer lokalen Datenbank (DB) eines Nutzers hinterlegt sind, so dass zur Bereitstellung einer von mehreren unterschiedlichen Softwareanwendungen (AM) ein bestimmtes Anwendungsmodell (AM) durch die Modell-Engine (ME) zur Laufzeit ausgelesen wird und eine Benutzeroberfläche (GUI) auf Basis dieses Anwendungsmodells (AM) generiert wird.
15. Computerimplementierte Einrichtung zur automatisierten Erzeugung und Bereitstellung wenigstens einer Client-/ Server-basierten Softwareanwendung mit einer Benutzeroberfläche für einen Nutzer, insbesondere zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 14, wobei die Einrichtung wenigstens das Folgende umfasst: eine Anwendungsplattform, in die sich ein Nutzer einloggen kann, mindestens eine mandantenspezifische Datenbank (CSD), in der Daten abgespeichert werden können, zumindest ein in der mandantenspezifischen Datenbank (CSD) gespeichertes Anwendungsmodell (AM) für die Erzeugung der wenigstens einen Softwareanwendung (AW), wobei mit dem Anwendungsmodell (AM) die Funktionsweise der Softwareanwendung (AW), eine Benutzeroberfläche (GUI) und die Datenstruktur maschinell verarbeitbar beschrieben sind, und eine Modell-Engine (ME) auf der Anwendungsplattform für den Zugriff auf Daten der mandantenspezifischen Datenbank (CSD), wobei das Anwendungsmodell (AM) nach dem Einloggen eines Nutzers zur Laufzeit mittels der Modell-Engine (ME) auslesbar ist und mittels der Modell-Engine (ME) zur Laufzeit auf Basis des Anwendungsmodells (AM) eine Softwareanwendung (AW) erzeugbar ist, die eine Benutzeroberfläche (GUI) beinhaltet, über die der Nutzer auf Daten aus der mandantenspezifischen Datenbank (CSD) zugreifen kann, und wobei die Modell-Engine (ME) derart ausgeführt ist, dass Befehle des Nutzers an der von ihr generierten Benutzeroberfläche (GUI) der Softwareanwendung (AW), die ein bestimmtes Datenobjekt betreffen, zur Laufzeit an die Modell-Engine (ME) weitergegeben werden und die Modell-Engine (ME) dem Nutzer unter Rückgriff auf das Anwendungsmodell (AM) einen Zugriff auf zu dem Datenobjekt gehörende Daten gestattet.
16. Einrichtung nach Anspruch 15, dadurch gekennzeichnet, dass die
Anwendungsplattform eine Steuereinrichtung aufweist, die nach dem Einloggen eines Nutzers das Anwendungsmodell (AM) aus der mandantenspezifischen Datenbank (CSD) in den Arbeitsspeicher eines Rechners lädt, auf dem die Einrichtung installiert ist.
17. Computerprogrammprodukt zum Betreiben eines Rechners, insbesondere eines Webservers, aufweisend maschinenlesbaren Code, der, wenn er auf dem Rechner ausgeführt wird, ausgebildet ist, den Rechner zu veranlassen, ein Verfahren nach einem Ansprüche 1 bis 14 durchzuführen.
18. Maschinenlesbares Speichermedium, aufweisend maschinenlesbaren Programmcode, der ausgestaltet ist, auf einem Rechner, insbesondere einem
Webserver ausgeführt zu werden und den Rechner bei der Ausführung des Programmcodes zu veranlassen, ein Verfahren nach einem Ansprüche 1 bis 14 durchzuführen.
Computerimplementierte Einrichtung zur Erstellung eines
Computerprogrammprodukts nach Anspruch 17, bei dem ein Anwendungsmodell (AM) wenigstens ein Metamodell (MM) und ein Anwendungskonfigurationsmodell (AKM) umfasst, wobei die Einrichtung wenigstens das Folgende aufweist:
- ein erstes Erstellungsmodul (MMD) für die Erstellung eines Metamodells (MM), wobei in dem Metamodell (MM) generische Metadatenelemente definiert und zu den Metadatenelementen gehörige Datenfeldstrukturen für die Benutzeroberfläche (GUI), Attribute und/oder Funktionen festgelegt sind, und
- ein zweites Erstellungsmodul (AKMD) für die Erstellung eines Anwendungskonfigurationsmodell (AKM), wobei über das Anwendungskonfigurationsmodell (AKM) das Metamodell (MM) spezifiziert ist und Datenobjekte für die Softwareanwendung (AW) definiert sind, die sich von Metadatenelementen des Metamodells (MM) ableiten, indem in dem Anwendungskonfigurationsmodell (AKM) Metadatenelementen konkrete Rollen für die zur Laufzeit zu erzeugende und bereitzustellende Softwareanwendung (AW) zugewiesen werden,
wobei wenigstens eines der Erstellungsmodule (MMD, AKMD) mindestens eine grafische Benutzeroberfläche definiert, über die eine Bedienperson ein Metamodell (MM) und/oder ein Anwendungskonfigurationsmodell (AKM) erstellen kann.
20. Einrichtung nach Anspruch 19, dadurch gekennzeichnet, dass das Metamodell (MM) und/oder das Anwendungskonfigurationsmodell (AKM) mindestens ein XML- Dokument umfassen und das erste und/oder zweite Erstellungsmodul (MMD, AKMD) die Erzeugung und/oder Veränderung eines XML-Dokuments gestatten, um das jeweilige Modell (MM, AKM) zu erstellen. 21 . Einrichtung nach Anspruch 19 oder 20, dadurch gekennzeichnet, dass die Einrichtung zusätzlich noch ein drittes Erstellungsmodul (OMD) für die Erstellung eins Organisationsmodells (OM) aufweist, wobei in dem Organisationsmodell (OM) wenigstens eine Organisations- und Prozessstruktur der Organisation, innerhalb derer die zur Laufzeit zu erzeugende Softwareanwendung genutzt werden soll, und/oder ein Geschäftsprozess, der mit der zur Laufzeit zu erzeugenden Softwareanwendung abgebildet werden soll, hinterlegt sind.
22. Einrichtung nach Anspruch 21 , dadurch gekennzeichnet, dass
- über die grafische Benutzeroberfläche eine Bedienperson auch ein Organisationsmodell (OM) erstellen kann und/oder
- das Organisationsmodell (OM) mindestens ein XML-Dokument umfasst und das dritte Erstellungsmodul (OMD) die Erzeugung und/oder Veränderung eines XML- Dokuments gestattet, um das Organisationsmodell (OM) zu erstellen.
PCT/EP2014/070663 2013-09-27 2014-09-26 Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung WO2015044374A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/025,266 US10296305B2 (en) 2013-09-27 2014-09-26 Method and device for the automated production and provision of at least one software application
EP14789530.4A EP3049920A1 (de) 2013-09-27 2014-09-26 Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102013219655 2013-09-27
DE102013219655.5 2013-09-27

Publications (1)

Publication Number Publication Date
WO2015044374A1 true WO2015044374A1 (de) 2015-04-02

Family

ID=51795610

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/070663 WO2015044374A1 (de) 2013-09-27 2014-09-26 Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung

Country Status (3)

Country Link
US (1) US10296305B2 (de)
EP (1) EP3049920A1 (de)
WO (1) WO2015044374A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109683853A (zh) * 2018-12-21 2019-04-26 云南电网有限责任公司电力科学研究院 一种基于建模的软件业务功能定义方法及系统
EP3819798A1 (de) * 2019-11-05 2021-05-12 Service Layers GmbH Verfahren und system zur ausführung eines identity und access management systems

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10956422B2 (en) 2012-12-05 2021-03-23 Oracle International Corporation Integrating event processing with map-reduce
EP3049920A1 (de) * 2013-09-27 2016-08-03 Rudolf Markus Petri Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung
KR102071335B1 (ko) * 2015-06-11 2020-03-02 한국전자통신연구원 워크플로우 모델 생성 방법과 워크플로우 모델 실행 방법 및 장치
US10235191B2 (en) * 2015-12-14 2019-03-19 Sap Se Application specific configurable graphical user interface
US10789250B2 (en) 2016-09-15 2020-09-29 Oracle International Corporation Non-intrusive monitoring output of stages in micro-batch streaming
US11977549B2 (en) 2016-09-15 2024-05-07 Oracle International Corporation Clustering event processing engines
WO2018169430A1 (en) 2017-03-17 2018-09-20 Oracle International Corporation Integrating logic in micro batch based event processing systems
WO2018169429A1 (en) 2017-03-17 2018-09-20 Oracle International Corporation Framework for the deployment of event-based applications
US10467335B2 (en) 2018-02-20 2019-11-05 Dropbox, Inc. Automated outline generation of captured meeting audio in a collaborative document context
US11488602B2 (en) 2018-02-20 2022-11-01 Dropbox, Inc. Meeting transcription using custom lexicons based on document history
CN111694580B (zh) * 2019-03-13 2023-03-10 杭州宏杉科技股份有限公司 存储设备升级及初始化的方法、装置、电子设备
US11689379B2 (en) 2019-06-24 2023-06-27 Dropbox, Inc. Generating customized meeting insights based on user interactions and meeting media
JP6847382B1 (ja) * 2019-09-23 2021-03-24 株式会社デンソークリエイト 設計支援ツール
CN111459588A (zh) * 2020-03-27 2020-07-28 深圳融安网络科技有限公司 大数据模型设置方法、终端设备及计算机可读存储介质
US11307955B2 (en) * 2020-07-02 2022-04-19 Bank Of America Corporation Graphical user interface and analysis system for determining platform stability and resiliency
US11231913B1 (en) * 2020-07-23 2022-01-25 Tracelink, Inc. Model driven user interface

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060248449A1 (en) * 2005-04-29 2006-11-02 Microsoft Corporation XML application framework

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS57133362A (en) 1981-02-10 1982-08-18 Mitsubishi Electric Corp Frequency detector
GB9215320D0 (en) 1992-07-18 1992-09-02 Int Computers Ltd Configuration mechanism for a computer system
FR2694105B1 (fr) 1992-07-22 1994-11-25 Bull Sa Utilisation d'un langage à interprète embarqué pour la réalisation d'un outil interactif de définition d'interface utilisateurs.
DE10008632B4 (de) 2000-02-24 2004-02-26 Gunter Gemmel Verfahren und System zum Erzeugen eines Computerprogramms
US7181740B2 (en) * 2003-03-31 2007-02-20 Sony Corporation Method and system for automated provision of build images
US7694271B2 (en) 2004-02-26 2010-04-06 International Business Machines Corporation Rendering GUI widgets with generic look and feel
DE102006038876A1 (de) 2006-08-18 2008-02-21 Giesecke & Devrient Gmbh Automatisches Erzeugen von lauffähigem Anwendungscode
US20080189679A1 (en) * 2007-02-05 2008-08-07 Jared Rodriguez Method and system for creating, deploying, and utilizing a service
US7934191B2 (en) * 2007-04-10 2011-04-26 Sap Portals IL Method and modules for generating client-server applications
US8418125B2 (en) 2007-05-03 2013-04-09 International Business Machines Corporation Incremental model refinement and transformation in generating commerce applications using a model driven architecture
US8255384B2 (en) * 2009-09-30 2012-08-28 Fujitsu Limited Client-tier validation of dynamic web applications
US8843884B1 (en) * 2009-11-23 2014-09-23 Jason Adam Koerner Interactive graphical construction of parametric components of typical cross section frameworks
US20110137872A1 (en) * 2009-12-04 2011-06-09 International Business Machines Corporation Model-driven data archival system having automated components
US20110145783A1 (en) * 2009-12-16 2011-06-16 Infosys Technologies Limited System and method for representing and validating functional requirements of a software system
US8417798B2 (en) * 2010-05-11 2013-04-09 International Business Machines Corporation Deploying artifacts for packaged software application in cloud computing environment
US8510373B2 (en) * 2010-08-30 2013-08-13 Sap Ag Data synchronization and disablement of dependent data fields
US8516364B2 (en) * 2010-08-30 2013-08-20 Sap Ag View model aspects of component objects
US8356282B1 (en) * 2011-09-13 2013-01-15 Advanced Testing Technologies, Inc. Integrated development environment for the development of electronic signal testing strategies
US8904357B2 (en) * 2012-05-08 2014-12-02 Siemens Aktiengesellschaft Dashboard for architectural governance
US8832662B2 (en) * 2012-05-08 2014-09-09 Siemens Aktiengesellschaft Rules engine for architectural governance
US9038017B2 (en) * 2012-08-23 2015-05-19 Cognizant Technology Solutions India Pvt. Ltd. Method and system for facilitating rapid development of end-to-end software applications
US9411845B2 (en) * 2013-06-13 2016-08-09 Sap Se Integration flow database runtime
EP3049920A1 (de) * 2013-09-27 2016-08-03 Rudolf Markus Petri Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung
WO2017031459A1 (en) * 2015-08-19 2017-02-23 Integrator Software Integrated software development environments, systems, methods, and memory models
IN2015CH05184A (de) * 2015-09-28 2015-10-16 Wipro Ltd

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060248449A1 (en) * 2005-04-29 2006-11-02 Microsoft Corporation XML application framework

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
C-L LAZAR ET AL: "Using a fUML Action Language to Construct UML Models", SYMBOLIC AND NUMERIC ALGORITHMS FOR SCIENTIFIC COMPUTING (SYNASC), 2009 11TH INTERNATIONAL SYMPOSIUM ON, IEEE, PISCATAWAY, NJ, USA, 26 September 2009 (2009-09-26), pages 93 - 101, XP031674013, ISBN: 978-1-4244-5910-0 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109683853A (zh) * 2018-12-21 2019-04-26 云南电网有限责任公司电力科学研究院 一种基于建模的软件业务功能定义方法及系统
EP3819798A1 (de) * 2019-11-05 2021-05-12 Service Layers GmbH Verfahren und system zur ausführung eines identity und access management systems
WO2021089083A1 (de) * 2019-11-05 2021-05-14 Service Layers GmbH Verfahren und system zur ausführung eines identity und access management systems

Also Published As

Publication number Publication date
US20160239272A1 (en) 2016-08-18
US10296305B2 (en) 2019-05-21
EP3049920A1 (de) 2016-08-03

Similar Documents

Publication Publication Date Title
EP3049920A1 (de) Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung
DE10121790B4 (de) Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem
DE10051645B4 (de) Prozesssteuersystem und Verfahren zum Kontrollieren eines Prozesses
DE60311805T2 (de) Erfassung, Zusammenstellung und/oder Visualisierung von strukturellen Merkmalen von Architekturen
DE60131683T2 (de) Verfahren und system zur verwaltung von mehreren netzwerk-betriebsmitteln
DE102007040823A1 (de) Editier- und Berichts-Tool für Grafische Programmiersprachenobjekte
WO2003071455A2 (de) Engineeringverfahren und engineeringsystem für industrielle automatisierungssysteme
WO2015185328A1 (de) Computerimplementiertes verfahren und signalfolge für ein programm zur wiederverwendung von ausführbaren softwarekonfigurationen für softwaresysteme sowie rechneranlage und ein computerprogramm mit programmcode zur durchführung des verfahrens
DE102006046310A1 (de) System zur Erzeugung und zum Betrieb einer Softwareapplikation für medizinische Bildgebung
DE10206903A1 (de) Softwareapplikation, Softwarearchitektur und Verfahren zur Erstellung von Softwareapplikationen, insbesondere für MES-Systeme
DE10244685A1 (de) Produktkonfigurationsverfahren und -system
DE102004043788A1 (de) Programm Generator
DE60019996T2 (de) System zum Koordinieren von Dokumenten und Aufgaben für einen Rechner
EP1202167B1 (de) Verfahren zur modellbasierten objektorientierten Entwicklung von externen Schnittstellen für verteilte Softwaresysteme
DE10215653A1 (de) Verfahren und Anordung zur automatischen Erzeugung von Programmcodeabschnitten sowie ein entsprechendes Computerprogrammprodukt und ein entsprechendes computerlesbares Speichermedium
EP1387260A1 (de) Verfahren und Vorrichtung zur Erzeugung von Software
EP1490762B1 (de) Verfahren, software-produkt und system zur universellen computergestuetzten informationsverarbeitung
EP3355186A1 (de) Erzeugung und ausführung von software-modulen
EP1234231B1 (de) Verfahren zur erzeugung grafischer benutzerschnittstellen für computerprogramme
DE10233971A1 (de) Verfahren und Vorrichtung zur Erzeugung von Software
WO2014131430A1 (de) Verfahren zur modellbasierten softwareentwicklung von programmen mit datenbankzugriff
DE102013006949A1 (de) Verfahren zur Gewährleistung der Funktionsfähigkeit eines technischen Systems im Hinblick auf dessen Konfiguration im Rahmen einer Installation bzw. Beseitigung von Komponenten
EP1926019A1 (de) Datenaustauschverfahren und Steuerverfahren zwischen Softwarebausteinen sowie wiederverwendbare Softwarebausteine
EP3940553A1 (de) Verfahren zum bereitstellen sicherheitsrelevanter daten mittels eines serversystems, serversystem und computerprogrammprodukt
EP1343078A1 (de) System zur Modellierung und Generierung von Softwaregenerierungssystemen

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15025266

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2014789530

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2014789530

Country of ref document: EP