Patent Description:
Users often need to layer a software architecture in processes of software architecture development to separate service complexity, technical complexity, and service content by layering. High intra-layer cohesion and low inter-layer coupling improve reusability of a software architecture and make the software architecture easy to maintain. Because of the foregoing advantages, currently a layered architecture is a popular and widely used architecture mode. In a conventional technology, efficiency of software architecture developers is low in managing layered architectures.

<CIT> discloses a method and apparatus for managing, in a computer system, design of a software system. Various embodiments include receiving an input to the computer system specifying dependency relationships among subsystems of the software system and providing an output from the computer system responsive to the input. A rule is imposed on at least one of the dependency relationships and data for the rule is provided as part of the input.

<CIT> discloses a system to generate an interactive layered visualization of a software system including a storage device to storage a model of the system that defines entities and relationships among entities. The system also includes a visualization tool to generate nodes representing the entities and assign nodes to layers in a set of ordered layers in accordance with rules associated with each layer. A layered layout of the software system is thereby generated and an interactive visualization of the layered layout is rendered for display to the user.

The document by <NPL> defines two dependency related parameters and explores their impact on the results of a layer reconstruction algorithm. The first parameter concerns the types of dependencies between software units included in the algorithm. The second parameter concerns the maximum ratio of allowed back-call dependencies between two software units in different layers. It is shown that these parameters have a big impact.

<CIT> discloses a method for structuring a software implementation with a plurality of modules, for checking whether these modules fit a logical model. In a preparation phase the logical model will be defined and consists of two independent dimensions comprising a technical dimension and a business-driven-dimension. Further, allowed dependencies between the elements of the logical model, namely layers and slices, will be defined. In a subsequent implementation phase the modules of the software implementation will be assigned to the logical model while checking for any violations of the allowed dependencies. After assigning the modules to the logical model the logical model with the assigned modules will be visualised interactively and integrally and the allowed dependencies and any violations of the checked dependencies will be indicated.

This application provides a computer implementation method for software architecture analysis, which improves efficiency of software architecture analysis and management.

The subject-matter for which protection is sought is defined by the appended claims.

A first aspect of this application provides a computer implementation method for software architecture analysis, where the method is implemented by using a computer, and the method includes the following steps:.

An architecture analysis module imports an architecture model, where the architecture model includes a each module is a software code set with a specific function, and plurality of modules, each module includes at least one file, and wherein the importing comprises receiving, by a communication interface of a computer, the architecture model and storing it in a memory of the computer. Each file may call a file of another module. A call between files is also referred to as a call between modules to which the files belong.

The architecture analysis module analyzes files included in the plurality of modules to obtain module call information, where the module call information includes a call relationship between the plurality of modules.

Subsequently, the architecture analysis module obtains an architecture setting by receiving an input by a user, wherein the architecture setting includes a layering rule and a call rule, the layering rule includes set information of a plurality of layers and a module included at each of the plurality of layers, and the call rule includes a call rule between modules located at different layers (inter-layer call rule) and/or a call rule between modules included at each layer (intra-layer call rule).

The architecture analysis module indicates a display driver to generate a layered architecture presentation interface based on the layering rule and the module call information, where in the layered architecture presentation interface, each module is allocated to an area corresponding to a layer including the module.

The architecture analysis module detects the module call information based on the call rule, and displays a detection result by using the layered architecture presentation interface. That is, the architecture analysis module indicates the display driver to display the detection result in the layered architecture presentation interface.

The architecture analysis module is used to analyze the call relationship between the modules, detect a matching degree between the call relationship and the call rule, and visually displays a detection result on an interface, so that efficiency of architecture analysis and architecture management is improved, and difficulty in architecture analysis and architecture management is reduced.

In a possible implementation, after the module call information is obtained, the architecture analysis module further indicates the display driver to generate a module call relationship interface, and displays the call relationship between the modules on the module call relationship interface. The module call relationship interface is shown by using an interface, so that a user can visually obtain a call relationship between the modules in the architecture model, and operation difficulty of architecture analysis is reduced.

In a possible implementation, the set information of the plurality of layers includes a sequence number of each layer; and in the layered architecture presentation interface, a location of each layer is set based on the sequence number of the layer. For example, a layer with a smaller sequence number is lower in the layered architecture presentation interface, or a layer with a larger sequence number is lower in the layered architecture presentation interface.

In a possible implementation, the set information of the plurality of layers further includes an identity ID of each layer, and in the layered architecture presentation interface, the ID of each layer is set in a corresponding area of the layer.

In a possible implementation, the analyzing files included in the plurality of modules to obtain module call information includes: counting a quantity of times that a file included in each module calls a file included in another module, to obtain a quantity of times of calls between the plurality of modules. Counting the quantity of times of calls between the plurality of modules helps effectively manage calls between the modules.

