WO2003017105A2

WO2003017105A2 - Method for representing the architecture of a software system

Info

Publication number: WO2003017105A2
Application number: PCT/EP2002/008503
Authority: WO
Inventors: Thomas Kohler; Roland Trauter
Original assignee: Daimlerchrysler Ag
Priority date: 2001-08-16
Filing date: 2002-07-31
Publication date: 2003-02-27
Also published as: DE10140124A1; WO2003017105A3

Abstract

The invention relates to a method for producing a representation of the architecture of a software system of which the source program is provided. The software system architecture to be represented describes the structure and the operations of the software system by means of structural elements and the relations between said structural elements. The architecture is automatically determined by means of a data processing system. According to the invention, a plurality of views of the architecture is defined. Once a view has been selected, a primary window of the view and at least one secondary window of the view are produced. A plurality of structural elements is selected on the basis of a pre-determined criterion and is displayed in the primary window of the selected view. A plurality of other structural elements having a defined relationship with a selected structural element displayed in the primary window is displayed in a secondary window of the selected view. By repeatedly selecting a structural element in a secondary window and displaying this structural element in the primary window of a second view, it is possible to navigate through the architecture of the software system.

Description

Method for representing the architecture of a software system

The invention relates to a method for generating a representation of an architecture of a software system.

The source program of the software system in a certain programming language is given, as well as a formal specification of this programming language. The architecture of the software system to be represented describes the structure and processes of the software system through structure elements, through the dependencies, relations and interactions between these structure elements as well as through the properties of the structure elements that are visible from the outside. Structural elements are those elements of the P programming language that are used to define the structure or execution of a program in the P programming language. Structure elements combine definitions of data structures and / or program commands for processing instructions (or statements) in a source program to form different types of blocks.

In the past few decades, large software systems have been implemented in companies, which have required a lot of time and expense, new environments (e.g. a new operating system or Internet technology) and new requirements (e.g. due to changed business processes) and expanded to include additional functionalities. Software developers often have to work on software systems that other people have implemented in the past that are no longer available. A model or formal specification or one The formal description of the software system is often not available, is not precise enough or does not match the software system as implemented by the source program. Therefore, methods and facilities are required that analyze the software system by evaluating the source program.

The prior art knows four classes of tools that analyze a software system given as a source program, also with regard to its architecture.

• Mechanics-based tools automatically derive characteristic values for a given source program and / or a formal specification for the software system, which is given in the form of a model, which provide summary information about the scope and quality of the software. These characteristic values are compared with specified limit values.

• Testing tools compare a given source program with design rules and programming conventions for the programming language of the source program. The source program is preferably compared with predefined rules. Parts of the source program are found that violate design rules or programming conventions.

• For a given source program, visualization tools generate a coarsened, abstracted model in the form of a graphical representation for the structure or the sequence of the source program. The representation consists, for. B. from UML diagrams.

• Tools with an interactive display (or browsing tools) select certain structural elements of the software system from the source program and display them in lists as known from Windows. These lists are also linked, in particular with tools with cross references (or cross referencing tools).

A method and a system are presented in US Pat. No. 6,247,020 B1 that support a user in the development of a software system. Is given on files shared source program of a software system in a programming language, e.g. B. Java. The screen is divided into three different windows (or panes). Software system files are displayed in a primary window (or navigation pane). Such a file can be a Java file (or Java file) or a Java package z. B. with classes and interfaces (or Java package) of a certain / class (or class). A hierarchical view (or hierarchical view) shows a section of a family hierarchy (taxonomy) under classes in the primary window. In a first secondary window (or content pane) the content, e.g. B. the source text of a previously selected file. The inner structure of the previously selected file is displayed in a second secondary window (or structure pane). If a user selects a "Java file" in the primary window, structural elements contained in the file are listed, for example classes, interfaces, variables and methods.

From WO 95/00902 AI a method is known which generates a representation of a software system (or computer program) in which a user can navigate interactively. The source program of the software system in a specific programming language, e.g. B. C ++ is given. The software system comprises a collection of structural elements (or components). Several windows (or panes) are created on one screen of a data processing system. An optional tree-shaped or net-shaped representation of the structural elements of the software system is generated and displayed in a primary window (or left pane). This representation includes e.g. B. all classes (or classes), methods of these classes and global variables (or globals). A user selects a structural element shown in the primary window. Information about this structural element is displayed in the secondary windows. B. the source text of a previously selected method or a declaration or a textual description of a previously selected class. US Pat. No. 6,202,199 discloses a system and a method for analyzing the processing of a software system by a data processing system, performing step-by-step tracking (or tracing) and displaying the analysis results. The analysis results are displayed in a primary window and several secondary windows. The primary window (or trace tree pane) shows in a tree-like manner which functions are activated when the software system is being processed and which other functions are activated when a previously selected process (or thread) is executed during execution. Secondary windows display detailed information about a previously selected function. To determine which functions should be followed step by step, a user selects a function in a selection window (or fil ter tree pane). This selection window consists of four different windows, of which the user selects one using a tab (or tab). The functions are shown in a tree-like manner in these windows according to the files, classes, names or processes to which they belong. A tree-like representation shows z. B. all files and functions or all processes (or threads) and functions.

In S. Malpricht, M. Manns and others:. "Transparent translation", - mc extra; 11/94; 1994, pp. 33 - 39, a method is presented by which the mode of operation of an analysis and translation program ^' (or Compiler) is displayed graphically on a screen. The source code of a software system is given. It is checked lexically, then syntactically and finally semantically. The results of each step are shown in windows into which the screen is divided Each phase of the translation shows the section of the source text that has just been checked. In another window, for example, a syntax tree or applied semantic rules are displayed, in a third window the respective intermediate result shown, for example a symbol table or machine source text (or assembler code). From US 6,128,773 a metric-based tool is known which determines the entropy (in the sense of information theory) of the source program of a software system. This entropy is a measure of the complexity of the software system. The tool creates a graph for the dependencies in the system and evaluates the dependencies with entropies. This graph can become very confusing for complex software systems. It is not disclosed in US 6,128,773 how the tool produces clear representations.

No. 5,581,797 discloses a device which presents statistical information on a "hierarchy of things" (or hlerarchy of entities), in particular on a large software system, on the screen of a computer. The disclosure teaches how the statistical information is transmitted the hierarchy of things is arranged in a hierarchy of two-dimensional areas on the screen. The setup is limited to statistical information that is presented on a single screen. If a thing A in the hierarchy of things belongs to a thing B, so the area on the screen for thing A is included in the area for information about part B. The dimensions of the area in which information about thing A is presented may depend on statistical characteristics of thing A.

The device according to US 5,581,797 is limited to statistical information that is presented statically on a screen. The structure and the dependencies of a large software system cannot be clearly represented by the disclosed system.

US 6,118,447 discloses a system for error detection in software systems, in which a developer defines a set of tasks that the software system has to perform and a set of operating states in which the software system operates, as well as illegal states under these operating states. An end user selects one of the predefined tasks. The system for error detection determines whether the software system would end up in an impermissible operating state due to the processing of the task and issues a warning to the end user and / or the developer. This system is therefore a test tool.

If one applies the procedure according to US Pat. No. 6,118,447 to an existing software system, this requires that the developer has analyzed the software system by hand in order to find the tasks and operating states.

