WO2015188851A1

WO2015188851A1 - Tool and method for modularizing a system

Info

Publication number: WO2015188851A1
Application number: PCT/EP2014/062016
Authority: WO
Inventors: Erich Günther; Martin Richard NEUHÄUSSER; Gabor SOVAK
Original assignee: Siemens Aktiengesellschaft
Priority date: 2014-06-10
Filing date: 2014-06-10
Publication date: 2015-12-17

Abstract

A modularization tool (MW) has, inter alia, a component determination apparatus (KE) and a module determination apparatus (ME). The component determination apparatus (KE) is provided for the purpose of determining (140), for each application (f) from a first subset (tm(F)) of applications (f), those components (v) of a system (S) on which a starting component (vs(f)) of the particular application (f) is at least indirectly dependent. The module determination apparatus (ME) is provided for the purpose of determining (150) a first set of components (m) specific to the subset of applications, wherein each component (v) in the first set of components (m) specific to the subset of applications is assigned to each application (f) in the first subset (tm(F)) of applications but is not assigned to each application (f) in another subset (tm(F)) of applications which comprises more applications (f) than the first subset (tm(F)) of applications. A corresponding method (100) for producing a module (m) of a system (S) is also provided.

Description

description

Tool and method for modularizing a system

The invention relates to a modularization tool for modularizing a system. Modularizing can also be called split-up. The system can be described as a graph whose components are nodes of the graph and whose dependencies are directed edges of the graph. In order to focus on the problem to be solved by the present invention and without restricting the generality, it will hereinafter be assumed that the directed graph of the system is contiguous. Otherwise, splitting the directed graph would be at least partially trivial. Arranging a system S as a module is understood here to mean that the system is subdivided without residue into at least two subsystems, wherein graphs which describe the subsystems are in each case connected.

Moreover, the invention relates to a method for generating a module of a system.

Systems (eg software systems) tend to grow in size and grain size over time due to further development and maintenance measures. At some point, the original structure is considered inappropriate for adding functionality that was not envisaged at the time the system (especially its architecture) was designed. The consequence is that new functionalities are added without taking into account the structure of the system. Because the same functionality is realized multiple times at different locations, then the memory requirements are unacceptably large. This also increases the cost of adding functionality quickly and concomitants of adding functionality can only be recognized insufficiently. The maintainability of such a grown system decreases or even becomes impossible. At some point in the life cycle of a complex system Only a few professionals who are trained for the long term, are able to survey internal relationships, dependencies, side effects and original design intentions of the system and plan updates of the system. From then on, it is necessary to revise the existing architecture of the system in order to make the system manageable again.

One approach to overcoming this difficulty is to divide such systems into subsystems (modules) that are largely independent of one another. One goal of such a revision is to modularize the system (i.e., divide it into subsystems) so as to minimize resource requirements.

For example, only one (generally small) real subset of the system components needs to be maintained and / or kept in the limited main memory for execution for the individual concrete use cases of a software system. Software components needed to run an application simultaneously in the main memory of a computer can be packaged in dynamically loadable libraries that are loaded into main memory only upon request.

In one possible application scenario, the resource requirement to be minimized is to minimize the maintenance effort of a system. Instead, depending on the application scenario, the resource requirement to be minimized may be to minimize the storage footprint (e.g., for software components to be kept concurrently in main memory), minimize clumping risk in fulfillment of transfer or transport jobs, minimize required manufacturing capacity, and / or Minimize an energy requirement and / or minimize a computing capacity (for example, on a server farm) exist. The object of the present invention is an optimization task, as it (at least in a similar way) also at risk Distributing risk distribution systems, market analysis systems for modeling a market model, fault analysis systems for finding and analyzing causes of errors, sensitivity analyzes for possible modularisations (eg, cost and / or testability), and diagnostic systems for finding and analyzing causes of disease.

There are tools for static analysis of software code. While the results of these tools for identifying independent software components can be generally exploited in part, they are aimed at enforcing coding standards and at detecting programming errors (for example, detecting access outside a shared space (array-out-of-memory)). bound violation), of a non-defaulted pointer (NULL

dereferences) or an infinite loop.

However, tools are still not known which use a system description as a graph to break a complex system into components. Many known techniques (such as dependency matrices) tend to grow very rapidly in real systems, often resulting in loss of clarity and clarity, and severely restricting the usability and / or benefit of these techniques.