In a possible implementation, the quantity of times of calls between the plurality of modules is displayed in the layered architecture presentation interface. The quantity of times of calls between the plurality of modules is displayed in a visual manner, thereby implementing better management of calls between the modules.

Further, the quantity of times of calls between the modules is also displayed in the interface, so that a user can obtain an analysis result of the architecture more intuitively and quickly, thereby improving efficiency of subsequent architecture management.

In a possible implementation, the call relationship between the plurality of modules is displayed by using an arrow in the layered architecture presentation interface. Then, the displaying a detection result by using the layered architecture presentation interface includes: changing, in the layered architecture presentation interface, a color and/or a format of an arrow corresponding to a call that is between modules and that violates the call rule. In this case, if the module call information further includes the quantity of times of calls between the plurality of modules, the quantity of times of calls may be displayed above the arrow.

The call relationship between the modules is shown by using a visual graph, so that readability of an architecture analysis result is further improved, and complexity in architecture analysis and management is reduced.

In a possible implementation, the call rule between modules located at different layers includes any one or more of the following: an adjacent-layer call rule, a cross-layer call rule, and a reverse call rule.

The adjacent-layer call rule indicates whether a call between modules at layers with adjacent layer sequence numbers is allowed. The cross-layer call rule indicates whether a call between modules at layers with non-adjacent layer sequence numbers is allowed. The reverse call rule indicates whether a module at a lower layer in the software architecture calls a module at an upper layer in the software architecture is allowed. In addition, the intra-layer call rule indicates whether a call between modules at a same layer is allowed.

A call rule is generally formulated by a user based on a requirement of a software architecture design. By using the method provided in this application, the user may see, in a detection result, a degree of compliance between the architecture model and the design requirement, so as to subsequently improve the architecture model.

In a possible implementation, the architecture analysis module may further detect a loop call, and display a detection result of the loop call by using the layered architecture presentation interface. An inter-module loop call indicates that one module is called by another module called by the module.

In a possible implementation, in the layered architecture presentation interface, colors of areas corresponding to adjacent layers are different.

In a possible implementation, in the layered architecture presentation interface, textures of areas corresponding to adjacent layers are different.

Different presentation manners (colors and/or textures) are used for areas corresponding to adjacent layers, so that the user can distinguish between different areas in the interface more conveniently, and efficiency of architecture management is improved.

A second aspect of this application provides a software architecture analysis apparatus, including: a module analysis unit, an architecture design unit, and a rule detection unit.

The module analysis unit is configured to import an architecture model, where the architecture model each module is a software code set with a specific function, and includes a plurality of modules, each module includes at least one file, and wherein the importing comprises receiving, by a communication interface of a computer, the architecture model and storing it in a memory of the computer; and analyze files included in the plurality of modules to obtain module call information, where the module call information includes a call relationship between the plurality of modules.

The architecture design unit is configured to obtain an architecture setting by receiving an input by a user, wherein the architecture setting includes a layering rule and a call rule, the layering rule includes set information of a plurality of layers and a module included at each of the plurality of layers, and the call rule includes a call rule between modules located at different layers and/or a call rule between modules included at each layer; and indicate a display driver to generate a layered architecture presentation interface based on the layering rule and the module call information, where in the layered architecture presentation interface, each module is allocated to an area corresponding to a layer including the module.

The rule detection unit is configured to detect the module call information based on the call rule, and display a detection result by using the layered architecture presentation interface. The rule detection unit indicates, based on the detection result, a display driver to display the detection result in the layered architecture presentation interface.

In a possible implementation, the set information of the plurality of layers includes a sequence number of each layer; and in the layered architecture presentation interface, a location of each layer is set based on the sequence number of the layer.

In a possible implementation, the module analysis unit is configured to count a quantity of times that a file included in each module calls a file included in another module, to obtain a quantity of times of calls between the plurality of modules.

In a possible implementation, the quantity of times of calls between the plurality of modules is displayed in the layered architecture presentation interface.

The module analysis unit is configured to count a quantity of times that a file included in each module calls a file included in another module, to obtain a quantity of times of calls between the plurality of modules.

In a possible implementation, the call relationship between the plurality of modules is displayed by using an arrow in the layered architecture presentation interface.

In a possible implementation, the rule detection unit is further configured to indicate the display driver to change, in the layered architecture presentation interface, a color and/or a format of an arrow corresponding to a call that is between modules and that violates the call rule.

The second aspect and the possible implementations of the second aspect correspond to the first aspect and the possible implementations of the first aspect. Therefore, technical effects of the second aspect and the possible implementations of the second aspect are not described herein again.