US 5,655,074 (corresponds to WO 97/02528) discloses a method for analyzing software systems. The task is to support a software developer in recognizing the greatest risks in a software system. The process consists of the following steps: The components of the software are defined. Attributes are defined for each component and then measured. Use of the software system in the past yields data on performance. A first probability theory distribution over the components is derived from the measurements of the attributes, and a second distribution from the performance data. The two distributions are compared to gain dependencies between the attributes and the performance.

A representation of the dependencies between different components of the software system is not generated in US 5,655,074. It is not disclosed how a clear representation of the generated information is generated. In addition, it is not disclosed how the components of the software system are systematically defined and automatically found.

As an example of a visualization tool, WO 00/38051 discloses a method which carries out a method of reverse engineering (or reverse engineering process) for a system. The process consists of the following steps:

• The application and development environments are identified. • Object types and entry points are identified that serve as a starting point for the analysis.

• A network of dependencies is built based on these entry points.

• The generated information is prepared for further processing in a development environment or for a representation for a person.

WO 00/38051 does not disclose how the visual representation is generated.

Tables with cross references (or cross referencing tables according to the state of the art) are static tables with columns to show relations between the components of the software system. It is possible that one element is shown in the left column and 500 elements in the right. - The advantages of flexible and dynamic display on a screen of a data processing system are increasingly being used, with modern browsing tools already using lists of graphical user interfaces for this purpose.

An example of a browsing tool is the product "SNiFF +" from the company "Wind River"