The object of the present invention is to provide a modularization tool and a corresponding method for generating a module of a system with which a cost-effective, error-free modularization of a complex system is possible.

According to the invention, this object is achieved by a modularization tool for modularizing a system, wherein the modularization tool comprises a component detection device for detecting components of a system, a dependency detection device for detecting dependencies between the components, an application subset A determination device for determining a first application subset from a total of applications of the system, a component determination device, and a module determination device. The component determination device is provided for determining for each application from the first application subset of those components of which a startup component of the respective application is at least indirectly dependent. The module discovery device is provided for determining a first application subset specific component set, each component of the first application subset specific component set associated with each application of the first application subset, but not associated with each application with another application subset which contains more applications than the first application subset.

If a first system component (for example a software module) requires, for example, a method or a parameter of a second system component for its execution, the first system component is dependent on the presence and readiness of the second system component (at least on one side). An inverse dependence of the second system component on the first system component is not necessarily required for one thing. The resulting graph is a subgraph that spans the graph of the original system. In the following, we will speak of a dependency 'pointing away' from the first system component if the first system component is dependent on the second system component (this definition being arbitrary).

Accordingly, a method according to the invention for generating a module of a system comprises the following steps. In a first step, a total of components of a system is detected. In a second step, dependencies between the components are recorded. In a third

Step is to set a first application subset of a total of applications of the system. In one The fourth step determines for each application from the first application subset those components of which the start component of the respective application is at least indirectly dependent. In a fifth step, a first application subset specific component set is determined, wherein each component of the first application subsets specific component set of each application is associated with the first application subset, but not associated with each application to a different application subset, the more Applications includes as the first application subset. The second step can be done before the first step. Alternatively or additionally, the third step may be performed before the first or before the second step.

One concept of the invention may be seen as determining an application subset specific component set, wherein each component of the application subset specific component set of each application is associated with a particular subset of a total set of applications, but not each application associated with other applications subset that contains more applications than the first application subset. By having each component of the application subset specific component set of each application of a particular subset of one

Is assigned to the maximum number of applications, only a maximum of a single module is defined and generated for each conceivable combination of applications. This ensures that the individual modules are not impractically small and that the number of modules determined is not unnecessarily large. The latter feature avoids avoidable resource requirements due to unnecessary granularity of the modules (eg, a component number dependent resource requirement and / or increased resources through avoidable load and unload operations). By having no component of the first application subset specific component set of each application associated with a different application subset containing more applications than the first application subset, is achieved that individual modules and their resource requirements are not unnecessarily large. Typically, the launch component is required to run the application on the system. It is also possible that several starting components are provided per application. Typically, but not necessarily, the application-specific launch component of a first application is executed on not every execution of one of the other applications of the total set of applications.

It is useful if the modularization tool has a first tool that is prepared to determine the components of the first application subset-specific component set by executing a recursively nested multiple loop, with the first tool being prepared with each newly discovered component perform a first sub-loop over all dependencies pointing away from the found component to determine all components of the first application-subset-specific component set on which the newly discovered components are dependent. Hereby, the proposed Modularisierungsverfahren by means of a determinate process and with minimal effort is feasible. If a dependency is found in the components already found when finding the application-by-item-specific component set, it is a cyclic dependency that can be ignored for further finding of dependent components.

It is advantageous if the modularization tool has a second tool for mapping the system into a directed graph, wherein each of the components is associated with exactly one node of the directed graph and each direct dependency between pairs of the components is associated with an edge of the directed graph. An illustration of the system in a directed graph leads to a well-understood, proven description of the system (as far as this is even possible with a complex system).

It also has advantages when the modularization tool has a third tool for extracting from the system the first application subset specific component set determined by the modularization tool. As a result, a modularization of a system following a system change can be re-optimized in the short term with little effort and in a timely manner.

It is also preferred if the modularization tool has a start component detection device for selecting at least one application-specific starting component from the quantity of the components for at least one application from the total amount of applications. If an application knows a component that belongs to the application, one or more start components of the application can be found starting from the component by tracing the one-sided dependencies in the opposite direction of the one-sided dependencies. A startup component is a component that does not have a dependency that is directed in the opposite direction of the dependencies. A startup component is thus found when tracing back the one-way dependencies a component is found whose input degree is zero. Optionally, it is also possible to automatically locate all startup components of an application (or all applications) of a system by tracing all one-way dependencies in the opposite direction of one-way dependencies, starting from each component of the application (or all applications of the system).