A third aspect of this application provides a computer system, including at least one computer, where each computer includes a processor and a memory. The processor of the at least one computer is configured to access instructions in the memory of the at least one computer to perform the method provided in the first aspect and the possible implementations of the first aspect.

A fourth aspect of this application provides a non-transient computer-readable storage medium. When instructions stored in the non-transient readable storage medium are executed by a computer system, the computer system performs the method provided in the first aspect and the possible implementations of the first aspect. The storage medium stores program instructions. The storage medium includes but is not limited to a volatile memory, for example, a random access memory, and a nonvolatile memory, for example, a flash memory, a hard disk drive (hard disk drive, HDD), and a solid-state drive (solid-state drive, SSD).

A fifth aspect of this application provides a computer program product. When instructions included in the computer program product are executed by a computer system, the computer system performs the method provided in the first aspect and the possible implementations of the first aspect. The computer program product may be a software installation package. In a case in which the method provided in the first aspect and the possible implementations of the first aspect needs to be used, the computer program product may be downloaded, and instructions included in the computer program product may be executed on the computer system.

To describe the technical method in embodiments of this application more clearly, the following briefly describes the accompanying drawings for describing the embodiments.

The following describes the technical method in embodiments of this application with reference to the accompanying drawings in embodiments of this application.

Referring to <FIG>, a software architecture analysis system <NUM> provided in this application includes an input/output (input output, IO) driver <NUM>, a display driver <NUM>, and an architecture analysis apparatus <NUM>. The architecture analysis apparatus <NUM> includes a module analysis unit <NUM>, an architecture design unit <NUM>, a rule detection unit <NUM>, and a report generation unit <NUM>. The foregoing apparatuses and units may be software apparatuses/units, and functions of the apparatuses and units are implemented by using software instructions. The I/O driver <NUM> is configured to manage an I/O device of a computer, and receive, by using the I/O device, various types of information input by a user. The display driver <NUM> has a capability of rendering an interface based on various types of information and controlling a display device to display a rendering result.

Further, each apparatus in the software architecture analysis system <NUM> has two deployment manners. In a first deployment manner, the I/O driver <NUM>, the display driver <NUM>, and the architecture analysis apparatus <NUM> are all deployed on a same computer. In the first deployment manner, the software analysis system <NUM> is generally provided as a software analysis tool for a user, and the user deploys the entire software architecture analysis system <NUM> on a local computer.

In a second deployment manner, in a computer system provided in <FIG>, an I/O driver <NUM> and a display driver <NUM> are deployed in each computer <NUM>, and an architecture analysis apparatus <NUM> is deployed in a cluster of computers <NUM>. The computer <NUM> is connected to the cluster of computers <NUM> by using a communication network. The computer <NUM> is a user-side computer, and the cluster of computers <NUM> is a remote computer. The computer may be, for example, a smartphone (smart phone), a personal digital assistant (personal digital assistant, PDA), a tablet computer, a laptop computer (laptop computer), a personal computer (personal computer, PC), or a server. The communication network may be a wired communication network, or a wireless communication network, for example, a <NUM>th generation (<NUM>th Generation, <NUM>) mobile communication technology system, a long term evolution (long term evolution, LTE) system, or wireless fidelity (wireless fidelity, Wi-Fi).

In the second deployment manner, each computer <NUM> may be deployed with the module analysis unit <NUM>, the architecture design unit <NUM>, the rule detection unit <NUM>, and the report generation unit <NUM>. Alternatively, some of the module analysis unit <NUM>, the architecture design unit <NUM>, the rule detection unit <NUM>, and the report generation unit <NUM> are deployed in each computer <NUM>, and all units of the architecture analysis apparatus <NUM> are deployed in the cluster of computers <NUM>. The cluster of computers <NUM> as a whole provides a function of the architecture analysis apparatus <NUM> for the user-side computer <NUM>. In this case, the architecture analysis apparatus <NUM> runs on a plurality of computers <NUM> in a distributed mode, providing an architecture analysis service with higher performance. In the second deployment manner, an architecture analysis service is generally provided as a remote service, for example, a cloud service, for a user to use. The user can obtain the architecture analysis service by only deploying the I/O driver <NUM> and the display driver <NUM> on a local computer. The I/O driver <NUM> and the display driver <NUM> are parts of a client of the architecture analysis service.

A software architecture analysis method is described below with reference to <FIG>.

Step <NUM>: An I/O driver <NUM> receives an architecture model input by a user, and sends the architecture model to a module analysis unit <NUM>. The architecture model includes software architecture-related information generated in a software development process. The architecture model includes a plurality of modules of a software architecture, where a file included in each module records a call by the file to a file in another module.