(http: // www. windriver. com / products / html / sniff. html, queried on May 3, 2001). SNiFF + presents a user with lists and diagrams for structural elements of a given software system using a graphical user interface. Not all relations between structural elements are shown. When the user selects a structural element, SNiFF + shows the source code of these structural elements or offers the possibility to switch to another structural element in relation to the first structural element of another list. However, the connections created in this way are only partially and not systematically available. To close this gap, SniFF + provides search functions that operate directly on the source program and only compare character strings. If two structural elements have the same name, it remains the responsibility of direction of the user to find out which structural element is meant when the name appears in a list or diagram.

The invention has for its object to improve a method according to the preamble of claim 1 so that the display, which is to be generated automatically depending on the selection operations of a user, is clear and yet complete with respect to a predetermined criterion. A model or a formal or natural language specification for the software system should not be required. Furthermore, a device and a computer program product for carrying out the method have to be created.

The object is achieved by a method according to claim 1, an apparatus according to claim 22 and a computer program product according to claim 24 or claim 25. Advantageous refinements are specified in the subclaims.

The software system is available as a source program in a specific programming language P. The architecture to be displayed includes structural elements and relations among these structural elements. The architecture is automatically determined with the help of a data processing system. The method according to the invention determines how this architecture is represented, e.g. B. on an output unit of the data processing system.

According to the invention, a number of views of the architecture are defined. Each view represents a set of structural elements of the software system, which are selected on the basis of a predetermined criterion, as well as relations of these structural elements to other structural elements of the software system. For this purpose, it is defined which types of structural elements and which types of relations between structural elements are defined in the programming language P. , Only these types of structural elements and relations can occur in the software system, and therefore only these types need to be shown. The criteria for the views are defined depending on the types of structure elements and relations. The representation to be generated comprises at least one view, which is selected from this set of views of the architecture before the representation is generated. The representation to be generated can comprise several selected views or even all views of the set of views (claim 18). The selected view is generated and displayed automatically. This creates a primary window of the view and at least one secondary window of the view. At least one category of structural elements of the software system is selected. The structural elements that belong to at least one selected category are determined. A set of structural elements determined in this way is selected on the basis of a predetermined criterion and displayed in the primary window of the selected view. Information about at least one structure element displayed and selected in the primary window is displayed in at least one secondary window of the selected view. This information includes a number of further structural elements that are in at least one specific relation to the selected structural element.

The structural elements are preferably classified by belonging to categories which depend exclusively on the programming language (P). When the method is carried out, it is automatically determined which structural elements of the determined architecture belong to which of these categories. A structural element can belong to several categories. The identification of the categories is an intermediate step in the creation of the views.

The solution according to the invention generates complete and systematic representations of information about the structural elements and their relations and thus about the structure of the given software system.

In particular, the division of the display into views with primary and secondary windows ensures that the generated display is clear. The relatively complex information network of the structural elements and their relations among other is organized and thus made clearer. The fact that a lot of information is only shown in the secondary window for the structure element previously selected in the primary window results in a user-friendly filtering of information. In particular, different structural elements with the same name are automatically differentiated. Because different types of structural elements are assigned to several views, the views are also connected to one another via common structural elements. As a result, the architecture of the software system is completely mapped to the views.

The set of views can be used to represent the architecture of any software system whose source program is implemented in the P programming language. It is not necessary to redefine views for each software system.

The representation is preferably generated as a function of a user's selection operations. A user can make any selection operations among the alternatives offered to him. In this way, different representations of the architecture of the same software system, in particular different views of the architecture, can be generated for different users without the need for adaptation, for example for implementations.

The information is obtained from the source program of the software system without the need for a model or a formal specification for the software system. The method according to the invention is therefore also suitable for software systems which are not documented at all or are insufficiently documented.

A set of structural elements is preselected according to claim 1 based on a predetermined criterion and displayed in the primary window of the selected view. In the embodiment according to claim 2, the preselection is carried out by preselecting all structural elements of at least one category. be chosen. According to claim 3, the preselection is carried out by preselecting those structural elements of at least one category that meet a previously defined filter condition.

These categories include at least one of the following categories (claim 4): a category of the file management units, which comprises the files to which the source program is divided, a category of the data types, this category being the data types of the programming language (P) and the data types, which are defined in the software system, a category of data objects, which includes the variables and constants, a category of translation units, these are the structural elements from which a compiler or interpreter creates library units, a category of subroutines, which includes the functions and procedures , and a category of library units generated from translation units by a compiler or interpreter.

According to the method according to the invention, at least one selected view is generated and displayed from a set of views. This set preferably comprises the following views: a file source code view (claim 5) with at least one secondary window, a data type view (claim 6) with at least three secondary windows, a data object view (claim 7) with at least one secondary window, one Assembly view (claim 11) with at least one secondary window, a call view (claim 13) with at least two secondary windows

- And an import-export view (claim 16) with at least two secondary windows.

Structural elements of a certain category are determined. Some of the structural elements determined are preselected based on a criterion. Which this category is depends on which of these views are selected.

- After selecting the file source code view (claim 5), the category of file management units is selected.

- After selecting the data type view (claim 6), the category of the data types is selected.

After selecting the data object view (claim 7), the category of the data objects is selected.

- After selecting the structure view (claim 11), the category of data objects is selected.

- After selecting the call view (claim 13), the category of data objects is selected.

After selecting the import-export view (claim 16), the category of the data objects is selected.

The following information or structure elements are displayed in the secondary window (s) of the selected view:

- After selecting the file source code view (claim 5) and a file displayed in the primary window, the source code of the selected file is displayed in a secondary window.

- After selecting the data type view (claim 6) and a data type displayed in the primary window, those additional structure elements are displayed in a secondary window in which the selected data type is used.

- After selecting the data object view (claim 7) and a variable or constant displayed in the primary window, those additional structures are displayed in a secondary window. elements are displayed that have write or read access to the selected variable or constant.

- After selecting the structure view (claim 11) and selecting a structure element, those additional structure elements that are used in the source text of the selected structure element are displayed in a secondary window.

- After selection of the call view (claim 13) and selection of a subroutine, those subroutines are displayed in a first secondary window that are called by the selected subroutine, and those subroutines from which the selected subroutine is called up in a second secondary window.

After selecting the import-export view (claim 16) and selecting a library unit, those library units that are imported by the selected library unit are displayed in a first secondary window, and those library units from which the selected library unit is imported are displayed in a second secondary window.

Further subclaims define configurations of these views.

According to claim 8, three secondary windows are generated after selection of the data object view and a variable or constant displayed in the primary window. In a first secondary window, those library units of the software system are displayed that have write and non-read access to the selected variable or constant. In a second secondary window, those library ^{units ¬ of} the software system are displayed that have read and non-write access to the selected variable or constant. In a third secondary window, those library units of the software system are displayed that have both read and write access to the selected variable or constant The preselected data objects are displayed in ascending or descending order according to their number of uses (claim 9). Depending on the user specification, it is counted how many library units only have write, read and / or write and read access to a variable or constant.

The primary window of the data object view is preferably divided into two columns (claim 10). After selecting the data object view, the names of the preselected data objects are displayed in a first column of the primary window (PF_1). The name of the library unit in which the data object is defined is displayed in a second column of the primary window (PF_1) next to a data object.

Two secondary windows are preferably generated after selection of the assembly view (claim 12). After selection of a structural element displayed in the primary window, the ones that are defined in the specification of the selected structural element are defined in a first secondary window. In a second secondary window, those structure elements are displayed that are used in the implementation of the selected structure element.

After selecting the call view, the preselected subroutines are displayed in ascending or descending order according to their number of uses.

According to claim 15, the primary window of the call view comprises two columns. After selecting the call view, the names of the preselected subroutines are displayed in a first column of the primary window. In a second column of the primary window, in addition to the name of a subroutine, the name of the library unit in which the subroutine is defined is displayed.

Furthermore, a step flow chart is additionally generated and displayed in accordance with claim 17. This step-by-step plan shows which structural elements in which order the execution of the source program can be called and processed.

According to claim 19, an additional step is carried out. Structure elements are displayed in a secondary window of the selected view, one of these structure elements is selected. Name SE this second selected structural element. From the set of views of the architecture, those are determined in which the structural element SE occurs in the primary window. After selecting at least one of these views, this second view is created and displayed. The structural element SE is shown in the primary window of this second view, preferably highlighted. In the secondary window of the second view, a number of further structural elements are displayed for the structural element SE, which are in a specific relationship with the structural element SE.

An embodiment of claim 19 provides that all views are generated and displayed in which the structural element SE occurs in the primary window. For the selection of one or more of these views, a context menu for the structure element SE is preferably generated, which can be called up by selecting the structure element SE by pressing the right mouse button.

The development of claim 19 according to claim 20 provides that the method steps of claim 19 are carried out repeatedly in succession. For example, after selecting a second structural element, a second view is selected, generated and displayed. After selecting a third structure element in the primary window of the second view, a number of further structure elements are displayed in a secondary window. A fourth structural element is selected from this set. A third view is then selected, generated and displayed. After selecting a fifth structure element in the primary window of the third view, a second set of further structure elements is displayed in a secondary window of the third view. For this further A sixth structure door element is selected. A fourth view is then selected, generated and displayed. This sequence continues.

This configuration in particular supports a user in carrying out targeted navigation through the architecture of the software system. Here the user has the option of jumping back and forth between different views. Views with lists in primary and secondary windows are created one after the other. These lists are linked to each other by structure elements, which are shown in several windows. According to appropriate user specifications, the relationships shown in different views for one or more structure elements are displayed one after the other or next to one another.

According to a corresponding specification for a structural element. the point at which the structure element is defined or used is displayed in the source program of the software system. (Claim 21). First, either a structural element is selected that is displayed in the primary window of the selected view, or a structural element is selected that is displayed in a secondary window of the selected view. The location in the source program is then displayed at which the selected structure element is defined or used.

An apparatus for performing the method according to one of claims 1 to 21 comprises according to claim 22

- A device for determining the architecture of the software system

- And a device for generating a representation of the determined architecture.

This device for generating a representation comprises according to claim 23

a device for selecting at least one view from a set of views (S 1, S 2) of the architecture, a device for generating and displaying a selected view (S_l), the view comprising exactly one primary window (SE_1) and at least one secondary window (SF_1.1, SF_1.2),

a device for preselecting structural elements of the software system,

- A device for displaying the preselected structure elements (SE_1, SE_l.x) in the primary window (PF_1) of the selected view (S_l)

a device for displaying information about a selected structure element (SE_1) in a secondary window (SF Ll, SF_1.2) of the selected view (S_l), and a device for displaying a set of further structure elements (SE_2, SE__2.x), that are in at least one specific relation with the selected structure element (SE_1), in a secondary window (SF_1.1, SF_1.2) of the selected view (S_l).

An exemplary embodiment of the method according to the invention is described in more detail below with reference to the accompanying drawings. Show

1. a file source code view of the architecture;

2 shows a data type view of the architecture;

3 shows the data type view of FIG. 2 with a selection menu for specifying a filter condition and a sorting;

4 shows a data object view of the architecture with three secondary windows;

5 shows the data object view of FIG. 4 with a selection menu for defining a filter condition and sorting;

FIG. 6 shows a construction view of the architecture with two secondary windows; 7 shows the structure view of FIG. 4 with a selection menu for defining a filter condition and a sorting;

8 shows a call view of the architecture with two secondary windows;

9 shows the call view of FIG. 8 with a selection menu for defining a filter condition and a sorting;

10 shows an import-export view of the architecture with four secondary windows;

Fig. 11. the import-export view of FIG. 10, in which translation units are displayed for a library unit;

12 shows the import-export view of FIG. 10 with a selection menu for defining a filter condition and a sorting;

Fig. 13. Pictograms for the different types of structural elements;

14 shows an explanation for primary and secondary windows of two views generated in succession.

The software system, the architecture of which is represented according to the invention, is available as a source program in a specific programming language P. A preferred embodiment of the method according to the invention consists of the following steps: a) A description of the types of structural elements that the programming language P consists of is read or automatically acquired in another way. This description includes a list of the types of structural elements and a description of the possible relationships among structural elements. This description of the types of structural elements is made once for the P programming language. It is valid for every source program that has been implemented in P. Only structural elements of this type can occur in the software system. b) A description of the set of views of the architecture of a software system that has been implemented in the programming language P is read in or otherwise automatically acquired. This description defines which primary window and which secondary window each view has and which categories of structure elements are displayed in which primary and secondary windows after a view has been selected. Furthermore, the description includes a definition of filtering and sorting options for the primary window and a set of relations for the secondary windows of each view. This description of the set of views is created in advance for the structural elements of the P programming language. It is valid for every source program that has been implemented in P. c) The given source program for the software system is read. d) The architecture of the software system is analyzed. In particular, it is determined which structural elements occur in the software system, which types and categories these structural elements are and which relations exist between which structural elements. The description recorded in step a) and the source program read in step c) are used for this. The result of the architecture analysis is stored in a temporary and / or permanent memory. e) A sequence consisting of steps i) to iv) is carried out at least once: i) The result of the architecture analysis is recorded automatically. ii) User specifications are automatically recorded.