An independent refinement provides that the modularization tool has an application detection device for detecting a total amount of applications that are to be executable on the system. Effort and time required for a manual determination of applications can be saved if at least a subset of the total amount of Phrases that are to be executable on the system can be determined by means of an application detection device. Based on the description of the system by means of a directed graph, all applications of a system can be determined at least by tracing back all existing directed edges (one-sided dependencies) in the opposite direction. Since, under this condition, each start component is distinguished from all other components in that the input level of the node representing the start component is equal to zero, all start components and thus all applications can be determined by machine.

It is particularly advantageous if the module-determining device is prepared to determine an application-subset-specific component quantity for each non-empty subset of the total amount of applications, wherein each component of the application subset-specific component quantity of each application is assigned to the respective subset of applications but not every application is associated with a different application subset that contains more applications than the first application subset. By determining such an application subset specific component set for each nonempty application subset of the total application set, optimal complete modularization of the system can be achieved.

An application-specific benefit arises when the modularization tool is part of at least one of the following application systems: a load distribution system for distributing transport orders and / or transfer orders and / or production orders and / or energy deliveries and / or computer loads and / or memory loads to available ones Resources; a software development system for modeling a complex system; a market analysis system for modeling a market model; a risk assessment system for modeling risk models;

a fault analysis system for searching and analyzing Error causes; a diagnostic system for finding and analyzing causes of disease.

The invention is explained in more detail with reference to the accompanying drawings, in which:

1 schematically shows a structural design of a modularization tool for modularizing a system,

2 schematically shows a flowchart of a method for

Generating a module of a system,

3 schematically shows a set diagram of sets whose set elements are components of applications of a system,

4 shows schematically an example of a software program in the programming language Java,

5 schematically shows a directed graph for a first

Embodiment,

6 shows schematically an example of a transitive envelope of a first node of a graph, schematically the example of FIG. 6 with a transitive envelope of a second node of the same graph, FIG.

8 schematically shows a sequence of a modularization for the example of FIGS. 6 and 7,

FIG. 9 schematically shows a directed graph containing a

Structure of an embedded controller whose nodes are colored for two applications of the controller,

10 schematically shows a detailed view of the directed graph phen of FIG. 9,

11 shows schematically a flow chart of a method for

Modularizing a system.

The embodiments described in more detail below represent preferred embodiments of the present invention.

The modularization tool MW shown in FIG. 1 for modularizing a system S comprises a component detection device VE, a dependency detection device EE, a component determination device KE and a module determination device ME.

In the following, the capital letters E, F, M and V are used to denote quantities. To denote elements of these sets, corresponding lower case letters e, f, m, and v are used. The letter S denotes a system for executing applications f, wherein the system S comprises a plurality of components v, wherein between the respective two components of multiple pairs of components each one-sided dependence e exists.

A refactoring or modularization M of a system S can be solved by obtaining a directed graph G = (V, E) describing the system S. The components v in V represent functional units. In a software system, these would be, for example, code blocks, functions, classes, libraries, modules, or parameters. The directed edges e in E represent influences between the components v in V. Examples of such one-way dependencies e in software systems are function calls in Java, web service calls in SOA environments or calls to a library of a service-oriented architecture (SOA). A data flow for return or the like is not represented by an edge. It is therefore assumed that no backward directed influence by an edge e (vl, v2) between two components vi and v2 takes place.

The component detection device VE is prepared to determine the components v (nodes of a graph G) of the system S from a system description Sb of the system S. The system description can be, for example, a translatable or executable program system or a machine structure documented in a CAD language (for example, from a transmission) (CAD = Computer Aided Design).

The dependency detection device EE is prepared to determine the one-sided dependencies e (directed edges) between the respective two components of pairs of components v of the system S from a system description Sb of the system S.

The component determination device KE is prepared to determine from the set V of the detected components v and the set E of the detected directed edges e an amount V (f) of components v (f) required for executing an application f , The capital letter V denotes a set of components v. V (f) denotes all components v (f) of a single application f of the system S. The capital letter E denotes a set of one-sided dependencies e. E (f) denotes the set of all one-sided dependencies e (f) between components v (f) of an application f. The capital letter F denotes a set of applications f. Tm (F) denotes a subset (application subset) of a set F of applications f of the system S.