A module is a software code set with a specific function, such as a component (component)/a service (service). For example, the component may be an independent entity that is logically divided in the C/C++ language, and a file included in the component may be a. so file, a. dll file, or the like. The service refers to a module that can be independently deployed and run in a service-oriented scenario. Services coordinate and cooperate with each other to provide a logical service function for a user. Each service runs in its own independent process, and services collaborate with each other by using a lightweight communication mechanism (usually a RESTful API based on an HTTP protocol).

Each module includes at least one file. A file included in one module may call a file in another module. For example, a module A includes header files, such as math. h and stdio. h, and a file of a module B calls both of the header files. For example, the files stdio. h and math. h are called by the file of the module B by using instructions "#include <stdio. h>" and "#include <math. In this case, it is considered that the file in the module B calls the file in the module A two times, and it is also considered that the module B calls the module A two times. In the following figures, a call by the module B to the module A is indicated by an arrow from the module B to the module A. One module may include one or more files, and each file may call one or more files in another module. Therefore, one module may call another module once or more times. A module analysis unit <NUM> counts a quantity of times that a file included in each module calls a file included in another module, to obtain a quantity of times of calls between a plurality of modules. For example, if the module B includes <NUM> files, and each of the <NUM> files calls the files math. h and stdio. h, the module B calls the module A for <NUM> times. In the following figures, a number above an arrow that presents a call by the module B to the module A indicates a quantity of times that the module B calls the module A.

Step <NUM>: The module analysis unit <NUM> imports the architecture model, analyzes the architecture model, and obtains module call information in the architecture model, where the module call information includes a call relationship between modules.

Optionally, the module call information further includes a quantity of times of calls between modules.

After step <NUM>, optionally, step <NUM> and step <NUM> may be performed.

Step <NUM>: The module analysis unit <NUM> generates the module call information based on an analysis result in step <NUM>, and sends the module call information to a display driver <NUM>.

Step <NUM>: The display driver <NUM> generates a module call information presentation interface based on the module call information, and displays the module call information presentation interface on a display device of a computer <NUM>.

As shown in <FIG>, in the module call information presentation interface, the call relationship between modules is displayed by using an arrow. A call relationship between a module <NUM> and a module <NUM> in the figure is used as an example. An arrow (an arrow points from the module <NUM> to the module <NUM>) is provided between the module <NUM> and the module <NUM>, and a quantity of times of calls is marked as <NUM>. This indicates that the module <NUM> calls the module <NUM> for <NUM> times in total.

Optionally, when the analysis result obtained by the module analysis unit <NUM> in step <NUM> further includes the quantity of times of calls between modules, the quantity of times of calls between the modules is further displayed by using a number above an arrow in the module call information presentation interface.

After the module call information is obtained by using the module analysis unit <NUM>, the module call information is displayed to the user through the interface, thereby improving understanding of the architecture model by the user and reducing costs of analyzing a software architecture for the user.

Step <NUM>: The I/O driver <NUM> receives an architecture setting input by the user, and sends the architecture setting to an architecture design unit <NUM>.

To further manage modules, the user needs to perform layered management on the modules included in the architecture model. Generally, functions of modules included at each layer are similar, and a set of modules at each layer implements a logical function for the user.

A common layering method includes a four-layer architecture, including a representation layer, an application layer, a business logic layer, and a persistence layer. The representation (user interface, UI) layer is used to receive a request of the user, return data to the user, and provide an interactive operation interface for the user. The application layer (also referred to as a service layer) is used to decouple the representation layer from the business logic layer. The business logic (business logic, BL) layer (also referred to as a domain layer) is used to embody a user request, that is, parse the user request into a specific operation at a data access layer. The data access (data access, DA) layer (also referred to as a persistence layer) is used to perform the specific operation parsed out by the business logic layer. As the bottom layer of the architecture, the data access layer generally includes modules such as a database and a file system.

Another common layering method includes a three-layer architecture, including a data access layer, a business logic layer, and a representation layer. In the following figures, a three-layer architecture is used for presentation. The business logic layer in the three-layer architecture may be formed by combining the application layer and the business logic layer in the four-layer architecture.

There is a plurality of architecture layering methods in practice. A total quantity of layers, a layer sequence number, a layer identity (identity, ID), and a function of each layer can be changed based on different service requirements and user design habits.

The architecture setting includes a layering rule and a call rule that are included in the architecture model imported to the architecture analysis apparatus <NUM> in step <NUM>. The layering rule includes set information of a plurality of layers, for example, a layer sequence number, a layer ID, and a module included at each of the plurality of layers.