These specifications include a selection from the set of views of the architecture as well as filtering and sorting conditions for the primary windows of the selected views. iii) Depending on the specifications recorded in step ii), a representation of the architecture of the software system, which consists of the selected views, is generated and displayed in a primary window on a screen of a computer whose operating system supports the window technology. In the primary window, structural elements are displayed that have been preselected according to a specified criterion. iv) Depending on a user selection, a selected structural element is highlighted in the primary window of a selected view, and in the secondary windows of this view

Information about the first structure element and / or a set of further structure elements that are in a specific relationship with the first structure element is displayed.

For the implementation of step d), methods can be used which, for. B. for syntax analysis of a source program (or source code analysis) are known. The expert knows techniques for compiler construction, for. B. from AV Aho, R. Sethi, JD Ullman: "Compilers: Principles, Techniques, and Tools", Addison-Wesley, 1985 or from St. Muchnick: "Advanced Compiler Design and Implementation", Morgan Kaufmann, 1997. These techniques provide an executable program. For use as part of the method according to the invention, such a technique is modified so that it provides a description of the structural elements and their relationships. A data structure with a semantic network is preferably generated. The source program of the software system is analyzed and checked for syntactical correctness. If the program is syntactically correct, it only contains permissible relations between the structural elements. Passages of the source program that are not syntactically correct are preferably ignored. Step e) is usually carried out several times for a software system. It is therefore advantageous to save the results of step d) and reuse them.

In the embodiment described below, the source program is in the programming language "Ada-95". A formal definition of "ADA-95" is given by "ADA Reference Manual - ISO / IEC 8652" (1995). A program in the programming language P is syntactically correct if and only if it can be derived from a given start character by applying the production rules.

In the preferred embodiment of the invention described below, only those structural elements of the programming language P are taken into account when determining the architecture that have user-defined names (or user-defined identifiers). Custom names are for ADA-95 e.g. B. from John Barnes.. "Programming in Ada95", Addison-Wesley, ^2nd Ed, 1998, known blocks in a branch instruction are examples of structural elements without custom names structural elements without custom names to play for to be presented architecture of the software system only. subordinate role, since they cannot be referenced and can therefore only be used at the place of definition.

From this formal definition, the types of structural elements are derived in advance, which are automatically recorded in step a). The formal definition of a programming language such as ADA-95 preferably includes a syntax in the form of a hierarchical representation of all elements of the programming language P. From non-terminal characters, other non-terminal characters or terminal characters are derived by so-called production rules with left and right sides. A program in the programming language P is syntactically correct if and only if it can be derived from a given start character by applying the production rules. Different structural elements of the same type can have the same name. They are always clearly identifiable by the scope, that is the context of their definition, or by distinguishing parts of the name.

All types of structural elements are described in the "ADA Reference Manual - ISO / IEC 8652" (1995). A package (or package) groups data and processing instructions (or states) into a structural element. A function (or Function) and a procedure (or procedure) group processing instructions of the source program. A task (or task) allows processes to be processed in parallel. In an exception handling (or exception) processing instructions for handling errors are compiled.

In the description automatically recorded in step a), types of structural elements are preferably combined into categories. A type of structure element can belong to several categories. For example, the following categories of structural elements are defined and stored for ADA-95, which are given below with German and English names: the category of the file management units,

the category of the data types (or data types), which includes the data types of ADA-95 and all data types that can be defined in an ADA-95 source program,

- The category of data objects (or data objects), the category of translation units (or compile units), these are the structural elements from which an ADA-95 compiler uses syntax analysis and translation to generate library units, which are then performed with a main routine be bound to the executable software system, - and the category of library units (or library units) that are generated by an ADA-95 compiler from the aforementioned translation units.

The category of the file management units consists of the files (or files) between which the source program of the software system is divided and the file directories (or directories). Files contain source code of the source program. File directories group files in a tree structure.

Each data type is a structural element, namely both the data type predefined by ADA-95 (or pre-defined data type) and each user-defined data type (or user-defined) introduced in an ADA-95 source program using the predefined data types data type). The following types of predefined data types are distinguished: Integer (or integer) real number {or real)

- enumeration

Pointer type (or access type), which is a data type for pointers to structure elements, usually to other data types

- vector (or array)

Data structure type (or record type), which is a predefined fixed data structure that is composed of elements of various other data types,

- Variable data structure type (or variant record), that is a predefined variable data structure that is composed of elements of various other data types and whose structure is made variable by differentiations (or discriminators). Discriminants are a type of parameterization in which functions can be used. Derived data types (or derived types), that is a superclass for the user-defined data types, and sub-types (or sub types) are not discussed in more detail.

The category of data objects summarizes the following types of structure elements:

- Variable (or variable) constant (or constant) exception (or exception)

- Task type, or protected type.

The category of translation units is divided into three subcategories, namely that of translation unit specifications (or compile unit specifications), that of translation unit implementations (or compile unit bodies) and the category of translation subunits (or compile subunits) , these are outsourced components of translation units that the compiler translates separately.

In an ADA-95 source program, the specification of a translation unit (or compile unit specification) can be separated from its implementation (or compile unit body). A translation unit specification essentially contains definitions of data types as well as interfaces to functions and procedures. A translation unit implementation contains the definition of variables and constants as well as the processing instructions and thus in particular the use of structural elements. Parts of the implementation can be outsourced to translation subunits (or compile subunits). An ADA-95 compiler generates from a translation unit specification, none or a translation unit implementation and none, one or multiple translation sub-units a library unit (or library unit).

The sub-category of translation unit specifications summarizes the following types of structural elements:

Package specification (or package specification)

Procedure specification

Function specification (or function specification)

Specification of a generic package (or generic package specifica tion)

Specification of a generic procedure (or generic procedure specification)

Specification of a generic function (or generic function specification)

- Task specification.

The sub-category of translation unit implementations summarizes the following types of structural elements:

Package implementation (or package body)

Procedure implementation (or procedure body)

Function implementation (or function body)

Implementation of a generic package (or generic package body)

Implementation of a generic function (or generic function body)