V (F) will denote the union of all sets V (f) of all components v (f) of all applications f of system S (typically V (F) denotes all nodes v of system S). A corresponding notation is also used here for other quantities. For example, TM (F) denotes the set of all subsets tm (F) of applications f. TM (F) So is the power of the set F of applications f. Accordingly, the capital letter M denotes the set of all modules m of the system S. The abbreviation vs (f) designates a start component of a single application f. The component determination device KE requires (as an input also the indication of at least one application-specific start component vs (f)) (to determine an amount V (f) of components v (f) required for executing the application f). Application specific start components vs (f) can be determined manually or by machine by means of a start component detection device SKE. Basically it is possible that all or part of the

Set F of applications f has more than one startup component vs (f) (the set of all startup components vs (f) of an application f may be denoted VS (f)). In this case, to perform the modularization method 100 in a pre-processing step 101, a separate application f can be defined for each start component vs' (f) of an application. If no start-component-specific modularization M 'but only an application-specific modularization M is desired, the start-component-specific modularization M' can be converted into a purely application-specific modularization M in an optional post-processing step 141. For this purpose, for each application subset tm (F), all start component-specific modules are used

m '(tm (F); vs (f)) of the respective application subset tm (F) to a respective application subset specific (but then no more startup component specific) module (m' (tm (F); VS ( f)) -> m (tm (F)).