A layer sequence number of a layer is used to indicate a location of the layer in the software architecture. The architecture analysis apparatus <NUM> sets a location of each layer in the layered architecture presentation interface based on the layer sequence number. For example, a sequence number of the UI layer is <NUM>, a sequence number of the BL layer is <NUM>, and a sequence number of the DA layer is <NUM>. Under this numbering rule, a layer with a larger layer sequence number is closer to the user, and a layer with a smaller layer sequence number is farther away from the user and closer to the bottom layer. For another example, a sequence number of the UI layer is <NUM>, a sequence number of the BL layer is <NUM>, and a sequence number of the DA layer is <NUM>. Under this numbering rule, a layer with a smaller layer sequence number is closer to the user, and a layer with a larger layer sequence number is farther away from the user and closer to the bottom layer. For example, the former numbering rule is used below. Under the layering rule, the modules included at each layer are used to allocate the modules included in the architecture model obtained in step <NUM> to the layers. Generally, a layer ID and modules included at each layer are correspondingly recorded in an architecture setting, for example, layer ID <NUM>: module <NUM>/ module <NUM>/ module <NUM>, which indicates that a layer whose ID is <NUM> includes the module <NUM>, the module <NUM>, and the module <NUM>.

The call rule includes a call rule between modules located at different layers and/or a call rule between modules included at each layer. The call rule between modules included at each layer is also referred to as an intra-layer call rule. The call rule between modules of different layers can be any or more of the following: an adjacent-layer call rule, a cross-layer call rule, and a reverse call rule. Based on an actual design requirement of the software architecture, the call rule may further include another rule that indicates a call between modules at a same layer/different layers. The intra-layer call rule indicates whether a call between modules at a same layer is allowed. The adjacent-layer call rule indicates whether a call between modules at layers with adjacent layer sequence numbers is allowed. The cross-layer call rule indicates whether a call between modules at layers with non-adjacent layer sequence numbers is allowed. The reverse call rule indicates whether a module at a lower layer in the software architecture calls a module at an upper layer in the software architecture is allowed. Under the foregoing former numbering rule, a sequence number of a lower layer in the software architecture is smaller.

In an implementation, the user may use the I/O driver <NUM> to send an instruction that carries the architecture setting to the architecture design unit <NUM>, for example, an application programming interface (application programming interface, API) instruction.

As shown in <FIG>, in another implementation, the architecture design unit <NUM> indicates the display driver <NUM> to generate an architecture setting interface. In the architecture setting interface, the user can enter an architecture setting by editing a visual interface, so that the user can quickly set a layer sequence number, a layer ID, a module included at each layer, and a call rule. For example, if the user taps the "+" symbol in a layer sequence number column of the architecture setting interface, the architecture setting interface will automatically generate a row of configuration corresponding to a next layer sequence number. In a row corresponding to each layer sequence number, the customer can enter a layer ID and a call rule. Further, after the user taps a layer ID, a module configuration sub-interface will pop up in the architecture setting interface. In the module configuration sub-interface, the user may map each module imported in step <NUM> to a layer ID. Therefore, the user can configure the module included at each layer by using the module configuration sub-interface.

In <FIG>, the user has set the DA layer, the BL layer, and the UI layer, and their layer sequence numbers are respectively <NUM>, <NUM>, and <NUM>. Call rules of the DA layer are as follows: an intra-layer call is not allowed, an adjacent-layer call is allowed, a cross-layer call is not allowed, and a reverse call is not allowed. Call rules of the BL layer are as follows: an intra-layer call is allowed, an adjacent-layer call is allowed, and a reverse call is not allowed. Because the software architecture has only three layers, there is no possibility of a cross-layer call at the BL layer. Therefore, the cross-layer call column corresponding to the BL layer is Null (null). Call rules of the UI layer are as follows: an intra-layer call is allowed, an adjacent-layer call is allowed, and a cross-layer call is not allowed. Because the UI layer is the top layer in the software architecture, there is no possibility of a reverse call to a higher layer. Therefore, the reverse call column corresponding to the UI layer is Null.

In <FIG>, after the user taps BL in the layer ID column, the module configuration sub-interface of the BL layer is entered. In the module configuration sub-interface, it can be seen that some modules have been allocated to the UI layer and the DA layer. Therefore, the user can allocate the remaining modules to the BL layer. A specific allocation method may be filling BL in a layer ID corresponding to a module ID. In the following instance, architecture modules include modules <NUM> to <NUM>, where the UI layer includes the module <NUM>, the module <NUM>, and the module <NUM>, the BL layer includes the module <NUM>, the module <NUM>, and the module <NUM>, and the DA layer includes the module <NUM>, the module <NUM>, and the module <NUM>.

Step <NUM>: The architecture design unit <NUM> indicates, based on the module call information and a layering rule, the display driver <NUM> to generate a layered architecture presentation interface.