Implementation of a generic procedure (or generic procedure body

- Copy of a generic package (or (generic) package instance)

Example of a generic procedure (or (generic) procedure instance) - Copy of a generic function (or (generic) function instance)

- Task implementation (or task body).

The category of translation subunits summarizes the following types of structural elements:

Package implementation (or package body)

Procedure implementation (or procedure body)

Function implementation (or function body)

- specification of a protected object (or protected object specification)

Implementation of a protected object (or protected object body).

The following types of structural elements in particular belong to two different subcategories: package body, procedure body and function body.

Library units are generated by the compiler from translation unit specifications and translation unit implementations as well as translation subunits. Depending on the types of translation units, the following types of structural elements belong to the category of library units:

Package

Procedure

Function (or function) generic package (or generic package) generic procedure (or generic procedure) generic function (or generic function)

Copy of a generic package (or package instance)

- Copy of a generic procedure (or (generic) procedure instance) - Copy of a generic function (or (generic) function instance).

Those types of structure elements that can be called by other structure elements are grouped into a subcategory of the subroutines (or subprograms). This subcategory includes the following types of structural elements:

Procedure

Function

Example of a generic procedure (or (generic) procedure instance)

- Copy of a generic function (or (generic) function instance).

A subroutine can be a library unit, an exportable subroutine or a local subroutine.

Between the structure elements of the categories and types of structure elements described above, certain relationships are permissible and others are not. Some permissible relations are described below as examples. The permissible relations can occur between structural elements of the software system, but do not have to.

The exemplary description of the relations is grouped by category. Relationships for data types and data objects are:

• Any other structural elements can be used in a structural element belonging to the category of translation units.

• Two restrictions are: In a protected object specification (this type belongs to the category of the translation subunits), procedure specifications and function specifications can occur. In a protected obj ect body, variables, constants as well as procedure bo-dies and function bodies can occur. • Other, already defined data types are used to define a data type.

• Variables and constants are defined using previously defined data types.

• ^' In a protected type, data types as well as procedure specifications and function specifications are defined and used.

• Exceptions and task specifications do not contain any structural elements.

• A data type is used in a procedure specification or function specifica tion or task specifica tion to determine the type of a call parameter.

• A data type is used in a function specification or task specification to determine the type of the return value.

• A function body, generic function body, procedure body or generic procedure body has read or write access to a variable or constant.

• A function body, generic function body, procedure. body or generic procedure body calls other functions or procedures and uses variables or constants as call parameters.

The following allowable relations exist between translation units and library units:

• A package is made up of exactly one package specification and no or exactly one package body, as well as none, one or more compile subunits.

• A procedure arises from exactly one procedure specification and exactly one procedure body and from none, one or more compile subunits.

• A function arises from exactly one function specification and exactly one function body and from none, one or more compile subunits. • A generic package is made up of exactly one generic package specification and no or exactly one generic package body and none, one or more compile subunits.

• A generic procedure arises from exactly one generic procedure specification and exactly one generic procedure body and from none, one or more compile subunits.

• A generic function arises from exactly one generic function specification and exactly one generic function body as well as from none, one or more compile subunits.

• A package instance is created from exactly one generic package. Conversely, no, one or any number of package instances are generated from a generic package.

• A procedure instance arises from exactly one generic procedure. Conversely, no, one or any number of package instances are generated from a generic procedure.

• A function instance arises from exactly one greneric function. Conversely, no, one or any number of function instances are generated from a generic function.

The name of a library unit is the same as that of the translation unit from which the library unit is generated. A translation unit specification and the associated translation unit implementation have the same name.

The following relations are allowed between translation units and library units:

• A translation unit A imports a library unit B. Both a translation unit specification and a translation unit implementation as well as a translation subunit can import a complete library unit. Conversely, a library unit B is exported to a translation unit A.

• A translation unit imports none, one or more library units.

• One restriction is that if a library unit A was created from a translation unit B, B cannot import A, but only other library units.

These import-export relations are implemented in an ADA-95 source program by means of a so-called with statement (or with clause). The following relations are permitted between library units:

• A library unit A imports a library unit B directly if a translation unit C imports the library unit B and the library unit A is generated using the translation unit C.

Conversely, a library unit B is exported directly to a library unit A if B is exported to a translation unit C and the library unit A is generated using the translation unit C.

A "library unit A imports a library unit C indirectly if A imports a library unit B and library unit B directly imports library unit C.

Conversely, a library unit C is exported indirectly to a library unit A.

There are also two hierarchical relationships between library units:

• A library unit A extends a library unit B (or "library unit A is child of library unit B").

Conversely, the following applies: a library unit B is expanded by a library unit A (or “library unit B is parent of library unit A”). The hierarchical relation "library unit A extends library unit B" means: If A is imported from another library unit, B is imported together with A into the other library unit.

These relations are possible relations between library units. Many library units do not import other library units and do not expand other library units.

The following relationships are permitted between file management units and other structural elements:

• A file directory is a subdirectory of another file directory. The file directories form an arbitrarily branched tree structure.

• A file belongs to exactly one directory. Conversely, a file directory contains no, one or more files.

• One translation unit is contained in exactly one file.

• A file contains at least one translation unit.

• The translation units from which a library unit was created are all contained in the same or in different files.

The permissible relations between structural elements are determined by automatically evaluating production rules defining the programming language P.

In method step b), a description of the set of possible views of the architecture of a software system that has been implemented in the programming language P is read in or automatically acquired in some other way. Most of the possible views can be used equally for many programming languages; some views require special properties of programming languages. By reading the description, the following is defined in particular for each possible view: - How many secondary windows are created and displayed after selecting a view?

According to which criterion is a set of structural elements selected to be displayed in the primary window of the view? This criterion is preferably a category or a set of categories of structural element. In addition, a filter condition under the structure elements of these categories can be effective.

- What types of relations are used to select the set of additional structure elements that are displayed in a secondary window after selecting a structure element displayed in the primary window? The other structural elements that are in at least one specific relation to the selected structural element are selected.

- What information about structural elements is shown in the primary window? At least the names of all structure elements are displayed.

- After selecting a structure element displayed in the primary window, what information is displayed about the selected structure element in a secondary window?

- How are the structural elements displayed in the primary window and in the secondary windows sorted?

In a preferred embodiment, the set of views comprises the following six views:

- File source view

- Data type view Data object view

- Construction view

- Call view import-export view.

These six views are described below. In sub-step ii) of step e), user specifications are automatically recorded. In particular, one or more of the views are selected by these specifications, the representation to be generated comprises the selected views.

After selecting the file source view, a primary window and a secondary window are displayed. 1 shows the file source code view for an application example. In the primary window all files are listed, on which the source program of the software system is divided. The following information about the files is preferably determined and displayed in the primary window:

Name of the file,

Path to the file in the file management system,

- total number of program lines in the file,

- of which number of comment lines,

- Number of declarations e.g. B. of variables and constants in the file

- and number of processing instructions (or statements) in the file.

The primary window is preferably divided into six columns. The left column shows the names of the files in alphabetical order, the other five columns show the information about the file in the respective line. An alternative embodiment provides that only an alphabetically sorted list with the names of the files is displayed in the primary window and the information about the file is shown after selection of a file name by "expanding" (or expanding).

In an alternative embodiment, a tree structure with the file directories (or directories) of the file management system and assigned files (or files) is displayed in the primary window of the file source text view. The preselected files are displayed sorted in the primary window, sorted according to a user specification in one of the following ways: alphabetically according to the name of the structure element in ascending order or descending according to the total number of program lines in the file

- Number of declarations in the files

- Number of instructions in the files.

After selecting a file displayed in the primary window, the source text of the file is displayed in the secondary window (SF_1.1). The keywords, e.g. B. IF, THEN, END IF, highlighted in the source text.

After the user has selected a second structure element (SE_2) whose name is contained in the displayed source text, a second view is generated and displayed, in the primary window of which the second structure element is displayed.

After selecting the data type view, a primary window and a secondary window are created. 2 shows the data type view for an application example. All data types are listed in the primary window, i.e. all structure elements belonging to the category of data types described above. The number of the displayed data types is indicated in the heading of the primary window, in the example in FIG. 2 this is 148. The names of the data types and the names of the library units in which these data types are defined are preferably given in two columns in the primary window. The primary window of FIG. 2 shows, for example, that the data type FORMAT_TYPE is defined in the library unit ADAR_FORMATS.

The preselected files are displayed sorted in the primary window, sorted in one of the following ways depending on a user preference:

- alphabetically by name of the data type ascending or descending according to the number of uses.

The number of uses counts how many other structural elements use a data type in any way.

In the example in FIG. 7, the data types are shown in descending order according to the number of uses.

After selecting a data type (SE_1) displayed in the primary window, all other structural elements (SE_2, SE_l.x) of the software system are displayed in the secondary window (SF_1.1), in which the selected data type is used in any way. The names of the structural elements used and the names of the library units in which these structural elements are defined are also preferably displayed in two columns in the secondary window.