According to the invention, a modulus m is the set V (tm (F)) of those components v of a particular subset tm (F) (the set F of all applications f) associated with each application f of the particular subset tm (F) minus the Quantity V (TM '(F)) of all components v, which can be used by any application f belongs to one of the other application subsets tm '(F), which contains more applications f than the particular application subset tm (F): m (tm (F): = (tm (F) \ V (TM' (F) ) (Equation 1).

The word 'any' here means that the specified decrease is to be performed for each of the other application subsets tm '(F) that contains more applications f than the particular application subset tm (F).

Correspondingly, a modularization M is defined as the set of all application-subset-specific modules m. The modularization M is not an amount of components v (that is, not equal to V (F)) but an amount whose elements are m (similar to a power set) sets.

If edges e are considered to be properties of components v, the edges for modularization need not be considered as soon as it is clear which components v belong to which functions f.

In a further development, the modularization tool MW has an application subset determination device FTME for the automatic determination of subsets tm (F) of applications.

In an independent development, the modularization tool MW has an application detection device FE for detecting a total quantity F of applications f that are to be executable on the system S.

The method 100 shown in FIG. 2 for generating a module m of a system S comprises the following steps. In a first step 110, a total quantity V of components v of a system S is detected. In a second step 120, one-sided dependencies e between the components v are detected. In a third step 130, a first application Subset tm (F) of a total set F of applications f of the system S. In a fourth step 140, for each application f from a first application subset tm (F) of applications f, those components v are determined from which a start component vs (f) of the respective application f is at least indirectly dependent. In a fifth step 150, a first application subset specific component set m is generated, but each component v (m) is associated with the first application subset specific component set m of each application f of a first application subset tm (F), but not each application f is associated with another applications subset tm '(F) that includes more applications f than the first application subset tm (F). The steps of method 100 may also be performed in a different order. For example, the second step 120 may be performed prior to the first step 110. Alternatively or additionally, it is also possible for the third step 130 to be carried out before the first 110 or before the second 120 steps.

As will be explained in more detail in the following exemplary embodiment, the components v, of which a start component vs (f) of the respective application f is at least indirectly dependent, can be calculated by calculating a transitive envelope E ⁺ around the start component vs (in the fourth step 140). f) are determined on the edge relation E of the graph G.

One possible method for carrying out the fifth step 150 results for the person skilled in the art directly from the above equation. From the fact that the subsets of a finite set (ie the number of elements of a power set) are countable, it follows that a finite fixed point iteration can be used to find all subsets tm (F).

In the following, a method 200 for modularizing software modules m will be described. After the directed graph G has been extracted (eg, by means of a static analysis), the next step is to compute which nodes v are needed for the application f defining the system S. For example, if a software system S incorporated in a servo drive controls a permanent magnet synchronous motor, such a drive would typically have at least the three applications 'speed control', 'brake' and 'control encoder'. Each of these applications f is realized in the software system S of such a drive by means of a (preferably small) set V (f) of components v.

The actual modularization can be started as soon as the application f has been extracted from the input structure of the system S according to its representative components v and the structure of the directed graph G. In this case, the quantity V of the representative components v need not be completely known by each application f. For partial modularization, it suffices to determine transitive envelopes E ⁺ in the directed graph G only around those components v that are considered. Thus, all components v with connections e to those components v that are relevant for a specific application f can be determined automatically. For this purpose, only those components v that are representative of the respective application f need to be specified by a user of the modularization tool MW.

Thereafter, for each application f, the set V (f) of all components v (i.e., nodes) required for the application f is determined. With the modularization method 100, directed graphs G can be divided into directed subgraphs and the system S modularized.

Let G be a directed graph consisting of an ordered pair G = (V, E), where V is a nonempty set of Node v and where E is a set of edges e, with EcVxV. For each individual application f, the sets V (f) should define the relevant v nodes v for each application.

Each set V (f) of an application f is completed along a transitive envelope E ^{+ of} the edge relation E. The transitive envelope E ^{+ of} a two-digit relation E on a set V (f) is given by

(v "v) e £ ⁺ :« «e N ₀ Λ Ξν,, ν ^.,., ν ,,, v, e V: (y,, ν ^, θΊ, v ₂ ), ... ( _vn , v) e E.

A transitive shell E ⁺ (also transitive conclusion of a two-digit relation E is an extension of the two-digit relation E, which contains all indirect pairs e ⁺ = (vi, Vj) in addition to the direct pairs e of the relation (ie edges e) ( and thus is transitive).

In the systems relevant to practice here, the transitive shell E ^{+ is} typically not reflective. For if E ^{+ were} a reflexive transitive envelope E ^* , then this would mean in addition that not only individual, but even without exception all components v of the envelope E ⁺ is dependent on itself. (For example, if the components v (f) are methods, it would mean that not only individual but each of these methods is recursive and recursively used in the system, which is not usually the case .) For a certain application subset tm (F), the corresponding module m is calculated according to the proposed modularization method 100 according to Equation 1.

The modularization M can be determined by first, for each element (ie each application subset tm (F)) of the power set TM (F), the set V (tm (F)) of those components v of the considered application subset tm (F) (the set F of all applications f) is formed, which corresponds to each application f are assigned to the particular subset tm (F) and then removed from this component set V (tm (F)) components v of all those other subsets tm '(F) that contain more applications f than the first application subset, if they are each of the applications f are associated with the respective other subset tm '(F) considered (see Equation 1).

The following first example explained with reference to FIG 3, the proposed modular, when three applications f _LR f _2, f are considered: m ₁₂₃ = (f ₁₎ (f ₂₎ (f ₃₎

m ₁₃ = (F (f ₁ ) F (f ₃ )) \ m ₁₂₃

m ₂₃ = ((f ₂ ) (f ₃ )) \ m ₁₂₃

m ₁ = (f ₁ ) \ ((f ₂ ) u (f ₃ ))

m ₂ = (f ₂ ) \ ((f ₁ ) u (f ₃ ))

m ₃ = (f ₃ ) \ ((f ₁ ) u (f ₂ ))

If, for example, the application f _{x is to be} executed, at least temporarily each of the modules rtii, mi ₂ mi ₃ and mi ₂ 3 must be loaded. The modules m ₂ , m ₂₃ , and m ₃ are not needed for the application fi in the main memory, because they are not required for the execution of the functionality of the application fi.

This modularization method 100 can be carried out completely automatically (at least with the exception of specifying the applications f and their most frequently used nodes v). The modularization method 100 determines how a system S can be split.

In a subsequent step, the system S can be divided according to the modularization M (division) determined by means of the modularization method 100.

The following second example illustrates the proposed modularization when only two applications fi, f _{2 are} considered. Given is the first listing of Java code (the software architecture) shown in FIG 4 with the five methods vi, v2, v3, v4, v5.

Unless all of these methods are always needed in each environment, it is possible to modularize this piece of program code with the proposed modularization method 100. For this purpose, applications f are defined. The information available in this list of applications f may be incomplete because the transitive shell of the selected method 100 is calculated so that the proposed modularization method 100 requires only the knowledge of the starting components vs (f).

In a first step, information about application-related startup components is provided: vs (fi) = vi;

vs (f ₂ ) = v ₃ .

In a next step, the architecture of the system S is mapped into a directed graph G, where the components (nodes v in the directed graph G) are connected with directed edges e, which represent one-sided dependencies on other components (eg, directions of invocation) (see FIG. 5). With the directed graph G, for each application f the transitive envelope E ^{+ of} the node v can be calculated, which the application f needs for its execution (see FIGS. 6 and 7).

In this example, a first set V (fi) of components v (fi) of a first application fi consists of nodes vi, v ₂ , v ₅ , while a second set V (f ₂ ) of components v (f ₂ ) consists of Node v ₃ , v ₄ , v ₅ exists. By combining the sets V (fi), V (f ₂ ), a set M of modules rtii, m ₂ , m _i2 can be determined (see FIG. 8). In two applications fi, f ₂ , typically a first rtii, a second m ₂ and a are formed third mi2 module. The first module rtii contains from the considered set V of vertex v exactly that set m =

V (fi) \ V

of nodes vi, v ₂ needed exclusively for execution of the first application fi. The _second modulus m ₂ contains from the considered set V of vertex v exactly that set V (f ₂ ) \ (F \ f ₂ ) of vertex v ₃ , v ₄ , which only needs execution of the second application f ₂ become. The third module m ₁₂ contains from the considered set V of nodes v exactly that set i ₂ of nodes v ₅ which are required both for executing the first application fi and for executing the second application f _2. M ₁₂ = V ( fi) nV (f ₂ ). For the application fi only all nodes v of the set mi mi ₂ need to be maintained or loaded. For the characteristic f ₂ only every node v the amount m ₂ need to be maintained or loaded to _i2.

In order to gain a better understanding of the proposed modularization method and its use, a modularization method 200 will now be explained as a further exemplary embodiment.

Here, in a first step 210, a system S is identified that needs improvement (ie, a system S grown over time or a system S developed for other conditions than exist today.) Software architecture of software or Embedded Control (embedded Controllers) is an example of a system (grown over decades). An embedded software controller uses different applications created from software packages, which in turn are built from components v, which are core components of such Systems S are.

In a second step 220, required parts of the system S are determined. This example implements an export attached to a data flow process that has already been created. The data can then be in the

GRAPHML file format (the v node as a grain components and edges e as one-sided dependencies), which is a good starting point for using a graph visualization tool.

In a third step 230, the exported data is imported into a graphualization program. This is not necessary because the proposed modularization method 200 can be calculated without any visualization of the graph G. However, a visualization G makes it easier to get an overview of a strong network that the user often encounters in complex systems. 9 shows, from an embedded control, the directed graph G of its components v and the one-sided dependences e existing between its components v. In the representation of the graph G, groups of components v between which there is strong cross-linking are shown more closely side by side (ie with shorter edges e) than components v that do not belong to such a group of components v.

In a fourth step 240, applications f in the problem space are defined and a mapping into a solution space is performed. For this purpose, relevant applications f of the given system S are defined (which have an influence on the modularization M). In some cases of modularization M, the mapping G -> M is already known. In other applications of a modularization M, the mapping G -> M can be worked out by means of expertise (knowledge of the system S to be modularized) from the directed graph G of the problem space. This can be done with the aid of a (preferably interactive) graph visualization tool, with which clusters can be displayed in the directed graph G.

In an optional intermediate step 245, clusters G are visualized in the directed graph and nodes v are searched which can be assigned to a set of applications f. Then edges e are searched, the applications thus determined connect. Then it is attempted to remove these edges e by appropriate measures (for example, weak references, downstream processing). This step may require semi-manual manipulation of the directed graph G by a system architect or other skilled person.

In this example of an embedded controller S, possible components v are details of mechanical design, diagnostic features, or safety functions.

In a fifth step 250, a calculation of the modularization M is performed. For this purpose, a plug-in for the graph visualization tool can be installed, which calculates the modularization M on the basis of given applications f, and the result is displayed graphically and in text form.

An example of a visualization result is shown in FIG. 10, which shows a detail view of the upper left corner of the directed graph G of FIG. 9. Black knots v (rtii) are exclusively used fi. For the module ml we have m ₂ : = V (rtii) = V (fi) \ V (f ₂ ) =

V (fi) \ V

, Plotted nodes v (m ₂ ) belong exclusively to the application f ₂ . For the module m2, m ₂ = V (m ₂ ) =

= V (f ₂ ) \ V (F \ f ₂ ). The hatched nodes v (rtii ₂ ) here belong to an intersection m _i2 of nodes v (mi ₂ ), which can be used for application f2 cjehöirGn (ΓΠ12: = V (m ₁₂ ) = V (fi) nV (f ₂ ). application name; component name

fi; v000311

f ₂ ; v002000

In order to execute the application fi, the component union amount mi mi _{2 is} required. In order to execute the application f ₂ , the component merging amount m ₂ is required by _{i 2} . In a sixth step 260, the result M of the proposed modularization method 200 is provided to developers and system architects, and the calculated modularization M can be realized.

The proposed methods 100, 200 propose a method for optimizing architectures S by reengineering and using incomplete information about applications f.

The method of modularizing a system S may be performed as follows. An existing architecture S with a high degree of crosslinking is loaded as a directed graph G into a graph analysis tool MW. By means of the predefined features f (which have been mapped in node v of the directed graph G) becomes a transitive envelope

E ⁺ (vs (f)) of a starting node vs (f) of each application calculates f. The transitive shell consists of a set of nodes (E ⁺ (vs (f)) = V (E ⁺ (vs (f)).) Then, from the envelopes E ⁺ (vs (f)), complementary and intersections m are formed. These complementary and intersections m describe a modularization M of the architecture S, which meets the objectives of the invention mentioned above.

The present invention is not limited to software systems S. It can also be used to modularize any type of system S (regardless of the type of unilateral dependencies e). An example of modularization M is a system S modeled from different perspectives (e.g., hardware and software perspectives), as is common in the automotive field, where many development goals must be considered. The proposed modularization methods 100, 200 may be helpful in determining boundaries of a subsystem V (f) and to help developers and system architects modularize a system S (ie, minimize the number of one-way dependencies e) and prevent that is a further development of an application f the whole considered system S affects or spreads. This may be particularly helpful to a system architect to keep track of how different parts V (f) of the system S are related to each other. As a result, the system S can be easily divided into modules m for future handling.

The method 200 shown in FIG. 11 for modularizing a system S comprises the following steps. In a first step 210, a system S is identified, which needs improvement. In a second step 220 required component v of the system S are determined. In a third step 230, structural data V, E are imported from the system S into a graph visualization program. In a fourth step 240, applications f of the system S are defined in a problem space and an image is taken in a solution space. In a fifth step 250, a calculation of a modularization M is started. In a sixth step 260, the modularization M calculated by means of the proposed modularization method 200 is provided to a system architect and / or a system developer.

A further development of the proposed modularization tool MW and the proposed method 100, 200 provides that the first application-component-specific component quantity m is determined during a real-time operation of the system S. Independent further development provides that the first application-specific-quantity-specific component quantity m determined by the modularization tool MW is divided out of the system S during real-time operation.

The invention provides a modularization tool MW which comprises inter alia a component determination device KE and a module determination device ME. The component determination device KE is provided for determining 130 for each application f from a first set F of applications f of those components v of the system S that are associated with a start component vs (f) of the respective application f are at least indirectly dependent. The module determination device ME is provided for determining 140 a first application subset-specific component quantity m, each component v (tm (F)) of the first application subset-specific component quantity m of each application f of a first subset tm (F) is associated with a total set F of applications f, but is not associated with each application f of another applications subset tm '(F) that includes more applications f than the first application subset tm (F).

The modularization M is determined by determining transitive envelopes E ⁺ (vs (f)).

The present invention provides a modularization tool MW for modularizing a complex system S and a method 100 for generating a module M of the system S. With the modularization tool MW and the method 100 for generating a module m of a system S, those components v (f) needed for executing an application can be determined. Based on this knowledge, it is possible to maintain only those components v (f) for the care of a particular application f, which may affect the application f. Alternatively or additionally, this knowledge can also be used to dynamically load only those parts of a software system S into a main memory at runtime, which are required for executing the application f to be executed. At the same time, considering the boundary condition that this goal is fulfilled, the largest possible modules m are defined. As a result, an increased demand for resources (for example, by additional loading and unloading of modules m in a main memory), due to an unnecessarily large number of modules m is avoided. LIST OF REFERENCE NUMBERS

AS application system

e dependent dependence; directed edge

E set of directed dependencies; Lot of directed

edge

E ⁺ transitive shell of an amount containing at least one

Starting components has

EE dependency detection device

f application

F amount of applications

FE application detection device

FTME application subset detection device

G directed graph

KE component detection device

m module; Application subset specific component quantity

M amount of modules; modularization

ME module detection device

MW modularization tool

S system

Sb system description

tm (F) Subset of a set of applications

TM (F) set of all subsets of a set of applications v component, parameters; node

vs (f) starting components; Start parameters; starting node

VS (F) Quantity of all start components

V component amount; Set of parameters; node-set

VE component detection device

100 Method for Creating a Module

110 Capture a total amount of components

120 Detecting Dependencies Between Components

130 Setting a First Application Subset 140 Identify components on which the startup component depends

150 Determine a first application subset specific component set

200 Method of Modularizing a System

210 first step

220 second step

230 third step

240 fourth step

245 optional intermediate step

250th step

260 sixth step

Claims

claims

A modularization tool (MW) for modularizing a system (S), the modularization tool (MW) comprising: - a component detection device (VE) for detecting (110) components (v) of the system (S);

a dependency detection device (EE) for detecting (120) dependencies (e) between the components (v);

an application subset determination device (FTME) for determining (130) a first application subset (tm (F)) from a total quantity (F) of applications (f) of the system (S);

a component determining means (KE) for determining (140) for each application (f) from the first application subset (tm (F)) of those components (v) of which a starting component (vs (f)) of the respective ones Application (f) is at least indirectly dependent; and

a module determining device (ME) for determining (150) a first application subset specific

Component set (m), where each component (v) of the first application subset specific component set (m) of each application (f) is associated with the first application subset (tm (F)), but not each application (f) of another Associated with an application subset (tm '(F)) that includes more applications (f) than the first application subset (tm (F)).

2. Modularization tool (MW) according to claim 1, character- ized in that the modularization tool (MW) comprises a first tool which is prepared, the components (v (m)) of the first application-portion-specific component quantity (m) by executing a recursively nested multiple loop, with the first tool being prepared with each newly found one

Component (v) of the first application subset specific component set (m) another subloop across all dependencies pointing away from the found component (v) (e) to determine all the components (v) of the first application-specific component set (m) on which the newly discovered components (v) are dependent.

Modularization tool (MW) according to one of the preceding claims, characterized in that the modularization tool (MW) has a second tool for mapping the system (S) into a directed graph (G), each of the components (v) being exactly one node is associated with the directed graph (G) and any direct dependence (e) between pairs of components (v) is associated with an edge (e) of the directed graph (G).

4. Modularisierungswerkzeug (MW) according to any one of the preceding claims, characterized in that the Modularisierungswerkzeug (MW) a third tool for dividing the determined by the Modularisierungswerkzeug (MW) first application-portion-specific component set (m) from the system ( S).

Modularization tool (MW) according to one of the preceding claims, characterized in that the modularization tool (MW) comprises a starting component detection device (SKE) for selecting at least one application (f) from the total quantity (F) of applications (f) at least an application-specific starting component (vs (f)) from the set (V (F)) of the components (v (F)).

Modularization tool (MW) according to one of the preceding claims, characterized in that the modularization tool (MW) has an application detection device (FE) for detecting a total quantity (F) of applications (f) executable on the system (S) should be.

7. Modularization tool (MW) according to one of the preceding claims, characterized in that the module-determining device (ME) is prepared to each non-empty subset (tm (F)) of the total amount (F) of applications fertilize (f) to determine an application subset specific component set (m), each component (v) associated with the application subset specific component set (m) of each application (f) of the respective application subset (tm (F)) but is not associated with each application (f) of any other application subset (tm '(F)) that includes more applications (f) than the first application subset (tm (F)).

8. Modularisierungswerkzeug (MW) according to one of the preceding claims, characterized in that the Modularisierungswerkzeug (MW) is part of at least one of the following application systems (AS):

a load distribution system for the distribution of transport orders and / or transport orders and / or production orders and / or energy supplies and / or computer loads and / or storage loads to available resources;

a risk distribution system for distribution of transport orders and / or transport orders and / or production orders and / or energy supplies and / or computer loads and / or storage loads to failure areas;

a software development system for modeling a complex system;

a market analysis system for modeling a market model;

a risk assessment system for the modeling of risk models;

an error analysis system for the search and analysis of error causes;

a diagnostic system for the search and analysis of disease causes.

9. Method (100) for generating a module (m) of a system (S), the method (100) comprising the following steps:

Detecting (110) a total amount (V) of components (v) of the system (S); Detecting (120) dependencies (e) between components (v);

Defining (130) a first application subset

(tm (F)) from a total quantity (F) of applications (f) of the system (S);

Determining (140) for each application (f) from the first applications subset (tm (F)) of those components (v) of which the starting component (vs (f)) of the respective application (f) is at least indirectly dependent;

Determining (150) a first application subset specific component set (m), each component (v (m)) of the first application subset specific component set (m) of each application (f) of the first application subset (tm (F )), but not associated with each application (f) of another application subset (tm '(F)) that includes more applications (f) than the first application subset (tm (F)).