In the layered architecture presentation interface, areas corresponding to different layers are divided based on the layer sequence number and the layer ID. The module included at each layer is set in an area of the layer. Generally, a location of an area corresponding to a layer that is closer to the user is higher in the layered architecture presentation interface. As shown in <FIG>, a layered architecture presentation interface includes a UI layer area, a BL layer area, and a DA layer area. Deployment locations of the modules in <FIG> are re-deployed based on modules included at each layer in an architecture setting, and a call relationship between modules and a quantity of times of calls between the modules in <FIG> are inherited in <FIG>.

Optionally, different colors may be used to represent adjacent layer areas (not shown in the figure). A same color may be used to represent non-adjacent layer areas (not shown in the figure). Different colors are used to represent areas corresponding to adjacent layers, so as to improve user experience and help the user to distinguish between different layer areas.

Optionally, different background textures may be used to represent adjacent layer areas (not shown in the figure). A same background texture may be used to represent non-adjacent layer areas (not shown in the figure). Different background textures are used to represent adjacent layer areas, so as to improve user experience and help the user to distinguish between different layer areas.

Optionally, a blank area may be included between the adjacent layer areas, so as to help the user to distinguish between different layer areas.

The foregoing manners in which a color, a texture, and a blank area are used to represent different areas in the layered architecture presentation interface may be combined at random, and any one of the color, the texture, and the blank area may be used independently, or any two or three of the color, the texture, and the blank area may be used in combination.

The layered architecture presentation interface further includes an operation area, and the operation area includes at least one operation entry. The operation entry includes one or more of the following: "violation call" and "report generation". When the user taps different operation entries, a rule detection unit <NUM> is triggered to perform different actions.

Further, because a user that analyzes the software architecture may be interested in a loop call between modules, a loop call operation entry may be provided in the operation area. The loop call between modules indicates that one module is called by another module that is called by the module, that is, each of the two modules includes a file that is called by the other module, so that a loop is formed. The module call relationship presentation interface in <FIG> is used as an example. The module <NUM> and the module <NUM> call each other, that is, each of the module <NUM> and the module <NUM> includes a file called by the other module, so that a loop call is formed between the module <NUM> and the module <NUM>.

Step <NUM>: The rule detection unit <NUM> detects the module call information based on different operation entries tapped by the user in the operation area of the layered architecture presentation interface, and indicates the display driver <NUM> to provide a detection result to the user.

Optionally, as shown in <FIG>, if the user taps the loop call in the configuration area, the rule detection unit <NUM> detects, based on the module call information, whether a loop call exists between two modules. If a loop call exists between two modules, the display driver <NUM> is indicated to display the detection result in the layered architecture presentation interface. For example, a dialog box pops up in the layered architecture presentation interface, and IDs of modules that have a loop call are displayed in the dialog box. For another example, colors of modules that have a loop call are changed in the layered architecture presentation interface. For another example, a color of an arrow between modules that have a loop call is changed in the layered architecture presentation interface. For another example, a format of an arrow between modules that have a loop call is changed in the layered architecture presentation interface, for example, changed from a solid line to a dashed line. In <FIG>, because a loop call exists between the module <NUM> and the module <NUM>, after the user taps "loop call", an arrow between the module <NUM> and the module <NUM> changes from a solid line to a dashed line.

Optionally, as shown in <FIG>, if the user taps "violation call" in the configuration area, the rule detection unit <NUM> detects, based on the module call information, whether a call that does not comply with a call rule exists between two modules. If a call that does not comply with a call rule exists between two modules, the display driver <NUM> is indicated to display the detection result in the layered architecture presentation interface. For example, a dialog box pops up in the layered architecture presentation interface, and IDs of modules that have a call that does not comply with a call rule and a specific call rule that is not complied with are displayed in the dialog box. For another example, colors of modules that have a call that does not comply with a call rule are changed in the layered architecture presentation interface. For another example, a color of an arrow between modules that have a call that does not comply with a call rule is changed in the layered architecture presentation interface. For another example, a format of an arrow between modules that have a call that does not comply with a call rule is changed in the layered architecture presentation interface, for example, changed from a solid line to a dashed line. A person skilled in the art may understand that displaying a call that does not comply with a call rule in the layered architecture presentation interface may be further implemented by using a combination of the foregoing different examples. In addition, there may be another equivalent implementation other than the foregoing examples.