After selecting the data object view, a primary window (PF_1) and three secondary windows (SF_1.1, SF_1.2, SF_1.3) are created. Fig. 4 shows the construction view for an application example.

In one embodiment, all variables and constants of the software system are preselected and listed in the primary window (PF_1).

The names of the preselected variables and constants, the names of the library units in which the preselected variables and constants are defined, are preferably displayed in four columns in the primary window.

- The names of the data type of the preselected variables and constants and the names of the library units in which these data types are defined are listed. This is not shown in Fig. 4.

After selecting the layout view, a primary window (PF_1) and two secondary windows (SF_1.1, SF_1.2) are created. 6 shows the construction view for an application example. In the primary window (PF_1) all library units as well as other structure elements with an inner structure, namely tasks, task types, protected type and protected objects are listed. All structure elements that either belong to the category of translation units or are tasks, task types, protected types or protected objects are preselected. The number of the structure elements displayed is specified in the heading of the primary window (PF_1), in the example in FIG. 6 these are 1,048.

The preselected structure elements are displayed sorted in the primary window, sorted in one of the following ways depending on a user specification: alphabetically by name of the structure element first by type of structure element. The similar structural elements are sorted alphabetically.

In the example of FIGS. 6 and 7, the structural elements are sorted alphabetically.

After selecting a structure element (SE_1) in the primary window (PF_1), further structure elements are displayed in the two secondary windows, which have the following two relationships with the selected structure element (SE_1):

The first secondary window (SF_1.1) shows those structure elements that are defined in the specification of the selected structure element (SE_1). If the selected structural element (SE_1) is a library unit, the specification here means the translation unit specification that is used when the library unit is generated. If it is a protected object, the specification means the associated protected object specification.

In the second secondary window (SF_1.2), those structure elements are displayed that are used in the implementation of the selected structure element (SE 1). In the example in FIG. 6, a package called PARSER_PCKG is selected. In the first secondary window (SF_1.1) the directory path and file name in which the package is defined are displayed in the first line and the name PARSER_PCKG of the package in the second line. The structure of the PARSER_PCKG specification is listed in the following lines, in the order in which they appear in the source text. The pictograms in front of the names indicate the type of structural element they contain.

In the second secondary window (SF_1.2) the directory path, file name and name of the package are displayed in the first two lines. The structure of the implementation of PARSER_PCKG is listed in the following lines

After the user has clicked on an "expand" pictogram in front of the name of another library unit (SE_2, SE_2.x) displayed in one of the four secondary windows, the next level of a nested definition is displayed. After a corresponding user specification a nested definition is completely displayed. The display can be "collapsed" again. In the example of FIG. 6, the representation means of the tree (or tree view) is used.

Depending on the corresponding specifications of the user, not all library units, tasks, task types, protected types and protected objects are preselected, but only those that meet a filter condition specified by the user specifications. The filter condition is determined by individual filter conditions. The individual filter conditions can be switched on or off independently of each other. The activated individual filter conditions are combined to the filter condition used for the preselection. 7 shows which individual filter conditions can be defined: - The types of the structural element, e.g. B. package (this makes library units of the type package) and protected objects, a single condition for the name of the structure element

- And globally and / or locally defined structural elements

In the example in FIG. 7, no restrictions are set.

After selecting the call view, a primary window and two secondary windows (SF_l-.l, SF_1.2) are created. 8 shows the call view using an example. All subroutines are preselected in the primary window (PF_1), i.e. all structure elements that are functions or procedures and therefore belong to the subroutine category. In the heading of the primary window (PF_1), the number of subroutines displayed is specified; in the example in FIG. 8, this is 903.

The names of the subroutines and the names of the library units in which these subroutines are defined are preferably displayed in two columns in the primary window. H. in which their specification is included. The primary window of FIG. 8 shows, for example, that the FORMAT subroutine is defined in the ADAR_FORMATS library unit.

The preselected subroutines are displayed sorted in the primary window (PF__1), sorted in one of the following ways depending on a user specification: alphabetically according to the name of the subroutines ascending or descending according to the number of uses.

Depending on user specifications, one or both of the following uses are counted:

How many other structural elements call a subroutine and use it with it?

- How many other subroutines a subroutine calls and uses? The preselected subroutines in Fig. 8 and Fig. 9 are sorted in descending order by use. As FIG. 9 shows, both the number of times a subroutine is called and how many other subroutines it calls are counted.

After selecting a subroutine (SE_1) in the primary window (PF_1), further structure elements (SE_2, SE_2.x) are displayed in the two secondary windows (SF_1.1, SF_1.2), which are in the following two relations with the selected subroutine (SE_1) :

In the first secondary window (SF_1.1) those further subroutines are displayed that call the selected subroutine (SE_1).

In the second secondary window (SF_1.2) those further subroutines are displayed which the selected subroutine (SE_1) calls. In other words, those additional subroutines are displayed that are called up by the selected subroutine (SE__1).

In the example in FIG. 8, the FORMAT subroutine is selected, a function. FORMAT is called by 9 subroutines and calls 7 further subroutines. The names of the subroutines and the names of the library units in which these subroutines are defined are preferably also in the secondary windows in two columns. H. in which their specification is included.

In a further development of the embodiment, additional information about the subroutines and library units displayed in the two secondary windows (SF__1.1, SF_1.2) is displayed, namely the line number in the source text of the structure element in which the subroutine is started. This information is preferably displayed with the help of a tree view, which is “unfolded” and “folded in” again. After a corresponding user specification, the source text is displayed, through which the subroutine is called. Depending on the corresponding specifications of the user, not all subroutines are preselected, but only those that meet a filter condition defined by the user specifications. The filter condition is determined by individual filter conditions. The individual filter conditions can be switched on or off independently of each other. The activated individual filter conditions are combined to the filter condition used for the preselection. Fig. 9 shows which individual filter conditions can be defined:

- Procedures are preselected.

- Functions are preselected.

- Subroutines are selected that have multiple names (aliases), which is achieved via the mechanism of the rename.

- Pre-selected subroutines that are library units.

- Subroutines are selected which are exportable subroutines.

Subroutines that are local subroutines are preselected.

- Pre-selected subroutines are used at least m times and / or at most n times. Depending on the corresponding user specifications, all uses or only the following uses are counted:

- How many other structural elements call a subroutine and use it with it?

- How many other subroutines does a subroutine call and use them with?

After selecting the import-export view, a primary window (PF_1) and four secondary windows (SF_1.1, SF_1.2, SF_1.3, SF_1.4) are created. Fig. 10 shows the import-export view for an application example. In the primary window (PF_1) all Library units are listed, so all structural elements belonging to the category of library units are preselected. The number of library units displayed is specified in the heading of the primary window (PF_1).

The preselected library units are displayed in the primary window (PF 1) sorted in one of the following ways, depending on a user specification:

- alphabetically by the name of the library unit

- ascending or descending according to the number of import and / or export relations.

The preselected library units are sorted alphabetically in FIG. 10. In Fig. 12 the preselected library units are shown in descending order according to the number of import and / or export relations, which are called "uses" in Fig. 12. Depending on user specifications, all uses or only the following uses are counted: the direct and / or indirect imports into a translation unit specification, the direct and / or indirect imports into a translation unit implementation, the direct and / or indirect imports into a translation subunit, the direct and / or indirect exports into another library unit ,