In <FIG>, a call by the module <NUM> to the module <NUM> does not comply with the call rule of the BL layer that a reverse call is not allowed. Therefore, after the user taps "violation call", an arrow of the call by the module <NUM> to the module <NUM> is changed from a solid line to a dashed line. A call by the module <NUM> to the module <NUM> does not comply with the call rule of the BL layer that a reverse call is not allowed. Therefore, after the user taps "violation call", an arrow of the call by the module <NUM> to the module <NUM> is changed from a solid line to a dashed line. A call by the module <NUM> to the module <NUM> does not comply with the call rule of the UI layer that a cross-layer call is not allowed. Therefore, after the user taps "violation call", an arrow of the call by the module <NUM> to the module <NUM> is changed from a solid line to a dashed line. A call by the module <NUM> to the module <NUM> does not comply with the call rule of the UI layer that a cross-layer call is not allowed. Therefore, after the user taps "violation call", an arrow of the call by module <NUM> to module <NUM> is changed from a solid line to a dashed line. A call by the module <NUM> to the module <NUM> does not comply with the call rule of the DA layer that an intra-layer call is not allowed. Therefore, after the user taps "violation call", an arrow of the call by module <NUM> to module <NUM> is changed from a solid line to a dashed line.

The foregoing manner of displaying the detection result in the layered architecture presentation interface is merely an example. In a specific implementation, the detection result may be provided to the user in another manner.

Optionally, if the user taps "report generation" in the configuration area, the rule detection unit <NUM> indicates, based on the module call information and the call rule, the display driver <NUM> to generate a detection report and provides the detection report to the user. The detection report may include any one or more of the following: module call information, a detection result of a loop call, a detection result of a violation call, and a modification suggestion for a call relationship between modules.

After step <NUM>, step <NUM> and step <NUM> may be first performed, and then step <NUM> to step <NUM> are performed. That is, the module call information presentation interface is first displayed to the user, and then the layered architecture presentation interface is displayed to the user. After step <NUM>, step <NUM> to step <NUM> may be directly performed without performing step <NUM> and step <NUM>. That is, the module call information presentation interface does not need to be displayed to the user; and the architecture setting is directly obtained, and then the layered architecture presentation interface is displayed to the user based on the architecture setting.

The modules are layered and displayed in different layer areas by using the layered architecture presentation interface, and the detection result of the call rule is also displayed to a user through the interface, so that the user can intuitively obtain a difference between the architecture model and the architecture setting, costs for the user to analyze a software architecture are reduced and an updating speed for an architecture module is improved.

After step <NUM>, the user may clearly learn of, by using the detection result, a conflict between the architecture model developed by the user and both of the call rule and module layering designed by the user, and may further modify the architecture model based on the detection result. Further, the user may re-input a modified architecture model into the module analysis unit <NUM> by using the I/O driver <NUM>, so as to re-perform the software architecture analysis method provided in <FIG> on the modified architecture model, to further determine whether the modified architecture module conforms to the user design. In this case, an architecture analysis apparatus <NUM> may simultaneously provide the user with a module call information presentation interface and an analysis architecture presentation interface that are corresponding to the architecture model before being modified and a module call information presentation interface and an analysis architecture presentation interface that are corresponding to the architecture model after being modified.

<FIG> provides a computer <NUM>. At least one computer <NUM> provided in <FIG> is deployed in the computer system. The computer <NUM> is applied to the first deployment manner described above. The computer <NUM> includes a bus <NUM>, a processor <NUM>, a communication interface <NUM>, a display device <NUM>, and a memory <NUM>. The processor <NUM>, the memory <NUM>, the display device <NUM>, and the communication interface <NUM> communicate with each other by using the bus <NUM>. The communication interface <NUM> is configured to communicate with the outside, for example, receive an architecture model and an architecture setting, and store the architecture model in the memory <NUM>.

The processor <NUM> may be implemented by using a general-purpose central processing unit (English: central processing unit, CPU for short), a field programmable gate array (Field Programmable Gate Array, FPGA), or another programmable logic device. The memory <NUM> may include a volatile memory (English: volatile memory), for example, a random access memory (English: random access memory, RAM for short). The memory <NUM> may further include a non-volatile memory (English: non-volatile memory), for example, a read-only memory (English: read-only memory, ROM for short), a flash memory, an HDD, or an SSD.

The memory <NUM> stores executable instructions, and the processor <NUM> executes the executable instructions to perform the software architecture analysis method provided in <FIG> described above. Specifically, the memory <NUM> stores executable instructions to run the I/O driver <NUM>, the display driver <NUM>, the architecture analysis apparatus <NUM>, and the units thereof. The memory <NUM> may further include executable instructions required to run an operating system of the computer <NUM>. The operating system may be Linux™, Unix™, Windows™, or the like.

The display device <NUM> may be a display, configured to provide various interfaces to a user. The computer <NUM> may further include various I/O devices for receiving architecture settings. The I/O driver <NUM> is a driver of the I/O device. The display driver <NUM> is a driver of the display device <NUM>.

<FIG>, and <FIG> provide a computer system. The computer system is used in the foregoing second deployment manner described above. The computer system includes at least one computer <NUM> and at least one computer <NUM>. The computer <NUM> and the computer <NUM> are connected through a communication network.

A hardware structure of the computer <NUM> in <FIG> is similar to that in <FIG>. A difference is that only an I/O driver <NUM> and a display driver <NUM> are run in the computer <NUM> in <FIG>. In other words, a memory <NUM> in <FIG> stores executable instructions. A processor <NUM> executes the executable instructions to execute a part executed by the I/O driver <NUM> and the display driver <NUM> in the software architecture analysis method provided in <FIG> described above. Specifically, the memory <NUM> stores executable instructions to run the I/O driver <NUM> and the display driver <NUM>. A display device <NUM> of the computer <NUM> in <FIG> may be a display, configured to provide various interfaces to the user. The computer <NUM> may further include various I/O devices for receiving architecture settings. A communication interface <NUM> of the computer <NUM> in <FIG> is configured to communicate with the computer <NUM>.

The computer <NUM> includes a bus <NUM>, a processor <NUM>, a communication interface <NUM>, and a memory <NUM>. The processor <NUM>, the memory <NUM>, and the communication interface <NUM> communicate with each other by using the bus <NUM>. The communication interface <NUM> is configured to communicate with the computer <NUM>, for example, receive an architecture model and an architecture setting that are sent by the I/O driver <NUM>, and send module call information, the architecture setting, and a detection result to the display driver <NUM> of the computer <NUM>, so that the display driver <NUM> generates various interfaces and detection results.

The processor <NUM> may be implemented by using a general-purpose CPU, an FPGA, or another programmable logic device. The memory <NUM> may include a volatile memory or a non-volatile memory. The memory <NUM> stores executable instructions, and the processor <NUM> executes the executable instructions to execute a part executed by the architecture analysis apparatus <NUM> and the unit thereof in the software architecture analysis method provided in <FIG> described above. Specifically, the memory <NUM> stores executable instructions to run the architecture analysis apparatus <NUM> and the unit thereof described above. The memory <NUM> may further include executable instructions required to run an operating system of the computer <NUM>. The operating system may be Linux™, Unix™, Windows™, or the like.

The computer system in <FIG>, and <FIG> may include one or more computers <NUM>. When the computer system includes one computer <NUM>, the computer <NUM> runs all units of the architecture analysis apparatus <NUM>. When the computer system includes a plurality of computers <NUM>, in a deployment manner, each of the computers <NUM> runs all the units of the architecture analysis apparatus <NUM>. In this deployment manner, each computer <NUM> has all functions of the architecture analysis apparatus <NUM>. When there are many computers <NUM>, numerous software architecture analysis tasks may be load-balanced to any computer <NUM>, thereby improving an analysis capacity and analysis efficiency of a software architecture analysis system. Alternatively, when the computer system includes a plurality of computers <NUM>, in another deployment manner, each computer <NUM> runs some units of the architecture analysis apparatus <NUM>, and the plurality of computers <NUM> run all the units of the architecture analysis apparatus <NUM>. In this deployment manner, some units are deployed on each computer <NUM>, and there are fewer types of units running on each computer <NUM>, thereby avoiding conflicts between units of different types, and improving an analysis capacity and analysis efficiency of the software architecture analysis system.

A description of a procedure corresponding to each of the accompanying drawings has a focus. For a part that is not described in detail in a procedure, refer to a related description of another procedure.

Claim 1:
A computer implemented method for software architecture analysis, comprising:
importing (Step <NUM>) an architecture model, wherein the architecture model comprises a plurality of modules, each module is a software code set with a specific function, and each module comprises at least one file, and wherein the importing comprises receiving, by a communication interface of a computer, the architecture model and storing it in a memory of the computer;
analyzing (Step <NUM>) files comprised in the plurality of modules to obtain module call information, wherein the module call information comprises a call relationship between the plurality of modules;
obtaining an architecture setting by receiving an input by a user, wherein the architecture setting comprises a layering rule and a call rule, the layering rule comprises set information of a plurality of layers and a module comprised at each of the plurality of layers, and the call rule comprises a call rule between modules located at different layers and/or a call rule between modules comprised at each layer;
indicating (Step <NUM>) to generate a layered architecture presentation interface based on the layering rule and the module call information, wherein in the layered architecture presentation interface, each module is allocated to an area corresponding to a layer comprising the module; and
detecting (Step <NUM>) the module call information based on the call rule, and displaying a detection result by using the layered architecture presentation interface.