All library units are displayed in the primary window, even those without an import or export relation to another library unit. In the four secondary windows those library units are listed with which the library unit (SE_1) selected in the primary window is directly or indirectly connected via an import or export relation. After selecting a library unit (SE 1) In the primary window (PF_1), further structural elements (SE_2, SE_2.x) are displayed in the four secondary windows, which are in the following four relationships with the selected library unit (SE_1):

The first secondary window (SF_1.1) shows those other library units that are imported directly into the selected library unit (SE_1). In other words: those other library units are displayed that the selected library unit (SE_1) imports directly.

The second secondary window (SF__1.2) shows those other library units that are indirectly imported into the selected library unit (SE_1).

The third secondary window (SF_1.3) shows those other library units into which the selected library unit (SE_1) is exported directly.

In the fourth secondary window (SF_1.4) those

1 whose library units are displayed, which indirectly export the selected library unit (SE_1).

The heading of the secondary window shows how many library units are displayed in each.

Depending on a corresponding user specification, the other library units in the four secondary windows are either sorted alphabetically or differentiated according to specification, implementation and subunits.

After a corresponding user specification for a preselected library unit (SE_l.x) in the primary window (PF__1), those translation units are displayed from which the selected library unit (SE_1) is generated. This user specification is carried out, for example, by a user clicking on an "expand" pictogram in front of the name of the preselected structural element. clicks (SE_1) and the information is displayed using a tree view. In the folded state, all imported library units are shown in summary in a secondary window; in the expanded state, a distinction is made as to whether a library unit is imported into the specification, the implementation or into a subunit of the selected library unit (SE_1).

This is shown in Fig. 11. The user clicked on the "Expand" icon next to the "ADAR-COMP" library unit. The translation units from which “ADAR-COMP” is generated are then displayed. In the example in FIG. 11, these are the translation unit specification “Specification”, the translation unit implementation “Body” and eight translation subunits.

After the user has clicked on an "expand" icon that is shown in front of the name of another library unit (SE_2, SE_2.x) displayed in one of the four secondary windows, the translation units from which this additional one is displayed are displayed Library unit was created.

After a different selection of a library unit (SE_1) in the primary window (PF_1), those library units are also displayed which extend the selected library unit (SE_1) (using the relation “is child o ^). The different selection is made by a user clicking on an "expand" pictogram in front of the name of the structure element (SE_1). After the click, the extensions for the selected structure element (SE_1) are displayed in a tree-like manner.

Depending on the user's specifications, either all library units are preselected and displayed in the primary window (PF_1) or only those that meet a filter condition specified by the user specifications. The filter condition is determined by individual filter conditions. The single filter conditions can be switched on or off independently of each other. The activated individual filter conditions are combined to the filter condition used for the preselection. Fig. 12 shows which individual filter conditions can be switched on or off:

The library units are preselected, which are of a certain type, e.g. B. all packages or all function instances.

The library units are preselected, the names of which meet a certain condition, e.g. B. start with A.

- The library units that are used at least m times and / or at most n times are selected. Depending on user specifications, all or only the following import and export relations are counted:

- the direct exports to a translation unit specification, the direct exports to a translation unit implementation, the direct exports to a translation subunit, the direct imports to another library unit, the indirect exports to a translation unit specification, the indirect exports to one Implementation of translation units, indirect exports to one translation subunit, indirect imports to another library unit.

In Fig. 12, import and export relations are referred to as uses.

The representation generated according to the invention is preferably on an output unit, for. B. a screen, a data processing system displayed. Graphical user interface Surfaces {graphical user interfaces) such as MS Windows or UNIX versions offer different functions to display different windows on the screen, e.g. B. the primary window and the secondary window of a selected view. Furthermore, extensive lists with names of objects (“list view”) can be displayed. If these functionalities are used for the method according to the invention, the objects to be displayed are structural elements of the software system.

For example, two lists of structure elements are displayed in two secondary windows, which are in two specific relationships with a structure element previously selected in the primary window. A user is able to select one of the displayed objects. After selecting a structure element, for example, a selection menu with possible actions is displayed. B. Creation and display of a new view, this is carried out. Further developments of this functionality show multi-column lists, so that relations between objects can be displayed in this way. With the help of a scrolling function, certain sections of the list can be displayed quickly. Further functionalities ("tree views") indicate hierarchical relationships between objects.

An icon for the type of structure element is preferably displayed to the left of each structure element that is displayed in a primary or secondary window. 14 shows an example of the pictograms for each type of structural element.

After selecting a structure element, a context menu for the structure element is preferably shown after a corresponding user specification. The user specification consists, for example, of pressing the right mouse button. The next steps, which can be activated by selection in the context menu, include the generation of a second view according to claim 19. 14 illustrates the creation of a second view. A structure element (SE_2) that is displayed in a secondary window (SF_1.1, SF_1.2) of the selected view (S_l) is selected. A second view (S_2) of the architecture is then selected, generated and displayed. The second structure element (SE_2) is displayed in the primary window (PF_2) of the second view (S_2). Then either the second structure element (SE_2) or a third structure element (SE_3), which is displayed in the primary window (PF_2) of the second view (S_2), is selected in the primary window (PF_2) of the second view (S_2). Then, in a secondary window (SF_2.1, SF_2.2) of the second view (S_2), a number of further structure elements (SE_4.1, SE_4.2) are displayed, which are linked to the second (SE_2) or third structure element (SE_3) stand in a certain relation.

LIST OF REFERENCE NUMBERS

Claims

claims

Method for generating a representation of an architecture of a software system, the representation being generated automatically by a data processing system, a source program of the software system being given in a specific programming language (P), the architecture comprising structural elements of the software system, the architecture being determined automatically, exactly one primary window (PF_1) and at least one secondary window (SF_1.1, SF_1.2) is generated,

Structure elements (SE_1, SE_l.x) are displayed in the primary window (PF_1)

- and after selection of a structure element (SE_1) from the structure elements (SE_1, SE_l.x) displayed in the primary window (PF_1), information about the selected structure element (SE_1) is displayed in at least one secondary window (SF_1.1, SF_1.2), characterized in that that at least one selected view (S_l) from a set of views (S_l, S_2) on the architecture is generated and displayed by at least the following steps:

- Determination of all structural elements that belong to at least one selected from a set of categories tegorie belong to structural elements, whereby the categories depend exclusively on the programming language (P),

Preselection of determined structural elements (SE_1, SE__l.x) based on a specified criterion,

Displaying the preselected structure elements (SE_1, SE_l.x) in the primary window (PF_1) after selecting a structure element (SE_1) from the structure elements displayed in the primary window (PF_1)

(SE_1, SE_l.x) Determine those additional structure elements that are associated with the selected structure element

(SE_1, SE_l.x) stand in at least one specific relation, different permissible relations being distinguished between structural elements,

Display the amount of additional structure elements in the secondary window (SF 1.1, SF 1.2).

Method according to Claim 1, ie that the preselection of determined structural elements is carried out by preselecting all structural elements of at least one category.

A method according to claim 1, characterized in that the preselection of determined structural elements is carried out by preselecting those structural elements of at least one category which meet a previously defined filter condition. f

49

4. The method according to any one of claims 1 to 3, d a d u r c h g e k e n n z e i c h n e t that the category is selected from one of the following categories:

a category of file management units, which includes the files to which the source program is divided

a category of the data types, this category comprising the data types of the programming language (P) and the data types defined in the software system, a category of the data objects, which includes the variables and constants, a category of the translation units, these are the structural elements, from which a compiler or interpreter creates library units, a category of subroutines, which comprises the functions and procedures, and a category of library units, which are generated by a compiler or interpreter from translation units.

5. The method according to claim 4, so that the set of views (S_l, S_2) comprises a file source code view and after selection of the file source code view

the category of the file management units is selected and then if the selected structural element (SE_1) is a file, - The source text of the selected file (SE_1) is displayed in the secondary window (SF_1.1).

6. The method according to claim 4 or claim 5, characterized in that the set of views (S_l, S_2) comprises a data type view, after selecting the data type view, the category of data types is selected and those structural elements of the software system as the set of further structural elements can be determined in which the selected data type (SE_1) is used.

7. The method according to any one of claims 4 to 6, that the set of views (S_l, S_2) comprises a data object view and after selection of the data object view

- The category of the data objects is selected and then, if the selected structure element (SE_1) is a variable or constant, those library units of the software system that access the selected variable or constant (SE_1) as read or write are determined as the set of further structure elements ,

8. The method according to claim 7, characterized in that when the selected structural element (SE__1) is a variable or constant, - At least three secondary windows (SF_1.1, SF_1.2, SF_1.3) are generated, in a first secondary window (SF_1.1) those library units of the software system are displayed as further structure elements (SE_2, SE_2.x) that refer to the selected one Access variables or constants (SE_1) for writing and non-reading, in a second secondary window (SF_1.2) as additional structure elements (SE_2, SE_2.x) those library units of the software system are displayed that refer to the selected variable or constant (SE_1) read and not write access, in a third secondary window (SF_1.3) those library units of the software system are displayed as additional structure elements (SE_2, SE_2.x) that have both read and write access to the selected variable or constant (SE_1).

9. The method according to claim 7 or claim 8, so that after selection of the data object view, the preselected data objects (SE_1, SE_l.x) are displayed in ascending or descending order according to the number of times they are used.

10. The method according to any one of claims 7 to 9, characterized in that after selection of the data object view, a primary window (PF_1) with at least two columns is generated, - The names of the preselected data objects (SE_1, SE_l.x) are displayed in a first column of the primary window (PF_1)

- And in a second column of the primary window (PF_1) next to a data object, the names of the library unit in which the data object is defined are displayed.

11. The method according to any one of claims 4 to 10, so that the set of views (S_l, S_2) comprises a structure view and after selection of the structure view the category of the library units is selected

- And as the set of further structure elements (SE_2, SE_2.x) those library units of the software system are determined which are defined or used by the selected structure element (SE_1).

12. The method of claim 11, d a d u r c h g e k e n n z e i c h n e t that after selection of the construction view

- at least two secondary windows (SF_1.1, SF_1.2) are generated,

- those structural elements (SE_2, SE_2.x) of the software system that are defined in the specification of the selected structural element (SE 1) are displayed as further structural elements (SE_2, SE_2.x) in a first secondary window (SF_1.1), - And in a second secondary window (SF_ .2), as structure elements (SE_2, SE_2.x), those structure elements (SE__2, SE_2.x) of the software system are displayed that are used in the implementation of the selected structure element (SE_1).

13. The method according to any one of claims 4 to 12, that the set of views (S_l, S_2) comprises a call view and after selection of the call view

- the category of the subroutines is selected,

- at least two secondary windows (SF_1.1, SF_1.2) are generated, in a first secondary window (SF__1.1) those subroutines of the software system are displayed as additional structure elements (SE_2, SE_2.x) that are selected by the selected subroutine (SE_1) be called,

- And in a second secondary window (SF_1.2) as further structure elements (SE_2, SE_2.x) those subroutines of the software system are displayed, from which the selected subroutine (SE_1) is called.

14. The method according to claim 13, characterized in that after selecting the call view the preselected subroutines (SE_1, SE_l.x) are displayed in ascending or descending order according to their number of uses.

15. The method according to claim 13 or claim 14, characterized in that after selection of the call view in a first column of the primary window (PF_1) the names of the preselected subroutines (SE_1, SE_l.x) are displayed and in a second column of the primary window ( PF_1) In addition to the name of a subroutine, the name of the library unit in which the subroutine is defined is displayed.

16. The method according to any one of claims 4 to 15, so that the set of views (S_l, S_2) comprises an import-export view and after selecting the import-export view, the category of the library units is selected,

- at least two secondary windows (SF_1.1, SF_1.2) are generated,

- In a first secondary window (SF_1.1), those library units of the software system that are imported from the selected library unit (SE_1) are displayed as further structure elements (SE_2, SE_2.x),

- and in a second secondary window (SF_1.2) as further structural elements (SE 2, SE 2.x) those bib library units of the software system are displayed, from which the selected library unit (SE_1) is imported.

17. The method according to any one of claims 1 to 16, d a d u r c h g e k e n n e e c h n e t that in addition a step flow chart is generated and displayed, which shows in which order which structural elements are called and processed when the source program is executed.

18. The method according to any one of claims 1 to 17, so that a representation is generated that comprises all views of the set of views (S_l, S_2).

19. The method according to any one of claims 1 to 18, characterized in that after selecting a second structure element (SE_2) displayed as a further structure element in a secondary window (SF_1.1, SF_1.2) of the selected view (S_l), a second view (S_2) selected, created and displayed on the architecture, the further structure element (SE_2) being displayed in the primary window (PF_2) of the second view (S_2) and after selection of the second structure element (SE_2) in the primary window (PF_2) of the second view (S_2) or after selecting one of the second in the primary window (PF 2) View (S_2) displayed third structure element (SE_3) a set of further structure elements which are related to the second (SE_2) or third structure element (SE_3) in at least one specific relationship, and the determined further structure elements in a secondary window (SF_2. 1, SF_2.2) of the second view (S__2).

20. The method according to claim 19, so that the method steps of claim 19 are repeatedly carried out in succession, the second view (S_2) being used at least once as the selected view (S_l).

21. The method according to claim 19 or claim 20, characterized in that after selection of a structural element (SE_1, SE_l.x) displayed in the primary window of the selected view or one of the selected view (S_l) in a secondary window (SF__1.1, SF_1.2) displayed structure element (SE_2, SE_2.x) the positions in the source program are determined and displayed at which the selected structure element is defined or used.

22. Device for performing the method according to one of claims 1 to 21, characterized in that the device comprises a device for determining the architecture of the software system and a device for generating a representation of the determined architecture.

23. The device according to claim 22, characterized in that the device for generating a representation, a device for selecting at least one view from a set of views (S_l, S_2) on the architecture, a device for generating and displaying a selected view (S_l), the view comprises exactly one primary window (SE_1) and at least one secondary window (SF_1.1, SF_1.2), a device for preselecting structural elements of the software system, a device for displaying the preselected structural elements (SE_1, SE_l.x) in the primary window ( PF_1) of the selected view (S_l), a device for displaying information about a selected structural element (SE_1) in a secondary window (SF_1.1, SF_1.2) of the selected view (S_l), and a device for displaying a set of others Structure elements (SE_2, SE_2.x) that are in at least one specific relation with the selected structure element (SE_1) in a second ar window (SF_1.1, SF_1.2) of the selected view (S_l).

24. Computer program product which can be loaded directly into the internal memory of a computer and comprises software sections with which a method according to one of claims 1 to 21 can be carried out when the product is running on a computer.

25. A computer program product which is stored on a computer-readable medium and which has computer-readable program means which cause the computer to carry out a method according to one of claims 1 to 21.